[FFmpeg-trac] #7847(avformat:new): Mkv customIO wrong cluster

[FFmpeg]

#7847: Mkv customIO wrong cluster
-------------------------------------+-------------------------------------
             Reporter:  lunatichai   |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mkv          |               Blocked By:
  avio_alloc_context                 |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by mkver):

 * keywords:  mkv cluster avio_alloc_context => mkv avio_alloc_context


Comment:

 That's strange: Your hex stuff says that the cluster has been written as
 unknown-length cluster (usually every element has its length at the
 beginning, but it is also legal to use an "unknown length field" (like
 0x01FFFFFFFFFFFFFFFF) which is designed for streaming. But actually the
 Matroska muxer tries to avoid this: Both in the codepath for seekable
 output and for non-seekable output no unknown-length cluster should be
 written.
 More exactly, the non-seekable codepath (that's the one that should be
 used for your sample as you did not specify a seek function) works like
 this: The whole cluster (including the Cluster ID and the size field) is
 written into a temporary buffer. The size of the buffer is updated in the
 (seekable) buffer before it is actually output to your IO context.
 Meanwhile, the seekable codepath currently looks like this: The Cluster ID
 is written and an unknown length field for the cluster (the 1F 43 B6 75 01
 FF FF FF FF FF FF FF). Then the cluster is written into a temporary
 buffer. When it is decided to close the current cluster, the temporary
 buffer is written to the output IO, a seek to the length field is
 performed and the length field is overwritten with the real length.

 What you describe shouldn't happen in the case that the customIO isn't
 seekable. Did you change the seekable flag somewhere? The output is
 exactly what I expect when the AVIOContext isn't seekable, but claims to
 be.

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