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

[Alexander Strange]

On Sep 11, 2010, at 3:41 PM, Reimar Döffinger wrote:

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

Do you mean draw_horiz_band? The behavior is the same as mainline ffmpeg.
MPEG-2 slice threading already can call that from multiple threads.
I think it would lower performance to enforce anything less than this inside ffmpeg.

> Also ffmpeg-mt could just not advertise DR1 support if it can't
> keep the API identical to ffmpeg.

The dr1 differences I can think of are that get_buffer will be called from another thread and that more pictures will be retained.
The second is necessary, the first is just really hard to avoid.

Or do you mean something else?