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
Other than that, patch looks OK
/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
