[FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: fix opAtom audio demuxing

Marton Balint cus at passwd.hu
Mon Mar 5 02:52:19 EET 2018



On Sun, 4 Mar 2018, Tomas Härdin wrote:

> tor 2018-03-01 klockan 22:41 +0100 skrev Marton Balint:
>> Consider edit rate when determining edit_units_per_packet and also make sure
>> that checks are done in edit rate time base and not in stream time base.
>> 
>> Fixes some errors reported with the sample in ticket #5863.
>> 
>> > Signed-off-by: Marton Balint <cus at passwd.hu>
>> ---
>>  libavformat/mxfdec.c | 15 ++++++++++-----
>>  1 file changed, 10 insertions(+), 5 deletions(-)
>> 
>> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>> @@ -2786,6 +2786,7 @@ static AVStream* mxf_get_opatom_stream(MXFContext *mxf)
>>  static void mxf_handle_small_eubc(AVFormatContext *s)
>>  {
>>      MXFContext *mxf = s->priv_data;
>> +    MXFTrack *track;
>>  
>>      /* assuming non-OPAtom == frame wrapped
>>       * no sane writer would wrap 2 byte PCM packets with 20 byte headers.. */
>> @@ -2805,7 +2806,8 @@ static void mxf_handle_small_eubc(AVFormatContext *s)
>>      /* TODO: We could compute this from the ratio between the audio
>>       *       and video edit rates for 48 kHz NTSC we could use the
>>       *       1802-1802-1802-1802-1801 pattern. */
>> -    mxf->edit_units_per_packet = 1920;
>> +    track = st->priv_data;
>> +    mxf->edit_units_per_packet = FFMAX(1, track->edit_rate.num / track->edit_rate.den / 25);
>>  }
>
> That 25 looks a bit arbitrary. But I guess with OPAtom we don't have a
> video edit rate to make use of

25 is selected to mimic existing behaviour (as in 48000/1/25 = 1920,
the edit_units_per_packet value which was used before).

>
> Other than that, patch looks OK

Thanks,
Marton


More information about the ffmpeg-devel mailing list