On Mon, 22 Jun 2015 07:52:21 -0400 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> Hi, > > On Mon, Jun 22, 2015 at 6:24 AM, wm4 <nfx...@googlemail.com> wrote: > > > On Mon, 22 Jun 2015 11:23:55 +0200 > > Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > > > > On Mon, Jun 22, 2015 at 11:02 AM, wm4 <nfx...@googlemail.com> wrote: > > > > On Sun, 21 Jun 2015 18:34:33 -0400 > > > > "Ronald S. Bultje" <rsbul...@gmail.com> wrote: > > > > > > > >> Hi, > > > >> > > > >> On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes <h.lepp...@gmail.com > > > > > > >> wrote: > > > >> > > > >> > On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje < > > rsbul...@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... I don't mind. If this happens, it'd be extremely visible anyway, because the pixels won't line up. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
