The "+16" is not NTSC setup.  It is simply footroom in the Y'CbCr encoding
         scheme for digital pixel data.  NTSC setup is part of the spec for *analog*
         transmission.

I understand that the lowest "legal" Y' value is 16. I assume it comes
right off my camera in the range 16-235?  But the libdv and kino
documentation led me to believe that to get the same brightness on a
computer monitor as I would get playing back from my camera to the TV,
I would need another 16 added on.  From the libdv README:

  NTSC Setup/Pedestal
  ===================
  The decoder's add_ntsc_setup option should only be used 
  by North American NTSC users when viewing the video on your computer
  monitor. It should never be used when transcoding, image processing,
  or rendering.

Kino says much the same, and suggests that US NTSC users should turn
on add_ntsc_setup, which adds 16 to Y'.  It does look sort of dark
without the flag, but that's subjective.  I guess the only way to do a
direct comparison is to compare both version on the TV.

         >that it should NOT be added before any processing, which makes sense
         >as it pushes Y up against the upper bound.  Despite this, from
         >examining output and the code, it looks as about half the software out
         >there adds the setup.  kino/smil2yuv (by default) and transcode do,
         >lav2yuv and ffmpeg don't (if I recall properly).

        Are you talking about the +16 offset/base-level in Y', or NTSC setup?
         Assuming the former, half the software out there is broken, and does not
         properly process Y'CbCr --- either by neglecting the +16, or by doing
         weird things with it.  File bug reports.

I'm talking about the libdv option add_ntsc_setup, which adds 16 to
Y'.  Since it shifts Y' I don't think any software should do it by
default, and I spent a while tracking down why different programs'
output had different brightness levels.  yuvcorrect -M STAT is handy
for that.  It all traces back to add_ntsc_setup in libdv.

        Neither --- it simply hands the (assumed correct) Y'CbCr data over to the
         SDL library.  *That* library needs to correctly convert it to R'G'B' for
         display --- and SDL probably still doesn't do that.

No, as discussed previously the hardware and software YUV outputs from
SDL are visually quite different, with the latter more green.

         "Yes, setup, please."  It's a question of how the analog signal is
         interpreted; it's all the same once it is digital (thankfully).

So, to be clear: I want Y' values between 16-235 everywhere, in
whatever digital format?

Dan



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to