[FFmpeg-devel] [PATCH 1/2] file: operate in blocks, check for interrupts

Michael Niedermayer michaelni at gmx.at
Wed Jul 10 19:57:57 CEST 2013


On Mon, Jul 08, 2013 at 06:41:22PM +0300, Andrey Utkin wrote:
> 2013/7/8 Michael Niedermayer <michaelni at gmx.at>:
> > isnt it sufficient to simply limit size without any loop ?
> 
> Yes, it is sufficient.
> 
> > also, by how much does this patch improve reactiveness ?
> 
> Currently i have such facts:
> 1. File reading is works through retry_transfer_wrapper(). There it
> tries to read full block _first_. I.e. avio.interrupt_callback is not
> checked before reading the block, and also no interrupt_callback check
> if block is fully read. This is usually the case with generic files.
> 2. avformat_find_stream_info() on mpegts file reads the file in blocks of 32768.
> 3. avformat_find_stream_info() calls subroutine
> estimate_timings_from_pts(), which ignores AVERROR_EXIT it its loops.
> 

> My conclusions:
> 1. It is not optimal for reactiveness to have interrupt check after
> I/O processing. But this is optimal for performance, so we can live
> with it. Also it is undesirable to change this behaviour because some
> applications may depend on the above fact.

> 2. To the above: if there are more voices for it, we could optionize
> this behaviour (so user can choose between performance and
> reactiveness optimization).

This probably makes most sense
extending the callback is tricky though due to AVIOInterruptCB not
having any flags and being non extensible.
The cleanest solution i see ATM would be adding a special case
something like
if(cb->callback == CHECK_INT && *(int*)cb->callback->opaque > 0)
    return AVERROR_EXIT

This does no callback at all but just checks an integer from a user
provided pointer so its not affected by the user mistakely providing
a slow callback. And this kind of check could then be done in the
retry_transfer_wrapper loop

Also ffplay & ffmpeg just check a pointed to variable so they could
easily use it.

I wonder if (m)any applications do more complex things than checking
a variable in the callback.

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/20130710/9d127c44/attachment.asc>


More information about the ffmpeg-devel mailing list