코덱 전쟁

지난 글에서 살펴본 대로 <video> 태그는 많은 장점을 가지고 있습니다. HTML5의 가장 큰 적인 브라우저 호환성 문제도 IE9이 <video> 태그를 지원하게 되면서 어느 정도 해소될 전망이고요. 그렇지만, <video> 태그에는 코덱(codec)1이라는 또 다른 복병이 존재합니다.

코덱 쪽은 짧은 시간 내에 많은 변화가 일어나고 서로의 이해가 물려있는 형상이 '전쟁'에도 비유할 수 있을 정도입니다. 이 글에서는 '코덱 전쟁'의 배경과 진행 상황 등을 짚어볼까 합니다.

WebM 브라우저 전쟁 from techauto

분열된 코덱 지원

우리가 흔히 동영상이라고 부르는 파일에는 영상과 음성이 따로 포함되어 있습니다. HTML5의 경우 영상을 다루는 코덱에는 H.264, Theora, VP8 등이 있고, 음성을 다루는 코덱에는 AAC, MP3, Vorbis가 주로 사용됩니다. Apple 진영에서 제공하는 .mp4, .mov 포맷은 H.264+AAC로 이루어져있고, 따라서 Mac과 iPhone 등에서 사용하는 Safari 웹 브라우저도 이 포맷을 지원합니다. 반면 오픈소스 진영인 Firefox는 Theora+Vorbis로 이루어진 .ogg, .ogv 포맷을 지원합니다. 모바일쪽을 살펴보면 iOS2의 Safari, 안드로이드의 웹 브라우저에서는 Apple의 Safari와 동일한 형식을 지원합니다. 그리고 각각의 진영은 서로 상대 진영의 포맷을 지원하지 않습니다. 즉, Apple은 Theora+Vorbis를 지원하지 않고, Firefox는 H.264를 지원하지 않습니다.

표1. 웹 브라우저의 코덱 지원 현황
- IE Firefox Safari Chrome Opera iOS Android
Theora+Vorbis - 3.5+ * 5.0+ 10.5+ - -
H.264+AAC 9.0+ - 3.0+ 5.0- ** - 3.0+ 2.0+

*: Mac 운영체제의 Safari는 QuickTime이 지원하는 미디어는 모두 지원합니다. 기본값으로는 H.265+AAC를 지원하지만 사용자가 직접 써드파티 플러그인을 설치하면 Theora+Voirbis도 볼 수 있습니다.
**: Google은 2011년 1월 11일, 자사의 웹 브라우저인 Chrome에서 H.264를 더 이상 지원하지 않겠다고 발표했습니다.

이렇게 웹 브라우저마다 코덱 지원 현황이 다른 이유는 바로 코덱에 걸려있는 특허때문입니다. H.264 포맷의 특허권은 MPEG LA3라는 단체에서 관리하고 있고 이 방식을 사용하려면 특허사용료를 지불해야 합니다. 또한 코덱 사용에 대한 배타적이고 독점적인 권리때문에 누구나 자유롭게 사용할 수 있는 기술이 아닙니다. 바로 이 점이 Firefox와 같은 오픈소스 진영에서 H.264를 지원하지 않는 이유입니다. 이에 대해서는 Mozilla의 기술부사장(vice-president of engineering)인 Mike Shaver가 자신의 블로그에 밝힌 바 있습니다.

비록 MPEG LA에서 로열티 무료 기간을 2011년 1월 1일에서 2015년 1월 1일로 늘리기는 했으나 오픈소스 진영에서 특허권자에 따라 좌지우지 될 수 있는 상황을 만들리는 없을 것입니다. 또한 MPEG LA가 선언한 로열티 무료는 인터넷 스트리밍에 한하기 때문에 일부에는 여전히 로열티 문제가 남아있습니다(예컨데, Firefox에서 H.264를 제공하려면 Mozilla 재단에서 로열티를 지불해야 합니다).

지난 1월 11일 구글이 자사의 웹 브라우저인 Chrome에서 더 이상 H.264를 지원하지 않기로 선언함에 따라 Anti-H264 진영(?)은 MS-Apple vs Mozilla-Google-Firefox의 형태로 분열되었습니다. 사실 기존의 강자인 Flash까지 포함하면 동영상 분야의 대결 구도는 Adobe vs MS-Apple vs Mozilla-Google-Firefox인 셈이죠.

이와 같은 코덱의 분열로 인해 피해를 보는 것은 다름아닌 사용자들입니다. 동영상을 제공하는 업체에서는 어마어마한 비용을 감당하기 힘들기 때문에 1개 혹은 2개의 코덱을 지원하는 정도가 전부인데, 이렇게 되면 결국 특정한 웹 브라우저 사용자들은 소외되기 마련입니다. HTML5를 포기하거나 플러그인 기술을 사용하거나 또는 아예 동영상 콘텐츠를 포기해야되는 것이죠.

