Recherche avancée

Sur d’autres sites (5243)

• avcodec/hevc_filter : Pass HEVCLocalContext when slice-threading

  29 juin 2022, par Andreas Rheinhardt

  avcodec/hevc_filter : Pass HEVCLocalContext when slice-threading
  The HEVC decoder has both HEVCContext and HEVCLocalContext
  
  structures. The latter is supposed to be the structure
  
  containing the per-slicethread state.
  Yet that is not how it is handled in practice : Each HEVCLocalContext
  
  has a unique HEVCContext allocated for it and each of these
  
  coincides with the main HEVCContext except in exactly one field :
  
  The corresponding HEVCLocalContext.
  
  This makes it possible to pass the HEVCContext everywhere where
  
  logically a HEVCLocalContext should be used.
  This commit stops doing this for lavc/hevc_filter.c ; it also constifies
  
  everything that is possible in order to ensure that no slice thread
  
  accidentally modifies the main HEVCContext state.
  There are places where this was not possible, namely with the SAOParams
  
  in sao_filter_CTB() or with sao_pixels_buffer_h in copy_CTB_to_hv().
  
  Both of these instances lead to data races, see
  
  https://fate.ffmpeg.org/report.cgi?time=20220629145651&slot=x86_64-archlinux-gcc-tsan-slices
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/hevc_filter.c
  • [DH] libavcodec/hevcdec.c
  • [DH] libavcodec/hevcdec.h

• avcodec/svq1enc : Use unsigned for parameter >= 0 to workaround GCC bug

  10 juillet 2022, par Andreas Rheinhardt

  avcodec/svq1enc : Use unsigned for parameter >= 0 to workaround GCC bug
  encode_block() in svq1enc.c looks like the following :
  static int encode_block(int block[7][256], int level)
  
  
  
      int best_score = 0 ;
  
      for (unsigned x = 0 ; x < level ; x++) 
  
          int v = block[1][x] ;
  
          block[level][x] = 0 ;
  
          best_score      += v * v ;
  
      
      if (level > 0 && best_score > 64) 
  
          int score = 0 ;
  
          score += encode_block(block, level - 1) ;
  
          score += encode_block(block, level - 1) ;
          if (score < best_score) 
  
              best_score = score ;
  
          
  
      
      return best_score ;
  
  
  When called from outside of encode_block(), it is always called with
  
  level == 5.
  This triggers a bug [1] in GCC : On -O3, it creates eight clones of
  
  encode_block with different values of level inlined into it. The clones
  
  with negative values are of course useless*, but they also lead to
  
   Warray-bounds warnings, because they access block[-1].
  This has been mitigated in GCC 12 : It no longer creates clones
  
  for parameters that it knows are impossible. Somehow switching levels
  
  to unsigned makes GCC know this. Therefore this commit does this.
  
  (For GCC 11, this changes the warning to "array subscript 4294967295 is
  
  above array bounds" from "array subscript -1 is below array bounds".)
  [1] : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
  * : These clones can actually be discarded when compiling with
  
   ffunction-sections.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/svq1enc.c

• avcodec/mpegvideo_enc : Fix a chroma mb size error in sse_mb()

  4 juillet 2022, par Wenbin Chen

  avcodec/mpegvideo_enc : Fix a chroma mb size error in sse_mb()
  For 422 frames we should not use hard coded 8 to calculate mb size for
  
  uv plane. Chroma shift should be taken into consideration to be
  
  compatiple with different sampling format.
  The error is reported by fate test when av_cpu_max_align() return 64
  
  on the platform supporting AVX512. This is a hidden error and it is
  
  exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
  mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
  
  squared error) on current mb, reconstructed mb will be wrote to the
  
  previous mb space, so that the memory can be saved. However if the align
  
  is 64, the frame is shared in somewhere else, so the frame cannot be
  
  reused and a new frame to store reconstrued data is created. Because the
  
  height of mb is wrong when compute sse on 422 frame, starting from the
  
  second line of macro block, changed data is read when frame is reused
  
  (we need to read row 16 rather than row 8 if frame is 422), and unchanged
  
  data is read when frame is not reused (a new frame is created so the
  
  original frame will not be changed).
  That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d exposes this
  
  issue, because it add av_cpu_max_align() and this function return 64 on
  
  platform supporting AVX512 which lead to creating a frame in mpeg2enc,
  
  and this lead to the different outputs.
  Signed-off-by : Wenbin Chen <wenbin.chen@intel.com>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavcodec/mpegvideo_enc.c
  • [DH] tests/ref/seek/vsynth_lena-mpeg2-422
  • [DH] tests/ref/vsynth/vsynth1-mpeg2-422
  • [DH] tests/ref/vsynth/vsynth2-mpeg2-422
  • [DH] tests/ref/vsynth/vsynth3-mpeg2-422
  • [DH] tests/ref/vsynth/vsynth_lena-mpeg2-422