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

Marton Balint cus at passwd.hu
Sat Mar 7 11:21:33 EET 2020



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...

Regards,
Marton


More information about the ffmpeg-devel mailing list