[FFmpeg-devel] [PATCH] RV30/40 decoder

Kostya kostya.shishkov
Thu Sep 20 05:36:21 CEST 2007

On Thu, Sep 20, 2007 at 12:09:03AM +0200, Roberto Togni wrote:
> On Wed, 19 Sep 2007 19:53:01 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
> [...]
> > 
> > maybe its not your job to fix the demuxer, but you worked around the bug
> > in the demuxer by joining split slices in the decoder this is unacceptable
> > and the rv30/40 decoder is rejected as long as this code is in it
> > 
> I'll try to do it, but i'm very short of time in these days.
> The trick is to queue all slices into a video frame until you find the
> last one (header & 0x0c == 0x80), and then you can flush it with
> av_new_packet(). When you got the first slice you already know the size
> of the complete video frame (len2), so you can use it to allocate the
> memory. The offset (pos) is basically useless except for error
> detection and recovery, because I never found a file where the slices
> are in wrong order. Same for pic_num: you may count the slices that you
> already got, and check if the pic_num is the one you were expecting; if
> not you have an error, and assuming that slices are always in the right
> order you must close the old incomplete frame and start a new one
> (the new one may be incomplete too, if pic_num != 0). You may have more
> than one slice in one data_packet (at least mplayer demuxer can accept
> it), and you may have slices from the same video frame divided in
> multiple data_packets. I don't remember if you can have more than one
> video frame (sliced or complete) in a single data_packet, but if it's
> true the timestamp handling can get tricky (timestamps are associated
> to data_packets).

Actually, when last slice pos != len then the rest of packet are slices
for another frames. For example, test.rmvb from MPHQ/real/VC-RV40/ has
several frames stored in one packet. You can distinguish them by pic_num
byte and there's 13-bit timestamp at slice header (with offset of 12 bits
for RV30 and offset of 13 bits for RV40).
> Ciao,
>  Roberto

More information about the ffmpeg-devel mailing list