1. 25 Mar, 2020 1 commit
    • Andreas Rheinhardt's avatar
      avformat/webmdashenc: Don't use custom option for bitexactness · 00d0934f
      Andreas Rheinhardt authored
      The WebM DASH Manifest muxer can write manifests for live streams and
      these contain an entry that depends on the time the manifest is written;
      an AVOption to make the output reproducible has been added for tests.
      But this is unnecessary, as there already is a method for reproducible
      output: The AVFMT_FLAG_BITEXACT-flag of the AVFormatContext. Therefore
      this commit removes the custom option.
      
      Given that the description of said option contained "private option -
      users should never set this" and that it was not documented in
      muxers.texi, no deprecation period for this option seemed necessary.
      
      The commands of the FATE-tests for this muxer have been changed to no
      longer use this option.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      00d0934f
  2. 16 Mar, 2020 2 commits
  3. 10 Mar, 2020 1 commit
  4. 22 Feb, 2020 1 commit
  5. 07 Feb, 2020 1 commit
  6. 04 Feb, 2020 1 commit
  7. 30 Jan, 2020 1 commit
  8. 29 Jan, 2020 1 commit
  9. 27 Jan, 2020 1 commit
  10. 26 Jan, 2020 1 commit
  11. 14 Jan, 2020 1 commit
  12. 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
  13. 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
  14. 17 Dec, 2019 3 commits
  15. 13 Dec, 2019 1 commit
  16. 12 Dec, 2019 2 commits
  17. 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
  18. 08 Dec, 2019 2 commits
  19. 07 Dec, 2019 2 commits
  20. 05 Dec, 2019 1 commit
  21. 02 Dec, 2019 1 commit
  22. 01 Dec, 2019 2 commits
  23. 29 Nov, 2019 3 commits
  24. 19 Nov, 2019 1 commit
  25. 13 Nov, 2019 1 commit
  26. 11 Nov, 2019 1 commit
  27. 30 Oct, 2019 1 commit
  28. 21 Oct, 2019 1 commit
  29. 18 Oct, 2019 1 commit
  30. 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