subject:"\[FFmpeg\-devel\] \[PATCH\] lavf\/mov.c\: Guess video codec delay based on PTS while parsing MOV header."

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-12-20 Thread Michael Niedermayer

On Mon, Dec 18, 2017 at 03:31:16PM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 56 
> 
>  tests/fate/mov.mak   |  7 +
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  tests/ref/fate/mov-guess-delay-3 |  3 +++
>  5 files changed, 72 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2
>  create mode 100644 tests/ref/fate/mov-guess-delay-3

will apply
thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-12-18 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 56 
 tests/fate/mov.mak   |  7 +
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 tests/ref/fate/mov-guess-delay-3 |  3 +++
 5 files changed, 72 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2
 create mode 100644 tests/ref/fate/mov-guess-delay-3

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 28d60289aa..480e506370 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3241,6 +3241,60 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+#define MAX_REORDER_DELAY 16
+static void mov_estimate_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t pts_buf[MAX_REORDER_DELAY + 1]; // Circular buffer to sort pts.
+int buf_start = 0;
+int buf_size = 0;
+int j, r, num_swaps;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+st->codecpar->codec_id == AV_CODEC_ID_H264) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+if (buf_size == (MAX_REORDER_DELAY + 1)) {
+// If circular buffer is full, then move the first element 
forward.
+buf_start = (buf_start + 1) % buf_size;
+} else {
+++buf_size;
+}
+
+// Point j to the last elem of the buffer and insert the current 
pts there.
+j = (buf_start + buf_size - 1) % buf_size;
+pts_buf[j] = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// The timestamps that are already in the sorted buffer, and are 
greater than the
+// current pts, are exactly the timestamps that need to be 
buffered to output PTS
+// in correct sorted order.
+// Hence the video delay (which is the buffer size used to sort 
DTS and output PTS),
+// can be computed as the maximum no. of swaps any particular 
timestamp needs to
+// go through, to keep this buffer in sorted order.
+num_swaps = 0;
+while (j != buf_start) {
+r = (j - 1 + buf_size) % buf_size;
+if (pts_buf[j] < pts_buf[r]) {
+FFSWAP(int64_t, pts_buf[j], pts_buf[r]);
+++num_swaps;
+}
+j = r;
+}
+st->codecpar->video_delay = FFMAX(st->codecpar->video_delay, 
num_swaps);
+
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3897,6 +3951,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_estimate_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 19b01304fb..b37ba0e3aa 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -13,6 +13,9 @@ FATE_MOV = fate-mov-3elist \
fate-mov-elst-ends-betn-b-and-i \
fate-mov-frag-overlap \
fate-mov-bbi-elst-starts-b \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
+   fate-mov-guess-delay-3 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -82,3 +85,7 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
+fate-mov-guess-delay-3: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_4bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-12-18 Thread Sasi Inguva

Sorry for getting back so late as I was on vacation. Submitting the patch
again. This time I compute the delay exactly using a 17 element circular
buffer to sort the timestamps. PTAL.

On Wed, Nov 22, 2017 at 4:43 AM, Michael Niedermayer  wrote:

