Hi, I'm a pal guy as well. I have good knowledge about video. Not so much about codec's. But Mikey list gives all the info. THX a lot mike.

The original question was what the option "use dv codec" does for quicktime reference. And I still have a few questions.

Am I correct that this option sets a "flag" in the exported file so the program that imports this file knows what kind of stream it is dealing with. i.e. which aspect ratio, a 720x486 or 720x480.

It also changes the codec from apple dv to avid dv. But is there a difference between the 2?

I could measure with a WFM monitor what is going on, IF i lived in a NTSC country and had a NTSC WFM under the assumption that an mojo, mojo sdi, or adrenaline DNA show all lines and don't blank anything. Isn't it possible for somebody to make a graphic with (colored) lines to see which lines are actually added, dropped or if the picture is stretched...

MikeyB:

Well, as I say, I'm a PAL guy but my understanding is that the codec pads the image out with 4 lines of black at the top and 2 at the bottom.  

I just did some tests and this is correct when using the "Avid DV codec" option -- 4 black lines on top and 2 on the bottom.  When UNchecking the "Avid DV codec" box, the resulting QTRef does not have these extra lines.

As for your CCE encoder, what does it do with real 720x486 pixel NTSC?

That's what I'm going to try to determine with my next tests, but it gets a bit confusing with all the import and export steps, and all the options at each step.  Cinema Craft got back to me, but their response to this question didn't answer it.

And why would it do anything different with Avid DV?  I think you're probably worrying unnecessarily.

I'm not sure what you're asking here.  When you say "with Avid DV," do you mean with the "Avid DV codec" option?  If so, there are clear differences with the resulting QTRef files generated with vs without this option, which will translate to differences in the encoded files.  I really don't think this is "unnecessary" worrying given that my tests demonstrate visible differences.  I just need to figure out how all the differences combine with each other, and what settings to use for the best result.

Larry

Some more info on this:

I "think" that the way it works in CCE is that you use the "offset line" control to crop the top 4 lines in a 486 line movie.  By setting the "offset" to "4" in the advanced CCE settings, it crops the top 4 lines that were added by Avid during the creation of the QTRef (with the "Use Avid DV codec" setting), then uses the next 480 lines and crops the last 2, which were also added during the Avid export.

If you do NOT use the "Avid DV codec" option, the output is already 480 lines, so you'd use a "0" line offset in CCE and use the entire 480 lines as they are.

I think that the reason the effects of this situation aren't more widely known is simply because the top 4 and bottom 2 lines are usually cut off by overscan on normal TVs and not seen.  In other words, the difference that these settings make is usually hidden.  I'm just trying to "do it right" here, and I'm also taking into consideration that when viewing on a computer monitor, there is often no overscan.

Larry

That was what I was trying to say - you should set the CCE encoder up the same way for Avid DV codec QT Ref as you would for standard NTSC.  Glad you got it sorted!

MikeyB:

That was what I was trying to say - you should set the CCE encoder up the same way for Avid DV codec QT Ref as you would for standard NTSC.  Glad you got it sorted!

The problem was that I had never set up CCE for standard ntsc (486 line) -- I had always output dv resolution from Avid before, so it has always been 480 lines to start with, and I've therefore never had to deal with the "offset line" setting.

The CCE instructions are also rather vague on this.  They do talk about the setting in general, but they never specifically refer to 486 vs 480 line material, so if you've never dealt with this before it's not overtly clear that this is how you deal with 486 to 480 line conversion.  In other words, nothing in the manual says that if you don't change this setting, you'll lose the last 6 lines in a 486 line source, which I "think" is how it works.

I still have to test this to confirm that all this is correct.

Note also that through all this, I'm STILL not clear about the implications of the fact that when you don't check "use Avid DV codec," the QT player plays the files with an RGB luminance range.  I'm therefore still not clear about whether or not to use the "Avid DV codec" when creating QTRef files, which is one of the fundamental questions of this thread.

Thanks again for all the feedback here,

Larry

lalittle:

I've therefore never had to deal with the "offset line" setting.

Okay, so here's a question that's not quite as easy to test:

It has already been established that when NOT checking the "Use Avid DV codec" box and outputting a QTRef with the 601 option (16-235), the resulting file plays in the QT player with RGB luminance range (0-255.)  Is it just the QT player that is converting the luminance range for playback?

My theory on what's happening is this:  According to Avid, when you don't select "Use Avid DV codec," Avid uses the "Apple DV codec" instead.  I'm wondering if Apple designed their QT player to assume that when you play a file with their Apple DV codec on a computer monitor, you would WANT to view it with the range converted to RGB since this is needed for it to look "correct."  If the file is viewed with it's native 16-235 range, the blacks will look a bit washed out and the white won't be as bright, so perhaps the QT player is trying to be "smart" when it sees this codec and display the video as it assumes you "want" to see rather than displaying the "actual" range.

In other words, maybe apple designed the QT player and the Apple DV codec to have this special behavior.

Does anyone have any idea if this might be correct?

Thanks,

Larry

