[FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

[Sasi Inguva]

I think there is some bug in mp3 decoder which is making skip
samples -1431655766 for ~/tickets/5528/fire.mp3 . For now I have removed
the assert from the 3rd commit.
For the file one.mov , I think the audio has edit list with start time
correspending to the second sample - (which should be media time 1024 if I
guess correctly). This indicates that the first sample be used for encoder
delay.
 Previously without edit  list parsing , we used to offset the start_dts by
-1024 to make the second sample timestamp start from zero.
             sc->time_offset = start_time - empty_duration;
-            current_dts = -sc->time_offset;
             if (sc->ctts_count>0 && sc->stts_count>0 &&

But now edit list parsing handles the rebasing of timestamps to zero,
because it will  assign increasing timestamps  starting from zero, to
samples present in the edit list. Because the first sample is not in the
edit list, we mark it as DISCARD, which flag av_decode_audio4 will look at
and decode-and-discard that frame. So it wouldn't matter what the first
sample timestamp should be assigned because it is anyway discarded after
decode.

I am sure when you do ./ffprobe -show_frames -print_format compact one.mov
, you won't get the first audio sample at all and second audio sample will
start from zero timestamp. If I can get a link to the file, I can get a
deeper look but I am almost sure that this is what is happening.

Attaching the modified 3rd patch again.


On Thu, Aug 25, 2016 at 3:01 PM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Thu, Aug 25, 2016 at 12:31:19PM -0700, Sasi Inguva wrote:
> > oops. thanks for pointing that out. Even in our version of ffmpeg, that
> > assert doesn't get compiled so we never catched it. That assert logic is
> > not correct anymore. At the end of one edit list there can be frames
> marked
> > as discard, for which we would keep increasing the timestamp even if they
> > are marked as discard, so that when the timestamps are rerodered to
> compute
> > PTS B-frames get the correct PTS. But the next edit list should always
> > start with the timestamp of the last-non-discarded frame of the previous
> > edit list. Hence we will get non-increasing timestamps added as index
> > entries.
> >
> > The test may have passed for you before, because before that line was
> > assert(..) instead of av_assert1(...) so maybe that line wasn't getting
> > compiled before. Attaching the 4 patches again.
>
> patchset breaks timestamps for audio:
> ./ffmpeg -i matrixbench_mpeg2.mpg  -t 0.1  one.mov
> ./ffprobe  -show_packets -print_format compact one.mov
> packet|codec_type=video|stream_index=0|pts=0|pts_time=
> 0.000000|dts=-1024|dts_time=-0.080000|duration=512|duration_time=0.040000|
> convergence_duration=N/A|convergence_duration_time=N/A|
> size=9368|pos=36|flags=K
> packet|codec_type=video|stream_index=0|pts=1024|pts_
> time=0.080000|dts=-512|dts_time=-0.040000|duration=512|
> duration_time=0.040000|convergence_duration=N/A|
> convergence_duration_time=N/A|size=2190|pos=9404|flags=_
> packet|codec_type=audio|stream_index=1|pts=0|pts_time=
> 0.000000|dts=0|dts_time=0.000000|duration=N/A|duration_
> time=N/A|convergence_duration=N/A|convergence_duration_time=
> N/A|size=323|pos=11594|flags=K
> packet|codec_type=video|stream_index=0|pts=512|pts_
> time=0.040000|dts=0|dts_time=0.000000|duration=512|duration_time=0.040000|
> convergence_duration=N/A|convergence_duration_time=N/A|
> size=1328|pos=11894|flags=_
> packet|codec_type=audio|stream_index=1|pts=0|pts_time=
> 0.000000|dts=0|dts_time=0.000000|duration=1024|duration_
> time=0.021333|convergence_duration=N/A|convergence_
> duration_time=N/A|size=261|pos=13222|flags=K
>
> if you look at the audio stream 2 packets have the same pts, that
> looks wrong, previously the first packet had -1024
>
> [...]
>
>
> --
> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-avutil-frame-Add-a-flag-to-discard-frame-after-decod.patch
Type: text/x-patch
Size: 1670 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160826/99ea3763/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-lavf-mov-Add-support-for-edit-list-parsing.patch
Type: text/x-patch
Size: 117722 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160826/99ea3763/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-lavc-Add-a-flag-in-AVPacket-to-discard-packet-after-.patch
Type: text/x-patch
Size: 2921 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160826/99ea3763/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-avformat-avframe.h-Add-a-flag-in-AVIndexEntry-to-dis.patch
Type: text/x-patch
Size: 1818 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160826/99ea3763/attachment-0003.bin>