WebM = 코덱 전쟁 종결자?

구글은 2009년 8월에 On2 Technology라는 비디오 코덱 전문 기업을 인수했습니다. 이 회사는 VP3, 4, 5, 6, 7, 8 과 같은 코덱을 개발했는데 이 중 VP6 코덱은 몇 년전 Daum에서 동영상 서비스를 구축할 때 사용한 제품이기도 합니다. 구글은 이 회사의 인수가 확정되자마자 VP7, VP8 코덱을 오픈소스로 공개하겠다고 밝혔는데 2010년 5월 19일에 WebM이라는 컨테이너로 결실을 맺게 됩니다4.

이 포맷이 오픈된 후 구글은 물론이고, Mozilla, Opera 등에서 공식적으로 WebM을 지원하기로 했고, Adobe Flash에서도 VP8코덱을 지원하기로 밝힘에 따라 코덱 전쟁은 Google-Mozilla-Opera vs Apple-MS 그리고 아무래도 좋은 Adobe로 정리되어갔습니다(참고로, IE9에서도 코덱을 설치하면 WebM을 재생할 수 있습니다).

뿐만 아닙니다.

AMD, ARM, nVidia 등은 WebM을 위한 하드웨어 가속을 지원하겠다 밝혔고, Intel도 Atom을 기반으로 한 자사의 제품에 WebM 지원을 고려하고 있을 정도로 WebM은 다양한 반면에서 급속도로 자리잡아가고 있습니다. 물론, 여기에는 로열티가 없는 공개 기술이라는 점 외에도 구글이라는 이름이 크게 작용했을 것입니다.

로열티도 없고 기술 자체도 상용으로 사용되었을만큼 품질이 보증되니 그대로 모두가 WebM을 지원해주면 좋으련만 상황은 그렇게 간단하지 않습니다. Apple은 이미 H.264에 포함된 특허의 일부를 소유하고 있기 때문에 H.264가 많이 사용될수록 이득이고, 무시할 수 없는 모바일 트래픽 점유율을 가진 iPhone/iPad가 있기 때문에 굳이 굽히고 들어갈 이유가 없습니다. MS는 자사에서 개발한 코덱대신 H.264를 사용하는 것으로 대세를 따르기로 한 모습이고요(여기에는 구글에 대한 반감이 작용했을 것이라는 분석도 있습니다).

표2. 웹 브라우저의 코덱 지원 현황(WebM 포함)
- IE Firefox Safari Chrome Opera iOS Android
Theora+Vorbis - 3.5+ ** 5.0+ 10.5+ - -
H.264+AAC 9.0+ - 3.0+ 5.0- - 3.0+ 2.0+
WebM 9.0+ * 4.0+ ** 6.0 10.6+ - 2.3+ ***

*: 사용자가 VP8 코덱을 설치하면 IE9에서도 WebM 동영상을 재생할 수 있습니다.
**: Mac 운영체제의 Safari는 QuickTime이 지원하는 미디어는 모두 지원합니다. 기본값으로는 H.265+AAC를 지원하지만 사용자가 직접 써드파티 플러그인을 설치하면 Theora+Voirbis도 볼 수 있습니다.
***: 안드로이드는 2.3부터 WebM을 지원하지만 하드웨어 디코더가 포함된 것은 아니라서 배터리 문제가 선결 과제로 남아있습니다.

과정이야 어찌됐든 지원 현황으로만 보면 비(非) WebM 진영에는 Apple만 남아있는 셈인데요, 스티브 잡스가 2010년 5월 경에 보낸 메일을 보면 사용자들은 실망할 수 밖에 없을 것 같습니다. 실제로는 "VP8 코덱에 대해 어떻게 생각하느냐"는 사용자의 질문에 단 한줄의 URL로 답했다고 하는데요, 잡스가 보낸 URL의 내용을 살펴보면 VP8에 대해 다음과 같이 평하고 있습니다.

  • 스펙만 보면 H.264 Baseline Profile과 VC-1 보다는 낫지만 H.264 Main하고는 경쟁조차 안된다.
  • 디코딩면에서 보면 ffmpeg에서 구현한 H.264보다 느리다.
  • H.264에서 너무 많이 베껴와서 특허 분쟁의 소지가 다분하다.
  • Theora, Dirac보다는 나으므로 특허 문제만 해결된다면 특허 문제없는 코덱으로는 자리잡을 수 있을 것이다.
  • 구글이 WebM에 Matroska와 Vorbis를 사용하기로 한 것은 옳은 결정이었다.

아마도 iPhone/iPad에서 WebM을 볼 수 있는 날은 조금 멀리 있는 것 같습니다.

