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

Ronald S. Bultje rsbultje
Sat Feb 5 21:50:02 CET 2011


Hi,

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.

Ronald



More information about the ffmpeg-devel mailing list