FFmpegSource

[Myrsloik]

FFMS currently has an issue opening 10bit per component yuv files (such as those that can made with a recent x264). The cause is known and should be fixed within a week or two.

[Mini-Me]

Two questions:

• Is support for YV24 (etc.) currently built into FFMS/FFMS2, or does the codebase need to be updated for that?
• Now that x264 can output 4:4:4 streams and libavcodec can decode them, are the FFMS2 packagers planning on releasing updated builds that take advantage of this?

[kemuri-_9]

Originally Posted by Mini-Me

Two questions:

• Is support for YV24 (etc.) currently built into FFMS/FFMS2, or does the codebase need to be updated for that?
• Now that x264 can output 4:4:4 streams and libavcodec can decode them, are the FFMS2 packagers planning on releasing updated builds that take advantage of this?

no, ffms2 needs to be updated to support any of the new colorspaces in avs 2.6 - including YV24,
and this generally means that avs 2.6 should finish the de-baking of code to where the interface is usable again.

Edit:
I should clarify that i'm referring to the ability for the ffms2 plugin to output the streams as 4:4:4, currently they'll be decoded and then converted internally to one of the colorspaces that 2.5 supports.

[qyot27]

As long as the libav stuff it's linked against supports the colorspaces, I don't see why it couldn't (although I guess one might also need to be using 2.6 for this to work). I've been able to decode 4:4:4 with my own builds since I noticed the relevant commits on x264-devel a couple weeks ago and started doing tests with it. And I'd guess that's because 4:4:4 support in ffmpeg was already there for a day or two at the time I compiled it.

The only strange part is that ConvertToYV24 in the original script results in AviSynth outputting greyscale video to media players, but using FFMS2 to decode an already 4:4:4 H.264 file gives the correct colors in the same media players (and the player decodes the actual file correctly as well; recent ffdshow, at any rate). I suppose the colorspace actually being output when playing a 4:4:4 H.264 file uses the opposite channel mapping than YV24 does, somewhat like the whole YV12 is fine/I420 isn't stuff. Or something like that.

Now, RGB stuff is still off (as in, the channels are swapped in a way I can't figure out how to reverse), but it's better than it was a couple weeks ago when it was mostly a grey nothingness.




So the short version of all that is: it's already 'kind of' capable from what I can see, you just need to compile it against a recent libavcodec and probably also use either the AviSynth 2.6 alpha from May 2011 (which I'm currently using), or a similar trunk build like the ones JEEB posted back in January (which I was using before).

[TheRyuu]

ffms2-r484.7z
ffms2-r484-avs64.7z

Changes since last build:
-Updated build chain to gcc 4.6.1
-Now using msvc2010 for 32bit builds.
-Updated libav to rev. 2cb6dec
-Fixed what was known as the "parse_nal_units" segfault. It was feeding audio packets into the h264 parser.
-Fixed forcing of certain output formats

[pandy]

btw - not sure how it can be compared to GCC however some results looks very impressive

http://www.phoronix.com/scan.php?pag...th4_open&num=1

[aegisofrime]

Originally Posted by pandy

btw - not sure how it can be compared to GCC however some results looks very impressive

http://www.phoronix.com/scan.php?pag...th4_open&num=1

It does look very impressive, however being only for Linux et al and not Windows, it's not exactly relevant to FFMS2 at this point.

[Blue_MiSfit]

Hi guys,

I'm having strange issues with some QuickTime wrapped DVCPro HD files. These files are in-theater trailers, and have the following strange behavior

1) In QuickTime player these MOVs are totally in sync, and begin with a usual MPAA green-band warning.

2) If I use something like x264 or ffmpeg with the lavf demuxer to transcode these into H.264, the video starts much earlier, with extra frames visible. These frames are either black, or production slates. I'm not sure how this is masked out from normal viewing in QuickTime Player. I think it has something to do with a "QuickTime EDL Cut List", but I'm not certain.

3) If I indead use FFMS2 inside of AviSynth, the video does start at the green-band, but the audio track has a lot of silence in the beginning, making the audio way out of sync. This extra silence is the same length as the production slate I see when I transcode with something that uses lavf splitter.

