linuxism

※ 반드시 먼저 읽어 주세요.

제 게시글에서 "동영상"은 "영상+소리"정보를 가진 파일을 가르킵니다.

단지 "영상" 정보만을 가진 파일을 말할 때는 "비디오", "비디오 파일", "비디오 스트림"이라고 말하겠습니다.

"비디오"란 용어을 저처럼 "영상"정보만을 가진 파일을 가르킬 때 사용하는 경우도 있고, "영상+소리"정보를 가지 파일을 말할때 사용하는 분도 있습니다.

이렇게 "비디오"란 용어 하나만으로도 충분히 글을 잘 못 읽고 혼동을 줄 가능성이 높기에 시작전에 용어 정리 부터 하는 것입니다.

1. 컨테이너 포맷이란?

동영상 파일을 말할 때는 "컨테이너 포맷", "비디오 코덱", 그리고 "오디오 코덱"에 대한 정보를 모두 이야기 해야 합니다.

파일 확장자만 이야기하면 되지 않나 싶죠. 왜 3가지 정보나 이야기해야 하는지 그 이유를 알아 보도록 하겠습니다.

1. 컨테이너 포맷의 개요

위 그림은 요즘 많이 돌고 있는 블루레이립 mkv 파일을 그림으로 그려 놓은 것입니다.

컨테이너 포맷은 "비디오"와 "오디오"를 담아두는 "상자"나 포장해 둔 "포장지" 그 쯤으로 생각하시면 충분합니다.

그림에서 "비디오"는 x264코덱으로 만들어졌고, "오디오"는 DTS코덱으로 만들어졌습니다.

그런데 "비디오"와 "오디오"가 따로 따로 존재한다면 동영상 파일이라 말할 수 없겠죠.

컨테이너는 이렇게 "비디오"와 "오디오"를 하나의 파일로 만드는 역할을 합니다.

우리가 보통 파일의 정체를 확인하는 방법은 확장자를 보는 방법입니다.

하지만 동영상을 판단할 때 확장자를 보아서는 단지 컨테이너 상자가 무엇인지 알수 있을 뿐이지, 상자 안에 들어 있는 "비디오"와 "오디오"가 어떤 코덱으로 만들어져 있는지 알수 없습니다.

동영상 파일의 확장자인 avi, mkv, asf, mov, vob, flv, mp4, mpeg, ts, ps들이 모두 컨테이너 포맷을 가르키는 말로 "파일 형식"이라고도 말합니다.

컨테이너에 포함된 "비디오"와 "오디오"를 만드는 과정을 "인코딩"이라고 하며, 코덱이라는 압축 프로그램이 담당합니다.

"비디오"와 "오디오"를 재생하는 과정을 "디코딩"이라고 하며, 이 또한 코덱이 담당합니다.

동영상이 재생이 안될 때는 "컨테이너 포맷"을 확인하는 것도 중요하지만 그보다 "비디오 코덱", "오디오 코덱"을 확인하는 것이 더 중요합니다.

그렇기에 동영상을 말할 때는 3가지 정보를 모두 말해야 하는 것입니다.

동영상을 구체적으로 표현하는 방법

DivX로 인코딩된 비디오와 MP3로 인코딩된 오디오가 AVI 컨테이너에 들어 있는 동영상

DivX 비디오와 MP3 오디오가 AVI에 들어 있는 동영상

DivX.avi 동영상 (이처럼 오디오 코덱은 생략하고 비디오만을 써서 파일명처럼 간단히 표현하기도 하지만 이경우는 아는 사람만 알게 되죠.)

여기까지 읽은 분들은 동영상 파일이 어떤 컨테이너 포맷을 사용했는지 쉽게 알수 있을 것입니다.

이제 좀 자세히 들여다 보죠.

* Audio Video Interleave 컨테이너 포맷은 avi라는 파일 확장자를 사용합니다. IMF처럼 글자의 첫글자를 따서 AVI 컨테이너라고 줄여 말하는 것입니다.

* Advanced Systems Format은 asf 확장자를 사용합니다. AVI처럼 첫글자를 따서 ASF 컨테이너라고 줄여 말합니다.

   동영상 파일중에 wmv라는 파일 확장자를 가진 것이 있습니다. wmv라는 컨테이너는 없습니다. 사실 이것은 ASF 컨테이너입니다.

* Matroska 컨테이너 포맷은 확장자를 mkv, mka 두가지를 사용합니다. 이 컨테이너 포맷을 말할 때 확장자를 그대로 따서 mkv 컨테이너라고 말하는

   것이 일반적이지만 사실은 잘못된 표현입니다.

* QuickTime File Format (QTFF)는 확장자를 mov를 사용합니다. 보통 퀵타임이라고 말하는 컨테이너 포맷입니다.

* MPEG Program Stream(MPEG-PS)은 확장자를 mpeg, mpg, ps를 사용합니다. MPEG-1, MPEG-2 코덱으로 만들어진 비디오가 들어갑니다.

   DVD-Video에 사용되는 VOB파일도 이 MPEG PS 컨테이너를 사용합니다.

* MPEG Transport Stream(MPEG-TS)은 확장자를 ts를 사용합니다.  MPEG-1, MPEG-2 코덱으로 만들어진 비디오가 들어갑니다.

   MPEG-PS와 똑같은 비디오가 들어가는 것을 알수 있습니다. 사용목적에 따라 두가지 컨테이너를 만들었습니다.

   디지털 방송에서 사용되는 형식으로 녹화파일에서 이 확장자를 사용하는 것을 볼수 있습니다.

* OGG 컨테이너를 사용한 비디오는 ogm, ogg, ogv등을 사용합니다. 오디오 파일인 ogg 때문에 헛갈리게 됩니다.

   오디오 파일은 Vobis코덱으로 만들어진 오디오가 OGG컨테이너에 들어 있는 형태로 그래서 단지 ogg라고만 하지 않고 ogg vobis라고 하는 것입니다.

2. 비디오 코덱, 오디오 코덱을 확인하는 방법

앞서 말했듯이 동영상에서 컨테이너 포맷은 확장자로 쉽게 알수 있지만, 비디오 코덱과 오디오 코덱은 파일명으로는 알수 없습니다.

프로그램을 이용해 비디오, 오디오 코덱을 확인하는 방법 대해 알아 보겠습니다.

첨부파일에서 DP MediaInfo를 다운받아 압축을 풀어 놓습니다. 무설치버전이라 설치하지 않고 더블클릭으로 실행합니다.

Open버튼을 클릭해 동영상을 열기합니다.

그림의 좌측에서 동영상의 "컨테이너 포맷", "비디오 코덱", "오디오코덱"을 알수 있습니다.

그림을 보시면 열기한 동영상의 컨테이너 포맷은 AVI이며, 비디오 코덱은 DivX 3 Low, 오디오 코덱은 MPEG-1 Audio Layer 3(줄여 MP3)입니다.

프로그램의 오른쪽 구획에서 그림처럼 비디오 파일의 "포맷"과 실제 비디오 파일을 만들때 사용한 "코덱"을 확인할 수 있습니다.

포맷과 코덱은 분명히 다른 개념입니다.

그림에서 보시면 비디오의 파일 포맷은 "MPEG-4 Visual"이며, DivX 3 코덱을 사용하여 만들었습니다.

"MPEG-4 Visual(=MPEG-4 Part 2)" 파일 형식을 따르는 코덱은 DivX3뿐만 아니라, Xvid, DivX 4, DivX5가 있습니다.

3. 플레이어의 동영상 지원 포맷 

컨테이너 포맷은 단지 "비디오"와 "오디오"를 하나로 묶는 역할을 합니다.

실제 재생은 코덱이라는 프로그램이 담당합니다.

