Recherche avancée

Sur d’autres sites (7756)

• FFMPEG with VP9 + RTSP

  4 janvier 2021, par Jim Jin

  When we use HEVC + RTSP, ffmpeg works fine. The stream is captured by webcam.

  


  ffmpeg -f dshow -rtbufsize 100M  -f vfwcap -i "0" -strict experimental -c:v hevc_qsv -f rtsp -rtsp_transport tcp rtsp://127.0.0.1/live/test


  


  The output is like :

  


  frame=  355 fps= 37 q=-0.0 size=N/A time=00:00:11.27 bitrate=N/A dup=159 drop=0 speed=1.18x


  


  Then we switch to VP9 + RTSP.

  


  ffmpeg -f dshow -rtbufsize 100M  -f vfwcap -i "0" -strict experimental -c:v libvpx-vp9 -f rtsp -rtsp_transport tcp rtsp://127.0.0.1/live/test


  


  The fps and speed looks too slow :

  


  frame=  263 fps=9.5 q=0.0 size=N/A time=00:00:07.94 bitrate=N/A dup=119 drop=0 speed=0.288x


  


  Then we use ffplay to play the stream. There are a lot of error messages and the video seems frozen.

  


  [vp9 @ 000001c3da86c200] Not all references are available
[vp9 @ 000001c3dffd5700] Not all references are available
[vp9 @ 000001c3da8477c0] Not all references are available
[vp9 @ 000001c3da848240] Not all references are available
[vp9 @ 000001c3da848e40] Not all references are available
[vp9 @ 000001c3e01d2fc0] Not all references are available
[vp9 @ 000001c3e01dd280] Not all references are available
[vp9 @ 000001c3e01e8980] Not all references are available
[vp9 @ 000001c3e01f1880] Not all references are available
[vp9 @ 000001c3da86c200] Not all references are available
[vp9 @ 000001c3dffd5700] Not all references are available
[vp9 @ 000001c3da8477c0] Not all references are available
[vp9 @ 000001c3da848240] Not all references are available
[vp9 @ 000001c3da848e40] Not all references are available
[vp9 @ 000001c3e01d2fc0] Not all references are available
[vp9 @ 000001c3e01dd280] Not all references are available0B f=0/0
[vp9 @ 000001c3e01e8980] Not all references are available
[vp9 @ 000001c3e01f1880] Not all references are available
[vp9 @ 000001c3da86c200] Not all references are available
[vp9 @ 000001c3dffd5700] Not all references are available
[vp9 @ 000001c3da8477c0] Not all references are available
[vp9 @ 000001c3da848240] Not all references are available
[vp9 @ 000001c3da848e40] Not all references are available
[vp9 @ 000001c3e01d2fc0] Not all references are available
[vp9 @ 000001c3e01dd280] Not all references are available
[vp9 @ 000001c3e01e8980] Not all references are available
[vp9 @ 000001c3e01f1880] Not all references are available


  


  Finally, we try hardware VP9 encoder.

  


  ffmpeg -f dshow -rtbufsize 100M  -f vfwcap -i "0" -strict experimental -c:v vp9_qsv -f rtsp -rtsp_transport tcp rtsp://127.0.0.1/live/test


  


  It can't work.

  


  [swscaler @ 0000021e88df9fc0] deprecated pixel format used, make sure you did set range correctly
[vp9_qsv @ 0000021e8687df80] Selected ratecontrol mode is unsupported
[vp9_qsv @ 0000021e8687df80] Low power mode is unsupported
[vp9_qsv @ 0000021e8687df80] Current frame rate is unsupported
[vp9_qsv @ 0000021e8687df80] Current picture structure is unsupported
[vp9_qsv @ 0000021e8687df80] Current resolution is unsupported
[vp9_qsv @ 0000021e8687df80] Current pixel format is unsupported
[vp9_qsv @ 0000021e8687df80] 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
Conversion failed!


  


  So, how can we deal with VP9 + RTSP successfully ?

  


• avutil/mathematics : speed up av_gcd by using Stein’s binary GCD algorithm

  11 octobre 2015, par Ganesh Ajjanagadde

  avutil/mathematics : speed up av_gcd by using Stein’s binary GCD algorithm
  This uses Stein’s binary GCD algorithm :
  
  https://en.wikipedia.org/wiki/Binary_GCD_algorithm
  
  to get a roughly 4x speedup over Euclidean GCD on standard architectures
  
  with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
  
  At the moment, the compiler intrinsic is used on GCC and Clang due to
  
  its easy availability.
  Quick note regarding overflow : yes, subtractions on int64_t can, but the
  
  llabs takes care of that. The llabs is also guaranteed to be safe, with
  
  no annoying INT64_MIN business since INT64_MIN being a power of 2, is
  
  shifted down before being sent to llabs.
  The binary GCD needs ff_ctzll, an extension of ff_ctz for long long (int64_t). On
  
  GCC, this is provided by a built-in. On Microsoft, there is a
  
  BitScanForward64 analog of BitScanForward that should work ; but I can’t confirm.
  
  Apparently it is not available on 32 bit builds ; so this may or may not
  
  work correctly. On Intel, per the documentation there is only an
  
  intrinsic for _bit_scan_forward and people have posted on forums
  
  regarding _bit_scan_forward64, but often their documentation is
  
  woeful. Again, I don’t have it, so I can’t test.
  As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
  
  use a compiled version based on the De-Bruijn method of Leiserson et al :
  
  http://supertech.csail.mit.edu/papers/debruijn.pdf.
  Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
  
  with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
  
  make fate.
  aac-am00_88.err :
  
  builtin :
  
  714 decicycles in av_gcd,    4095 runs,      1 skips
  de-bruijn :
  
  1440 decicycles in av_gcd,    4096 runs,      0 skips
  previous :
  
  2889 decicycles in av_gcd,    4096 runs,      0 skips
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavutil/intmath.h
  • [DH] libavutil/mathematics.c

• libavformat/utils : only run delta_dts_min calculation code when its value is used.

  7 septembre 2011, par Michael Niedermayer

  libavformat/utils : only run delta_dts_min calculation code when its value is used.