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

[Reimar Döffinger]

On Sat, Feb 05, 2011 at 03:50:02PM -0500, Ronald S. Bultje wrote:
> On Sat, Feb 5, 2011 at 3:14 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > 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.
> 
> Uoti tells me something along those lines also. Could we simply claim
> that GL && threads && draw_hband(/dr?) just happen to be incompatible?
> After all it's in the doxy that draw_hb is called from multiple
> threads - and it's up to the application to disable either threads or
> draw_hband(/dr?) if they want to use GL output, nog really up to lavc.
> Would you be OK with it that way?
> 
> If not, what shall we do? Maybe I misunderstand.

My suggestions is to add a way to detect which types (or at least if at
all) threading will be used, and to add that in a way that allows to
still change the draw_slice, get_frame and possibly other callback pointers.
It's not a big deal if we do not manage to get it 100% accurate in cases
where it depends on content (e.g. for slice multithreading), but at least
the big cases "codec does support MT" and "FFmpeg compiled without pthread"
should be covered.