[FFmpeg-soc] [soc]: r1168 - rv40/rv40.c

[Michael Niedermayer]

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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070823/04acb446/attachment.pgp>