만약 플레이어가 AVI, ASF, MOV, MKV, MPEG 컨테이너를 지원한다는 한다면, 플레이어가 그 컨테이너에서 "비디오"와 "오디오"를 꺼낼수 있다는 말이지, 그안의 "비디오"와 "오디오"를 재생할 수 있다는 말이 아닙니다.

실제 재생은 컴퓨터에 설치된 "비디오 코덱" "오디오 코덱"이 수행합니다.

코덱에서 재생능력만 때어낸 디코더라는 프로그램이 있습니다.

이 디코더를 플레이어가 내장한 경우에는 자신의 컴퓨터에 코덱을 설치하지 않아도 재생이 되는 것입니다.

그런데 컴퓨터에 코덱도 설치되지 않고, 플레이어에 내장 디코더도 없는 경우엔 재생에러가 발생합니다.

예를 들어 곰플레이어로 동영상 파일을 열었을때, 화면은 나오나 소리가 나오지 않는 경우가 있습니다.

이 경우는 비디오 코텍이나 디코더가 컴퓨터나 플레이어에 있기 때문에 화면을 출력되나, 오디오 코덱이나 디코더가 컴퓨터나 플레이어에 설치 되지 않았기 때문입니다.

무턱대고 통합코덱을 깔것이 아니라 코덱정보를 알아 그 동영상에 맞는 오디오 코덱이나 디코더를 설치해 주면 해결됩니다.

통합코덱의 설치는 어떤 코덱인지 모르니 모든 코덱을 깔아 재생되게 만드는 것으로, 프로그램간의 충돌 원인이 될 가능성이 높습니다.

컴퓨터와 달이 동영상을 지원하는 PMP, 디빅스 플레이어, 디빅스를 지원하는 DVD 플레이어, 동영상의 USB 호스트기능을 지원하는 TV등에서는 이미 지원하는 코덱이 정해져 있습니다. 추가 설치가 어렵죠.

기기들은 재생할수 있는 동영상의 정보를 메뉴얼에 명시합니다.

이때 지원하는 "컨테이너 포맷" "비디오 코덱" "오디오 코덱"에 대한 명확한 표시를 해야 하는데, 그렇지 못한 경우를 종종 보게 됩니다.

아래 표는 비교적 명확하게 명시를 한 모회사의 TV의 "동영상 지원 파일" 리스트입니다.

H264 코덱으로 만들어진 "비디오"는 mkv 컨테이너에도, avi 컨테이너에도 모두 들어 갈 수 있습니다.("h264.mkv"와 "h264.avi")

그러나 표를 보면 H264 비디오가 들어간 mkv는 재생하나 H264 비디오가 들어간 avi파일은 재생할 수 없음을 알 수 있습니다.

H264 비디오가 들어간 avi파일을 재생하려면 어떻게 해야 할까요?

곰 인코더, 팟 인코더 같은 프로그램으로 재인코딩하면 어떨까요? 물론 가능합니다. 그러나 화질은 변하게 되고, 시간도 오래 걸립니다.

그것보다는 avi 상자에서 H264 비디오를 꺼내어 mkv 상자에 넣는 변환을 하면 이 TV에서도 재생할수 있게 됩니다.

비디오를 건드리지 않고 컨테이너만 바꾸는 이런 변환은 원본 화질을 그대로 유지하게 됩니다.

VC-1 코덱으로 만들어진 "비디오"는 asf 컨테이너에도, avi 컨테이너에도 모두 들어갈 수 있습니다. ("VC-1.asf"와 "VC-1.avi")

그런데 표를 보면 이 TV는 VC-1 비디오가 들어간 asf파일은 재생하나 VC-1 비디오가 들어간 avi파일은 재생하지 못합니다.

이럴때도 마찬가지로 AVI에서 VC-1 비디오를 꺼내어 ASF에 넣으면 TV에서 재생할 수 있게 됩니다.

2. 동영상 변환의 이해

동영상의 변환은 크게 2가지가 있습니다.

1. 컨테이너 포맷만을 바꾸는 방법 (비디오와 오디오를 담아두는 상자만을 바꾸는 방법)

2. 비디오를 다른 코덱으로 트랜스코딩하는 방법 (보통 컨버터라는 프로그램들이 사용하는 방법)

   (정확히는 트랜스코딩이라고 말해야 하지만 보통 강좌에서 인코딩이라고 칭합니다.)

아래 글에서 이해를 돕기위해 편의상 컨테이너 포맷을 상자라고 바꾸어 말하기도 했습니다.
 

1. 원본의 화질과 음질을 유지하기 컨테이너 포맷만을 바꾸는 방법

디먹싱(Demux, Demultiplexing), 먹싱(Muxing, Multiplexing)

디먹싱은 컨테이너 포맷에서 비디오 데이터, 오디오 데이터등의 구성요소를 빼내는 과정을 말합니다.

먹싱은 비디오 데이터나, 오디오 데이터등을 특정 컨테이너 상자에 넣는 과정을 말합니다.

디먹싱, 먹싱은 상자에서 비디오, 오디오 데이터를 빼거나 넣는 과정일뿐, 상자안의 비디오, 오디오를 변화시키지 않습니다.

따라서 원본 화질과 음질을 그대로 유지합니다.

예 1.

DVD-Video에서 립한 흔히 디빅스라고 말하는 영화파일을 준비합니다.(그림에서 왼쪽편 파일)

이 AVI파일에서 DivX 비디오와 MP3 오디오를 추출합니다.(디먹싱)

추출된 DivX 비디오와 MP3 오디오를 MKV 상자에 넣습니다.(먹싱)

2가지의 avi 파일과 mkv 파일을 비교해 보면, 비디오와 오디오를 담아두는 상자만 다를뿐 실제 비디오 데이터와 오디오 데이터는 똑같습니다.

즉 바꾸어 말하면 화질과 음질은 똑같습니다. 또한 거꾸로 MKV파일을 디먹싱, 먹싱을 통해 AVI파일로 만들수 있습니다.

※ 실제 변환

DivX 비디오가 들어간 AVI파일은 재생하지만, DivX 비디오가 들어간 MKV파일은 재생하지 못하는 플레이어가 있다면 MKV 상자에서 DivX 비디오를 꺼내 AVI 상자에 넣으면 재생 문제가 해결됩니다.

※ 참고 사항 

AVI에서 비디오, 오디오를 꺼내 MKV 상자에 넣는 디먹싱, 먹싱 과정은 "mkvmerge GUI"를 이용하면 자동으로 됩니다.

하지만 H264 비디오의 경우 AVI에 넣었을때 약간 문제가 있습니다. 그래서 MKV에서 AVI로 바꾸는 과정은 상당히 까다롭습니다.

예 2.

DVD 타이틀의 본편 영화는 VOB이라는 컨테이너 상자에 담겨있습니다. (MPEG-PS은 확장자를 mpeg, mpg를 사용하지만, DVD에서는 vob을 사용합니다.)

DVD 타이틀에서 MPEG-2 Video(=MPEG2) 비디오 파일과, AC-3 오디오 파일이 들어가 있는 VOB파일을 립핑합니다.

이 VOB파일에서 MPEG-2 Video 파일(확장자 .m2v)과 AC-3 오디오 파일(확장자 .ac3)을 디먹싱한뒤, MKV파일로 먹싱합니다.

이렇게 만들어진 MKV파일과 VOB파일은 똑같은 비디오 데이터와 오디오 데이터를 가지기에 화질과 음질은 똑같습니다.

참고 사항 

사실 디먹싱, 먹싱과정을 따로 나누어 설명했지만, MKVMerge GUI라는 프로그램은 VOB을 MKV로 만드는 과정을 한번에 자동으로 실행합니다.

2. 파일크기를 줄이기 위한 트랜스코딩 방법

트랜스코딩이란 특정 코딩방식의 파일을 다른 코딩방식으로 바꾸는 것을 말합니다.

흔히 변환이라고도 말하고 인코딩으로 칭하기도 합니다.(바닥 인코더, 곰 인코더, 팟 인코더에서 사용하는 방법)

