On Sat, Mar 07, 2020 at 10:21:33AM +0100, Marton Balint wrote: > > > On Sat, 7 Mar 2020, Michael Niedermayer wrote: > > >On Thu, Mar 05, 2020 at 10:56:28PM +0100, Marton Balint wrote: > >>The packet durations might not be set properly which can cause the MXF muxer > >>to write more than one packet of a stream to an edit unit messing up the > >>constant byte per element index... > >> > >>Also use nb_samples directly to calculate dts of audio packets because > >>adding > >>packet durations might not be precise. > >> > >>Signed-off-by: Marton Balint <c...@passwd.hu> > >>--- > >> libavformat/audiointerleave.c | 12 +++++++++--- > >> libavformat/audiointerleave.h | 3 ++- > >> libavformat/gxfenc.c | 2 +- > >> libavformat/mxfenc.c | 2 +- > >> 4 files changed, 13 insertions(+), 6 deletions(-) > > > >This doesnt feel correct > > > >Either case > >A. The durations are correct but not what the muxer wants > >then changing them at the muxer level could lead to AV sync issues and > >wrong timestamps, something which the application should have dealt with > >by frame duplication / frame drops or other > > > >B. The durations are just wrong > >then changing them at the muxer level will leave the calling application > >with incorrect values potentially causing all kinds of problems. > > > >Maybe iam missing something but isnt this just fixing the issue when the > >durtations are wrong in a very special way ? > > It is the same "special" way that is used for audio. We ignore incoming DTS > and duration, and make up our own. > > Yes, it can cause A-V sync issues is somebody wants to push VFR video or > sparse audio data, that is not allowed in the MXF muxer. > > Maybe we should hard reject streams if there is a difference between the > calculated and the incoming DTS? I have a feeling that such measure would > broke a lot of existing command lines...
iam unsure if this concept of timestamp changing in the muxer is a good idea but if its done, there probably should be a warning if it happens and maybe more then that if the difference becomes larger than what is "harmless" but maybe iam missing something Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell
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".
