보통 인터넷에서 동영상을 구하는 분들에게는 매우 생소한 형식이겠지만, ts 형식에 대해서 이야기를 해보고자 합니다. 그런데 TS 형식의 모든 부분에 대해서 이야기를 하면 책이 한권이 나올 수 있는 분량이기 때문에, 이번 글에서는 188byte에 대해서만 이야기를 하도록 하겠습니다.


기본적으로 MPEG - TS는 방송을 목적으로 만들어진 프로토콜입니다. 따라서 저장된 데이터를 읽어오는 것처럼 한번에 필요한 양의 데이터를 읽어올 수 있는 환경이 아닙니다. 네트워크 스트리밍이 아니라 방송용이기 때문에 늘 해당 주파수 대역을 점유한다는 가정을 두고 만들어, 고정적인 bitrate를 보장받아야 한다는 점도 존재합니다. 겸사겸사 MPEG - TS Packet의 기본적인 구조를 보고가는 것이 좋을 것 같아서 첨부를 합니다. 세부적인 내용은 추후에 설명하기로 하고 기본 패킷 구조가 어떻게 생겼는지만 보고 가도록 하겠습니다.


 이름

 bit

 설명

 Sync byte

 8

 1바이트로 값은 0x47

 TEI(Transport Error Indicator)

 1

 Demodulator가 Demuxer에게 해당 패킷은 복원할 수 없는 에러를 지니고 있다는 표시를 해주기 위한 비트

 Payload Unit Start Indicator

 1

 해당 TS 패킷이 PES 혹은 PSI 데이터의 시작점인 경우, 그것을 알려주기 위한 비트

 Transport Priority

 1

 동일한 PID에 비해서 더 높은 우선순위를 가지고 있다는 것을 표기하기 위한 비트

 PID

 13

 Packet Identifier

 Scrambling control

 2

 00b: 스크램블 되지 않았음

 이하 DVB-CSA에서만 사용

 01b: 나중에 사용하기 위해 예약되어있음

 10b: 짝수 키로 스크램블 되어있음

 11b: 홀수 키로 스크램블 되어있음

 Adaption field exist

 1

 추가 필드가 존재함

 Contains payload

 1

 페이로드 데이터가 존재함

 Continuity counter

 4

 시퀀스 번호, 페이로드 데이터가 존재할 경우에만 증가한다

 Adaption field

 variable

 Adaption field exist 비트 플래그가 '1'인 경우에만 존재

 Payload data

 variable

 Contains payload 비트 플래그가 '1'인 경우에만 존재


정확하게 이야기를 하자면, 위의 패킷 구조에서 Adaption field와 Payload data를 제외한 부분인 4 바이트가 MPEG TS Packet의 Header 부분입니다. 세부적인 내용에 대해서는 추후에 별도의 포스팅에서 다루도록 하겠습니다. 일단 보시면 아시겠지만, Packet 내에 Length와 관련된 부분이 없습니다. 보통 이런 경우에는 고정 바이트 크기이거나, 혹은 극히 드물기는 하지만, 가변적인 길이임에도 해당 길이를 직접 파싱을 하면서 알아내야 하는 경우입니다. Private한 목적으로 하는 프로토콜에서는 본 적이 있지만, 호환성을 생각하는 부분에서 후자의 경우를 본 적은 없습니다.


MPEG - TS는 기본적으로 188 바이트의 고정 크기를 기반으로 하고 있습니다. 이는 위에서도 언급을 했듯이 MPEG - TS 방식 자체가 방송을 목적으로 만들어졌기 때문입니다. 이런 고정 크기의 바이트를 가지는 패킷은 상대적으로 Length 부분에 대한 파싱의 필요성이 사라지면서 효율이 더 올라감은 물론이고, 중간에 유실되거나 손상된 패킷에 대한 처리를 할 수 있다는 장점도 존재합니다. 이런 장점이 존재는 하는데, 도대체 왜 188 바이트의 고정 크기를 잡은 것인지 조금 의문이 들 수 있습니다. 이는 순수하게 방송용으로만 생각한 것이 아니라, QoS가 보장되는 ATM을 통해서 전송된다면, 이 역시 방송을 볼 수 있도록 설계를 했기 때문입니다. 혹시나 해서 찾아봤는데, ATM에 대해서 만족할 만한 수준까지 정리를 한 글은 없더군요. 이 부분도 추후에 보충해야겠습니다.


기본적으로 ATM(Asynchronous Transfer Mode)은 고정 크기의 Cell을 이용하여, Connection 상태를 유지하고 해당 bandwidth를 보장해주는 형태의 네트워크 입니다. 실제로 전화가 연결된 것처럼 특정 connection이 발생하면, 관련 connection간의 고정 bandwidth를 잡아버리고, 이를 해당되는 connection이 끊어질 때까지 유지해 줍니다. 일반적인 인터넷이 Best effort 모델인데 반해, ATM을 이용하면 방송용으로 제작된 MPEG - TS 역시 전송하는데 용이함이 있습니다. 문제는 ATM을 통해 데이터를 전송할 때, Cell이라고 불리는 패킷을 이용해서 전송하는데, Cell은 53바이트의 고정 크기로, 이는 5 바이트의 헤더와 48 바이트의 payload로 구성되어 있습니다. 그런데 여기의 48바이트를 그대로 사용하는 것이 아니라, 1바트는 AAL1 헤더로 사용합니다. 그러면 하나의 Cell은 47바이트를 사용할 수 있고, MPEG - TS Packet의 크기인 188 바이트는 정확히 4개의 Cell에 들어갈 수 있습니다.


최근에는 네트워크 인프라의 상황이 매우 좋아져서, 굳이 ATM을 통하지 않더라도, 일반 가정에서 네트워크 스트리밍을 이용한 방송을 보는 데에는 전혀 문제가 없는 수준으로 올라섰습니다. 동시에 모바일 기기에서도 네트워크 스트리밍을 볼 수 있는 시대인 상황입니다. 그럼에도 기존의 인프라와 계속해서 사용되고 있었던 점을 생각하여, HLS 같은 기술에서도 MPEG-TS는 계속 사용되고 있습니다. 앞으로도 MPEG - TS에 대해서 조금 더 알아봐야 할 것은 있지만, 일단 이 기술이 존재한다는 것과 그리고 아직 현역이라는 점을 알게 된 것으로도 충분한 소득이라고 생각합니다.



참고자료

http://en.wikipedia.org/wiki/MPEG_transport_stream#Packet

http://en.wikipedia.org/wiki/Asynchronous_Transfer_Mode


저작자 표시 비영리 변경 금지
신고
by 가우초 2013.12.01 23:34
| 1 |

티스토리 툴바