[MPlayer-dev-eng] [PATCH] vf_ffmpeg, threads and slice callback

[Reimar Döffinger]

On Sat, Sep 11, 2010 at 09:31:18PM +0200, Michael Niedermayer wrote:
> On Wed, Jul 14, 2010 at 12:32:20AM +0200, Reimar Döffinger wrote:
> > On Tue, Jul 13, 2010 at 11:24:14PM +0200, Adrian Stutz wrote:
> > > Hello,
> > > 
> > > This patch originates from this discussion on mplayer-users:
> > > http://lists.mplayerhq.hu/pipermail/mplayer-users/2009-December/078410.html
> > > http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-January/078845.html
> > > 
> > > Basically, using a ffmpeg decoder that supports slices with multiple
> > > threads leads to serious video corruption (e.g. when playing DVDs).
> > > 
> > > I can reproduce the issue with this command line (see the above thread
> > > for more info):
> > > mplayer -lavdopts threads=4 dvd:////path/to/VIDEO_TS
> > > 
> > > I cherry picked this patch from the fix Utoi applied to his unofficial
> > > git branch.
> > > 
> > > There's also a much less educated patch from me in this post:
> > > http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-January/078851.html
> > > 
> > > Is this ok to apply?
> > 
> > The do_dr1 part should only apply to ffmpeg-mt and should only needlessly
> > slow things down for normal FFmpeg.
> > Also a good question is why exactly slices fail with multiple threads...
> 
> the draw slice callback being called at the same time from multiple threads
> maybe ...
> for example the scale filter will blow up with that input

Normally the scale filter will not be used, however e.g. OpenGL possibly
won't do any better.
However, for that only disabling slices (-noslices) would be enough.
I think there was something about the threads even calling get_buffer
independently.
However, in all cases I still think it's the ffmpeg-mt design that's
simply crap, such internals as with how many threads the decoder works
should not unnecessarily be exposed, and even for draw_slices I have
some doubts that wrapping it so this issue is avoided would cause
a significant performance issue (in particular since almost all
applications will have to do it anyway).
Also ffmpeg-mt could just not advertise DR1 support if it can't
keep the API identical to ffmpeg.