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

[Alexander Strange]

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

> On Sat, Sep 11, 2010 at 03:47:31PM -0400, Alexander Strange wrote:
>> 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.
> 
> It would be possible to e.g. disable draw slice or call it only from the
> main thread in the multithreaded case.
> Since even libswscale can't handle it, how is this intended to work
> otherwise? An application can't know whether FFmpeg will actually
> be using mutiple threads or not, so it has the choice of trying to
> always handle muti-threading and break performance for the codecs
> that don't use it or it can't use multithreading and slices at all.

If it can't handle out of order draw_horiz_band it would probably be best to not set the callback if it set thread_count > 1.
That or add a SLICE_FLAG_ONLY_IF_IN_ORDER and have libavcodec not use the call in those cases, but I'm not sure if that's simpler.

Anyway, mpeg12 + slice threading has already been calling draw_horiz_band out of order since 2004.
ffmpeg-mt actually adds no more cases of this; it will call on multiple frames but is in order (or rather, the same order as the codec already had) within each frame.
I think swscale can handle that but I can imagine some other parts of the client interface needing changes.

draw_horiz_band seems to be very underused and poorly tested as it is…vp3/some other codecs have broken it very badly recently and I didn't notice until I read the actual source.

>>> 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.
> 
> What about the first is hard to avoid?
> You just keep the main thread waiting fo buffer requests, and all real
> decoding threads pass the get_buffer through that.
> Compared to all the other things this needs (e.g. making sure you
> don't end up with wrong buffer sizes just because some later frame
> has a different frame size) this should be rather simple, though
> somewhat annoying to implement.

Well, I wanted to avoid annoyance.

The specific difference here (between a mutex on calling get/release_buffer and forwarding requests to the main thread) should only affect clients using thread-local storage, though. That does happen in mplayer (vo_corevideo, just causes a missing autorelease pool warning) but I don't think it's what you meant. What's the specific problem here?

BTW, ffplay dr1 seems to work fine. Although ffplay -vf vflip crashes with mpeg4/h264 even on mainline…