Recherche avancée

Sur d’autres sites (10310)

• FFmpeg with Nvidia GPU - full HW transcode with 50i to 50p deinterlacing

  5 janvier 2018, par Jernej Stopinšek

  I’m trying to do a full hardware transcode of an udp stream to hls
  with 50i to 50p deinterlacing.

  I’m using ffmpeg and Nvidia GPU.

  Since HLS requires deinterlacing

  https://developer.apple.com/library/content/documentation/General/Reference/HLSAuthoringSpec/Requirements.html

  I would like to deinterlace an interlaced source stream and preserve
  as much smooth motion and picture quality as possible.

  My hardware, software and driver info :

  GPU : Tesla P100-PCIE-12GB
  Nvidia Driver Version : 387.26
  Cuda compilation tools, release 9.1, V9.1.85
  FFmpeg from git on 20171218
  
  

  ffmpeg version N-89520-g3f88744067 Copyright (c) 2000-2017 the FFmpeg
  developers built with gcc 6.3.0 (Debian 6.3.0-18) 20170516
  configuration : —enable-gpl
  —enable-cuda-sdk —enable-libx264 —enable-libx265 —enable-nonfree —enable-libnpp —enable-opengl —enable-opencl —enable-libfreetype —enable-openssl —enable-libzvbi —enable-libfontconfig —enable-libfreetype —enable-libfribidi —extra-cflags=-I/usr/local/cuda/include —extra-ldflags=-L/usr/local/cuda/lib64 —arch=x86_64

  libavutil 56. 6.100 / 56. 6.100
  libavcodec 58. 8.100 / 58.
  8.100
  libavformat 58. 3.100 / 58. 3.100
  libavdevice 58. 0.100 / 58. 0.100
  libavfilter 7. 7.100 / 7. 7.100
  libswscale 5.
  0.101 / 5. 0.101
  libswresample 3. 0.101 / 3. 0.101
  libpostproc 55. 0.100 / 55. 0.100

  Input stream info :

  ffmpeg -t 00:05:00 -i udp://xxx.xxx.xxx.xxx:xxxx -map 0:0 -vf idet -c rawvideo -y -f rawvideo /dev/null

  ---

  Input #0, mpegts, from ’udp ://xxx.xxx.xxx.xxx:xxxx’ :
  Duration :
  N/A, start : 49634.159411, bitrate : N/A
  Program xxxxx
  Metadata : service_name :
  service_provider : Stream
  #0:0[0x44d] : Video : h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k
  tbn, 50 tbc
  Stream #0:10x19de : Audio : mp2 ([3][0][0][0] /
  0x0003), 48000 Hz, stereo, s16p, 192 kb/s
  Stream
  #0:20x19e1 : Subtitle : dvb_subtitle ([6][0][0][0] / 0x0006)
  

  Output #0, rawvideo, to ’/dev/null’ :
  Metadata :
  encoder :
  Lavf58.3.100
  Stream #0:0 : Video : rawvideo (I420 / 0x30323449),
  yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 622080 kb/s, 25 fps, 25
  tbn, 25 tbc
  Metadata :
  encoder : Lavc58.8.100 rawvideo
  frame= 7538 fps= 25 q=-0.0 Lsize=22896675kB time=00:05:01.52
  bitrate=622080.0kbits/s dup=38 drop=0 speed=1.02x
  video:22896675kB audio:0kB subtitle:0kB other streams:0kB global
  headers:0kB muxing overhead : 0.000000%
  [Parsed_idet_0 @
  0x56370b3c5080] Repeated Fields : Neither : 7458 Top : 24 Bottom : 18
  [Parsed_idet_0 @ 0x56370b3c5080] Single frame detection : TFF : 281 BFF :
  13 Progressive : 5639 Undetermined : 1567
  [Parsed_idet_0 @
  0x56370b3c5080] Multi frame detection : TFF : 380 BFF : 0 Progressive :
  7120 Undetermined : 0
  

  ---

  This is my command for adaptive hardware deinterlacing. It gives great results with picture, but sound is out of sync.

  ffmpeg -y -err_detect ignore_err -loglevel debug -vsync -1 -hwaccel cuvid -hwaccel_device 1 -c:v h264_cuvid -deint adaptive -r:v 50 -gpu:v 1 -i "udp://xxx.xxx.xxx.xxx:xxxx=?overrun_nonfatal=1&fifo_size=84450&buffer_size=33554432" -map 0:0 -map 0:1 -c:a aac -b:a 196k -c:v h264_nvenc -flags -global_header+cgop -gpu:v 1 -g:v 50 -bf:v 4 -coder:v cabac -b_adapt:v false -b:v 5184000 -minrate:v 5184000 -maxrate:v 5184000 -bufsize:v 2488320 -rc:v cbr_hq -2pass:v true -rc-lookahead:v 25 -no-scenecut:v 1 -profile:v high -preset:v slow -color_range:v 1 -color_trc:v 1 -color_primaries:v 1 -colorspace:v 1 -f hls -hls_time 5 -hls_list_size 3 -start_number 0 -hls_flags delete_segments /srv/hls/program_01/1080p/index.m3u8

  If I add option "-drop_second_field 1" to h264_cuvid and remove -r:v 50 from input and put it to h264_nvenc - then transcoded stream has synced audio, but I think I’m losing quality due to drop_second_field option.

  ffmpeg -y -err_detect ignore_err -loglevel debug -vsync -1 -hwaccel cuvid -hwaccel_device 1 -c:v h264_cuvid -deint adaptive -drop_second_field 1 -gpu:v 1 -i "udp://xxx.xxx.xxx.xxx:xxxx=?overrun_nonfatal=1&fifo_size=84450&buffer_size=33554432" -map 0:0 -map 0:1 -c:a aac -b:a 196k -c:v h264_nvenc -flags -global_header+cgop -gpu:v 1 -g:v 50 -r:v 50 -bf:v 4 -coder:v cabac -b_adapt:v false -b:v 5184000 -minrate:v 5184000 -maxrate:v 5184000 -bufsize:v 2488320 -rc:v cbr_hq -2pass:v true -rc-lookahead:v 25 -no-scenecut:v 1 -profile:v high -preset:v slow -color_range:v 1 -color_trc:v 1 -color_primaries:v 1 -colorspace:v 1 -f hls -hls_time 5 -hls_list_size 3 -start_number 0 -hls_flags delete_segments /srv/hls/program_01/1080p/index.m3u8

  Could someone please point me in the right direction how to properly deinterlace with cuvid and minimal possible loss of quality ?

