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

2015-07-11 Thread Paul B Mahol
Dana 11. 7. 2015. 03:16 osoba Ronald S. Bultje rsbul...@gmail.com
napisala je:

 ---
  libavformat/yuv4mpeg.h   |  1 +
  libavformat/yuv4mpegdec.c| 26 +++
  tests/ref/seek/lavf-yuv4mpeg | 78
+---
  3 files changed, 72 insertions(+), 33 deletions(-)

 diff --git a/libavformat/yuv4mpeg.h b/libavformat/yuv4mpeg.h
 index 750f498..eba7337 100644
 --- a/libavformat/yuv4mpeg.h
 +++ b/libavformat/yuv4mpeg.h
 @@ -23,5 +23,6 @@

  #define Y4M_MAGIC YUV4MPEG2
  #define Y4M_FRAME_MAGIC FRAME
 +#define Y4M_FRAME_MAGIC_LEN 6

  #endif /* AVFORMAT_YUV4MPEG_H */
 diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
 index 7613c3c..4ebdb78 100644
 --- a/libavformat/yuv4mpegdec.c
 +++ b/libavformat/yuv4mpegdec.c
 @@ -256,6 +256,12 @@ static int yuv4_read_header(AVFormatContext *s)
  st-sample_aspect_ratio   = (AVRational){ aspectn, aspectd };
  st-codec-chroma_sample_location = chroma_sample_location;
  st-codec-field_order= field_order;
 +s-packet_size = avpicture_get_size(st-codec-pix_fmt, width,
height) + Y4M_FRAME_MAGIC_LEN;
 +if ((int) s-packet_size  0)
 +return s-packet_size;
 +s-internal-data_offset = avio_tell(pb);
 +
 +st-duration = (avio_size(pb) - avio_tell(pb)) / s-packet_size;

  return 0;
  }
 @@ -264,7 +270,7 @@ static int yuv4_read_packet(AVFormatContext *s,
AVPacket *pkt)
  {
  int i;
  char header[MAX_FRAME_HEADER+1];
 -int packet_size, width, height, ret;
 +int width, height, ret, off = avio_tell(s-pb);
  AVStream *st = s-streams[0];

  for (i = 0; i  MAX_FRAME_HEADER; i++) {
 @@ -287,17 +293,22 @@ static int yuv4_read_packet(AVFormatContext *s,
AVPacket *pkt)
  width  = st-codec-width;
  height = st-codec-height;

 -packet_size = avpicture_get_size(st-codec-pix_fmt, width, height);
 -if (packet_size  0)
 -return packet_size;
 -
 -ret = av_get_packet(s-pb, pkt, packet_size);
 +ret = av_get_packet(s-pb, pkt, s-packet_size -
Y4M_FRAME_MAGIC_LEN);
  if (ret  0)
  return ret;
 -else if (ret != packet_size)
 +else if (ret != s-packet_size - Y4M_FRAME_MAGIC_LEN)
  return s-pb-eof_reached ? AVERROR_EOF : AVERROR(EIO);

  pkt-stream_index = 0;
 +pkt-pts = (off - s-internal-data_offset) / s-packet_size;
 +pkt-duration = 1;
 +return 0;
 +}
 +
 +static int yuv4_read_seek(AVFormatContext *s, int stream_index,
 +  int64_t pts, int flags)
 +{
 +avio_seek(s-pb, pts * s-packet_size + s-internal-data_offset,
SEEK_SET);
  return 0;
  }

 @@ -316,5 +327,6 @@ AVInputFormat ff_yuv4mpegpipe_demuxer = {
  .read_probe = yuv4_probe,
  .read_header= yuv4_read_header,
  .read_packet= yuv4_read_packet,
 +.read_seek  = yuv4_read_seek,
  .extensions = y4m,
  };
 diff --git a/tests/ref/seek/lavf-yuv4mpeg b/tests/ref/seek/lavf-yuv4mpeg
 index 81c1de9..60c3036 100644
 --- a/tests/ref/seek/lavf-yuv4mpeg
 +++ b/tests/ref/seek/lavf-yuv4mpeg
 @@ -1,27 +1,53 @@
  ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 64
size:152064
 -ret:-1 st:-1 flags:0  ts:-1.00
 -ret:-1 st:-1 flags:1  ts: 1.894167
 -ret:-1 st: 0 flags:0  ts: 0.80
 -ret:-1 st: 0 flags:1  ts:-0.32
 -ret:-1 st:-1 flags:0  ts: 2.576668
 -ret:-1 st:-1 flags:1  ts: 1.470835
 -ret:-1 st: 0 flags:0  ts: 0.36
 -ret:-1 st: 0 flags:1  ts:-0.76
 -ret:-1 st:-1 flags:0  ts: 2.153336
 -ret:-1 st:-1 flags:1  ts: 1.047503
 -ret:-1 st: 0 flags:0  ts:-0.04
 -ret:-1 st: 0 flags:1  ts: 2.84
 -ret:-1 st:-1 flags:0  ts: 1.730004
 -ret:-1 st:-1 flags:1  ts: 0.624171
 -ret:-1 st: 0 flags:0  ts:-0.48
 -ret:-1 st: 0 flags:1  ts: 2.40
 -ret:-1 st:-1 flags:0  ts: 1.306672
 -ret:-1 st:-1 flags:1  ts: 0.200839
 -ret:-1 st: 0 flags:0  ts:-0.92
 -ret:-1 st: 0 flags:1  ts: 2.00
 -ret:-1 st:-1 flags:0  ts: 0.883340
 -ret:-1 st:-1 flags:1  ts:-0.222493
 -ret:-1 st: 0 flags:0  ts: 2.68
 -ret:-1 st: 0 flags:1  ts: 1.56
 -ret:-1 st:-1 flags:0  ts: 0.460008
 -ret:-1 st:-1 flags:1  ts:-0.645825
 +ret: 0 st:-1 flags:0  ts:-1.00
 +ret: 0 st: 0 flags:1 dts: 0.04 pts: 0.04 pos: 152134
size:152064
 +ret: 0 st:-1 flags:1  ts: 1.894167
 +ret:-EOF
 +ret: 0 st: 0 flags:0  ts: 0.80
 +ret: 0 st: 0 flags:1 dts: 0.80 pts: 0.80 pos:3041464
size:152064
 +ret: 0 st: 0 flags:1  ts:-0.32
 +ret: 0 st: 0 flags:1 dts: 0.84 pts: 0.84 pos:3193534
size:152064
 +ret: 0 st:-1 flags:0  ts: 2.576668
 +ret:-EOF
 +ret: 0 st:-1 flags:1  ts: 1.470835
 +ret:-EOF
 +ret: 0 st: 0 flags:0  ts: 0.36
 +ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 

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

2015-07-11 Thread Michael Niedermayer
On Sat, Jul 11, 2015 at 10:59:58AM +, Paul B Mahol wrote:
 Dana 11. 7. 2015. 03:16 osoba Ronald S. Bultje rsbul...@gmail.com
 napisala je:
 
  ---
   libavformat/yuv4mpeg.h   |  1 +
   libavformat/yuv4mpegdec.c| 26 +++
   tests/ref/seek/lavf-yuv4mpeg | 78
 +---
   3 files changed, 72 insertions(+), 33 deletions(-)
 
  diff --git a/libavformat/yuv4mpeg.h b/libavformat/yuv4mpeg.h
  index 750f498..eba7337 100644
  --- a/libavformat/yuv4mpeg.h
  +++ b/libavformat/yuv4mpeg.h
  @@ -23,5 +23,6 @@
 
   #define Y4M_MAGIC YUV4MPEG2
   #define Y4M_FRAME_MAGIC FRAME
  +#define Y4M_FRAME_MAGIC_LEN 6
 
   #endif /* AVFORMAT_YUV4MPEG_H */
  diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
  index 7613c3c..4ebdb78 100644
  --- a/libavformat/yuv4mpegdec.c
  +++ b/libavformat/yuv4mpegdec.c
  @@ -256,6 +256,12 @@ static int yuv4_read_header(AVFormatContext *s)
   st-sample_aspect_ratio   = (AVRational){ aspectn, aspectd };
   st-codec-chroma_sample_location = chroma_sample_location;
   st-codec-field_order= field_order;
  +s-packet_size = avpicture_get_size(st-codec-pix_fmt, width,
 height) + Y4M_FRAME_MAGIC_LEN;
  +if ((int) s-packet_size  0)
  +return s-packet_size;
  +s-internal-data_offset = avio_tell(pb);
  +
  +st-duration = (avio_size(pb) - avio_tell(pb)) / s-packet_size;
 
   return 0;
   }
  @@ -264,7 +270,7 @@ static int yuv4_read_packet(AVFormatContext *s,
 AVPacket *pkt)
   {
   int i;
   char header[MAX_FRAME_HEADER+1];
  -int packet_size, width, height, ret;
  +int width, height, ret, off = avio_tell(s-pb);
   AVStream *st = s-streams[0];
 
   for (i = 0; i  MAX_FRAME_HEADER; i++) {
  @@ -287,17 +293,22 @@ static int yuv4_read_packet(AVFormatContext *s,
 AVPacket *pkt)
   width  = st-codec-width;
   height = st-codec-height;
 
  -packet_size = avpicture_get_size(st-codec-pix_fmt, width, height);
  -if (packet_size  0)
  -return packet_size;
  -
  -ret = av_get_packet(s-pb, pkt, packet_size);
  +ret = av_get_packet(s-pb, pkt, s-packet_size -
 Y4M_FRAME_MAGIC_LEN);
   if (ret  0)
   return ret;
  -else if (ret != packet_size)
  +else if (ret != s-packet_size - Y4M_FRAME_MAGIC_LEN)
   return s-pb-eof_reached ? AVERROR_EOF : AVERROR(EIO);
 
   pkt-stream_index = 0;
  +pkt-pts = (off - s-internal-data_offset) / s-packet_size;
  +pkt-duration = 1;
  +return 0;
  +}
  +
  +static int yuv4_read_seek(AVFormatContext *s, int stream_index,
  +  int64_t pts, int flags)
  +{
  +avio_seek(s-pb, pts * s-packet_size + s-internal-data_offset,
 SEEK_SET);
   return 0;
   }
 
  @@ -316,5 +327,6 @@ AVInputFormat ff_yuv4mpegpipe_demuxer = {
   .read_probe = yuv4_probe,
   .read_header= yuv4_read_header,
   .read_packet= yuv4_read_packet,
  +.read_seek  = yuv4_read_seek,
   .extensions = y4m,
   };
  diff --git a/tests/ref/seek/lavf-yuv4mpeg b/tests/ref/seek/lavf-yuv4mpeg
  index 81c1de9..60c3036 100644
  --- a/tests/ref/seek/lavf-yuv4mpeg
  +++ b/tests/ref/seek/lavf-yuv4mpeg
  @@ -1,27 +1,53 @@
   ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 64
 size:152064
  -ret:-1 st:-1 flags:0  ts:-1.00
  -ret:-1 st:-1 flags:1  ts: 1.894167
  -ret:-1 st: 0 flags:0  ts: 0.80
  -ret:-1 st: 0 flags:1  ts:-0.32
  -ret:-1 st:-1 flags:0  ts: 2.576668
  -ret:-1 st:-1 flags:1  ts: 1.470835
  -ret:-1 st: 0 flags:0  ts: 0.36
  -ret:-1 st: 0 flags:1  ts:-0.76
  -ret:-1 st:-1 flags:0  ts: 2.153336
  -ret:-1 st:-1 flags:1  ts: 1.047503
  -ret:-1 st: 0 flags:0  ts:-0.04
  -ret:-1 st: 0 flags:1  ts: 2.84
  -ret:-1 st:-1 flags:0  ts: 1.730004
  -ret:-1 st:-1 flags:1  ts: 0.624171
  -ret:-1 st: 0 flags:0  ts:-0.48
  -ret:-1 st: 0 flags:1  ts: 2.40
  -ret:-1 st:-1 flags:0  ts: 1.306672
  -ret:-1 st:-1 flags:1  ts: 0.200839
  -ret:-1 st: 0 flags:0  ts:-0.92
  -ret:-1 st: 0 flags:1  ts: 2.00
  -ret:-1 st:-1 flags:0  ts: 0.883340
  -ret:-1 st:-1 flags:1  ts:-0.222493
  -ret:-1 st: 0 flags:0  ts: 2.68
  -ret:-1 st: 0 flags:1  ts: 1.56
  -ret:-1 st:-1 flags:0  ts: 0.460008
  -ret:-1 st:-1 flags:1  ts:-0.645825
  +ret: 0 st:-1 flags:0  ts:-1.00
  +ret: 0 st: 0 flags:1 dts: 0.04 pts: 0.04 pos: 152134
 size:152064
  +ret: 0 st:-1 flags:1  ts: 1.894167
  +ret:-EOF
  +ret: 0 st: 0 flags:0  ts: 0.80
  +ret: 0 st: 0 flags:1 dts: 0.80 pts: 0.80 pos:3041464
 size:152064
  +ret: 0 st: 0 flags:1  ts:-0.32
  +ret: 0 st: 0 flags:1 dts: 0.84 pts: 0.84 pos:3193534
 size:152064
  +ret: 0 st:-1 

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

2015-06-22 Thread Hendrik Leppkes
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.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-22 Thread wm4
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


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

2015-06-22 Thread wm4
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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-22 Thread wm4
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


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

2015-06-22 Thread Carl Eugen Hoyos
Ronald S. Bultje rsbultje at gmail.com writes:

 Why don't we do that once we start seeing files with 
 frame-headers other than empty FRAME\n in the wild?

+1

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-22 Thread Nicolas George
Le quartidi 4 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
  Why don't we do that once we start seeing files with 
  frame-headers other than empty FRAME\n in the wild?
 +1

Me2.

And do not forget that, technically, 0x46 0x52 0x41 0x4d 0x45 0x0a can very
well appear in the frame data; with the bytes values, is is not even that
unlikely. Generic seeking can only really work when the start code is
guaranteed not to appear in the packets payload.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-21 Thread Ronald S. Bultje
---
 libavformat/yuv4mpeg.h|  1 +
 libavformat/yuv4mpegdec.c | 26 +++---
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/libavformat/yuv4mpeg.h b/libavformat/yuv4mpeg.h
index 750f498..eba7337 100644
--- a/libavformat/yuv4mpeg.h
+++ b/libavformat/yuv4mpeg.h
@@ -23,5 +23,6 @@
 
 #define Y4M_MAGIC YUV4MPEG2
 #define Y4M_FRAME_MAGIC FRAME
+#define Y4M_FRAME_MAGIC_LEN 6
 
 #endif /* AVFORMAT_YUV4MPEG_H */
diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
index 7613c3c..4ebdb78 100644
--- a/libavformat/yuv4mpegdec.c
+++ b/libavformat/yuv4mpegdec.c
@@ -256,6 +256,12 @@ static int yuv4_read_header(AVFormatContext *s)
 st-sample_aspect_ratio   = (AVRational){ aspectn, aspectd };
 st-codec-chroma_sample_location = chroma_sample_location;
 st-codec-field_order= field_order;
+s-packet_size = avpicture_get_size(st-codec-pix_fmt, width, height) + 
Y4M_FRAME_MAGIC_LEN;
+if ((int) s-packet_size  0)
+return s-packet_size;
+s-internal-data_offset = avio_tell(pb);
+
+st-duration = (avio_size(pb) - avio_tell(pb)) / s-packet_size;
 
 return 0;
 }