AndrewAction:

lalittle:

I've therefore never had to deal with the "offset line" setting.

Have no access to CCE at present but from memory I am almost 100% certain that the offset line setting changes the field order and has nothing to do with 480 or 486 lines.

It does EFFECT the field order, and is used in conjunction with the "Output top field first stream" box.  The manual says this:

This parameter specifies offset lines from which encoding starts.  When the output is MPEG-2 video, it affects on field order.

and

If the field order is same between the source and the output,
Offset line should be 0 or even number.

If the field order is different between the source and the
output, Offset line should be 1 or odd number.

An email I got from Cinema Craft explains further:

By selecting offset line in "Advance video setting",
you can choose how many lines are cropped from the top.
For example.  if you set 0, no line is cropped and encoding starts
from the top.

Since the manual never talks about "cropping," it isn't really clear about this, but the email from Cinema Craft is much more straightforward on this point.

Larry

lalittle:

Does anyone have any idea

I dont think they have been on the same page very often for a number of years.  My gut feeling is that it's Apple who keep changing QT (from my PAL users perspective) causing thr problems.

Every time I change the version of QT on an Avid CPU I automatically retest all my MPEG templates in all different encoders to check for field order irregularities. A Regal PIA. Maybe we should all change to Strobe City (progressive) and cure the problem that way.

FWIW in PAL checking or not checking the source input video is 16 to 235 box makes no difference in the MPEG 2 file out of Sorenson here.

The Avid and Apple DV codecs are different. This is a good explanation of the differences:

http://www.adamwilt.com/24p/index.html#CodecDifferences

AndrewAction:

lalittle:

Does anyone have any idea

I dont think so. Especially Apple or Avid. 

I dont think they have been on the same page very often for a number of years.  My gut feeling is that it's Apple who keep changing QT (from my PAL users perspective) causing thr problems.

I'm not sure I follow what you're saying here.  What I'm wondering is if apple designed their player (QuickTime) to work with their codec (Apple DV) in certain specific ways.  This would explain some of the behavior we're seeing.

Every time I change the version of QT on an Avid CPU I automatically retest all my MPEG templates in all different encoders to check for field order irregularities. A Regal PIA.

My experiences are similar.  When QT changes, it seems to cause a lot of unexpected repercussions.

FWIW in PAL checking or not checking the source input video is 16 to 235 box makes no difference in the MPEG 2 file out of Sorenson here.

I'm wondering if Sorenson is checking some flag and making the appropriate adjustments automatically.  In other words, it "sees" whether the source is 16-235 or 0-255 and automatically outputs to 16-235 in either case.

Thanks again,

Larry

BobRusso:

The Avid and Apple DV codecs are different. This is a good explanation of the differences:

http://www.adamwilt.com/24p/index.html#CodecDifferences

Based on what it says about the gamma curves on that site, it sounds like not checking "Use Avid DV code" might effect the gamma of the end result in ways that might not be readily apparent.

At this point it sounds like the best thing to do is to use the Avid DV codec option, then have the encoder crop the top 4 lines.  It sounds like if you don't crop the top 4 lines, you'll lose the last 4 lines instead.  This would probably not be noticeable most of the time, but with certain program material it could be visible when viewed on a computer monitor.

Thanks,

Larry

lalittle:

At this point it sounds like the best thing to do is to use the Avid DV codec option, then have the encoder crop the top 4 lines.  It sounds like if you don't crop the top 4 lines, you'll lose the last 4 lines instead.

I'm finding it rather difficult to accurately test this.  I created a 480 line black image with the top and bottom 5 lines different colors.  I imported this into Avid as a 5 second clip in order to track what happens to the top and bottom lines throughout the process.  Everything works fine up through the creation of the QTRef, but when I encode the file, the colored lines get "smeared" together, making it difficult to tell exactly what happened during the encoding process.  It appears that the encoder cannot keep the single line detail during the encoding process.  I don't know if this is due to the way I'm viewing the material (via software DVD player), or to the file itself.

As far as I can tell, however, it "appears" that the theory holds -- i.e. that by setting the CCE "offset line" to "4," the top 4 lines (and the bottom 2 lines) get cropped.  With the loss of full detail, however, it's not conclusive.

Larry

lalittle:

I created a 480 line black image with the top and bottom 5 lines different colors.

AndrewAction:

lalittle:

I created a 480 line black image with the top and bottom 5 lines different colors.

Maybe try using 3 colours each displayed on two adjacent lines.  If that still has problems then leave the top line black and then use 3 colours the same as before.   (remove possible interlace from the equation?)

I'll give those a try.  Is this just a limitation of encoding?  Do encoders simply not try to resolve single-line detail?  I would have thought that the end result would look pretty much identical to the original with this test image.  I tried Procoder 3 and saw similar smearing.

Regarding the interlacing, I'll try the test with a progressive project source, but this "shouldn't" matter given that I went from an interlaced source to an interlaced project in Avid back to an interlaced mpeg2 stream.  The field data should have remained perfectly in tact throughout the process.

Larry