JT/T1078-RTP音视频封包

音视频应用开发系列文章目录

JT1078-RTP包结构

JT1078-RTP音视频包定义

#pragma pack(push)
#pragma pack (1)
typedef struct Jt1078AudioRtpPacket_T {

    unsigned char head[4];
#if IS_JT1078RTP_BIGENDIAN // 大小端模式
    unsigned char v : 2;
    unsigned char p : 1;
    unsigned char x : 1;
    unsigned char cc : 4;
    unsigned char m : 1;
    unsigned char pt : 7;
#else
    unsigned char cc : 4;
    unsigned char x : 1;
    unsigned char p : 1;
    unsigned char v : 2;
    unsigned char pt : 7;
    unsigned char m : 1;
#endif
    unsigned short seq;
    unsigned char sim[6];
    unsigned char ch;
#if IS_JT1078RTP_BIGENDIAN
    unsigned char frame_type : 4;
    unsigned char packet_type : 4;
#else
    unsigned char packet_type : 4;
    unsigned char frame_type : 4;
#endif
    int64_t timestamp;
    unsigned short payload_size;

}Jt1078AudioRtpPacket;

JT1078-RTP视频包定义

#pragma pack(push)
#pragma pack (1)
typedef struct Jt1078VideoRtpPacket_T {

    unsigned char head[4];
#if IS_JT1078RTP_BIGENDIAN
    unsigned char v : 2;
    unsigned char p : 1;
    unsigned char x : 1;
    unsigned char cc : 4;
    unsigned char m : 1;
    unsigned char pt : 7;
#else
    unsigned char cc : 4;
    unsigned char x : 1;
    unsigned char p : 1;
    unsigned char v : 2;
    unsigned char pt : 7;
    unsigned char m : 1;
#endif
    unsigned short seq;
    unsigned char sim[6];
    unsigned char ch;
#if IS_JT1078RTP_BIGENDIAN
    unsigned char frame_type : 4;
    unsigned char packet_type : 4;
#else
    unsigned char packet_type : 4;
    unsigned char frame_type : 4;
#endif
    int64_t timestamp;
    unsigned short i_frame_interval;
    unsigned short frame_interval;
    unsigned short payload_size;

}Jt1078VideoRtpPacket;
#pragma pack(pop)

JT1078-RTP音频包封装

填充结构体Jt1078AudioRtpPacket即可,需要注意的是sim是BCD码,大小端根据实际情况转换。payload_size,最大是950byte。音频帧无需分包,每包能发950就发950。

JT1078-RTP视频包封装

填充结构体Jt1078VideoRtpPacket即可,需要注意的是sim是BCD码,大小端根据实际情况转换。如果视频帧大于950byte,需要分包发送。比如某帧视频的大小是2000byte,则先发950且packet_type为第一包,再发950且packet_type为中间包,最后发100且packet_type为最后一个包,可以在一个循环内完成。序列号以RTP包递增,不管是音频还是视频,共用同一个seq。

 

