Recherche avancée

Sur d’autres sites (3190)

• Problem to capture a video in 4K with FFmpeg

  16 mars 2020, par Ale7

  I am a new user of FFmpeg. I am trying to capture a ten minutes video in mp4 format, on 4 4K’s slot and 4 FHD’s slot with cards video Pro Capture by Magewell.
  My machine has the following characteristics :

  • OS : Windows Server 2012
  • RAM : 64 GB
  • CPU : 2 processors Intel Xeon E5-2640 v3 @ 2.60 GHz

  The FFmpeg script, for slot 4K (I change resolution for FHD), used is the following :

  ffmpeg -rtbufsize 2048M -re -y -thread_queue_size 20384 -pix_fmt yuv420p -f dshow -video_size 3840x2160 -r 50 -i video="Video (05-0 Pro Capture HDMI 4K+)"  -codec:v libx264  -preset ultrafast -threads 8 -pix_fmt yuv420p -tune fastdecode -bufsize 2048M output.mp4

  This command is the best solution found at the moment, but the CPU goes up to 100% and the buffer fills up quickly and starts to drop the frames.
  So, my question : Is there a way to improve it or is a limit, principally, of the my machine ?
  If it is a machine limit, you would indicate me the minium requirments to do that.

  Thanks in advance to everyone.

• ffmpeg gets stuck at 20 FPS on 4Kp30

  1er mars 2023, par Ivy Growing

  Please, help me to understand why putting OBS between the capture card and the ffmpeg improves the FPS rate.

  


  Details :

  


  timeit ffmpeg -y -init_hw_device qsv=hw -filter_hw_device hw -hwaccel qsv -f dshow -video_size 3840x2160 -rtbufsize 2002000k -framerate 30 -c:v rawvideo -i video="USB Capture HDMI 4K+" -r 30 -t 00:01:00 -c:v h264_qsv -preset veryfast -b:v 10000K -movflags faststart -f mpegts output4kqsv.mpg -benchmark
...
Input #0, dshow, from 'video=USB Capture HDMI 4K+':
  Duration: N/A, start: 787911.842300, bitrate: N/A
  Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422(tv, bt709/bt709/unknown), 3840x2160, 30 fps, 30 tbr, 10000k tbn
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_qsv))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'output4kqsv.mpg':
  Metadata:
    encoder         : Lavf59.27.100
  Stream #0:0: Video: h264, nv12(tv, bt709/bt709/unknown, progressive), 3840x2160, q=2-31, 10000 kb/s, 30 fps, 90k tbn
    Metadata:
      encoder         : Lavc59.37.100 h264_qsv
...
frame= 1800 fps= 19 q=17.0 Lsize=   74557kB time=00:00:59.90 bitrate=10196.5kbits/s speed=0.648x
...
Elapsed Time:     0:01:34.749


  


  Capturing the video from the capture card is limited to 19-20 FPS and speed 0.65. Tried million tweaks like changing codec from QSV to pure software, changing bitrate, presets, flags, etc - nothing helps.

  


  However, if the same capture card is sourced to OBS and the OBS is set as Virtual camera then it's 30 FPS and speed 1.0 :

  


  timeit ffmpeg -y -init_hw_device qsv=hw -filter_hw_device hw -hwaccel qsv     -f dshow -video_size 3840x2160 -rtbufsize 2002000k -framerate 30 -i video="OBS Virtual Camera" -r 30 -t 00:01:00      -c:v h264_qsv -preset veryfast -b:v 10000K -movflags faststart -f mpegts obs4kqsv1.mpg -benchmark
...
Input #0, dshow, from 'video=OBS Virtual Camera':
  Duration: N/A, start: 1576816.988000, bitrate: N/A
  Stream #0:0: Video: rawvideo (NV12 / 0x3231564E), nv12, 3840x2160, 30 fps, 30 tbr, 10000k tbn
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_qsv))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'obs4kqsv1.mpg':
  Metadata:
    encoder         : Lavf59.27.100
  Stream #0:0: Video: h264, nv12(progressive), 3840x2160, q=2-31, 10000 kb/s, 30 fps, 90k tbn
    Metadata:
      encoder         : Lavc59.37.100 h264_qsv
