[FFmpeg-devel] Allow interrupt callback for AVCodecContext

[Don Moir]

----- Original Message ----- 
From: "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Monday, January 06, 2014 4:39 AM
Subject: Re: [FFmpeg-devel] Allow interrupt callback for AVCodecContext


> On 16.12.2013, at 07:21, "Don Moir" <donmoir at comcast.net> wrote:
>> So you have to ask what the real hack is. Keeping an opened cached context or having an interrupt callback. An interrupt callback 
>> does not use any additional resources but then it has to be implemented for every decoder. An opened context works now, but uses 
>> addtional resources and mostly opened threads that are more or less dormant. Having an interruptible intense process is normal 
>> and not a hack and you should not have to beat it to death to get it to work.
>
> Sorry, but the main problem with an interrupt callback is that it just does not work properly.
> There is always going to be some place where it isn't called, and it might take quite some time.
> So you can't know how long it will actually process it, and it may or may not be fast enough for you. Everyone using it will have 
> a different overhead/responsiveness ratio they find acceptable.
> For example testing it at the end of each slice might be good enough for some and low-cost, but will not work for videos that do 
> not use slices.
> Testing after each macroblocks risks having a high overhead, mostly due to branch prediction costs and entries in jump target 
> tables etc.
> Testing after each macroblock row might not be good enough for very wide videos and/or if it also has to work for corrupted 
> frames.

Yeah I get that and I am open and it's kind of an unusual sititution. I come at from the standpoint of intense task should be 
interruptible without much cost. We know interrupt callback is a project for sure though.

> In other words: I think this looks so attractive to you because it would work
> well if it was implemented specifically _just for you_. But having code specifically
> for one person in such a large project doesn't make much sense.

I think its a real issue and I know better than to ask for something just for me. Although the people that would benefit would be in 
the minority. Players apps would not benefit much. Timeline and editiing apps can benefit though.

> Also, if these additional resources are relevant the better solution would be to
> reduce resource usage of FFmpeg,  that is something everyone would benefit from.

Yes. I don't think there is a way to partially shut down an open context so it can come back up quickly. You have to close it to 
save on resources but then re-open takes time again. I have to be as efficient as possible as I have a lot going on and I do what I 
can and hope ffmpeg is same. I keep memory and threads to a minimal so maybe you can see why it bothers me to add another cached 
open context allocating memory and threads. To refresh, it's to avoid waiting for avcodec_decode_video2 to return which can be 
anywhere from about 5 to 60 ms on my duo slower machine depending on video.

If you can think of a better way than having a cached opened context then I am all ears.