> On Wed, Nov 22, 2017 at 01:21:45PM +0530, Sasi Inguva wrote:
> > I was just shooting for a heuristic which works for most of the cases.
>
> I do not think a heuristic is a good idea. Its not very hard to
> compute this exactly. You just reorder using a 16 entry buffer and
> keep track of what the largest size was that was actually needed.
>
> Or a buffer that is increased in size whenever it would lead to
> out of order output
>
>
>
> [...]
>
> > I can build a better heuristic by finding the  frame with next min. PTS
> > after Pmin and computing the distance between that frame and Pmin.
> However
> > that will still fail for this example,
> >  0, 3, 5, 1, 4, 2 . The delay computed will be 2 (because 2 frames
> between
> > 0 and 1 ) but we need a buffer size of 3 .
> >
> > On Wed, Nov 22, 2017 at 8:29 AM, Michael Niedermayer
>  > > wrote:
> >
> > > On Mon, Nov 20, 2017 at 08:27:05PM -0800, Sasi Inguva wrote:
> > > > Signed-off-by: Sasi Inguva 
> > > > ---
> > > >  libavformat/mov.c| 50 ++
> > > ++
> > > >  tests/fate/mov.mak   |  7 ++
> > > >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> > > >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> > > >  tests/ref/fate/mov-guess-delay-3 |  3 +++
> > > >  5 files changed, 66 insertions(+)
> > > >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> > > >  create mode 100644 tests/ref/fate/mov-guess-delay-2
> > > >  create mode 100644 tests/ref/fate/mov-guess-delay-3
> > > >
> > > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > > index fd170baa57..afb0d4ca5c 100644
> > > > --- a/libavformat/mov.c
> > > > +++ b/libavformat/mov.c
> > > > @@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts**
> > > ctts_data, unsigned int* ctts_count, uns
> > > >  return *ctts_count;
> > > >  }
> > > >
> > > > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> > > > +MOVStreamContext *msc = st->priv_data;
> > > > +int ind;
> > > > +int ctts_ind = 0;
> > > > +int ctts_sample = 0;
> > > > +int64_t curr_pts = AV_NOPTS_VALUE;
> > > > +int64_t min_prev_pts = AV_NOPTS_VALUE;
> > > > +int64_t prev_max_pts = AV_NOPTS_VALUE;
> > > > +int num_steps = 0;
> > > > +
> > > > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> > > > +st->codecpar->codec_id == AV_CODEC_ID_H264) {
> > > > +st->codecpar->video_delay = 0;
> > > > +for(ind = 0; ind < st->nb_index_entries && ctts_ind <
> > > msc->ctts_count; ++ind) {
> > > > +curr_pts = st->index_entries[ind].timestamp +
> > > msc->ctts_data[ctts_ind].duration;
> > > > +
> > > > +// Everytime we encounter a new max_pts we reset
> num_steps
> > > and compute again.
> > > > +if (curr_pts > prev_max_pts) {
> > > > +st->codecpar->video_delay =
> FFMIN(FFMAX(st->codecpar->video_delay,
> > > num_steps), 16);
> > > > +num_steps = 0;
> > > > +prev_max_pts = curr_pts;
> > > > +min_prev_pts = curr_pts;
> > > > +} else {
> > > > +// Compute delay as the length of the path from max
> PTS
> > > to min PTS.
> > > > +// Frames: I0 I1 B0 B1 B2
> > > > +// PTS: 0  4  1  2  3 -> num_steps = delay = 1
> > > (4->1)
> > > > +//
> > > > +// Frames: I0 I1 B1 B0 B2
> > > > +// PTS: 0  4  2  1  3 -> num_steps = delay = 2
> > > (4->2, 2->1)
> > > > +if (min_prev_pts != AV_NOPTS_VALUE) {
> > > > +if (curr_pts < min_prev_pts) {
> > > > +++num_steps;
> > > > +min_prev_pts = curr_pts;
> > > > +}
> > > > +}
> > > > +}
> > >
> > > Can you explain why this algorithm is correct ?
> > > (iam asking as i suspect it is not correct, but i may be wrong)
> > >
> > > What this should do is find the minimum buffer size to sort the stream
> > > of frame timestamps.
> > >
> > >
> > > [...]
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >
> > > Its not that you shouldnt use gotos but rather that you should write
> > > readable code and code with gotos often but not always is less readable
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-22 Thread Michael Niedermayer

On Wed, Nov 22, 2017 at 01:21:45PM +0530, Sasi Inguva wrote:
> I was just shooting for a heuristic which works for most of the cases.

I do not think a heuristic is a good idea. Its not very hard to
compute this exactly. You just reorder using a 16 entry buffer and
keep track of what the largest size was that was actually needed.

Or a buffer that is increased in size whenever it would lead to
out of order output



[...]

> I can build a better heuristic by finding the  frame with next min. PTS
> after Pmin and computing the distance between that frame and Pmin.  However
> that will still fail for this example,
>  0, 3, 5, 1, 4, 2 . The delay computed will be 2 (because 2 frames between
> 0 and 1 ) but we need a buffer size of 3 .
> 
> On Wed, Nov 22, 2017 at 8:29 AM, Michael Niedermayer  > wrote:
> 
> > On Mon, Nov 20, 2017 at 08:27:05PM -0800, Sasi Inguva wrote:
> > > Signed-off-by: Sasi Inguva 
> > > ---
> > >  libavformat/mov.c| 50 ++
> > ++
> > >  tests/fate/mov.mak   |  7 ++
> > >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> > >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> > >  tests/ref/fate/mov-guess-delay-3 |  3 +++
> > >  5 files changed, 66 insertions(+)
> > >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> > >  create mode 100644 tests/ref/fate/mov-guess-delay-2
> > >  create mode 100644 tests/ref/fate/mov-guess-delay-3
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index fd170baa57..afb0d4ca5c 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts**
> > ctts_data, unsigned int* ctts_count, uns
> > >  return *ctts_count;
> > >  }
> > >
> > > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> > > +MOVStreamContext *msc = st->priv_data;
> > > +int ind;
> > > +int ctts_ind = 0;
> > > +int ctts_sample = 0;
> > > +int64_t curr_pts = AV_NOPTS_VALUE;
> > > +int64_t min_prev_pts = AV_NOPTS_VALUE;
> > > +int64_t prev_max_pts = AV_NOPTS_VALUE;
> > > +int num_steps = 0;
> > > +
> > > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> > > +st->codecpar->codec_id == AV_CODEC_ID_H264) {
> > > +st->codecpar->video_delay = 0;
> > > +for(ind = 0; ind < st->nb_index_entries && ctts_ind <
> > msc->ctts_count; ++ind) {
> > > +curr_pts = st->index_entries[ind].timestamp +
> > msc->ctts_data[ctts_ind].duration;
> > > +
> > > +// Everytime we encounter a new max_pts we reset num_steps
> > and compute again.
> > > +if (curr_pts > prev_max_pts) {
> > > +st->codecpar->video_delay = 
> > > FFMIN(FFMAX(st->codecpar->video_delay,
> > num_steps), 16);
> > > +num_steps = 0;
> > > +prev_max_pts = curr_pts;
> > > +min_prev_pts = curr_pts;
> > > +} else {
> > > +// Compute delay as the length of the path from max PTS
> > to min PTS.
> > > +// Frames: I0 I1 B0 B1 B2
> > > +// PTS: 0  4  1  2  3 -> num_steps = delay = 1
> > (4->1)
> > > +//
> > > +// Frames: I0 I1 B1 B0 B2
> > > +// PTS: 0  4  2  1  3 -> num_steps = delay = 2
> > (4->2, 2->1)
> > > +if (min_prev_pts != AV_NOPTS_VALUE) {
> > > +if (curr_pts < min_prev_pts) {
> > > +++num_steps;
> > > +min_prev_pts = curr_pts;
> > > +}
> > > +}
> > > +}
> >
> > Can you explain why this algorithm is correct ?
> > (iam asking as i suspect it is not correct, but i may be wrong)
> >
> > What this should do is find the minimum buffer size to sort the stream
> > of frame timestamps.
> >
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Its not that you shouldnt use gotos but rather that you should write
> > readable code and code with gotos often but not always is less readable
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-22 Thread Sasi Inguva

I was just shooting for a heuristic which works for most of the cases.
Most GOP structures are like this in decoding order
PTS:  Pmin ,  Pmax , (Pmin + k) , (Pmin + k -1) ... (Pmin + 1)
,  (Pmin + 2k) , (Pmin + 2k -1) ... (Pmin + k + 1)  (Pmax + 1)
PICT_TYPE: I0 I1   Bk   Bk-1
B0  B2k B2k-1  Bk+1
   I2

The min. buffer size is actually the number of frames that came in between
Pmin and Pmin + 1 ,since the buffer should be able to hold all those frames
(and sort them) , before Pmin + 1 comes along and is output. So here, the
buffer size is "k".

The algo computes the number of decreasing steps from Pmax ->  (Pmin + 1)
=  k . Hence the algo works for this case.

However I realize now that my algo will break,
when Pmin and Pmax are not adjacent
Pmin , *(Pmin + k -1)* , Pmax , (Pmin + k) ,  ... (Pmin + 1) , ...   - The
buffer size is still k but the algo will compute as (k - 1) . e.g.  0, 2,
4, 1, 3

or the path from Pmax -> (Pmin + 1) not strictly decreasing .
Pmin ,  Pmax , (Pmin + k) , (Pmin + k -1), *(Pmin + k +1)*   ... (Pmin +
1)  - The buffer size is now (k + 1) but the algo will still compute as  k
e.g. 0, 4, 2, 3, 1

I can build a better heuristic by finding the  frame with next min. PTS
after Pmin and computing the distance between that frame and Pmin.  However
that will still fail for this example,
 0, 3, 5, 1, 4, 2 . The delay computed will be 2 (because 2 frames between
0 and 1 ) but we need a buffer size of 3 .

On Wed, Nov 22, 2017 at 8:29 AM, Michael Niedermayer  wrote:

> On Mon, Nov 20, 2017 at 08:27:05PM -0800, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/mov.c| 50 ++
> ++
> >  tests/fate/mov.mak   |  7 ++
> >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> >  tests/ref/fate/mov-guess-delay-3 |  3 +++
> >  5 files changed, 66 insertions(+)
> >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> >  create mode 100644 tests/ref/fate/mov-guess-delay-2
> >  create mode 100644 tests/ref/fate/mov-guess-delay-3
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index fd170baa57..afb0d4ca5c 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts**
> ctts_data, unsigned int* ctts_count, uns
> >  return *ctts_count;
> >  }
> >
> > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> > +MOVStreamContext *msc = st->priv_data;
> > +int ind;
> > +int ctts_ind = 0;
> > +int ctts_sample = 0;
> > +int64_t curr_pts = AV_NOPTS_VALUE;
> > +int64_t min_prev_pts = AV_NOPTS_VALUE;
> > +int64_t prev_max_pts = AV_NOPTS_VALUE;
> > +int num_steps = 0;
> > +
> > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> > +st->codecpar->codec_id == AV_CODEC_ID_H264) {
> > +st->codecpar->video_delay = 0;
> > +for(ind = 0; ind < st->nb_index_entries && ctts_ind <
> msc->ctts_count; ++ind) {
> > +curr_pts = st->index_entries[ind].timestamp +
> msc->ctts_data[ctts_ind].duration;
> > +
> > +// Everytime we encounter a new max_pts we reset num_steps
> and compute again.
> > +if (curr_pts > prev_max_pts) {
> > +st->codecpar->video_delay = 
> > FFMIN(FFMAX(st->codecpar->video_delay,
> num_steps), 16);
> > +num_steps = 0;
> > +prev_max_pts = curr_pts;
> > +min_prev_pts = curr_pts;
> > +} else {
> > +// Compute delay as the length of the path from max PTS
> to min PTS.
> > +// Frames: I0 I1 B0 B1 B2
> > +// PTS: 0  4  1  2  3 -> num_steps = delay = 1
> (4->1)
> > +//
> > +// Frames: I0 I1 B1 B0 B2
> > +// PTS: 0  4  2  1  3 -> num_steps = delay = 2
> (4->2, 2->1)
> > +if (min_prev_pts != AV_NOPTS_VALUE) {
> > +if (curr_pts < min_prev_pts) {
> > +++num_steps;
> > +min_prev_pts = curr_pts;
> > +}
> > +}
> > +}
>
> Can you explain why this algorithm is correct ?
> (iam asking as i suspect it is not correct, but i may be wrong)
>
> What this should do is find the minimum buffer size to sort the stream
> of frame timestamps.
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Its not that you shouldnt use gotos but rather that you should write
> readable code and code with gotos often but not always is less readable
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-21 Thread Michael Niedermayer

On Mon, Nov 20, 2017 at 08:27:05PM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 50 
> 
>  tests/fate/mov.mak   |  7 ++
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  tests/ref/fate/mov-guess-delay-3 |  3 +++
>  5 files changed, 66 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2
>  create mode 100644 tests/ref/fate/mov-guess-delay-3
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index fd170baa57..afb0d4ca5c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
> unsigned int* ctts_count, uns
>  return *ctts_count;
>  }
>  
> +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> +MOVStreamContext *msc = st->priv_data;
> +int ind;
> +int ctts_ind = 0;
> +int ctts_sample = 0;
> +int64_t curr_pts = AV_NOPTS_VALUE;
> +int64_t min_prev_pts = AV_NOPTS_VALUE;
> +int64_t prev_max_pts = AV_NOPTS_VALUE;
> +int num_steps = 0;
> +
> +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> +st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +st->codecpar->video_delay = 0;
> +for(ind = 0; ind < st->nb_index_entries && ctts_ind < 
> msc->ctts_count; ++ind) {
> +curr_pts = st->index_entries[ind].timestamp + 
> msc->ctts_data[ctts_ind].duration;
> +
> +// Everytime we encounter a new max_pts we reset num_steps and 
> compute again.
> +if (curr_pts > prev_max_pts) {
> +st->codecpar->video_delay = 
> FFMIN(FFMAX(st->codecpar->video_delay, num_steps), 16);
> +num_steps = 0;
> +prev_max_pts = curr_pts;
> +min_prev_pts = curr_pts;
> +} else {
> +// Compute delay as the length of the path from max PTS to 
> min PTS.
> +// Frames: I0 I1 B0 B1 B2
> +// PTS: 0  4  1  2  3 -> num_steps = delay = 1 (4->1)
> +//
> +// Frames: I0 I1 B1 B0 B2
> +// PTS: 0  4  2  1  3 -> num_steps = delay = 2 (4->2, 
> 2->1)
> +if (min_prev_pts != AV_NOPTS_VALUE) {
> +if (curr_pts < min_prev_pts) {
> +++num_steps;
> +min_prev_pts = curr_pts;
> +}
> +}
> +}

Can you explain why this algorithm is correct ?
(iam asking as i suspect it is not correct, but i may be wrong)

What this should do is find the minimum buffer size to sort the stream
of frame timestamps.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-21 Thread Michael Niedermayer

On Tue, Nov 21, 2017 at 09:59:08AM +0530, Sasi Inguva wrote:
> Reattaching Fate sample.

uploaded

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 50 
 tests/fate/mov.mak   |  7 ++
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 tests/ref/fate/mov-guess-delay-3 |  3 +++
 5 files changed, 66 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2
 create mode 100644 tests/ref/fate/mov-guess-delay-3

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..afb0d4ca5c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t min_prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_steps = 0;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+st->codecpar->codec_id == AV_CODEC_ID_H264) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// Everytime we encounter a new max_pts we reset num_steps and 
compute again.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = 
FFMIN(FFMAX(st->codecpar->video_delay, num_steps), 16);
+num_steps = 0;
+prev_max_pts = curr_pts;
+min_prev_pts = curr_pts;
+} else {
+// Compute delay as the length of the path from max PTS to min 
PTS.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_steps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_steps = delay = 2 (4->2, 2->1)
+if (min_prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < min_prev_pts) {
+++num_steps;
+min_prev_pts = curr_pts;
+}
+}
+}
+
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3894,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..6e79f0aba8 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,9 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
+   fate-mov-guess-delay-3 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +75,7 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
+fate-mov-guess-delay-3: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_4bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=1
+[/STREAM]
diff --git a/tests/ref/fate/mov-guess-delay-2 b/tests/ref/fate/mov-guess-delay-2
new file mode 100644
index 00..248de1c3ea
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-2
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=2
+[/STREAM]

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Sasi Inguva

