Yonghwan's Blog

싱숭생숭 어수선하다. 에라~ 일단 공부나 하자.

누군가로부터, 이런 질문을 받은 적이 있다. "우리 솔루션이 MPEG를 지원하나요?"

잠깐 딴소리. 이 질문을 받은 것이... 한달도 되지 않았는데 벌써 기억이 가물거린다. 그래서... 그때 그때 써놔야 한다. 누군가는 "그딴 거 천천히 하고 일이나 해" 라고 말한다 해도, 내가 이 시스템 삼총사(계관이, 개관이, 사랑이)를 다른 모든 일보다 먼저 끝내고 싶었던 이유가 거기에 있다. 열심히 일하면 뭐하는가? 지나면 그만인 것을... (그 때) 열심히 설명해줬으나 무슨 소용인가? 누군가 다시 물어본다면 또 다시 열변을 토해야 하는데... 이젠, "사랑이에게 물어보세요"라고 말할 수 있다. 잡설 그만!

MPEG란 무엇인가? 일단 약자가 나왔으니 풀어서 써야지. 예전에 학동들이랑 공부할 때 즐겨 쓰던 말, "약자는 세로로 써보자."

M oving
P icture
E xpert
G roup

뭔소리여? "활동사진 한가닥 동아리"랄까? 동영상 분야에서 뭐 꽤나 뀌는 사람들의 모임. 근본적으로 MPEG라는 말은 그룹의 이름이다. 그러나, 흔히 MPEG라는 표현을 했을 때 그들을 지칭하는 것은 아니겠지. 보통 MPEG라는 표현의 일반적인 의미는 그들이 지정한 "동영상 표준"을 가리킨다. 흔히 얘기하는 MP3 등도 그런 표준의 일부.

그런데, MPEG라는 말은 "동영상 표준"이기는 한데, 두 가지 다른 의미로 사용되고 있다. 하나는, "코덱"으로써의 MPEG이고 다른 하나는 "컨테이너"로써의 MPEG이다. 오늘 하고자 하는 얘기는 바로 이 "코덱"과 "컨테이너"이다.

1. 코덱이란 무엇인가?

코덱이란, 말하자면 문자이다. 알파벳, 한글 등과 같다고 생각하면 된다. 예를 들어, "개소리"를 떠올려보자. 그 느낌이 바로 원본 영상이라면, "멍멍멍", "Bow Wow" 는 인코딩된 파일인 샘이다. 각각 한글과 영문이라는 코덱을 이용하여 인코딩 한 것이다. 물론, 엄밀히 말하자면 위의 예는 '디지타이징' 정도가 적당한 표현이겠다. 위의 예를 다시한번, "3멍", "Ba Wow" 과 같이 표현해보자. 앞의 "3멍"의 경우, 원본에 비하여 그 길이가 줄어있지만 "숫자에 대하여 뒤이은 음절을 그 숫자만큼 반목한다"라는 약속이 있다면, 해석을 거쳐 문자화(수치화; 디지타이징)된 원본을 그대로 복원해낼 수 있다. (무손실 코덱) 또한, 뒤의 "Ba Wow"의 경우, 문자수는 크게 줄지 않았지만 쉽사리 원본과 비슷한 소리를 떠올릴 수 있다. (손실 코덱, 그러나 빠른 디코딩)

잠깐 용어를 정리해보면,

• 코덱 : 영상/음성을 디지털 신호로 표시하기 위한 약속된 기호, 또는 그 표기 방식
  
• 인코딩 : 비압축의 영상/음성을 규약에 의하여 해석 가능한 형태로 재기록하는 행위
  
• 디코딩 : 인코딩되어있는 영상/음성을 원 모습으로 되돌리기 위하여 해석하는 행위
  

MPEG라는 용어는 이런 관점에서, 영상을 위한 MPEG1 Video, MPEG2 Video, MPEG4 Video, MPEG4 Part10 AVC (H.264)등의 영상 코덱을, 또는 음성을 위한 MPEG1 Audio, MPEG2 Audio, MPEG4 AAC 등의 음성 코덱을 싸잡아 부르는 것이거나 그 중 하나를 대충 부르는 것으로 받아들일 수 있다.

2. 컨테이너란 무엇인가?

그럼 컨테이너란 무엇인가? 코덱이 글자라면 컨테이너는 종이이다. 또는 대나무 조각일 수도 있고, 심지어는 손바닥일 수도 있다. 무슨 소리냐면 종이가 글자를 가지런히 적어놓는 "글자의 그릇"이 되듯이, 인코딩된 결과물, 0과 1의 연속된 배열으로 이루어진 그것을 어딘가에 적당한 형태로 담아둬야 하는데, 그 그릇의 역할을 하는 것이 바로 미디어의 컨테이너이다.

