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

Sat Sep 3 22:06:39 EEST 2016

Hi Michael,

In fact from audacity I see that out-ingu.wav out-mp3.wav are almost
equivalent, though not exactly. However if I do the same RAW->MOV->WAV
conversion with head, I see that the out-head.wav is shifted to the right .
This is because the MOV file contains edit list
EntryCount 1
Entry[0].SegmentDuration 2000
Entry[0].MediaTime 1105which represents the encoder delay but without my
patch we are not parsing that entry as encoder delay and outputting the
first silent packet too. This existing line in HEAD does it for AAC  but
not mp3
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=f4999068519f1f06f6b5d84ca007148e74e5a82e;hb=HEAD#l2799
. With editlist patch we solve this problem for mp3 too. Please find
attached the audacity screenshot.

On Fri, Sep 2, 2016 at 3:56 PM, Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Fri, Sep 02, 2016 at 01:00:59PM -0700, Sasi Inguva wrote:
> > On Aug 31, 2016 5:23 AM, "Michael Niedermayer" <michael at niedermayer.cc>
> > wrote:
> > >
> > > On Tue, Aug 30, 2016 at 06:37:22PM -0700, Sasi Inguva wrote:
> > > > On Sun, Aug 28, 2016 at 3:10 AM, Michael Niedermayer
> > <michael at niedermayer.cc
> > > > > wrote:
> [...]
> > >
> > >
> > > > The timestamps for discarded packets are meaningless to av_decode_*
> > > > functions because they parse the DISCARD flag and ignore the
> packets. I
> > am
> > > > not sure, what you mean by semantics though, because I don't think I
> am
> > > > changing any user expectations defined by the mov_read_frame
> > mov_seek_frame
> > > > functions .
> > >
> > > > If by semantics, you mean that user expects to see
> > > > monotonically increasing timestamps for the "demuxed " packets then
> yes
> > > > that expectation changes to " monotonically increasing timestamps for
> > the
> > > > "demuxed and non-discarded" packets" and user has to parse the
> discard
> > > > flag.
> > >
> > > Adding a flag that "must be parsed" would be a incompatible API change.
> > > It would require a major version bump
> > >
> > > also this patchset changes streamcopy
> > > try:
> > > ./ffmpeg-ref -i matrixbench_mpeg2.mpg  -acodec mp3 -vn -t 1
> test-ref.mov
> > > ./ffmpeg     -i matrixbench_mpeg2.mpg  -acodec mp3 -vn -t 1  test.mov
> > > ./ffmpeg-ref -i test-ref.mov -acodec copy test2-ref.mov
> > > ./ffmpeg     -i test.mov -acodec copy test2.mov
> > >
> > > old code:
> > > ./ffmpeg-ref -i test-ref.mov -aframes 3 -f framecrc -
> > > 0,          0,          0,     1152,     4608, 0xa2a00df2
> > > 0,       1152,       1152,     1152,     4608, 0xa573dfd4
> > > 0,       2304,       2304,     1152,     4608, 0x8994a906
> > > and
> > > ./ffmpeg-ref -i test2-ref.mov -aframes 3 -f framecrc -
> > > 0,          0,          0,     1152,     4608, 0xa2a00df2
> > > 0,       1152,       1152,     1152,     4608, 0xa573dfd4
> > > 0,       2304,       2304,     1152,     4608, 0x8994a906
> > >
> > > new code:
> > > ./ffmpeg -i test.mov -aframes 3 -f framecrc
> > > 0,          0,          0,     1152,     4608, 0xa573dfd4
> > > 0,       1152,       1152,     1152,     4608, 0x8994a906
> > > 0,       2304,       2304,     1152,     4608, 0x824d1a30
> > > and
> > > ./ffmpeg -i test2.mov -aframes 3 -f framecrc -
> > > 0,          0,          0,     1152,     4608, 0xa2a00df2
> > > 0,          1,          1,     1152,     4608, 0xa573dfd4
> > > 0,       1152,       1152,     1152,     4608, 0x8994a906
> > >
> >
> > First phase of transmuxing :
> >
> > test.mov and test-ref.mov both have an edit list with media time 1152
> which
> > indicates that the first audio frame be not output (and perhaps it is a
> > silent packet used as encoder delay) . While ./ffmpeg correctly doesn't
> > output first frame ./ffmpeg-ref does.
>
> Ill awnser the first part of your mail separatly, but first this
>
> If you use audacity to compare the output, and it can probably be
> most clearly seen with this:
>
> ./ffmpeg -f u8 -ar 16000 -ac 1 -i sync_audio.raw -acodec libmp3lame
> test-ingu.mov
> ./ffmpeg -f u8 -ar 16000 -ac 1 -i sync_audio.raw -acodec libmp3lame
> test.mp3
> ./ffmpeg -f u8 -ar 16000 -ac 1 -i sync_audio.raw ref.wav
> ./ffmpeg -i test-ingu.mov out-ingu.wav
> ./ffmpeg -i test.mp3 out-mp3.wav
>
> you can clearly see that the mp3 encoding and decoding gives an exactly
> matching output, there is no error in the initial padding /start skip
>
> your patchset with mov does not achive this it also doesnt use the
> existing framework for initial skip/padding
>
> see libavformat/mp3dec.c for an example of the existing framework
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> _______________________________________________
> 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: audacity2.png
Type: image/png
Size: 101955 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160903/07ab2707/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audacity2.png
Type: image/png
Size: 101955 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160903/07ab2707/attachment-0001.png>