[FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
Michael Niedermayer
michael at niedermayer.cc
Sat Sep 3 01:56:04 EEST 2016
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sync_audio.raw.bz2
Type: application/octet-stream
Size: 62 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160903/34f67eb9/attachment.obj>
-------------- 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/20160903/34f67eb9/attachment.sig>
More information about the ffmpeg-devel
mailing list