(인코딩이라 말하는 것은 잘못된 표현입니다. 같은 코덱으로 재인코딩, 다른 코덱으로 트랜스코딩한다고 해야 합니다.)

흔히 디비디립이나 블루레이립 파일을 만드는 과정이 트랜스코딩을 이용한 방법인데 그림을 통해 알아보겠습니다.

예 : 디비디립

DVD 타이틀에서 본편영화가 담겨있는 VOB파일을 추출합니다.

VOB 상자에서 MPEG-2 Video를 꺼내어 DivX코덱으로 인코딩합니다.

VOB 상자에서 DTS나 AC-3 오디오를 꺼내어 MP3코덱을 이용해서 변환합니다.

만들어진 DivX 비디오 파일과 MP3 오디오 파일을 AVI 상자에 넣습니다.(이때는 먹싱과정이 필요합니다.)

이렇게 "비디오" "오디오"를 다른 코덱으로 변환하는 트랜스코딩은 많은 시간을 요구합니다.

디비디립 파일을 만드는 과정을 나누어서 설명했지만, 사실 DVD를 AVI로 만들어 주는 프로그램들은 사용자가 처음에 셋팅값을 지정해 주면 위 과정이 자동으로 실행됩니다.

이렇게 비디오와 오디오를 트랜스코딩방법은 화질과 음질을 어느정도 보장하면서 파일 크기를 많이 줄이고자 할때 사용합니다.

위에서 설명한 컨테이너를 바꾸는 방법에서 비디오, 오디오 데이터를 변환시키는 과정이 더 추가된 것입니다.

DVD 타이틀, 블루레이 타이틀에서 비디오와 오디오를 빼내면 파일사이즈가 아주 크게 됩니다.

이때 파일 크기를 줄여, 디비디립이나 블루레이립 파일을 만들때 이런 과정을 거치게 됩니다.(모든 과정을 설명하기보다 중심만 말하는 것입니다.)

이러한 방법은 설정에 지식이 필요하며, 비디오와 오디오를 모두 변환하기에 작업시간이 아주 오래 소요됩니다.

동영상을 네이버 동영상이나 유투브같은 곳에 올릴 때도 이렇게 컨테이너, 비디오, 오디오를 모두 바꾸는 방법을 사용합니다.

3. 비디오는 유지하고, 오디오만 변환하는 방법

어떤 동영상 파일에서 비디오와 오디오를 모두 변환하는 2번의 방법은 시간이 오래 걸립니다.

하지만 비디오는 그대로 두고 오디오만 변환한다고 한다면 시간은 많이 단축될 것입니다.

(오디오의 변환 시간은 짧으나, 비디오의 변환은 상당한 시간이 걸립니다.)

위 그림과 같은 변환은 아래와 같은 작업과정을 통해 이루어 집니다.

① MKV 컨테이너에서 x264 비디오와 DTS 오디오를 디먹싱하여 꺼냅니다.

② 꺼낸 DTS 오디오를 AC-3(돌비 디지털)로 변환합니다.

③ x264 비디오와 변환된 AC-3오디오를 다시 MKV 컨테이너에 먹싱하여 집어 넣습니다.

(이 과정에서 MKV대신 AVI 컨테이너나 MP4 컨테이너에 넣어도 됩니다.)

4. 결론

사용자의 필요에 따라 어떤 변환 방식을 사용할지 정해야 합니다.

하지만 컨테이너, 비디오 코덱, 오디오 코덱에 대한 이해가 없다면, 최선의 변환방법을 찾을 수 없을 것입니다.

예를 들어 컨테이너만 바꾸면 될 상황에서 불필요하게 바닥 인코더를 이용하여 원본 화질을 크게 바꿀수도 있는 것입니다.

변환 이유야 여러가지가 있겠지만 작업시간이 적고 원본의 화질과 음질을 되도록 유지하는 방법을 선택해야 할 것입니다.

출처 - http://blog.naver.com/hcwha?Redirect=Log&logNo=70095361247

코덱(영어: codec)은 어떠한 데이터 스트림이나 신호에 대해, 인코딩이나 디코딩, 혹은 둘 다를 할 수 있는 하드웨어나소프트웨어를 일컫는다. 또, 이를 위한 알고리즘을 가리키는 용어로도 쓰인다. 전기 통신분야의 용어로는 디지털 회신, 곧 송수신 장치를 뜻하였으며, "부호기", "복호기"를 합쳐 불렀다.

코덱에는 데이터 압축 기능을 사용하여 자료를 압축하거나 압축을 푸는 소프트웨어나, 소리, 동영상 등의 자료를 다른 형식으로 변환하는 장치 및 소프트웨어가 포함된다.

[편집]코덱의 어원

코덱의 어원은 다음의 세 가지를 들 수 있다^{[출처 필요]}:

• Compressor/Decompressor
• Coder/Decoder
• Compression/Decompression algorithm

[편집]압축 품질

• 손실 코덱: 대부분의 유명한 코덱들이 손실 코덱을 사용하는데, 이는 품질을 떨어뜨려 압축을 수행하는 것을 뜻한다. 사용되는 코덱과 설정에 따라 압축되지 않은 원음과 실제로 차이를 느끼기가 쉽지 않다.^[1]
• 비손실 코덱: 압축된 데이터가 원본 스트림에 존재하는 모든 정보를 보유하고 있는 코덱을 비손실 코덱이라고 한다. 대개 영상 편집처럼 빠른 처리가 필요하거나 편집 도중 화질 열화를 막기 위해 비손실 코덱이 쓰인다.

[편집]주석

1. ↑ Audio quality of aac vs. mp3 vs. wma vs. ogg encoders publisher=SoundExpert".

[편집]같이 보기

• 모뎀
• 데이터 압축

코덱 ( Codec )은 인코딩 방식 을 사용하여 데이터 의 인코딩 (encode) 및 디코딩 (암호)를 양방향으로있는 장치 및 소프트웨어 등 수 ^{[1] [2] [3] [4] [5]} . 또한이를위한 알고리즘 을 지칭하는 용어로 사용되고있다 ^{[6] [7] [8] [9]} .

코덱은 데이터 압축 기능을 사용하여 데이터를 압축 · 신장하는 소프트웨어 또는 음성 이나 동영상 등의 데이터를 다른 형식으로 변환하는 장치 및 소프트웨어가 포함된다.

코덱은 원래 데이터를 디지털 통신 회선 에서 송수신하기위한 장치를 의미하는 통신 분야의 용어였다. 어원은 Co der /dec oder의 약어이다.

다양한 코덱 [ 편집 ]

현재는 디지털 기기와 개인용 컴퓨터 (PC) 등의 발달로 코덱이라고하면 디지털 신호 사이와 디지털 데이터 간의 변환을 실시하는 것을 가리키는 경우가 많다. 옛날에는, 예를 들면, 음성 코덱, 오디오 코덱라고 부르는 경우, 디지털 신호와 아날로그 신호를 변환하는 DA 컨버터 , AD 컨버터 를 말합 있었다.

1980 년대 에 디지털 이미지를 압축하여 모뎀을 통해 아날로그 회선 통신 기술과 디지털 회선을 사용하여 음성이나 화상 등의 통신 기술이 본격적으로 실용화되고 이러한 작업을 수행 집적 회로 (IC)가 등장했다. 음성 부호 · 해독에 사용되는 IC를 음성 코덱, 이미지 압축 · 신장하는 IC를 이미지 코덱이라고 부르게되었다. 전자에는 예를 들어 ISDN 음성 통신에 사용 G.711 코덱, 후자는 G3, G4 팩시밀리 이미지 압축 및 압축을 사용 코덱 등이있다.

