I now realize that my test was irrelevant and the result pointless. * When I load the mpeg2 clip into cinelerra, render it as uncompressed YCbCr 4:2:0 (using yuv4mpegpipe), reload it into cinelerra and compare to the original clip (setting "Overlay" mode of the track to "Subtract"), there's absolutely no difference between original and rendered versions of the video.
* When I load the mpeg2 clip into avisynth (using DGDecode_MPEG2Source), render it as uncompressed YCbCr 4:2:0 (using avs2yuv), reload it into avisynth and compare to the original clip (with Subtract), there's absolutely no difference between original and rendered versions of the video. * Moreover, when I load the mpeg2 clip into avisynth, render it as uncompressed YCbCr 4:2:0, load this (.y4m) file into cinelerra, render it again as uncompressed YCbCr 4:2:0, then reload it into avisynth and compare with the original, there's also no difference between original and twice-rendered versions of the video. avisynth -> .y4m -> cinelerra -> .yuv -> avisynth = exactly the same video stream (Hope that's understandable...) What it means (I guess) : 1. The difference that appeared in my previous test only means that cinelerra and avisynth/DGDecode decode mpeg2 in a slightly different way - the two file loaders produce a slighlty different video stream from the same mpeg2 file. 2. Using "YUVA-8 Bit" or "YUV-8 Bit" as "Color model" in cinelerra definitely avoids colorspace conversion when working with YCbCr video, and therefore allow some kind of "lossless" editing inside the video editing workflow. -> Good news :-) ----- Mail Original ----- De: "julien cynober" <[email protected]> À: [email protected] Envoyé: Mardi 16 Novembre 2010 20h24:27 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [CinCV] help choosing a video camera compatible with gnu/linux Thank you Monty for your clear and informative explanations ! De: "Monty Montgomery" <[email protected]> : >> 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 ? > > No, unfortunately. You could minimize the loss by working in floating > point intermediaries, but Cinelerra doesn't support them AFAIR. The > chroma resampling aspects complicate it further (floating point won't > save you there). You're right - as usual. I did a little test to know if I could avoid colorspace conversions, and if not, how much loss it would induce. My typical workflow for SD video editing is : 1. Load footage (mpeg2 from my camcorder, sometimes DV from another one) into cinelerra using "YUVA 8-Bit" as color model ; edit video ; render it with yuv4mpegpipe to uncompressed "YUV" 4:2:0 stream. 2. Load this uncompressed stream into avisynth (running under wine) with RawSource() ; apply some nice postprocessing filters. 3. Pipe frames served by avisynth to an encoder (usually x264) with avs2yuv.exe. I reproduced steps 1 and 2 of this workflow in my test : 1. Cinelerra load & render 1.1. Load mpeg2 footage into cinelerra ("YUVA 8-Bit" color model) 1.2. Render -> File format : YUV4MPEG Stream, Use Pipe : 'ffmpeg -i - -an -vcodec rawvideo %' 2. Comparison with avisynth 2.1. Load original mpeg2 footage (with DGDecode plugin) as "src" 2.2. Load uncompressed "YUV" file rendered by cinelerra (with RawSource plugin) as "rdr" 2.3. Create clip "a" containing the difference between src and rdr, using Subtract() 2.4. Create clip "b" by increasing contrast of clip a difference to make it blatantly obvious, using Levels() 2.5. Display a and b side-by-side + timecode information (hours:minutes:seconds:frame) Here's my avisynth script : """ src = DGDecode_MPEG2Source("D:\M2U00070.d2v") rdr = RawSource("D:\render1.yuv",pixel_type="I420") a = Subtract( src , rdr ).Subtitle("visible differences") b = a.Levels(127, 1, 129, 0, 255).Subtitle("amplified differences") StackHorizontal( a , b ) ShowSMPTE() """ Here's a still image (png) showing the output of this script : http://img241.imageshack.us/img241/2590/000310.png Only grey pixels can be considered identical between the two clips. The left part of the screenshot is totally grey, with only very slight noise, meaning differences are almost not noticeable. But when these differences are (over)amplified, they become clearly visible on the right part of the picture. Conclusion : there are very slight differences between original footage and uncompressed "YUV" file rendered by cinelerra. Since these differences are almost unnoticeable to the human eye, I think I won't change my workflow for that :-) ----- De: "Monty Montgomery" <[email protected]> : > 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. I also noticed a visible color shift when I used RGB for editing and YUV4MPEG for rendering. ----- De "Burkhard Plaum" <[email protected]> : > yuv420p has video range for luma and chroma. yuvj420p has full range > (0..255). So the conversion simply maps the video range values to full > range (e.g. with a loopup table). It seems to me that yuv420p has full range (0-255) for luma and chroma. It can be demonstrated with an histogram. >> 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 ? > > You save the conversion to RGB if you use these. > But these colormodels are 4:4:4, so you'll upsample the chroma planes, > which doubles the memory footprint of the video frames compared to 4:2:0. You're right, but choosing another "Color model" (eg. "RGB 8-Bit" or "RGBA 8-Bit") would also at least double the memory footprint, so there's no way to avoid it. _______________________________________________ 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
