[FFmpeg-devel] Allow interrupt callback for AVCodecContext
Reimar.Doeffinger at gmx.de
Mon Jan 6 11:17:11 CET 2014
On 06.01.2014, at 10:01, "Don Moir" <donmoir at comcast.net> wrote:
>> 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.
Your examples make me supicious. Why would timeline and editing apps have to completly unpredictably stop decoding? Player apps should be far more affected... If it's predictable, you can just flush the context...
>> 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.
Without analysis what exactly the cost is, that is micro-optimization. There are going to be loads of places where you can micro-optimize that doesn't need new FFmpeg features and might gain your application more im overall performance.
If you did an analysis and the cost was relevant, then we should look at that and see if we can fix it so that cached contexts are nothing anyone has to worry about.
The other option is to make creating contexts really fast, so you don't have to cache them in the first place.
More information about the ffmpeg-devel