@@ -264,7 +270,7 @@ static int yuv4_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 {
 int i;
 char header[MAX_FRAME_HEADER+1];
-int packet_size, width, height, ret;
+int width, height, ret, off = avio_tell(s-pb);
 AVStream *st = s-streams[0];
 
 for (i = 0; i  MAX_FRAME_HEADER; i++) {
@@ -287,17 +293,22 @@ static int yuv4_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 width  = st-codec-width;
 height = st-codec-height;
 
-packet_size = avpicture_get_size(st-codec-pix_fmt, width, height);
-if (packet_size  0)
-return packet_size;
-
-ret = av_get_packet(s-pb, pkt, packet_size);
+ret = av_get_packet(s-pb, pkt, s-packet_size - Y4M_FRAME_MAGIC_LEN);
 if (ret  0)
 return ret;
-else if (ret != packet_size)
+else if (ret != s-packet_size - Y4M_FRAME_MAGIC_LEN)
 return s-pb-eof_reached ? AVERROR_EOF : AVERROR(EIO);
 
 pkt-stream_index = 0;
+pkt-pts = (off - s-internal-data_offset) / s-packet_size;
+pkt-duration = 1;
+return 0;
+}
+
+static int yuv4_read_seek(AVFormatContext *s, int stream_index,
+  int64_t pts, int flags)
+{
+avio_seek(s-pb, pts * s-packet_size + s-internal-data_offset, 
SEEK_SET);
 return 0;
 }
 
@@ -316,5 +327,6 @@ AVInputFormat ff_yuv4mpegpipe_demuxer = {
 .read_probe = yuv4_probe,
 .read_header= yuv4_read_header,
 .read_packet= yuv4_read_packet,
+.read_seek  = yuv4_read_seek,
 .extensions = y4m,
 };
-- 
2.1.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-21 Thread Hendrik Leppkes
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?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-21 Thread Ronald S. Bultje
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.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2015-06-21 Thread Michael Niedermayer
On Sun, Jun 21, 2015 at 04:41:23PM -0400, Ronald S. Bultje wrote:
 ---
  libavformat/yuv4mpeg.h|  1 +
  libavformat/yuv4mpegdec.c | 26 +++---
  2 files changed, 20 insertions(+), 7 deletions(-)

this needs to update the reference checksum for
fate-seek-lavf-yuv4mpeg assuming the change is intended


--- ./tests/ref/seek/lavf-yuv4mpeg  2015-06-20 16:32:37.183978941 +0200
+++ tests/data/fate/seek-lavf-yuv4mpeg  2015-06-22 00:38:43.982413616 +0200
@@ -1,27 +1,53 @@
 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 64 
size:152064
-ret:-1 st:-1 flags:0  ts:-1.00
-ret:-1 st:-1 flags:1  ts: 1.894167
-ret:-1 st: 0 flags:0  ts: 0.80
-ret:-1 st: 0 flags:1  ts:-0.32
-ret:-1 st:-1 flags:0  ts: 2.576668
-ret:-1 st:-1 flags:1  ts: 1.470835
-ret:-1 st: 0 flags:0  ts: 0.36
-ret:-1 st: 0 flags:1  ts:-0.76
-ret:-1 st:-1 flags:0  ts: 2.153336
-ret:-1 st:-1 flags:1  ts: 1.047503
-ret:-1 st: 0 flags:0  ts:-0.04
-ret:-1 st: 0 flags:1  ts: 2.84
-ret:-1 st:-1 flags:0  ts: 1.730004
-ret:-1 st:-1 flags:1  ts: 0.624171
-ret:-1 st: 0 flags:0  ts:-0.48
-ret:-1 st: 0 flags:1  ts: 2.40
-ret:-1 st:-1 flags:0  ts: 1.306672
-ret:-1 st:-1 flags:1  ts: 0.200839
-ret:-1 st: 0 flags:0  ts:-0.92
-ret:-1 st: 0 flags:1  ts: 2.00
-ret:-1 st:-1 flags:0  ts: 0.883340
-ret:-1 st:-1 flags:1  ts:-0.222493
-ret:-1 st: 0 flags:0  ts: 2.68
-ret:-1 st: 0 flags:1  ts: 1.56
-ret:-1 st:-1 flags:0  ts: 0.460008
-ret:-1 st:-1 flags:1  ts:-0.645825
+ret: 0 st:-1 flags:0  ts:-1.00
+ret: 0 st: 0 flags:1 dts: 0.04 pts: 0.04 pos: 152134 
size:152064
+ret: 0 st:-1 flags:1  ts: 1.894167
+ret:-EOF
+ret: 0 st: 0 flags:0  ts: 0.80
+ret: 0 st: 0 flags:1 dts: 0.80 pts: 0.80 pos:3041464 
size:152064
+ret: 0 st: 0 flags:1  ts:-0.32
+ret: 0 st: 0 flags:1 dts: 0.84 pts: 0.84 pos:3193534 
size:152064
+ret: 0 st:-1 flags:0  ts: 2.576668
+ret:-EOF
+ret: 0 st:-1 flags:1  ts: 1.470835
+ret:-EOF
+ret: 0 st: 0 flags:0  ts: 0.36
+ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 pos:1368694 
size:152064
+ret: 0 st: 0 flags:1  ts:-0.76
+ret: 0 st: 0 flags:1 dts: 0.40 pts: 0.40 pos:1520764 
size:152064
+ret: 0 st:-1 flags:0  ts: 2.153336
+ret:-EOF
+ret: 0 st:-1 flags:1  ts: 1.047503
+ret:-EOF
+ret: 0 st: 0 flags:0  ts:-0.04
+ret:-EOF
+ret: 0 st: 0 flags:1  ts: 2.84
+ret:-EOF
+ret: 0 st:-1 flags:0  ts: 1.730004
+ret:-EOF
+ret: 0 st:-1 flags:1  ts: 0.624171
+ret: 0 st: 0 flags:1 dts: 0.64 pts: 0.64 pos:2433184 
size:152064
+ret: 0 st: 0 flags:0  ts:-0.48
+ret: 0 st: 0 flags:1 dts: 0.68 pts: 0.68 pos:2585254 
size:152064
+ret: 0 st: 0 flags:1  ts: 2.40
+ret:-EOF
+ret: 0 st:-1 flags:0  ts: 1.306672
+ret:-EOF
+ret: 0 st:-1 flags:1  ts: 0.200839
+ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos: 760414 
size:152064
+ret: 0 st: 0 flags:0  ts:-0.92
+ret: 0 st: 0 flags:1 dts: 0.24 pts: 0.24 pos: 912484 
size:152064
+ret: 0 st: 0 flags:1  ts: 2.00
+ret:-EOF
+ret: 0 st:-1 flags:0  ts: 0.883340
+ret: 0 st: 0 flags:1 dts: 0.88 pts: 0.88 pos:3345604 
size:152064
+ret: 0 st:-1 flags:1  ts:-0.222493
+ret: 0 st: 0 flags:1 dts: 0.92 pts: 0.92 pos:3497674 
size:152064
+ret: 0 st: 0 flags:0  ts: 2.68
+ret:-EOF
+ret: 0 st: 0 flags:1  ts: 1.56
+ret:-EOF
+ret: 0 st:-1 flags:0  ts: 0.460008
+ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos:1824904 
size:152064
+ret: 0 st:-1 flags:1  ts:-0.645825
+ret: 0 st: 0 flags:1 dts: 0.52 pts: 0.52 pos:1976974 
size:152064
Test seek-lavf-yuv4mpeg failed. Look at tests/data/fate/seek-lavf-yuv4mpeg.err 
for details.
make: *** [fate-seek-lavf-yuv4mpeg] Error 1
make: *** Waiting for unfinished jobs



[]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel