[FFmpeg-devel] Allow interrupt callback for AVCodecContext

Don Moir donmoir at comcast.net
Tue Jan 7 05:58:06 CET 2014


----- Original Message ----- 
From: "Michael Niedermayer" <michaelni at gmx.at>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, January 08, 2014 7:13 AM
Subject: Re: [FFmpeg-devel] Allow interrupt callback for AVCodecContext

>> The way it is right now with cached context is extreme overkill to
>> perform a fairly simple task. You have memory allocations per thread
>> that can be quite large and that depends on codec. For h264 it can
>> be large and for others not as much. The whole process of caching a
>> context has some merit but the overhead and time required to close
>> and reopen reduces it's effectiveness.
>>
>> Essentially, everytime you want to use a cached context, you will be
>> closing threads, freeing memory, etc and then reopening the threads
>> and reallocating memory (silly). The reason for this is it's the
>> only way to free the context accumulated memory. flush does not do
>> this and I don't know whats up with that.
>>
>> Backing off from this but of course would still like
>> avcodec_decode_video2 to be interruptible or a reasonable way to
>> avoid waiting on it. Cached context the way it stands now is
>> anything but reasonable.  Possibly if flush actually flushed the
>> memory it would be more attractive.
>>
>> The AVCodecContext.execute function which can be set by user would
>> almost work but that is only used for slices and it does not look
>> like its complete to me.

>are you using frame threads ?
>if you want lowest latency possibly , frame threads probably are
>not a good idea

Tried a few variations with thread_type. Seems to be less latency with FF_THREAD_FRAME rather than with FF_THREAD_SLICE so that is 
not clear.

Test done with older and slower duo machine.

Average latency is not too bad but max latency can be about 50ms or so. Average latency has a range of about 2ms to 9ms or more. 
Tested with mpeg2 and h264.

Do you think execute/execute2 will be in a state someday that it could be used for interrupt or is that just not the way to go? 



More information about the ffmpeg-devel mailing list