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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