4) If I trim the MOV using QuickTime Pro, all this strangeness goes away, and both ffms2 and lavf produce the same results. This makes me think doing a trim, followed by a "save as" in QuickTime Pro does actually trim off the junk in the beginning

5) Manually trimming in QuickTime is a pain in the ass, so instead I use some simple scripting to make x264 transcode the video into a high birate MKV, use ffmpeg to dump a PCM WAV from the original WAV, and mux both results into an MKV. This then opens into AviSynth nicely with FFMS2, and I can set my trims in here to strip away the junk.

In conclusion, I think there's something different with how lavf and ffms2 handle MOV files. This wouldn't surprise me

Both behaviors are "incorrect", with "correctness" defined as "giving me the same result as QuickTime Player". FFMS2 starts the video in the proper place , but reads the audio from the beginning. lavf reads both from the beginning, and reveals content that shouldn't be visible.

I have a sample file, if someone is curious and wants to try to fix this. Apologies for the size, performing a trim is useless for the reasons I stated above. Here is the link:

http://www.mediafire.com/?n0wwl5adwuepm

Hopefully somebody cares ! As always, thanks for all the hard work on this awesome piece of software!!

Thanks,
Derek

[TheFluff]

Interesting problem, I'll have a look. What audio delay mode were you using with ffaudiosource?

[Blue_MiSfit]

Hmm... the default?

Thanks for your time!

[TheRyuu]

Originally Posted by Blue_MiSfit

Hmm... the default?

Thanks for your time!

From the documentation:

FFAudioSource

FFAudioSource(string source, int track = -1, bool cache = true,
string cachefile = source + ".ffindex", int adjustdelay = -1, bool utf8 = false)


Opens audio. Invokes indexing of all tracks if no valid index file is found, or if the requested track isn't present in the index.

Arguments
Are exactly the same as to FFVideoSource, with one exception:

int adjustdelay = -1
Controls how audio delay is handled, i.e. what happens if the first audio sample in the file doesn't have a timestamp of zero. The following arguments are valid:

-3: No adjustment is made; the first decodable audio sample becomes the first sample in the output.
-2: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at time zero.
-1: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at the same time as frame 0 of the first video track. This is the default, and probably what most people want.
Any integer >= 0: Same as -1, but adjust relative to the video track with the given track number instead. If the provided track number isn't a video track, an error is raised.

-2 obviously does the same thing as -1 if the first video frame of the first video track starts at time zero. In some containers this will always be the case, in others (most notably 188-byte MPEG TS) it will almost never happen.

[Mini-Me]

Originally Posted by TheRyuu

ffms2-r484.7z
ffms2-r484-avs64.7z

Changes since last build:
-Updated build chain to gcc 4.6.1
-Now using msvc2010 for 32bit builds.
-Updated libav to rev. 2cb6dec
-Fixed what was known as the "parse_nal_units" segfault. It was feeding audio packets into the h264 parser.
-Fixed forcing of certain output formats

Thanks for the responses, kemuri-_9 and qyot27! Keeping your replies in mind, I just tried with the new build in the quoted message (thank you, TheRyuu!). While FFVideoSource still does not output YV24, it will now read 4:4:4 H.264 video. As a consequence, we can now get genuine 4:2:2 output from a 4:4:4 file by setting "colorspace" to "YUY2" in the FFVideoSource parameters.

In other words, we can convert YUY2 to YV24, encode with x264 as 4:4:4, and load it back into Avisynth without ever having to go through YV12 (resolution reduction). Encoding 4:2:2 as 4:4:4 may be somewhat wasteful, but doing exactly that and using a higher quantizer for chroma (to get the same filesize as YV12 encodes) is now a pretty viable option now for archiving YUY2 captures. For the same filesize, I'm getting basically equivalent luma but chroma that is much more faithful to the source. (I'm using extremely high bitrates though, so it might be a different story with "regular" bitrates.)

[TheRyuu]

ffms2-r494.7z
ffms2-r494-avs64.7z

