[FFmpeg-devel] [PATCH 2/6] Frame-based multithreading framework using pthreads

[Reimar Döffinger]

On Sat, Feb 05, 2011 at 02:59:43PM -0500, Ronald S. Bultje wrote:
> On Sat, Feb 5, 2011 at 1:35 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > On Sat, Feb 05, 2011 at 12:28:25AM -0500, Alexander Strange wrote:
> >> @@ -1238,6 +1255,10 @@ typedef struct AVCodecContext {
> >> ? ? ? * decoder to draw a horizontal band. It improves cache usage. Not
> >> ? ? ? * all codecs can do that. You must check the codec capabilities
> >> ? ? ? * beforehand.
> >> + ? ? * When multithreading is used, it may be called from multiple threads
> >> + ? ? * at the same time; threads might draw different parts of the same AVFrame,
> >> + ? ? * or multiple AVFrame, and there is no guarantee that slices will be drawn
> >> + ? ? * in order.
> >
> > I think this is _mostly_ the same as before, so my comments should probably
> > not be considered objections.
> [..]
> > The same applies to dr1 really, since e.g. many OpenGL implementations have
> > issues with multiple threads, even when reentracy is not required.
> 
> So, probably silly question, but have people reported such issues? I
> mean, as you say, H264 has done slice-based MT forever afaics, so it
> seems to me if there was an issue, people would've noticed it in
> mplayer (or so I hope).

First, currently the "issue" only exists for draw_horiz_band.
Since slice-based MT works so rarely it is hardly ever enabled.
I am fairly certain that threads > 1 + FFmpeg MPEG-2 decoder is
broken in MPlayer currently (never got around to investigate), but
there was never a bug report.
And the fact that the vp3 draw_horiz_band was broken for a long
time before anyone noticed tells me that few if any other applications
use this, so I fear there's no way to get reliable information on
whether it really works currently.