RTP_PAYLOAD_PCMU = 0, // ITU-T G.711 PCM µ-Law audio 64 kbit/s (rfc3551) RTP_PAYLOAD_G723 = 4, // ITU-T G.723.1 8000/1, 30ms (rfc3551) RTP_PAYLOAD_PCMA = 8, // ITU-T G.711 PCM A-Law audio 64 kbit/s (rfc3551) RTP_PAYLOAD_G722 = 9, // ITU-T G.722 audio 64 kbit/s (rfc3551) RTP_PAYLOAD_CN = 13, // Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) (rfc3389) RTP_PAYLOAD_MP3 = 14, // MPEG-1/MPEG-2 audio (rfc2250) RTP_PAYLOAD_G729 = 18, // ITU-T G.729 and G.729a audio 8 kbit/s (rfc3551) RTP_PAYLOAD_SVACA = 20, // GB28181-2016 RTP_PAYLOAD_JPEG = 26, // JPEG video (rfc2435) RTP_PAYLOAD_MPV = 32, // MPEG-1 and MPEG-2 video (rfc2250) RTP_PAYLOAD_MP2T = 33, // MPEG-2 transport stream (rfc2250) RTP_PAYLOAD_H263 = 34, // H.263 video, first version (1996) (rfc2190) RTP_PAYLOAD_AV1X = 35, // https://bugs.chromium.org/p/webrtc/issues/detail?id=11042 RTP_PAYLOAD_MP2P = 100, // MPEG-2 Program Streams video (rfc2250) RTP_PAYLOAD_MP4V = 97, // MP4V-ES MPEG-4 Visual (rfc6416) RTP_PAYLOAD_H264 = 96, // H.264 video (MPEG-4 Part 10) (rfc6184) RTP_PAYLOAD_SVAC = 99, // GB28181-2016 RTP_PAYLOAD_H265 = 98, // H.265 video (MPEG-H Part 2) (rfc7798) RTP_PAYLOAD_MP4A = 101, // MPEG4-generic audio/video MPEG-4 Elementary Streams (rfc3640) RTP_PAYLOAD_LATM = 102, // MP4A-LATM MPEG-4 Audio (rfc6416) RTP_PAYLOAD_OPUS = 103, // RTP Payload Format for the Opus Speech and Audio Codec (rfc7587) RTP_PAYLOAD_MP4ES = 104, // MPEG4-generic audio/video MPEG-4 Elementary Streams (rfc3640) RTP_PAYLOAD_VP8 = 105, // RTP Payload Format for VP8 Video (rfc7741) RTP_PAYLOAD_VP9 = 106, // RTP Payload Format for VP9 Video draft-ietf-payload-vp9-03 RTP_PAYLOAD_AV1 = 107, // https://aomediacodec.github.io/av1-rtp-spec/ RTP_PAYLOAD_H266 = 108, // https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-vvc-18.html RTP_PAYLOAD_RTX = 110, // RTP Retransmission Payload Format (rfc4588) RTP_PAYLOAD_RED = 111, // RTP Payload for Redundant Audio Data (rfc2198) RTP_PAYLOAD_FEC_ULP = 112, // RTP Payload Format for Generic Forward Error Correction (rfc5109) RTP_PAYLOAD_FEC_FLEX = 113, // RTP Payload Format for Flexible Forward Error Correction (rfc8267) RTP_PAYLOAD_FEC_RS = 114, // RTP Payload Format for Reed-Solomon(non-standard/private)如果要打包xml成rtp应该选哪个
最新发布
10-15
<think>我们在处理RTP负载类型时,需要根据具体的媒体类型选择合适的负载类型(payload type)。问题是要将XML打包成RTP,那么我们需要考虑XML数据的特点。XML是文本数据,通常用于传输结构化信息,如字幕、元数据等。 在RTP中,文本数据的传输有专门的负载格式。常见的文本负载类型包括: - `text/red` (冗余文本,使用RED格式) - `text/t140` (用于即时文本,如T.140标准,通常用于实时文本会话) 但是,在给定的枚举列表中,并没有直接对应XML的负载类型。通常,自定义数据或未列出的格式可以使用动态负载类型(dynamic payload types),范围在96-127(根据RFC3551)。动态负载类型需要在SDP中通过`a=rtpmap`属性明确指定媒体类型(media type)和子类型(subtype)。 对于XML数据,我们可以考虑: 1. 如果XML用于传输字幕,可以使用TTML(Timed Text Markup Language)或WebVTT等格式,这些有对应的RTP负载格式(如TTML over RTP)。 2. 如果没有特定的标准,我们可以定义一个自定义的负载类型,在动态范围内选择一个值(例如96-127之间未被使用的值),并为它定义媒体类型(如`application/xml`)。 在给出的枚举列表中,我们看到一些自定义或特定用途的负载类型,比如: - `RTP_PAYLOAD_SVACA` = 20 (GB28181-2016) 和 `RTP_PAYLOAD_SVAC` = 99 (GB28181-2016) 是国标中的负载类型,用于特定的音视频编码。 - 其他负载类型都是针对音视频编码的。 因此,对于XML数据,在标准RTP负载类型中没有直接对应的值。我们需要使用动态负载类型(96-127之间),并在SDP中描述。 所以,如果我们必须从枚举中选择一个,那么我们可以选择一个未被使用的动态负载类型,例如: - 在枚举中,96(H264)、97(MP4V)、98(H265)、99(SVAC)、101(MP4A)、102(LATM)、103(OPUS)、104(MP4ES)、105(VP8)、106(VP9)、107(AV1)、108(H266)等已经被使用。 - 110、111、112、113、114用于重传、冗余和FEC。 因此,我们可以选择96-127之间未被占用的值,例如100(MP2P)已经被使用,那么我们可以选择96-127之间没有被列出的值,比如96-99已经被占用,100被占用,101-108被占用,110-114被占用。那么我们可以选择109(在枚举中没有出现)或者115-127之间的值。 但是,枚举中并没有列出所有动态负载类型,所以我们可以在代码中自己添加一个,例如: ``` RTP_PAYLOAD_XML = 115, // 自定义用于XML传输的负载类型 ``` 注意:在SDP中,我们需要通过`a=rtpmap`属性来指定这个负载类型对应的媒体类型,例如: ``` a=rtpmap:115 application/xml/90000 ``` 这里假设时间戳时钟频率为90000Hz(对于文本,时钟频率通常可以设置为1000,因为文本更新频率较低,但具体取决于应用。如果传输的是静态文本,也可以设置一个较低的频率)。 另外,如果XML数据量小,也可以考虑使用其他已有的文本负载格式,比如T.140(负载类型可以是动态的,在SDP中指定为`text/t140`)。但T.140是为即时文本设计的,可能不适合结构化XML数据。 总结:在枚举中没有直接适用于XML的负载类型,需要自定义一个动态负载类型(例如115),并在SDP中指定媒体类型为`application/xml`。 因此,回答用户问题:如果要打包XML成RTP,应该选择哪个负载类型? 答案:在给定的枚举中没有直接对应的,需要自定义一个动态负载类型(96-127之间未被使用的值,如115),并定义媒体类型为`application/xml`。 §§相关问题§§ 1. RTP动态负载类型的范围是什么?如何分配? 2. 在SDP中如何描述自定义的RTP负载类型(如XML)? 3. 除了自定义负载类型,RTP传输XML数据还有哪些标准方法? 4. 如何为XML数据确定合适的RTP时间戳时钟频率? </think>在RTP协议中打包XML数据时,需要根据XML数据的特性选择合适的负载类型(Payload Type)。分析如下: 1. **XML数据特性** XML是文本型结构化数据(非音视频流),具有数据量小、突发传输的特点。现有标准负载类型(如PCMU、H264等)均针对连续媒体流设计,**无直接对应的标准负载类型**。 2. **推荐解决方案** - **选项1:自定义动态负载类型**(首选) 使用96-127范围的动态负载类型(如`RTP_PAYLOAD_MP4ES=104`),在SDP协议中通过`a=rtpmap`声明媒体类型: ``` a=rtpmap:104 application/xml 1000 ``` 时钟频率(如1000Hz)需根据XML更新频率设定。 - **选项2:复用现有负载类型** 若需兼容旧系统,可选择未使用的静态类型(如`RTP_PAYLOAD_CN=13`),但需确保接收端能识别XML数据。 - **选项3:封装为扩展协议** 通过RTP头部扩展(Header Extension)或载荷扩展携带XML片段(RFC8285)。 3. **关键注意事项** - 需在SDP中明确描述负载格式(如`application/xml`) - 建议添加时间戳支持数据时序 - 大体积XML需分片处理(RFC4629)
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值