와우자 트랜스코더 CBR 버그, 한달간의 추적과 공식 이슈 등록과정
와우자 스트리밍 엔진 트랜스코더 CBR 모드의 버그를 찾아 공식 이슈 목록에 올리기까지의 1개월간의 기록과 그 과정에서 확인한 와우자에서 공개하지 않고있던 수정 가능한 VBR 추가 옵션들에 대해 설명한다.
삽질의 시작 : 어? 왜 없지?
본 필자가 작성하는 모든 글들은, 본 필자가 실제로 구축해 운영했거나 운영하고 있는 서비스 또는, 계획하고 있는 서비스의 테스트베드를 구축하는 과정을 재현해 가며 작성하고 있다. 본 필자의 부족한 기억력을 보조하는 동시에, 어디에선가 비슷한 상황에 처한 독자 제위의 삽질 시간을 절약하셨으면 하는 작은 소망이 있기 때문이다.
본 필자가 꾸역꾸역 구글 서치콘솔과 애드센스의 홀대를 참아가며 와우자 스트리밍 엔진(Wowza Streaming Engine, 이하 와우자)에 관한 글을 쓰며 트랜스코더에 대한 내용을 다루기 시작했을 때, 본 필자는 한 가지 당황스러운 상황을 만나게 되었다.
어? 왜 트랜스코딩 옵션에 VBR이 없지?
생각해보니 본 필자는 VBR(Variable Bit Rate : 가변 전송률)을 사용할 일이 거의 없었다. VBR을 사용할 일이라고 해봐야 과거 위성장비나 RealVideo 시절 정도였고, 대부분은 CBR(Constant Bit Rate : 고정 전송률) 기반 시스템들을 다뤄왔었다. 그 오랜기간 와우자를 다뤄오면서도 VBR 설정항목이 없다는 것을 눈치채지 못할 만큼 말이다. (맞다. 사실 핑계다..)
하지만 이제까지 수많은 인코더와 트랜스코더를 다뤄 오며, CBR – VBR 선택 옵션이 없는 장비를 본 기억은 없었다. 와우자 트랜스코더에 대한 글을 작성하며 당연히 이 부분을 다루려 했던 필자가 혼란에 빠진 순간이었다.
그렇지, 없을 리가 없지
일단 관련된 자료를 뒤져보기 시작했으나, 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의 디코딩 비트레이트를 캡처하려 했다. 그리고, 본격적인 삽질이 시작되었다.
본격적인 삽질 : 어? 이거 아닌데?
뭐가 다른 거야?
본 필자는 하나의 라이브 어플리케이션에서 아래와 같이 두 트랜스코더 프로파일을 생성한 다음, 9Mbps UDP Multicast MPEG TS 스트림을 입력시켰다.
- 와우자 기본 트랜스코딩 프로파일의 비디오 비트레이트에 3.65Mbps 적용
- 와우자 기본 트랜스코딩 프로파일의 비디오 비트레이트에 3.65Mbps 적용 후 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.
정적인 화면에서는 비트레이트 변화도 작으니까 동적인 화면으로 시험해 보셈
이 답변을 받는 순간, 본 필자는 촉이 왔다. 이거.. 답 나오기 힘들겠네..
눈을 크게 뜨고 보라고!
콘텐츠 문제라 말하는 데에는, 두 눈으로 직접 보여주는 게 답이다. 동적인 화면이라고 하면 보통 콘서트나 스포츠 중계와 같은 콘텐츠를 생각한다. 본 필자도 동의하지만, 그 못지않게 동적인 콘텐츠가 있으니 바로 변신소녀가 등장하는 애니메이션이다.
여기서 주의깊게 봐야 할 것은 세 가지로,
- 입력 미디어 데이터 크기
- 스트림이 전송된 총 양을 나타낸다. 두 트랜스코더는 서로 다른 프로파일로 동작하고 있으므로, 스트림 데이터의 크기가 같지 않아야 한다.
- 입력 비트 전송속도 그래프
- CBR과 VBR은 인코딩 방식이 다르기 때문에 그 형태가 서로 달라야 한다.
- 디먹스 데이터 크기
- VLC가 스트림에서 재생에 사용한 데이터의 크기로, 역시 두 스트림의 크기가 같지 않아야 한다.
또 며칠이 흐르고, 와우자에서 기다리던 답장이 왔다. 그리고 그 내용은 본 필자가 외국 회사와 이야기하고 있는 중임을 다시 한 번 깨닫게 해 주었다.
…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로 시험해 봐
좋아, 그렇다면 이건 뭐야?
해외 업체의 기술지원은 국내 업체와 많이 다르다. (다만, 해외의 대응이 더 상식적인 것이라는건 동의한다.) 그네들은 상식 수준의 기본적인 것 부터 확인을 시작한다. 기본과 절차에 따라 확인하는 것은 당연한 일이지만, 가끔 이렇게 벙 찌는 느낌을 받는 것은 어쩔 수 없다. (본 필자는 장비 동작이 안된다고 하니 ‘접지는 연결 했냐?’라고 답한 Thomson의 답변이 십수년이 지난 지금도 기억에 생생하다. 그것도 전화로..) CBR로 바꾸는거 당연히 진작에 해 봤지, 안 해봤겠는가 말이다.
그러다 문득, 뭔가 빼먹고 있다는 생각을 하게 되었다. 보통 VBR에는 따라다니는 추가적인 옵션들이 있다. 보통 세 가지 정도는 따라 붙는데,
- Max Bitrate
- 가변 비트레이트 동작시 넘기지 말아야 하는 최대 값
- Min Bitrate
- 가변 비트레이트 동작시 넘기지 말아야 하는 최소 값
- Q-Factor
- 품질 계수, 유지하고자 하는 화질의 수준
이 세가지 옵션의 기본 값이나 조정하는 방법을 알면, VBR이 기본인 트랜스코더에서 CBR을 구현할 수 있을 것다. 그래서 와우자에 CBR 설정은 진작에 해 보았다는 말과 함께, 저 세가지 값에 대한 정보를 달라고 요청하는 답장을 보냈다.
그리고 수 일이 지나고 와우자에서 는 이렇게 답장을 보내왔다.
..I could replicate the issue you reported… …we currently do not have any documented…이제 시작이다!(그런데, 그럼 이제까지 뭘 한거냐..)
..여기서 실험해 보니 정말 니 말대로 안된다.. ..세가지 값에 대해서 정리해 놓은건 아직 없어..
삽질의 결과는 큰 바위
트랜스코더의 추가적인 파라미터 정보
다음날, 트랜스코더의 상세 설정을 위한 몇 가지 옵션들에 대한 내용이 담긴 메일이 와우자에서 도착했다. 이 메일에는 궁금해하던
- Average bitrate
- Maximum bitrate
- Buffer Size
- Q Factor : I-frame, B-frame, P-frame 설정
이번에는 뭔가 건질 게 있겠다는 생각이 든 본 필자는, 신나게 설정을 적용해 봤고 결국 유의미한 차이를 확인하는데 성공 했다.
결국 만난것은 커다란 바위
그렇다면 이 값들의 초기값이 얼마인지 알면, 와우자 트랜스코더에서 출력되는 스트림의 특성을 파악하고, 글을 작성하는데 좀 더 도움이 될 것이다. 당연히 이러한 문의를 와우자쪽에 전달했고, 몇일 후 이러한 내용의 답변이 도착했다.
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
이거 버그 맞고, 정식으로 버그 등록 했어.
끝까지 삽질을 하며 열심히 땅을 파 본 결과는, 삽으로는 더 이상 팔 수 없는 커다란 바위였다. 이 바위를 치울 수 있는건 이제 와우자의 몫으로 남게 되었다.
마무리와 결론
최초의 질문으로 부터 이슈 등록까지 한달이 넘는 기간이 걸렸다. 비록 순간 답답함이 있을 때도 있었으나, 긴 기간동안 와우자의 담당자는 성실하게 본 필자의 이슈에 대응해 주었다. (그리고 현재도 대응 중이기도 하다.) 이슈의 여부를 떠나, 와우자의 기술지원은 나쁘지 않다는게 본 필자의 생각이다.
와우자는 오랜 기간동안 현업에서 사용되어 온 프로그램이다. 그 기능과 안정성에 대해서는 긴 기간동안 충분히 검증 되었으며 이에 대해서 절대로 이견이 없는 바이다. 하지만 본 필자는, 와우자는 기본적으로 오리진 서버라고 생각한다. 인코딩/트랜스코딩은 외부에 존재하는 별도의 장비에서 진행하고, 와우자는 프로토콜의 변환과 분배에만 사용하는 것이 더 좋을 것이라고 본 필자는 생각한다.
또한, 이 이슈가 와우자 트랜스코더를 현업에서 사용하는 것이 불가능 하다는 것이 아님을 기억해 주기 바란다. 지금도 수많은 스트림들이 와우자 트랜스코더를 사용해 송출되고 있으며, OTT의 세계에서 CBR은 사실 사용되는 곳이 한정되어 있기 때문이다. 사실, 본 필자도 블로그를 작성하기 위해 파고 들지 않았더라면, 지금까지 그랬던 것 처럼 모르고 잘만 썼을 것이다.
이 이슈가 공식적으로 버그인것이 인정 되었고 버그 목록(ENG-2346)에 올랐으니, 이 다음 절차는 와우자가 처리해야 할 내용이다. 본 필자는 와우자 유저의 한 사람으로서, 사용하는 프로그램이 더 개선되는데 한 숟가락 얹을 수 있었다는 것과, 좀 더 깊숙한 지식을 얻을 수 있었던 것, 그리고 본 필자와 같은 문제로 생각과 시간을 낭비하실 분들께 작은 참고가 될 만한 글 하나 쓴 것으로 충분하다 생각한다.