결론

코덱 전쟁은 여전히 진행중입니다. 아주 잠깐은 WebM으로 통일되나하는 희망을 품었지만, 지금은 특허 문제때문에 WebM의 존폐마저 걱정해야 할 상황입니다(MPEG LA에서는 VP8의 특허에 대한 조사를 진행중이죠). HTML5에서 가장 유용하게 쓰일 수 있는 <video> 태그는 코덱 전쟁으로 발이 묶여있는 상태이고 이 모든 불편은 사용자가 감당해야할 몫입니다.

이 전쟁의 결말이 어떻게 나든 과정이 순탄치는 않을 것 같습니다.

... and Next

다음 글에서는 <video> 태그의 속성과 메소드를 살펴보고 간단한 사용법을 익혀보도록 하겠습니다. 간단한 사용법을 익힌 뒤에는 간단한 플레이어를 만들어보고 이 재생기에 스킨 기능까지 입혀볼 예정입니다. 코덱 전쟁이 언제 끝날지 모르지만, 이 전쟁이 끝나고 HTML5 <video>가 널리 퍼지기 시작하면 아마 유용하게 사용할 수 있을 것입니다.

참고자료


  1. 코덱(codec)이란? 아무런 가공도 하지 않은 상태의 음성이나 동영상 데이터는 상당히 많은 용량을 차지하게 되기 때문에 특별한 방법을 사용해서 데이터를 압축해서 저장하고, 출력할 때는 이 데이터를 해제합니다. 이 때 데이터를 압축하고 해제하는 특별한 방법이 바로 코덱입니다. 코덱(codec)이라는 용어는 압축기(compressor)-해제기(decompressor)의 약자입니다. 
  2. iPhone, iPad 등에서 사용하는 운영체제 
  3. MPEG LA는 MPEG-2, MPEG-4, IEEE 1394, H.264 등 영상 기술의 특허를 관리하는 회사입니다. 
  4. WebM은 VP8 영상 코덱과 Vorbis 음성 코덱으로 이루어져 있습니다. 
  1. 유익한 내용 잘 읽었습니다. ^^
    코덱 종결자라는 표현이 아주 인상적이었어요. webm에 대한 스티브잡스의 의견도 몰랐는데 새로 알게됐네요. 보통 webm에 대해 구글이 하기 때문에 잘 될꺼다라고만 이해하는 경우가 많은데 상황을 보면 구글 생각대로 되기가 쉽지만은 않을 것 같다는 생각도 듭니다.

    MS에서는 윈도우 사용자를 위해서 크롬과 파폭에 대해서 h.264 플러그인을 제공한다는 발표가 나기도 했어요.
    http://news.cnet.com/8301-30685_3-20025721-264.html
    http://arstechnica.com/microsoft/news/2011/02/microsoft-offers-h264-plugin-for-chrome-queries-google-on-webm.ars

    재밌는 코덱 전쟁...

  2. 재미있는 글 잘 읽었습니다.

    그런데 'WebM = 코덱 종결자?'항목에 약간 오해가 될 텍스트가 있는 것 같습니다 ^^;

    - 구글은 Matroska와 Vorbis를 HTML5 동영상 포맷으로 제안했을 때가 옳았다.

    요 부분의 경우

    - 구굴이 WebM을 위한 컨테이너 포맷을 Matroska, 오디오 코덱을 Vorbis 로 선택한 것은 옳은 결정이다.

    라고 써 주시는 쪽이 더 나을 것 같네요~

    덕분에 많은걸 알고 갑니다. 당분간은 WebM이라던가.. 웹에서의 비디오 표준 전쟁과 관련해서는 신경 안 써도 될 것 같네요~

    1. 실수가 있었네요 OTL
      의미가 달라지는 부분이라 조심했어야 하는데... 덕분에 수정할 수 있었습니다.

      감사합니다.

  3. 좋은 글인데 중요한 용어 잘못되어 수정이 필요합니다. WebM 은 코덱이 아닌 컨테이너입니다. 많은 분들이 이 글을 읽고 혼란을 가질 수 있을 거 같습니다. 코덱은 동영상을 압축하는(또는 해제) 기능을 담당하지만, 컨테이너는 코덱을 이용해 압축한 데이터를 담는 그릇과 같이 비유될 수 있습니다. 예를 들면, H.264 코덱으로 압축하고 컨테이너는 MP4 를 사용. 또는 VP8 이나 VP9 코덱으로 압축하고 WebM 컨테이너 사용. 이렇게 표현을 해야합니다.

    1. 오래된 글이라 기억을 못하고 있었는데 다시 읽어보니 말씀하신대로 혼란을 줄 수도 있을 것 같아서 글을 조금 수정했습니다. 감사합니다. 🙂

Leave a Reply to nezzCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.