H265 about RTP Package __RTP

Source: Internet
Author: User

First, the lower h265 (HEVC) nal cell header, compared to the h264 nal layer, has two bytes of h265 unit header, as shown in the following figure:

It can be seen from the graph that the NAL package structure of HHEVC is different from H264, HEVC add the ID of the time layer of nal, take away NAL_REF_IDC, this information is merged into Naltype, usually F is 0,layerid as 0,tid is 1.

    There are several types of nal units:

[CPP] View plain copy on the code to see a piece of coding derived to my Code slice
Enum Nalunittype
{
Nal_unit_coded_slice_trail_n = 0,//0
Nal_unit_coded_slice_trail_r,//1

Nal_unit_coded_slice_tsa_n,//2
Nal_unit_coded_slice_tla,//3//Current name in the Spec:tsa_r

Nal_unit_coded_slice_stsa_n,//4
Nal_unit_coded_slice_stsa_r,//5

Nal_unit_coded_slice_radl_n,//6
NAL_UNIT_CODED_SLICE_DLP,//7//Current name in the Spec:radl_r

Nal_unit_coded_slice_rasl_n,//8
NAL_UNIT_CODED_SLICE_TFD,//9//Current name in the Spec:rasl_r

NAL_UNIT_RESERVED_10,
Nal_unit_reserved_11,
Nal_unit_reserved_12,
Nal_unit_reserved_13,
Nal_unit_reserved_14,
Nal_unit_reserved_15, Nal_unit_coded_slice_bla,///current name in the SPEC:BLA_W_LP
Nal_unit_coded_slice_bla,////current name in the SPEC:BLA_W_LP
Nal_unit_coded_slice_blant,////current name in the SPEC:BLA_W_DLP
NAL_UNIT_CODED_SLICE_BLA_N_LP,//18
NAL_UNIT_CODED_SLICE_IDR,////current name in the SPEC:IDR_W_DLP
NAL_UNIT_CODED_SLICE_IDR_N_LP,//20
NAL_UNIT_CODED_SLICE_CRA,//21
Nal_unit_reserved_22,
Nal_unit_reserved_23,

Nal_unit_reserved_24,
NAL_UNIT_RESERVED_25,
Nal_unit_reserved_26,
Nal_unit_reserved_27,
Nal_unit_reserved_28,
Nal_unit_reserved_29,
Nal_unit_reserved_30,
Nal_unit_reserved_31,

Nal_unit_vps,//32
Nal_unit_sps,//33
Nal_unit_pps,//34
Nal_unit_access_unit_delimiter,//35
Nal_unit_eos,//36
NAL_UNIT_EOB,//37
Nal_unit_filler_data,//38
Nal_unit_sei,//Prefix SEI
Nal_unit_sei_suffix,//SUFFIX SEI
Nal_unit_reserved_41,
Nal_unit_reserved_42,
NAL_UNIT_RESERVED_43,
NAL_UNIT_RESERVED_44,
NAL_UNIT_RESERVED_45,
NAL_UNIT_RESERVED_46,
NAL_UNIT_RESERVED_47,
NAL_UNIT_UNSPECIFIED_48,
Nal_unit_unspecified_49,
NAL_UNIT_UNSPECIFIED_50,
Nal_unit_unspecified_51,
NAL_UNIT_UNSPECIFIED_52,
Nal_unit_unspecified_53,
Nal_unit_unspecified_54,
Nal_unit_unspecified_55,
NAL_UNIT_UNSPECIFIED_56,
nal_unit_unspecified_57,
NAL_UNIT_UNSPECIFIED_58,
nal_unit_unspecified_59,
NAL_UNIT_UNSPECIFIED_60,
Nal_unit_unspecified_61,
NAL_UNIT_UNSPECIFIED_62,
NAL_UNIT_UNSPECIFIED_63,
Nal_unit_invalid,
};
Below receives the FU group packs the way, the FU packet header format is as follows:

Fus header contains two bytes of Payloadhdr, a byte of Fu Header,fu header and H264, the structure of the following figure, including the start bit (1b), stop bit (1b), Futype (6b)

PAYLODHDR two of its own assignment, in fact, is to HEVC frame data nal Unit header Naltype replaced with 49, the following is from the ffmpeg source of the FU Packaging code fragment:

[CPP] View plain copy on the code to see a piece of coding derived to my Code slice
static void Nal_send (Avformatcontext *ctx, const uint8_t *buf, int len, int last_packet_of_frame)
{
Rtpmuxcontext *rtp_ctx = ctx->priv_data;
int rtp_payload_size = rtp_ctx->max_payload_size-rtp_hevc_headers_size;
int nal_type = (buf[0] >> 1) & 0x3F;

    /* Send it as one single NAL unit?  /if (len <= rtp_ctx->max_payload_size)//less than the maximum value, send directly (maximum is less than MTU) {/* Use the original NAL unit  

Buffer and transmit it as RTP payload * * Ff_rtp_send_data (CTX, buf, Len, last_packet_of_frame); else//greater than the maximum when the FU packet sent {/* Create the HEVC payload header and transmit the buffer as fragment 
                ation units (FU) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                |   F|  Type | Layerid | 
                TID | +-------------+-----------------+ F = 0 Type = Fragmentation Unit 
                    (FU))  
    Layerid = 0 TID = 1/rtp_ctx->buf[0] = << 1;  
       RTP_CTX-&GT;BUF[1] = 1; Here is PAYLAODHDR, the canonical assignment should be the PAYLOADHDR type//rtp_ctx->buf[0 of the replacement HEVC data nal] = (buf[0) &0x81) |  
   (49<<1); 
        RTP_CTX-&GT;BUF[1] = buf[1]/* Create the FU header 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | s|  e| 
        Futype | 
    +---------------+ S = variable E = variable futype = NAL unit type  
    * * rtp_ctx->buf[2] = Nal_type;       
    /* Set the S Bit:mark as start fragment * * Rtp_ctx->buf[2] |= 1 << 7;  
    * Pass the original NAL header///here to note that when the first report data is grouped, it should overwrite the top two bytes of data, H264 to overwrite the previous byte of data, that is the first packet to remove HEVC frame data paylaodhdr  
    BUF + 2;     
    Len-= 2; while (Len > Rtp_payload_size) {/* Complete and send current RTP packet/memcpy (&  
        Rtp_ctx->buf[rtp_hevc_headers_size], buf, rtp_payload_size);  

            Ff_rtp_send_data (CTX, Rtp_ctx->buf, rtp_ctx->max_payload_size, 0);  
        BUF + = Rtp_payload_size;  

            Len-= rtp_payload_size;  
         * Reset the S bit * *   RTP_CTX-&GT;BUF[2] &= ~ (1 << 7);  

     }/* Set the E Bit:mark as last fragment * * rtp_ctx->buf[2] |= 1 << 6;  
    /* Complete and send last RTP packet * * memcpy (&rtp_ctx->buf[rtp_hevc_headers_size), buf, Len);  

Ff_rtp_send_data (CTX, Rtp_ctx->buf, Len + 2, last_packet_of_frame);  
 }

}

Through RTP to send HEVC video data, when the HEVC frame data is greater than the MTU, should be sent to the FU group, from the above code flow is more than max_payload_size data for the flow of the group, this h264 fu-a very similar, very easy to understand.

Reference specification:

Https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14

FFmpeg related Code

Https://www.ffmpeg.org/doxygen/2.5/rtpenc__hevc_8c_source.html

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.