Reattaching Fate sample.


On Tue, Nov 21, 2017 at 9:57 AM, Sasi Inguva  wrote:

> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 50 ++
> ++
>  tests/fate/mov.mak   |  7 ++
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  tests/ref/fate/mov-guess-delay-3 |  3 +++
>  5 files changed, 66 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2
>  create mode 100644 tests/ref/fate/mov-guess-delay-3
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index fd170baa57..afb0d4ca5c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts** ctts_data,
> unsigned int* ctts_count, uns
>  return *ctts_count;
>  }
>
> +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> +MOVStreamContext *msc = st->priv_data;
> +int ind;
> +int ctts_ind = 0;
> +int ctts_sample = 0;
> +int64_t curr_pts = AV_NOPTS_VALUE;
> +int64_t min_prev_pts = AV_NOPTS_VALUE;
> +int64_t prev_max_pts = AV_NOPTS_VALUE;
> +int num_steps = 0;
> +
> +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> +st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +st->codecpar->video_delay = 0;
> +for(ind = 0; ind < st->nb_index_entries && ctts_ind <
> msc->ctts_count; ++ind) {
> +curr_pts = st->index_entries[ind].timestamp +
> msc->ctts_data[ctts_ind].duration;
> +
> +// Everytime we encounter a new max_pts we reset num_steps
> and compute again.
> +if (curr_pts > prev_max_pts) {
> +st->codecpar->video_delay = 
> FFMIN(FFMAX(st->codecpar->video_delay,
> num_steps), 16);
> +num_steps = 0;
> +prev_max_pts = curr_pts;
> +min_prev_pts = curr_pts;
> +} else {
> +// Compute delay as the length of the path from max PTS
> to min PTS.
> +// Frames: I0 I1 B0 B1 B2
> +// PTS: 0  4  1  2  3 -> num_steps = delay = 1 (4->1)
> +//
> +// Frames: I0 I1 B1 B0 B2
> +// PTS: 0  4  2  1  3 -> num_steps = delay = 2 (4->2,
> 2->1)
> +if (min_prev_pts != AV_NOPTS_VALUE) {
> +if (curr_pts < min_prev_pts) {
> +++num_steps;
> +min_prev_pts = curr_pts;
> +}
> +}
> +}
> +
> +ctts_sample++;
> +if (ctts_sample == msc->ctts_data[ctts_ind].count) {
> +ctts_ind++;
> +ctts_sample = 0;
> +}
> +}
> +av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for
> stream st: %d\n",
> +   st->codecpar->video_delay, st->index);
> +}
> +}
> +
>  static void mov_current_sample_inc(MOVStreamContext *sc)
>  {
>  sc->current_sample++;
> @@ -3846,6 +3894,8 @@ static void mov_build_index(MOVContext *mov,
> AVStream *st)
>  // Fix index according to edit lists.
>  mov_fix_index(mov, st);
>  }
> +
> +mov_guess_video_delay(mov, st);
>  }
>
>  static int test_same_origin(const char *src, const char *ref) {
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index 76f66ff498..6e79f0aba8 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -11,6 +11,9 @@ FATE_MOV = fate-mov-3elist \
> fate-mov-440hz-10ms \
> fate-mov-ibi-elst-starts-b \
> fate-mov-elst-ends-betn-b-and-i \
> +   fate-mov-guess-delay-1 \
> +   fate-mov-guess-delay-2 \
> +   fate-mov-guess-delay-3 \
>
>  FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
> fate-mov-zombie \
> @@ -72,3 +75,7 @@ fate-mov-spherical-mono: CMD = run
> ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
>  fate-mov-gpmf-remux: CMD = md5 -i 
> $(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4
> -map 0 -c copy -fflags +bitexact -f mp4
>  fate-mov-gpmf-remux: CMP = oneline
>  fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
> +
> +fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=has_b_frames -select_streams v
> $(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
> +fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=has_b_frames -select_streams v
> $(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
> +fate-mov-guess-delay-3: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=has_b_frames -select_streams v
> $(TARGET_SAMPLES)/h264/h264_4bf_pyramid_nobsrestriction.mp4
> \ No newline at end of file
> diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-
> delay-1
> new file mode 100644
> index 00..96cb67be0c
> ---

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Sasi Inguva

Ok. Just restricting this to H264 .

On Tue, Nov 21, 2017 at 3:56 AM, Hendrik Leppkes 
wrote:

> On Mon, Nov 20, 2017 at 11:06 PM, Michael Niedermayer
>  wrote:
> > On Mon, Nov 20, 2017 at 09:58:05PM +0530, Sasi Inguva wrote:
> >> On Sun, Nov 19, 2017 at 1:17 AM, Michael Niedermayer
>  >> > wrote:
> >>
> >> > On Sat, Nov 18, 2017 at 11:12:17AM -0800, Sasi Inguva wrote:
> >> > > Signed-off-by: Sasi Inguva 
> >> > > ---
> >> > >  libavformat/mov.c| 54
> ++
> >> > ++
> >> > >  tests/fate/mov.mak   |  5 
> >> > >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> >> > >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> >> > >  4 files changed, 65 insertions(+)
> >> > >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> >> > >  create mode 100644 tests/ref/fate/mov-guess-delay-2
> >> > >
> >> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> > > index fd170baa57..7354652c6e 100644
> >> > > --- a/libavformat/mov.c
> >> > > +++ b/libavformat/mov.c
> >> > > @@ -3213,6 +3213,58 @@ static int64_t add_ctts_entry(MOVStts**
> >> > ctts_data, unsigned int* ctts_count, uns
> >> > >  return *ctts_count;
> >> > >  }
> >> > >
> >> > > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> >> > > +MOVStreamContext *msc = st->priv_data;
> >> > > +int ind;
> >> > > +int ctts_ind = 0;
> >> > > +int ctts_sample = 0;
> >> > > +int64_t curr_pts = AV_NOPTS_VALUE;
> >> > > +int64_t prev_pts = AV_NOPTS_VALUE;
> >> > > +int64_t prev_max_pts = AV_NOPTS_VALUE;
> >> > > +int num_swaps = 0;
> >> > > +
> >> > > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> >> > > +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
> >> > > + st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
> >> > > + st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
> >> > > + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
> >> > > + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> >> > > + st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
> >> >
> >> > Do all these cases really need this ?
> >> >
> >> > I just wanted to list all codecs with B-frames. H264, HEVC need it in
> >> case, the bitstream_restriction_flag is not set in the bitstream. Other
> >> codecs might need it only if the bitstream has been written incorrectly
> >> i.e. writing 0 for the delay bit when there are B-frames etc. I can
> >> restrict to H264 , HEVC if needed.
> >
> > yes, please restrict this.
> > I very much doubt that the mov/mp4 demuxer has more correct data
> > about the codec than the codec itself when such data is needed to
> > decode and cannot be ommited.
> >
> > I kind of find it a poor design choice that this can be ommited in
> > h264 & hevc, but theres nothing we can do about this
> >
>
> I don't belive hevc needs this value to be set, our decoder certainly
> doesn't. It seems to fill it straight from the SPS, without conditions
> (and the decoding logic never actually reads it).
> Our h264 decoder is the only one that actually needs this value to not
> drop frames, most other decoders just set it (potentially for the
> generic timestamp stuff?)
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Hendrik Leppkes

On Mon, Nov 20, 2017 at 11:06 PM, Michael Niedermayer
 wrote:
> On Mon, Nov 20, 2017 at 09:58:05PM +0530, Sasi Inguva wrote:
>> On Sun, Nov 19, 2017 at 1:17 AM, Michael Niedermayer > > wrote:
>>
>> > On Sat, Nov 18, 2017 at 11:12:17AM -0800, Sasi Inguva wrote:
>> > > Signed-off-by: Sasi Inguva 
>> > > ---
>> > >  libavformat/mov.c| 54 ++
>> > ++
>> > >  tests/fate/mov.mak   |  5 
>> > >  tests/ref/fate/mov-guess-delay-1 |  3 +++
>> > >  tests/ref/fate/mov-guess-delay-2 |  3 +++
>> > >  4 files changed, 65 insertions(+)
>> > >  create mode 100644 tests/ref/fate/mov-guess-delay-1
>> > >  create mode 100644 tests/ref/fate/mov-guess-delay-2
>> > >
>> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
>> > > index fd170baa57..7354652c6e 100644
>> > > --- a/libavformat/mov.c
>> > > +++ b/libavformat/mov.c
>> > > @@ -3213,6 +3213,58 @@ static int64_t add_ctts_entry(MOVStts**
>> > ctts_data, unsigned int* ctts_count, uns
>> > >  return *ctts_count;
>> > >  }
>> > >
>> > > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
>> > > +MOVStreamContext *msc = st->priv_data;
>> > > +int ind;
>> > > +int ctts_ind = 0;
>> > > +int ctts_sample = 0;
>> > > +int64_t curr_pts = AV_NOPTS_VALUE;
>> > > +int64_t prev_pts = AV_NOPTS_VALUE;
>> > > +int64_t prev_max_pts = AV_NOPTS_VALUE;
>> > > +int num_swaps = 0;
>> > > +
>> > > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
>> > > +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
>> > > + st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
>> > > + st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
>> > > + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
>> > > + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
>> > > + st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
>> >
>> > Do all these cases really need this ?
>> >
>> > I just wanted to list all codecs with B-frames. H264, HEVC need it in
>> case, the bitstream_restriction_flag is not set in the bitstream. Other
>> codecs might need it only if the bitstream has been written incorrectly
>> i.e. writing 0 for the delay bit when there are B-frames etc. I can
>> restrict to H264 , HEVC if needed.
>
> yes, please restrict this.
> I very much doubt that the mov/mp4 demuxer has more correct data
> about the codec than the codec itself when such data is needed to
> decode and cannot be ommited.
>
> I kind of find it a poor design choice that this can be ommited in
> h264 & hevc, but theres nothing we can do about this
>

I don't belive hevc needs this value to be set, our decoder certainly
doesn't. It seems to fill it straight from the SPS, without conditions
(and the decoding logic never actually reads it).
Our h264 decoder is the only one that actually needs this value to not
drop frames, most other decoders just set it (potentially for the
generic timestamp stuff?)

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Michael Niedermayer

On Mon, Nov 20, 2017 at 09:58:05PM +0530, Sasi Inguva wrote:
> On Sun, Nov 19, 2017 at 1:17 AM, Michael Niedermayer  > wrote:
> 
> > On Sat, Nov 18, 2017 at 11:12:17AM -0800, Sasi Inguva wrote:
> > > Signed-off-by: Sasi Inguva 
> > > ---
> > >  libavformat/mov.c| 54 ++
> > ++
> > >  tests/fate/mov.mak   |  5 
> > >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> > >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> > >  4 files changed, 65 insertions(+)
> > >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> > >  create mode 100644 tests/ref/fate/mov-guess-delay-2
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index fd170baa57..7354652c6e 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -3213,6 +3213,58 @@ static int64_t add_ctts_entry(MOVStts**
> > ctts_data, unsigned int* ctts_count, uns
> > >  return *ctts_count;
> > >  }
> > >
> > > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> > > +MOVStreamContext *msc = st->priv_data;
> > > +int ind;
> > > +int ctts_ind = 0;
> > > +int ctts_sample = 0;
> > > +int64_t curr_pts = AV_NOPTS_VALUE;
> > > +int64_t prev_pts = AV_NOPTS_VALUE;
> > > +int64_t prev_max_pts = AV_NOPTS_VALUE;
> > > +int num_swaps = 0;
> > > +
> > > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> > > +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
> > > + st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
> > > + st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
> > > + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
> > > + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> > > + st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
> >
> > Do all these cases really need this ?
> >
> > I just wanted to list all codecs with B-frames. H264, HEVC need it in
> case, the bitstream_restriction_flag is not set in the bitstream. Other
> codecs might need it only if the bitstream has been written incorrectly
> i.e. writing 0 for the delay bit when there are B-frames etc. I can
> restrict to H264 , HEVC if needed.

yes, please restrict this.
I very much doubt that the mov/mp4 demuxer has more correct data
about the codec than the codec itself when such data is needed to
decode and cannot be ommited.

I kind of find it a poor design choice that this can be ommited in
h264 & hevc, but theres nothing we can do about this



[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Sasi Inguva

Attaching the fate sample

On Mon, Nov 20, 2017 at 8:28 AM, Sasi Inguva  wrote:

> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 55 ++
> ++
>  tests/fate/mov.mak   |  7 +
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  tests/ref/fate/mov-guess-delay-3 |  3 +++
>  5 files changed, 71 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2
>  create mode 100644 tests/ref/fate/mov-guess-delay-3
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index fd170baa57..d1bd0c4f29 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3213,6 +3213,59 @@ static int64_t add_ctts_entry(MOVStts** ctts_data,
> unsigned int* ctts_count, uns
>  return *ctts_count;
>  }
>
> +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> +MOVStreamContext *msc = st->priv_data;
> +int ind;
> +int ctts_ind = 0;
> +int ctts_sample = 0;
> +int64_t curr_pts = AV_NOPTS_VALUE;
> +int64_t min_prev_pts = AV_NOPTS_VALUE;
> +int64_t prev_max_pts = AV_NOPTS_VALUE;
> +int num_steps = 0;
> +
> +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
> + st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
> + st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
> + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
> + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> + st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
> +st->codecpar->video_delay = 0;
> +for(ind = 0; ind < st->nb_index_entries && ctts_ind <
> msc->ctts_count; ++ind) {
> +curr_pts = st->index_entries[ind].timestamp +
> msc->ctts_data[ctts_ind].duration;
> +
> +// Everytime we encounter a new max_pts we reset num_steps
> and compute again.
> +if (curr_pts > prev_max_pts) {
> +st->codecpar->video_delay = 
> FFMIN(FFMAX(st->codecpar->video_delay,
> num_steps), 16);
> +num_steps = 0;
> +prev_max_pts = curr_pts;
> +min_prev_pts = curr_pts;
> +} else {
> +// Compute delay as the length of the path from max PTS
> to min PTS.
> +// Frames: I0 I1 B0 B1 B2
> +// PTS: 0  4  1  2  3 -> num_steps = delay = 1 (4->1)
> +//
> +// Frames: I0 I1 B1 B0 B2
> +// PTS: 0  4  2  1  3 -> num_steps = delay = 2 (4->2,
> 2->1)
> +if (min_prev_pts != AV_NOPTS_VALUE) {
> +if (curr_pts < min_prev_pts) {
> +++num_steps;
> +min_prev_pts = curr_pts;
> +}
> +}
> +}
> +
> +ctts_sample++;
> +if (ctts_sample == msc->ctts_data[ctts_ind].count) {
> +ctts_ind++;
> +ctts_sample = 0;
> +}
> +}
> +av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for
> stream st: %d\n",
> +   st->codecpar->video_delay, st->index);
> +}
> +}
> +
>  static void mov_current_sample_inc(MOVStreamContext *sc)
>  {
>  sc->current_sample++;
> @@ -3846,6 +3899,8 @@ static void mov_build_index(MOVContext *mov,
> AVStream *st)
>  // Fix index according to edit lists.
>  mov_fix_index(mov, st);
>  }
> +
> +mov_guess_video_delay(mov, st);
>  }
>
>  static int test_same_origin(const char *src, const char *ref) {
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index 76f66ff498..6e79f0aba8 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -11,6 +11,9 @@ FATE_MOV = fate-mov-3elist \
> fate-mov-440hz-10ms \
> fate-mov-ibi-elst-starts-b \
> fate-mov-elst-ends-betn-b-and-i \
> +   fate-mov-guess-delay-1 \
> +   fate-mov-guess-delay-2 \
> +   fate-mov-guess-delay-3 \
>
>  FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
> fate-mov-zombie \
> @@ -72,3 +75,7 @@ fate-mov-spherical-mono: CMD = run
> ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
>  fate-mov-gpmf-remux: CMD = md5 -i 
> $(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4
> -map 0 -c copy -fflags +bitexact -f mp4
>  fate-mov-gpmf-remux: CMP = oneline
>  fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
> +
> +fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=has_b_frames -select_streams v
> $(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
> +fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=has_b_frames -select_streams v
> $(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
> +fate-mov-guess-delay-3: CMD = run ffprobe$(PROGSSUF)$(EXESUF)

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 55 
 tests/fate/mov.mak   |  7 +
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 tests/ref/fate/mov-guess-delay-3 |  3 +++
 5 files changed, 71 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2
 create mode 100644 tests/ref/fate/mov-guess-delay-3

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..d1bd0c4f29 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,59 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t min_prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_steps = 0;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
+ st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
+ st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H263 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+ st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// Everytime we encounter a new max_pts we reset num_steps and 
compute again.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = 
FFMIN(FFMAX(st->codecpar->video_delay, num_steps), 16);
+num_steps = 0;
+prev_max_pts = curr_pts;
+min_prev_pts = curr_pts;
+} else {
+// Compute delay as the length of the path from max PTS to min 
PTS.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_steps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_steps = delay = 2 (4->2, 2->1)
+if (min_prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < min_prev_pts) {
+++num_steps;
+min_prev_pts = curr_pts;
+}
+}
+}
+
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3899,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..6e79f0aba8 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,9 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
+   fate-mov-guess-delay-3 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +75,7 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
+fate-mov-guess-delay-3: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_4bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-20 Thread Sasi Inguva

On Sun, Nov 19, 2017 at 1:17 AM, Michael Niedermayer  wrote:

> On Sat, Nov 18, 2017 at 11:12:17AM -0800, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/mov.c| 54 ++
> ++
> >  tests/fate/mov.mak   |  5 
> >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> >  4 files changed, 65 insertions(+)
> >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> >  create mode 100644 tests/ref/fate/mov-guess-delay-2
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index fd170baa57..7354652c6e 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3213,6 +3213,58 @@ static int64_t add_ctts_entry(MOVStts**
> ctts_data, unsigned int* ctts_count, uns
> >  return *ctts_count;
> >  }
> >
> > +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> > +MOVStreamContext *msc = st->priv_data;
> > +int ind;
> > +int ctts_ind = 0;
> > +int ctts_sample = 0;
> > +int64_t curr_pts = AV_NOPTS_VALUE;
> > +int64_t prev_pts = AV_NOPTS_VALUE;
> > +int64_t prev_max_pts = AV_NOPTS_VALUE;
> > +int num_swaps = 0;
> > +
> > +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> > +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
> > + st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
> > + st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
> > + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
> > + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> > + st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
>
> Do all these cases really need this ?
>
> I just wanted to list all codecs with B-frames. H264, HEVC need it in
case, the bitstream_restriction_flag is not set in the bitstream. Other
codecs might need it only if the bitstream has been written incorrectly
i.e. writing 0 for the delay bit when there are B-frames etc. I can
restrict to H264 , HEVC if needed.

video_delay = 0 is also a valid value so it can be set to 0 already

intentionally
>
> I just want to avoid the case where the code incorrectly estimates a
video_delay that is lesser than what is written in the bitstream, because
that would be a fatal error resulting in incorrect timestamps. The other
case where the code estimates non-zero video_delay when it is zero in the
bitstream is benign.

>
> > +st->codecpar->video_delay = 0;
> > +for(ind = 0; ind < st->nb_index_entries && ctts_ind <
> msc->ctts_count; ++ind) {
> > +curr_pts = st->index_entries[ind].timestamp +
> msc->ctts_data[ctts_ind].duration;
> > +
>
> > +// This is used as an indication that the previous GOP has
> ended and a
> > +// new GOP has started.
>
> this is not neccesary a GOP uless i misread the code
>
> Corrected the comment.

>
> > +if (curr_pts > prev_max_pts) {
> > +st->codecpar->video_delay = 
> > FFMIN(FFMAX(st->codecpar->video_delay,
> num_swaps), 16);
> > +num_swaps = 0;
> > +prev_max_pts = curr_pts;
> > +}
> > +
> > +// Compute delay as the no. of "drop"s in PTS inside a GOP.
> > +// Frames: I0 I1 B0 B1 B2
> > +// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
> > +//
> > +// Frames: I0 I1 B1 B0 B2
> > +// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2,
> 2->1)
>
> This may be incorret
>
> consider
> PTS0  5  2  1  4  3
> BUFFER 0  05 25 25 45 45 5
> OUT  0  1  2  3  4  5
>
> So this is a delay = 2 but your code would set 3 i think
>
> True. Thanks for catching it. The issue will only get worse, with more no.
of B-frames in-between ( 0 7 2 1 4 3 6 4 -> would have delay 4 ) . I have
changed the code to estimate the delay as the length of the patch from max.
PTS to min. PTS . (So only 5->2->1 will be counted). Sending the new
patch.  PTAL. Thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-18 Thread Michael Niedermayer

On Sat, Nov 18, 2017 at 11:12:17AM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 54 
> 
>  tests/fate/mov.mak   |  5 
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  4 files changed, 65 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index fd170baa57..7354652c6e 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3213,6 +3213,58 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
> unsigned int* ctts_count, uns
>  return *ctts_count;
>  }
>  
> +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> +MOVStreamContext *msc = st->priv_data;
> +int ind;
> +int ctts_ind = 0;
> +int ctts_sample = 0;
> +int64_t curr_pts = AV_NOPTS_VALUE;
> +int64_t prev_pts = AV_NOPTS_VALUE;
> +int64_t prev_max_pts = AV_NOPTS_VALUE;
> +int num_swaps = 0;
> +
> +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
> + st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
> + st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
> + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
> + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> + st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {

Do all these cases really need this ?

video_delay = 0 is also a valid value so it can be set to 0 already
intentionally


> +st->codecpar->video_delay = 0;
> +for(ind = 0; ind < st->nb_index_entries && ctts_ind < 
> msc->ctts_count; ++ind) {
> +curr_pts = st->index_entries[ind].timestamp + 
> msc->ctts_data[ctts_ind].duration;
> +

> +// This is used as an indication that the previous GOP has ended 
> and a
> +// new GOP has started.

this is not neccesary a GOP uless i misread the code


> +if (curr_pts > prev_max_pts) {
> +st->codecpar->video_delay = 
> FFMIN(FFMAX(st->codecpar->video_delay, num_swaps), 16);
> +num_swaps = 0;
> +prev_max_pts = curr_pts;
> +}
> +
> +// Compute delay as the no. of "drop"s in PTS inside a GOP.
> +// Frames: I0 I1 B0 B1 B2
> +// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
> +//
> +// Frames: I0 I1 B1 B0 B2
> +// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2, 2->1)

This may be incorret

consider
PTS0  5  2  1  4  3
BUFFER 0  05 25 25 45 45 5
OUT  0  1  2  3  4  5

So this is a delay = 2 but your code would set 3 i think


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-18 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 54 
 tests/fate/mov.mak   |  5 
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 4 files changed, 65 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..7354652c6e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,58 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_swaps = 0;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
+ st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
+ st->codecpar->codec_id == AV_CODEC_ID_VC1 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H263 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+ st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// This is used as an indication that the previous GOP has ended 
and a
+// new GOP has started.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = 
FFMIN(FFMAX(st->codecpar->video_delay, num_swaps), 16);
+num_swaps = 0;
+prev_max_pts = curr_pts;
+}
+
+// Compute delay as the no. of "drop"s in PTS inside a GOP.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2, 2->1)
+if (prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < prev_pts)
+++num_swaps;
+}
+
+prev_pts = curr_pts;
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3898,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..ef89e62096 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +74,6 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=1
+[/STREAM]
diff --git a/tests/ref/fate/mov-guess-delay-2 b/tests/ref/fate/mov-guess-delay-2
new file mode 100644
index 00..248de1c3ea
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-2
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=2
+[/STREAM]
-- 
2.15.0.448.gf294e3d99a-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-18 Thread Sasi Inguva

Done. is there a better way to identify codecs that might need 
Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 52 
 tests/fate/mov.mak   |  5 
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 4 files changed, 63 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..687297be33 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,56 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_swaps = 0;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
+ st->codecpar->codec_id == AV_CODEC_ID_H263 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+ st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// This is used as an indication that the previous GOP has ended 
and a
+// new GOP has started.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = 
FFMIN(FFMAX(st->codecpar->video_delay, num_swaps), 16);
+num_swaps = 0;
+prev_max_pts = curr_pts;
+}
+
+// Compute delay as the no. of "drop"s in PTS inside a GOP.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2, 2->1)
+if (prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < prev_pts)
+++num_swaps;
+}
+
+prev_pts = curr_pts;
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3896,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..ef89e62096 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +74,6 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=1
+[/STREAM]
diff --git a/tests/ref/fate/mov-guess-delay-2 b/tests/ref/fate/mov-guess-delay-2
new file mode 100644
index 00..248de1c3ea
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-2
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=2
+[/STREAM]
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-18 Thread Carl Eugen Hoyos

