[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