1990 년대 에 들어가면, PC 주변 하드웨어 영상 압축 · 신장을 실시할 수있는 코덱도 등장했다. 이후 컴퓨터 의 급속한 발전으로 화상이나 음성 등의 압축 · 신장을 소프트웨어적으로 할 수있게 소프트웨어만으로 처리하는 소프트웨어 코덱도 등장했다. 현재는 코덱이라고하면 디지털 신호의 데이터 압축 · 신장하는 장치 및 소프트웨어를 가리키는 경우가 많다.

그러나 데이터 압축 · 신장하는 코덱은 코덱 무리 중 한 카테고리에 해당하며, 좁은 의미의 코덱을 가리키고있다. 일반적으로 코덱라는 말은별로 사용​​되지 않지만,보다 넓은 의미에서는 다음과 같은 것도 코덱이다.

• 전자 메일 에서 사용되는 MIME 인코딩 디코딩 작업을 실시하는
• URL 문자열을 % xx 같은 문자열 인코딩 (URL 인코딩된)가 반대로 복호화 (URL 디코딩)하는 것
• 압축하지 않은 이미지 데이터 포맷 간의 상호 변환 (예 : BMP ⇔ TIFF ⇔ PICT )을 실시하는
• 데이터 암호화 및 암호화된 데이터를 해독하는 것

데이터 압축 코덱은 원래의 데이터에 완전 복원할 수 무손실 압축 (Lossless라고도 함)를 이용하는 것과, 압축 단계에서 원래의 데이터는 복구할 수없는 처리를 가하는 대신 높은 압축을 손실 압축 (Lossy라고도 함)를 이용하는 것이있다. 전자는 완벽하게 복원하는 것이 필수 문서 파일과 일부 화상 · 음성 파일에 사용된다. 후자는 가역 압축은 데이터 크기가 상대적으로 커지기 쉽다 화상, 음성, 동영상의 고능률 압축에 사용된다. → 데이터 압축 을 참조하십시오.

데이터 압축 · 신장하는 코덱 [ 편집 ]

예를 들어, Microsoft Windows 의 표준 형식은 음성 은 PCM , 이미지 는 BMP 와 같은 무압축 (비압축) 상태 파일 데이터가 존재한다. 시스템에서 자주 사용되는 짧은 음성이나 동영상, 작은 이미지 등을 처리하려면 압축되지 않은에서 다루는 것이 적합한 경우도 있지만, 큰 영상과 음성을 압축되지 않은 채 다루려하면 대용량 메모리 와 하드 디스크 등이 필요하거나 트래픽이 증가한다. 그것을 피하기 위해 파일을 압축하여 크기를 줄일 수 필요하다. 이때 필요한 것이 데이터 압축 · 신장을위한 코덱이다.

영상 압축 코덱 [ 편집 ]

• ERINA - 손실 압축
• GIF - 256 색까지 무손실 압축
• JPEG XR ( HD Photo ) - 지정에 따라 손실 압축, 무손실 압축의 선택이 가능
• JPEG - 손실 압축
  • JPEG 2000 - 지정에 따라 손실 압축, 무손실 압축 의 선택이 가능
• PNG - 최대 48bit (각 색 16bit) 컬러 (약 280 조 색상)의 무손실 압축, 8bit (256 단계)의 알파 채널 ( 투명도 )이 가능
• WebP - 손실 압축, 무손실 압축의 선택이 가능. Google이 개발했다.
• 두 값을 이미지의 무손실 압축 : 팩시밀리 등으로 사용된다.
  • MH (modified huffman) - 연속 길이 압축
  • MR (modified READ : relative element address designate) - 두 차원 부호화
  • MMR (Modified Modified READ) - ITU-T T.6
  • JBIG (Joint Bi-lebel Image experts Group) - Arithmetic Coding

    음성 압축 코덱 [ 편집 ]

음성 압축 코덱은 인간의 발성을 주요 대상으로 코딩 하는 음성 대역을위한 코덱과 그것에 한정하지 않고 음악 등도 대상으로 코덱이있다. 전자는 사람의 발성 특성을 이용하고 있기 때문에 후자보다 낮은 코딩 속도 음성 코딩이 가능하다.

음성 대역을위한 코덱의 대표적인 것으로는 ITU -G 시리즈 권고의 각종 코덱 (아래)이 휴대 전화 와 IP 전화 등으로 널리 이용되고 있으며, 음성을 4 ~ 13k bps 정도로 압축하고있다. 음악도 대상으로 코덱의 대표적인 것으로는 1990 년대전반에 등장한 미니 디스크 (MD)에 사용되고있는 ATRAC 과 1990 년대말 무렵부터 PC 오디오 넓게 침투하기 시작했다MP3 가있다. 예를 들어, 128kbps 스테레오 오디오 압축 오디오는 콤팩트 디스크 (CD)에 비해 1 / 10 이하로 압축되고있다. 이들은 원래 오디오는 완전히 복원할 수없는 손실 압축 방식을 이용하고있다.

한편, 최근 기록 미디어 의 용량이 비약적으로 증가함에 따라 데이터의 크기가 커지지만, 전혀 열화를 일으키지 않는 가역 압축을 이용한 코덱도 많아지고있다. 이곳은 대략 60 %에서 70 % 정도의 압축이 가능하다.

• 압축하지 않은 코덱
  • LPCM - 음악 CD , DVD-Video / Audio , Blu-ray Disc 등에 사용되는
• 손실 압축 손실 압축을 선택할 수있는 코덱
  • Windows Media Audio (WMA) - Windows Media Player 에 탑재되고있는 코덱
  • Dolby Digital Plus - 돌비 디지털 플러스 (DD +)
  • DTS-HD Master Audio - DTS가 개발한 DTS 확장 규격. BD에 채용되고있다.
  • WavPack - 무손실 모드, 손실 모드, 그리고 독특한 하이브리드 모드를 갖추고있다
  • MIO - 순수한 일본제 오디오 압축 형식
• 손실 압축 코덱
  • ADPCM - 드림 캐스트 등에 사용되는 코덱
  • AC-3 - 돌비 디지털
  • AMR
  • DRA - 중국 기업이 개발한 코덱
  • ATRAC - 미니 디스크 (MD) 와 SDDS 에서 사용되는 코덱
  • ATRAC2
  • ATRAC3 - MDLP 에서 사용되는 코덱
    • ATRAC3plus - Hi-MD 와 UMD 에서 사용되는 코덱
  • DivX Audio - WMA 해적판
  • DSP Group TrueSpeech
  • DTS
  • Ghost
  • Indeo Audio
  • ITU -G 시리즈 권고에 따라 국제 규격화된 코덱
    • G.723
    • G.726
    • G.729
  • MPEG 오디오 코덱
    • AAC - iPod 과 벨소리 , 유럽의 DVD 또한 BS 디지털 방송 과 지상파 디지털 방송 등에서 사용되는 코덱
      • HE-AAC - 원세그 , 컬러링 등에서 사용되는 코덱
    • MP1
    • MP2 - 많은 MPEG1가 사용하는 코덱
    • MP3 - 오디오 기기 등 폭넓게 사용되는 코덱
      • MP3PRO HE-AAC 와 같은 기술이다 SBR 을 사용한 MP3.
      • Mp3Surround 다중 채널 버전
      • MP3 # mp3HD 무손실 압축을 지원 버전. 기존의 MP3 스트림도 포함된다.
  • Musepack (MPC)
  • Vorbis - 특허 무료로 오픈 소스 개발 코덱. Google의 WebM 을 채용합니다.
  • QDesign Music
  • Real Audio
  • Speex - 오픈 소스 음성 대역을위한 코덱, Ogg 프로젝트에도 채용되고있다
  • TwinVQ
    • SoundVQ - YAMAHA에서 개발한 코덱
  • XVD Audio
  • UEMCLIP - ITU-T G.711 전화 음성 부호화 표준 방식을 확장하여 고음질의 광대역 음성 통신을 가능하게하는 encode 방식, NTT 연구소에서 개발된 기술
