[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 11:14 AM
Subject: Re: [FFmpeg-devel] Allow interrupt callback for AVCodecContext


> Hi,
>
> On Mon, Dec 16, 2013 at 1:30 AM, Don Moir <donmoir at comcast.net> wrote:
>
>>
>> ----- 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.
>
>
> This is where more evolved languages have the concept of garbage
> collection. For your purpose, you simply have a queue where you push
> "AVCodecContexts I don't need anymore" into, and while the application is
> in the idle loop, you pop it and destroy items left in it.
>
> Really, I understand your use case, but you don't want to add all kind of
> clever hacks in AVCodecContext to get this kind of stuff done. You're not
> using a shared I/O resource that may be protected by a cookie or worse for
> pay-per-view video, and you're not in any sort of kernel wait, so there's
> no reason to add these kind of hacks. It's a logical thought, but this
> problem has been solved already and there's better, easier and faster
> solutions out there that do not involve adding hacks in every single FFmpeg
> decoder to actually support this.
>
> Ronald

Yeah really did not like the notion of changing decoders and I don't like adding anything that might not be needed, but I will see 
what I can do with your suggestions. I never know what ffmpeg can tolerate. I had asked in libav-user but get the same old BS there 
when asking about things like this.