Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 16 Jul, 2019 1 commit
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Don't abort resyncing upon seek failure · 27f40b1d
      Andreas Rheinhardt authored 
      When an error happens, the Matroska demuxer tries to resync to level 1
elements from an earlier position onwards. If the seek to said earlier
position fails, the demuxer currently treats this as an unrecoverable
error. And that behaviour is suboptimal as said failure is nothing
unrecoverable or unexpected (when the input isn't seekable).
It is preferable to simply resync from the earliest position available
(i.e. the start of the AVIOContext's buffer) onwards if the seek failed.

Here are some scenarios that might be treated as unrecoverable errors
by the current code if the input isn't seekable. They all have in
common that the current position is so far away from the desired
position that the seek can't be fulfilled from the AVIOContext's buffer:

1. Blocks (both SimpleBlocks as well as a Block in a BlockGroup) for
which reading them as binary EBML elements succeeds, but whose parsing
triggers an error (e.g. an invalid TrackNumber). In this case the
earlier position from which resyncing begins is at the start of the block
(or even earlier).
2. BlockGroups, whose parsing fails in one of the latter elements. Just
as in 1., the start of the BlockGroup (the target of the seek) might be
so far away from the current position that it is no longer in the
buffer.
3. At the beginning of parsing a cluster, the cluster is parsed until a
SimpleBlock or a BlockGroup is encountered. So if the input is damaged
between the beginning of the cluster and the first occurrence of a
SimpleBlock/BlockGroup and if said damage makes the demuxer read/skip so
much data that the beginning of the cluster is no longer in the buffer,
demuxing will currently fail completely.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      27f40b1d
  3. 15 Jul, 2019 4 commits
  5. 14 Jul, 2019 15 commits
  7. 13 Jul, 2019 9 commits
  9. 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
  11. 11 Jul, 2019 7 commits