使用 FFMPEG,传输大部分静态图片的最轻松方式是什么?(就带宽而言)

使用 FFMPEG,传输大部分静态图片的最轻松方式是什么?(就带宽而言)

我想优化类似广播的 YouTube 或 Twitch 直播,其进度条每秒刷新 5 次。除了这个进度条,视频的其他部分都是静态的。每隔 10 分钟左右,直播就会转到新的轨道,整个屏幕应该会发生变化。

为了使其更加清晰,这里有一些屏幕外观的插图。

赛道的开始是这样的:

+++++++++++++++++++++++++++++
+  First track name         +
+                ,          +
+  BG n⁰1     _ `|.         +
+            /o`=|          +
+     .=""=./::(.=""=.      +
+    /./.' .::::. \'. \     +
+   //\/ / :::::: \/\ \\    +
+  /\/ /\/\'::::'/\ \/\ \   +
+  /' `     '::'     ` `\   +
+           /::\            +
+          /\/\/\           +
+                           +
+  Progress-bar is below    +
+  |                   |    +
+                           +
+++++++++++++++++++++++++++++

大约 10 分钟内,唯一的变化就是进度条:

+++++++++++++++++++++++++++++
+  First track name         +
+                ,          +
+  BG n⁰1     _ `|.         +
+            /o`=|          +
+     .=""=./::(.=""=.      +
+    /./.' .::::. \'. \     +
+   //\/ / :::::: \/\ \\    +
+  /\/ /\/\'::::'/\ \/\ \   +
+  /' `     '::'     ` `\   +
+           /::\            +
+          /\/\/\           +
+                           +
+  Progress-bar is below    +
+  |==========         |    +
+                           +
+++++++++++++++++++++++++++++

当曲目结束时,10 分钟后,整个图像应该改变以显示新的背景:

+++++++++++++++++++++++++++++
+  Second track name        +
+                           +
+  (the whole screen        +
+   should have refreshed)  +
+                           +
+  BG n⁰2        ,-.        +
+        ,      ( {o\       +
+        {`"=,___) (`~      +
+         \  ,_.-   )       +
+    ~^~^~^`- ~^ ~^ '~^~    +
+                           +
+                           +
+  Progress-bar is below    +
+  |                   |    +
+                           +
+++++++++++++++++++++++++++++

为了继续讨论实际问题,我目前有一个可以使用此 ffmpeg 命令的解决方案:

 ffmpeg -f x11grab -s "1280x720" -i :99.0+0,0 -f pulse -i default -f flv \
   -vcodec libx264 -b:v 1000k -maxrate 1360k -bufsize 1360k -g 60 -tune stillimage \
   -s "1280x720" -preset veryfast -vf "format=yuv420p" \
   "rtmp://SERVER_EITHER_YOUTUBE_OR_TWITCH/STREAM_KEY"

然而,这种解决方案会导致相对较高的带宽消耗:

  • 一秒钟内,上传速度约为 900-1000 KB/s
  • 一秒钟内,上传速度约为 1500-1600 KB/s

我们可以在 的输出中看到这种模式nload -t 100,其中每个字符对应 100 毫秒:

Device eth0 [xyz.xyz.xyz.xyz] (1/1):
====================================================================================
Incoming:
                                                               Curr: 60.77 kBit/s
                                                               Avg: 72.08 kBit/s
                                                               Min: 52.23 kBit/s
                                                               Max: 252.88 kBit/s
                                                               Ttl: 118.24 GByte
Outgoing:

   #||||..|||          #|.|||..|#          #|..|...|#          Curr: 1002.47 kBit/s
   ##########          ##########          ##########          Avg: 1.24 MBit/s
|#|##########.||||##|||##########.||#||##|.##########..||..||  Min: 749.30 kBit/s
#############################################################  Max: 8.83 MBit/s
#############################################################  Ttl: 92.46 GByte

我尝试降低比特率,但图像却变得明显不均匀。

在理想世界中,此流将使用少十倍的带宽完成:

  • 每 2 秒上传一次屏幕图片(约 100 kB,png 格式),作为关键帧
  • 否则传输音频和进度条的细微变化的速度会低于 100 kB/s

所以问题是,是否有一个与流媒体服务约束(每 2 秒一个关键帧)兼容的 ffmpeg 设置,可以实现较低的带宽同时保持高质量?




编辑我尝试使用该-crf 23选项,ffmpeg 命令变成了这样:

 ffmpeg -f x11grab -s "1280x720" -i :99.0+0,0 -f pulse -i default -f flv \
   -vcodec libx264 -crf 23 -g 60 -tune stillimage \
   -s "1280x720" -preset veryfast -vf "format=yuv420p" \
   "rtmp://SERVER_EITHER_YOUTUBE_OR_TWITCH/STREAM_KEY"

好的一面是,带宽确实减少了,这是一个进步。但我仍然看到这个矩形信号,一秒钟的低带宽消耗为 300 KB/s,一秒钟的高带宽消耗为 1300 KB/s。

 Device eth0 [xyz.xyz.xyz.xyz] (1/1):                                                 
 =================================================================================
 Incoming:
                                                                 Curr: 76.65 kBit/
                                                                 Avg: 76.11 kBit/s
                                                                 Min: 10.08 kBit/s
                                                                 Max: 9.78 MBit/s
                                                                 Ttl: 118.88 GByte
 Outgoing:
 
                                                                 Curr: 1.26 MBit/s
  ||||||||||          |||||||||          ||||||||||          ||  Avg: 1.09 MBit/s
  ##########          ##########         ##########          ##  Min: 55.66 kBit/s
  ##########         |##########         ##########          ##  Max: 10.86 MBit/s
 ####################################|||#######################  Ttl: 103.00 GByte

相关内容