On Sat, 2008-11-22 at 15:15 +0100, Stefan Scheffler wrote: Sometimes I type too fast (or think too slow, or both). Let's recap the whole thing and let's write down a sensible battle plan.
> Am Sat, 22 Nov 2008 10:50:31 +0100 > schrieb Francesco Romani <[EMAIL PROTECTED]>: > > > On Sat, 2008-11-22 at 10:09 +0100, Francesco Romani wrote: > > > > > to UYVY. This happened roughly around the time of colorspace > > > identification (--use_rgb, -V --uyvy merged into -V). > > ^^^^^^^^^^^^^^^^ > > unification > > > > > The solution looks easy enough: allow UYVY to be specified via -V. > > > > Not that easy, really. I'm tacking this chance to cleanup some > > internal mess and finally clarify some things, but the patch seems > > invasive (and can have a few consequences which deserve a few more > > thinking). > > > > For HEAD, no big deal. For 1.1.x (given we're in RC stage), I dunno. > > > > Bests, > > > Alright, I guess it would affect a lot of the internal conversations. Yes indeed. The whole story can be summarized as that. - As our passionate followers likely know, some parts of transcode grown up messy. One of that was internal colorspace handling. - We've got CODEC_YUV422 (forgive the ambiguous naming here) which was (likely) intended to mean UYVY, but time passed and someone started using it as YUV422 planar. - Time passed again, and entropy was added to the (already fairly rich pool). - Enter the new transcode team. Someday in 2005, internal colorspace conversion routines got rewritten from scratch and much, MUCH sanitization happened. At that time, we've chosen to bind the ambiguous name "yuv422" to planar format. - most of code was ported to planar yuv422. Some bits still believes that YUV422 is UYVY, but they are a minority right: encode/encode_xvid.c export/export_dvraw.c export/export_raw.c export/export_xvid4.c filter/subtitler/load_pictures.c import/extract_avi.c import/import_avi.c import/import_bktr.c import/probe_bsdav.c import/tcextract.c import/v4l/import_v4l2.c import/v4l/videodev.h libtcvideo/tcvideo.c It's mostly Import/Export. > I only asked because of Wasilios Goutas question on the user list. It > would be possible to do what he wants if the format was still packed. > > What about an option for import_raw to specify the source color model? > If the core can't handle the specified model the module converts it to > something it can. Export_raw does something similar already. Adding a quick fix is easy enough (this time for real!) and I like the above proposal. It will be added ASAP, likely in 1.1.x too. -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
