Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th January 2012, 13:13   #1441  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,019
Quote:
Originally Posted by aufkrawall View Post
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:
Code:
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?

Last edited by TheFluff; 24th January 2012 at 13:17.
TheFluff is offline   Reply With Quote
Old 25th January 2012, 02:14   #1442  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,682
Quote:
Originally Posted by TheFluff View Post
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.

Quote:
Originally Posted by TheFluff View Post
Post a sample.
http://ht4u.net/images/reviews/2011/...x580hq_neu.avi
Thanks for taking a look at it.

Quote:
Originally Posted by TheFluff View Post
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

Last edited by aufkrawall; 25th January 2012 at 02:28.
aufkrawall is offline   Reply With Quote
Old 25th January 2012, 03:31   #1443  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,019
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.
TheFluff is offline   Reply With Quote
Old 25th January 2012, 03:42   #1444  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?
henryho_hk is offline   Reply With Quote
Old 25th January 2012, 03:50   #1445  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,019
Quote:
Originally Posted by henryho_hk View Post
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.
TheFluff is offline   Reply With Quote
Old 25th January 2012, 04:01   #1446  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by TheFluff View Post
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:
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 25th January 2012, 04:35   #1447  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,682
Quote:
Originally Posted by TheFluff View Post
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:


Quote:
Originally Posted by TheFluff View Post
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.
aufkrawall is offline   Reply With Quote
Old 25th January 2012, 08:46   #1448  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,373
A change in the hue rather sounds like different colorimetrics?!
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 25th January 2012, 09:23   #1449  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,682
Quote:
Originally Posted by LigH View Post
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.
aufkrawall is offline   Reply With Quote
Old 25th January 2012, 10:53   #1450  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 453
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 ).
__________________
x264 full help - x264 --fullhelp r2345
Cuttermaran HCEnc provider - Support for HCEnc in Cuttermaran
DualDVDRB - Dual core support for DVD-RB free
Rumbah is offline   Reply With Quote
Old 25th January 2012, 11:06   #1451  |  Link
the_weirdo
Yes, I'm weird.
 
the_weirdo's Avatar
 
Join Date: May 2010
Location: Southeast Asia
Posts: 273
Quote:
Originally Posted by aufkrawall View Post
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?
the_weirdo is offline   Reply With Quote
Old 25th January 2012, 18:57   #1452  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,019
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:
Code:
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.

Last edited by TheFluff; 25th January 2012 at 18:59.
TheFluff is offline   Reply With Quote
Old 26th January 2012, 00:47   #1453  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,682
Quote:
Originally Posted by TheFluff View Post
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:
Code:
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*).

Quote:
Originally Posted by TheFluff View Post
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.
aufkrawall is offline   Reply With Quote
Old 26th January 2012, 01:22   #1454  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 415
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 !

Last edited by Pat357; 26th January 2012 at 01:37. Reason: Added a question :)
Pat357 is offline   Reply With Quote
Old 26th January 2012, 03:17   #1455  |  Link
TheRyuu
warpsharpened
 
Join Date: Feb 2007
Posts: 788
Quote:
Originally Posted by Pat357 View Post
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).
TheRyuu is offline   Reply With Quote
Old 29th January 2012, 06:49   #1456  |  Link
bencahill
Registered User
 
Join Date: Oct 2009
Posts: 10
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.
bencahill is offline   Reply With Quote
Old 29th January 2012, 16:48   #1457  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,019
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.
TheFluff is offline   Reply With Quote
Old 29th January 2012, 19:46   #1458  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
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.
Yellow_ is offline   Reply With Quote
Old 29th January 2012, 22:54   #1459  |  Link
bencahill
Registered User
 
Join Date: Oct 2009
Posts: 10
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.
bencahill is offline   Reply With Quote
Old 30th January 2012, 01:43   #1460  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,019
File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:
Quote:
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.
TheFluff is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.