Changes since last build:
-Not much...
-Updated libav to rev. e3bc07f

[Plorkyeran]

Audio delay mode -2 appears to give the correct result, but it's sort of hard to tell if it's perfectly synced as it doesn't quite play in real time on my machine.

[TheFluff]

Originally Posted by Mini-Me

Thanks for the responses, kemuri-_9 and qyot27! Keeping your replies in mind, I just tried with the new build in the quoted message (thank you, TheRyuu!). While FFVideoSource still does not output YV24, it will now read 4:4:4 H.264 video. As a consequence, we can now get genuine 4:2:2 output from a 4:4:4 file by setting "colorspace" to "YUY2" in the FFVideoSource parameters.

FFMS2 can't output YV24 because Avisynth (2.5) doesn't support it. Avisynth 2.6 does, but so far I haven't looked into what needs to be done on FFMS2's side to make it a working 2.6 plugin. If you want the support like RIGHT NOW you need to write a patch yourself (any contributions are welcome), but if you're okay with waiting we'll get around to it eventually.

[forclip]

Hi. Just wondering, is it normal that FFVideoSource produces an error "No suitable output format found" when I trying to open a 10-bit depth samples with "default call"? Is it possible to auto choose the most suitable output format that can be supported (by FFMS2 and AviSynth) without explicity specifying it with "colorspace" key?

[Myrsloik]

Originally Posted by forclip

Hi. Just wondering, is it normal that FFVideoSource produces an error "No suitable output format found" when I trying to open a 10-bit depth samples with "default call"? Is it possible to auto choose the most suitable output format that can be supported (by FFMS2 and AviSynth) without explicity specifying it with "colorspace" key?

I've said it before and I'll say it again. This is a bug in libav/ffmpeg. The bug report is here:
http://bugzilla.libav.org/show_bug.cgi?id=10
I'm however very close to copying that function out of libav and fixing it just to work around this bug.

[Myrsloik]

Originally Posted by Mini-Me

Thanks for the responses, kemuri-_9 and qyot27! Keeping your replies in mind, I just tried with the new build in the quoted message (thank you, TheRyuu!). While FFVideoSource still does not output YV24, it will now read 4:4:4 H.264 video. As a consequence, we can now get genuine 4:2:2 output from a 4:4:4 file by setting "colorspace" to "YUY2" in the FFVideoSource parameters.

Blah blah blah...

Since colorspace conversion is done at the same time as scaling internally you can double the width of the video to get full resolution chroma information too. (kinda hackish but that's one of the reason the output dimensions and colorspace can be specified)

[forclip]

Myrsloik
OK, thanks for the clarification.

[Mini-Me]

Originally Posted by TheFluff

FFMS2 can't output YV24 because Avisynth (2.5) doesn't support it. Avisynth 2.6 does, but so far I haven't looked into what needs to be done on FFMS2's side to make it a working 2.6 plugin. If you want the support like RIGHT NOW you need to write a patch yourself (any contributions are welcome), but if you're okay with waiting we'll get around to it eventually.

Actually, the only reason I personally wanted 4:4:4 was so I could get 4:2:2. Once I realized FFMS2 could read 4:4:4 files and output in the YUY2 colorspace, I knew I was set.

I just wanted to point out to others that this is a viable option for archiving analog captures now: Interlaced YUY2 is a common capture format for analog video, and downsizing to interlaced YV12 is suboptimal (without motion-adaptive upsampling on playback, it creates artifacts). Now that x264 has 4:4:4 input/output, it's now viable to just upsize YUY2 to YV24, encode as 4:4:4, and increase the chroma quantizer to keep the filesize down. I was originally afraid that FFMS2 would drag everything through YV12 and I wouldn't be able to compare the two encodes (4:2:0 vs. 4:4:4), but that is thankfully not the case.

Originally Posted by Myrsloik

Since colorspace conversion is done at the same time as scaling internally you can double the width of the video to get full resolution chroma information too. (kinda hackish but that's one of the reason the output dimensions and colorspace can be specified)

Although I don't need true 4:4:4, this is actually a really good point for those who do!