Advanced search

On other websites (3363)

• ffmpeg QSV hardware encoder with x11grab screen capture

  11 January 2020, by Toby Eggitt

  I believe I have built ffmpeg with support for my motherboard’s Intel graphics processor chip, but I have not succeeded in showing this working in any way. My goal is to use it for screen capture (the ffmpeg I built does capture screen successfully using the software encoding, but this is far too slow to be useful—it manages about 12fps at a very modest quality).

  My main problem—I think—is that I don’t know how to use these encoders, the examples I found all fail, which makes me suspect that what I’ve built is broken in some way. However, I also have no idea how I can verify that I built this correctly, but the following are true:

  • The five components that I built to get to this all compiled without
    errors (they were libva, gmmlib, intel-media-driver, libmfx, and
    ffmpeg
  • The output of ffmpeg -encoders includes four encoders with _qsv in
    their names including h264_qsv
  • Most of the commands I have tried result in output of this form:

      [h264_qsv @ 0x55ef1dc72040] Low power mode is unsupported
  
      [h264_qsv @ 0x55ef1dc72040] Current frame rate is unsupported
  
      [h264_qsv @ 0x55ef1dc72040] Current picture structure is unsupported
  
      [h264_qsv @ 0x55ef1dc72040] Current resolution is unsupported
  
      [h264_qsv @ 0x55ef1dc72040] Current pixel format is unsupported
  
      [h264_qsv @ 0x55ef1dc72040] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters.
  
      Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

  I have the impression this thing might be fussy about many parameters of this sort but have no idea where to find out what it would like. Any suggestions at all, how to verify it, or better yet, how to issue a command that captures screen and encodes with the hardware, would be most welcome.

• How to handle differing .mp4 file types from different sources?

  10 October 2017, by Dave502619

  If I take a .mp4 recorded on my mobile (Samsung S5) and pass it through FFmpeg with the below command, the output file (fileX.avi) is a greyscale bitmap uncompressed video file.

  • The offset values in fileX.avi (output from FFmpeg) to allow me to locate the video frame data are always 5680 bytes for the file header.

  • And 62 bytes for the inter frame header.

  • The data is uncompressed RGB24 so i can easily calculate the size of a video frame from height x width x 3.

  So my C# application can access the video frames in fileX.avi always at these above offsets.
  (This works great).

  My FFmpeg Command is:

  ffmpeg.exe -i source.mp4 -b 1150 -r 20.97 -g 120 -an -vf format=gray -f rawvideo -pixfmt gray -s 384x216 -vcodec rawvideo -y fileX.avi

  However... I recently took an .mp4 file from a different source (produced by Power Director 14 instead of direct from my mobile phone) and used this as the input source.mp4. But now the structure of fileX.avi differs as the offset values of 5680 + 62 bytes from the start in fileX.avi do not land me at the start of the video data frames.

  There seems to be different file formats for .mp4 - and obviously if there are my crude offset approach will not work for them all. I suspected at the time I wrote the code my method was all too easy a solution!

  So can anyone advise on the approach I should take now? Should I check the original .mp4 or the output file (fileX.avi) to determine a "file type" to which I can determine the different offsets?

  At the very least I need to be able to identify the "type" of .mp4 file that works so I can declare the type that will work with my software.

• lavc/h264dsp: optimise R-V V weight for shorter heights

  1 September 2024, by Rémi Denis-Courmont

  lavc/h264dsp: optimise R-V V weight for shorter heights
  The height is a power of two of up to 16 rows. The current code was
  
  optimised for large sample counts.
  T-Head C908:
  
  h264_weight2_8_c:                                      211.7 ( 1.00x)
  
  h264_weight2_8_rvv_i32:                   before       184.0 ( 1.15x)
  
  h264_weight2_8_rvv_i32:                   after         54.2 ( 3.90x)
  
  h264_weight4_8_c:                                      285.7 ( 1.00x)
  
  h264_weight4_8_rvv_i32:                   before       341.2 ( 0.86x)
  
  h264_weight4_8_rvv_i32:                   after         82.2 ( 3.47x)
  
  h264_weight8_8_c:                                      498.7 ( 1.00x)
  
  h264_weight8_8_rvv_i32:                   before       683.7 ( 0.73x)
  
  h264_weight8_8_rvv_i64:                   after        128.5 ( 3.95x)
  
  h264_weight16_8_c:                                     878.2 ( 1.00x)
  
  h264_weight16_8_rvv_i32:                  unchanged    239.5 ( 3.67x)
  SpacemiT X60:
  
  h264_weight2_8_c:                                      207.2 ( 1.00x)
  
  h264_weight2_8_rvv_i32:                   before       259.6 ( 0.80x)
  
  h264_weight2_8_rvv_i32:                   after         82.2 ( 2.52x)
  
  h264_weight4_8_c:                                      290.8 ( 1.00x)
  
  h264_weight4_8_rvv_i32:                   before       509.6 ( 0.57x)
  
  h264_weight4_8_rvv_i32:                   after         61.5 ( 4.73x)
  
  h264_weight8_8_c:                                      498.8 ( 1.00x)
  
  h264_weight8_8_rvv_i32:                   before      1019.8 ( 0.49x)
  
  h264_weight8_8_rvv_i64:                   after         71.8 ( 6.95x)
  
  h264_weight16_8_c:                                     874.0 ( 1.00x)
  
  h264_weight16_8_rvv_i32:                  unchanged    249.0 ( 3.51x)
  

  • [DH] libavcodec/riscv/h264dsp_init.c
  • [DH] libavcodec/riscv/h264dsp_rvv.S