Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 30 Mar, 2020 4 commits
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Cosmetics · 6cf69f0e
      Andreas Rheinhardt authored 
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      6cf69f0e
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Avoid unnecessary seek · b1c3d711
      Andreas Rheinhardt authored 
      When writing the SeekHead (a form of index) at the end of the muxing
process, mkv_write_seekhead() would first seek to the position where the
SeekHead ought to be written, then write it there and seek back to the
original position afterwards. Which means: To the end of the file.
Afterwards, a seek to the beginning of the file is performed to update
further values. This of course means that the second seek in
mkv_write_seekhead() was unnecessary.

This has been changed: A new parameter was added to mkv_write_seekhead()
containing the destination for the second seek, effectively eliminating
the seek to the end of the file after writing the SeekHead.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      b1c3d711
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Check for failure when writing SeekHead · 8c89fc18
      Andreas Rheinhardt authored 
      mkv_write_seekhead() would up until now try to seek to the position where
the SeekHead ought to be written, write the SeekHead and seek back. The
first of these seeks was checked as was writing, yet the seek back was
unchecked. Moreover the return value of mkv_write_seekhead() was unchecked
(the ordinary return value was the position where the SeekHead was written).

This commit changes this: Everything is checked. In the unseekable case
(where the first seek may nevertheless work when it happens in the buffer)
a failure at the first seek is not considered an error. In any case,
failure to seek back is an error.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      8c89fc18
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Improve calculating EBML ID size · e6ea75a3
      Andreas Rheinhardt authored 
      When the Matroska muxer writes an EBML ID, it calculates the length of
said ID before; and it does this as if this were a number that needs to
be encoded as EBML number: The formula used is (av_log2(id + 1) - 1) / 7
+ 1. But the constants used already contain the VINT_MARKER (the leading
bit indicating the length of the EBML number) and therefore the algorithm
used makes no sense. Instead the position of the most significant byte
set gives the desired length.

The algorithm used until now worked because EBML numbers are subject to
restrictions: If the EBML number takes up k bytes, then the bit 1 << (7
* k) is set and av_log2(id) is 7 * k. So the current algorithm produces
the correct result unless the EBML ID is of the form 7 * k - 1 because
of the "id + 1". But contrary to encoding lengths as EBML number (where
the + 1 exists to avoid the encodings reserved for unknown length),
such EBML numbers are simply forbidden as EBML IDs and as such none of
them were ever written.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      e6ea75a3
  3. 29 Mar, 2020 5 commits
  5. 28 Mar, 2020 9 commits
  7. 27 Mar, 2020 13 commits
  9. 26 Mar, 2020 9 commits