[FFmpeg-devel] Allow interrupt callback for AVCodecContext

[Don Moir]

----- Original Message ----- 
From: "Ronald S. Bultje" <rsbultje at gmail.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, January 01, 2014 10:52 AM
Subject: Re: [FFmpeg-devel] Allow interrupt callback for AVCodecContext


> Hi,
>
> On Mon, Dec 16, 2013 at 2:07 AM, Don Moir <donmoir at comcast.net> wrote:
>
>> For now just seeing what you think about this. This is about thread based
>> apps where this makes sense.
>>
>> When attempting to do a new seek or waiting to close a video, I find that
>> I am waiting on avcodec_decode_video2 to return before I can continue.
>> Depending on machine and video, this wait time can be up to about 50ms but
>> normally wait time about 5 to 20 ms or so.
>>
>> You might say 'so what' and I would agree for a simple player app it does
>> not make that much difference.
>>
>> If you are trying to stay on a timeline, or in case of scrubbing, or for
>> editing apps, this wait time does make a difference. That is, you can not
>> move on until avcodec_decode_video2 has returned.
>>
>> I can pretty much seek instantly to zero for any file except when I have
>> to wait on avcodec_decode_video2 if that be the case.
>>
>> For me, it's normal for any intense process like decoding to be
>> interruptible but this is not the case for AVCodecContext in ffmpeg. This
>> is strange, don't you think?
>>
>> For AVFormatContext you have:
>>
>> typedef struct AVIOInterruptCB {
>>     int (*callback)(void*);
>>     void *opaque;
>> } AVIOInterruptCB;
>>
>> I would use this model for AVCodecContext but change naming to:
>>
>> typedef struct AVInterruptCB {
>>     int (*callback)(void*);
>>     void *opaque;
>> } AVInterruptCB;
>>
>> Then make name changes to whereever and add to AVCodecContext.
>>
>> This callback could be implemented piecemeal whereever needed over time,
>> hitting the more intense processes first.
>>
>
> Just open a (potentially pre-cached) new AVCodecContext, it'll be even
> faster than your solution.
>
> Ronald

hmmm. That's a thought for seeking I suppose but does not apply to waiting to close. Why do I care about close time ? Because 
another video has come in to replace it or variations of it. This can happen rapidly.

Have you tried it Ronald ?