• 무손실 압축 코덱
  • AAL (ATRAC Advanced Lossless) - 손실 압축 부분을 내포하고 용도에 따라 꺼내 이용한다.
  • Apple Lossless (Apple Lossless Audio Codec, Apple 무손실) - iTunes 와 QuickTime 등에 탑재되는 코덱
  • MLP 또는 Packed PCM - Dolby Digital의 파생. DVD-Audio 와 Dolby Digital Plus에 채용되고있다.
  • MPEG-4 ALS (MPEG-4 Audio Lossless) - 국제 표준
  • DTS-HD - Blu-ray Disc · HD DVD 를위한 코덱
  • FLAC (Free Lossless Audio Codec) - 오픈 소스로 개발되고 Ogg 프로젝트 무손실 압축 용도로 사용되는 코덱
  • Monkey 's Audio - 프리웨어 하면서 높은 압축과 평이한 조작을 실현
  • TTA (The True Audio)
  • TAK (Tom 's lossless Audio Kompressor)
  • Dolby TrueHD

    동영상 압축 코덱 [ 편집 ]

동영상은 대용량 데이터를 처리하므로, 고효율 손실 압축이 필수가되고있다. 대표적인 것은 DVD 에 사용되는 MPEG-2가있다.

• AVS (Advanced Audio Video Coding Standard in Information Technology) - 중국 자체 코덱
• Canopus HQ Codec - 카노푸스 가 개발한 동영상 편집을위한 코덱
• Cinepak
• Dirac - 영국 방송 협회 (BBC)의 연구 개발 부문이 개발한 코덱
• DV CODEC - 디지털 비디오 카메라 에서 사용되는 코덱
• ITU-T 권고 H 시리즈를 통해 국제 규격화된 코덱
  • H.261 - ISDN TV 회의 시스템 코덱
  • H.263 - 전화 모뎀을 상정한 H.261보다 높은 압축 코덱
    • H.263 + - H.263을 개량한 코덱
  • H.264 (MPEG-4 AVC) - H.263보다 높은 압축 비율을 위해 개량한 코덱. MPEG-4 AVC와 같다.
    • x264 무료 H.264 인코딩 라이브러리.
• Indeo Video - 인텔 사가 개발한 코덱
• MEI - 동영상 ERI
• Microsoft Video 1
• Motion JPEG - 디지털 카메라 에서 사용되는 코덱
• Motion JPEG 2000
• MPEG 에서 표준화된 코덱
  • MPEG-1 - 비디오 CD 등에서 사용되는 코덱
  • MPEG-2 - DVD, 지상파 디지털 방송 에서 사용되는 코덱
  • MPEG-4 - 모바일 콘텐츠 등에 사용되는 코덱
    • MPEG-4 AVC ( H.264 ) - MPEG-4라고되어 있지만, 내용은 H.264 와 같으며, 호칭이 다를 뿐이다.
    • AVC-Intra - 파나소닉 이 개발한 비디오 코덱입니다. H.264을 준수합니다.
• MPEG-4에서 파생된 코덱
  • MS-MPEG4 (Microsoft MPEG-4 Video Codec) - MPEG과 무관하지만 MPEG-4와 호환 있음
    • DivX ;-) - MS-MPEG4 해적판
    • AngelPotion - MS-MPEG4 해적판
    • Windows Media Video MS-MPEG4를 기준으로 만들어진
  • RMP4 (REALmagic MPEG-4 Video Codec) - 미국 Sigma Designs社가 개발한 코덱. Xvid의 소스 코드 를 유용한 것으로 밝혀졌다.
• H.263보다 파생 코덱
  • DivX - DivX, Inc. 가 개발하고있는 코덱. MPEG-4 ASP에 따릅니다.
  • Xvid - 오픈 소스 H.263 (MPEG-4) 코덱. MPEG-4 ASP에 따릅니다.
  • 3ivx - DivX와 마찬가지 쉐어웨어이며, 시험 기간이있다. MPEG-4 ASP에 따릅니다.
• On2가 개발한 코덱 (TrueMotion)
  • On2VP3 - 오픈 소스화된 무료로 사용할 수있는 코덱
  • On2VP4 - 중국 고유의 광디스크 규격 EVD 등에 사용되는 코덱
  • On2VP5 - 상기에 따릅니다.
  • TrueMotion VP6 - Adobe Flash 에서 사용되는 코덱입니다.
  • TrueMotion VP7 - VP6보다 고화질 압축 코덱
  • VP8 - Google의 WebM 에서 사용
• RealVideo - RealNetworks에서 개발한 코덱. 낮은 속도에 강한
• Rududu - 잔물결 기술을 사용한 코덱
• Snow - ffdshow 에서 지원하는 코덱
• Sorenson Video - QuickTime 동영상을위한 코덱
• Theora - Xiph.org 가 On2VP3을 기반으로 개발중인 코덱
• WMV9 ( VC-1 ) - Blu-ray Disc · HD DVD에서 사용
• XVD
• ZyGoVideo
• 무손실 압축 코덱
  • Alparysoft Lossless Video Codec - Alparysoft 사가 제공하는 코덱
  • AMV Video Codec - 손실 손실 압축 코덱
  • AVImszh - 단색 애니메이션용으로
  • AVIzlib - 3DCG 동영상 제작 용도로 사용되는 코덱
  • CorePNG - 현재 문제가 많다
  • Fast Codec - 색상 왜곡을 일으키는 경우가
  • H.264 lossless -
  • Huffyuv - TV 프로그램의 고화질 기록 등에 사용되는 코덱입니다. 멀티 스레드 비대응.
    • huffyuvs - Huffyuv의 개량 판
    • huffyuv-mt - Huffyuv 개량 버전. 멀티 코어 대응.
  • Motion JPEG XR
  • Lagarith Lossless Video Codec
  • LocoCodec
  • Luna - 순수 국산 코덱.
  • MSU Lossless Video Codec
  • UtVid​​eo
  • YUY2 lossless codec - Aviutl 저자의 코덱.

각주 · 참조 [ 편집 ]

1. ^ 아스키 디지털 용어 사전 - CODEC (Glossary Help)
2. ^ 아스키 디지털 용어 사전 - 코덱 (PC EXPLORER)
3. ^ RBB TODAY - IT 사전 - CODEC
4. ^ @ IT - Insider 's Computer Dictionary - codec
5. ^ ITmedia + D Mobile - 코덱
6. ^ 아스키 디지털 용어 사전 - CODEC (Macintosh 용어 사전)
7. ^ 시스코 시스템즈, Cisco IOS 소프트웨어 릴리스 - 약어 목록 - Codec
8. ^ 마이크로 소프트 주식 회사, Windows Media 코덱을 사용하는 오디오 / 비디오 인코딩
9. ^ 리얼 네트웍스, Helix Producer 사용자 설명서 2 장

관련 항목 [ 편집 ]

• 컨테이너 형식 - 오디오 파일 포맷
• 데이터 압축
• 음성 부호화
• 모뎀
• K-Lite Codec Pack
• Combined Community Codec Pack
• 음향 신호 처리

NHN P2P서비스개발팀 윤병조

라이브 스트리밍을 위한 전통적인 프로토콜로인 RTSP는 도입 비용이 높고 방화벽 환경에서 서비스가 원활하게 이루어지지 않는 단점이 있습니다. 이러한 단점을 해결하는 방법으로 HTTP를 라이브 스트리밍을 위한 프로토콜로 사용하는 방법이 나오게 되었습니다. 이 글에서는 HTTP를 이용해 원활한 스트리밍 서비스를 제공하고 방화벽 문제 등을 해결하려는 노력 중에 하나인, Apple이 만든 HLS(HTTP Live Streaming)에 대해 살펴보겠습니다.

HTTP를 사용하는 라이브 스트리밍

