black level offset in DebugMode frameserver?

john-beale wrote on 6/23/2006, 1:21 PM

When I export my video from Vegas 6d through the DebugMode Frameserver to an AVI for subsequent processing (eg. into VirtualDub) I have a black level offset (blacks become grey). I've confirmed this using the VirtualDub "levels" filter and looking at a sample frame histogram. The black level offset happens for both RGB24 and RGB32 output (the YUY2 option isn't read by VirtualDub). When I render the identical project out to a DV format AVI first, and then read that into Virtual Dub, the black level stays the same, no offset.

Is there any easy way to fix this, hopefully not involving adding a contrast filter to the entire project?

Comments

johnmeyer wrote on 6/23/2006, 1:53 PM

Yes, this is normal. It can be completely overcome by checking (or un-checking -- I can't remember) the "RGB 16:235" box in the encoder you use in VirtualDub. For instance, I use the MainConcept DV encoder (and also the MainConcept MPEG encoder) and I check this box.

john-beale wrote on 6/23/2006, 4:19 PM

Thanks for the reply! I'm going from Vegas (via Debugmode Frameserver) through Avisynth to the x264 encoder (MPEG-4). Probably x264 has a 16-235 level flag somewhere, but I can't find it. So I used the workaround below in my Avisynth script. I don't know if this is optimal, but it works for me.

--------
# Avisynth 2.5 script to read HDV 1080i and generate 720p for x264 encode
# by John Beale 6/23/2006

AVISource("H:\Edit-1080i.avi") # Vegas6 Debugmode Frameserver YUY2
ColorYUV(levels="TV->PC") # <-seems necessary to fix black level
TDeint() # deinterlace source, converting to progressive
BilinearResize(1280,720) # resize frame to 720p
ConvertToYV12() # format wanted by x264

johnmeyer wrote on 6/23/2006, 6:44 PM

Ah, if you are going through AVISynth, you can fix it there.

Play around with the Levels statement. Something like this:

Levels(16, 1, 235, 0, 255, coring=false)

NickHope wrote on 4/1/2008, 2:27 AM

Apparently...

ColorYUV(levels="TV->PC")

...and...

Levels(16, 1, 235, 0, 255, coring=false)

...do exactly the same thing.

I've got a similar issue. I can't find a 0:255 control for either Xvid or x264 codecs and I'm not even sure if i'm losing contrast or not because the files look different depending on which media player is playing them back. For example Quicktime shows less contrast than VLC.

I wanted to try comparing the output in Vegas but it won't read either the x264 H.264 file or the Xvid. I only get the audio on the timeline.

Do you think I need to apply that levels fix in Avisynth/VirtualDub for encoding to x264/Xvid?

johnmeyer wrote on 4/1/2008, 2:13 PM

Do you think I need to apply that levels fix in Avisynth/VirtualDub for encoding to x264/Xvid? I don't know.

I always do a test encode of 3-5 seconds and then put that back on the timeline, just to check the 0-255 issue, at least whenever I frameserve into something else. I then have to figure out where to fix the problem, if a problem exists. Generally, if you are going into an application, like VirtualDub, that requires RGB, I use the RGB24 option in Satish's Frameserver. However, AVISynth filters prefer YUV or YV12, etc., so I serve into AVISynth using the YUY2 option in Frameserver.

Then, I have to look at whatever is doing the final encoding. Sometimes I read the AVISynth script into VirtualDub and save using the MainConcept DV encoder. This has a 16:235 option. Often the problem can be solved by checking or unchecking this. The same thing is true when I use the MainConcept external MPEG-2 encoder.

So, the point is, you have to experiment, because there are so many different variations in workflow.

Within AVISynth, many of my scripts have these last two lines, which I include or exclude, depending on what works:



ConvertToRGB32(interlaced=false)          #Needed to get correct color when serving into MC.



#Levels(16, 1, 235, 0, 255, coring=false)

craftech wrote on 4/1/2008, 7:37 PM

John Beale,

Have you tried frameserving to Super (c) for x264? It works really well and produces nice results. It also works with AviSynth scripts and it's free. So far it's also the best flash encoder I have tried.
John

john-beale wrote on 4/1/2008, 10:12 PM

well, note that my posts in this thread are almost two years old! ...most recently I've just been using the built-in Vegas MPEG4 encoder with the 640x480 iPod preset, and that seems to work pretty well.

haven't heard about "Super (c)" but might have a look, thanks.

NickHope wrote on 4/1/2008, 10:13 PM

Thanks for the help.

John Meyer, yes I'd love to get the finished encodes on the Vegas timeline for comparison but unfortunately it won't accept Xvid or x264 so I've been eyeballing them in multiple copies of VLC Player. I can check Xvid against the original in a VirtualDub levels filter but unfortunately it won't open the x264 mp4 files, which is what I'm currently more interested in. I'm wondering what empirical method I could use (e.g. a levels histogram for the x264 file) to compare short of putting screen grabs in Photoshop.

If I frameserve in YUY2 the colorspace still needs to be converted to YV12 so I figured that frameserving in RGB24 gave the fewest conversions and hence least quality loss since (according to Satish himself) Vegas always gives data in RGB format. Makes sense?

My AviSynth script is currently looking like this:

AviSource("d:\fs.avi")

SeparateFields()

SelectEven()

ConvertToYV12()

ColorYUV(levels="TV->PC")

LanczosResize(960,540)

If I'm doing anything but 540 lines I use TDeint instead.

John (craftech), I don't know if John Beale is around. I dragged up his old thread. But I tried exactly what you suggest, frameserving to Super (c) for x264. Unfortunately it did not respect the bitrate I was giving it and made the files way too big. I wrestled with it for a long time. So I decided to go the route of more control. MeGUI (GUI for x264 etc.) makes things fairly easy and I'm liking it a lot.

johnmeyer wrote on 4/2/2008, 2:02 PM

I'd love to get the finished encodes on the Vegas timeline for comparison but unfortunately it won't accept Xvid or x264 ...

Yes, it can, but you have to change the fourcc code to DivX. You can either do this when you encode, or if you have already encoded, you can use "Nic's Fourcc Changer" which comes with Xvid. Open the AVI file, and change both settings to DivX.

I just tried all this, just to make sure. If I encoded to Xvid, Vegas (7.0d) wouldn't accept the video (just the audio). If I encoded using Xvid, but in Xvid's preferences (accessed through the "Configure" button in the Video tab of Vegas' Custom button on the Render As menu) under "Other Options" I changed the FourCC Used from Xvid to DivX. This imported just fine. Then, I used the FourCC Changer on the Xvid file I had previously created and that wouldn't import. After the header was patched with this utility, Vegas used it without any complaints or problems.

I have both Xvid and Divx installed on my computer (the free versions). I cannot remember now whether I had to have the free Divx software installed before all this would work, but if you can't get the results I describe above, then install the free Divx decoder (don't install their player and other junk).

NickHope wrote on 4/10/2008, 5:19 AM

Thanks John. I have also noticed that the Xvid files load onto the Vegas timeline OK if they have a fourcc code of DX50 set in the options of Xvid when they are encoded. DX50 is the fourcc that Divx has written into files since version 5.

Getting the x264 files to open on the timeline is more difficult. Sony AVC and MainConcept AVC open OK on the timeline but x264 don't. I don't know what the difference is as they are both AVC/AAC/mp4. The SonyAVC files have a problem in an online Flash Player though. They don't buffer properly. They have to load the whole 100% of the file first. I can get them to buffer properly if I remux them in Yamb, but then they no longer load onto the Vegas timeline! Grrr

Anyway I have now established that Xvid done via Framserver and VirtualDub retains the same luminance levels as the original HDV footage.

x264 done via AviSynth and MeGUI certainly seems to be paler than the original, even after applying a "16-235 to 0-255" fix in VirtualDub. I don't know why that is and I have a thread on Doom9 to try to get to the bottom of it.

I'm pushing along with this because I think that x264 looks better than the AVC options available in Vegas, notwithstanding the luminance issue.

Edit: I also established that going from Vegas > Frameserver > VirtualDub > Uncompressed AVI there is no change in luminance.

IMPORTANT EDIT: See my post at