Recherche avancée

Sur d’autres sites (12452)

• Exactly what parameters are needed by libva/VAAPI to decode an H.264 video frame ?

  12 juillet 2022, par Synthetix

  I've got a basic Linux app running on supported Intel hardware that uses Intel's libva (VAAPI) to decode H.264 frames from an MP4 file. I have the entire thing working except the part where the frame gets submitted to the GPU/decoder. What's unclear is exactly what information to submit, when, and it what order. I don't see any official documentation on this, either. Here's the point in the code I'm referring to :

  


  vaBeginPicture(...)
vaRenderPicture(...)
vaEndPicture(...)


  


  The functions vaBeginPicture and vaEndPicture are self-explanatory, but my issue is with vaRenderPicture. I would expect to need to send the SPS and PPS (out of the AVCC atom in the MP4 file), then each frame, or slice of frames to the decoder via vaRenderPicture(). But this isn't mentioned anywhere other than in code examples I've found online. From some of these examples, I've surmised the following :

  


  vaRenderPicture() // call 1/4: VAPictureParameterBufferH264: Send picture params? e.g. frame size and SPS/PPS?
vaRenderPicture() // call 2/4: VAIQMatrixBufferH264: Send inverse matrix? Where do I get this?
vaRenderPicture() // call 3/4: VASliceParameterBufferH264: Parameters of the next slice of H.264 picture data?
vaRenderPicture() // call 4/4: Slice Data? The actual compressed H.264 data from the file?


  


  I have a very rudimentary understanding of how H.264 data is arranged in an MP4. But the libva documentation, as far as I can tell, does not explain exactly what is needed and in what order to successfully decode a frame. Furthermore, the buffer structures submitted to the decoder have an extensive amount of fields, which implies I need to know a ton of information about the frames before I submit them. In other video APIs I've used, none of this is needed. Why so complex ?

  


  Any pointers to documentation on exactly what parameters, data and how to arrange it all before submitting to the VAAPI decoder would be much appreciated.

  


• Compiling FFMPEG with libvpx on Mac OS X

  26 août 2014, par Dalvik

  I’m having hard timed trying to manually compile FFMPEG on my MAC. I’m trying to compile it with —enable-libvpx but keep getting this annoying error :

  ERROR: libvpx decoder version must be >=0.9.1"

  I’m compiling FFMPEG using this guide by ROMAN10 and this link from the FFMPEG official documentation. You can find the build script I’m using in ROMAN’s web page.

  Note : I’m working with HomeBrew because I found it easier and more convenient tool from which I can install all the core packages that ffmpeg requires(yasm,libogg,libvorbis and more).

  In an efforts to solve it I’ve try to fix ffmpeg’s ./configure file and notice that the link to libvpx is as follow :

  enabled libvpx            && {
  
  enabled libvpx_vp8_decoder && { check_lib2 "vpx/vpx_decoder.h vpx/vp8dx.h" vpx_codec_dec_init_ver -lvpx ||
  
                                  die "ERROR: libvpx decoder version must be >=0.9.1"; }
  
  enabled libvpx_vp8_encoder && { check_lib2 "vpx/vpx_encoder.h vpx/vp8cx.h" "vpx_codec_enc_init_ver VP8E_SET_MAX_INTRA_BITRATE_PCT" -lvpx ||
  
                                  die "ERROR: libvpx encoder version must be >=0.9.7"; }
  
  enabled libvpx_vp9_decoder && { check_lib2 "vpx/vpx_decoder.h vpx/vp8dx.h" "vpx_codec_vp9_dx" -lvpx || disable libvpx_vp9_decoder; }
  
  enabled libvpx_vp9_encoder && { check_lib2 "vpx/vpx_encoder.h vpx/vp8cx.h" "vpx_codec_vp9_cx VP9E_SET_AQ_MODE" -lvpx || disable libvpx_vp9_encoder; } }

  You can see that the method check_lib2 receives 2 params - the header path and the function’s name. Unfortunately even when I’m changing the path to a downloaded version of libvpx(which is much newer than 0.9.1) I’m still getting this error. Any help would be much appreciated.

• lavu/riscv : CPU flag for the Zbb extension

  2 octobre 2022, par Rémi Denis-Courmont

  lavu/riscv : CPU flag for the Zbb extension
  Unfortunately, it is common, and will remain so, that the Bit
  
  manipulations are not enabled at compilation time. This is an official
  
  policy for Debian ports in general (though they do not support RISC-V
  
  officially as of yet) to stick to the minimal target baseline, which
  
  does not include the B extension or even its Zbb subset.
  For inline helpers (CPOP, REV8), compiler builtins (CTZ, CLZ) or
  
  even plain C code (MIN, MAX, MINU, MAXU), run-time detection seems
  
  impractical. But at least it can work for the byte-swap DSP functions.
  

  • [DH] libavutil/cpu.c
  • [DH] libavutil/cpu.h
  • [DH] libavutil/riscv/cpu.c
  • [DH] tests/checkasm/checkasm.c