[Ffmpeg-devel] Broken rv20 sample

[Roberto Togni]

On Sat, 30 Sep 2006 00:41:35 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Fri, Sep 29, 2006 at 10:53:00PM +0200, Roberto Togni wrote:
> > Hi all
> > 
> > RV20 video from this stream
> > rtsp://ert.media.noc.ntua.gr:5554/encoder/tv.rm can't be played by
> > ffmpeg decoder (latest svn). A sample clip (dumped with MPlayer) can be
> > found at http://samples.mplayerhq.hu/real/VC-RV20/rv20errors.rm
> > 
> > The file works ok with the binary codec.
> 
> and it also works fine if you force the w/h to 256x208
> 
> just wondering where thats hidden
> 

hmm, there is some extra-extradata that is passed by MPlayer real
demuxer to vd_realvid, and that is used to build the data for the
cmsg24 custom_message. This happens only for codec id (H.263 ID) is >=
0x20200002 and <= 0x30335652.
This data is appended at the end of the bitmapinfoheader struct in
MPlayer (after the 8-byte extradata) but it's not added to the biSize
field.

This specific file has 8 extra bytes, even if MPlayer now uses only 6
bytes (typical files have 4 or 6 bytes). The values are multiplied by 4
before passing them to the binary codec.

In this file we have 0x40 0x34 0x2c 0x24 0xc0 0x90 0x58 0x48
the first 2 bytes, multiplied by 4, are the picture size (i'll have to
check if it's true also for other files).

Now the question is: why does the container have  a different pic size?
Do we have to include this extra-extradata in the extradata passed to
the codec? Or just the first 2 bytes? I colud also tweak the demuxer to
extract the size and use it instead of the one in the headers, it sounds
like a dirty hack but real demuxer already has some codec-dependant
parts.

Ciao,
 Roberto