...
frame= 1800 fps= 30 q=17.0 Lsize=   74629kB time=00:00:59.90 bitrate=10206.3kbits/s speed=0.999x
...
Elapsed Time:     0:01:02.780


  


  Is OBS just providing "artificial" extra frames ?

  


  How to tweak the ffmpeg command to have all 30 FPS encoded ?

  


• Minimal Understanding of VP8′s Forward Transform

  16 novembre 2010, par Multimedia Mike — VP8

  Regarding my toy VP8 encoder, Pengvado mentioned in the comments of my last post, “x264 looks perfect using only i16x16 DC mode. You must be doing something wrong in computing residual or fdct or quantization.” This makes a lot of sense. The encoder generates a series of elements which describe how to reconstruct the original image. Intra block reconstruction takes into consideration the following elements :

  
  
  

  I have already verified that both my encoder and FFmpeg’s VP8 decoder agree precisely on how to reconstruct blocks based on the predictors, coefficients, and quantizers. Thus, if the decoded image still looks crazy, the elements the encoder is generating to describe the image must be wrong.

  So I started studying the forward DCT, which I had cribbed wholesale from the original libvpx 0.9.0 source code. It should be noted that the formal VP8 spec only defines the inverse transform process, not the forward process. I was using a version designated as the “short” version, vs. the “fast” version. Then I looked at the 0.9.5 FDCT. Then I got the idea of comparing the results of each.

  input:   92 91 89 86 91 90 88 86 89 89 89 88 89 87 88 93

  • libvpx 0.9.0 “short” :

    forward : -314 5 1 5 4 5 -2 0 0 1 -1 -1 1 11 -3 -4
    inverse : 92 91 89 86 89 86 91 90 91 90 88 86 88 86 89 89
    

  • libvpx 0.9.0 “fast” :

    forward : -314 4 0 5 4 4 -2 0 0 1 0 -1 1 11 -2 -5
    inverse : 91 91 89 86 88 86 91 90 91 90 88 86 88 86 89 89
    

  • libvpx 0.9.5 “short” :

    forward : -312 7 1 0 1 12 -5 2 2 -3 3 -1 1 0 -2 1
    inverse : 92 91 89 86 91 90 88 86 89 89 89 88 89 87 88 93
    

  I was surprised when I noticed that input[] != idct(fdct(input[])) in some of the above cases. Then I remembered that the aforementioned property isn’t what is meant by a “bit-exact” transform– only that all implementations of the inverse transform are supposed to produce bit-exact output for a given vector of input coefficients.

  Anyway, I tried applying each of these forward transforms. I got slightly differing results, with the latest one I tried (the fdct from libvpx 0.9.5) producing the best results (to my eye). At least the trees look better in the Big Buck Bunny logo image :

  
  
  The dense trees of the Big Buck Bunny logo using one of the libvpx 0.9.0 forward transforms
  
  
  The same segment of the image using the libvpx 0.9.5 forward transform
  

  Then again, it could be that the different numbers generated by the newer forward transform triggered different prediction modes to be chosen. Overall, adapting the newer FDCT did not dramatically improve the encoding quality.

  Working on the intra 4×4 mode encoding is generating some rather more accurate blocks than my intra 16×16 encoder. Pengvado indicated that x264 generates perfectly legible results when forcing the encoder to only use intra 16×16 mode. To be honest, I’m having trouble understanding how that can possibly occur thanks to the Walsh-Hadamard transform (WHT). I think that’s where a lot of the error is creeping in with my intra 16×16 encoder. Then again, FFmpeg implements an inverse WHT function that bears ‘vp8′ in its name. This implies that it’s custom to the algorithm and not exactly shared with H.264.