Yes People this conversation is very interesting. I would like to know if is there any web site or book you know on this subject (transcodings and particularity of differents normes) which might make this knowledge more rich and stable or continious i might say. Because a very important point in my eyes. I've already learned and discovered a lot but still hungry to learn from the basements to the upstairs. I'll be interested in your exemple Monty. I shot also in HDV but edit on DV because of my old computer but that will change someday (I hope)
Haldun

Le 16/11/2010 08:58, Monty Montgomery a écrit :
Huh? I would say that anything more than having a hardly noticeable
difference in the noise level is either a bug in the transcoder or a painful
(but sometimes necessary) reduction in the bit rate. The latter should
result in chunks, blocks and noise, but changes in colors and brightness?
Pixel shifts?
Yes. The colorspace conversions themselves are not lossless, and you
lose more with each conversion.  You only have eight bits to start
with...

Example: pixel shifts. The different colorspaces do not put subsampled
color pixels in the same places.  EG, MPEG2 chroma is shifted one half
pixel to the left compared to MJPEG/MPEG1/Theora.  Either the
transcoder has to account for this (and resampling the chroma plane to
shift it will always introduce additional loss/aliasing) or just
ignore the shift, and all your edges start picking up colored fringes
(this is what Cinelerra does).

I am fully aware of the YUV vs. YCbCr flavors issue, but transcoders should
handle that gracefully.
The terminology there is confused.  'YUV' by definition is analog,
though it's often used as a generic term. 'YCbCr' is by definition
digital.  Most people just use YUV to refer to both, but when both
appear in the same sentence... well, I'm not sure what you're trying
to say. :-)

Coversion between different YCbCr flavors is not and cannot be
lossless.  EG, the range of the MJPEG Y channel is 256 steps.  The
range of an MPEG-2 Y channel is only 218 steps (less than a full eight
bits). If you convert from MJPEG to MPEG-2 colorspace, you either have
to live with the fact that your Y steps are no longer evenly spaced,
or add the additional noise of a dither to avoid banding.  'graceful'
means different things depending on what you need.

Will one conversion ruin a video?  No, of course not (though the
difference will be visible even on a cheap consumer display).  Will 2?
  If you hit 4, just about anyone paying attention to vid quality is
going to notice something is up even if they don't have an original to
compare against.

As for those 8-bit issues and extra noise that is
added when moving from one lossy format to another
All the conversions I'm talking about are lossy even when there's no
lossy compression involved!  They bite even if you never compress the
video.

I would say that as long
as the target format is given a generous bitrate, there's no reason to get a
significant difference when the target is MPEG-2 or MJPEG, possibly even
with MPEG-4 derivatives (H.264 and DIVX). And when I say "significant" I
compare with the original noise generated by the sensor or the camera's own
coding. Which may be low with professional cameras used in good lighting
conditions. On a good day.
The loss involved in lossy compression steps is a completely different
topic, and the results are also a little different.  Even with a huge
bitrate (say, 100Mbit), you're going to notice differences after just
a few compression round trips, depending on codec; most codec bases
lose energy (h.264 is a little different; it tends to *gain* HF
energy, more like real film, at least with the popular encoders).
Compress the same video over and over in the same encoder with the
same settings and watch it decay. It's going to the 10x worse if it's
going between different codecs each time, as they way each one fudges
the numbers is completely different.

The noise generated by a sensor is very different from the 'noise'
introduced by codecs.  In general, codecs lose random energy, they
don't add it.  Edges soften, grain gets lost, flat areas get lumpy or
blocky, you start seeing basis noise (usually blocks or 'tweeds') and
each format's loss characteristics are different.

In the last vid I made, I had Cinelerra accidentally set to use RGB
internally for editing.  No compression involved.  My source was HDV
(a YUVish colorspace).  I was rendering out to YUV4MPEG (which allows
the same colorspace as HDV, so it should be zero conversion).  The
difference in output quality between the 'Use RGB for rendering',
which caused Cinelerra to convert to 8-bit RGB and back, and 'Use YUV
for rendering', which involved no conversion, was stark.  I'd be happy
to post an example if people care, though I'd have to load the raw
video back off the USB drive and rerender.

  Monty

_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra



_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to