[FFmpeg-trac] #8083(avformat:new): Matroska demuxer fails to parse big attachements

[FFmpeg]

#8083: Matroska demuxer fails to parse big attachements
------------------------------------+------------------------------------
             Reporter:  Zenitram    |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  1           |
------------------------------------+------------------------------------

Comment (by Zenitram):

 > Is there any limit on the size of the attachments that you intend to
 store in Matroska?

 I actually did not plan to have such big attachment, such size is due to
 messy input (invalid? I would say yes because the content is not parsable
 by any DPX parser conform to spec, it is just "random" content appended to
 the end of the DPX files) and I need to store this content in the MKV file
 for the purpose of the tool.
 So the limit is infinite (if I have 1 MB of DPX real content + 1 GB of
 garbage, I need to store this 1 GB per DPX file in the resulting MKV).

 > These exist so that (potentially intentionally) damaged data does not
 cause arbitrarily big allocations.

 I see two cases to handle:
 - legitimate big element that should not make FFmpeg allocate big amount
 of RAM; in that case, the element should be skipped with a warning (not an
 error) and the stream synced to the next expected element (not trying to
 sync inside the "bad" element as it is currently).
 - damaged data; I totally understand the idea of trying to sync inside the
 "bad" element but here I don't see a good method for detecting damaged
 data (FileData element should not be bigger than the nesting Attachments
 element, but I guess that such test is already done).

 So I suggest to remove MATROSKA_ID_FILEDATA from the list of tests. This
 element is only at the beginning of the file, so not having this test
 should not hurt much here + if the MATROSKA_ID_FILEDATA is too big, we
 skip it without allocating RAM.

 Note: MATROSKA_ID_BLOCKADDITIONAL could also be legitimate to be big (no
 limitation of opaque data), but IMO more problematic because it can be at
 each block.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8083#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker