On Tuesday 15 April 2008 16:20, Herman Robak wrote: > Hold your horses... Isn't this quirk in Cinelerra a bug? I mean, > is it hard to change Cinelerra's behaviour here, so that it does > The Right Thing in the cases you have described?
Something tells me it's more difficult then one might think. Why else would the RGB-601 filter exist? It shouldn't even be necessary. If it could be easily fixed, there would be no need for this filter. Because Cinelerra's composite preview also has the wrong brightness/contrast, I guess the proper thing for Cinelerra to do is to automatically apply a color space expand on videos which needs it and to let the internal encoders compress again. This way, your preview is OK (not when using XV, but, see my comment below about that), rendering directly to MPEG is OK, and rendering to PNG and then using something like mencoder to make the MPEG is also OK. The only problem remains is rendering to JPG en then encoding with an external encoder, but as pointed out before in this thread, that's jpeg's fault. Or, a color range conversion should be done on the X11 output driver (so that it looks equally bright as XV in the compositor and media previewer) and then you take the opposite approach: you compress the color range of every format which needs it (still frames and non-mpeg video). Encoding to mpeg then results in proper brightness, and the imagesequence renderers will then need to do a color scale expansion, to come up with images with range 0-255. I think this is the best way, because then when you encode clips and reuse them a lot, you don't get brightness drift over the several generation of videos, because of all the compression and expansion (except of course when you store your scenes in non-mpeg video...). Additionally, X11 and XV will look equally bright. Excuse me for my brainstorming. If anything, it does indicate that there is no easy fix... Blender's sequence editor (which uses ffmpeg) does everything automatically and correct BTW. AVI's and still frames I load have equal contrast. Blender does not use overlay video. It doesn't even use XV, it simply writes pixels in its own window, I believe. > > Another annoyance is Cinelerra's flipping between the X11 and X11-XV > display pipeline. This is too jarring and disruptive to any grading > or colour correction work, so the user will have to work around it > some way. I'm sending a plea to those who have looked into the parts > of Cinelerra's source code that deal with this: Can you provide us > some insights? Because it needs fixing. > The best way to work around that is to set the X11 driver. In my (perhaps uninformed) opinion, the XV driver shouldn't even be used (I don't even notice a CPU usage difference). This because of the brightness instability mentioned earlier in the thread, the flickering when you change shots and when there is no video input from Cinellera (mute video), I get to see frame flashes of things I played before and are still in the overlay buffer. The only problem is, is that the brightness is not correct for your mpeg source material. But that can be fixed like I describe above. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
