FFmpegSource

[TheFluff]

Originally Posted by aufkrawall

I encounter a problem with FFMS 2.17 that wasn't there with 2.16 cbuild: It seems that it doesn't convert range from PC to TV correctly.
I used the following script:

LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
FFVideoSource("alt.avi")
AssumeFPS(30.0)
ConvertToYV12(matrix="Rec709")

Source was FRAPS I420.
With 2.16 the x264 result looked like this:

2.17 (too dark):

2.17 looks more correct to me, and I know Fraps has some super mysterious color matrix magic going on, but I can take a look anyway. Post a sample.

Your Avisynth script doesn't convert to RGB either, so that conversion happens elsewhere. What colorspace is FFMS2 outputting?

[aufkrawall]

Originally Posted by TheFluff

2.17 looks more correct to me, and I know Fraps has some super mysterious color matrix magic going on, but I can take a look anyway.

The 2.16 screenshot looks exactly like the original FRAPS source.
2.17 really is too dark, details get lost in darkness.

Originally Posted by TheFluff

Post a sample.

http://ht4u.net/images/reviews/2011/...x580hq_neu.avi
Thanks for taking a look at it.

Originally Posted by TheFluff

Your Avisynth script doesn't convert to RGB either, so that conversion happens elsewhere. What colorspace is FFMS2 outputting?

I assume it just outputs YV12/I420, just like the CSP of the source is.
x264's range conversion doesn't work (colors look slightly wrong), that's why I used Rec709 (I don't know why FRAPS keeps PC range in I420 mode...).
Here's the encoded video with ffmpegsource 2.16:
http://www.mediafire.com/?h2nsa7qtt6f56as

[TheFluff]

Took a look at the sample file. FFMS2 correctly detects the input as PC range I420 and does no conversions at all. Your ConvertToYV12() line does nothing since the input already is YV12 (I420 is the same thing as YV12 but with the chroma plane order swapped; Avisynth considers the two formats the same for most purposes). I assume that when VirtualDub (or whatever you're screenshotting with) converts the YV12 input to RGB for display, it does so while incorrectly assuming TV range. I added ConvertToRGB32(matrix="PC.709") to the end of the script and then I got mostly the same results as in your 2.16 screenshot (didn't compare exactly but it looks very similar at least). FFVideoSource(..., colorspace="RGB32") gives the same results as well.

If the same script worked in 2.16, what happened there was that you were a victim of that bug I fixed; FFMS2 internally scaled the PC range input to TV range, and by pure chance the rest of your encoding/playback chain happened to assume the input was TV range and thus rescaled it to PC range again for display.

Keep in mind that when you encode with x264 and the input is an Avisynth script, x264 cannot automatically detect the color range. You'll have to tell it to set the fullrange flag appropriately.

[henryho_hk]

I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?

[TheFluff]

Originally Posted by henryho_hk

I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?

Indeed, they cannot. FFGetVersion() could return that, yes.

[kemuri-_9]

Originally Posted by TheFluff

Because there is no easy way for end users to tell the difference between a ffms2.dll that contains the C-plugin interface and one that contains the 2.5 C++ interface.

I've gone ahead and added version information to the dll when built within the c branch so you can better indicate what it is/what it can do, etc.

ex:

[aufkrawall]

Originally Posted by TheFluff

Took a look at the sample file. FFMS2 correctly detects the input as PC range I420 and does no conversions at all. Your ConvertToYV12() line does nothing since the input already is YV12 (I420 is the same thing as YV12 but with the chroma plane order swapped; Avisynth considers the two formats the same for most purposes). I assume that when VirtualDub (or whatever you're screenshotting with) converts the YV12 input to RGB for display, it does so while incorrectly assuming TV range. I added ConvertToRGB32(matrix="PC.709") to the end of the script and then I got mostly the same results as in your 2.16 screenshot (didn't compare exactly but it looks very similar at least). FFVideoSource(..., colorspace="RGB32") gives the same results as well.

But the result isn't right, colors are wrong. For example red turns more orange:

Originally Posted by TheFluff

If the same script worked in 2.16, what happened there was that you were a victim of that bug I fixed; FFMS2 internally scaled the PC range input to TV range, and by pure chance the rest of your encoding/playback chain happened to assume the input was TV range and thus rescaled it to PC range again for display.

I liked this bug, it served me well.
With it I could convert from PC to TV range without visual quality loss.
With 2.17 it even looks wrong with PC range.

[LigH]

A change in the hue rather sounds like different colorimetrics?!

[aufkrawall]

Originally Posted by LigH

A change in the hue rather sounds like different colorimetrics?!

The same happens when I let x264 convert range from PC to TV with FRAPS I420 videos.
The range conversion of AviSynth/ffms 2.16 is the only thing that works.

Range of the output file has to be TV because most decoders can't deal right with non-RGB video with PC range.

[Rumbah]

