View Single Post
Old 19th May 2003, 23:49   #3  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Q10: What's the deal with the "Upper Field First" option? I heard it has a bug?

The confusion about this option arises from that it works different from what you think. Naturally, you'd think that you set this option according to the field order of the video to be encoded, that is, deactivate it if source is bff (bottom field first) and activate it if source is tff (top field first). However, when you do this the encoded video plays back jerky with artifacts typical for incorrect field order.

So how do we set it right? First, you have to know that CCE (SP as well as Basic) always outputs video that is flagged "top field first" (there is a flag in the MPEG header that tells the player which field of the decoded frame to display first on a TV screen). There is no way in CCE to change this. According to Custom Technology, this is not a bug but a feature of CCE... Actually what happens if you check "Upper Field First" is that CCE assumes that source is bff and converts it to tff so it complies with the always set tff flag. It does so by shifting each frame up by one line, ensuring that the previously bottom fields are now top fields and the video is played back correctly. This is not the most sophisticated way to handle the situation, but it works and you won't notice the missing line at the top.

So here is the rule of thumb: Always uncheck "Upper Field First" unless your video is interlaced AND bottom field first. Progressive material is always top field first. To check whether your interlaced video is bottom field first, use the following AVISynth script:
Code:
#Use Mpeg2Source() for MPEG2 video
AVISource("E:\Video\holiday.avi")
AssumeBFF()
SeparateFields()
Now open this script in Windows Media Player. If all movements and horizontal pans look smooth, it's definitely bottom field first, but if you notice stuttery/jerkiness, it's top field first.

If for some reason you want to encode bff video without that line shift, there are two ways to do this:
  1. Frameserve bff video into CCE via AVISynth and convert it to tff "the right way". Here is a basic AVISynth script that does this:
    Code:
    AVISource("E:\Video\holiday.avi")
    DoubleWeave().SelectOdd()
    Uncheck "Upper Field First" in CCE and encode.
  2. Uncheck "Upper Field First" and encode bff video directly. Then use ReStream to clear the top field first flag in the MPV file CCE generated. Load the MPV into ReStream, uncheck "top field first" and click "Write!".


Q11: Where is the "Upper Field First" option in CCE-SP 2.67 and CCE-Basic?

In CCE-SP 2.67 and CCE-Basic, this option has been replaced by "Offset Line" (a text input control in Video Settings you can type a line number into). It works exactly like "Upper Field First" in that it tells CCE by how many lines to shift up the video.

Again here is the rule of thumb: Always set "Offset Line" to 0 unless your video is interlaced AND bottom field first in which case you set it to 1. Progressive material is always top field first.

While possible, it makes no sense to set this option to anything other than 0 and 1. I wonder why they are implementing it that way, now it's possibly even more confusing than before

Q11.1: Does CCE-SP 2.70 Support a true field dominance setting?

Funny you should ask. It sure does. It uses a "top_first" setting to allow changing the actual Top Field First flag. "top_first" set to 1 will set the Top Field First setting for all frames. "top_first" set to 0 will give you a Bottom Field First setting for all frames. CCE-SP 2.70 also still supports the "offset line" setting and works as before but you may want to leave it alone (ie always at 0) as not to confuse things with top_first.


Q12: How do I set the "Luminance Level" option correctly?

To make it short: it doesn't matter unless your video is in RGB format. I know some people will argue about that but I'll prove it below *).

MPEG1/2 (and that's what CCE encodes to) uses a color format called YCbCr which is vastly different from RGB. So CCE needs to convert RGB to YCbCr if the input clip uses RGB colors and does so by applying a conversion formula described in the CCE manual. The "Luminance Level" setting specifies a factor in this formula that controls whether the luminance range of the conversion complies with the ITU-R BT.601-5 standard (16-235, applicable for display on TV) or is more applicable for viewing on a computer screen (0-255). You decide what's best for your viewing application. But basically, if you want to retain the original luminance level of the RGB video, set it to 0-255 as 16-235 compresses down luminance.

So, how do you know if your video uses RGB colors? I know of only the two following scenarios where this can happen:
  • You are frame serving a DVD2AVI project into CCE via VFAPI. VFAPI always converts to RGB. And this is also the only time where the YUV -> RGB Scale setting in DVD2AVI matters. Because DVDs usually already comply to the ITU-R BT.601-5 (16-235) standard, you will want to use "PC Scale" in DVD2AVI and "0-255" in CCE in this case to avoid any luminance compression.
  • You are using the CCE Adobe Premiere plugin. Premiere feeds RGB video to the plugin and it depends on the DV codec used whether it performs any luminance scaling during the conversion. For instance, the Canopus DV codec has an option "Expand RGB range to 150%" for the YUV-RGB conversion which means luminance would be stretched to 0-255 during conversion. Again, you generally want to avoid any luminance scaling and set Luminance Level to 0-255 in the CCE plugin.
DVD2AVI projects frame served into CCE via AVISynth/mpeg2decX.dll do not use RGB but the YUV color space which is basically just another name for YCbCr. So no conversion takes place and you can ignore both the YUV -> RGB Scale setting in DVD2AVI and the Luminance Level setting in CCE.

*) Here is the proof: take any short clip you know is in YUV color format. For instance, the following short AVISynth script ensures you get a YUV colors clip:
Code:
ColorBars(720,480)
ConvertToYUY2
Trim(0, 299)
Now encode that clip in CCE into two different files, use "0-255" for the first and "16-235" for the second encode. Perform a binary comparison of both MPV files (use a command line fc /b clip0_255.mpv clip16_235.mpv). They will be identical.



Q13: Why does the manual say I should not set the timecode to 00:00:00:00?

The manual says that you should not do this because "00:00:00:00 has a special meaning to CCE-SP". I honestly do not know what that special meaning is and I never had any problem using the 00:00:00:00 time code.

The only time where you must not set it to 00:00:00:00 is when you are encoding hybrid NTSC material and want to utilize the inverse 3:2 pulldown feature in CCE-SP 2.66/2.67 and CCE-Basic ("3:2 Pulldown Detection" option). Apparently 3:2 pulldown detection does not work correctly when time code is set to 00:00:00:00, see this thread.


Q14: Questions related to frameserving video into CCE via AVISynth

AVISynth is a powerful frameserver that in conjunction with CCE is mostly used to feed MPEG2 video into CCE because CCE cannot natively decode MPEG streams. It's true power however is in the endless possibilities of preprocessing video, like cropping, resizing, trimming and applying filters. You can learn more about it at the AVISynth web site and in the AVISynth Usage Forum at Doom9. Doom9 also hosts a basic guide for setting up an AVISynth script that will serve your decrypted DVD VOBs into CCE for re-encoding.

You get the latest AVISynth version here. Note AVISynth 2.0x is no longer being developed, please use the currently released AVISynth 2.5.x version.

Last edited by Trahald; 1st August 2005 at 17:20.
RB is offline