Re: [FFmpeg-devel] [PATCH] avformat/mov: set AVFMT_SEEK_TO_PTS flag

Looks good to me. We were already doing PTS based seeking in MOV demuxer (although it's not perfect). On Thu, May 2, 2019 at 3:23 AM Gyan wrote: > > FATE passes. Checked that transcoded output remains the same whereas in > copy mode, seek to a video KF using ffmpeg cli returns the desired KF >

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for all sterams (in case of edit lists).

s > > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > From a0da82579a1c9ebb81bd029750fa718fa5f1c152 Mon Sep 17 00:00:00 2001 From: Sasi Inguva Date: Mon, 6 Aug 2018 16:28:50 -0700 Subject: [PATCH] lavf/mov.c: Set st

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for audio too (in case of edit lists).

Pls find attached, the corrected patch. On Wed, Aug 8, 2018 at 5:24 PM Sasi Inguva wrote: > Ok. i'll correct the commit message. > > On Wed, Aug 8, 2018 at 4:25 PM Michael Niedermayer > wrote: > >> On Wed, Aug 08, 2018 at 12:20:34PM -0700, Sasi Inguva wrote: >> >

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for audio too (in case of edit lists).

Ok. i'll correct the commit message. On Wed, Aug 8, 2018 at 4:25 PM Michael Niedermayer wrote: > On Wed, Aug 08, 2018 at 12:20:34PM -0700, Sasi Inguva wrote: > > i intended it only for audio, but i don't see any harm if it gets applied > > to subtitle tracks also . > > if y

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for audio too (in case of edit lists).

i intended it only for audio, but i don't see any harm if it gets applied to subtitle tracks also . On Tue, Aug 7, 2018 at 3:23 PM Michael Niedermayer wrote: > On Mon, Aug 06, 2018 at 04:32:29PM -0700, isasi-at-google@ffmpeg.org > wrote: > > From: Sasi Inguva > > > >

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for audio too (in case of edit lists).

Attaching the fate file. On Mon, Aug 6, 2018 at 4:33 PM wrote: > From: Sasi Inguva > > Fixes vorbis mp4 audio files, with edit list specified. Since > st->skip_samples is not set in case of vorbis , ffmpeg computes the > start_time as negative. > > Si

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mov: Break out of inner loop early in mov_estimate_video_delay()

LGTM. thanks On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer wrote: > 0.266 <- 0.299 sec (this is time ffmpeg so containing alot other things) > > Sample for benchmark was: ffmpeg -f rawvideo -pix_fmt yuv420p -s 32x32 -i > /dev/zero -t 24:00:00.00 out.mp4 > > Signed-off-by: Michael

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mov: Simplify last element computation in mov_estimate_video_delay()

LGTM. On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 67b3e11eb9..951a337cca 100644 > ---

Re: [FFmpeg-devel] [PATCH 2/4] bavformat/mov: Eliminate variable buf_size from mov_estimate_video_delay()

LGTM. thanks On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 19 --- > 1 file changed, 8 insertions(+), 11 deletions(-) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index

Re: [FFmpeg-devel] [PATCH 1/4] avformat/mov: remove modulo operations from mov_estimate_video_delay()

This one LGTM. Thanks for doing this. On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer wrote: > 0.324 <-0.491 sec > > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/libavformat/mov.c

Re: [FFmpeg-devel] [PATCH] libavformat/yuv4mpeg: Add color range support for Y4M Add color_range support in Y4M. Also set pixel format and color_range for YUVJ pixel formats.

Friendly ping! Thx. On Fri, Jun 22, 2018 at 6:25 AM Carl Eugen Hoyos wrote: > 2018-06-22 9:29 GMT+02:00, Wang Cao : > >> > >> My question was which authority defined this metadata for > >> y4m? Or which (non-FFmpeg-based) other software > >> understands the metadata your patch adds to the

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Only set pkt->duration to non negative values

looks good to me On Wed, Jun 13, 2018 at 10:11 AM Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 5d9ffa69a3..0acf981aef 100644 >

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set st->start_time for video streams explicitly.

friendly ping. thx. On Thu, May 31, 2018 at 4:26 PM Sasi Inguva wrote: > Pls find attached, the correctly signed patch > Thanks. > > On Thu, May 31, 2018 at 4:14 PM Sasi Inguva wrote: > >> Sorry. Forgot to attach the file. Pls find it attached. Also resending >> th

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set st->start_time for video streams explicitly.

Pls find attached, the correctly signed patch Thanks. On Thu, May 31, 2018 at 4:14 PM Sasi Inguva wrote: > Sorry. Forgot to attach the file. Pls find it attached. Also resending the > patch signed with correct email address > > On Thu, May 31, 2018 at 2:14 PM Michael Niederma

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set st->start_time for video streams explicitly.

Sorry. Forgot to attach the file. Pls find it attached. Also resending the patch signed with correct email address On Thu, May 31, 2018 at 2:14 PM Michael Niedermayer wrote: > On Tue, May 29, 2018 at 03:39:40PM -0700, Sasi Inguva wrote: > > If start_time is not set, ffmpeg takes the

[FFmpeg-devel] [PATCH] lavf/mov.c: Set st->start_time for video streams explicitly.

If start_time is not set, ffmpeg takes the duration from the global movie instead of the per stream duration. Signed-off-by: Sasi Inguva --- libavformat/mov.c| 20 +--- tests/fate/mov.mak | 4 +++ tests/ref/fate/mov-neg-firstpts

Re: [FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

Hi. sorry for the late reply. I sent a patch similar to this a while back https://patchwork.ffmpeg.org/patch/8227/ but it got lost in the sea. You also want to do, @@ -3579,7 +3579,8 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)

Re: [FFmpeg-devel] [PATCH] display: Add AVDisplayOrientation API

On Wed, Apr 4, 2018 at 8:30 AM, Vittorio Giovara wrote: > The transformation operations that can be described by a display matrix > are not limited to pure rotation, but include horizontal and vertical > flip, as well as transpose and antitranspose. Unfortunately the

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix timestamps to be strictly monotonic for video also.

From: Sasi Inguva <is...@isasi.mtv.corp.google.com> Using same timestamp for multiple packets confuses clients like Ffms2 while seeking to a packet with specific timestamp. Signed-off-by: Sasi Inguva <is...@isasi.mtv.corp.google.com> --- libavformat/mov.c | 9 + 1 fil

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix timestamps to be strictly monotonic for video also.

Signed-off-by: Sasi Inguva <is...@isasi.mtv.corp.google.com> --- libavformat/mov.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index cb6f3a45de..6b13742e4d 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

If we can support ffmpeg to parse and display a timeline with multiple edits correctly, I am ok with deleting that code. On Thu, Mar 29, 2018 at 6:43 AM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 3/29/2018 1:06 PM, wm4 wrote: > > I think mov files at least use a > > filename/URL

Re: [FFmpeg-devel] [PATCH] lavf/utils.c: Don't compute start_time from DISCARD packets for video.

friendly ping On Wed, Mar 21, 2018 at 2:55 PM, Michael Niedermayer <michae...@gmx.at> wrote: > On Wed, Mar 21, 2018 at 01:35:05PM -0700, Sasi Inguva wrote: > > Attaching fate sample. > > sample uploded > > thx > > [...] >

[FFmpeg-devel] [PATCH] lavf/utils.c: Don't compute start_time from DISCARD packets for video.

Signed-off-by: Sasi Inguva <is...@isasi.mtv.corp.google.com> --- libavformat/utils.c | 4 +++- tests/fate/mov.mak| 10 +++- tests/ref/fate/mov-neg-firstpts-discard | 3 +++ .../ref/fate/mov-neg-firstpts-discard-frames

[FFmpeg-devel] [PATCH] lavf/utils.c: Don't compute start_time from DISCARD packets for video.

Signed-off-by: Sasi Inguva <is...@isasi.mtv.corp.google.com> --- libavformat/utils.c | 4 +++- tests/fate/mov.mak | 10 +- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index 4d0b56c2a8..f13c8208b1 100644 --- a/libav

Re: [FFmpeg-devel] [PATCH] lavf/utils.c: Don't compute start_time from DISCARD packets for video.

Attaching fate sample. On Wed, Mar 21, 2018 at 1:33 PM, Sasi Inguva <is...@google.com> wrote: > Signed-off-by: Sasi Inguva <is...@isasi.mtv.corp.google.com> > --- > libavformat/utils.c | 4 +++- > tests/fate/mov.mak | 10 +- > 2 files changed, 12 insertions(

Re: [FFmpeg-devel] [PATCH] lavf/utils.c: Don't compute start_time from DISCARD packets for video.

Sorry, forgot to add the test reference files. Sending the revised patch. On Wed, Mar 21, 2018 at 1:35 PM, Sasi Inguva <is...@google.com> wrote: > Attaching fate sample. > > On Wed, Mar 21, 2018 at 1:33 PM, Sasi Inguva <is...@google.com> wrote: > >&

[FFmpeg-devel] [PATCH] lavf/mov.c: Use the correct offset to shift timestamp when seeking.

Fixes seek for files with empty edits and files with negative ctts (dts_shift > 0). Added fate samples and tests. Signed-off-by: Sasi Inguva <is...@isasi.mtv.corp.google.com> --- libavformat/isom.h | 1 + libavformat/mov.c| 27 +++-- t

Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: use calculated dts offset when seeking in streams

3:04PM -0800, Sasi Inguva wrote: > > This patch seems to be doing the wrong thing and breaking seek tests for > us. > > > > As far as I understand , seeking for most containers is based on > "decoding > > timestamp". Unless AV_SEEK_TO_PTS flag is specified

Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: use calculated dts offset when seeking in streams

This patch seems to be doing the wrong thing and breaking seek tests for us. As far as I understand , seeking for most containers is based on "decoding timestamp". Unless AV_SEEK_TO_PTS flag is specified in container, which is not for most containers and MOV. So if PTS and DTS are like such,

Re: [FFmpeg-devel] [PATCH 5/6] lavf/mov: fix disposable flags in mov_fix_index

This will increase memory requirement, since we are storing one CTTS for each sample. Please see my comments on your previous patch. On Sun, Nov 19, 2017 at 1:00 PM, John Stebbins wrote: > Merges ctts_data into mov_index_entries. This allows a considerable > amount of

Re: [FFmpeg-devel] [PATCH 4/6] lavf/mov: set AV_PKT_FLAG_DISPOSABLE from sdtp box

On Sun, Nov 19, 2017 at 12:46 PM, John Stebbins wrote: > --- > libavformat/isom.h | 10 ++ > libavformat/mov.c | 92 ++ > --- > libavformat/utils.c | 3 +- > 3 files changed, 99 insertions(+), 6 deletions(-) > >

Re: [FFmpeg-devel] Fix ctts_index calculation

this what we want? Also, the "wrong" > |ctts_index| will be available outside of this function. How do we make > sure it won't cause trouble later? > > On Fri, Feb 9, 2018 at 12:26 PM, Sasi Inguva <isasi-at-google.com@ffmpeg. > org > > wrote: > > &g

Re: [FFmpeg-devel] Fix ctts_index calculation

lso, the "wrong" > |ctts_index| will be available outside of this function. How do we make > sure it won't cause trouble later? > > On Fri, Feb 9, 2018 at 12:26 PM, Sasi Inguva <isasi-at-google.com@ffmpeg. > org > > wrote: > > > > > > > diff --

Re: [FFmpeg-devel] Fix ctts_index calculation

> > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 5adba52e08..f0bd3e3623 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st, > *ctts_index = 0; > *ctts_sample = 0; > for

Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently

i was on vacation so I missed this. sorry for the trouble and thanks for fixing the test. This test was fixed once before http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=4ccc1ef2a3b1a22d849861423df830e110c9a4ab . I've no idea why only this test needs to have the "-flags +bitexact -idct

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

Signed-off-by: Sasi Inguva <is...@google.com> --- 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-d

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

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 tra

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

mputed 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 <mich...@niedermayer.cc > wrote: > On Mon, Nov 20, 2017 at 08:27:05PM -0800, Sasi Inguva wrote: > > Signed-off-by: Sasi Inguva <is...@google.c

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

Signed-off-by: Sasi Inguva <is...@google.com> --- 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-d

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

Reattaching Fate sample. On Tue, Nov 21, 2017 at 9:57 AM, Sasi Inguva <is...@google.com> wrote: > Signed-off-by: Sasi Inguva <is...@google.com> > --- > libavformat/mov.c| 50 ++ > ++ > tests/fate/mov.mak

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

Ok. Just restricting this to H264 . On Tue, Nov 21, 2017 at 3:56 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Mon, Nov 20, 2017 at 11:06 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Mon, Nov 20, 2017 at 09:58:05PM +0530, Sasi Inguva wrote: &

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

Attaching the fate sample On Mon, Nov 20, 2017 at 8:28 AM, Sasi Inguva <is...@google.com> wrote: > Signed-off-by: Sasi Inguva <is...@google.com> > --- > libavformat/mov.c| 55 ++ > ++ > tests/fate/mov.mak

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

Signed-off-by: Sasi Inguva <is...@google.com> --- 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-d

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

On Sun, Nov 19, 2017 at 1:17 AM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > On Sat, Nov 18, 2017 at 11:12:17AM -0800, Sasi Inguva wrote: > > Signed-off-by: Sasi Inguva <is...@google.com> > > --- > > liba

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

Signed-off-by: Sasi Inguva <is...@google.com> --- 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 inse

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

Done. is there a better way to identify codecs that might need Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c| 52 tests/fate/mov.mak | 5 tests/ref/fate/mov-guess-delay-1 | 3 +++ tests/re

Re: [FFmpeg-devel] [mov] Fix leak of frame_duration_buffer in mov_fix_index().

LGTM. Thanks for the fix. On Sat, Nov 18, 2017 at 4:24 AM, Dale Curtis wrote: > Should be unconditionally freed at the end of mov_fix_index() in case it > hasn't been used during the fix up. > > Signed-off-by: Dale Curtis >

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

Signed-off-by: Sasi Inguva <is...@google.com> --- 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 inse

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

gt; 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, beca

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

enh...@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

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

enh...@gmail.com> wrote: > On 11/14/2017 2:15 AM, Sasi Inguva wrote: > > Signed-off-by: Sasi Inguva <is...@google.com> > > --- > > libavformat/mov.c| 48 ++ > ++ > > tests/fate/mov.mak | 5 +

[FFmpeg-devel] [PATCH] lavf/mov.c: Don't correct edit list start to zero, when we can't find a frame before edit list start. After c2a8f0fcbe57ea9ccaa864130f078af10516c3c1 this can happen on normal ed

Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c| 4 +- tests/fate/mov.mak | 6 + tests/ref/fate/mov-bbi-elst-starts-b | 391 +++ 3 files changed, 398 insertions(+), 3 deletions(-) create mode

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

Signed-off-by: Sasi Inguva <is...@google.com> --- 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 inse

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Don't correct edit list start to zero, when we can't find a frame before edit list start. After c2a8f0fcbe57ea9ccaa864130f078af10516c3c1 this can happen on norma

Forgot the fate REF file. Sending the full patch again. On Mon, Nov 13, 2017 at 4:15 PM, Sasi Inguva <is...@google.com> wrote: > Signed-off-by: Sasi Inguva <is...@google.com> > --- > libavformat/mov.c | 4 +--- > tests/fate/mov.mak | 6 ++ > 2 files changed, 7

[FFmpeg-devel] [PATCH] lavf/mov.c: Don't correct edit list start to zero, when we can't find a frame before edit list start. After c2a8f0fcbe57ea9ccaa864130f078af10516c3c1 this can happen on normal ed

Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c | 4 +--- tests/fate/mov.mak | 6 ++ 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index fd170baa57..79023ef369 100644 --- a/libavformat/mov.c +++ b/libavformat

[FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Partially fixes t/6699. --- libavformat/mov.c | 32 +++--- tests/fate/mov.mak| 4 tests/ref/fate/mov-elst-ends-betn-b-and-i | 33 +++ 3 files changed, 58 insertions(+), 11 deletions(-)

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Sorry, about this. i had uncommitted changes. Attaching the patch. On Thu, Nov 9, 2017 at 12:22 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > On Wed, Nov 08, 2017 at 04:13:46PM -0800, Sasi Inguva wrote: > > Partially fixes t/6699. > > --- &

[FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Partially fixes t/6699. --- libavformat/mov.c | 32 --- tests/fate/mov.mak| 4 tests/ref/fate/mov-elst-ends-betn-b-and-i | 31 ++ 3 files changed, 56 insertions(+), 11 deletions(-)

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Updated the fate test after http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c2a8f0fcbe57ea9ccaa864130f078af10516c3c1 . Sending the updated patch. On Thu, Nov 2, 2017 at 4:23 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Wed, Nov 01, 2017 at 02:27:50PM -0700, Sasi Ing

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

Modified the comment for find_prev_index function. Thx. On Thu, Nov 2, 2017 at 4:22 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Tue, Oct 31, 2017 at 04:45:00PM -0700, Sasi Inguva wrote: > > Attaching the fate sample. > > uploaded > > [...] > > -

[FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

Partially fixes t/6699. --- libavformat/mov.c| 129 +++ tests/fate/mov.mak | 8 +++ tests/ref/fate/mov-ibi-elst-starts-b | 33 + 3 files changed, 127 insertions(+), 43 deletions(-) create mode 100644

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

This patch is not an alternative. Both patches are required to fix t/6699 . Once one of the patches is submitted, i will update the fate tests in the other patch. On Wed, Nov 1, 2017 at 5:11 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Wed, Nov 01, 2017 at 02:26:45PM -0

[FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Partially fixes t/6699. --- libavformat/mov.c | 32 +--- tests/fate/mov.mak | 4 2 files changed, 25 insertions(+), 11 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 60f0228e2d..e716e5ba9e 100644 --- a/libavformat/mov.c +++

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Pls find attached, the FATE sample. On Wed, Nov 1, 2017 at 2:26 PM, Sasi Inguva <is...@google.com> wrote: > Partially fixes t/6699. > --- > libavformat/mov.c | 32 > --- > tests/fate/mov.mak| 4 +

[FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Partially fixes t/6699. --- libavformat/mov.c | 32 --- tests/fate/mov.mak| 4 tests/ref/fate/mov-elst-ends-betn-b-and-i | 31 ++ 3 files changed, 56 insertions(+), 11 deletions(-)

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

Forgot to attach the FATE ref file. sending the patch again. On Wed, Nov 1, 2017 at 2:23 PM, Sasi Inguva <is...@google.com> wrote: > Partially fixes t/6699. > --- > libavformat/mov.c | 32 +--- > tests/fate/mov.mak | 4 > 2 files changed,

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

Thanks. Sent the corrected patch. On Tue, Oct 31, 2017 at 7:14 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > On Tue, Oct 31, 2017 at 04:42:56PM -0700, Sasi Inguva wrote: > > Partially fixes t/6699. > > --- > >

[FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

Partially fixes t/6699. --- libavformat/mov.c| 125 +++ tests/fate/mov.mak | 8 +++ tests/ref/fate/mov-ibi-elst-starts-b | 33 + 3 files changed, 123 insertions(+), 43 deletions(-) create mode 100644

[FFmpeg-devel] (no subject)

Added the fate ref file to the commit. Thx. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

Attaching the fate sample. On Tue, Oct 31, 2017 at 4:42 PM, Sasi Inguva <is...@google.com> wrote: > Partially fixes t/6699. > --- > libavformat/mov.c | 125 ++ > +-- > tests/fate/mov.mak | 8 > 2 files chang

[FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

Partially fixes t/6699. --- libavformat/mov.c | 125 +++-- tests/fate/mov.mak | 8 2 files changed, 90 insertions(+), 43 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 60f0228e2d..a295445651 100644 ---

Re: [FFmpeg-devel] [PATCH]fate: Add bitexact and idct simple to the mov-invalid-edst test

looks good to me. Thanks for the fix. On Sun, Oct 29, 2017 at 2:11 PM, Carl Eugen Hoyos wrote: > 2017-10-29 22:03 GMT+01:00 Carl Eugen Hoyos : > > Hi! > > > > Attached patch fixes a fate test here on a ppc system. > > The following is sufficient: -flags

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

On Tue, Oct 24, 2017 at 2:48 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > On Mon, Oct 23, 2017 at 04:18:28PM -0700, Sasi Inguva wrote: > > Signed-off-by: Sasi Inguva <is...@google.com> > > --- > > libavformat/mov.c | 15

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

On Fri, Oct 20, 2017 at 4:26 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > On Wed, Oct 18, 2017 at 08:12:50PM -0700, Sasi Inguva wrote: > > Signed-off-by: Sasi Inguva <is...@google.com> > > --- > > libavformat/mov.c | 16

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c | 15 +++- tests/fate/mov.mak | 4 ++ tests/ref/fate/mov-invalid-elst-entry-count | 57 + 3 files changed, 75 insertions(+), 1 de

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c | 16 +++- tests/fate/mov.mak | 6 ++- tests/ref/fate/mov-invalid-elst-entry-count | 57 + 3 files changed, 76 insertions(+), 3 del

Re: [FFmpeg-devel] [mov] When both edit list and start padding present, take maximum.

Patch LGTM. Thanks. On Wed, Oct 18, 2017 at 4:14 PM, Dale Curtis <dalecur...@chromium.org> wrote: > On Wed, Oct 18, 2017 at 4:00 PM, Sasi Inguva <is...@google.com> wrote: > >> Thanks for the patch. The bug is because mov_fix_index updates >> skip_samples correct

Re: [FFmpeg-devel] [mov] When both edit list and start padding present, take maximum.

Thanks for the patch. The bug is because mov_fix_index updates skip_samples correctly, but not start_pad. Can you instead of taking the max, just update the mov_fix_index function so that start_pad = skip_samples always. Something like this diff --git a/libavformat/mov.c b/libavformat/mov.c index

[FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.

Signed-off-by: Sasi Inguva <is...@google.com> --- libavfilter/avfilter.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index 58917ed445..f0f849b326 100644 --- a/libavfilter/avfilter.c +++ b/libavfilter/avfi

Re: [FFmpeg-devel] [PATCH 5/5] ffmpeg: send EOF pts to filters.

I've encountered the same problem, and tracked it to guess_status_pts function which tries to take the end timestamp from the input links however without converting it to correct time base. Sent a patch, PTAL. On Tue, Oct 3, 2017 at 5:36 PM, Thomas Mundt wrote: > Hi Nicolas,

[FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.

Signed-off-by: Sasi Inguva <is...@google.com> --- libavfilter/avfilter.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index 58917ed445..ec7dfc0bd3 100644 --- a/libavfilter/avfilter.c +++ b/libav

[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

According to https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3 Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/movenc.c| 22 +++--- tests/re

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

Ping! On Aug 5, 2017 10:08 AM, "Sasi Inguva" <is...@google.com> wrote: > To the best of my knowledge, all fate changes are benign. All of them > correspond to a size increase of 54 bytes, which is the total size of the > new atoms added. > > On Sat, Aug 5, 20

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

To the best of my knowledge, all fate changes are benign. All of them correspond to a size increase of 54 bytes, which is the total size of the new atoms added. On Sat, Aug 5, 2017 at 9:27 AM, Derek Buitenhuis <derek.buitenh...@gmail.com > wrote: > On 8/4/2017 9:35 PM, Sasi Ing

[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

According to https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3 Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/movenc.c

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

addresses for some atoms will change for all MP4 files . On Fri, Aug 4, 2017 at 12:11 PM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 8/4/2017 7:46 PM, Sasi Inguva wrote: > > According to https://developer.apple.com/library/content/documentation/ > QuickTi

[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

According to https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/movenc.c| 70 + tests/ref/fate/adtstoasc_ticket3715 | 4 +--

Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?

Hi, I was the one who made that change. We needed a way to obtain individual stream durations from a Matroska file without reading the entire file. I don't think it adds to the file size greatly (< 50 bytes) compared to the size of video and audio data, hence I didn't hide it under an option.

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

That's great. Thanks. On Jun 9, 2017 9:24 AM, "wm4" <nfx...@googlemail.com> wrote: > On Tue, 6 Jun 2017 11:16:01 -0700 > Sasi Inguva <isasi-at-google@ffmpeg.org> wrote: > > > Fixes t/6421. If the videos starts with B frame, then the minimum > com

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

Ping! On Jun 6, 2017 11:17 AM, "Sasi Inguva" <is...@google.com> wrote: > Got it. Added to the description. > > On Tue, Jun 6, 2017 at 6:51 AM, wm4 <nfx...@googlemail.com> wrote: > >> On Sat, 3 Jun 2017 19:31:37 -0700 >> Sasi Inguva <isasi-at-googl

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

Got it. Added to the description. On Tue, Jun 6, 2017 at 6:51 AM, wm4 <nfx...@googlemail.com> wrote: > On Sat, 3 Jun 2017 19:31:37 -0700 > Sasi Inguva <isasi-at-google@ffmpeg.org> wrote: > > > > -// Offset the DTS by ctts[0] to mak

[FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

/twofields_packet.mp4 is a similar file starting with 2 Bframes. Before this change the PTS of first two B-frames was -6006 and -3003, and I am guessing one of them got dropped when being decoded and remuxed to the framecrc before, and now it is not being dropped. Signed-off-by: Sasi Inguva

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

ot dropped when being decoded and remuxed to the framecrc before, and now it is not being dropped but I dont understand why. On Sat, Jun 3, 2017 at 5:40 AM, wm4 <nfx...@googlemail.com> wrote: > On Fri, 2 Jun 2017 18:17:22 -0700 > Sasi Inguva <isasi-at-google@ffmpeg.org> wr

[FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

Fixes t/6421 Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c| 57 -- tests/ref/fate/h264-twofields-packet | 60 ++-- 2 files changed, 70 insertions(+), 47 deletions(-) diff

[FFmpeg-devel] [PATCH] lavf/mov.c: Correct keyframe search in edit list to return the very first keyframe/frame with matching timestamp. Fixes ticket#5904

Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/mov.c | 12 1 file changed, 12 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index b5181775e7..2a7cbfe142 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2847,11 +2847,23 @@ static i

Re: [FFmpeg-devel] mov: support for multiple edits and cenc decryption

> -Original Message- > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Sasi Inguva > > > > Sent: Wednesday, January 18, 2017 3:30 AM > > > > To: FFmpeg development discussions and patches < > ffmpeg-devel@ffmpeg.org> &

[FFmpeg-devel] [PATCH] lavf/matroskaenc.c: Free dyn bufs in mkv_free. Fixes memory leaks when muxing fails.

Signed-off-by: Sasi Inguva <is...@google.com> --- libavformat/matroskaenc.c | 17 + 1 file changed, 17 insertions(+) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index f731b678b9..88f6c647b9 100644 --- a/libavformat/matroskaenc.c +++ b/libav

[FFmpeg-devel] [PATCH] ffmpeg.c: Add output file index and stream index to vstats file.

Signed-off-by: Sasi Inguva <is...@google.com> --- doc/ffmpeg.texi | 8 +++- ffmpeg.c| 9 +++-- ffmpeg_opt.c| 2 +- 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index cdea1a271f..996d6a6cc4 100644 --- a/doc/ffmpeg.texi

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: Add output file index and stream index to vstats file.

Updated the patch with using vstats_version. PTAL. On Sat, Jan 21, 2017 at 3:52 AM, Michael Niedermayer <michae...@gmx.at> wrote: > On Fri, Jan 20, 2017 at 07:31:09PM -0800, Sasi Inguva wrote: > > Couldn't find any version that relates to vstats. There is nothing that > > s

[FFmpeg-devel] [PATCH] ffmpeg_opt.c: Introduce a -vstats_version option and document the existing -vstats format.

Signed-off-by: Sasi Inguva <is...@google.com> --- doc/ffmpeg.texi | 4 ffmpeg.h| 1 + ffmpeg_opt.c| 3 +++ 3 files changed, 8 insertions(+) diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index b56bdbe261..cdea1a271f 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@

  1   2   3   >