Peter Zebühr: >> On 29 Aug 2022, at 16:37, Andreas Rheinhardt >> <andreas.rheinha...@outlook.com> wrote: >> >> The Matroska muxer is buggy wrt. to the ts_offset relating to codec >> delay. You can see it in lines 1839-1841 which are commented out. >> Commenting them out happened in commit >> 82e4f39883932c1b1e5c7792a1be12dec6ab603d, merging the libav commit that >> implemented it (namely >> https://github.com/FFmpeg/FFmpeg/commit/a1aa37dd0b96710d4a17718198a3f56aea2040c1 >> >> <https://github.com/FFmpeg/FFmpeg/commit/a1aa37dd0b96710d4a17718198a3f56aea2040c1>). >> It mentions "assertion failures and av sync errors". I can only think of >> one way that it could have led to assertion failures, but this should >> have been fixed in 4ebeab15b037a21f195696cef1f7522daf42f3ee (and since >> then I wondered whether it can't be enabled). >> >> - Andreas > > Interesting, > > It does look like re-enabling that commented out section would indeed shift > my teimstamps forward by the encoder dalay and work with my ts_offset > setting. > I do wonder though, would that not also mean that for the cases where the > stream should start at 0 it would result in streams starting 7ms in due to > the handle_avoid_negative_ts already having shifted the first packets PTS > from -7 to 0? And that would end up being shifted once again for the > inital_padding? >
Yes, the shifting code in libavformat/mux.c does not yet know about the Matroska muxer's ability to shift by initial_padding samples. But at least it will shift all packets, thereby preserving sync in case there are multiple streams. This is not done currently. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