2017-11-18 7:12 GMT+01:00 Sasi Inguva :

> +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> +(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
> + st->codecpar->codec_id == AV_CODEC_ID_H263 ||
> + st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> + st->codecpar->codec_id == AV_CODEC_ID_HEVC))

Sorry if I misunderstand but shouldn't this also include MPEG4 (and
VC1)?

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

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-17 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 52 
 tests/fate/mov.mak   |  5 
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 4 files changed, 63 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..687297be33 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,56 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_swaps = 0;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
+ st->codecpar->codec_id == AV_CODEC_ID_H263 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+ st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// This is used as an indication that the previous GOP has ended 
and a
+// new GOP has started.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = 
FFMIN(FFMAX(st->codecpar->video_delay, num_swaps), 16);
+num_swaps = 0;
+prev_max_pts = curr_pts;
+}
+
+// Compute delay as the no. of "drop"s in PTS inside a GOP.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2, 2->1)
+if (prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < prev_pts)
+++num_swaps;
+}
+
+prev_pts = curr_pts;
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3896,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..ef89e62096 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +74,6 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=1
+[/STREAM]
diff --git a/tests/ref/fate/mov-guess-delay-2 b/tests/ref/fate/mov-guess-delay-2
new file mode 100644
index 00..248de1c3ea
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-2
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=2
+[/STREAM]
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-17 Thread Sasi Inguva

