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

[Ronald S. Bultje]

Hi,

On Mon, Jun 22, 2015 at 6:24 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 22 Jun 2015 11:23:55 +0200
> Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>
> > 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.
>
> OK, but I'd rather have slow seeking than possibly randomly inaccurate
> seeking. Maybe the seek mode could be switched on AVFMT_FLAG_FAST_SEEK.


Why don't we do that once we start seeing files with frame-headers other
than empty "FRAME\n" in the wild? Right now they are just theoretical...

Ronald