[MPlayer-dev-eng] [PATCH] hack to make vd_ffmpeg work with demux_lavf for rm files

[Reimar Döffinger]

Hello,
On Sun, Sep 16, 2007 at 01:15:28PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 15, 2007 at 10:05:26PM +0200, Reimar Döffinger wrote:
> > attached is a hack that disables some other hack when lavf demuxer is
> > used and thus makes rv decoding work instead of crash.
> > 
> > Greetings,
> > Reimar Döffinger
> 
> > Index: libmpcodecs/vd_ffmpeg.c
> > ===================================================================
> > --- libmpcodecs/vd_ffmpeg.c	(revision 24537)
> > +++ libmpcodecs/vd_ffmpeg.c	(working copy)
> > @@ -754,7 +754,7 @@
> >  
> >      avctx->hurry_up=(flags&3)?((flags&2)?2:1):0;
> >  
> > -//    if(sh->ds->demuxer->type == DEMUXER_TYPE_REAL){
> > +    if(sh->ds->demuxer->type != DEMUXER_TYPE_LAVF)
> >      if(   sh->format == mmioFOURCC('R', 'V', '1', '0')
> >         || sh->format == mmioFOURCC('R', 'V', '1', '3')
> >         || sh->format == mmioFOURCC('R', 'V', '2', '0')
> 
> ok, btw the slice_offset/slice_count system is broken (thread saftey issues
> between demuxer and decoder also it breaks remuxing)
> and all traces of it should be removed from both mplayer and
> libavcodec
> 
> the slice offset (and count?) should be passed together with the bitstream of
> the frame, and lavc should be fixed to be able to use this
> this would fix remuxing and tread saftey issues
> also the lavf demxuer would need to be fixed to store it in the frames

I think you are not up-to-date (though I _might_ be wrong), when using
the lavf demuxer, the decoder does not need the slice_offset/slice_count
stuff (I think makes the demuxer return always one slice?), the
disadvantage being that it does not work with binary codecs.
Our demuxer transfers the slice offsets prepended to the frame data
which is again extracted in the libmpdemux part of the decoder.
Extremely ugly, but not affected by the issues you mentioned (but
affected by recent crashes due to insufficient checking of the slice
offsets and I think stupidly also not endian safe - for no good reason).

Applied btw.

Greetings,
Reimar Döffinger