restricted the patch to MPEG based codecs. Also, setting the delay only if
it's not set already and capping the max. value to 16.

On Wed, Nov 15, 2017 at 5:55 AM, Michael Niedermayer  wrote:

> On Tue, Nov 14, 2017 at 03:36:49PM -0800, Thierry Foucu wrote:
> > On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
> > derek.buitenh...@gmail.com> wrote:
> >
> > > On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > > > I don't know if the patch can be made more generic to work for all
> > > > demuxers, because this patch requires that PTS of all packets be
> > > available
> > > > in the header.  The other route is to make it very specific to codecs
> > > with
> > > > B-frames.
> > >
> > > All PTS may not be available in MP4 either, in the live profile
> fragmented
> > > MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> > > code
> > > say whether we seek to each fragment and make it available or not. I
> assume
> > > you've tested such a case, or can (or know the fragment code)?
> > >
> > > It's feasible to restrict it to codecs, I suppose.
> > >
> > > >> You do not appear to be restricting this to one specific codec, or
> even
> > > >> codecs
> > > >> with B-frames.
> > > >>
> > > >> I can make it specific to only H264 / H265.
> > >
> > > The GOP structure should be applicable to most MPEG codecs, I think.
> > >
> > > > It is true that the patch will fail to compute the correct delay in
> lots
> > > of
> > > > cases. However the consequence of wrongly computing the has_b_frames
> is
> > > > pretty benign. It only increases the buffer size held for PTS
> > > reordering.
> > > > I can put a max-value check on the computed video_delay here. So in
> my
> > > > opinion, we won't see fatal regressions where a file is not able to
> be
> > > > decoded / played.
> > >
> > > It's true it's likely benign, but it's not exactly a "fix" either...
> > >
> > > From a user perspective, it's kinda possible to work around it
> "properly"
> > > (I use that term loosely here) by decoding enough frames to fill the
> max
> > > DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> > > (or in a user's code if they don't use that function), isn't it?
> Though,
> > > I feel that particular fix won't be welcomed with open arms, due to a
> > > ~16x 'slow down' in probing.
> > >
> > >
> > One option i asked on IRC was to use the spec for max DPB when the
> bitstream
> > restriction flag was not set.
> > But people were worry about low latency usage.
> > Normally, if the  bitstream restriction flag is not set, the DPB should
> be
> > set based on the spec, even if there is no B frames.
> > But in some case, it will be 16 frame and this could increase then the
> low
> > latency.
>
> it could also increase memory requirements substantially
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Michael Niedermayer

