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 <c...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
