[FFmpeg-devel] [PATCH] v210 decoder
Tue Feb 17 20:54:30 CET 2009
On Tue, Feb 17, 2009 at 08:45:22PM +0100, Reimar D?ffinger wrote:
> On Tue, Feb 17, 2009 at 08:05:38PM +0100, Michael Niedermayer wrote:
> > 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 ...
> I will consider it the moment someone points me to a nice step-by-step
> tutorial to adding stuff to swscale, or makes it similarly easy to add a
> conversion to swscale as adding a codec (i.e. copy a file, modify it,
> add a few references).
it would be that simple had the related soc project suceeded :)
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