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

[Reimar Döffinger]

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.

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