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

[FFmpeg]

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

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:5 mkver]:
 > 1. What does worse mean? Do you measure the badness by how much output
 differs from the ordinary output with vanilla IO?
 > 2. If so, then you are using the wrong measure: The Matroska/WebM
 muxer's output is supposed to be different for seekable and non-seekable
 output:\\
 >  a) In the seekable case, clusters are by default big, wherease the non-
 seekable mode uses very small clusters (can be overridden with the
 cluster_size_limit and cluster_time_limit options).\\
 >  b) Also, there won't be cues (the index used for seeking) in the non-
 seekable-mode (cues can be at the beginning of the output file (in front
 of the clusters) or at the end. In the first case, one would need to seek
 to the beginning to write them, which is impossible in non-seekable mode.
 In the second case, the position of the cues is being put into the
 SeekHead at the beginning of the file, so that the cues can be found.
 Writing said seekhead would require a seek.\\
 >  c) And there are some more minor differences: If your output format
 weren't WebM, but Matroska, then there would be CRC-32 elements written
 for every level 1 element by default in the seekable mode, but not the
 non-seekable mode. (These elements are invalid for WebM and aren't written
 at all for WebM, so that this difference can't occur in your usecase.)
 Furthermore, in the seekable mode, the duration and a few other elements
 are updated at the end based upon the real duration, in the non-seekable
 mode this can't happen.
 > 3. Are there currently unknown-sized clusters in the output? The only
 thing that should be unknown-sized right now is the "segment" (i.e. you
 should have 0x18 53 80 67 01 FF FF FF FF FF FF FF somewhere at the
 beginning). If so, then everything is as expected.


 Thank you very much for explaining! Now i understand how it works and it's
 not bug. So it can be closed.

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