MPEG라는 용어가 사용될 때, 위의 "코덱으로 해석하기" 보다 일반적인 것은 바로 "컨테이너로 해석하기"일것 같다. (이 경우, '시스템'이라는 표현이 좀 더 MPEG 스럽긴 하다. MPEG에는 PS라는 파일 저장용 그릇과 TS라는 전송용 그릇이 있다.)

3. RTP란?

말 나온 김에, 그럼 RTP란 소리도 들리던데 그건? 뭐, 딱 이거다라고 하면 거짓말이겠지만, 지금의 문맥상에서 보면 RTP는 "4랑해"라고 적힌 종이를 담은 '봉투'라고나 할까? 연애편지 전문 봉투는 아니지만 어쨌든 연애편지를 담은 이 표준의 봉투는 우편배달부의 손을 거쳐 짝순이의 손에 전달된다. 영상물을 위한 전문 봉투는 아니지만 어쨌든 인코딩된 동영상을 담은 이 표준의 RTP라는 봉투는 네트워크를 거쳐 재생기에게 전달된다.

그 연애편지... 그냥 종이로 주면 안될까? 안돼~ 등기로 부치고 싶으니까! RTP는 그렇다고 등기우편은 아니지만, 일련번호 등의 방법을 이용하여 중간에 빠진 편지가 없는지 검사하는 기능을 가지고 있다.

예전에, 일련번호가 붙어있는 위문/연애편지를 받던 고참이 생각나는군. 참 이상한건, 그 고참은 휴가나갈 때 휴가증을 두 개 챙긴다는 것. 날짜 긴거 하나, 짧은거 하나. 긴건 진짜 휴가증, 짧은건 애인 보고용. 결혼은 했으려나...

그니까 어쩌라고~ 우리 시스템은 MPEG를 지원한다고?

1) 우리 시스템은 '전송' 영역에서 동작하는 것으로, 코덱과는 무관하게 동작할 수 있다. 뭐, 원한다면 MPEG로 압축된 영상도 실어보낼 수 있으니 지원한다고 해야할까?

2) 우리 시스템은 고유의 전송 방식과 파일 형식을 갖는다. MPEG로 말하자면 PS와 TS에 해당하는 무언가가 따로 있는 샘. 그렇다면... 컨테이너로써의 MPEG는 지원하지 않는다고 말할 수 있을까?

3) 고객이 이미 MPEG 영상을 다수 가지고 있고, 이를 서비스하기 위하여 우리를 바라보고 있는 것이라면? 까짓거 MPEG를 우리 솔루션에 맞도록 변환해주면 되는거 아니냐고요~ 이런 과정/행위를 트랜스코딩이라고 하지.

결론적으로, 우리 시스템은 MPEG 기반 시스템은 아니다. 그러나, MPEG 원본에 대한 서비스를 처리할 수는 있다. 라고 주장하면 되나? 그렇게 주장하지 마시고... "이건 됩니까?" 라는 질문 말고 "이걸 원합니다."라는 요구를 들어보고, 요구에 합당한 답을 만들어 드리면 됩니다. 단답식의 답은... 오답일 수 있습니다.

디디로써의 첫 리딩인가? 사실, 회사 아래에 블로그 시스템을 두는 것을 고려하게 된 사연인 즉, 이렇게 읽은 글들을 어떻게 관리해야 하나... 하는 질문에서 출발하여, 프로젝트에 메이지 않은 (그래서 PMS에 포함시키기는 좀 애매한), 그리고 개인적이지만서도 함께하면 좋은 것들을 쉽게 담을 수 있는 그릇이 뭘까... 하고 접근해보니까 답이 블로그로 귀결되어 버렸다. 개인적이고, 함께 엮여있고, 쉽게 작성하고 나눌 수 있다. 어쨌든, 시작해본다.

오늘의 리딩 - 프레임기반 우선순위화를 이용한 무선랜 환경에서의 적응형 HD MPEG-2 스트림 전송기술

제목에 그 내용이 다 담겨있다. 다시 설명하자면, "품질 보장이 어려운 무선랜 환경에서 어떻게 하면 보다 매끄럽게 고화질의 HD MPEG-2 스트림을 전송해볼까..." 하는 내용으로, "네트워크 상황을 지속적으로 파악하여 비교적 우선순위가 낮은 프레임을 미리 버림으로써 전송률을 조정하고 화면 깨짐을 방지해보자."를 그 해답으로 삼았다는 글이다.

본문은 여기서 다운받아 보시라.

