[FFmpeg-devel] v210 decoder patch

[Francois Oligny-Lemieux]

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
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"

The main question of this email is about option B: 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
implemented in raw.c. How would the convertion be triggered in raw.c ? 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.

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.

> * 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.

Thanks for your time,
Francois