르마님 방송은 다른 방송보다 재생하기 힘들고, 깨지기도 잘 깨지면서 가끔은 이렇게 화질 변경 문제까지 생깁니다.
무려 비트레이트가 6Mbps 이기 때문에 트랜스코딩 서버의 상태가 안좋은 경우 우선순위에서 밀리는 것이죠. 시청자도 디코딩하기 부담됩니다. 실제로 제 메인 워크스테이션에서 하드웨어 디코더 성능을 50% 이상 사용합니다.
방법은 더 낮은 비트레이트에 더 많은 정보를 넣는 것입니다. 유튜브에 업로드된 컨텐츠는 엄청난 압축 효율을 가지고 있어서 3Mbps로도 1080p60를 제공할 수 있습니다.
압축에는 두 가지 타입이 있습니다. 손실 압축과 무손실 압축.
손실 압축은 사람이 필요로 하지 않는 정보에 노이즈를 섞어서 디테일을 살리는 것입니다. 사람은 원래 이미지와 유사성보다 복잡성을 더 중시합니다. 그래서 이미지의 복잡한 부분의 정보를 노이즈로 치환해서 전송하면 뇌를 속일 수 있습니다. 이것을 양자화(quantisation...스펠링이 맞는진 모름)라고 합니다. 원래 정보가 아니므로 손실이라고도 합니다.
무손실 압축은 아마 다른 사이트에서 더 잘 설명해줄겁니다. 요즘은 z계열 압축을 많이 사용합니다. 보통 압축률을 조절할 수 없습니다.
인코더는 이미지에서 복잡한 부분을 분석하고 이에 따라 적절한 압축 방식을 적용합니다. 양자화에는 거의 자원이 들어가지 않고, 무손실 압축은 자원을 많이 필요로 합니다. 인코더마다 이걸 분석하는 알고리즘이 다릅니다. 분석에도 자원이 필요하기 때문에 빠르게 분석하는 것이 인코더의 성능을 의미합니다.
분석하는데 사용될 자원은 인코더 설정에 따라 달라지는데, 모든 인코더는 프리셋을 가지고 있어서 간편하게 사용량을 지정할 수 있습니다. 이것이 obs에서 볼 수 있는 "품질 우선","속도 우선"같은 설정입니다.
생방송에서 만약 인코더 출력 fps가 입력 fps보다 낮으면 해당 프레임을 생략하고 전송합니다. 르마님 방송에서도 종종 프레임 드랍이 발생합니다.
하지만 비트레이트를 다 채우지 못하면 남은 비트들은 그저 0으로 채워지기 때문에 손실율을 적당히 설정하는 것이 중요합니다.
프리셋을 빠르게 설정할수록 압축을 덜 사용하고 손실을 더 많이 사용합니다. 여기서 손실율은 비트레이트가 정합니다.
최종 목표는 5Mbps까지 평균 비트레이트를 줄이고, 손실은 최소화하면서 최소 65fps 인코더 속도를 확보하는 것입니다.
h264 코덱에서 르마님이 사용할 수 있는 코덱들을 모았습니다.
- libx264
CPU를 사용합니다. GPL 라이선스이고, 현재 시간 대비 가장 효율적인 인코더입니다. 다른 인코더들도 있지만 트위치에서는 사실상 유일한 소프트웨어 인코더입니다.
- h264_nvenc
엔비디아의 CUDA 기술을 사용합니다. CPU를 거의 사용하지 않으며, CUDA 코어만 사용합니다. 또한 시스템 메모리가 아닌 VRAM을 사용합니다.
-h264_qsv
인텔 내장 그래픽과 CPU를 동시에 사용합니다. 시스템 메모리를 사용하며, 병목이 발생하지 않습니다.
현재 르마님 설정은 h264_nvenc -preset fast -cbr 로 추정됩니다.
마인크래프트는 그래픽을 거의 사용하지 않습니다. CPU도 스레드 2~3개만 사용합니다.
이게 문제입니다.
모든 CPU 스레드를 골고루 사용하는 x264를 사용하기 힘듭니다. 같은 작업은 같은 코어에서 완료하려는 경향이 있는데 스레드 하나를 100%로 돌리는 마인크래프트와 싸울 수 있습니다.
그래서 qsv를 먼저 테스트해봤습니다.
테스트 환경은 i5-4460, GTX860M 랩탑입니다. 성능이 많이 안좋지만 이 성능이 르마님 환경에서 확보 가능한 여유 성능(게임이 차지하지 않는)과 비슷합니다.
qsv는 너무 느렸습니다. 양자화는 적절하게 했고 낮은 비트레이트에서도 높은 디테일을 보여주었으나 param tuning을 오래 했는데도 6Mbps에서 30fps를 넘기는데 실패했습니다. 생방송보다 저장이나 멀티GPU 작업에 적합합니다. 하이브리드 프로세싱에서 가능성이 보였기 때문에 테스트는 즐거웠지만 트위치와는 상관없는 일입니다.
nvenc는 잘 모르겠습니다. 10시간정도 튜닝했지만 50~70fps 사이를 오락가락 했습니다. 입력에 따라 속도가 크게 차이나는 것으로 보아 분석 능력이 많이 떨어지는 것으로 보입니다. 하드웨어 인코더는 설계에 따라 효율이 많이 달라지는데 1000시리즈에서는 어떨지 모르겠습니다. 1070의 마인크래프트 플레이 중 여유 성능은 860의 최대 성능과 비슷할 것으로 추정되지만 효율 차이는 있을 수 있습니다.
가능한 튜닝으로 low latency tuning을 켜는 것과 slow 프리셋에서 버퍼를 늘리는 것, 그냥 fast로 돌리는것, 커스텀 프리셋을 사용하는 것을 모두 테스트했습니다.
low latency 모드, VBR 5M 사용 시 손실이 과하게 발생했습니다. slow 프리셋과 조합하니 약 55fps가 나왔습니다.
slow 프리셋과 VBR 5600k, max 6M, bufsize 10M 사용 결과 최소 50, 최대 65fps정도를 달성했습니다. 그럭저럭 괜찮은 성능이지만 현재 방송 세팅과 다른 점은 보이지 않습니다.
p5프리셋, VBR 5M, max 6M, bufsize 12M, rc lookahead 60 설정에서는 추가로 cq값을 지정해주는데 성능이 달려있었습니다. cq 23~26 사이에서 적합한 성능을 보였지만 60fps 방어에는 실패했습니다.
aq와 관련된 설정은 아직 이해하지 못해서 사용하지 못했습니다.
목표를 달성한 설정은 하나도 없었지만 GTX1000 시리즈에서는 다를 것입니다. slow 프리셋, avg 5M, max 6M, rc-lookahead 60, level 4.2가 고려할만한 설정으로 보입니다. 실제 테스트 사용을 통해 알맞은 profile(main/high)과 cq(23~26)을 맞추면 될 것 같습니다.
하지만 obs에는 그런 설정이 없습니다.
x264에서 OpenCL을 사용해서 load 분산을 하는 것도 생각해봤지만 obs에는 그런 설정이 없습니다.
스레드 수를 줄여서 코어 몇개를 비워두는 생각도 했지만 obs에는 그런 설정이 없습니다.
obs는 ffmpeg로 돌아가는데 ffmpeg에 있는 설정이 없습니다.
왜...?
어쩌면 옛날 기기라서 그런 것 일수도 있습니다. 옛날 글카는 드라이버 업데이트도 안해서 프로그램 연동도 잘 안되거든요.
옛날 기기라는게 끝까지 뒷목을 잡네요.
집에 NVIDIA GPU가 없습니다... 이것때문에 하고싶던 딥러닝도 못해보고, 인코딩도 못하네요.
NotLikeThis
르마