애크미... 루니툰을 좀 보셨던 분들은 귀에 익은 이름이리라 생각됩니다. 이전 포스트의 말미에서 말씀 드린 것처럼 그런데 왜 ACME 란 이름이 프로그래밍 관련 서적이나 문서에 빈번히 등장하는 걸까요?
궁금해서 위키피디아를 뒤졌더니 간단하게 답이 나왔습니다.
루니툰에서 애크미란 회사 이름을 사용한 이후로, 가상의 회사를 나타내는 전형적인 이름으로 여러 분야에서 널리 사용되어 오고있다.
정도의 내용입니다.
그리고 논쟁의 여지가 있지만 A Company that Makes Everything 의 backronym 이기도 하다고 합니다.
루니툰 대표 선수들
여기서 backronym이 뭔지 찾아보지 않을 수가 없습니다... backcronym 은 acronym 의 반대로서, acronym 이 기존 구문의 앞글자를 따서 축약한 형태인 반면에, backcronym 은 존재하는 축약형에다 어구를 같다 붙인 거라고 하네요... 옛날식 유머로 하면 ROTC 란 말에다 '로타리 오리발 튀김 센터' 라고 같다 붙이는 식입니다. ^^
그러고 보니 예전에 말보로(Marlboro) 담배의 어원에 대한 논란이 있었는데요... Marlboro는 'Man Always Remember Love Because Of Romance Over' 을 줄인 acronym 일까요? 아님 원래 지어진 이름에 그 의미를 나중에 갖다 붙인 backronym 일까요? 약간의 네이버링(?) 으로 결론을 내려보면... 원래는 누군가 지어낸 backcronym 이나, 이야깃 거리 만들기 좋아하는 몇몇 사람들이 acronym 이라고 개기고 있는 것으로 추정됩니다.
그외 ACME 처럼 임의의 이름으로 자주 사용되는 단어를 보면...
먼저 우리나라의 홍길동 대신 사용되는 'John Doe' 란 이름이 있습니다. 그리고 프로그래밍 책에 클래스명이나 함수명으로 자주 사용되는 foo, bar 도 있네요...
보안 쪽의 Alice 와 Bob 도 이런 범주에 넣어야 할까요....?
그외에 또 뭐가 있을까요? 영어 실력자분들의 지도 편달을 바랍니다.
기왕 얘기가 나온 김에 축약형과 관련된 또 다른 단어들을 알아 보면 anacronym, apronym 이라는 단어들도 있는데요....
apronym은 BASIC(Beginner's All-Purpose Symbolic Instruction Code), CARE(Cooperation for American Relief Everywhere), STAR(Satellite Television Asian Region) 처럼 축약된 형태의 단어가 풀어쓴 구절의 의미를 담고 있는 acronym 또는 backronym을 의미 합니다. 재미있는 예를 몇개 들어보면
FORD - Fix Or Repair Daily 또는 Found On Road Dead (자동차 회사 사장이 보면 미치고 팔짝 뛸 apronym 이죠)
FIAT - Fix It Again Tony (이것도 위의 것과 거의 비숫한 수준이 군요 ㅋㅋ)
INFINITY - Increment Numbers Forever - It's Nuts, I Tell You! (숫자를 영원히 증가시켜봐 - 그거봐 미친짓이라니깐)
IRELAND - Independent Republic, English Lodgers Are Nearly Dislodged! (독립공화국, 영국놈들 거의다 쫓아냈다~~)
등이 있네요^^
anacronym 은 뜻이 조금씩 달라서 어느게 맞는 건지 모르겠슴다만, 어떤 곳에서는 acronym 이 세월이 지나다 보니 원문이 뭐였는지 기억하는 사람이 거의 없는 경우를 말한다고 하기도 하고, 위키피디아에서는 사회적으로든, 정치적으로든, 기술 진보에 의해서든, 어떤 acronym 용어가 시대에 뒤떨어져 다른 의미로 대체되는 것이라고 합니다.
마지막으로 SPAM 과 관련된 재밌는 backronym 들을 소개하면서 마칩니다. 다른 것도 많으니 약어에 관심 있으신 분들은 검색해 보시기 바랍니다. 진짜 재미나거든요...
C# 에서는 서로 다른 네임스페이스에 같은 타입명이 존재하는 경우, 타입의 Fully qualified name (한글용어 : 정규화된 형식이름)을 적어줌으로써 충돌을 피하고 있습니다.
예를 들어 한국의 Mhn 이라는 회사와 Baum 이라는 회사가 모두 StreetMap 이라는 타입을 정의하여 제공하고 있고 각각의 타입이 포함된 어셈블리 둘 모두를 참조하는 코드를 작성하는 경우 아래의 모호함이 발생합니다. (예제는 'CLR via C#' 에 나온 예를 약간 수정하였습니다.)
// StreetMapTest.cs
usingMhn;
usingBaum;
publicsealedclassProgram
{
publicstaticvoidMain()
{
StreetMapm = newStreetMap(); // 알쏭달쏭한 참조
}
}
그래서 Fully qualified type name 을 써서 아래와 같이 코드를 써야 합니다.
usingMhn;
usingBaum;
publicsealedclassProgram
{
publicstaticvoidMain()
{
StreetMapm = newBaum.StreetMap(); // 문제 없음
}
}
그런데 만일 타입이 정의된 네임스페이스까지 같다면 어떻게 될까요? 미국에 Baum 이라는 같은 이름을 가진 회사가 있는데 만일 이 회사가 Baum 이라는 네임스페이스에 StreetMap 이란 타입이 정의된 어셈블리를 제공한다면, 그리고 내 프로그램에서 이렇게 두개의 같은 fully qualified name 을 가진 서로 다른 StreetMap 타입을 참조해야 한다면 어떻게 해야 할까요? ('CLR via C#' 에서는 Australian Boomerang Company (ABC) 라는 회사와 Alaskan Boat Corporation(ABC)란 회사가 모두 BuyProduct 라는 타입을 제공하고 있는 경우 부메랑과 보트 모두를 구매하는 코드를 작성하는 예를 들고 있습니다)
예를 들어 아래와 같은 코드는 어느 어셈블리의 Baum.StreetMap 을 참조하는지 모호합니다.
publicsealedclassProgram
{
publicstaticvoidMain()
{
Baum.StreetMapm = Baum.StreetMap();
}
}
위의 예를 빌드하면 형식 'Baum.Streetmap' 이 서로다른 두 군데의 어셈블리에 존재한다는 컴파일러의 투덜거림을 보게 됩니다.
잘 일어나진 않겠지만, 이런 멍멍이 같은 경우를 해결하기 위해 사용되는 것이 extern alias 입니다. 위의 예에서 한국 Baum 의 어셈블리가 Baum.1.0.0.0.dll 로 제공된다고 하고, 미국의 이름만 같은 다른 회사 Baum 이 제공한 어셈블리 파일이 BaumMap.dll 이라고 하면 아래와 같은 옵션으로 컴파일 할 수 있습니다.
Orcas (Visual Studio 2008) 과 함께 제공될 것이라고 하는데요.... MFC 소스 처럼 Visual Studio 설치시 소스가 함께 설치되는 것은 아닌 것 같구요, 디버깅 시 닷넷 프레임웍 내부의 메소드로 F11 키를 눌러 '한단계씩 코드 실행(Step into)' 를 할 때 해당 소스를 다운로드 하는 방식이라고 합니다.
물론 소스코드 단독 설치를 통해 로컬에서 뒤적거려 보는 것도 가능하도록 할 것이라고 합니다.
공개는 대략 아래 것들로부터 시작해서...
Base Class Libraries (mscorlib.dll)
ASP.NET (System.Web.dll)
Windows Forms (System.Drawing.DLL & System. Windows.Forms.dll)
ADO.NET (System.Data.DLL)
XML (System.Xml.DLL)
WPF (System.Windows.DLL)
단계적으로 WCF, Workflow, LINQ 까지 와장창 공개될 것이라고 합니다.
코드는 Microsoft Reference 라이센스 로 공개될 것이라고 합니다. 이 라이센스에 따르면 소스코드의 사용은 참조용으로서 읽기 전용으로, 오로지 제품을 디버깅하고, 유지보수하고, 닷넷프레임웍과의 상호운용성을 향상시키는 목적으로만 제한된다고 합니다.
배운지 얼마 되지 않았거나 예전에 해보지 못한 기술을 적용하느라 코딩 삽질에 집에도 못가고 날밤 새고 있는데... 덜컥 내 코드가 아닌 남의 라이브러리에서 Exception 이 날아왔다. 아.. 젠장 도대체 뭐가 잘못된겨.... 블로그, 뉴스그룹, 라이브러리 레퍼런스까지 다 뒤적거려도 답은 안나오고.. ㅜㅜ 일단 잠 한숨 때리고 다음날 업무시간 시작하자 말자 제품 지원측에 전화를 때려본다. 하지만 그쪽에다 내 코드를 읊어줄 수도 없고, 프로젝트 코드를 메일로 보내줄 수도 없고... 그쪽이 내 상황을 제대로 이해할 수 없는 판이니 어짜피 전화 붙들고 입술 부르트도록 얘기해 봤자 답도 안나온다... 헐...
과 같은 억장 무너지는 사태를 겪는 경우에 도움이 되겠지만, 한편으로는 '과연 MS가 이러한 순수하게 선한 의도로만 소스를 공개할까' 라는 의구심이 듭니다.
오픈소스에 대한 참여를 늘여가고 있는 MS지만 과연 MS가 소스코드 공개를 결정하기 전 계산기에 대고 두드려본 진짜 수식은 무엇이었을까요?
Windows 프로그래밍 관련 책의 저자들 중 무한 신뢰도를 받는 몇명 중의 한 분... 업무상 API 나 MFC를 이용한 개발을 위주로 한 사람들에게는 아련한 향수까지도 자아내는 이름입니다.
Windows API 프로그래밍의 바이블 Programming Windows 의 저자 찰스 펫졸드 아저씨의 새 책이 나왔습니다. 원서가 작년 말에 나온 것으로 되어 있는데 거의 1년이 다 되어서 번역서가 나왔네요... '찰스 페졸드의 WPF', 원서의 제목은 ' Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation'입니다. 'Application = Code + Markup' 제목도 상당히 재밌습니다. 단지 번역서의 제목은 좀... 특히나 페졸드에서 안습입니다... (저는 그래서 일부러 펫졸드라고 썼습니다.)
어쨌건 내용을 보지 않더라도 많은 분들이 펫졸드 아저씨의 이름만으로도 구매 결정을 하리라 생각됩니다. 물론 어둠의 경로를 통해 원문으로 된 비공식 e-book 을 가지고 계신 분들도 있겠습니다만, 이런 책은 e-book 보다는 한권 쯤 소장해 줘야 하지 않을까요... 조금 걸리는 것은 번역이 어떨까 하는 것인데, 책이 워낙 두꺼운지라 번역서와 원서의 가격차가 얼마(?) 되지 않으니 번역본에 알레르기 반응을 보이는 분들은 원서를 구매해도 좋을 듯 합니다. 아니면 어둠의 원서를 옆에 두고 번역이 찝찝한 부분은 원문을 참고하는 것도 좋을 듯 하구요... 아무래도 우리말이 훨씬 빨리 읽히는 것은 저뿐만이 아니겠지요? ^^
역시 세월은 세월인가 봅니다. Windows API 가 트레이드마크였던 분이 WinForm 을 거쳐 결국 WPF 에 대한 책까지 냈군요. 하긴 Jeffrey Richter 조차 자신의 책, 'CLR via C#' 의 서문을 통해서 '예전 프로그래밍으로 돌아가라고 한다면 차라리 직업을 바꾸겠다' 라는 말까지 했을 정도니, 펫졸드 아저씨가 WPF 에 관한 책을 낸 것도 이상한 일은 아니겠습니다.
책 제목으로 짐작할 수 있듯이, 책은 크게 두개의 파트로 나뉘어 있습니다. 첫번째 파트에서는 XAML 을 쓰지 않고 순수 코딩만으로 WPF 애플리케이션을 작성합니다. 두번째 파트는 마크업 언어 XAML 에 대해 다루는데 xaml 과 코드를 함께 사용하는 방법을 보여줍니다.
한마디로 툴은 전혀 사용하지 않고 손가락 노가다로 코드든 마크업이든 입력해서 WPF 를 배우도록 합니다. 따라서 툴을 써서 어떻게든 빨랑 결과를 보기를 바라는 분들보다는, 툴이 해주는 작업의 실제 내용, 즉 기본부터 확실히 알고자 하는 분들에게 알맞은 말그대로 펫졸드틱 한 책입니다.
익스프레션 블렌드 및 Visual Studio 등의 툴을 사용하는 개발을 보고 싶은 분들은 차라리 WROX 에서 나온 'Professional WPF Programming'이 나을 것 같습니다. (WROX 책은 익스프레션 블렌드에 대해 다루는 파트도 따로 있습니다)
모쪼록 펫졸드 아저씨의 새 책이 일부 프로그래밍계의 얼리 어답터가 아닌 저를 포함한 많은 게으른 개발자들이 WPF 라는 새로운 영역을 체계적으로 이해할 수 있도록 도와주는 친절한 도우미 역할을 해주기를 기대해 봅니다.
펫졸드의 팬이라면 저자의 홈페이지 도 들러보시길... Books 로 가면 C/C++ 프로그래머를 위한 C# 과 닷넷 가이드인 '.NET Book Zero' 이라는 250 페이지가 넘는 e-book 을 공짜로 받을 수도 있습니다. 그리고 이 아저씨의 최신작인 WPF를 이용한 '3D Programming for Windows' 도 흥미로울 거 같구요...
서점에 못갔었는데 번역을 물어보셨네요.. 그래서 점심 시간에 다녀왔습니다. 말을 뱉었다는게 무섭습니다.^^;;;
1장만 읽어보았는데 괜찮게 번역된거 같았습니다. 네분이 번역한 거라 전체적인 번역 수준은 주위 분들의 의견을 참고하시는게 나을 거 같습니다.
번역서를 보고 알게된 사실 한가지는, 번역서에는 원서에 없는 실행 결과 화면이 곁들여져 있다는 점입니다. 실행될 모습을 떠올리면서 코드를 읊어갈 수 있다는 점에서 장점이 아닐까 합니다. 댓글 감사합니다 ^^
많은 사람들이 플래시나 실버라이트 같은 RIA 를 이야기 하지만 아직 웹에서의 RIA는 광고, 사이트메뉴, 게임, UCC 등과 같은 영역에서 집중되어 사용되고 있습니다. 이런 면에서 볼 때 웹에서의 진정 새로운 UX는 아직 시작 단계라고 볼 수 있으며, 이후 RIA들이 진화를 거듭하였을 때 과연 우리가 어느정도의 UX 를 경험하게 될지... 상상만으로도 흥분되는 일이 아닐 수 없습니다.
수년간 조연에만 머물고 있는 RIA가 웹의 주류가 되기 위해서는 여러가지가 필요하겠으나, 그 중 하나는 피검색성(적절한 표현인진 잘 모르겠습니다)일 것 같습니다. 이 경우도 SEO 라 불러야 할지는 잘 모르겠습니다만, 따지고 보면 SEO이기도 하고, 물건너 동네에서도 SEO로 부르고 있으니 이후 SEO라 지칭하겠습니다. (사실 처음에 이 주제와 관련된 글을 구글에서 검색할 때 삽질 많았습니다 ㅎㅎ)
페이지 리퀘스트시 클라이언트로 컨텐츠가 전송되는 보통의 웹 페이지와는 달리, 실행시 코드에 의해 동적으로 내용이 구성되는 플래시, 실버라이트와 같은 RIA 계열의 웹 애플리케이션에서는 컨텐츠의 내용이 검색엔진에 의해 인덱싱 되기가 어렵습니다. (Ajax 역시 마찬가지 이겠습니다)
검색 결과 역사가 길다보니 플래시와 관련된 자료들이 주로 많이 나오는데, 해결 방법은 대체로,
1. RIA를 호스팅 하는 페이지와 상응하는 정적인 웹페이지를 따로 만들어 피검색성을 높이고, 외부에서 검색결과의 링크로 정적 웹페이지로 들어오는 요청은 RIA 페이지로 redirection 시키거나,
2. <div> 같은 영역에 컨텐츠를 같이 뿌려주고 RIA가 지원되는 브라우저에서는 자바스크립트를 써서 해당 영역을 숨기거나 컨텐츠를 RIA로 바꿔버리는 등의 방법
등이 많이 고려되는 것 같습니다. 어쨌거나 편법 또는 컨텐츠의 중복(좋게 말하면 RIA 또는 자바스크립트를 지원하지 못하는 텍스트기반 브라우저를 위한 배려) 등, 정공법이라는 느낌이 들지는 않는 것 같습니다.
RIA의 특성상 쉽지는 않겠으나, 향후 애플리케이션 별 workaround가 아닌, 쌈빡하게 단일화된 SEO를 위한 표준적인 방법이 실버라이트에서 제시되었으면 하는 바램입니다.
Flash SEO, 또는 Silverlight SEO 로 검색하면 많은 자료(주로 플래시)가 있습니다만, 아래의 두 링크는 플래시와 실버라이트에서의 SEO 관해서 꼭 한번 읽어봐야 하는 글이 아닌가 합니다.
첫번째 링크는 SwfObject(FlashObject)라는 스크립릿을 플래시 SEO에 응용하는 방법에 대해 얘기하고 있습니다. 플래시 SEO 에 관심있으셨던 분들은 다 아시는 내용이겠죠 아마 ^^;;;
두번째 링크의 Nikhil Kothari는 'Developing Microsoft ASP.NET Server Controls and Components' 라는 책의 저자중 한명으로서, 실버라이트 또는 ASP.NET/Ajax 프로그래밍에 관심 있는 분들은 한번씩 들러 볼 만한 곳이 아닌가 합니다. 슬라이드쇼 데모 애플리케이션을 통해 컨텐츠 중복없이 SEO 를 고려한 RIA 웹페이지를 보여주고 있습니다.
플래시 쪽은 역사가 긴 편이니 고민 하신 분들이 많을 것 같습니다. RIA의 SEO와 관련해 더 좋은 아이디어가 있으신 분이 있다면 공유의 기쁨을 함께 하고 싶습니다. ^^;;
Tracked from Inspiration, Feel Good Factor for Flex Dev2008/07/03 00:39삭제
'그의 모니터는 늘 꺼져있습니다. 켜 있을 필요가 없는 탓입니다. 앞을 볼 수 없는 병욱 씨는 컴퓨터가 빠르게 읽어주는 소리를 들으며 코딩을 합니다.' 마소 7월호 인터뷰기사에 실린 센스리더의 개발자 황병욱님의 인터뷰에 대한 이야기입니다. (센스리더는 6월 30일 새로운 버전의 Sense Reader Professional Edition 을 출시했다고 합니다.) 지난 4월 장애인 차별 금지법이 발효된 이후 웹접근성에 대한 여러 문제제기와 이슈들이 거..
테크크런치의 소식에 의하면 에코스타사가 현금 및 주식 박치기로 3억 8000만불에 슬링미디어를 인수하기로 합의했다고 합니다.
슬링미디어사는 슬링박스란 제품으로 주목 받아온 회사입니다. 슬링박스와 같은 제품을 Place Shifter 라고 부르는데, 개별 가정에 TV와 연결된 셋탑박스를 두고 이를 인터넷에 연결하면, 외부에서 인터넷에 연결된 노트북 PDA등의 장치를 이용하여 가정의 tv를 리얼타임으로 보거나 박스에 녹화된 방송을 시청할 수 있도록 해주는 제품입니다. 비슷한 컨셉의 제품으로는 소니의 로케이션프리, 국내에서는 유비코드(서비스:유티비투고), 아코지토, TVIO등이 있습니다.
제가 인수 소식을 듣고 가장 놀란 것은 인수 금액입니다. 과연 슬링박스(및 관련기술)가 그 정도를 지불하고 인수할 만한 가치가 있는가 하는 점입니다.
플레이스쉬프터의 시장 타겟은 크게 두가지 정도가 있습니다.
하나는 현재까지 대부분의 플레이스 쉬프터처럼 일반 컨슈머용으로 판매하는 것입니다. 슬링박스가 새로운 제품에 열광하는 얼리어답터들에게는 흥미로운 제품임에 틀림없으나, 일반인들에게 널리 판매되기에는 한계가 많다고 생각합니다. 슬링미디어의 말로는 작년부터 올해까지 hundreds of thousands 가 판매되었다고는 하나 제품 특성상 단기간에 수요 고갈이 되지 않을까요? 반면에 시장 규모가 상대적으로 작은 국내의 관련 회사들은 현재 상당히 힘든 상태에 있는 것으로 알고 있습니다. (제품 판매 뿐만 아니라 관련 서비스 사업까지 구상했던 유비코드도 마찬가지인 것으로 알고 있습니다.)
다른 하나는 가입자를 유치하여 서비스 하는 사업자 시장입니다. 하나tv용 셋탑박스를 개인이 구매하는 것이 아니라 서비스 사업자가 구매하는 것과 같은 형태입니다. 국내 이동통신사들이 휴대폰으로 플레이스쉬프터와 연동되는 서비스를 개발하여 가입자를 유치한다면 그나마 전자보다는 가능성 있는 시장이라 생각됩니다. 박스의 설치부터 설정까지 설치기사가 방문하여 처리해준다면 일반 셋톱박스보다 설치가 어려운 플레이스 쉬프터를 일반 사용자들이 보다 쉽게 사용할 수 있는 것은 분명합니다만, 과연 얼마나 많은 가입자를 유치할 수 있을까요? 비지니스 개발의 고수분들이 잘 판단하시겠지만, 개인적으로는 물음표입니다. (유비코드나 아코지토 같은 제품들의 경우 응용 서비스와 연동되는 컨셉의 제품인 것으로 알고 있고, 유비코드의 경우 유티비투고라는 서비스도 있으나 돈을 벌고 있는 것 같아 보이진 않습니다.)
대부분의 관련제품들은 부가적으로 PVR 기능까지 제공하므로, PVR전용 제품과 비슷한 가격으로 부가적인 Place Shifter 기능을 제공한다면 PVR구매층을 공략할 수 있겠지만... 국내는 PVR 수요가 크지 않은 것 같습니다. 한때 수능방송 녹화 등으로 붐이 불었던 적이 있었으나 이제 많이 가라 앉은 느낌입니다. 인터넷에 접속하면 빠르게는 드라마 한편을 5분에 다운로드해서 볼 수 있으니, 국내에서는 특별한 경우 이외에는 PVR의 필요성을 느낄 수가 없게 되어 있습니다.
물론 앞으로 IPTV가 본격화되면 PVR및 Place Shifter 기능이 부가된 IP셋탑박스가 나올 것으로 예상됩니다. 그렇다면 현재의 PVR 또는 Place Shifter 시장의 메이저 회사들이 IP셋탑박스 시장의 메이저가 될 수 있을까요? 물론 IP셋탑박스와, PVR, Place Shifter 제품 간의 기술 교집합이 상당히 큰 것은 사실입니다만 제 개인적으로는 아니라고 생각합니다.
업체들로서는 될지 안될지 확인 사살을 해야하나 아직은 시간이 더 필요하고, 이렇게 기다리는 시간은 평소보다도 길게 느껴지며 들어가는 돈도 부담스럽기 그지 없을 것입니다. 물론 총알이 넉넉하다면 상관없겠습니다만.. ^^
슬링미디어의 인수는 당연히 플레이스쉬프터 시장만을 바라본 것이 아니라, IP 셋탑박스 등에 응용할 수 있는 기반 기술 확보에도 신경을 썼다는 것은 분명하지만 그래도 우리 돈으로 3000억이 넘는 액수는 여전히 과해 보입니다. 인수자의 입장에서 성공적인 거래인지는 시간이 지나봐야 알겠습니다만 이후 어떻게 평가될지 상당히 궁금합니다.
VC-1 은 WMV9 입니다. WMV9 이 어떻게 VC-1 이란 이름으로 바뀌어 나타났는지에 대해서는 이전에 올린 글을 참조하시면 되겠습니다. 이후 WMV9 과 VC-1 을 섞어서 말씀드리더라도, 둘 모두 같은 대상을 지칭하는 것입니다.
보통 MPEG 과 같은 스펙이 하나 나오는 데는 수년의 시간이 걸립니다. 그 시간 동안 수 많은 관련 업체, 연구기관들이 위원회에 참여하여 제안을 하고 토론을 하면서 스펙을 다듬어 나갑니다. MS 역시 H.264 표준화 과정에 참여한 기업이었습니다. H.264 스펙 정립과정 중 MS는 압축효율 향상이 최우선 과제인 H.264 와는 달리 보다 가볍고 계산상 효율이 뛰어난 코덱의 필요성을 느끼고 (우선적으로 PC 에서 잘돌릴 수 있는지가 MS에의 최대 관심사일 수 밖에 없습니다) WMV9 으로 불리게될 독자적 코덱 개발에 박차를 가하게 됩니다.
이전 글에서 이미 말씀드렸던 내용이지만 VC-1 이 WMV9 의 Advanced Profile 만을 포함 하는 것은 아닙니다. WMV9에는 아래와 같은, Simple Profile, Main Profile, Advanced Profile의 세가지 프로파일이 있고, VC-1 도 위의 프로파일을 모두 포함하고 있습니다. Advanced Profile 이 Main Profile 에 비해 특별히 다른 코딩 툴(알고리즘)을 가지고 있는 것은 아니며, Interlaced 소스 인코딩과 전송 포맷 독립적 스트림을 생성한다는 점만 다르다고 합니다. 전송과 관련된 배경 내용은 예전 포스팅을 참조하시면 됩니다.
이전 글에서 H.264 의 무거움에 대해 말씀드렸습니다만 이에 대비되는 VC-1의 미덕은 보여주는 H.264 와 비견되는 퀄리티에 비해 가볍다는 점입니다. MS 의 주장에 따르면 프레임 디코딩 시간이 H.264 에 비해 두배 빠르다고 합니다. 이것은 다른말로 초당 같은 수 많큼의 프레임을 디코딩 할 때 PC에서 CPU 점유율이 H.264에 비해 절반 밖에 되지 않는 다는 말이 됩니다. 물론 여기에도 과장이 섞여 있습니다. 어떤 Profile 을 적용하였는지, 그리고 특정 Profile 에서 어떤 옵션이 사용되었는지 (예를 들어 H.264 Main Profile 에서 엔트로피 코딩을 CABAC 대신 CAVLC 를 쓰면 디코딩시 부하가 현격하게 줄어듭니다.) 에 따라 다릅니다.
어쨌든 전체적인 퍼포먼스 면에서 VC-1 이 낫다는 것은 부정할 수 없는 사실이며, 퀄리티와 효율이라는 두마리 토끼를 모두 놓치지 않았다는 점이 VC-1 의 가장 큰 미덕입니다. (인터넷에서 x264 로 인코딩된 컨텐츠와 WMV9으로 인코딩된 컨텐츠를 다운 받아 CPU점유율을 비교해 봐도 됩니다.) 코덱 자체로는 이러한 점이 WMV9 의 가장 큰 장점이지만, 실제 WMV9 의 진정한 힘은 다른데에 있습니다.
DRM 이 적용된 인터넷 강의를 RIA 형태로 서비스 하는 사이트를 컨텐츠 관리 시스템까지 묶어서 사용자가 원하는 형태의 커스터마이즈된 UI 로 설정할 수 있는 스트리밍서버, 인코더까지 전체적으로 개발해야 한다고 가정해 보죠. 이를 몽땅 MS 솔루션으로가는 것과 비 MS 솔루션인 VP6 또는 H.264 (플래시를 쓰건 안쓰건) 를 이용하여 비 MS 솔루션으로 가는 것을 비교해 보면 개발 생산성면에서, 그리고 관리면에서 게임이 안됩니다.
바로 여기에 VC-1 의 진정한 힘이 있습니다. Windows Media Encoder 나 Expression Encoder 를 쓰면 인코딩에 대해 잘 모르는 사람들도 손쉽게 VC-1 비디오를 만들 수 있습니다. Windows Media Service 는 RTSP/RTP 와 같은 표준 프로토콜을 지원하며, 어도비의 Flash Media Server 와 같은 고가의 서버 제품을 구매하지 않아도 되게 해 줍니다.(물론 Windows Server 2003 을 사야합니다. ^^;) H.264 스트리밍을 위해서는 공짜인 Darwin 서버가 있습니다만, 관리/사용상의 편리함은 Windows Media Service를 따라갈 수 없습니다. 요즘은 어떤지 모르겠지만 몇년전 다윈 서버가 Trick Play (Fast Forward 나 Rewind 같은 앞뒤 배속 플레이)를 지원하지 않아 데모를 하려다가 낭패를 본 기억이 있습니다 ㅡㅡ;. DRM 역시 개발자 들에게 익숙한 컴포넌트 베이스로서 서버측 솔루션을 손쉽게(?) 구축 할 수 있게 해줍니다. PC를 타겟으로 한다면 DRM 클라이언트는 신경쓸 것도 없고, PC가 아니라도 PMP 나 셋탑박스 등 각종 디바이스들에 DRM 클라이언트를 포팅하기도 무지 쉽게 되어 있습니다.
이런 제품군만 제공하는게 아니라 각각의 제품들은 COM 컴포넌트로서 원하는 대로 커스터마이징 할 수 있습니다. 데스크탑 애플리케이션이건 웹기반 애플리케이션이건 인코딩하고, 스트리밍 서버에 게시하는 등의 작업을 원하는 형태의 애플리케이션으로 만들어 낼 수가 있습니다.
또한 이 모든 작업들이 .NET 이라는 일관된 플랫폼 상에서 가능합니다. 컨텐츠 관리 시스템도 RIA 도 모두 닷넷 이라는 플랫폼을 타겟으로 개발 할 수 있기 때문에 웹애플리케이션 따로, RIA 따로, 각종 서버 연동 따로.... 생각만 해도 머리아픈 각기 다른 언어와 개발 툴의 학습에서 개발자를 해방시켜 줍니다. <- 쓰고 나니 왠지 MS 에서 나온 White Paper 같은 말투네요 ㅎㅎ
이러한 개발자의 관점에서 현실을 바라보면 왜 너도나도 H.264를 외치는지 이해하기가 힘듭니다. 물론 ISO 표준과 SMPTE 표준의 권위는 다르겠지만 상용 소프트웨어나 웹사이트를 개발하는 현업의 개발자들에게는 아직까지는 MS 가 가려운 곳을 훨씬 제대로 긁어주기 때문입니다. 공개된 표준이란 것도 어차피 자본의 논리로 움직이는 것 아닌가요? ISO 표준에 참여한 수많은 기업체 (몇개인지 모르겠지만 A4 용지 몇장으론 어림 없을 겁니다) 들이 자본과 권력에서 벗어난 순수한 이상의 결정체로서의 H.264를 만들지 않은 것은 분명합니다. (논쟁을 원하는 것은 아니니 반대 의견이신 분들은 너무 화내지 마시구요^^)
두서 없이 긁적 거린 잡담 수준의 글에 결론이란게 가당찮습니다만... 몇가지 정리하면서 글을 마칠까 합니다.
VP6, H.264, VC-1 세가지 코덱을 두고 절대적으로 어떤게 낫다고 주장하기는 힘듭니다. 코덱마다 장단점이 있고, 이중 어떤 장점 또는 단점에 개인적인 무게 중심을 두느냐에 따라 코덱에 대한 평가는 극히 주관적일 수 밖에 없습니다. 단지 특정 목적에 어떤 것이 더 적합하다라는 말을 할 수 있을 뿐입니다.
Flash Video Codec 에 H.264 가 추가 되었다고 해서 플래시에서 HD 가 되는 것은 아닙니다. Flash 에서 H.264 로 HD 비디오를 보여주기에는 아직 전 세계에 널린 PC 의 평균적인 퍼포먼스가 낮습니다. 오히려 VP6.0 이 플래시에서의 HD 를 위해서 현실적인 솔루션입니다.
VC-1 의 장점은 압축효율(퀄리티) 대비 계산효율입니다. 그외에 부가적으로 MS 에서 제공하는 종합선물셋트의 혜택을 누릴 수 있다는 점입니다. 개발자에게는 현실적으로 가장 매력적인 솔루션입니다.
H.264 는 ISO 표준이라는 네임밸류가 가장 큰 힘이자 장점입니다. 이러한 힘을 바탕으로한 컨텐츠의 가용성(PC 뿐만아니라 모바일 디바이스 등에서도 재생가능)에 대해서는 현재(!)까지 VC-1 이나 VP6 는 마땅한 카드가 없는 상황입니다.
VC-1의 효율성(가벼움), H.264의 상대적인 무거움에 대한 얘기는 당분간만 유효합니다. 이후 그래픽 카드에서 VC-1, H.264 디코딩을 하드웨어적으로 지원하게 되면 어짜피 양쪽 모두 CPU를 거의 점유하지 않을테니깐요. 셋탑박스와 같은 임베디드용으로는 풀HD VC-1/H.264 동시지원 디코더 칩들이 이미 나와 있습니다.
개발자로서 또는 비지니스를 기획하는 입장에서 코덱을 선택해야 하는 상황이라면, 각 코덱자체의 장단점 뿐만 아니라, 상호 운용해야 하는 주변 기술, 현재 또는 가까운 미래의 컴퓨팅 환경과 같은 코덱의 가용성등을 전체적으로 고려해야 한다고 생각합니다.
저는 각 고려사항에 대한 저의 생각을 두리뭉실하게 위에서 밝혔습니다만, 평가의 관점은 개별 제품 또는 비지니스의 타겟에 따라 얼마든지 달라질 수 있다는 사실을 잊지마시기 바랍니다.
Tracked from 디지털 콘텐츠 플랫폼 - Media 2.02008/05/13 09:43삭제
작년(2007년) 12월 7일 워크샵을 갔다. 그때 www.sbs.co.kr의 서비스 질(quality)에 문제가 없는가?'라는 질문과 제공 방안에 대한 이야기가 있었다. 주로 동영상 화질에 관한 것이었다. 불법 콘텐츠, IPTV 등에 비교해 영상의 질이 떨어진다는 이야기다. 그러면서 이 문제를 제기한 분이 같은 bit rate의 wmv로 엔코딩(encoding)된 영상파일과 H.264로 된 영상파일을 비교하여 화질차이를 보여줬다. 이런 논의의 이면..
안녕하세요?
직접 서비스를 해본 적은 없어서 영양가 있는 답변은 못해드릴 거 같습니다. ㅡㅡ;;
이미 알고 계시겠지만 Unicast를 기준으로 한 가장 간단한 숫자상 계산은 (네트워크 대역폭 / 타겟 비트레이트)값이 동시 서비스 가능 단말 수가 되겠구요... 디스크 io 대역폭도 같이 고려되어야 할 것 같습니다.
CPU 퍼포먼스 보다는 위와 같은 io 쪽에 제약을 받는 것으로 알고 있습니다. 시원한 답변 못드려 죄송합니다. ^^;;
영상에 대해서 배우는 초보자 입니다. ^^
도움도 얻고자 글을 남깁니다.
예로 a.avi 고화질 영상을 h.264 코덱을 사용해서 a.wmv로
트랜스를 할 수 있을까요?
둘이 다른 표준인것 같아서.... 서로 호환이 되는지도 모르겠구요..
이제 막 시작해서 막막한 마음에 위의 예가 맞는지 모르지만 질문
남깁니다. h.264 코덱을 이용해서 hd wmv를 만들 수 있는지
고견을 듣고자 합니다 ^^
앞선 포스트에서 코덱과 관련된 이야기들을 했던 관계로, 이번 포스트에서는 현재 가장 많이 사용되고 있는 H.264, WMV9/VC-1, VP6/7 에 대해 이런저런 잡담을 좀 늘어놓을까 합니다. (사실 기술적인 세부 사항을 잘 모르기 때문에 어떻게 얘기해도 잡담 수준밖엔 안됩니다만...^^;;;)
결론부터 말씀드리면 이 글은 VC-1 에 대한 아니 엄밀히 따지면 MS 에 대한 칭찬 쪽으로 흐르게 될 것 같습니다. 물론 얼토당토 않은 얘기를 하지는 않겠습니다만 혹시라도 기분이 상할 것 같다고 생각하시는 분은 시간 뺏기고 찝찝해 하지 마시길 부탁드립니다.
각 코덱에 대한 정보를 찾다가 이 글을 읽게 되신 분들께는, 이 글은 어디까지나 저의 주관적인 견해임을 감안하시기를 부탁드립니다.
1. VP6/7
먼저 VP6/7 는 미국의 On2 Technologies 사의 표준과는 상관없는 Proprietary 한 코덱입니다. 두리뭉실하게 VP6 라 불리는 코덱은 실상 그 종류가 많아서, 엄밀히 따지면 VP6.0, VP6.1 VP6.2 의 세가지가 있습니다. On2 에서는 예전에 이렇게 서로다른 VP6 의 버전을 아래와 같은 명칭으로 부르기도 했습니다.
프로파일이란 용어를 모르시는 분을 위해 간략히 의미를 요약해 보면... 특정 비디오 코덱은 비디오 압축을 위해 여러가지의 알고리즘을 정의합니다. 프로파일이란 특정 목적에 맞게 이들 알고리즘의 일부를 셋트로 묶은 것입니다. 인/디코딩 속도가 중요한 경우에는 상대적으로 단순한 알고리즘셋을 적용하고, 시간이 더 걸리더라도 결과물의 압축효율 또는 퀄리티가 중요한 경우는 상대적으로 복잡한 알고리즘 셋을 적용하는 식입니다. 물론 프로파일간에 공유되는 알고리즘도 있습니다. 보통 Simple Profile 이라 하면 압축효율보다는 계산상의 효율을 위해 비교적 인/디코딩 시 프로세서에 부하가 덜 걸리는 알고리즘 셋을 가지고 있습니다.
이중 UCC 계를 주름잡은 플래시 비디오 코덱은 VP6.2 입니다. VP6.2 는 플래시 8부터 새로운 플래시 비디오 코덱으로 채택되면서 기존 플래시 버전에서 사용되던 H.263 기반 Sorenson 코덱보다 월등한 화질을 보여주었습니다.
얼마전 플래시에 H.264 적용 소식과 함께 플래시에서 HD 영상을 재생하기 위한 용도라고 소개된 VP6 HD 코덱은 VP6.0 Simple Profile 입니다. HD 처럼 해상도가 높은 영상을 디코딩 하려면 CPU 에 부하가 많이 걸리므로, 기존 VP6.2 보다는 좀 가벼운 VP6.0 을 갖다 붙여 놓고 VP6 HD 라고 부르는 것입니다. 좀 멋쩍은 이름입니다... ㅎㅎ. (참고로 H.264로는 HD 이거 힘듭니다.... 이 부분은 H.264 이야기에서 덧붙이겠습니다)
VP7 은 Skype 의 화상통화시 사용되는 비디오 코덱입니다. VP6 도 훌륭하지만 VP7이 보다 나은 화질을 보여주는 것 같습니다. 보통 VP7과 H.264, WMV9 의 화질을 동시에 비교해 보신분들은 VP7 이 낫다고 하는 경우가 많습니다. VP7의 장점은 특히나 낮은 비트레이트에서 두드러집니다. 사실 높은 비트레이트에선 뭘로 인코딩해도 화질이 좋으므로 비교 의미도 별로 없습니다.
On2 는 초창기부터 저대역 코덱에 대한 연구개발을 계속해 왔던 회사입니다. 조그만 회사가 공룡 MS 에 눌려 휘청거릴 때, 플래시라는 동아줄이 내려오는 바람에 죽다 살아난 것으로 알려져 있습니다만, VP7 이 보여주는 퀄리티는 On2 가 가진 코덱에 관한 기술력을 단적으로 말해준다 하겠습니다. 부디 플래시에 H.264가 적용되더라도 자신의 강점을 잘 살려 롱런(또는 좋은 조건에 인수되거나) 했으면 합니다.
2. H.264
H.264 는 ISO 및 ITU-T 공동 결과물로서 ISO 에서는 MPEG4 Part 10 Advanced Video Coding으로, ITU-T에서는 H.264 로 부릅니다. H.264 는 처음 릴리즈 시에 Baseline Profile, Main Profile, Extended Profile 의 세가지 프로파일 셋을 가지고 있었으나 이후 High Pofile 부터 High 로 시작되는 무수히 많은 프로파일을 추가로 정의하였고, 이중 High Profile은 HD-DVD, 블루레이 용 프로파일이 됩니다. 표준을 릴리즈 한후 단순 amendment 라고 하기에는 이례적인 High Profile 의 추가가 이루어진 것은, 이후 공개된 VC-1 에서 사용된 몇몇 아이디어를 차용하기 위함이었다는 얘기가 있습니다.
기존의 MPEG4 비디오(정확히 MPEG4 Part2) 를 개선하기 위해 고안된 H.264는 동일 비트레이트에서 더 나은 퀄리티 구현이라는 목적은 달성하였으나, 워낙에 똑똑한 분들이 퀄리티에만 중점을 둔 나머지 효율성은 좀 떨어진다는 업계의 의견이 많았습니다. 특히, 블럭현상을 감소시키기 위해 적용되는 in-loop deblocking filter 의 과도한 처리나, Baseline Profile 외 나머지 프로파일에 적용되는 비손실 압축을 위한 CABAC('카박' 이라고 읽습니다) 알고리즘의 무거움이 많이 지적되었습니다.
참고: 영상 압축은 개념적으로 '프레임 샘플링->프레임내 작은 블럭 단위별로 픽셀을 시각적 민감도(정확한 용어는 공간주파수)기준으로 변환->압축률을 높이기 위해 시각적으로 둔감한 부분 손실->비손실 압축(엔트로피 코딩)' 의 단계를 거칩니다.
실제로 CABAC 이 적용된 H.264 HD 영상은 3.0GHz CPU 를 가진 데스크탑 PC 에서조차 제대로 돌아가질 않습니다 (반면 VC-1 이나 위의 VP6 HD 같은 경우는 쌩쌩 잘 돌아갑니다) . 예전에 어떤 DSP 에서는 SD 급의 WMV9 동영상은 문제없이 잘 돌아가는데 같은 비트레이트와 해상도의 CABAC 이 적용된 H.264 메인 프로파일 동영상의 디코딩은 아예 불가능한 경우도 있었습니다.
H.264 는 그러한 무거움 때문에 말만 무성하지 실제품에의 응용은 H.264 디코딩 전용 칩들이 시장에 나오기 전까지는 무척 드문 수준이었습니다. 심지어 3년 전 쯤 어떤 국제적인 방송 전시회에서는, 한 업체가 DSP 여러개를 내장한 데스크탑 PC 만한 케이스의 H.264 HD 지원 셋탑박스를 들고 나오는 웃지 못할 일이 있기도 했습니다.
어쨌거나 요즘은 전용 칩들의 개발로, 모바일 디바이스에 조차 H.264 를 지원할 수 있게 되었습니다. IPTV 를 하겠다는 사업자들도 표준이라는 이유로 너도나도 H.264 HD 를 채택하겠다고 했으나, 이들의 요구에 맞는 셋탑박스를 만들기 위해 필요한 H.264 HD 지원 디코더칩이 안정된 형태로 나온 것은 불과 작년 쯤이었습니다.
보통 직접 비교해 보니, 다른 코덱에 비해 H.264 의 화질이 뛰어나다고 하시는 분들이 많은데, 거기에는 약간의 트릭이 있습니다. 특히나 낮은 비트레이트에서 H.264 의 화질이 좋게 느껴지는 것은 H.264의 in-loop deblocking filter 의 덕택입니다. 여기에는 trade-off 가 숨어 있습니다. H.264는 블럭 현상을 없애기 위해 영상을 너무 지나치게 문지릅니다. 만일 눈밭에 밝은 색의 옷을 입고 있는 사람을 아주 멀리서 촬영한, 그래서 사람이 전체화면에서 아주 조그맣게 나오는 동영상이 있다면 H.264의 경우는 특유의 문지름 효과로 사람이 눈과 섞여(정확히는 사람과 눈의 경계 부분이 문질러저) 어디에 사람이 있는지 알아볼 수 없는 사태를 만들어 버리기도 합니다. 한마디로 부드러움을 얻기위해 선명함을 잃어버리는 것이죠.
이런 이유로 PSNR 측정 (영상을 디코딩 하여 원본 화상과 비교하였을 때 원래 화상과 왜곡된 화상의 비율을 측정하는 방법) 시 H.264 가 눈에 보이는 느낌 만큼 다른 코덱에 비해 뛰어난 결과를 보여주지는 않습니다.
사실, VC-1&H.264와 같은 기술과 비교하기에 On2의 기술은 조악합니다. 최고의 화질은 아니라고 보입니다. (VP7)
전 H.264를 지지하는데, 일단 저희 회사가 지분이 있기 때문이지요. 게다가 VC-1은 MS가 다 해먹으려는 전략의 초석이 될 기술이기 때문에 그 기술의 완성도는 인정!(따라서 널리 쓰여야 합니다) 그러나 견제가 필요한데, 현재 가능한 것은 오직 H.264 밖에 없으므로 동반 성장을 밀어주고 싶네요!
전 기술적인 세부사항은 잘 모르기 때문에 on2사의 기술적 완성도를 평가할 수 없습니다만... 한가지 비화를 말씀드리자면 예전에 DMB 비지니스를 하는 T모사에서 내부적으로 코덱 테스트를 수행한 적이 있었습니다. 육안과 PSNR 측정을 통한 결론은 300~400kbps 와 같은 저대역에서의 화질은 on2 의 우세였습니다.
독점과 관련된 치원님의 의견에는 저도 동의합니다. 저의 친 MS적인 견해는, 개발자의 고달픈 삶의 관점에서만 바라본 사물의 특정 단면에 대한 생각입니다.^^;
이제 VC-1을 모르시는 분들은 별로 없겠지만, 혹시 모르시는 분들도 이름만 모를 뿐 실제로는 다 알고 계실 겁니다. 제가 '이름만 모른다' 란 표현을 쓴 이유는 VC-1이 바로 WMV9 이기 때문입니다.
이 글은 쓴 이유는 얼마전까지 이슈가된 MS 의 Open Office XML 논쟁을 보면서 WMV9이 VC-1 이란 이름을 달고 SMPTE 표준으로 선정된 수년전의 상황이 생각났기 때문입니다.
포스트 MPEG4 코덱 중 가장 대중적인 코덱은 H.264, WMV9, VP6/7 정도가 있습니다. 포스트 란 말을 쓴 이유는 이 코덱들이 MPEG4 가 나온 이후에 이를 개선하고자 고안되었기 때문입니다.
H.264 는 ISO 및 ITU-T 공동 결과물로서 MPEG4 Part 10 Advanced Video Coding 이란 말로도 불립니다. VP6/7 은 미국 ON2 사의 코덱으로서 플래시 버전 8에 포함되면서(VP6.2) UCC 용 코덱으로 더욱 유명해 졌습니다. WMV9 은 따로 설명이 필요 없겠구요.
각 코덱마다도 빠(?) 들이 있습니다만, 저의 주관적 견해는 다른 포스트를 통해 밝히기로 하고, 여기서 각 코덱의 성능 비교를 하지는 않겠습니다.
각 코덱들이 서로의 활동영역을 넓히고 있을 때 쯤 MS 가 H.264 를 보면서 느낀 것은 비표준으로서의 설움이었던 것 같습니다.
성능 면에서 별 차이 없고(이거 논쟁거리 되는 발언입니다만), 중소사업자, 인터넷 방송이나 개인들은 엄청나게 사용해 주고 있는데, 대형 사업자 주도 또는 국가적 프로젝트에는 매번 제외되는 현실을 보았던 것입니다. 실제로는 무수한 레퍼런스가 있는 메이저이나 표준이 아닌 이유로 명분적 마이너가 되는 상황 말입니다.
우리나라의 DMB 방송의 비디오 코덱이 H.264 입니다. HD-DVD 도 H.264 가 유력했습니다. IPTV 를 하려는 각국의 사업자들은 표준이란 이유로 H.264 를 채택하려고 합니다. MS 의 입장에서는 코덱 전문가들 영입해서 뭔가 쓸만한 거 만들었다 싶었더니 푼돈만 만질 판입니다.
여기서 MS 가 떠올린 아이디어는 다름아닌 OOXML 과 같이 복수 표준으로 만들자는 거였습니다. 이미 H.264 는 ISO 표준인 관계로 MS는 SMPTE(Society of Motion Picture and Television Engineer) 란 조직에 작업을 하고 이들을 등에 업었습니다. 얼마의 시간이 지난 후(저는 얼마가 걸렸는지는 알지 못합니다만 아마도 파격적인 시간이 걸렸으리라는 것은 짐작됩니다) WMV9 은 VC-1 이란 이름의 SMPTE 표준으로 나타납니다.
VC-1 란 이름이 선택된 이유는 모르지만 WMV9(Windows Media Video9) 란 이름을 쓸 수 없었던 것은 분명합니다. 공개된 표준의 이름에 Windows 라니요… 하지만 MS 에서 약간의 미련은 남았었나 봅니다. VC-1 이란 이름 전에 잠시나마 VC-9 이란 이름이 사용되었으니깐요…
어쨌든 열심히 작업한 보람이 있어, VC-1 은 H.264 와 함께 HD-DVD 의 표준 코덱으로 선정되게 됩니다. DVD (MPEG2) 와 달리, HD-DVD 는 비디오 코덱에 있어 복수 표준을 가지게 된 것입니다.
VC-1 이 표준이 되고 난 다음 MS의 WMV9 에 대한 설명은 약간은 코미디 입니다. MS 에 의하면 WMV9는 이제 'Microsoft implementation of VC-1' 입니다. 갑자기 아들이 아버지가 되어버렸습니다 ㅋㅋ.
가끔 VC-1 을 WMV9 Advanced Profile 이라 알고 계시는 분들도 있는데, 이는 말만 무성했던 WMV9의 Advanced Profile 이 VC-1 을 통해서 공개되었기 때문입니다. 실제로 VC-1은 WMV 전제를 포함합니다.
MS 가 비디오 코딩에 대한 표준안 외에 함께 제출한 또다른 표준안이 있었는데, 이것은 VC-1 비디오를 MPEG2 Transport stream 에 실어 보내는 방법에 관한 것이었습니다.
이전까지 MS 가 WMV 를 위해 사용하고 있던 전송 포맷은 ASF 라는 형식이었습니다. 확장자 .asf 및 .wmv, .wma 같은 파일들이 ASF 포맷입니다. 하지만 ASF 를 표준화 하기에는 현실적 문제가 너무 많았습니다. 가장 큰 장애는 대부분의 디지털 방송 전송과 관련된 장비들이 MPEG2 의 TS(Transport Stream) 를 사용하고 있었다는 점이었습니다. 이에 고민하던 MS는 TS 에 VC-1 비디오를 담는 스펙을 함께 제출하게 됩니다.
VC-1 이 SMPTE 표준으로 선택된지 상당한 시간이 흘렀고, HD-DVD, 블루레이의 코덱으로 선택되는 등 많은 성과도 있었습니다.
하지만 세계는 넓고 먹어야할 시장은 아직도 많습니다. 아직도 갈길은 먼데 향후 VC-1 의 앞날이 밝지만은 않은 듯 합니다. 이에 대한 의견은 직전에 포스팅한 글로 대신해야 할 것 같습니다.
이올린에 북마크하기
이올린에 추천하기
댓글을 달아 주세요