Bump again for this one too. Thanks. The Arch Linux distro is awaiting resolution of this issue.
- dale On Mon, May 4, 2020 at 11:10 AM Dale Curtis <[email protected]> wrote: > Any comments on this? Thanks. > > - dale > > On Thu, Apr 30, 2020 at 12:42 PM Dale Curtis <[email protected]> > wrote: > >> Ping for this patch. Thanks >> >> - dale >> >> On Thu, Apr 23, 2020 at 4:33 PM Dale Curtis <[email protected]> >> 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 <[email protected]> >>> >> _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
