On Wed, 13 Jun 2018, Tomas Härdin wrote:
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?
Not really, I chose 32 MB because it is big enough to not fragment typical exotic files (e.g.: GOP wrapped, etc), but small enough so allocating this much RAM in one packet does not cause any issues if we encounter a huge KLV with some unknown (clip?) wrapping.
To be frank, I am still not sure if this should actually work or not, or if the parser system of libavformat can make something useful out of a chunked source like this or not, I don't seem to have an MXF file which triggers this.
Can't really digest the rest of this patch
Yeah, it is quite complex, I don't see an easy way to split it, sorry. Regards, Marton _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
