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

Ronald S. Bultje rsbultje
Sat Feb 5 22:20:38 CET 2011


Hi,

On Sat, Feb 5, 2011 at 3:55 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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.

I see, so something like AVCodec bla { [..] .capabilities = horiz_band
| bla | ONLY_IF_THRADS_ENABLED(CODEC_CAP_FRAME_THREADS) [..] would be
sufficient?

(And I guess we'd need a similar flag for slice-threads also?)

Ronald



More information about the ffmpeg-devel mailing list