FFmpegSource

[Guest]

Originally Posted by JEEB

I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is.

It appears fine to me. Using DGDecodeNV it decodes perfectly and the GPU deinterlacing looks very nice as well. I reported this bug years ago to the lavc guys, but nobody ever cared about it.

[JEEB]

Originally Posted by neuron2

It appears fine to me. Using DGDecodeNV it decodes perfectly and the GPU deinterlacing looks very nice as well. I reported this bug years ago to the lavc guys, but nobody ever cared about it.

Alrighty, can you link to the old bug report or something that would have more details on it, or, if that's no longer available, can you give some more technical details that I can then push towards both projects? It seems like both sides are nowadays more active with regards to getting bug reports dealt with.

[Daemon404]

Originally Posted by JEEB

This sample seems to have mostly been fixed with the recent multithreading-fixing commits

After a brief test with Aegisub the only problem I was getting was that every frame came out twice, which could be sample-related (I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is, as most things seem to fail to mux or deal with the H.264 stream included to begin with). Otherwise it seems like frame order was correct, and all frames seem to be output correctly. With Avisynth I did also try with threads=1 and that for some reason brought back the jerkiness in a bit different way.

A build is available for testing here.

My own code using the ffms2 lib works fine, but this may be related:

pts: 80
pts: 100
pts: 0
pts: 20
pts: 0
pts: 0
pts: 20
pts: 20
pts: 242
pts: 274
pts: 306
[...]

[le_canz]

I all First, I'd like to thank all the devs for ffmpegsource, it's the only source method I use with avisynth, and I works great (well... not always )

I have some trouble opening MTS files from some digital camera with ffmpegsource. I don't know which camera unfortunately, as it wasn't mine... This file plays fine with VLC.

Video is H264 interlaced 1440x1080, and what ffmpegsource shows is quite messed up : frames are sometimes repeated twice, and fields appear not to be in the good order.

I tried with several ffmpegsource builds (683 from google code, 695 compiled by JEEB), same result. FFIndex() doesn't help, nor remuxing to mkv.

I use avisynth 2.6 with linux / wine 1.4

Here is a small sample if you want to try.
http://dl.free.fr/ghi9NtIxE

[LigH]

PAFF interlaced AVC videos recorded by AVCHD cameras are known problems for the libav decoder already for longer. Did you use the parameter 'threads=1'?

[le_canz]

Originally Posted by LigH

PAFF interlaced AVC videos recorded by AVCHD cameras are known problems for the libav decoder already for longer.

I didn't know that. Thanks for the info.

Originally Posted by LigH

Did you use the parameter 'threads=1'?

Yes, same result.

[leoenc]

Could someone please share a current build (r700)?

Thanks

[JEEB]

Random build time: clicky.

ffms2: r700, libav: git-c29c1a1

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__ -D_SYSCRT' --disable-debug --enable-runtime-cpudetect

[Wilbert]

Just curious. Is FFmpegSource be able to load MXF files? I see that it was added to libavformat at some point.

[JEEB]

Originally Posted by Wilbert

Just curious. Is FFmpegSource be able to load MXF files? I see that it was added to libavformat at some point.

Tried with the Cars M2V sample available at mplayerhq, and it seems to load fine and linear decoding seems to be fine. Seeking backwards seemed a little awkward but I'm not sure if setting threads to one might help with that.

[wonkey_monkey]

Just out of curiosity, is there a simple explanation as to why ffmpegsource is frame-accurate with, for example, MKV, but not with VOB/MPG? Is it just a limitation of a library that's no-one's ever bothered to improve?

David

[Wilbert]

Tried with the Cars M2V sample available at mplayerhq, and it seems to load fine and linear decoding seems to be fine. Seeking backwards seemed a little awkward but I'm not sure if setting threads to one might help with that.

If I try to open it with 2.17 (ffms-2.17.7z) i get the following error:

Avisynth open failure:
FFVideoSource: Can't open blabla ...

script:

FFVideoSource("F:\Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf")

[Plorkyeran]

I made several MXF-related fixes recently to handle its lack of timestamps. r700 works correctly on all of the files I tested it on (which was not very many).

Originally Posted by davidhorman

Just out of curiosity, is there a simple explanation as to why ffmpegsource is frame-accurate with, for example, MKV, but not with VOB/MPG? Is it just a limitation of a library that's no-one's ever bothered to improve?

DGIndex mostly works fine, so things it can open are lower priority than formats which don't have any reasonable alternatives. AFAIK MPEG-2 in VOB should work fine as long as RFF handling is enabled other than that split VOBs aren't supported.

[wonkey_monkey]

Originally Posted by Plorkyeran

AFAIK MPEG-2 in VOB should work fine as long as RFF handling is enabled other than that split VOBs aren't supported.

Just today I was unable to get within 3 frames accurate on MPEG-2 in VOB (PAL, so no RFF) DGIndex is great, of course, but I'd love an alternative that didn't require demuxing audio.

David

[Plorkyeran]

If you can upload a sample with issues I'll take a look at it when I get a chance.

[qyot27]

FFMS2 C-plugin r700

FFmpeg version r42437 git-9b3f9f4
Both FFmpeg and FFMS2 built with GCC 4.8.0 20120610 (experimental)
Both optimized for Pentium III

