1. 12 Jan, 2017 1 commit
  2. 11 Jan, 2017 9 commits
  3. 10 Jan, 2017 5 commits
  4. 09 Jan, 2017 7 commits
  5. 08 Jan, 2017 4 commits
  6. 07 Jan, 2017 5 commits
    • Paul B Mahol's avatar
      avformat/riff: extend MagicYUV fourcc list · fd010406
      Paul B Mahol authored
      Newer version of encoder can create such files.
      Signed-off-by: 's avatarPaul B Mahol <onemda@gmail.com>
      fd010406
    • foo86's avatar
      avcodec/dca: add support for 20-bit XLL · 00063843
      foo86 authored
      Fixes ticket #6063.
      Reviewed-by: 's avatarPaul B Mahol <onemda@gmail.com>
      Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      00063843
    • softworkz's avatar
      avformat/matroskaenc: Regression fix for invalid MKV headers · 20e8be0c
      softworkz authored
      The following three commits created a regression by writing initially
      invalid mkv headers:
      
      650e17d8 avformat/matroskaenc: write a
      CRC32 element on Tags
      3bcadf82 avformat/matroskaenc: write a
      CRC32 element on Info
      ee888cfb avformat/matroskaenc: postpone
      writing the Tracks master
      
      Symptoms:
      
      - You can no longer playback a file that is still processed by ffmpeg,
      e.g. VLC fails playback
      - You can no longer stream a file to a client while if is still being
      processed
      - Various diagnosing tools show header errors or incomplete headers
      (e.g. ffprobe, mediainfo, mkvalidator)
      
      Note: The symptoms do not apply to completed files or ffmpeg runs that
      were interrupted with 'q'
      
      Cause:
      
      The mentioned commits made changes in a way that some header elements
      are only partially written in
      mkv_write_header, leaving the header in an invalid state. Only in
      mkv_write_trailer, these elements
      are finished correctly, but that does only occur at the end of the
      process.
      
      Regression:
      
      Before these commits were applied, mkv headers have always been valid,
      even before completion of ffmpeg.
      This has worked reliably over many versions of ffmpeg, to it was an
      obvious regression.
      
      Bugtracker:
      
      This issue has been recorded as #5977 which is resolved by this patch
      
      Patch:
      
      The patch adds a new function 'end_ebml_master_crc32_preliminary' that
      preliminarily finishes the ebml
      element without destroying the buffer. The buffer can be used to update
      the ebml element later during
      mkv_write_trailer. But most important: mkv_write_header finishes with a
      valid mkv header again.
      Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      20e8be0c
    • Clément Bœsch's avatar
    • softworkz's avatar
      libavformat/avio: Add avio_get_dyn_buf function · 9488032e
      softworkz authored
      This commit adds the avio_get_dyn_buf function which allows accessing
      the
      content of a DynBuffer without destroying it.
      
      This is required in matroskaenc for preliminary writing (correct) mkv
      headers.
      
      Context for this change is fixing regression bug #5977.
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      9488032e
  7. 06 Jan, 2017 6 commits
  8. 05 Jan, 2017 3 commits
    • Steven Liu's avatar
    • Rostislav Pehlivanov's avatar
      imdct15: replace the FFT with a faster PFA FFT algorithm · 2d208aaa
      Rostislav Pehlivanov authored
      This commit replaces the current inefficient non-power-of-two FFT with a
      much faster FFT based on the Prime Factor Algorithm.
      Although it is already much faster than the old algorithm without SIMD,
      the new algorithm makes use of the already very throughouly SIMD'd power
      of two FFT, which improves performance even more across all platforms
      which we have SIMD support for.
      
      Most of the work was done by Peter Barfuss, who passed the code to me to
      implement into the iMDCT and the current codebase. The code for a
      5-point and 15-point FFT was derived from the previous implementation,
      although it was optimized and simplified, which will make its future
      SIMD easier. The 15-point FFT is currently using 6% of the current
      overall decoder overhead.
      
      The FFT can now easily be used as a forward transform by simply not
      multiplying the 5-point FFT's imaginary component by -1 (which comes
      from the fact that changing the complex exponential's angle by -1 also
      changes the output by that) and by multiplying the "theta" angle of the
      main exptab by -1. Hence the deliberately left multiplication by -1 at
      the end.
      
      FATE passes, and performance reports on other platforms/CPUs are
      welcome.
      
      Performance comparisons:
      
      iMDCT, PFA:
      101127 decicycles in speed,   32765 runs,      3 skips
      iMDCT, Old:
      211022 decicycles in speed,   32768 runs,      0 skips
      
      Standalone FFT, 300000 transforms of size 960:
          PFA        Old FFT     kiss_fft    libfftw3f
          3.659695s, 15.726912s, 13.300789s, 1.182222s
      
      Being only 3x slower than libfftw3f is a big achievement by itself.
      
      There appears to be something capping the performance in the iMDCT side
      of things, possibly during the pre-stage reindexing. However, it is
      certainly fast enough for now.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      2d208aaa
    • Rostislav Pehlivanov's avatar
      imdct15: remove the AArch64 assembly · 4fdacf4c
      Rostislav Pehlivanov authored
      Prep work for the next commit, which will add a new FFT algorithm
      which makes the iMDCT over 3x faster than it is currently (standalone,
      the FFT is with some framesizes over 10x faster).
      
      The new FFT algorithm uses the already thouroughly SIMD'd power of two
      FFT which already has SIMD for AArch64, so users of that platform will
      still see an improvement.
      
      The previous FFT+SIMD was barely 2.5x faster than the C versions on these
      platforms.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      4fdacf4c