[FFmpeg-devel] v210 decoder patch

[Michael Niedermayer]

Hi

On Tue, Jul 17, 2007 at 04:57:33PM -0400, Francois Oligny-Lemieux wrote:
> Hi,
> 
> On 7/17/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > Hi
> >
> > On Tue, Jul 17, 2007 at 02:26:25PM -0400, Francois Oligny-Lemieux wrote:
> > > Hi,
> > >
> > > I came across a HD .avi file that I couldn't play back using usual
> > software
> > > (VLC, ffmpeg, Quicktime), so I created a function in ffmpeg to convert
> > this
> > > v210 pixel format to YUV422.
> > > I'm trying to submit this as a patch so ffmpeg can read these HD AVI
> > files
> > > with riff == "v210".
> > >
> > > Let me know if you like this patch and if there is something wrong with
> > it.
> >
> > * yes, if you add a PIX_FMT then you must add support to swscale to
> > convert to
> >   and from that
> > * convertion in a decoder must not loose information, so convertion to
> > 8bit
> >   is not ok
> > * ideally someone should add generic pix_fmt support to swscale so that
> > any
> >   packing of bits into 1-3 planes can be read and written with a generic
> >   routine and we dont need to add a new converter for each format, see
> >   the mailinglist for this, there where some disscussions about it but
> >   sadly patches drifted off into the direction of a bloated API full of
> >   stuff unrelated to what was actually needed
> >
> > so your options are either
> > A. continue where the generic PIX_FMT support got stuck and then just add
> >    2-5 lines of code to make lavc magically support v210
> > B. add v210 support to swscale, add a new PIX_FMT, update the raw decoder&
> >    demuxer
> 
> 
> If I understand well, option A also implies additions in swscale (since if I

yes


> go with option A I have to add PIX_FMT, and if I add PIX_FMT I have to add
> it in swscale) ? Also I have not found in old post the abandonned patch you
> refered too. I guess the keyword for my search were too generic: "swscale,
> pix_fmt, generic"

search for:
Adding 10-bit depth YUV
[RFC] 16-bit component library


> 
> The main question of this email is about option B: 

plan A is prefered


> how does AVI/RIFF would
> interface with swscale. From what I know it matches a CODEC_ID_XXX from a
> RIFF code, then load this codec and pass the packets to it. How would this
> work with swscale ? Would it use CODEC_ID_RAWVIDEO ? CODEC_ID_RAWVIDEO is

yes


> implemented in raw.c. How would the convertion be triggered in raw.c ? 

it would not


> Would
> that mean I would have to make a new pixel format with 10-bits per pixel
> similar to YUV422. Then at some place in raw.c I would need to include my
> convertion routine (see patch) to fill up this theorical 10-bpp YUV picture.

no, you must extend swscale to do the convertion


> 
> V210 uses 2 bit of padding for every 30 bit and is stored in a 128-bit
> sequence. My goal was to get rid of V210 as soon as possible into something
> known/sane instead of spreading the V210 pixel format accross ffmpeg.

plan b spreads it accross ffmpeg and requires several V210 specific routines
to be added to swscale
plan a adds the same number of routines but they are generic (and slow) to
swscale so that we need just one routine for n silly formats instead of
n

plan a is more work for whoever does it but less work overall as it will
be very easy to add a new pixel format after plan a is done


> 
> > * convertion in a decoder must not loose information, so convertion to
> 8bit is not ok
> 
> Can I get rid of all the PIX_FMT, keep v210.c and convert it to a pixel
> format that has bpp > 20 (maybe RBG24?) instead of downgrading to YUV422.

the only convertion which i would accept is to 16bit per component YUV422
but that will be more work as you still must add 16bit YUV422 support to
swscale
convertion to any RGB format is totally unaccpetable, so is to any <10bit
yuv format or yuv format of different subsample factor

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070717/521287aa/attachment.pgp>