[FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

[Michael Niedermayer]

On Thu, Apr 23, 2020 at 04:33:21PM -0700, Dale Curtis wrote:
> This is a patch Chromium has carried for a while, we forgot to send it
> upstream. 7546ac2fee4 made it so that the start_time for mp3 files is
> adjusted for skip_samples. However, this appears incorrect because
> subsequent packet timestamps are not adjusted and skip_samples are
> applied by deleting data from a packet without changing the timestamp.
> 
> E.g., we are told the start_time is ~25ms and we get a packet with a
> timestamp of 0 that has had the skip_samples discarded from it. As such
> rendering engines may incorrectly discard everything prior to the
> 25ms thinking that is where playback should officially start. Since the
> samples were deleted without adjusting timestamps though, the true
> start_time is still 0.
> 
> Other formats like MP4 with edit lists will adjust both the start
> time and the timestamps of subsequent packets to avoid this issue.
> 
> Signed-off-by: Dale Curtis <dalecurtis at chromium.org>

> 173f45ece85db7ccb5f242043b1d029bfbdbd28b  no_start_time_adjust_v0.patch
> From 1f551502a2e271da044f7e4be4be7ddca7f30bc1 Mon Sep 17 00:00:00 2001
> From: Dale Curtis <dalecurtis at chromium.org>
> Date: Thu, 23 Apr 2020 16:18:18 -0700
> Subject: [PATCH] Don't adjust start time for MP3 files; packets are not
>  adjusted.
> 
> This is a patch Chromium has carried for a while, we forgot to send it
> upstream. 7546ac2fee4 made it so that the start_time for mp3 files is
> adjusted for skip_samples. However, this appears incorrect because
> subsequent packet timestamps are not adjusted and skip_samples are
> applied by deleting data from a packet without changing the timestamp.
> 
> E.g., we are told the start_time is ~25ms and we get a packet with a
> timestamp of 0 that has had the skip_samples discarded from it. As such
> rendering engines may incorrectly discard everything prior to the
> 25ms thinking that is where playback should officially start. Since the
> samples were deleted without adjusting timestamps though, the true
> start_time is still 0.
> 
> Other formats like MP4 with edit lists will adjust both the start
> time and the timestamps of subsequent packets to avoid this issue.
> 
> Signed-off-by: Dale Curtis <dalecurtis at chromium.org>
> ---
>  libavformat/mp3dec.c       | 4 ----
>  tests/ref/fate/gapless-mp3 | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)

this causes
./ffmpeg -i tickets//5205/example-with-error_cut.mp3 -t 0.11 -f framecrc before
to change this way:

--- before	2020-05-27 17:16:08.282813662 +0200
+++ after	2020-05-27 17:14:40.654886720 +0200
@@ -11,9 +11,8 @@
 #channel_layout 1: 3
 #channel_layout_name 1: stereo
 0,          0,          0,        0,  3000000, 0x68775127
-1,          0,          0,       47,      188, 0x05b53e6d
-1,         47,         47,     1152,     4608, 0xaf804111
-1,       1199,       1199,     1152,     4608, 0xded29ae0
-1,       2351,       2351,     1152,     4608, 0x51b68940
-1,       3503,       3503,     1152,     4608, 0xa63e5ef7
-1,       4655,       4655,      196,      784, 0x9fd3a615
+1,       1105,       1105,       47,      188, 0x05b53e6d
+1,       1152,       1152,     1152,     4608, 0xaf804111
+1,       2304,       2304,     1152,     4608, 0xded29ae0
+1,       3456,       3456,     1152,     4608, 0x51b68940
+1,       4608,       4608,     1152,     4608, 0xa63e5ef7

what id like to point out here is that the audio stream no
longer starts at the same time as the video
also the duration from adding the durations before is
exact but not afterwards

i sadly didnt had the time to look into this before
it was applied. So ATM iam just reporting this change, i didnt look
at what exactly is going on

I assume the file is here:
https://trac.ffmpeg.org/raw-attachment/ticket/5205/example-with-error_cut.mp3

also i seem to have more files that appear to behave the same

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200527/6e59cd81/attachment.sig>