This blog is only to remind myself of what I've learned (from others or by myself) and only for knowledge sharing. External sources will be clearly stated in [Reference] of each article. I hope this blog won't infringe any copyrights and that it can be useful for interested blog readers.

顯示具有 RFC3640 標籤的文章。 顯示所有文章
顯示具有 RFC3640 標籤的文章。 顯示所有文章

2008年2月19日 星期二

mpeg4-generic-parsing for H264 over RFC3640 / RFC3 016


Preface

The following method applies to DVB-H CA channels
scrambled by Nagra and Irdeto CA servers

---
RTP header (there are 4 bytes per line)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... payload 1....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... payload 2....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... payload N.... | ... padding bytes .... | padding count = 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P => padding flag
The last byte of RTP packets => padding count

Steps explained in Psuedo code:

1) calculate real au_header_len_in_bytes

// get the number of bits of au header
au_header_len_in_bytes =
ntohs(*((unsigned short *)&pRTPBuffer[RTP_payload_start_index]));

// don't know why this? need further checking RFC3640/3016
if(au_headers_len_in_bytes % 8 != 0){
au_headers_len_in_bytes = au_headers_len_in_
bytes / 8 + 1;
}else{
au_headers_len_in_bytes = au_headers_len_in_
bytes / 8;
}

2) Find the
first_NALU_start_offset by searching ANNEX_B_START_CODE (0x00000001)

first_NALU_start_offset =
RTP_HEADER_SIZE + 2 + au_headers_len_in_bytes +
ANNEX_B_START_CODE_offset_from_payload;

3) Copy all the rest of RTP payload except padding bytes depending on
P flag of RTP header to a output buffer

ps: the payload might contain one NALU, part of a NALU, or multiple NALUs.

4) Send the resulted output buffer to H264 decoder for decoding

!!NOTES by Mark:
Because SPS/PPS might not be in SDP file,
remember to find SPS/PPS first, I-Frame first for H264 decoder from RTP packets
---

2008年2月18日 星期一

mpeg4-generic parsing for AAC over RFC3640


Preface

Reference
  • RFC3640
  • ISO/IEC 14496-3
  • ISO/IEC 13818-7, MPEG-2 Advanced Coding (AAC)

AU-header structure



AAC frame in AU-header


!!NOTES:
1) DVB-H supports High bit-rate AAC while streaming

2) The AU-headers are configured using MIME format parameters
may be empty. Don’t know how to know it according to SDP description??
(if anyone knows the answer, please let me know..:P)

3) If AAC frames are carried over RFC3640, ADTS header is needed for each AAC frame
for AAC decoder using the following info.

++++++++++++++++++++++++++
| ADTS header (length may vary) |
++++++++++++++++++++++++++
| AAC frame (length may vary) |
++++++++++++++++++++++++++

Example:
[ADTS header]
Please refer to adts_frame() of ISO/IEC 13818-7

[SDP info]
a=rtpmap:97 mpeg4-generic/32000/1
a=fmtp:97 streamType=5;profile-level-id=41;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1288

=> clock-rate = 32000

=> "config" should be parsed based on AudioSpecificConfig() in ISO/IEC 14496-3,

and when forming a ADTS header for an AAC frame,

sampling_frequency_index, channel_configuration needs to be

extracted from "config" field and

frame_length is calculated from RTP payload when parsing AU-header.

---------------------------------------------------------