Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 14 Jul, 2019 11 commits
  3. 13 Jul, 2019 9 commits
  5. 12 Jul, 2019 4 commits
    • Marton Balint's avatar
      avformat/mpegts: respect program number when merging streams · 81d3d7dd
      Marton Balint authored 
      merge_pmt_versions was not usable if multiple programs were present because
when it was searching for candidate streams it did not make sure that the PMT was
of the same program. This caused the streams of all programs to get merged into
a single (garbled) program.

This patch makes sure that the program number (service ID) is also matching
with the old streams when parsing the PMT making the feature useful for multi
program streams.

This change might cause issues for single program streams if the program number
changes, but I think it is acceptable because the goal of the option is to make
the parsing resilient to PID changes, and that is still working as expected.
Signed-off-by: 's avatarMarton Balint <cus@passwd.hu>
      81d3d7dd
    • Marton Balint's avatar
      avformat/movenc: use unspecified language by default · 397abca0
      Marton Balint authored 
      English was used before.
Signed-off-by: 's avatarMarton Balint <cus@passwd.hu>
      397abca0
    • Andreas Rheinhardt's avatar
      lavf/webm_chunk: Correct duration if start time > 0 · 24a64e04
      Andreas Rheinhardt authored 
      Up until now, it was simply presumed that the first packet had a pts of
zero; otherwise the duration of the first chunk was wrong.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      24a64e04
    • Andreas Rheinhardt's avatar
      lavf/webm_chunk: Fix NULL dereference · 8c6ee762
      Andreas Rheinhardt authored 
      The earlier version of the webm_chunk muxer had several bugs:

1. If the first packet of an audio stream didn't have a PTS of zero,
then no chunk will be started before a packet is delivered to the
underlying Matroska/WebM muxer, i.e. the AVFormatContext used to write
these packets had a NULL as AVIOContext for output. This is behind the
crash in ticket #5752.

2. If an error happens during writing a packet, the underlyimg
Matroska/WebM muxer context is freed. This leads to a use-after-free
coupled with a double-free in webm_chunk_write_trailer (which supposes
that the underlying AVFormatContext is still valid).

3. Even when no error occurs at all, webm_chunk_write_trailer is still
buggy: After the underlying Matroska/WebM muxer has written its trailer,
ending the chunk implicitly flushes it again which is illegal at this
point.

These bugs have been fixed.

Fixes #5752.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      8c6ee762
  7. 11 Jul, 2019 7 commits
  9. 10 Jul, 2019 7 commits
  11. 09 Jul, 2019 2 commits
    • Andreas Rheinhardt's avatar
      truehd_core: Switch to in-place modifications · 5a481b15
      Andreas Rheinhardt authored 
      The truehd_core bitstream filter decreases the sizes of the
major_sync_info structure (if present), of the
substream_directory and of the substreams themselves. As a consequence,
there is enough space available in front of the actual substream data
for the new header, so that one only needs to modify the header in front
of the actual data (which apart from shrinking is left untouched) and
the packet's size and buffer pointer (after having made sure that the
packet is writable).

This and switching to bsf_get_packet_ref also removed the need for
having separate packets for in- and output.

Even if the input is not writable, there are noticable performance
improvements: The average of 10 iterations of processing a file with 262144
runs each (inlcuding about 20 skips per iteration) went down from 5669
to 4362 decicycles. If the input is writable, it goes down to 1363
decicycles.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5a481b15
    • Andreas Rheinhardt's avatar
      truehd_core: Use byte offsets instead of bit offsets · 836065b2
      Andreas Rheinhardt authored 
      Words of 16 bit are the unit for TrueHD's size and offset fields;
in particular the sizes of the high-level structures of TrueHD are
always a multiple of a byte; yet truehd_core unnecessarily used
bit offsets at several places. This has been changed.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      836065b2