먼저, 이 논문에서 WLAN, IEEE 802.11a 등은 제목 이상의 의미를 가지지 않는다. 즉, 이 논문은 무선랜 환경을 위하여 특화된 기술을 다루고 있는 것이 아니라, 단지 네트워크 수준에서 QoS가 보장되지 않는 모든 환경, 즉 응용 수순에서 어떻게 하면 QoS를 보장해볼까 하는 것을 주제로 삼고 있다. (조금 실망 :-)

관련하여 같은 연구자의 연관된 논문 몇 편을 더 읽어봤는데, 정리해보면 다음과 같이 요약할 수 있다.

QoS 개선을 위하여 일반적으로 어떤 노력들이 있어왔는가?

• 비디오 압축률 개선
• 응용 계층에서 QoS 제어
• 혼합제어
• 손실률 제어
• 전송 프로토콜 개선
• 미디어 분배 서비스
• 스트리밍 서버
• 미디어 동기화

그래서, 이 연구에서는 어떤 방식을 제안하는가?

1. TS 패킷의 실시간 파싱
2. 프레임 기반 패킷 우선순위화 기법

어떻게 동작하는가?

1. TS 패킷을 실시간으로 파싱하여 비디오 데이터에 대하여 프레임 유형에 따른 우선순위를 준다.
2. 클라이언트는 주기적으로 RTP 패킷의 손실율과 전송편차를 측정하여 서버에 보고한다.
3. 보고된 자료를 바탕으로 전송상태에 대한 등급을 정하고, 이를 기반으로 프레임을 적절히 버린다.

일단, 읽으면서 재미있는 기술이라는 생각이 든다. 비교 예시로, 깨진 매크로블록이 가득한 정지영상과 깨끗한 정지영상을 그려놓았는데, 사실 동영상에 대한 기술이므로 실제 재생되는 것을 봐야 효과에 대하여 인정이 가능할 것 같다. 화면은 깨지지 않지만 뜩뜩 끊어져 움직인다면...

단순히 화면이 깨지는 것은, 클라이언트 측에서 TS를 파싱하여 손실된 데이터가 있으면 전체 프레임을 버리는 방식으로 구현할 수도 있다. 다만, 이 경우에는 어려운 네트워크가 개선되지 않으므로 오류가 지속적으로 발생할 것이다. 그러나, 서버가 보내는 양을 적절히 줄여서 정말 꼭 필요한 데이터 위주로 전송해준다면 네트워크 상황을 안정화시킬 수, 사실은 안정화는 안되고 최소한의 데이터라도 안정적으로 받을 수 있는 가능성을 높일 수 있겠다.

문제점 하나. 이 구현은 C/S 구조로 동작한다. 즉, 단일 클라이언트측의 리포트에 기반한, 유니케스트 환경에서만 가능한 기법이라는 점.

우리 프로토콜에는 어떻게 적용할 수 있을까? 우리 프로코톨은 이미 A/V 가 분리되어있다. 더군다나 프레임 유형 정보도 이미 패키지 안에 들어있다. 그리고 유니케스트가 오히려 기본. 그렇다면 클라이언트가 적절히 보고만 해준다면 V 스트림의 조절이 어렵지 않게 가능하겠는데? 게다가 이미 컨트롤 메시지를 주기적으로 보내고 있지 않은가?

언제 한번... 효과 시험용으로 대충 구현해보는 것도 나쁘지 않겠네.

관련 사이트 :

http://netmedia.gist.ac.kr/
http://hdtv.nm.gist.ac.kr/

사실, 잘 모르겠다. "신경통"은 어르신들의 영역의 것인 것으로 인식해왔고, 어떤 병인지, 어떤 증상을 가지고 있는지... 나는 잘 모른다. 그냥, 이 글을 쓰려다보니, 그 단어가 갑자기 떠올랐다.

신경통에 걸린게 아닌가 모르겠다. 신경이 마비되어... 정보 전달이 잘 되지 않고 있다. 밥을 못먹어 배에서 꼬로록 소리가 나고 위장이 쭈그러지는 느낌이 들만도 한데, 어찌된 영문인지 배고픔을 느끼지 못한다. 이놈의 타이핑. 손가락이 아파 죽겠는데... 손가락이 물러 터져도 그것을 발은 모른다. 발은, 자신은 열심히 뛰었지만 몸이 늦장을 부리는 것이라고 생각한다. 머리는... 자기는 정말 빨리 돌아가는데 손 발이 느려서... 그래서 머리가 아픈줄로만 안다.


어떤 형식으로든, 소통이 필요하다. 소통이 있는 세상. 그게 See뭣혀 World 가 아닐지...