[FFmpeg-devel] Allow interrupt callback for AVCodecContext

[Ronald S. Bultje]

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