De: "Monty Montgomery" <xiphm...@gmail.com> :
>
> On Sat, Nov 13, 2010 at 8:36 AM, Eli Billauer <e...@billauer.co.il> wrote:
>> The truth is that I don't understand why people are so uptight about having
>> their original footage going directly into Cinelerra. I mean, it's nice that
>> Cinelerra supports several video formats, but somehow I'm only really calm
>> when I feed it with MJPEGs. Meaning, take the original video, convert it to
>> MJPEG using ffmpeg or mencoder and then use that file with Cinelerra.
>
> The vast majority of digital video, uless you're a studio using
> cameras that cost more than most cars, is 8 bit. 8 bit is not quite
> enough dynamic resolution to avoid reasonably easy to see artifacts,
> one reason that pro production people are so concerned with dither and
> de-banding filters in production renders.
>
> The problem with MJPEG is that it uses a different color space than
> all other video formats, and the conversion isn't lossless. Going
> from any of the MPEG formats to MJPEG increases banding and
> quantization noise, and it is noticable. Every conversion from one
> format to another, even the uncompressed formats, is doing lossy
> colorspace conversion. You lose a fraction of a bit (out of only
> eight bits!) on every colorspace conversion.
>
> That doesn't even get into the fact that converting from lossy format
> to lossy format is also adding quantization noise and losing detail
> because each conversion is... well... lossy. There's no consumer
> camera out there using a bitrate high enough to be completely
> transparent as it is, and now conversion... plus conversion... plus
> conversion... each genration is losing more and more.
>
> Oh, and Cinelerra's colorspace conversion code is also subtly wrong at
> practically every step, so you're losing more than you would be
> otherwise because of that too...
>
> Monty
AFAIK mjpeg can handle different colorspaces, including YCbCr, so it seems to
me that transcoding video (footage) to mjpeg doesn't necessarily imply
colorspace conversion, or at least a "lossy" colorspace conversion
(independently of the loss due to the codec itself).
As an example, this is what I get when I transcode AVCHD to mjpeg with ffmpeg :
$ ffmpeg -i 20100520101256.m2ts -an -vcodec mjpeg -b 24000k render.mov
FFmpeg version SVN-r25679, Copyright (c) 2000-2010 the FFmpeg developers
built on Nov 5 2010 09:22:10 with gcc 4.5.1
[... snip ...]
Input #0, mpegts, from '20100520101256.m2ts':
Duration: 00:00:11.46, start: 1.000033, bitrate: 21952 kb/s
Program 1
Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 50
fps, 50 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.2[0x1200]: Subtitle: pgssub
[buffer @ 0xc53920] w:1920 h:1080 pixfmt:yuv420p
[ffsink @ 0xc1a010] auto-inserting filter 'auto-inserted scaler 0' between the
filter 'src' and the filter 'out'
[scale @ 0xc1ddf0] w:1920 h:1080 fmt:yuv420p -> w:1920 h:1080 fmt:yuvj420p
flags:0x4
Output #0, mov, to 'render.mov':
Metadata:
encoder : Lavf52.84.0
Stream #0.0: Video: mjpeg, yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31,
24000 kb/s, 50 tbn, 50 tbc
Stream mapping:
Stream #0.0 -> #0.0
[... snip ...]
In this case, there's a colorspace conversion from 'yuv420p' to 'yuvj420p', but
is it really "lossy" in itself since colorspace "family" and chroma subsampling
are the same (YCbCr and 4:2:0 respectively) ?
Furthermore, am I right to think that colorspace conversion can be avoided in
cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as Color model in the project
parameters, when working with 8-bits YCbCr footage ?
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