Contains some really bleeding edge support for decoding 12-bit and 14-bit 4:2:0 H.264, thanks to recent commits to FFmpeg. It seems to be most stable with 12-bit, although some of the problems I've been having getting the samples prepared could be due either to swscale issues or the tricky nature of trying to get the config files for JM (18.3, if that matters) correctly set. I had some 14-bit tests that seemed fine, but others went wonky and I can't determine which parts threw it off. 4:2:2 and 4:4:4 in either of the new bit depths result in mostly green output, which may or may not be due to swscale (my money is on swscale, but I can't be completely sure).

EDIT: New build here

[burfadel]

Originally Posted by qyot27

FFMS2 C-plugin r700

FFmpeg version r42437 git-9b3f9f4
Both FFmpeg and FFMS2 built with GCC 4.8.0 20120610 (experimental)
Both optimized for Pentium III

Contains some really bleeding edge support for decoding 12-bit and 14-bit 4:2:0 H.264, thanks to recent commits to FFmpeg. It seems to be most stable with 12-bit, although some of the problems I've been having getting the samples prepared could be due either to swscale issues or the tricky nature of trying to get the config files for JM (18.3, if that matters) correctly set. I had some 14-bit tests that seemed fine, but others went wonky and I can't determine which parts threw it off. 4:2:2 and 4:4:4 in either of the new bit depths result in mostly green output, which may or may not be due to swscale (my money is on swscale, but I can't be completely sure).

This build appears to fail, at least opening AVI files. Jeeb's r700 build works fine.

I get the same error as Wilbert in post http://forum.doom9.org/showthread.ph...34#post1580834

[qyot27]

I just tested an XviD AVI and an ffvhuff AVI. Both indexed without issue and the scripts played back fine.

Without more information, it's not possible to tell whether it's a compilation problem, a libavformat/codec problem, a script problem, or something in FFMS2 itself.

[qyot27]

It seems as though something has changed which makes MP4 files no longer work. All the MP4 files I tested with it fail, including music videos purchased from iTunes and videos that have been remuxed into MP4 with MP4Box. Files muxed by L-SMASH seem to be fine.

It's probably because of a change in libavformat, since a build of FFMS2 r700 from June 28th works, but ones from July 4th and 10th don't, responding with:

Indexing error: Invalid initial pts, dts, and duration

MOV and FLV files are unaffected, and FFmpeg itself deals with these same MP4s without an issue (as did the build of r700 from June 28th), so I'm guessing that what happened is that there was an API change and that's what's messing with FFMS2.


Also, I don't know what's going on (and I doubt it's related to the MP4 issue), but FFMS2 can't link to FFmpeg on any of my cross-compile environments through MinGW-w64, as it's complaining about libraries that FFmpeg shouldn't have linked to in the first place given this is a MinGW build:

checking whether i686-w64-mingw32-gcc works... yes
checking for -std=gnu99... yes
checking whether defined(_WIN32) is true... yes
checking for CoUninitialize(); in objbase.h... yes
checking whether LIBAVCODEC_VERSION_MICRO >= 100 is true... yes
checking for avcodec_decode_video2( 0, 0, 0, 0 ); in libavformat/avformat.h... no
Failed commandline was:
--------------------------------------------------
i686-w64-mingw32-gcc conftest.c  -Wall -march=pentium3 -mtune=pentium3 -std=gnu99  -lz -lbz2 -lpthreadGC2 \
     -lutvideo -lole32 -I/home/qyot27/win32_build/include -I/usr/local/include   -L/home/qyot27/win32_build/lib \
     -lswscale -lavformat -lavcodec -lavutil -lavifil32 -pthread -L/usr/local/lib -lavformat -lavcodec -ldl -lva \
     -ljack -lasound -lSDL -lxvidcore -lutvideo -lstdc++ -lbz2 -lz -lrt -lswscale -lavutil -lm  
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ldl
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lva
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ljack
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lasound
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lSDL
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
--------------------------------------------------
DIED: unable to link against FFmpeg

It's also trying to test FFMS2 against xvidcore and I didn't even have that in the FFmpeg configure, which was this:

  configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 \
     --disable-w32threads --enable-memalign-hack --disable-decoder=utvideo --enable-libutvideo --disable-encoders \
     --disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
     --cpu=pentium3 --extra-cflags='-march=pentium3 -mtune=pentium3 -DPTW32_STATIC_LIB' --target-os=mingw32 --arch=x86

The FFmpeg binary seems unaffected, because it'll display its normal output just fine under actual Windows (I can't do further testing with it due to it being reduced like it is).

That particular issue seems to have cropped up in just the last week or so, since the July 10th build was cross-compiled, but my attempts over the last day or two have resulted in the error above.

[Kovensky]

Originally Posted by qyot27

 (...) -L/home/qyot27/win32_build/lib \
     -lswscale -lavformat -lavcodec -lavutil -lavifil32 -pthread -L/usr/local/lib -lavformat -lavcodec -ldl -lva \
     -ljack -lasound -lSDL -lxvidcore -lutvideo -lstdc++ -lbz2 -lz -lrt -lswscale -lavutil -lm  
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ldl
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lva
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ljack
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lasound
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lSDL
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status

It's actually trying to link with two different "ffmpegs" at the same time, including your system one. Make sure pkg-config is properly configured; use PKG_CONFIG_LIBDIR to make sure it doesn't try to look in any of the default paths.