If I remember correctly Fraps does not use standard colorimetrics. That's why the normal Fraps decoder outputs RGB so it can do the correct conversion.
I did some tests a year ago and then the only way to get correct colours was to either use the normal Fraps decoder and then convert to YV12 or just capture in RGB. Else I got hue shifts in red and green (WoW chat text colours ).

[the_weirdo]

Originally Posted by aufkrawall

The same happens when I let x264 convert range from PC to TV with FRAPS I420 videos.
The range conversion of AviSynth/ffms 2.16 is the only thing that works.

Range of the output file has to be TV because most decoders can't deal right with non-RGB video with PC range.

Maybe there're flaws from your workflow. How about replace ConvertTo... line with ColorYUV(level="PC->TV")? What is your x264 command line? Which method you're using to take those screenshots?

[TheFluff]

I think FFMS 2.16 actually had another bug too that made it output RGB32. ConvertToYV12(matrix="foo") on YV12 material throws an error, so if that worked in your 2.16 script then FFMS2 definitely wasn't outputting YV12. Try this:

FFVideoSource("derp.avi", colorspace="RGB32")
ConvertToYV12(matrix="Rec709")

When I open that in VirtualDub, I get an image that matches your 2.16 screenshot on the reds, but on the other hand it looks less greenish overall. What did you screenshot with?

But yes, in the end I think Fraps does use its own color matrix that doesn't match Rec 709 perfectly.

[aufkrawall]

Originally Posted by TheFluff

I think FFMS 2.16 actually had another bug too that made it output RGB32. ConvertToYV12(matrix="foo") on YV12 material throws an error, so if that worked in your 2.16 script then FFMS2 definitely wasn't outputting YV12. Try this:

FFVideoSource("derp.avi", colorspace="RGB32")
ConvertToYV12(matrix="Rec709")

Your script works perfectly, thank you very much.
It also works great with little adjustment when converting FRAPS RGB source to I444.
Original FRAPS video and FRAPS decoder:


LAV x264:


Windows Media Player x264:


All three look almost identical (I guess WMP has some sharpening filter active *sigh*).

Originally Posted by TheFluff

When I open that in VirtualDub, I get an image that matches your 2.16 screenshot on the reds, but on the other hand it looks less greenish overall. What did you screenshot with?

I also got some weird results with VirtualDub, hence I used the save picture function of MPC HC (it extracts the source's frame).
Another advantage is that the screenshot matches the real picture drawed by the renderer to 100% in any case.
For WMP I had to make a capture of the whole screen.

[Pat357]

It would be really, really very nice if we could have the C version of this plugin soon : something like FFMS2-2.17-avs-cplugin.7z
Any idea when it will be available on the download area ?

Not that I'm looking for it, but why has there not been a 64bit version from the C plugin ? Was the "avisynth-interface" never made for x64 use ? Just curious...

Keep up the great work guys !

[TheRyuu]

Originally Posted by Pat357

It would be really, really very nice if we could have the C version of this plugin soon : something like FFMS2-2.17-avs-cplugin.7z
Any idea when it will be available on the download area ?

Not that I'm looking for it, but why has there not been a 64bit version from the C plugin ? Was the "avisynth-interface" never made for x64 use ? Just curious...

Keep up the great work guys !

ffms-2.17-cplugin.7z

Archive contains both 32-bit and 64-bit versions.
Primary use of the cplugin version is for those who want access to the extra colorspaces provided in Avisynth 2.6 (it is backward compatible with 2.5).

[bencahill]

This is really awesome, except that I'm getting artifacts on my Canon T2i footage in moving areas. (H.264 MOV)

Source:

FFMS:


I'd love to use this because it's fast and doesn't take up space (e.g. demuxing the h.264 stream), but because of this I'm using MPEGAutoIndexSource() for the time being (which is slower and takes space).

Any idea as to why this is happening? If you need me to test more, just let me know.

Thanks!

P.S. I searched, but couldn't find anything on this issue. If it's already been discussed, my apologies.

[TheFluff]

H.264 in MOV should work, AFAIK. Post sample (it doesn't need to be big, ~50MB is more than enough) and I'll take a look.

[Yellow_]

No problems with 2.17 32bit from #1438 http://forum.doom9.org/showthread.ph...91#post1553391 with Canon 550D/T2i MOVs, well at least not 1920x1088 25p.

[bencahill]

Oh yes, I forgot to mention: that clip was obtained here, so you can test it also.

It's 720p25, but I was getting the same with my 1080p30, and also with H.264 video from a Kodak Zi8. I'm guessing it's something with my setup?

I've used Avisynth 2.5.8 ST, and 2.6 MT. Using latest FFMS (2.17 with no suffix) on WinXP Home SP3 32-bit.

Thanks for your time.

[TheFluff]

File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:

Originally Posted by MKVMerge

Warning: 'E:\ffms2testclips\Bus h264 canon t2i.MOV' track 0: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

Resulting file has the same issue.

I think you should open a bugreport with ffmpeg.