diff options
author | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2019-05-17 00:30:01 +0200 |
---|---|---|
committer | James Almer <jamrial@gmail.com> | 2019-07-16 16:16:57 -0300 |
commit | 27f40b1dcdff426ed25e7c690ec907d18239ff49 (patch) | |
tree | dba5f8d936215f2d08e3653db2bfabe69d9139c7 /tests/extended.ffconcat | |
parent | 7cb4f8c962bdd0e08881f8ce15f7bdd2d546ba44 (diff) | |
download | ffmpeg-27f40b1dcdff426ed25e7c690ec907d18239ff49.tar.gz |
avformat/matroskadec: Don't abort resyncing upon seek failure
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: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Diffstat (limited to 'tests/extended.ffconcat')
0 files changed, 0 insertions, 0 deletions