.png)
진행률 표시줄이 초당 5회 새로 고쳐지는 YouTube 또는 Twitch용 라디오와 같은 스트림을 최적화하고 싶습니다. 이 진행률 표시줄을 제외하고 비디오의 다른 부분은 정적입니다. 약 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"
그러나 이 솔루션은 상대적으로 높은 대역폭 소비를 초래합니다.
- 1초 동안 업로드는 ~ 900-1000KB/s의 속도로 수행됩니다.
- 1초 동안 업로드는 ~ 1500-1600KB/s의 속도로 수행됩니다.
이 패턴은 a의 출력에서 볼 수 있으며 nload -t 100, 여기서 각 문자는 100ms에 해당합니다.
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
비트 전송률을 줄이려고 했지만 영상이 눈에 띄게 고르지 않게 되었습니다.
이상적인 세상에서, 이 스트림은 10배 더 적은 대역폭으로 수행됩니다.
- 2초마다 키프레임으로 업로드되는 화면 사진(png의 경우 약 100kB)
- 그렇지 않으면 오디오를 전송하는 데 100kB/s 미만이고 진행률 표시줄의 작은 변화가 나타납니다.
그래서 질문은,고품질을 유지하면서 더 낮은 대역폭을 달성할 수 있는 스트리밍 서비스의 제약 조건(2초마다 1개의 키프레임)과 호환되는 ffmpeg 설정이 있습니까?
편집하다옵션을 사용하려고했는데 -crf 23ffmpeg 명령이 다음과 같습니다.
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"
좋은 점은 대역폭이 줄어들었고 이는 개선된 점입니다. 하지만 이 직사각형 신호는 여전히 300KB/s에서 1초의 낮은 대역폭 소비와 1300KB/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