This article is available in English.
와우자 스트리밍 엔진 트랜스코더를 CBR 모드로 운영하는 것은 불가능하다. 설정 옵션은 있으나 실제로는 적용되지 않는다. CBR 모드의 버그를 찾아 기술 지원팀과 소통하며 공식 버그(ENG-2346)로 등록하기까지 1개월간의 기록과 1년 후의 현황을 공유한다.
삽질의 시작 : VBR 모드가 왜 없지?
본 필자가 블로그에 작성하는 모든 글은 실제로 운영했거나 현재 운영하고 있는 서비스 또는, 계획하고 있는 서비스의 테스트베드를 구축하는 과정을 하나하나 재현해 가며 작성하고 있다. 본 필자의 부족한 기억력을 보조하는 동시에 혹시나 모를 오류를 방지하고 독자 제위와 정확한 정보를 공유하고자 하는 작은 소망이 있기 때문이다.
본 필자가 꾸역꾸역 와우자 스트리밍 엔진(Wowza Streaming Engine, 이하 와우자)에 관한 글을 쓰며 트랜스코더에 대한 내용을 다루기 시작했을 때, 한 가지 당황스러운 상황을 만나게 되었다.
어? 왜 트랜스코딩 옵션에 VBR이 없지?
생각해 보니 본 필자는 VBR(Variable Bit Rate : 가변 전송률)을 사용할 일이 거의 없었다. VBR을 사용할 일이라고 해봐야 과거 RealVideo나 위성장비 만지던 시절이었고, 대부분은 CBR(Constant Bit Rate : 고정 전송률) 기반 시스템들을 다뤄 왔었다. 그 오랜 기간 와우자를 다뤄오면서도 VBR 설정 항목이 없다는 것을 눈치채지 못할 만큼 말이다. (맞다. 사실 핑계다..)
하지만 이제까지 수많은 인코더와 트랜스코더를 다뤄 오며, CBR·VBR 선택 옵션이 없는 장비를 본 기억은 없었다. 와우자 트랜스코더에 대한 글을 작성하며 너무나도 당연히 이 부분부터 다루려 했던 필자가 혼란에 빠진 순간이었다.
그렇지, 없을 리가 없지
일단 관련된 자료를 뒤져보기 시작했으나, CBR·VBR 설정과 관련된 의미 있는 자료를 찾을 수 없었다. 그렇게 여기저기 뒤적이던 중, 하나의 단서를 찾게 되었다.
Updated transcoder VBR target to peak bitrate range from varying values per-implementation to 110% everywhere
트랜스코더의 VBR 타겟을 최대 비트레이트의 110%로 수정함
그렇지! 명색이 트랜스코더인데 VBR 옵션이 없을 리가 없지! 실마리를 얻은 본 필자는 이 내용을 가지고 와우자 기술지원에 문의를 했고, 몇 시간 지나지 않아 와우자로부터 답변이 도착했다. 그 내용은 트랜스코더 템플릿 파일에 아래와 같은 파라미터를 추가하면 된다는 것이었다.
<Parameter>
<Name>mainconcept.bit_rate_mode</Name>
<Value>2</Value> <!-- 0 = CBR, 1 = CQT, 2 = VBR, 3 = TQM -->
<Type>Long</Type>
</Parameter>필자는 글을 이어갈 수 있다는 기쁜 마음을 가지고 설정을 적용시키고 CBR과 VBR의 차이를 실제 눈으로 보이기 위해 VLC의 디코딩 비트레이트를 캡처하려 했다. 그리고 본격적인 삽질이 시작되었다.
본격적인 삽질 : 어? 이거 아닌데?
뭐가 다른 거야?
본 필자는 하나의 라이브 어플리케이션에 두 개의 트랜스코더 프리셋을 생성하고, UDP 멀티캐스트 방식으로 전송되는 9 Mbps MPEG-TS 스트림을 입력했다. 두 프리셋의 목표 비트레이트는 동일하게 설정하되, 하나에만 VBR 파라미터를 추가했다.
- 기본 트랜스코딩 프리셋 출력 비디오 비트레이트 3.65Mbps 적용
- 기본 트랜스코딩 프리셋 출력 비디오 비트레이트 3.65Mbps 적용 후 VBR 파라미터 적용
서로 다른 트랜스코더를 거친 두 출력 스트림의 비트레이트의 변화는 당연히 다르게 나타나야 한다. 하지만 실제로 확인한 두 스트림의 비트레이트 변화는 동일했으며, 모드를 CBR로 변경해도 역시 결과는 동일했다. 즉, CBR로 설정하든 VBR로 설정하든 바뀐 게 하나도 없었다.
설정을 잘못 집어넣은 건가 싶어 ffprobe로 측정한 비트레이트 데이터와 사용한 transrate.xml을 가지고 와우자에 재문의했더니 며칠 후 이런 내용의 답변이 도착했다.
I’d also suggest testing with a more dynamic source (fast movement, scene changes, etc.) to give the encoder more reason to vary the bitrate.
정적인 화면에서는 비트레이트 변화도 작으니까 동적인 화면으로 시험해 보셈
이 답변을 받는 순간, 본 필자는 촉이 왔다. 이거.. 답 나오기 힘들겠네..
눈을 크게 뜨고 보라고!
콘텐츠 문제라 말하는 데에는 두 눈으로 직접 보여주는 게 답이다. 동적인 화면이라고 하면 보통 콘서트나 스포츠 중계와 같은 콘텐츠를 생각한다. 본 필자도 동의하지만, 그 못지않게 동적인 콘텐츠가 있으니 바로 변신소녀가 등장하는 애니메이션이다.
위 영상은, 실험 당시 사용된 콘텐츠의 저작권 보호를 위해 와우자에 보낸 캡처 파일의 오디오와 비디오를 가공한 것이다. 비록 모자이크지만 충분히 동적인 콘텐츠인 것을 알 수 있을 것이다. 영상 아래에는 VLC의 정보창이 나타나고 있다.
여기서 주의 깊게 봐야 할 지표는 다음 세 가지다.
- 입력 미디어 데이터 크기
- VLC가 수신한 스트림의 누적 데이터 크기다. 두 트랜스코더는 서로 다른 프로파일로 동작하고 있으므로, 스트림 데이터의 크기가 같지 않아야 한다.
- 입력 비트 전송속도 그래프
- VLC가 수신한 스트림의 비트레이트 변화 기록이다. CBR과 VBR은 인코딩 방식이 다르기 때문에 그 형태가 서로 달라야 한다.
- 디먹스 데이터 크기
- VLC가 스트림에서 재생에 사용한 데이터의 크기로, 역시 두 스트림의 크기가 같지 않아야 한다.
그리고 당연히 저 세 가지 지표의 움직임은 CBR 모드와 VBR 모드가 동일했다. 본 필자는 이 내용을 정리해 캡처한 동영상과 함께 와우자에 답장을 보냈다.
또 며칠이 흐르고 와우자에서 기다리던 답장이 왔다. 그리고 그 내용은 본 필자가 외국 회사와 이야기하고 있다는 것을 다시 한 번 깨닫게 해 주었다.
…Wowza Streaming Engine’s default behavior already uses VBR encoding. So, unless you’re explicitly changing it to a different mode (like CBR), VBR is the default behavior out-of-the-box….
확인해 보니까 VBR 먹은 거 맞고, 그게 원래 기본값이래. CBR로 시험해 봐
좋아, 그렇다면 이건 뭐야?
해외 업체의 기술지원은 국내 업체와 많이 다르다. (해외의 대응이 더 상식적인 것이라는 건 동의한다.) 그네들은 상식 수준의 기본적인 것부터 확인을 시작한다. 기본과 절차에 따라 확인하는 것은 당연한 일이지만, 가끔 이렇게 벙 찌는 느낌을 받는 것은 어쩔 수 없다. (장비 문제로 새벽 2시에 프랑스에 전화했더니 ‘접지는 연결했냐?’라고 물어본 Thomson 엔지니어의 목소리가 지금도 기억에 생생하다.) CBR로 바꾸는 거! 당연히 진작에 해 봤지! 안 해 봤겠는가 말이다!
그러다 문득, 뭔가 빼먹고 있다는 생각을 하게 되었다. 일반적으로 장비들의 VBR 설정에는 따라다니는 추가적인 파라메터들이 있는데 보통 아래의 세 가지 정도는 된다.
- Max Bitrate
- 가변 비트레이트 동작 시 넘기지 말아야 하는 최댓값
- Min Bitrate
- 가변 비트레이트 동작 시 넘기지 말아야 하는 최솟값
- Q-Factor
- 화질과 압축률에 영향을 주는 여러 가지 품질 계수다. 인코더에 따라 I-frame, B-frame, P-frame별 값을 따로 지정하기도 한다.
개별 파라메터들을 독립적으로 설정할 수 없는 장비라도 프리셋이나 모드의 개념을 통해 저 세 가지는 변경할 수 있게 한다. 그런데, 와우자 설정에서 이러한 설정을 본 적이 없었다.
이 파라메터들에 대한 기본값이나 조정하는 방법을 알면 트랜스코더에 대해 좀 더 깊숙하게 파헤쳐 볼 수 있을 것이다. 그래서 와우자에 CBR 설정은 진작에 해 보았다는 말과 함께, 저 세 가지 값에 대한 정보를 달라고 답장을 보냈다.
그리고 수일이 지나고 와우자에서는 이렇게 답장을 보내왔다.
..I could replicate the issue you reported… …we currently do not have any documented…
..여기서 실험해 보니 정말 니 말대로 안 된다.. ..세 가지 값에 대해서 정리해 놓은 건 아직 없어..
이제서야 제작사에서도 재현이 되었다고 한다. 이제 시작이다! (그런데, 그럼 이제까지 너네는 대체 뭘 한 거냐..)
삽질의 결과는 큰 바위
트랜스코더의 추가적인 파라메터 정보
다음날, 트랜스코더의 상세 설정을 위한 몇 가지 옵션들에 대한 내용이 담긴 메일이 와우자에서 도착했다. 이 메일에는 궁금해하던 여러 파라메터들뿐 아니라 여러 숨겨진 설정 항목에 대한 내용이 상세하게 들어 있었다.
이번에는 뭔가 건질 게 있겠다는 생각이 든 본 필자는, 신나게 설정을 적용해 봤고 드디어 유의미한 차이를 확인하는 데 성공했다.
결국 만난 것은 커다란 바위
추가 파라메터를 적용하자 출력 스트림의 특성이 달라진다는 사실은 확인했으니, 이 값들의 기본값이 얼마인지 알면 기본 프로파일의 동작을 이해하고 글을 작성하는 데 좀 더 도움이 될 것이다. 본 필자는 각 파라메터의 기본값을 알려 달라고 다시 문의했고, 며칠 후 다음과 같은 답변을 받았다.
there are no internal defaults applied for these parameters they default to 0.
다른거 없고 그냥 0이야
그리고 추가적으로 이런 내용이 함께 담겨 있었다.
I checked with our Product Management team, and they confirmed that this is indeed a bug. I’ve gone ahead and created a bug ticket for it in our internal system
이거 버그 맞고, 정식으로 버그 등록했어.
결국 CBR과 VBR 설정을 아무리 바꾸고 콘텐츠와 측정 방법을 달리해도 결과가 같았던 이유는 본 필자의 설정 실수나 시험 조건 때문이 아니었다. 와우자에서도 인정한 제품의 버그였다.
끝까지 삽질하며 열심히 땅을 파 본 결과는 삽으로는 더 이상 팔 수 없는 커다란 바위였다. 그리고 이 바위를 치우는 일은 이제 와우자의 몫으로 남게 되었다.
마무리
최초의 질문으로부터 이슈 등록까지 한 달이 넘는 기간이 걸렸다. 비록 순간 답답함이 있을 때도 있었으나, 와우자의 담당자는 성실하게 본 필자의 이슈에 대응해 주었다. (그리고 현재도 대응 중이기도 하다.) 이슈의 여부를 떠나, 와우자의 기술지원은 나쁘지 않다는 게 본 필자의 생각이다.
와우자는 오랜 기간 동안 현업에서 사용되어 온 프로그램이다. 그 기능과 안정성에 대해서는 긴 기간 동안 충분히 검증되었으며 이에 대해서 절대로 이견이 없는 바이다. 하지만 본 필자는, 와우자는 기본적으로 오리진 서버라고 생각한다. 인코딩과 트랜스코딩은 가능하면 외부의 전용 장비에서 처리하고, 와우자는 스트림의 입력과 프로토콜 변환, 분배에 집중시키는 구성을 선호한다. 각 장비의 역할이 분리되면 장애 원인을 추적하거나 출력 품질을 관리하기도 수월하기 때문이다.
단, 이 말은 와우자 트랜스코더는 쓸 게 못된다는 소리가 아님을 기억해 주기 바란다. 지금도 수많은 스트림들이 와우자 트랜스코더를 사용해 송출되고 있으며, OTT의 세계에서 CBR은 사실 사용되는 곳이 한정되어 있기 때문이다. 사실, 본 필자도 블로그를 작성하기 위해 파고들지 않았더라면, 지금까지 그랬던 것처럼 모르고 잘만 썼을 것이다.
본 필자가 발견한 현상은 와우자에서 공식적인 버그로 인정했고, 버그 추적 번호 ENG-2346으로 등록됐다. 여기서부터 원인을 분석하고 수정하는 일은 와우자가 처리해야 할 영역이다.
본 필자는 와우자 사용자의 한 사람으로서, 사용하는 프로그램이 조금 더 개선되는 데 한 숟가락 얹었다는 것과 그 과정에서 트랜스코더의 동작을 좀 더 깊이 이해하게 된 것으로 만족한다. 무엇보다 본 필자와 같은 문제로 생각과 시간을 낭비할 독자 제위에게 작은 참고가 될 만한 글 하나를 남겼으니, 그것으로 충분하다.
그리고 1년 후
와우자 스트리밍 엔진 트랜스코더의 CBR 버그가 ENG-2346으로 등록된 것은 이다. 그리고 약 1년이 지난 , DectENG.com에 있던 게시글을 eqmaker.kr로 옮기던 본 필자는 문득 이 버그가 해결되었는지 궁금해졌다. 그래서 와우자 기술지원에 진행 상태를 물어봤고 다음과 같은 답변을 받게 되었다.
I checked the bug ticket: ENG-2346 that was raised for this issue, and I can confirm that it is currently in progress. Our engineering team is actively working on it; however, we do not have an estimated timeline for when the fix will be completed.
I also confirmed that this bug ticket has already been associated with your account. Once the issue is resolved and the fix is available, you will automatically receive a notification.하고는 있는데 언제 될지는 몰라. 하지만 언젠가는 될 거야. 되면 얘기해 줄게.
안타깝게도 약 1년이 지난 지금까지 버그는 수정되지 않은 상태다. 본 필자가 느끼기에도 이것은 크리티컬한 문제는 아니다. 실제 사용에 치명적인 문제가 있었다면 이미 전 세계의 수많은 사용자로부터 항의가 빗발쳤을 것이고 버그를 발견할 기회가 본 필자에게까지 오지도 않았을 것이다.
사실 버그를 발견한 본 필자마저도 트랜스코더를 쓸 일이 없어 관심에서 멀어져 있었다. 결국 내가 쓰는 기능이 잘 돌아간다면 관심이 덜 가는 것은 사실이고, 다른 사용자들의 사정도 크게 다르지는 않을 것이다.
그렇다고 해서 잘못된 동작을 그대로 두어도 된다는 뜻은 아니다. 크리티컬하지 않은 버그라고 해도 잘못된 것은 분명히 고쳐야 한다. 언젠가 와우자로부터 ENG-2346이 수정됐다는 소식을 들을 수 있길 바란다.
갱신 내역
- — 최초 게시
- — 1차 수정
- — 2차 수정 및 주소 이전
