[FFmpeg-trac] #7185(avformat:new): Preserve codec delay/initial padding and trailing padding during muxing
FFmpeg
trac at avcodec.org
Thu May 3 00:35:53 EEST 2018
#7185: Preserve codec delay/initial padding and trailing padding during muxing
----------------------------------+---------------------------------------
Reporter: mkver | Type: enhancement
Status: new | Priority: wish
Component: avformat | Version: git-master
Keywords: mkv mov | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
----------------------------------+---------------------------------------
Currently initial and trailing padding data is often lost during muxing
even when the target container has features that can be used to retain it.
I'm thinking about Matroska and mp4 here, but there might be other
containers with these capabilities.
For Matroska, the CodecDelay track header field is only written for Opus
although it could be written for all audio tracks. Also, the
DiscardPadding element isn't used for end trimming for most encoders
(Opus, libopus libmp3lame and the experimental vorbis encoder being
exceptions; here the encoder adds the needed AV_PKT_DATA_SKIP_SAMPLES side
data; probably there are other exceptions).
For mp4, edit lists could be used to signal the actual encoder delay; and
sometimes this is already done so, but not by design, but by accident/as a
side-effect of the shifting of timestamps to make the dts nonnegative.
Here is a test*:
{{{
% ffmpeg.exe -f lavfi -i anullsrc -filter:a
"atrim=start_sample=0:end_sample=10000" -c:a aac -f framehash -hash crc32
-
#format: frame checksums
#version: 2
#hash: CRC32
#extradata 0, 5, c72331cb
#software: Lavf58.13.100
#tb 0: 1/44100
#media_type 0: audio
#codec_id 0: aac
#sample_rate 0: 44100
#channel_layout 0: 3
#channel_layout_name 0: stereo
#stream#, dts, pts, duration, size, hash
0, -1024, -1024, 1024, 23, 5a2d9cda
0, 0, 0, 1024, 6, 595037cd
0, 1024, 1024, 1024, 6, 595037cd
0, 2048, 2048, 1024, 6, 595037cd
0, 3072, 3072, 1024, 6, 595037cd
0, 4096, 4096, 1024, 6, 595037cd
0, 5120, 5120, 1024, 6, 595037cd
0, 6144, 6144, 1024, 6, 595037cd
0, 7168, 7168, 1024, 6, 595037cd
0, 8192, 8192, 1024, 6, 595037cd
0, 9216, 9216, 784, 6, 595037cd
}}}
When muxing this into mp4, there is an edit list showing that the first
1024 samples should be discarded which means that the dts of the first
packet is -1024:
{{{
% ffmpeg.exe -f lavfi -i anullsrc -filter:a
"atrim=start_sample=0:end_sample=10000" -c:a aac test.mp4
ffmpeg -i test.mp4 -c copy -f framehash -hash crc32 -
#format: frame checksums
#version: 2
#hash: CRC32
#extradata 0, 5, c72331cb
#software: Lavf58.13.100
#tb 0: 1/44100
#media_type 0: audio
#codec_id 0: aac
#sample_rate 0: 44100
#channel_layout 0: 3
#channel_layout_name 0: stereo
#stream#, dts, pts, duration, size, hash
0, -1024, -1024, 1024, 23, 5a2d9cda, S=1, 10,
be66397a
0, 0, 0, 1024, 6, 595037cd
0, 1024, 1024, 1024, 6, 595037cd
0, 2048, 2048, 1024, 6, 595037cd
0, 3072, 3072, 1024, 6, 595037cd
0, 4096, 4096, 1024, 6, 595037cd
0, 5120, 5120, 1024, 6, 595037cd
0, 6144, 6144, 1024, 6, 595037cd
0, 7168, 7168, 1024, 6, 595037cd
0, 8192, 8192, 1024, 6, 595037cd
0, 9216, 9216, 751, 6, 595037cd
}}}
But if we start the audio a bit later (at sample 500), only the first 524
samples are discarded via the edit list (because the edit list by design
is only there to make the dts non-negative) and time from 0 to 500/44100 s
now contains valid audio whereas previously there was nothing:
{{{
ffmpeg.exe -f lavfi -i anullsrc -filter:a
"atrim=start_sample=500:end_sample=10500" -c:a aac test2.mp4
ffmpeg -i test2.mp4 -c copy -f framehash -hash crc32 -
#format: frame checksums
#version: 2
#hash: CRC32
#extradata 0, 5, c72331cb
#software: Lavf58.13.100
#tb 0: 1/44100
#media_type 0: audio
#codec_id 0: aac
#sample_rate 0: 44100
#channel_layout 0: 3
#channel_layout_name 0: stereo
#stream#, dts, pts, duration, size, hash
0, -524, -524, 1024, 23, 5a2d9cda, S=1, 10,
d740a07e
0, 500, 500, 1024, 6, 595037cd
0, 1524, 1524, 1024, 6, 595037cd
0, 2548, 2548, 1024, 6, 595037cd
0, 3572, 3572, 1024, 6, 595037cd
0, 4596, 4596, 1024, 6, 595037cd
0, 5620, 5620, 1024, 6, 595037cd
0, 6644, 6644, 1024, 6, 595037cd
0, 7668, 7668, 1024, 6, 595037cd
0, 8692, 8692, 1024, 6, 595037cd
0, 9716, 9716, 780, 6, 595037cd
}}}
*: All tests have been done with this version of ffmpeg:
{{{
ffmpeg version N-90920-ge07b1913fc Copyright (c) 2000-2018 the FFmpeg
developers
built with gcc 7.3.0 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-
version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls
--enable-iconv --enable-libass --enable-libbluray --enable-libfreetype
--enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp
--enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-
libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-
libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va
--enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 18.100 / 56. 18.100
libavcodec 58. 19.100 / 58. 19.100
libavformat 58. 13.100 / 58. 13.100
libavdevice 58. 4.100 / 58. 4.100
libavfilter 7. 21.100 / 7. 21.100
libswscale 5. 2.100 / 5. 2.100
libswresample 3. 2.100 / 3. 2.100
libpostproc 55. 2.100 / 55. 2.100
}}}
This is one completely unrelated commit behind git-master.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7185>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list