|
|
| Dowlphin |
 Posted: Apr 9 2014, 01:07 PM |
 |
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
There's that whole "Color Depth" menu in VDub where I can select color space for the input as well as for display+output, but it seems to have no effect.
What I wanted to do:
Open a YV12 video and work with it (mainly extracting frame captures that are not to be used in other video material) like it looks when played in, say, MPC-HC - with TV-like colors. They should look somewhat gentler and not so harsh.
What happens:
Colors are always very harsh, not the way the end result should be for the viewer.
My current workaround:
Opening it via ffdshow+AVISynth script that does a conversion to RGB. Now the video will indeed have the proper colors as intended for output, but some borders look pixelated. I quickly figured out that I needed to to an additional step to regain the natural smoothness of the original material: I had to select (and make default for convenience) YV12 as input colorspace. Yes, that smoothed the edges without changing colors. I don't quite understand why it behaves this way; this area gets a little confusing for me.
It would all be a lot easier if I actually could have the input be like that without the workaround using AVISynth. But selecting RGB als input colorspace in VDub does nothing. The only thing that showed a change was selecting extremes like luma-only or greyscale on the input side.
Does it have anything to do with Rec.601? I tried the additional options and selected Rec.709, but that made VDub crash. The video IS 709 though.
The alternative would be some kind of photoshop plugin that can do video color space conversion as an image filter (if possible), but I couldn't find anything like that. |
|
| raffriff42 |
| Posted: Apr 9 2014, 01:46 PM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
If your source is Rec.709, but not flagged as such (for example by opening with the FFmpeg input driver, or by using the Convert format filter) preview will be wrong (green over-saturated, red under-saturated), since VirtualDub assumes YUV sources are Rec.601 by default. I use Alias format (color space=Rec.709, range=no change) for previewing (only) in that situation.
If your video is full range (0-255) YUV, again, you need Convert format or Alias format, or the highlights & lowlights will be blown out. |
|
| Dowlphin |
| Posted: Apr 9 2014, 03:22 PM |
|
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
Hmm, I guess my MKVs are opened with the ffd driver. (In case VDub can't open AVC+AAC in MKV). But the file info dialogue correctly states (as also repoeted by MediaInfo): yuv420p (709).
I'm a bit overwhelmed with the information you provided. If I need to use AVISynth scripting, I already kind of have the solution I think, at least for my frame capture purposes. And I am quite sure that what I get there is how it's supposed to look on TV because before I enabled RGB conversion in my MPC-HC (or setting some affected values correctly), there was no true black in (certain?many?all?) videos. It was too bright. The RGB conversion corrected that.
Could you clarify the Convert format and Alias format thingies please? Are they AVISynth plugins? If not, how do I use them?
EDIT: Nvm, found them in the filter list. I'm discovering so much new stuff about VDub!  |
|
| dloneranger |
| Posted: Apr 9 2014, 03:39 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
There are two standards for the levels in video
RGB
YUV
RGB uses 0-255 for black to white (full range)
YUV uses 16-235 for black to white (limited range)
0-15 are super-black and 236-255 super-white
These are the 'real' black and white - the kind you get for letterboxed movies, where even if you turn the brightness all the way up they're still black but the black in the movie has gone grey
Sigh.... apart from the other YUV movies that use 0-255 (full range)
And that's where the hassle comes in, because so many video's don't have information in them that says 'this video is using full range' (or limited)
When you do a yuv->rgb conversion you have to know if the movie is full or limited range
Then the conversion can scale the values up/down as needed
(Most players assume limited unless the video is flagged as full range)
Remember though that if you've converted them they might look washed out when played back on a tv if it assumes they're normal limited range YUV
The easiest way is to...
Set virtualdub to load in YUV
Load your video
Add an alias filter
Use that to swap between limited and full range
->tip, in the filters dialog tick the show formats checkbox so you can see what's going on
If you need to use avisynth, somethings going horribly wrong somewhere.......
When encoding some codecs (esp. external ones) will let you specify if the source video is 601/709, limited/fullrange
Really you should always set this if possible, as this puts the information into the video stream, so the player can correct the scaling as needed
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| Dowlphin |
| Posted: Apr 9 2014, 04:14 PM |
|
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
Cool, now I can use the other formats (including full range) as input in VDub, and those are the ones I was looking for. Maybe the crash issue was fixed by using a newer ffdshow input plugin.
Now when I open the video (yuv420p full HD BT.709) as such, assuming full range, leave it at that, and try to encode it, I get a message saying the selected output format isn't compatible with the Windows video codec API. Is this good? Is it, as a side effect, preventing me from encoding in a colorspace that would not be compatible with TV? Or do modern TV support full range without a hassle?
Which colorspace does the Windows API not support then? Full range? So I can open it in VDub as full range, but not save it as that.
Waaaah - confused. 
OK, different approach: What do I have to do to find out which colorspace a video file is, assuming it is tagged properly? MediaInfo tells me YUY 4:2:0 8 bit progressive BT.709, but nothing about colorspace. All I know is that if I open it as full range, the colors look a bit more 'pastel', but black is still black, while if I open it as limited, the colors are quite harsh. (It's a comic style video, so it's easy to determine.)
If I did a wrong colorspace conversion, one step too much, the black would start becoming gray, right? |
|
| dloneranger |
| Posted: Apr 9 2014, 04:26 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
| QUOTE | | selected output format isn't compatible with the Windows video codec API |
Hmmm, not sure where that message is coming from...... never seen that one
What's selected in your color depth output options (I normally have 'same as decompression format')?
Colorspace is the 601/709
Range is the limited/full
SD normally uses limited range, and a lot of HD tends to use full range from what I've seen
The only real way (if the video isn't flagged) is to do it by eye
Or a plugin like MultiAdjust that can overlay out of range areas - lots of grey blocks all over the picture means full range
TV's should support properly flagged video - ones that don't may have an option in its settings, and even older ones may just assume limited range
(and those can look truly horrible if fed full range video, with solid black blocks in dark hair etc)
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| Dowlphin |
| Posted: Apr 9 2014, 04:40 PM |
|
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
Output selected is same as input, input as I said assumes BT.709 full. Then I open MultiAdjust. When input and output levels 16-239 are both ticked, there's slightly exceeding range on blacks. I untick input (=full) and they disappear, but the picture gets hazier. I untick the output (=full) and the colors get vibrant again; identical to what VDub shows in the previews. If I only tick limited input, all blacks and whites are completely out of range. I get the same results whether I open the video with VDub input set to full or to limited.
If the video had a tag about whether it's full or limited, would the ffdshow plugin auto-detect that? Because while it does have an effect if I set the input to full in VDub, if I tell the input plugin to auto-detect (which doesn't mention color space though), it has no such effect.
Should VDub be able to auto-detect limited/full? |
|
| dloneranger |
| Posted: Apr 9 2014, 05:17 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
No you can't really autodetect the range or colorspace, you have to rely on the video being correctly flagged
To the pc it's just numbers, it's only a case of how the numbers are interpreted
eg it doesn't know if 64 means bright orange or slightly duller orange - you have to look at it and make your best guess
If multiadjust has in/out ticked and shows large blocks of greyed out areas on a normal frame, then it's probably full range
Small speckles scattered about are just rounding errors from encoding
Basically all it's doing is highlighting anything <16 or >235 when the in/out are set to 16-235
eg
 fullrange
 limited
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| raffriff42 |
| Posted: Apr 9 2014, 05:57 PM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
Agree w/ dloneranger on all he said, of course.
I wish this business was easier to explain!!
Anyway,
1. Color Depth: input should be Autoselect (the default)
2. When opening a video, get its color format as vdub sees it. This may not be the recorded color format,as decoders (FFmpeg input driver excepted) often default to RGB.
Select Full processing mode, open the Filters dialog and check Show image formats. Add a Null transform filter at the top of the chain. When you enable (tick the checkbox on) this filter, you will see the incoming color format: RGB32, YV12, etc.
3. From this point, you add Alias format and/or Convert filters to get the image looking as it should (and to get a format the compressor likes)
Can you post some screen shots, showing good and bad versions of the same scene? We will advise you from there.
If you are coming from Avisynth anyway, add a few seconds of ColorBars() at the head or tail. This way you can check each stage of your workflow.
|
|
| Dowlphin |
| Posted: Apr 9 2014, 06:14 PM |
|
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
I'd probably need a graphic or something to get this into my head.
I now checked between VDub and MPC-HC (which uses ffdshow) and they seem to match. I set in ffdshow "full range" and "display on computer monitor" and I still get greyish blacks. I switch to limited range and I get perfect black. (If I select TV, it gets brighter in addition to the other setting's effect.)
So both full and limited are saved in the file as values from 0-255. If I say it is limited range, then the interpreter would assume that 16 is already meant to be perfect black and 0-15 is super-black? OK, I understand that now. A limted range file would contain values from 0-255 just like a full range file, just that ~0-16 and 236-255 don't actually have any valuable meaning, no picture-information. And is this format required for older (analog?) devices because they treat color differently? Because if it wasn't so, one could just encode a limited range file without ever using those fringe values, right? Then it would be clear to a program that it's limited range.
Still got a problem: MPC-HC (ffdshow) colors still look better even if I set it to limited range, while blacks are perfect. If I do this in VDub, the blacks are perfect, but the colors become extreme.
If it helps you understand what's going on with my system, I can make some screenshots with annotations. |
|
| dloneranger |
| Posted: Apr 9 2014, 06:49 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
| QUOTE | | Still got a problem: MPC-HC (ffdshow) colors still look better even if I set it to limited range, while blacks are perfect. If I do this in VDub, the blacks are perfect, but the colors become extreme |
This might be to do with your graphics card
In mpc there are a few renderers to choose from
In virtualdub, there are three gdi, directx, direct3d
Some of these can have their output modified by the graphics driver - some have movie settings, some have directx settings etc etc
I usually untick all the directx stuff in virtualdub so I get an unadulterated output
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| Dowlphin |
| Posted: Apr 9 2014, 07:18 PM |
|
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
I have all driver optimizations for video playback disabled anyway. It's all left to the player app.
But I got it now. I got confused and had VDub compare the 709 full range to 601 limited range.
What happens is that either VDub's auto-select doesn't recognize the video's Rec.709 despite it being stated in the header and instead thinks it's Rec.601, or the autoselect function is limited to the range of formats in the main window and doesn't access the list of additional formats. Which kinda makes the autoselect inflexible if I'm working on different types of videos.
The problem is now that again I get the error message about incompatible format. Could it be that the formats in the additional list are not supported by AVI? Because 601 full as well as 709 limited and full throw that error, regardless of the output codec. (I tried x264vfw, XviD and Lagarith.) Rec.601 limited is the only 4:2:0 combination that works. And that might be conntected to why VDub doesn't properly detect the video's format.
UPDATE!:
I now did NOT tell it to use the same output as input, but set the output fixed to the regular 4:2:0 YUV there, which is Rec.601 limited, and NOW it autoselects the proper input as Rec.709 limited.
This is good for my frame extraction purposes now. It would not enable me to save the file in the proper color space though - not as long as the output container is AVI. I guess I'd have to use an external video encoder with VDub then? Would VDub write a containerless raw video stream in that case? Or would that pose a problem of missing header information?
If I want to reencode videos like said one without changing how it is displayed, I have to select Rec.601 limited for input and output.
I ran some tests to see how much the original/intended color is preserved after a Youtube upload. Youtube interprets the format not as my player, but like VDub opens it. So for Youtube, I get proper results by opening my Rec.709 video as Rec.709 and encoding it as Rec.601. No idea what would happen if I encoded it with the proper Rec.709 since, as I mentioned... incompatible. |
|
| raffriff42 |
| Posted: Apr 9 2014, 08:08 PM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
| QUOTE (Dowlphin @ Apr 9 2014, 07:18 PM) | | Youtube interprets the format not as my player, but like VDub opens it. |
For me, I get the most accurate prediction of my file's future appearance on YouTube (and I have tested with a variety of codecs & settings) by viewing it with MPC-HC, with Options, Playback, Output, Directshow Video = Haali Video Renderer, and Haali colorspace=auto, Luma range=TV (the default settings, I think) |
|
| Dowlphin |
| Posted: Apr 9 2014, 08:41 PM |
|
|
Member
Group: Members
Posts: 23
Member No.: 37864
Joined: 9-April 14
|
Does it look the same way in the player as it looks when opened in VDub?
Well, so many factors involved and all are relative to each other. As long as you have a reliable reference, there's your verification that your rendering methods at least yield the proper result, regardless of what means were used.
It helped me that I do have a color reference for my videos, so I know how they're supposed to look. (I was uncertain at first, but now it makes sense.) |
|
| raffriff42 |
| Posted: Apr 9 2014, 11:12 PM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
>Does it look the same way in the player as it looks when opened in VDub?
Not always, because Virtual shows YUV as if it is Rec.601, limited-range by default. |
|
|
