On Mon, Jun 24, 2019 at 11:16:18PM +0200, Andreas Rheinhardt wrote: > Commit 31f9032b added the audio_preload feature; its goal is to > interleave audio earlier than the rest. Unfortunately, it has never ever > worked, because the check for whether a packet should be interleaved > before or after another packet was completely wrong: When audio_preload > vanishes, interleave_compare_dts returns 1 if the new packet should be > interleaved earlier than the packet it is compared with and that is what > the rest of the code expects. But the codepath used when audio_preload is > set does the opposite. > > Also fixes potential undefined behaviour (namely signed integer > overflow). > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> > --- > avformat.h contains the following note about audio_preload: "not all > formats support this and unpredictable things may happen if it is used > when not supported." Has this been added because of unpredictable > results caused by the buggy check? This option seems to work fine as > long as audio_preload is not in the range of max_interleave_duration.
audio preload will violate the spec of some containers which dont allow any preload. Thats what the note was for IIRC > > libavformat/mux.c | 22 ++++++++++++++-------- > libavformat/version.h | 2 +- > 2 files changed, 15 insertions(+), 9 deletions(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: PGP signature
_______________________________________________ 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".