On Tue, Nov 14, 2017 at 03:36:49PM -0800, Thierry Foucu wrote:
> On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
> 
> > On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > > I don't know if the patch can be made more generic to work for all
> > > demuxers, because this patch requires that PTS of all packets be
> > available
> > > in the header.  The other route is to make it very specific to codecs
> > with
> > > B-frames.
> >
> > All PTS may not be available in MP4 either, in the live profile fragmented
> > MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> > code
> > say whether we seek to each fragment and make it available or not. I assume
> > you've tested such a case, or can (or know the fragment code)?
> >
> > It's feasible to restrict it to codecs, I suppose.
> >
> > >> You do not appear to be restricting this to one specific codec, or even
> > >> codecs
> > >> with B-frames.
> > >>
> > >> I can make it specific to only H264 / H265.
> >
> > The GOP structure should be applicable to most MPEG codecs, I think.
> >
> > > It is true that the patch will fail to compute the correct delay in lots
> > of
> > > cases. However the consequence of wrongly computing the has_b_frames is
> > > pretty benign. It only increases the buffer size held for PTS
> > reordering.
> > > I can put a max-value check on the computed video_delay here. So in my
> > > opinion, we won't see fatal regressions where a file is not able to be
> > > decoded / played.
> >
> > It's true it's likely benign, but it's not exactly a "fix" either...
> >
> > From a user perspective, it's kinda possible to work around it "properly"
> > (I use that term loosely here) by decoding enough frames to fill the max
> > DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> > (or in a user's code if they don't use that function), isn't it? Though,
> > I feel that particular fix won't be welcomed with open arms, due to a
> > ~16x 'slow down' in probing.
> >
> >
> One option i asked on IRC was to use the spec for max DPB when the bitstream
> restriction flag was not set.
> But people were worry about low latency usage.
> Normally, if the  bitstream restriction flag is not set, the DPB should be
> set based on the spec, even if there is no B frames.
> But in some case, it will be 16 frame and this could increase then the low
> latency.