동영상 라이브 스트리밍(Live Streaming)이란 텔레비전 생방송처럼 촬영한 정보를 실시간으로 사용자의 동영상 플레이어로 보내 재생하도록 하는 방식을 말한다. 온 디맨드 스트리밍(On-Demand Streaming)에서는 촬영과 편집을 거쳐 동영상 파일을 제작한 다음 사용자의 요구가 있을 때 동영상을 재생할 수 있도록 하지만, 라이브 스트리밍에서는 비디오와 오디오를 실시간으로 인코딩해 많은 사용자에게 동시에 보낼 수 있어야 한다.

라이브 스트리밍을 위한 전통적인 프로토콜로는 RTSP(Real-Time Streaming Protocol)/RTP(Real-time Transport Protocol), RTMP(Real-Time Messaging Protocol) 등이 있다. 이 프로토콜을 사용하는 스트리밍 서버는 영상 데이터의 전송뿐만 아니라, 동영상에 대한 정보 분석이나 전송 규격에 맞도록 동영상 파일을 읽어서 변형하는 기능도 갖춰야 한다. 기능이 많은 만큼 웹 서버에 비해 도입 비용이 상대적으로 높다.

고가의 도입 비용 이외에도 결정적인 단점이 있다. 현재 가장 많이 사용하는 RTSP/RTP의 경우, RTSP와 RTP가 서로 다른 네트워크 연결을 통해 데이터를 교환하기 때문에 방화벽이나 NAT(Network Address Translator)를 많이 쓰고 있는 환경에서는 서비스가 원활하지 않은 문제가 있다.

그래서 대안으로 나온 것이 HTTP를 전송 채널로 사용하는 것이다. HTTP는 양방(full-duplex) 방식이 아니기 때문에 라이브 스트리밍을 위해서는 단점을 극복할 별도의 방식이 필요하지만, 방화벽에서 HTTP 서버로의 요청만 통과시키면 되기 때문에 방화벽의 설정이 단순해진다. 요청과 응답이 1:1로 대응되므로 NAT 환경에서도 서버와 통신하는 것이 쉽다. 비단 방화벽 문제때문이 아니라, 웹 서비스를 위한 캐시 구조를 그대로 사용할 수 있고, 기존에 구축되어 있는 CDN(Content Delivery Network)도 특별히 변경하지 않고 그대로 이용할 수 있다는 것이 장점이다.

HTTP Live Streaming

HLS(HTTP Live Streaming)는 Apple에서 iOS 3.0과 QuickTime X를 위해 2009년에 내놓은 프로토콜이다. 이 프로토콜에서는 스트리밍 데이터를 MPEG-2 Transport Stream에 담아 시간 단위로 잘게 쪼개서 전송한다. 그리고 어떤 파일을 재생해야 하는 지에 대한 정보는 m3u8 파일을 이용하여 플레이어에 전달한다.

HLS는 iPhone과 iPad의 사용자 수가 늘어남으로써 자연스럽게 그 수요가 늘어나게 되었다. 또한, 규격 자체의 단순함과 IETF(Internet Engineering Task Force)를 통한 표준화 작업 등을 통해 다른 업체들도 쉽게 HLS를 지원할 수 있게 했다.

그 결과로, Adobe는 Flash Media Server 4.0에서, Microsoft는 IIS Media Server 4.0에서 HLS를 정식으로 지원하며, 모바일 운영체제에서 상대 진영이라 할 수 있는 Google의 Android에서도 3.0 버전인 Honeycomb부터 HLS를 지원하기 시작했다.

HLS와 기존 라이브 스트리밍 방식과의 비교

HLS와 기존 라이브 스트리밍 방식 모두 동영상을 끊김 없이 사용자의 동영상 플레이어에 전달한다는 점에서는 동일한 구조이다. 그림 1의 Server 부분과 그림 2의 Live H.264/AAC 부분의 역할은 같다. 카메라로 촬영한 영상을 코덱을 이용해 압축해서 서버로 보내는 것이다.

HLS와 기존 방식의 차이는 크게 두 가지이다. 하나는 '동영상 정보를 전달하는 방식'이고, 다른 하나는 HLS에서 만든 스트림 세그멘트(stream segment)이다.

그림 1 Apple 의 HLS 구성(원본 출처:http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html)

그림 2 기존 스트리밍 서버를 이용한 스트리밍 서비스 구성

HLS에서 서버는 HTTP로 요청을 받아서 플레이어에 응답을 주는 역할만 한다. 요청받은 파일을 읽어서 어떠한 변형도 하지 않고, 읽은 그대로 응답에 포함해 보내기만 한다. 즉 저장되어 있는 파일을 읽어서 HTTP 응답에 데이터를 실어서 보낼 수 있는 웹 서버면 어떤 웹 서버든 사용할 수 있다.

하지만 기존 스트리밍 서버는 플레이어가 스트리밍 서버에 연결한 스트리밍 규격에 맞게 다시 데이터를 변형해 보내는 작업을 해야 한다. 경우에 따라서는 특정 스트리밍 방식을 위해 해당 회사의 제품을 구매해야 할 때도 있다. 웹 서버에 비하여 처리 과정이 더 많기 때문에 서버 한 대당 처리할 수 있는 클라이언트의 수도 웹 서버보다 적다.

스트림 세그먼터(Stream Segmenter)는 일정한 시간 간격마다 입력받은 미디어 데이터를 분할해 파일을 만들고, 그 분할한 파일에 접근할 수 있는 메타데이터(m3u8)를 생성하는 일을 한다. HTTP는 양방향 방식이 아니기 때문에, 클라이언트에서 반드시 서버에 요청을 해야 그에 맞는 응답을 받을 수 있다. 즉, 잘게 쪼갠 동영상과 다음에 볼 동영상 정보를 함께 클라이언트에 전달하고 동영상이 끊김 없이 때에 맞춰 다음 동영상 정보를 요청한다.

스트림 세그먼터에서는 동영상 데이터를 변형하지 않으므로 기능이 복잡하지 않다. 기존의 스트리밍 서비스 구조의 "원본 > 인코더 > 스트리밍 서버 > 플레이어"라는 데이터 흐름에서 "원본 > 인코더 > 스트림 세그먼터 > 웹 서버 > 플레이어"라는 흐름으로 단계가 더 많아졌다. 하지만 대규모 서비스를 위해 부하 분산을 고려할 때 기존 라이브 스트리밍 방식은 매우 복잡한 구조를 사용했지만, HLS는 일반 웹 서비스의 구조와 같은 방식을 사용하기 때문에 전체적으로 볼 때 단순해졌다고 할 수 있다.

동영상 압축

널리 쓰고 있는 색 표현법에 RGB를 이용하는 표현법이 있다. 빛의 삼원색인 빨강, 초록, 파랑의 밝기 값을 각각 0~255의 숫자로 표현하는 방법이다. 0~255의 숫자를 컴퓨터에서 이용하는 이진 데이터로 만들면 8비트의 저장 공간이 필요하다. 따라서 RGB 방식으로 색을 표현할 때는 3바이트가 필요하다.

하지만 3바이트로는 픽셀이라고 부르는 1개 화소의 색만 표현할 수 있다. 전체 화면에 대한 정보를 보내려면 화면 크기만큼 화소의 색깔 정보가 있어야 한다. 해상도가 VGA(640x480)인 영상의 경우에는 30만 7천2백 개의 화소가 있으므로 데이터는 총 921,600바이트가 된다.

움직이는 화면에서 초당 약 30개의 화면을 보낸다고 하면 초당 27MB라는 어마어마한 데이터를 보내야 한다. 해상도가 더 높은 영상은 당연히 데이터의 양이 더 많아지므로 동영상 압축이 필요하다.

m3u8 포맷

그림 3 m3u8 파일과 ts 파일

m3u8 포맷을 이해하기 전에 m3u 포맷을 먼저 알아야 한다.