• FFMPEG low bitrate at starting frames

  21 janvier 2018, par Y. T

  So I noticed that the first 1-4s of the videos that I’m converting start with a low bitrate and gradually increase untill its around the specified bitrate (-crf 17 -minrate 2000k -maxrate 3000k -bufsize 2000k).

  ...
  
  frame= 37 fps= 0.0 q=24.0 size = 113kB time=00:00:02.08 bitrate= 443.5kbits/s
  
  frame= 66 fps= 64 q=30.0 size = 619kB time=00:00:03.20 bitrate= 1581.6kbits/s
  
  frame= 99 fps= 64 q=28.0 size = 1106kB time=00:00:04.52 bitrate= 2002.2kbits/s
  
  frame= 131 fps= 63 q=23.0 size = 1599kB time=00:00:05.82 bitrate= 2247.8kbits/s
  
  ...

  I already tried changing several settings like -crf, -b:v, -minrate, -maxrate and -bufsize. From my trial-and-error experience, the lower the -crf / higher -b:v, the faster it reaches an appropriate bitrate, but it still has this "lagg" in the beginning of the conversion.

  Is it possible to immediately start with, for example 2000kbits/s, at the start of the conversion ?

  EDIT

  Around the first 1-30s (roughly), the clips are more pixelated than the rest of the clip. See this image for a comparison (zoomed in on area of an 1080p clip). The rest of the clip doesn’t have any visible loss like this (1850kbps encoded vs 2000kbps original), so I still assume it has something to do with the start of the encoding.

• FFMPEG - how to identify a bottleneck in hardware transcoding ?

  26 août 2021, par Henry

  In the provided example I was trying to transcode a 4K h264 source to a 1080p h264 output using Nvidia's Hardware acceleration.

  


  Relevant information :

  


  ffmpeg version git-2017-12-25-613f789 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
  libavutil      56.  7.100 / 56.  7.100
  libavcodec     58.  9.100 / 58.  9.100
  libavformat    58.  3.100 / 58.  3.100
  libavdevice    58.  0.100 / 58.  0.100
  libavfilter     7.  7.100 /  7.  7.100
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100


  


  Command used :

  


  ffmpeg -c:v h264_cuvid -i "4K_input.mp4" -c:v h264_nvenc -preset slow -s 1920x1080 -c:a copy output.mkv


  


  Relevant PC Specs :

  


  GPU: (Gigabyte) GeForce GTX 1070 Ti
CPU: Intel Core i7 7700K
Memory: 8GB DDR4 2400MHz Single Channel.
SSD: Crucial CT525MX3


  


  While the Nvidia Desktop recording has absolutely no issues to record live h264 video in up to 50Mbps bitrates, this encoding at below 2600kbps was extremely slow utilizing barely 35% GPU.
I was unable to utilize 100% of the GPU on any video parameters.

  


  This is why I could use some advice concerning how to identify a (suspected) bottleneck.