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

[Kostya]

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.
 
> [...]
> > [...] 
> > > > +    cw = av_mallocz(size * 2);
> > > > +    syms = av_malloc(size * 2);
> > > > +    bits = av_malloc(size);
> > > 
> > > these could as well use use arrays on the stack, simplifying the source
> > 
> > Table sizes vary from 16 to 1296 elements. I suspect that it's easier to allocate
> > memory instead of remembering where 1296 came from.
> 
> then use
> int bits[size];

I did not know this was possible. I will give it a try. 
 
> [...]
> > > [...]
> > > > +static void rv40_postprocess(RV40DecContext *r)
> > > > +{
> > > 
> > > unused
> > 
> > But it should be used and will be used eventually.
> 
> no, postprocessing does NOT belong in the decoder, a loop filter does but
> the name doesnt sound like that
> if you want to support rv30/40 postprocessing, write a filter using
> the filter layer in soc, it would be interresting to see what effect it
> has on h.264 and svq3 ...
 
Yes, this is a loop filter and it is required to reconstruct frames properly. 
  
> > > [...]
> > > > +    if(avctx->slice_count){
> > > > +        slice_count = avctx->slice_count;
> > > > +        slice_offset = avctx->slice_offset;
> > > 
> > > 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

First of all, lavf RM demuxer should support slice gathering.
Maybe sombody in his free time...
I would gladly switch decoder to handle only gathered slices (they are
easier to decode anyway).
 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB