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

[Kostya]

On Wed, Sep 19, 2007 at 05:01:05PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Sep 17, 2007 at 07:05:36PM +0300, Kostya wrote:
> > On Mon, Sep 17, 2007 at 02:44:13PM +0200, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Mon, Sep 17, 2007 at 02:44:20PM +0300, Kostya wrote:
> > > > On Mon, Sep 17, 2007 at 11:34:17AM +0200, Michael Niedermayer wrote:
> > > > > Hi
> > > > > 
> > > > > On Mon, Sep 17, 2007 at 08:19:50AM +0300, Kostya 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
> > > > 
> > > > There is a 'picture number' field in slice header (demuxed, not codec).
> > > > MPlayer joins them with setting avctx->slice_offset[] but IIRC it still
> > > > has the problem with slice tails.
> > > 
> > > and how does the binary rv decoder handle that?
> > 
> > MPlayer passes similar slice offsets to it and looks like it joins slice end
> > itself (I discovered this by watching on its internal buffer).
> >  
> > > btw, how is rv remuxed in mkv? i dont think its allowed to split slices
> > > like that in mkv or?
> > > 
> > > and do you have a url of such a file with split slices, id like to confirm
> > > that neither binary nor mkv remuxer nor mplayer can detect the split
> > > slices
> > 
> > http://samples.mplayerhq.hu/real/VC-RV40/test.rmvb
> 
> ok, ive looked at it and i dont understand at all where the problem is
> there are no slices split over frames, there are slices which are split
> within a frame (maybe due to being over the MTU?) but they would be
> exactly after each other after the demuxer thus no joining should be needed

In test.rmvb there's exactly one B-frame which is represented by single real slice,
which is sent as two slices - 1341 and 11 bytes. When all slices are available
my decoder joins them and has no problems after that. But lavf RM demuxer sends
it as two slices, decoder has to detect it as continuation and resume decoding
after that.

I understand that it is hacky and not good but when proper RM demuxer will be introduced
I will gladly drop this code. And decoding per slice is quite fragile and may
result in consequent frame corruptions due to parsing errors.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB