[FFmpeg-devel] v210 decoder patch
Thu Jul 19 01:18:42 CEST 2007
On Wed, Jul 18, 2007 at 05:55:08PM -0400, Francois Oligny-Lemieux wrote:
> I have questions/comments:
> About the automatic generic function to extract YUV info. I began to draft
> it out yesterday and I found out it would work well on byte-aligned format.
> However luma components in V210 are not byte-aligned. For example the first
> Y luma begins at bit 3. I think V210 wouldn't fit in this hypothetical
> generic yuv reader function.
then its useless, also ive already suggested a system which supports all
> Does anyone know other YUV formats that are not byte-aligned. I don't want
> to make it complicated just for one format.
RGB16 RGB15 are the most common examples
for a bunch of other cases
> > > Do you mean adding swscale functions calls inside libavcodec/raw.c ?
> > no
> > the only change needed in raw.c is likely adding a single line to
> > ff_raw_pixelFormatTags
> Then where would the sws function be called? Would it be in ffmpeg.c (around
> line 746) ? If yes, I think YUV formats should be converted right away in
> libavcodec to the closest (and non-degrading) swscale-supported YUV format
> and should not reach this stage in ffmpeg.c. Otherwise it will mean these
> redondant YUV formats will be spread around ffmpeg.
no a codec should not do colorspace convertion if it can be avoided
think of a display device which supports the specific format directly
forced convertion to 16bit and back is not good
the convert to 16bit is a hack, its not the way it should be done
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel