1. 20 Mar, 2020 1 commit
  2. 16 Mar, 2020 2 commits
  3. 11 Mar, 2020 1 commit
  4. 10 Mar, 2020 1 commit
  5. 05 Mar, 2020 1 commit
    • Andreas Rheinhardt's avatar
      h264_mp4toannexb: Try to avoid four byte startcodes · 518bbe9e
      Andreas Rheinhardt authored
      According to the H.264 specifications, the only NAL units that need to
      have four byte startcodes in H.264 Annex B format are SPS/PPS units and
      units that start a new access unit. Before af7e953a, the first of these
      conditions wasn't upheld as already existing in-band parameter sets
      would not automatically be written with a four byte startcode, but only
      when they already were at the beginning of their input packets. But it
      made four byte startcodes be used too often as every unit that is written
      together with a parameter set that is inserted from extradata received a
      four byte startcode although a three byte start code would suffice
      unless the unit itself were a parameter set.
      
      FATE has been updated to reflect the changes. Although the patch leaves
      the extradata unchanged, the size of the extradata according to the FATE
      reports changes. This is due to a quirk in ff_h2645_packet_split which
      is used by extract_extradata: If the input is Annex B, the first zero of
      a four byte startcode is considered a part of the last unit (if any).
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      518bbe9e
  6. 02 Mar, 2020 1 commit
  7. 24 Feb, 2020 1 commit
  8. 23 Feb, 2020 1 commit
  9. 22 Feb, 2020 1 commit
  10. 15 Feb, 2020 3 commits
  11. 08 Feb, 2020 1 commit
  12. 07 Feb, 2020 1 commit
  13. 04 Feb, 2020 1 commit
  14. 30 Jan, 2020 2 commits
  15. 29 Jan, 2020 1 commit
  16. 27 Jan, 2020 1 commit
  17. 26 Jan, 2020 1 commit
  18. 24 Jan, 2020 1 commit
  19. 16 Jan, 2020 1 commit
  20. 14 Jan, 2020 1 commit
  21. 10 Jan, 2020 1 commit
  22. 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
  23. 28 Dec, 2019 2 commits
  24. 27 Dec, 2019 3 commits
  25. 21 Dec, 2019 3 commits
  26. 18 Dec, 2019 2 commits
    • Martin Storsjö's avatar
      checkasm: aacpsdsp: Tolerate extra intermediate precision in stereo_interpolate · aad0e26f
      Martin Storsjö authored
      The stereo_interpolate functions add h_step to the values h
      BUF_SIZE times. Within the stereo_interpolate C functions, the
      values h (h0-h3, h00-h13) are declared as local float variables,
      but the compiler is free to keep them in a register with extra
      precision.
      
      If the accumulation is rounded to 32 bit float precision after
      each step, the less significant bits of h_step end up ignored
      and the sum can deviate, affecting the end result more than
      the currently set EPS.
      
      By clearing the log2(BUF_SIZE) lower bits of h_step, we make sure
      that the accumulation shouldn't differ significantly, regardless
      of any extra precision in the accmulating register/variable.
      
      This fixes the aacpsdsp checkasm test when built with clang for
      mingw/x86_32.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      aad0e26f
    • 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
  27. 17 Dec, 2019 3 commits