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

[Roberto Togni]

On Mon, 17 Sep 2007 11:34:17 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

[...]
> > 
> > They are stored in container that way and I have not found a way to determine
> > whether current slice is really previous slice tail or not while demuxing.
> 
> how does mplayers demuxer do it? it does pass complete frames from what
> i remember
> 
[...]
> > > AVCodecContext.slice_count and slice_offset is deprecated, they break
> > > remuxing, cause thread issues with the demuxer writing these into the
> > > decoder context, ...
> > 
> > At least MPlayer and Xine pass slices gathered into one frame and my decoder
> > decodes both single slice and multiple slice data.
> 
> mplayer and xine should be changed to pass the offsets or sizes within the
> frame that makes remuxing work, fixes a few race conditions and so on
> of course its not your job to fix xine and mplayer, but if you support
> only the broken API noone will fix them
> 

This is how MPlayer passes frames to the decoder. All data si
passed along with the frame, there is no out-of-band data
(except from the extradata stored in the file header). Please note that
some changes are made in vd_ffmpeg before sending this data to lavc.

This is a quick explanation, i'll double-check it tomorrow, feel free
to ask for details.

uint32_t chunk_number-1 //< number of chunks (0==1 chunk)
uint32_t timestamp //< frame timestamp, the int value from the stream
uint32_t video_data_length //< length of the video data (all chunks)
uint32_t chunk_table_offset //< offset to chunk table
uint8_t[video_data_length] //< video data
uint32_t 1 //< flag?
uint32_t offset_to_1st_chunk // counting from video data
uint32_t 1
uint32_t offset_to_2nd_chunk
...
uint32_t 1
uint32_t offset_to_nth_chunk

At the moment all uint32_t fields are stored in native endian format
(this will be changed). iirc the binary codec need the chunk table in
native endian.

Chunks are the video subpackets in the demuxer, probably they are the
same thing you call slices.

The 1 fields (some kind of flag?) are needed by the binary codec. They
are passed this way from the demuxer to avoid a realloc() for every
video frame (imo, this code predates my hacking on the real demuxer).

The binary codec wants the first 4 values into a special struct
(along with some padding), and everything else starting from video data
in a separate buffer.
Don't ask me why the binary codec need the timestamp of the frame.

The chunk number is stored in the header of the 1st chunk (also in the
others?), timestamp is from the data packet, the other values are
computed by the demuxer (note: in mplayer video_data_length is the sum
of the lengths of the chunks, normally it's equal to the complete video
frame size stored in the header of the packet).

Matroska stores the frame in a similar way (they use
little endian for the values iirc):

uint32_t chunk_number-1
uint8_t video_data
uint32_t 1 //< flag?
uint32_t offset_to_1st_chunk // counting from video data
uint32_t 1
uint32_t offset_to_2nd_chunk
...
uint32_t 1
uint32_t offset_to_nth_chunk


There is some header flag to decide if a chunk is the last chunk of a
frame; in case of error MPlayer demuxer uses the sequence number of the
chunk to tell if a chunk is misplaced (expected seq != chunk seq).
iirc there is also a frame number but that's unused.


Hope I didn't put too many mistakes in this description. I know this is
quite confusing, I'll try to provide a file layout and the exact
demuxing strategy as soon as I have some more time.


Ciao,
 Roberto

-- 
Better is the enemy of good enough.