it could also increase memory requirements substantially


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Carl Eugen Hoyos

2017-11-15 0:36 GMT+01:00 Thierry Foucu :
> On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
>> On 11/14/2017 10:11 PM, Sasi Inguva wrote:
>> > I don't know if the patch can be made more generic to work for all
>> > demuxers, because this patch requires that PTS of all packets be
>> available
>> > in the header.  The other route is to make it very specific to codecs
>> with
>> > B-frames.
>>
>> All PTS may not be available in MP4 either, in the live profile fragmented
>> MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
>> code
>> say whether we seek to each fragment and make it available or not. I assume
>> you've tested such a case, or can (or know the fragment code)?
>>
>> It's feasible to restrict it to codecs, I suppose.
>>
>> >> You do not appear to be restricting this to one specific codec, or even
>> >> codecs
>> >> with B-frames.
>> >>
>> >> I can make it specific to only H264 / H265.
>>
>> The GOP structure should be applicable to most MPEG codecs, I think.
>>
>> > It is true that the patch will fail to compute the correct delay in lots
>> of
>> > cases. However the consequence of wrongly computing the has_b_frames is
>> > pretty benign. It only increases the buffer size held for PTS
>> reordering.
>> > I can put a max-value check on the computed video_delay here. So in my
>> > opinion, we won't see fatal regressions where a file is not able to be
>> > decoded / played.
>>
>> It's true it's likely benign, but it's not exactly a "fix" either...
>>
>> From a user perspective, it's kinda possible to work around it "properly"
>> (I use that term loosely here) by decoding enough frames to fill the max
>> DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
>> (or in a user's code if they don't use that function), isn't it? Though,
>> I feel that particular fix won't be welcomed with open arms, due to a
>> ~16x 'slow down' in probing.
>>
> One option i asked on IRC was to use the spec for max DPB when the
> bitstream restriction flag was not set.

I believe this should be done if the user had set -strict 1

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis

On 11/14/2017 11:36 PM, Thierry Foucu wrote:
> One option i asked on IRC was to use the spec for max DPB when the bitstream
> restriction flag was not set.
> But people were worry about low latency usage.
> Normally, if the  bitstream restriction flag is not set, the DPB should be
> set based on the spec, even if there is no B frames.
> But in some case, it will be 16 frame and this could increase then the low
> latency.

I guess that's a problem inherent to a generic API that tries to satisfy all
use cases - you can't please everyone.

I don't really have a /good/ solution given the use-case constraints, as
per previous email. :/

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Thierry Foucu

On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > I don't know if the patch can be made more generic to work for all
> > demuxers, because this patch requires that PTS of all packets be
> available
> > in the header.  The other route is to make it very specific to codecs
> with
> > B-frames.
>
> All PTS may not be available in MP4 either, in the live profile fragmented
> MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> code
> say whether we seek to each fragment and make it available or not. I assume
> you've tested such a case, or can (or know the fragment code)?
>
> It's feasible to restrict it to codecs, I suppose.
>
> >> You do not appear to be restricting this to one specific codec, or even
> >> codecs
> >> with B-frames.
> >>
> >> I can make it specific to only H264 / H265.
>
> The GOP structure should be applicable to most MPEG codecs, I think.
>
> > It is true that the patch will fail to compute the correct delay in lots
> of
> > cases. However the consequence of wrongly computing the has_b_frames is
> > pretty benign. It only increases the buffer size held for PTS
> reordering.
> > I can put a max-value check on the computed video_delay here. So in my
> > opinion, we won't see fatal regressions where a file is not able to be
> > decoded / played.
>
> It's true it's likely benign, but it's not exactly a "fix" either...
>
> From a user perspective, it's kinda possible to work around it "properly"
> (I use that term loosely here) by decoding enough frames to fill the max
> DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> (or in a user's code if they don't use that function), isn't it? Though,
> I feel that particular fix won't be welcomed with open arms, due to a
> ~16x 'slow down' in probing.
>
>
One option i asked on IRC was to use the spec for max DPB when the bitstream
restriction flag was not set.
But people were worry about low latency usage.
Normally, if the  bitstream restriction flag is not set, the DPB should be
set based on the spec, even if there is no B frames.
But in some case, it will be 16 frame and this could increase then the low
latency.



> Does anyone else have an opinion™ on this? I guess it's "OK enough" if
> restricted by codec...? :V
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis

On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> I don't know if the patch can be made more generic to work for all
> demuxers, because this patch requires that PTS of all packets be available
> in the header.  The other route is to make it very specific to codecs with
> B-frames.

All PTS may not be available in MP4 either, in the live profile fragmented
MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing code
say whether we seek to each fragment and make it available or not. I assume
you've tested such a case, or can (or know the fragment code)?

