The Otakon 2011 Thread

[Kireblue]

Gah I just realized I encoded at 29.97 when the source was 23...elementary mistake...

tisk tisk

[VicBond007]

Updated first post with the Big List of Bad Colorspaces, updated Iron Editor info, and updated Creator Badge info.

[Kireblue]

Updated first post with the Big List of Bad Colorspaces, updated Iron Editor info, and updated Creator Badge info.

It saddens me that I don't even know what most of the changes mean.

Converted levels from 32-215 to 16-235

[irriadin]

I don't know for certain either, but I'm guessing that a lot of people (including me) used a color profile that includes monitor levels of white and black not supported by the projection system.

[l33tmeatwad]

Updated first post with the Big List of Bad Colorspaces, updated Iron Editor info, and updated Creator Badge info.

It saddens me that I don't even know what most of the changes mean.

Converted levels from 32-215 to 16-235

http://en.wikipedia.org/wiki/YUV

[Davis 51]

Under The Box Productions Effects push levels out of spec, but original footage is in-spec. Left levels alone.

I assume that by "push levels" you mean the levels of the parts I had flashes/additive dissolves? Or is this something else entirely? I ask because this may/may not be something I need to avoid doing in the future.

[Brakus]

Good to know my entry didn't need tweaking. Still, it seems my video seemed a little strange-looking when I saw it played back at the pre-screenings 2 weeks ago. If that didn't cause it to not make the cut, the murmurs of "Why is this in action? It should be in comedy..." probably did....

The way Overflow has been scheduled, I might be able to see my video before I have to leave Baltimore on Sunday morning (unless by some miracle I get that day off from work).

Still, good luck to everybody!

[Scintilla]

This is why I added that gigantic-font update to my MPEG-2 encoding guide for conventions:

Edit, 7/21/10: Go to the "Quantize Matrix" tab, and UNCHECK the box for "Output YUV data as Basic YCbCr not CCIR601". This will ensure that your video never gets too bright or too dark for proper playback over the projector at the convention.

[VicBond007]

I don't know for certain either, but I'm guessing that a lot of people (including me) used a color profile that includes monitor levels of white and black not supported by the projection system.

Here's the quick and dirty version because going into this in depth requires my writing a FAQ with pictures and crap, and after all that work I'm still gonna get a bunch of fansub-sourced 10MB "720p" .wmv files

All TVs, from the old black and white tubes, to the 1080p plasma panels receive their TV signals in a format called YUV and that has to do with electrical signals and stuff. Your computer monitors output color in a signal space called RGB where pixels are lit up based up a 24-bit color code. There's no 100% perfect way to represent a YUV signal on an RGB device. It's like displaying a CMYK picture on an RGB device. You're only getting an approximation. Another way of saying it is that while you can capture and encode video off of a VHS tape, there's no way to get the actual magnetic information that's on the VHS tape, into your computer.

The way that RGB approximates a YUV signal places the color black at RGB 16.16.16 and the color white at RGB 235.235.235, with the rest of the shades spaced evenly in-between. This is in contrast to the actual RGB values for black (0.0.0) and white (255.255.255). If this 16-235 video is displayed, unfiltered on a 0-255 display, it makes the black look a little light, and the white look a little faded, and everything in between looks a bit washed out. All video signals intended for display on a TV (stuff on DVDs/ blu-rays, etc) SHOULD be stored within this 16-235 range. I say "should" because mpeg2 totally allows you to create a YUV video with a range of 0-255, and there's nothing stopping you from storing that on a DVD. I've seen it happen on "professional" discs before. Sony's also been pushing this concept of "hyper-white" which means that the level range is 16-255 instead of 16-235. It shouldn't exist and makes no sense. If your TV is calibrated to take advantage of hyper-white, then it will make the 99.99% of the other stuff out there look unnecessarily faded. If I tell my TV that signals coming in at 235 should be displayed at their whitest, there's no "whiter-than-white" after that! ANYWAYS...

Most of your editing programs work in RGB. Some support YUV partially, to some extent, but most of them rely on RGB since it's way faster for a computer to figure out how to decode and manipulate that signal, and it allows for WYSIWYG editing. There are two ways you can store your RGB video. The "best" way (my explanation, my opinion!) is to apply a filter on your video IN THE RIPPING PROCESS that transforms the level range from 16-235 to 0-255. This stretches all of the color values so that they display PROPERLY on your PC monitor. This also means that when you add effects, you won't be creating colors that are out of range of the video signal. The only caveat is at the end, when you encode your mpeg2 for cons that know what they're doing, you need to apply a second filter to that mpeg2 to bring the level range back down to 16-235.

The other way to store RGB video is called "normalized RGB" and this is where you take your 16-235 source and encode it so that 16=16, 235=235, basically leaving things untouched. The values 0-15 and 236-255 are still POSSIBLE to create since your video is stored in RGB, they're just "empty" at the moment. Storing normalized RGB eliminates any artifacts that could be introduced by converting color spaces (protip: nobody notices anyways) and reduces file size since you're storing fewer colors per frame, but when you add effects and even fades to the video, the footage then dips into those "unusable" color ranges. So why not apply the same filter as you would to any RGB 0-255 video? Well, if you do that, then your effects will be in spec, but all of your footage is now crunched down to a range of 32-215, meaning that even on TVs it will look faded and bland, and now that some original color information is gone, you'll never get it back.

So there you have it. if I had to convert your video from 0-255, chances are you were working in 0-255 RGB and didn't convert your levels down to 16-235 in your final render. OR, you were working in 16-235 normalized, and had "output YUV data as Basic YCbCr not CCIR601" checked in TMPGEnc (this button applies a 16-235 -> 0-255 filter to your video. It does NOT prevent 0-255 input from being encoded as a 0-255 output!). If I had to expand your video from 32-215, then you were probably working normalized, or even in YUV, but you exported RGB at some point and the video encoder that you used to make your final encode decided "hey, this is RGB video. This guy probably doesn't realize that in order to play this on a TV that the levels should be more compressed. I'm gonna be a good program and fix it automatically! Man I'm awesome!"

The bottom line is that everyone's entry is going to look as good as possible when we play it back in 2 weeks.

[Davis 51]

Ah, that makes sense and kinda answers my question. I feel a little bad, as all it would have taken would be a checkbox to fix things on my end.

Would it be worth it for me to re-encode it myself from the masters with corrected levels and send it to you or is it really unnoticeable?