Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 30 Mar, 2020 11 commits
    • Andreas Rheinhardt's avatar
      avformat/mxfdec: Correct confusing struct tag · 8d019dbc
      Andreas Rheinhardt authored 
      Don't use typedef struct MXFTrack {...} MXFTimecodeComponent, in
particular given the fact that MXFTrack is a type of its own.
Reviewed-by: 's avatarTomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      8d019dbc
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Check that Cluster has been opened · 5d24b684
      Andreas Rheinhardt authored 
      before setting the field indicating that a Cluster has been opened.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5d24b684
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Remove unused function parameter · 907b7f88
      Andreas Rheinhardt authored 
      end_ebml_master_crc32_preliminary() has a MatroskaMuxContext as
parameter that isn't used at all. So remove it.
Furthermore it doesn't close its dynamic buffer; it just uses the
underlying buffer and therefore it only needs a pointer to the
dynamic buffer, not a pointer to a pointer.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      907b7f88
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Write level 1 elements in one go · d9c21ec6
      Andreas Rheinhardt authored 
      Up until now, writing level 1 elements proceeded as follows: First, the
element id was written to the ordinary output AVIOContext and a dynamic
buffer was opened for the content of the level 1 element in
start_ebml_master_crc32(). Then this buffer was actually used and after it
was closed (in end_ebml_master_crc32()), the size field corresponding to
the buffer's size was written, after which the actual data was written.

This commit changes this: Nothing is written to the main AVIOContext any
more in start_ebml_master_crc32(). end_ebml_master_crc32() now writes
both the id, the length field as well as the data. This implies that
one can start a level 1 element in memory without outputting anything.
This is done to enable to test whether enough space has been reserved
for the Cues (if space has been reserved for them) before writing them.
A large duration between outputting the header and outputting the rest
could also break certain streaming usecases like the one from #8578
(which this commit fixes).
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      d9c21ec6
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Simplify writing Cues · 5e3b7bd5
      Andreas Rheinhardt authored 
      When the Matroska muxer writes the Cues (the index), it groups index
entries with the same timestamp into the same CuePoint to save space.
But given Matroska's variable-length length fields, it either needs
to have an upper bound of the final size of the CuePoint before writing it
or the CuePoint has to be assembled in a different buffer, so that after
having assembled the CuePoint (when the real size is known), the CuePoint's
header can be written and its data copied after it.

The first of these approaches is the currently used one. This entails
finding out the number of entries in a CuePoint before starting the
CuePoint and therefore means that the list is read at least twice.
Furthermore, a worst-case upper-bound for the length of a single entry
was used, so that sometimes bytes are wasted on length fields.

This commit switches to the second approach. This is no longer more
expensive than the current approach if one only resets the dynamic
buffer used to write the CuePoint's content instead of opening a new
buffer for every CuePoint: Writing the trailer of a file with 540.000
CuePoints improved actually from 219054414 decicycles to 2164379394
decicycles (based upon 50 iterations).
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5e3b7bd5
    • Andreas Rheinhardt's avatar
      avformat/aviobuf: Add function to reset dynamic buffer · 639728f5
      Andreas Rheinhardt authored 
      Resetting a dynamic buffer means to keep the AVIOContext and the
internal buffer used by the dynamic buffer. This is done in order to
save (re)allocations when one has a workflow where one opens and closes
dynamic buffers in sequence.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      639728f5
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Avoid allocation for Cues · 5cdd2ebb
      Andreas Rheinhardt authored 
      Up until now, the Matroska muxer would allocate a structure containing
three members: The segment offset, a pointer to an array containing Cue
(index) entries and a counter for said array. It is unnecessary to
allocate it separately and it is unnecessary to contain the segment
offset in said structure, as it duplicates another field contained in
the MatroskaMuxContext. This commit implements the corresponding
changes.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5cdd2ebb
    • 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 2 commits