1. 05 Aug, 2019 1 commit
  2. 04 Aug, 2019 3 commits
    • Rodger Combs's avatar
      build: add support for building CUDA files with clang · 01994c93
      Rodger Combs authored
      This avoids using the CUDA SDK at all; instead, we provide a minimal
      reimplementation of the basic functionality that lavfi actually uses.
      It generates very similar code to what NVCC produces.
      
      The header contains no implementation code derived from the SDK.
      The function and type declarations are derived from the SDK only to the
      extent required to build a compatible implementation. This is generally
      accepted to qualify as fair use.
      
      Because this option does not require the proprietary SDK, it does not require
      the "--enable-nonfree" flag in configure.
      Signed-off-by: 's avatarTimo Rothenpieler <timo@rothenpieler.org>
      01994c93
    • Stefan Schoenefeld's avatar
      ad97be9f
    • Stefan Schoenefeld's avatar
      avcodec/h263dec: fix hwaccel decoding · 39a5c0ac
      Stefan Schoenefeld authored
      Recently we encountered an issue when decoding a h.263 file:
      
      FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not directly related to NVDEC but is a problem that shows with several other HW decoders like VDPAU, though the exact kind of error is different (either error messages or freezing[1]). The root cause is that ff_thread_finish_setup() is called twice per frame from ff_h263_decode_frame(). This is not supported by ff_thread_finish_setup() and specifically checked for and warned against in the functions code. The issue is also specific to hw accelerated decoding only as the second call to ff_thread_finish_setup() is only issued when hw acceleration is on. The fix is simple: add a check that the first call is only send when hw acceleration is off, and the second call only when hw acceleration is on (see attached patch). This works fine as far as I was able to test with vdpau and nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if available.
      
      I also noticed a secondary issue when browsing through the code which is that, according to documentation, ff_thread_finish_setup() should only be called if the codec implements update_thread_context(), which h263dec does not. The patch does not address this and I'm not sure any action needs to be taken here at all.
      
      [1] This is depending on whether or not the hw decoder sets the  HWACCEL_CAPS_ASYNC_SAFE flag
      Signed-off-by: 's avatarTimo Rothenpieler <timo@rothenpieler.org>
      39a5c0ac
  3. 03 Aug, 2019 15 commits
  4. 02 Aug, 2019 4 commits
  5. 01 Aug, 2019 2 commits
  6. 31 Jul, 2019 8 commits
  7. 30 Jul, 2019 4 commits
  8. 29 Jul, 2019 3 commits
    • Andreas Rheinhardt's avatar
      cbs_mpeg2: Fix parsing the last unit · fd93d5ef
      Andreas Rheinhardt authored
      There is one way to find out if avpriv_find_start_code has found a start
      code or not: One has to check whether the state variable contains a
      start code, i.e. whether the three most significant bytes are 0x00 00 01.
      Checking for whether the return value is the end of the designated
      buffer is not enough: If the last four bytes constitute a start code,
      the return value is also the end of the buffer. This happens with
      sequence_end_codes which have been ignored for exactly this reason,
      although e.g. all three files used for fate tests of cbs_mpeg2 contain
      sequence_end_codes.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      fd93d5ef
    • Andreas Rheinhardt's avatar
      cbs_mpeg2: Rearrange start code search · 276b21a5
      Andreas Rheinhardt authored
      1. Currently, cbs_mpeg2_split_fragment uses essentially three variables
      to hold the start code values found by avpriv_find_start_code. By
      rearranging the code, one of them can be omitted.
      2. The return value of avpriv_find_start_code points to the byte after
      the byte containing the start code identifier (or to the byte after the
      last byte of the fragment's data if no start code was found), but
      cbs_mpeg2_split_fragment needs to work with the pointer to the byte
      containing the start code identifier; it already did this, but in a
      clumsy way. This has been changed.
      3. Also use the correct type for the variable holding the
      CodedBitstreamUnitType.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      276b21a5
    • Andreas Rheinhardt's avatar
      cbs_mpeg2: Decompose Sequence End · 0e66e1b6
      Andreas Rheinhardt authored
      Sequence End units (or actually, sequence_end_codes) have up until now
      not been decomposed; in fact due to a bug in cbs_mpeg2_split_fragment they
      have mostly been treated as part of the preceding unit. So implement
      decomposing them as preparation for fixing said bug.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      0e66e1b6