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

[Michael Niedermayer]

Hi

On Sun, Sep 16, 2007 at 01:53:11PM +0200, Reimar Döffinger wrote:
> 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.

if the lavf demuxer still returns just one slice thats broken as it wont
work with remuxing (i thought kostya changed that ...), also it would
cause problems with timestamps ...
if it returns all slices at once, then at least some rv10/20 should be
broken now as the decoder doesnt support that (it needs the broken
slice_offsetsin AVCodecContext)
now lets assume all decoders would support decoding all slices without
any slice offsets or sizes, that would work but it would fail fatally
if any slice is damaged -> we are back at what i suggested, demuxers
should put the slice_sizes in the frame itself, and decoders should use
that ...


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

yes, what about fixing the endianness in mplayer, ensuring that the format
of the sizes is sane and making lavc support that format as well and
make lavf return exactly that format too (long sentance yes :) ?
it would make all conbinatins of demuxer and decoder work, including binary
(maybe with a little convertion of the offset/size format ...)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/mplayer-dev-eng/attachments/20070916/17eddaad/attachment.pgp>