It's feasible to restrict it to codecs, I suppose.

>> You do not appear to be restricting this to one specific codec, or even
>> codecs
>> with B-frames.
>>
>> I can make it specific to only H264 / H265.

The GOP structure should be applicable to most MPEG codecs, I think.

> It is true that the patch will fail to compute the correct delay in lots of
> cases. However the consequence of wrongly computing the has_b_frames is
> pretty benign. It only increases the buffer size held for PTS  reordering.
> I can put a max-value check on the computed video_delay here. So in my
> opinion, we won't see fatal regressions where a file is not able to be
> decoded / played.

It's true it's likely benign, but it's not exactly a "fix" either...

From a user perspective, it's kinda possible to work around it "properly"
(I use that term loosely here) by decoding enough frames to fill the max
DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
(or in a user's code if they don't use that function), isn't it? Though,
I feel that particular fix won't be welcomed with open arms, due to a
~16x 'slow down' in probing.

Does anyone else have an opinion™ on this? I guess it's "OK enough" if
restricted by codec...? :V

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Sasi Inguva

I don't know if the patch can be made more generic to work for all
demuxers, because this patch requires that PTS of all packets be available
in the header.  The other route is to make it very specific to codecs with
B-frames.

On Tue, Nov 14, 2017 at 12:40 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 11/14/2017 8:28 PM, Sasi Inguva wrote:
> > For H264 files with no bitstream restriction flag, we aren't able to
> guess
> > the delay correctly. Especially if it's MOV container, because for MOV
> > container we just probe the 1st frame and stop in
> avformat_find_streaminfo .
>
> You do not appear to be restricting this to one specific codec, or even
> codecs
> with B-frames.
>
> I can make it specific to only H264 / H265.


> > When we are decoding , we increase the has_b_frames value from zero to 1
> or
> > 2, when we eventually encounter B-frames in H264 decoder, but that is too
> > late and we have already dropped 1 or 2 frames. Lot of other fields in
> > codecpar are being set from the demuxer like channel_layout, sample_rate
> > etc.
>
> I am aware of the intend, however...
>
> The difference between filling those fields in and this patch, is that we
> can
> read those values directly, generally. This is a guess; a heuristic. A
> heuristic
> based on the GOP structure of a single codec. Where we guess where a GOP
> even
> starts. Nor does it seem to take into account non-friendly files, with
> oddly
> ordered and/or invalid timestamps (which it can't, based solely on PTS).
>
> I'm pretty tired of hitting insane edge cases in other types of files due
> to
> hacks added for some other specific set of file, but used for *everything*.
> This is a recurring theme in FFmpeg, so I'm trying to fight hard to keep
> more out...
>
It is true that the patch will fail to compute the correct delay in lots of
cases. However the consequence of wrongly computing the has_b_frames is
pretty benign. It only increases the buffer size held for PTS  reordering.
I can put a max-value check on the computed video_delay here. So in my
opinion, we won't see fatal regressions where a file is not able to be
decoded / played.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis

On 11/14/2017 8:28 PM, Sasi Inguva wrote:
> For H264 files with no bitstream restriction flag, we aren't able to guess
> the delay correctly. Especially if it's MOV container, because for MOV
> container we just probe the 1st frame and stop in avformat_find_streaminfo .

You do not appear to be restricting this to one specific codec, or even codecs
with B-frames.

> When we are decoding , we increase the has_b_frames value from zero to 1 or
> 2, when we eventually encounter B-frames in H264 decoder, but that is too
> late and we have already dropped 1 or 2 frames. Lot of other fields in
> codecpar are being set from the demuxer like channel_layout, sample_rate
> etc.

I am aware of the intend, however...

The difference between filling those fields in and this patch, is that we can
read those values directly, generally. This is a guess; a heuristic. A heuristic
based on the GOP structure of a single codec. Where we guess where a GOP even
starts. Nor does it seem to take into account non-friendly files, with oddly
ordered and/or invalid timestamps (which it can't, based solely on PTS).

I'm pretty tired of hitting insane edge cases in other types of files due to
hacks added for some other specific set of file, but used for *everything*.
This is a recurring theme in FFmpeg, so I'm trying to fight hard to keep
more out...

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Hendrik Leppkes

On Tue, Nov 14, 2017 at 9:28 PM, Sasi Inguva
 wrote:
> For H264 files with no bitstream restriction flag, we aren't able to guess
> the delay correctly. Especially if it's MOV container, because for MOV
> container we just probe the 1st frame and stop in avformat_find_streaminfo .
>
> When we are decoding , we increase the has_b_frames value from zero to 1 or
> 2, when we eventually encounter B-frames in H264 decoder, but that is too
> late and we have already dropped 1 or 2 frames. Lot of other fields in
> codecpar are being set from the demuxer like channel_layout, sample_rate
> etc.
>

It was not the usefulness that was questioned, but the implementation.
Maybe this should be more generic?

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Michael Niedermayer

On Tue, Nov 14, 2017 at 09:39:33AM -0800, Sasi Inguva wrote:
> Sorry forgot to attach the fate samples. Pls find them attached.

uploaded

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Sasi Inguva

For H264 files with no bitstream restriction flag, we aren't able to guess
the delay correctly. Especially if it's MOV container, because for MOV
container we just probe the 1st frame and stop in avformat_find_streaminfo .

When we are decoding , we increase the has_b_frames value from zero to 1 or
2, when we eventually encounter B-frames in H264 decoder, but that is too
late and we have already dropped 1 or 2 frames. Lot of other fields in
codecpar are being set from the demuxer like channel_layout, sample_rate
etc.

On Tue, Nov 14, 2017 at 10:06 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 11/14/2017 2:15 AM, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/mov.c| 48 ++
> ++
> >  tests/fate/mov.mak   |  5 +
> >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> >  4 files changed, 59 insertions(+)
> >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> >  create mode 100644 tests/ref/fate/mov-guess-delay-2
>
> Going to play the part of wm4 here.
>
> This seems like one giant hack to me (and potentially yet more slowness
> during init/index).
>
> Should we *really* be populating codecpar with a heuristic guess and
> should we *really* be putting this in one specific demuxer?
>
> Seems pretty gross to me.
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis

On 11/14/2017 2:15 AM, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 48 
> 
>  tests/fate/mov.mak   |  5 +
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  4 files changed, 59 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2

Going to play the part of wm4 here.

This seems like one giant hack to me (and potentially yet more slowness
during init/index).

Should we *really* be populating codecpar with a heuristic guess and
should we *really* be putting this in one specific demuxer?

Seems pretty gross to me.

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Michael Niedermayer

On Mon, Nov 13, 2017 at 06:15:05PM -0800, Sasi Inguva wrote:
[...]
> +fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
> stream=has_b_frames -select_streams v 
> $(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
> +fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
> stream=has_b_frames -select_streams v 
> $(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4

fate-suite//h264/h264_3bf_nopyramid_nobsrestriction.mp4: No such file or 
directory

where are these files ?


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-13 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 48 
 tests/fate/mov.mak   |  5 +
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 4 files changed, 59 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..91c6987a96 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,52 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_swaps = 0;
+
+if (msc->ctts_data) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// This is used as an indication that the previous GOP has ended 
and a
+// new GOP has started.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = FFMAX(st->codecpar->video_delay, 
num_swaps);
+num_swaps = 0;
+prev_max_pts = curr_pts;
+}
+
+// Compute delay as the no. of "drop"s in PTS inside a GOP.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2, 2->1)
+if (prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < prev_pts)
+++num_swaps;
+}
+
+prev_pts = curr_pts;
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3892,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..ef89e62096 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +74,6 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=1
+[/STREAM]
diff --git a/tests/ref/fate/mov-guess-delay-2 b/tests/ref/fate/mov-guess-delay-2
new file mode 100644
index 00..248de1c3ea
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-2
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=2
+[/STREAM]
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

34 matches

Site Navigation

Mail list logo

Footer information