[FFmpeg-devel] Threading issue with avcodec_decode_video2 ?

Reimar Döffinger Reimar.Doeffinger at gmx.de
Tue Nov 13 07:13:16 CET 2012



On 13 Nov 2012, at 00:25, "Don Moir" <donmoir at comcast.net> wrote:

> ----- Original Message ----- From: "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
> Sent: Monday, November 12, 2012 4:44 PM
> Subject: Re: [FFmpeg-devel] Threading issue with avcodec_decode_video2 ?
> 
> 
>> On Mon, Oct 29, 2012 at 10:38:25PM +0100, Hendrik Leppkes wrote:
>>> On Mon, Oct 29, 2012 at 10:22 PM, Don Moir <donmoir at comcast.net> wrote:
>>> > In vc1dec.c it calls the init functions and does a little more. The code
>>> > under return -1; appears to be ok and seems to be happy in either
>>> > vc1_decode_init or vc1_decode_frame, but "if (ff_msmpeg4_decode_init(avctx)
>>> > < 0 || ff_vc1_decode_init_alloc_tables(v) < 0)" only seems to be happy in
>>> > vc1_decode_init or when locked down.
>>> >
>>> > Do you have a multi-threaded test case for this kind of thing ?
>>> 
>>> I looked over those two functions, and sadly its required to call them
>>> there, because its possible that width/height of the video are not
>>> known during the init function, or may even change in case of vc1image
>>> decoding.
>> 
>> Could you explain how you came to that conclusion?
>> At least for ff_msmpeg4_decode_init I am not so sure about that.
>> But even if they need to be called there, I see nothing speaking against
>> _also_ calling them in the init function, this results in the VLC tables
>> being initialized there, thus they will no longer be initialized when
>> calling those functions during decode, thus eliminating the race
>> condition.
> 
> Hendrik might have more info but in vc1_decode_frame you have this code:
> 
>   if (s->context_initialized &&
>       (s->width  != avctx->coded_width ||
>        s->height != avctx->coded_height)) {
>       ff_vc1_decode_end(avctx);
>   }
> 
> If  'ff_vc1_decode_end'  gets called then it's back to being unintialized and back to same problem as far as I can tell. You can call it in the init function but not sure that helps in the overall sense. 

There is no way to reset the static VLC tables, because it makes no sense to ever do that.
So the part at issue should always remain initialised, which is the whole point of my suggestion.


More information about the ffmpeg-devel mailing list