[FFmpeg-devel] [PATCH v2 7/7] avformat/audiointerleave: use a fixed frame duration for non-audio packets

[Michael Niedermayer]

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 <cus at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200308/83522781/attachment.sig>