[FFmpeg-devel] Allow interrupt callback for AVCodecContext

[Michael Niedermayer]

On Mon, Jan 06, 2014 at 11:58:06PM -0500, Don Moir wrote:
> 
> ----- 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?

I think what would be neccesary is
1. more than one developer who wants this feature
2. someone who maintains the code, writes fate tests for each codec
   that uses it and is willing and able to debug issues that it might
   cause

about implementation, the obvious way would be to treat a quick
exit request like a bitstream error, test for it once per mb row
and disable error concealment for this case.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140113/87b05c07/attachment.asc>