[FFmpeg-devel] Allow interrupt callback for AVCodecContext
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
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