[FFmpeg-devel] [PATCH] v210 decoder
Tue Feb 17 20:05:38 CET 2009
On Tue, Feb 17, 2009 at 07:38:03PM +0100, Reimar D?ffinger wrote:
> On Tue, Feb 17, 2009 at 06:53:08PM +0100, Michael Niedermayer wrote:
> > On Tue, Feb 17, 2009 at 06:26:01PM +0100, Reimar D?ffinger wrote:
> > > this is a decoder for
> > > http://samples.mplayerhq.hu/V-codecs/v210/v210_720p.avi
> > > it is not actually a proper codec, it is just little-endian
> > > UYVY with 10 bits per component and aligned to 32 bit every 3
> > > components.
> > > The last part makes it a bit awkward to deal with, which is also the
> > > reason why a favour a decoder instead of adding a pixfmt, IMHO if
> > > we want to support 10-bit pixfmts the planar or 444 variants would
> > > be enough and less painful to do...
> > I can accept codecs instead of pixfmts to deal with obscure packing
> > of pixels.
> > But i dont plan to accept code that always truncates 10 bit to 8
> Well, from my point of view that's silly because hardly anyone cares the
> slightest about those extra 2 bits and thus I expect nobody in the foreseeable
> future will write pixfmt support for them (I just see someone in 2007
> gave up at that point), but I don't really care, though I do find it a
why dont you move your 10->8 convertion into swscale? that still then
allows transcoding to other containers supporting v210 ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel