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

Michael Niedermayer michael at niedermayer.cc
Sat Aug 27 03:55:39 EEST 2016


On Fri, Aug 26, 2016 at 12:49:19PM -0700, Sasi Inguva wrote:
> 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.

current applications using libavformat have no knowledge of the
discard flag you can add the DISCARD flag, you can set it on packets but
applications written or built for libavformat 57 dont have to know
this flag and can treat the packets like any other packet.

Adding this feature without a major version bump requires things to
still work reasonable with the old semantics that apps are build
around. That should be possible unless iam missing something


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

heres a direct link
http://trac.ffmpeg.org/raw-attachment/ticket/5528/fire.mp3

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160827/d5c04bd7/attachment.sig>


More information about the ffmpeg-devel mailing list