Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 29 Dec, 2019 2 commits
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Fix lzo decompression · 2ff687c1
      Andreas Rheinhardt authored 
      When a Matroska Block is only stored in compressed form, the size of
the uncompressed block is not explicitly coded and therefore not known
before decompressing it. Therefore the demuxer uses a guess for the
uncompressed size: The first guess is three times the compressed size
and if this is not enough, it is repeatedly incremented by a factor of
three. But when this happens with lzo, the decompression is neither
resumed nor started again. Instead when av_lzo1x_decode indicates that x
bytes of input data could not be decoded, because the output buffer is
already full, the first (not the last) x bytes of the input buffer are
resent for decoding in the next try; they overwrite already decoded
data.

This commit fixes this by instead restarting the decompression anew,
just with a bigger buffer.

This seems to be a regression since 935ec5a1.

A FATE-test for this has been added.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      2ff687c1
    • Andreas Rheinhardt's avatar
      fate/matroska: Add test for ProRes and bz2 compression · 6c735b96
      Andreas Rheinhardt authored 
      This test tests that demuxing ProRes that is muxed like it should be in
Matroska (i.e. with the first header ("icpf") atom stripped away) works;
it also tests bz2 decompression as well as the handling of
unknown-length clusters.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      6c735b96
  3. 18 Dec, 2019 1 commit
    • Martin Storsjö's avatar
      ffprobe: Fix fate tests for ffprobe in cases where TARGET_PATH differs from the current path · e10654de
      Martin Storsjö authored 
      In these cases, we must pass the full path of the file to ffprobe
(as the current working dir on the remote system, e.g. when invoked
with "ssh remote ffprobe ..." isn't the wanted one).

The input filename passed to ffprobe is also included in the output,
which is part of the reference test data. Add a new option to
ffprobe to allow overriding what path is printed, to keep the
original relative path in the tests.

An alternative approach could be an option to allow requesting omitting
the file name from the dumped data, and updating the test references
accordingly.
Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      e10654de
  5. 17 Dec, 2019 3 commits
  7. 13 Dec, 2019 1 commit
  9. 12 Dec, 2019 2 commits
  11. 11 Dec, 2019 1 commit
    • Martin Storsjö's avatar
      fate: Use a oneoff test for the tremolo filter · c27a85b9
      Martin Storsjö authored 
      The tremolo filter uses floating point internally, and uses
multiplication factors derived from sin(fmod()), neither of
which is bitexact for use with framecrc.

This fixes running this test when built with for mingw/x86_32
with clang.

In this case, a 1 ulp difference in the output from fmod() would
end up in an output from the filter that differs by 1 ulp, but
which makes the lrint() in swresample/audioconvert.c round in a
different direction.
Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      c27a85b9
  13. 08 Dec, 2019 2 commits
  15. 07 Dec, 2019 2 commits
  17. 05 Dec, 2019 1 commit
  19. 02 Dec, 2019 1 commit
  21. 01 Dec, 2019 2 commits
  23. 29 Nov, 2019 3 commits
  25. 19 Nov, 2019 1 commit
  27. 13 Nov, 2019 1 commit
  29. 11 Nov, 2019 1 commit
  31. 30 Oct, 2019 1 commit
  33. 21 Oct, 2019 1 commit
  35. 18 Oct, 2019 1 commit
  37. 07 Oct, 2019 1 commit
    • Andreas Rheinhardt's avatar
      avcodec/flac_parser: Fix off-by-one error · e5e5be4c
      Andreas Rheinhardt authored 
      The flac parser uses a fifo to buffer its data. Consequently, when
searching for sync codes of flac packets, one needs to take care of
the possibility of wraparound. This is done by using an optimized start
code search that works on each of the continuous buffers separately and
by explicitly checking whether the last pre-wrap byte and the first
post-wrap byte constitute a valid sync code.

Moreover, the last MAX_FRAME_HEADER_SIZE - 1 bytes ought not to be searched
for (the start of) a sync code because a header that might be found in this
region might not be completely available. These bytes ought to be searched
lateron when more data is available or when flushing.

Unfortunately there was an off-by-one error in the calculation of the
length to search of the post-wrap buffer: It was too large, because the
calculation was based on the amount of bytes available in the fifo from
the last pre-wrap byte onwards. This meant that a header might be
parsed twice (once prematurely and once regularly when more data is
available); it could also mean that an invalid header will be treated as
valid (namely if the length of said invalid header is
MAX_FRAME_HEADER_SIZE and the invalid byte that will be treated as the
last byte of this potential header happens to be the right CRC-8).

Should a header be parsed twice, the second instance will be the best child
of the first instance; the first instance's score will be
FLAC_HEADER_BASE_SCORE - FLAC_HEADER_CHANGED_PENALTY ( = 3) higher than
the second instance's score. So the frame belonging to the first
instance will be output and it will be done as a zero length frame (the
difference of the header's offset and the child's offset). This has
serious consequences when flushing, as returning a zero length buffer
signals to the caller that no more data will be output; consequently the
last frames not yet output will be dropped.

Furthermore, a "sample/frame number mismatch in adjacent frames" warning
got output when returning the zero-length frame belonging to the first
header, because the child's sample/frame number of course didn't match
the expected sample frame/number given its parent.

filter/hdcd-mix.flac from the FATE-suite was affected by this (the last
frame was omitted) which is the reason why several FATE-tests needed to
be updated.

Fixes ticket #5937.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      e5e5be4c
  39. 26 Sep, 2019 1 commit
  41. 20 Sep, 2019 1 commit
  43. 19 Sep, 2019 2 commits
  45. 11 Sep, 2019 1 commit
  47. 08 Sep, 2019 1 commit
    • Calvin Walton's avatar
      lavfi/concat: allow to support inputs with different frame rates · 3ad5d4df
      Calvin Walton authored 
      Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.

If a later input is higher framerate, this results in dropped frames; if
a later input is lower framerate it might cause judder.

This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".

A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.
      3ad5d4df
  49. 05 Sep, 2019 1 commit
  51. 24 Aug, 2019 1 commit
  53. 17 Aug, 2019 1 commit
  55. 13 Aug, 2019 1 commit
  57. 01 Aug, 2019 1 commit
  59. 29 Jul, 2019 1 commit