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 Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th November 2010, 22:09   #1  |  Link
AlekseiV
Registered User
 
Join Date: Jan 2010
Posts: 92
Making FRAPS video from FFMS2 match AviSource?

FRAPS video is usually YV12. Their VFW codec stores it as YV12, but decodes it to RGB.
FFVideoSource decodes it to fullrange YV12. The problem is that it doesn't look the same as what AVISource (FRAPS) decodes.

Example:
FRAPS clip, AVISource
FRAPS clip, FFVideoSource
I also included histograms of the levels.

How do I round/shrink FFMS' levels so that they match the levels of AVISource?
AlekseiV is offline   Reply With Quote
Old 17th November 2010, 22:18   #2  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
you can try:

smoothlevels(preset="pc2tv")


you may have to adjust the settings a bit to make it match, and maybe colormatrix as well (I can't tell , because it's RGB screenshot and it's not clear what you did to take the screenshot (how you converted to RGB))

smoothlevels(preset="pc2tv", chroma=100)
colormatrix(mode="rec.709->rec.601" , clamp=0)


FRAPS has a RGB mode as well, RGB Lossless , so it depends what version you are using

Last edited by poisondeathray; 17th November 2010 at 22:31.
poisondeathray is offline   Reply With Quote
Old 17th November 2010, 22:28   #3  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
AVIsource is wrong, FFMS is correct. AVIsource is converting the PC-level FRAPS source to TV-level.
Dark Shikari is offline   Reply With Quote
Old 17th November 2010, 22:28   #4  |  Link
AlekseiV
Registered User
 
Join Date: Jan 2010
Posts: 92
It is closer but unfortunately still noticeably different:
FRAPS, FFVideoSource.smoothlevels(preset="pc2tv")

edit: hold on, testing something
AlekseiV is offline   Reply With Quote
Old 17th November 2010, 22:34   #5  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Note: It depends HOW you are taking screenshots , because the YUV data is converted to RGB for the screenshot (or display)

ie. If you converted to RGB using pc vs. tv levels, what matrix (BT 709 vs. 601 etc..)

If you use Lossless FRAPS, there is no confusion, because RGB is decoded as RGB, no levels issues
poisondeathray is offline   Reply With Quote
Old 17th November 2010, 22:45   #6  |  Link
AlekseiV
Registered User
 
Join Date: Jan 2010
Posts: 92
Using Lossless RGB mode in FRAPS makes FRAPS even slower due to the higher bitrate, and the quality difference is not noticeable.

AVISource is not wrong. Example:
Screenshot (taken using built-in screenshot utility; a SS from FRAPS looks identical)
AVISource, still image from video clip recorded at same approx time
FFVideoSource, same as above

The screenshot and AVISource are nearly identical; FFVideoSource looks utterly different. Unless the game's screenshot utility is converting PC levels to TV levels, AVISource is correct.

I am taking screenshots from the videos using AvsPmod's "Save Image". They are PNG which I then convert to JPG with 4:4:4 chroma.
AlekseiV is offline   Reply With Quote
Old 17th November 2010, 22:48   #7  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
I am taking screenshots from the videos using AvsPmod's "Save Image".
But when you save image , it uses rec.601 conversion (ie. you are converting the yuv data to rgb using rec.601 - you're not VIEWING the YUV data as YUV)

Try this:

ffvideosource()
converttorgb(matrix="pc.709")

and then examine the screenshot
poisondeathray is offline   Reply With Quote
Old 17th November 2010, 22:55   #8  |  Link
AlekseiV
Registered User
 
Join Date: Jan 2010
Posts: 92
The images I am using are correct.
Seriously, I was just in the game comparing how the game looks while I'm playing it to how FFVideoSource looks, and FFVideoSource looks wrong. But see below.

Quote:
Originally Posted by poisondeathray View Post
But when you save image , it uses rec.601 conversion (ie. you are converting the yuv data to rgb using rec.601 - you're not VIEWING the YUV data as YUV)

Try this:

ffvideosource()
converttorgb(matrix="pc.709")

and then examine the screenshot

Perfect, this solves the thread title.
Code:
FFVideoSource(file)
ConvertToRGB(matrix="pc.709")
ConvertToYV12()
Also it turns out using x264 --fullrange on will make the video decode properly in MPC-HC, but I don't know whether it works properly on the various video site backends. Also, this is easier to recommend than setting fullrange on.
AlekseiV is offline   Reply With Quote
Old 17th November 2010, 23:02   #9  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by AlekseiV View Post
Also it turns out using x264 --fullrange on will make the video decode properly in MPC-HC, but I don't know whether it works properly on the various video site backends. Also, this is easier to recommend than setting fullrange on.
Then this makes it obvious what's going on.

What you WERE doing:

AVIsource: Input -> PC->TV Conversion -> Encode -> Decode -> TV->PC conversion -> Display (Correct, but wasteful and hurts quality)

FFMS2: Input -> Encode -> Decode -> TV->PC conversion -> Display (WROOOOOOOONG)

What you are now doing:

FFMS2: Input -> Encode -> Decode -> Display (Optimal!)

Now, what we probably should do is make x264 automatically trigger --fullrange if it knows that the input is fullrange. I'll yell at TheFluff to do this. Thanks for the bug report.

Last edited by Dark Shikari; 17th November 2010 at 23:08.
Dark Shikari is offline   Reply With Quote
Old 17th November 2010, 23:28   #10  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,210
Quote:
Originally Posted by Dark Shikari View Post
Then this makes it obvious what's going on.

What you WERE doing:

AVIsource: Input -> PC->TV Conversion -> Encode -> Decode -> TV->PC conversion -> Display (Correct, but wasteful and hurts quality)

FFMS2: Input -> Encode -> Decode -> TV->PC conversion -> Display (WROOOOOOOONG)

What you are now doing:

FFMS2: Input -> Encode -> Decode -> Display (Optimal!)

Now, what we probably should do is make x264 automatically trigger --fullrange if it knows that the input is fullrange. I'll yell at TheFluff to do this. Thanks for the bug report.
bingo
dansrfe is offline   Reply With Quote
Old 17th November 2010, 22:47   #11  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Stop willy-nilly converting your screenshots around without considering luma levels! Converting to JPEG can change the levels! Converting to RGB also can change the levels! Going through a video renderer and saving a screenshot (e.g. using AvsPmod's Save Image) can change the levels!

My original statement was just based on your original graphs. Those graphs demonstrate that the data being used to create the graphs shows that AVIsource must be wrong. It's quite possible, of course, that the image is being mangled on the way to creating the graphs, and that AVISource is in fact correct.

For example, here's what might be happening:

AVISource: Original -> (PC->TV conversion) -> Create Graph -> (PC->TV conversion)
FFMS2: Original -> Create Graph -> (PC->TV conversion)

Last edited by Dark Shikari; 17th November 2010 at 22:52.
Dark Shikari is offline   Reply With Quote
Old 17th November 2010, 22:58   #12  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
LOL, don't just convert to RGB then back to YV12 - each conversion is LOSSY . Look at the red borders, they will get blurrier from each colorspace conversion. That example was just to show the proper RGB conversion for taking screenshots (AVSP assumes REC.601 for the RGB conversion otherwise)

You should use the suggestion above, this way you have 1 less colorspace conversion

smoothlevels(preset="pc2tv", chroma=100)
colormatrix(mode="rec.709->rec.601", clamp=0)

Essentially what you are doing is scaling 0-255 to 16-235 Y' then converting to REC.601 - this is not ideal, but a workaround for decoders that expect a TV range video (In avisynth, when you use ConvertToYV12() it means ConvertToYV12(matrix="rec.601") )

FRAPS is supposed to be full range, and decoded full range (converted to RGB full range) - When you compress Y' from 0-255 to 16-235 you get induce quantization (banding) ie. lower quality because there is fewer "steps" to express values

Last edited by poisondeathray; 17th November 2010 at 23:03.
poisondeathray is offline   Reply With Quote
Old 17th November 2010, 23:21   #13  |  Link
AlekseiV
Registered User
 
Join Date: Jan 2010
Posts: 92
Quote:
Originally Posted by poisondeathray View Post
LOL, don't just convert to RGB then back to YV12 - each conversion is LOSSY . Look at the red borders, they will get blurrier from each colorspace conversion. That example was just to show the proper RGB conversion for taking screenshots (AVSP assumes REC.601 for the RGB conversion otherwise)

You should use the suggestion above, this way you have 1 less colorspace conversion

smoothlevels(preset="pc2tv", chroma=100)
colormatrix(mode="rec.709->rec.601", clamp=0)
I cannot see a difference in quality between the YV12->RGB->YV12 method and the proper SmoothLevels.ColorMatrix method. I know it exists (and Subtract can show it), but I can't see it, even flipping back and forth between them in comparison. But I can notice a difference in speed; SmoothLevels.ColorMatrix halves my playback speed. Encode speed is only ~15% slower, but it still hurts.



Autosetting of fullrange would be really useful, thanks!
AlekseiV is offline   Reply With Quote
Old 17th November 2010, 23:28   #14  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by AlekseiV View Post
I cannot see a difference in quality between the YV12->RGB->YV12 method and the proper SmoothLevels.ColorMatrix method. I know it exists (and Subtract can show it), but I can't see it, even flipping back and forth between them in comparison. But I can notice a difference in speed; SmoothLevels.ColorMatrix halves my playback speed. Encode speed is only ~15% slower, but it still hurts.
It's up to you, but colorspace conversion are lossy

You can use levels or coloryuv, instead of smoothlevels and it should be faster

coloryuv(levels="PC->TV")

But smoothlevels does more than just change the levels, it dithers (have a look at the encoded YV12 video in a dark gradient area like shadows, you should see more banding in the video adjusted by levels or coloryuv, but it may or may not be noticable )
poisondeathray is offline   Reply With Quote
Old 17th November 2010, 23:34   #15  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by AlekseiV View Post
I cannot see a difference in quality between the YV12->RGB->YV12 method and the proper SmoothLevels.ColorMatrix method.
Have a look more closely, it's most noticable around red colors

You don't see the blurring ?

http://www.mediafire.com/?t279cf2oa6akg5o
poisondeathray is offline   Reply With Quote
Old 17th November 2010, 23:21   #16  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
^ yes ideally that's what you would do (do everything fullrange) . The problem is decoders and displays might not expect fullrange video or accept VUI information in the h.264 stream, and it will end up looking like the 1st ffvideosource screenshot .

That screenshot is 0-255 YUV data improperly converted to RGB 16-235 using Rec.601 (because he used AVSP to take screenshots without ConvertToRGB(matrix="PC.709") . Using ConvertToRGB(matrix="PC.709") emulates what the YUV data should look like when a decoder/display correctly decodes the fullrange video

Scaling it to "TV" levels is the (dumb) workaround for now, but it ensures consistency on every device and display
poisondeathray is offline   Reply With Quote
Old 18th November 2010, 00:04   #17  |  Link
AlekseiV
Registered User
 
Join Date: Jan 2010
Posts: 92
I can see the blurring in your sample, yes. I couldn't see it in mine (even looking at an area Subtract marked out).
I don't know if the quality difference is particularly noticeable after the video has gone through YouTube's encode process.
AlekseiV is offline   Reply With Quote
Old 18th November 2010, 00:16   #18  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Again, it's up to you , and (more) blurry might be better for compression since Youtube brutalizes everything

Youtube converts to RGB for display using Rec.709 (even SD video which should be Rec.601) regardless of flags or format uploaded, so you have to scale to TV levels anyways if it's for Youtube - fullrange isn't an option here
poisondeathray is offline   Reply With Quote
Reply

Tags
avisource, ffms, ffvideosource, fraps, levels

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 16:42.


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