m3u 포맷은 연속으로 재생할 MP3 파일 목록을 가진 플레이 리스트 파일이다. 각 줄마다 재생할 파일의 경로를 적는 매우 단순한 구조이다. 하지만 m3u에는 Latin-1 문자 집합만 적을 수 있다. 그리고 단순히 파일 목록을 나열할 뿐이므로 재생할 파일에 대한 정보를 재생하기 전에 미리 알 수 없다.

그래서 나온 확장 규격이 m3u8 포맷이다. m3u8 포맷에서는 UTF-8 문자 집합을 사용할 수 있고, 여러 가지 지시어로 재생할 파일에 대한 추가적인 정보를 제공할 수도 있다.

HTTP Live Streaming에서 m3u8 포맷을 사용하려면 몇 가지 규칙을 따라야 한다.

우선 m3u8 파일의 가장 첫 줄은 #EXTM3U로 시작해야 한다. #EXTM3U라는 지시어로 이 파일은 m3u8 포맷을 사용한다는 것을 플레이어에게 알려 준다.

둘째로 모든 m3u8 포맷의 지시어는 줄 맨 앞을 #EXT로 시작해야 한다. #EXT로 시작하지 않으면 # 이후의 문자열을 주석으로 간주한다.

m3u8 포맷의 주요 지시어에는 다음과 같은 것이 있다.

표 1 m3u8 포맷의 지시어

MPEG-2 TS (Transport Stream)

MPEG-2 TS는 MPEG-2 Part 1, Systems (ISO/IEC 13818-1 또는 ITU-T H.222.0)로 오디오나 비디오, 방송의 채널 정보 등을 전송하거나 저장하기 위해 정의한 규격이다. MPEG-2의 Elementary Stream(MPEG에서 오디오나 비디오 각각의 데이터 집합)을 패킷(Packet)으로 만들 때 에러 정정 및 동기화 정보 등을 같이 포함할 수 있도록 하는 컨테이너(container) 포맷이다. 실제로 TS로 데이터를 전송하는 경우 하나의 연결 내에 동시에 여러 개의 채널 정보를 담아서 전송할 수 있다.

TS에서 주로 사용하는 개념으로 프로그램(Program)이 있다. 프로그램은 간단하게 말하면 Elementary Stream의 집합이다. 조금 쉽게 생각하면, 텔레비전에서 오디오와 비디오가 포함되어 있는 각각의 채널을 MPEG-2 TS에서 말하는 프로그램이라 볼 수 있다. 방송에서 나오는 드라마나 뉴스 등의 프로그램을 말하는 것이 아니고, KBS, MBC, SBS와 같은 채널 자체를 MPEG-2 TS에서는 프로그램이라 한다.

다음 그림에서 보는 바와 같이 영화 채널, 뉴스 채널, 스포츠 채널 등의 정보를 하나의 전송 연결에 포함할 수 있고(multiplexing), 플레이어는 각 채널이 가진 고유한 ID를 이용하여 원하는 채널을 선택해 재생할 수 있다.

