[FFmpeg-soc] [soc]: r1168 - rv40/rv40.c
David Conrad
umovimus at gmail.com
Thu Aug 23 23:01:22 CEST 2007
On Aug 23, 2007, at 2:11 PM, Michael Niedermayer wrote:
> Hi
>
> On Thu, Aug 23, 2007 at 08:06:21PM +0300, Kostya wrote:
>> On Thu, Aug 23, 2007 at 06:38:03PM +0200, Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Thu, Aug 23, 2007 at 07:18:08PM +0300, Kostya wrote:
>>>> On Thu, Aug 23, 2007 at 06:05:26PM +0200, kostya wrote:
>>>>> Author: kostya
>>>>> Date: Thu Aug 23 18:05:26 2007
>>>>> New Revision: 1168
>>>>>
>>>>> Log:
>>>>> Handle case when slice tail is sent as another slice
>>>>
>>>> Let me elaborate on it a bit.
>>>>
>>>> Real container stores video frame by slices (controversal
>>>> decision to me).
>>>> They decided to drop macroblock count in slice, so you need
>>>> either to get
>>>> next slice, parse its header and set limit or just decode until
>>>> end and
>>>> hope thet nothing goes wrong. But it appears that sometimes
>>>> slice end is
>>>> stored as new slice so you need to add it to the end before
>>>> decoding.
>>>>
>>>> In order to workaround this err... design I keep track of last
>>>> macroblock
>>>> decoded successfully in slice and in case of bit reader reading
>>>> past
>>>> frame data set mode expecting frame tail, then if it arrives
>>>> (without
>>>> correct slice header), concatenating it with the previous data and
>>>> decoding starting from the last successfully decoded macroblock.
>>>
>>> you should use a parser which puts these parts back together
>>> how should it work with remuxing in another container lets say
>>> matroska, i very seriously doubt that it will work if the tail of
>>> a slice
>>> is in the next frame ...
>>
>> Not frame, it belongs to the same frame, just resides in separate
>> slice.
>> Typical RV40 intra frames contain about 11 slices, interframes -
>> 2-4 slices.
>> Also I doubt that SoC Matroska muxer will be able to do this (but
>> I will
>> ge happy if proven wrong).
SoC Matroska muxer currently doesn't handle any Real codecs correctly...
>>> also are you sure that there are no flags/sizes at demuxer level
>>> which
>>> could be used to easily combine these parts into slices or frames
>>> without needing to look into the codec bitstream?
>>
>> There seems to be something. At least MPlayer demuxer gathers
>> slices for
>> one frame (including those loose tails).
>>
>>>>
>>>> I've run my decoder under FFplay and MPlayer and should note
>>>> that lavf
>>>> demuxer drops some frames (can be clearly seen on title fade out in
>>>> test.rmvb), so I will try to fix it.
>>>
>>> thanks
>>
>> Can you give some hints on how to operate on slices gathered into
>> one frame?
>> Setting avctx->slice_offset[] and avctx->slice_count in parser is
>> impossible
>> because of race conditions.
>
> the slice_offset/slice_count should be deprecated, it was bad
> design ...
>
> the standard h.264/mpeg1/... way is that there is a startcode which
> does not
> occur anywhere in the bitstream so you just search for that if you
> need to
> know where the slices start, i guess that doesnt work with rv40 ...
>
> the second simple solution is just to decode slice after slice if
> thats
> possible without knowing where the slices start and end
>
> the third solution is to make the demuxer (which knows where the
> slices
> start put this data in the returned packet, like
> 32bit length of first slice, 32bit length of second slice, ...
> (you know where the list ends from the fact that theres no space left)
> of course there are a million other possible solutions
The third would make supporting muxing Real video in Matroska easier :)
I think Matroska is supposed to use the packed bitstream format
described at http://www.bunkus.org/videotools/librmff/doc/index.html
but the samples I have don't seem to correspond to this. Instead, the
first byte is the number of slices minus one, then for each slice
there's 4 bytes of something (always 0x01 0x00 0x00 0x00 in my
samples) and a 32bit LE offset to where the slice starts, then the
slice data after this header. See http://samples.mplayerhq.hu/
Matroska/realaudio/nosound.mkv for an example.
More information about the FFmpeg-soc
mailing list