[FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.

Hendrik Leppkes h.leppkes at gmail.com
Mon Jun 22 11:23:55 CEST 2015


On Mon, Jun 22, 2015 at 11:02 AM, wm4 <nfxjfg at googlemail.com> wrote:
> On Sun, 21 Jun 2015 18:34:33 -0400
> "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
>
>> Hi,
>>
>> On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes <h.leppkes at gmail.com>
>> wrote:
>>
>> > On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje <rsbultje at gmail.com>
>> > wrote:
>> > > ---
>> > >  libavformat/yuv4mpeg.h    |  1 +
>> > >  libavformat/yuv4mpegdec.c | 26 +++++++++++++++++++-------
>> > >  2 files changed, 20 insertions(+), 7 deletions(-)
>> > >
>> >
>> > What happens if a seek does not end up on a perfect frame boundary?
>> > Wouldn't that entirely screw over any further reading?
>> >
>> > So is it really that "rough", or does it actually work precise enough
>> > to do that?
>>
>>
>> It works for all y4m files I see in the wild, but the problem is that the
>> y4m spec is a little confusing. The frame header magic is "FRAME", followed
>> by optional per-frame options, and then a "\n". This is always empty (i.e.
>> "FRAME\n"), but in theory it could be non-empty and then this doesn't work.
>>
>> I don't know how much we care about such theoretical files to make a more
>> difficult dur/seek implementation.
>
> Why not use generic seeking mode? Add AVFMT_GENERIC_INDEX to the format
> flags. The utils.c will do seeking by doing byte seeks and using the
> byte position of previous packets. If you seek forward, it will read
> and skip packets until the target is reached (for parts of the file
> that have not been indexed yet). This should be very reliable, but of
> course seek speed will depend on I/O bandwidth.

Generic seeking is rather expensive, and if a format is already strict
CBR, doing a seek based on that is probably better.
I wonder how hard it would be to write a re-sync function to find the
next FRAME header when a seek does actually end up on the wrong spot.

- Hendrik


More information about the ffmpeg-devel mailing list