그림 4 MPEG-2 TS(원본 출처: http://en.wikipedia.org/wiki/MPEG_transport_stream)

다음 그림은 TS 포맷을 상세히 표시한 그림이다. 밑에 적혀 있는 숫자는 비트 단위이다.

그림 5 Transport Stream 구문(출처: ITU-T Recommendation H.222.0(05/2006))

TS 패킷의 크기는 188바이트로 고정되어 있고, 이보다 큰 데이터는 모두 나누어진다. 동기화를 위한 정보나 시간 정보, 에러 정정, 스크램블링(scrambling: 허가되지 않은 사용자가 해당 채널을 볼 수 없도록 하는 작업) 정보 등을 헤더에 명시한다.

페이로드에 포함되는 중요 데이터는 다음과 같다..

표 2 TS의 페이로드에 포함되는 데이터

다음 그림은 PAT, PMT, PES의 대략적인 관계를 나타낸 것이다. PAT를 통해 어떤 프로그램이 있는지 목록을 얻고, PMT로 선택한 프로그램의 비디오/오디오 데이터가 어떤 ID를 갖고 있는지 알아내어 해당 ID를 가진 패킷만 선택하여 재생한다.

그림 6 PAT, PMT, PES 의 상관 관계

HLS를 위한 ts 파일 생성

HLS에서 사용하기 위한 ts 파일은 MPEG-2 TS를 순서대로 저장한 파일이다. 다만 정한 시간에 따라 분할하여 저장한다.

HLS로 화면을 자연스럽게 재생하려면 각 ts 파일이 I-frame(Intra frame: 화면 전체가 압축되어 들어 있는 frame)을 포함해야 한다. 되도록이면 첫 비디오 데이터가 I-frame인 것이 좋다. 첫 화면이 I-frame 이 아니면 플레이어에서 화면이 나오지 않거나 일시적으로 뭉개진 화면이 나올 수 있다. I-frame은 데이터가의 크기가 크기 때문에 ts 파일이 포함하는 데이터의 재생 시간 간격을 적절하게 선택해야 한다. Apple이 HLS를 위해 권고하는 미디어의 규격은 다음과 같다.

표 3 HLS를 위한 Apple의 미디어 규격 권고 사항

Apple에서 권고하는 기기별/네트워크별 해상도와 비트레이트는 다음과 같다. 추천 값에 대한 더 자세한 내용은 "HTTP Live Streaming Overview" 문서를 참조한다.

그림 7 Apple의 기기별/네트워크별 해상도, 비트레이트 추천 값

Apple이 추천하는 각 ts 파일의 길이는 플레이어에서 10초간 재생할 수 있는 분량이다.

재생할 수 있는 분량이 짧아지면 네트워크로부터 받아와야 하는 데이터의 양이 증가한다. I-frame의 빈도가 늘어나게 되어 실질적인 데이터의 양도 늘어나고 전송 프로토콜의 헤더와 같은 추가적인 전송 데이터 및 갱신되는 index.m3u8 파일을 받기 위한 데이터의 양도 같이 늘어난다.

반대로 재생할 수 있는 분량이 길어지면 원래 방송하고 있는 데이터와 플레이어에서 재생하고 있는 데이터 사이의 시간 간격이 커진다. 이를 테면, 옆집에서는 TV로 축구 중계를 보고 있고 나는 HLS를 이용하여 축구 중계를 보고 있다면, 옆집에서 골을 넣는 장면을 보는 시간과 내가 골을 넣은 장면을 보는 시간의 차이는 재생할 수 있는 분량만큼이므로, 옆집에서 환호성을 지르고 나서 한참 후에야 내가 환호성을 지르게 될 수 있다.

물론 위에 나열되어 있는 값들은 Apple의 권장 값이므로, 각 서비스에 따라 적절한 값을 선택할 수 있다.

콘텐츠 보호

HLS는 콘텐츠 보호를 위해 각각의 ts 파일을 개별적으로 암호화하는 방식을 사용한다. 암호화가 적용되면 암호화에 사용한 키(key)를 #EXT-X-KEY 지시어로 플레이어에 제공한다. 플레이어는 이 키 파일에 기록된 키를 이용하여 ts 파일을 해독하여 재생한다.

HLS이 기본적으로 사용하는 암호화 방식은 AES-128이다. 따라서 키 파일에는 16 octet의 binary key 정보가 들어 있어야 한다.

모든 ts 파일은 하나의 키를 이용하여 암호화할 수도 있고, 각 구간별로 다른 키를 이용하여 암호화할 수도 있다. 이론적으로는 각 ts 파일마다 다른 키를 사용하여 암호화할 수도 있지만, 매번 키 파일을 플레이어가 받아야 되므로 추가적인 전송 데이터가 발생한다.

그림 8 HLS 에서의 콘텐츠 보호 

Adaptive Bitrate Streaming

HLS의 특징 중에 하나는 사용자의 네트워크 속도에 따라 적합한 콘텐츠를 선택하여 재생할 수 있는 Adaptive Bitrate Streaming을 지원하는 것이다.

Adaptive Bitrate Streaming에 대해 간단히 살펴 보겠다.

Adaptive Bitrate Streaming을 적용하면 사용자의 네트워크 환경이 변화해도 끊기지 않고 동영상을 볼 수 있다.

예를 들어 Wi-Fi 환경에서 스트리밍 서비스를 사용하던 중에 휴대전화망 환경으로 이동하면 사용 가능한 네트워크의 대역폭이 감소된다(네트워크 주소 변화 등으로 인한 연결 중단 등의 문제는 고려하지 않았음). 이때 Adaptive Bitrate Streaming이 적용되지 않은 스트리밍 서비스에서 Wi-Fi 환경에 적합한 비트레이트(bitrate)로 라이브 서비스를 제공하고 있었다면, 플레이어가 데이터를 제대로 수신하지 못하여 지속적으로 버퍼링이 발생하거나 부족한 데이터로 인해 화면이 제대로 표시되지 않는 문제가 발생한다.

하지만 Wi-Fi 환경과 휴대전화망 환경에 맞는 라이브 서비스를 동시에 제공하는 Adaptive Bitrate Streaming이 적용되어 있다면, 휴대전화망 환경의 라이브 서비스로 자동으로 옮겨감으로써 화면의 품질이나 해상도 등은 나빠지지만 끊기지 않고 계속 서비스를 이용할 수 있는 것이다.

그림 9 Adaptive Bitrate Streaming 의 동작

HLS에서도 Adaptive Bitrate Streaming을 위해 동시에 여러 비트레이트의 ts 파일에 대한 정보를 제공하는 것이 가능하다.

HLS에서 Adaptive Bitrate Streaming을 지원하기 위한 m3u8 파일과 ts 파일의 구조는 다음과 같다.  

그림 10 ABS를 위한 m3u8 파일과 ts의 연결 구조

전체를 대표하는 m3u8 파일이 있고, 대표 파일 내에서 다시 각각의 비트레이트별 플레이 리스트 파일을 가리키게 한다. 각 비트레이트별 플레이리스트 파일은 다시 각자의 비트레이트에 해당하는 ts 파일들을 가리킨다.

위의 예와 같은 variant.m3u8 파일의 내용은 다음과 같다.

Adaptive Bitrate Streaming 을 지원하는 스트리밍 서비스를 구성할 때는 다음과 같은 사항에 주의해야 한다.

각 ts 파일이 담고 있는 데이터는 동일한 구간의 데이터를 포함해야 한다. 네트워크 환경이 변화하여 다른 비트레이트를 가진 데이터를 받을 때 바뀐 비트레이트의 데이터 구간이 원래의 데이터 구간과 달라지면 순간적으로 화면의 끊김이나 앞/뒤로 건너뛰는 현상이 발생할 수 있다.

각 비트레이트의 플레이리스트에 대한 정보를 포함하는 대표 m3u8 파일에서 가장 처음에 나오는 m3u8 파일의 비트레이트는 서비스에서 가장 최적의 비트레이트값을 갖도록 해야 한다. 예를 들어, 위의 그림의 파일과 같이 대표 m3u8 파일을 만들 경우 플레이어에서 처음 시작할 때 128 kbps의 데이터를 요청하게 된다. 플레이어의 네트워크 속도가 만약 768 kbps 이상이라면 높은 화질의 영상을 재생할 수 있음에도 사용자는 낮은 화질의 영상을 한동안 시청해야 한다.

각 ts 파일이 포함하는 영상의 화면 비율은 반드시 동일해야 한다. 고화질 영상은 16:9, 저화질 영상은 4:3과 같이 다른 화면 비율을 사용하게 된다면 비트레이트의 변화에 따라 부드러운 화면 변화가 불가능하다. 단 같은 비율이라면 해상도를 변화시키는 것은 가능하다. 고화질은 800x600, 저화질은 400x300의 해상도를 사용하는 것은 가능하다.

HLS의 동작 방식

서버에서 HLS 서비스가 시작되면 m3u8 파일은 분할된 파일이 생길 때마다 계속 주기적으로 바뀐다.

그림 11 시간 흐름에 따른 m3u8 파일의 변화

위의 그림을 보면 처음에는 2, 3, 4의 일련번호를 갖는 파일이 있다. #EXT-X-TARGETDURATION이 2로 명시되어 있으므로 2초 후에는 5번 파일이 생긴다. m3u8 파일의 뒤에 5번 파일을 가리키는 줄을 추가할 수도 있다. 하지만 줄을 추가하여 m3u8 파일에 명시된 콘텐츠가 늘어나면 5번 파일이 생기고 난 뒤에 스트리밍 요청을 하는 플레이어는 콘텐츠 재생을 위해 2, 3, 4, 5의 4개 파일을 요청하게 된다. 이는 초기 시작을 위한 대기 시간을 늘리고, 실제 동영상과 플레이어에서 재생하는 동영상의 시간 차이를 늘리게 된다. 그래서 일정한 개수의 파일만을 m3u8 파일에 명시하는 것을 권장한다. 이렇게 함으로써 각 사용자마다 동일한 적정 수준의 대기 시간을 제공할 수 있다.

플레이어는 동영상 재생을 위해 다음과 같이 동작한다.

플레이어는 파일을 연속적으로 재생하여, 사용자가 마치 1개의 파일을 계속 재생하는 것과 같이 끊김 없는 화면을 제공하는 것이 중요하다. 물론, 서버에서 각 분할된 파일에 포함된 데이터가 시간적으로 겹치거나 간격이 지나치게 벌어지지 않도록 파일을 만드는 것은 기본이다.

HLS를 지원하는 플레이어

현재 HLS를 지원하는 플레이어는 다음과 같다. 우선 Apple의 모바일 제품은 모두 지원하고, Android 계열의 제품은 3.0 이후 버전에서 기본으로 지원한다.

표 4

마치며

HLS는 기존의 스트리밍 프로토콜이 지닌 단점을 극복하고 스트리밍 서비스를 위한 인프라를 단순화시키려는 의도에서 나온 규격이라고 할 수 있다. 고화질 서비스를 지원하고, 네트워크 상황에 따라 원하는 비트레이트의 콘텐츠를 선택할 수 있는 기능을 제공한다. Android 3.0 기기부터는 공식적으로 HLS를 지원하여 iOS 기기 및 Android 기기에 모두 동일한 방식의 라이브 스트리밍 서비스를 할수 있게 되었다.

HLS 이외에도 HTTP 를 이용한 Adaptive Bitrate Streaming을 지원하는 스트리밍 규격이 있다. Adobe의 HTTP Dynamic Streaming과 Microsoft의 Smooth Streaming도 HTTP를 이용한 스트리밍 규격이다. 이 외에도 MPEG과 3GPP에서 동시에 규격을 정의하고 있는 Dynamic Adaptive Streaming over HTTP (DASH)도 있다.

유선 및 무선 네트워크의 속도가 빨라짐에 따라 스트리밍 서비스의 품질 역시 점점 높아지고 있으며, 이동 시에 이용이 가능한 스트리밍 서비스의 중요성도 높아지고 있다. HTTP를 이용하지 않고 서버와 플레이어 사이의 연결에 기반하는 기존의 스트리밍 규격은 이런 이동성에 약하지만, HTTP의 경우 연결 지향적(connect-oriented) 스트리밍 방식이 아니라 필요한 데이터를 그때그때 받아오는 방식이므로 이동에도 비교적 강한 특징을 가진다.

모바일 기기가 확대될수록 HTTP를 이용한 스트리밍 방식이 기존 방식의 스트리밍 서비스를 대체할 날이 멀지 않았으리라 짐작해 본다.

출처 - http://helloworld.naver.com/helloworld/7122