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. |
24th January 2012, 13:13 | #1441 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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. |
25th January 2012, 02:14 | #1442 | Link | ||
Registered User
Join Date: Dec 2011
Posts: 1,812
|
Quote:
2.17 really is too dark, details get lost in darkness. http://ht4u.net/images/reviews/2011/...x580hq_neu.avi Thanks for taking a look at it. Quote:
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. |
||
25th January 2012, 03:31 | #1443 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
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. |
25th January 2012, 04:01 | #1446 | Link | |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Quote:
ex: |
|
25th January 2012, 04:35 | #1447 | Link | ||
Registered User
Join Date: Dec 2011
Posts: 1,812
|
Quote:
Quote:
With it I could convert from PC to TV range without visual quality loss. With 2.17 it even looks wrong with PC range. |
||
25th January 2012, 09:23 | #1449 | Link |
Registered User
Join Date: Dec 2011
Posts: 1,812
|
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. |
25th January 2012, 10:53 | #1450 | Link |
Registered User
Join Date: Mar 2003
Posts: 480
|
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 ). |
25th January 2012, 11:06 | #1451 | Link | |
Yes, I'm weird.
Join Date: May 2010
Location: Southeast Asia
Posts: 271
|
Quote:
|
|
25th January 2012, 18:57 | #1452 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
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") 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. |
26th January 2012, 00:47 | #1453 | Link | ||
Registered User
Join Date: Dec 2011
Posts: 1,812
|
Quote:
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:
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. |
||
26th January 2012, 01:22 | #1454 | Link |
Registered User
Join Date: Jun 2006
Posts: 452
|
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 :) |
26th January 2012, 03:17 | #1455 | Link | |
warpsharpened
Join Date: Feb 2007
Posts: 787
|
Quote:
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). |
|
29th January 2012, 06:49 | #1456 | Link |
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. |
29th January 2012, 19:46 | #1458 | Link |
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.
|
29th January 2012, 22:54 | #1459 | Link |
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. |
30th January 2012, 01:43 | #1460 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:
Quote:
I think you should open a bugreport with ffmpeg. |
|
|
|