sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> Also use common code with opAtom.
>
> Fixes ticket #2776.
> Partially fixes ticket #5671.
> Fixes ticket #5866.
>
> > Signed-off-by: Marton Balint <c...@passwd.hu>
> ---
> libavformat/mxfdec.c | 281
> ++++++++++++++++++++++++---------------------------
> 1 file changed, 130 insertions(+), 151 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>
> - next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
> -
> - if (next_ofs >= 0 && klv.next_klv > next_ofs) {
> - /* if this check is hit then it's possible OPAtom was
> treated as OP1a
> - * truncate the packet since it's probably very large (>2
> GiB is common) */
> - avpriv_request_sample(s,
> - "OPAtom misinterpreted as OP1a? "
> - "KLV for edit unit %"PRId64" extending
> into "
> - "next edit unit",
> - mxf->current_edit_unit);
> - klv.length = next_ofs - avio_tell(s->pb);
> + next_ofs = mxf_set_current_edit_unit(mxf, st, pos, 1);
> +
> + if (track->wrapping != FrameWrapped) {
> + int64_t size;
> +
> + if (next_ofs <= 0) {
> + // If we have no way to packetize the data, then return
> it in chunks...
> + int64_t max_packet_size = 33554432;
Any reason for this particular number?
Can't really digest the rest of this patch
/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
