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...
Regards,
Marton
_______________________________________________
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".
