CN106303537B - 一种openh264多码流传输方法 - Google Patents

一种openh264多码流传输方法 Download PDF

Info

Publication number
CN106303537B
CN106303537B CN201610782232.6A CN201610782232A CN106303537B CN 106303537 B CN106303537 B CN 106303537B CN 201610782232 A CN201610782232 A CN 201610782232A CN 106303537 B CN106303537 B CN 106303537B
Authority
CN
China
Prior art keywords
code stream
rtp
openh264
information
transmission methods
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610782232.6A
Other languages
English (en)
Other versions
CN106303537A (zh
Inventor
袁丽蓉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Ronglian Ets Information Technology Co Ltd
Original Assignee
Beijing Ronglian Ets Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Ronglian Ets Information Technology Co Ltd filed Critical Beijing Ronglian Ets Information Technology Co Ltd
Priority to CN201610782232.6A priority Critical patent/CN106303537B/zh
Publication of CN106303537A publication Critical patent/CN106303537A/zh
Application granted granted Critical
Publication of CN106303537B publication Critical patent/CN106303537B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Abstract

本发明涉及一种OpenH264多码流传输方法，所述方法为：信息发送端的视频编解码器OpenH264读取H.264视频，提取各层码流的可伸缩信息，将其作为RTP头部的扩展内容写入RTP扩展头部，将扩展后的RTP码流打包并依次发送各层数据给中间网元；中间网元接收到码流后，以帧为单位，解析RTP的扩展头部，再根据目标网络转发某一层子码流到目的网络；目标网络的客户端接收中间网元转发来的RTP数据包，客户端的视频编解码器OpenH264进行解码播放。

Description

一种openh264多码流传输方法
技术领域
本发明涉及视频编码技术领域，尤其涉及一种openh264多码流传输方法。
背景技术
SVC(Scalable Video Coding，可伸缩视频编码)是一种基于H.264的可伸缩视频编解码技术，于2007年7月作为H.264标准的附录G发布。SVC技术通常可以在视频编码、视频监控等网络带宽和设备性能各异的应用场景，以及内容管理、存储管理、码流加密等系统中使用。RFC6184和RFC6190分别定义了标准H.264和SVC码流的RTP(Real-time TransportProtocol，实时传输协议)负载格式和中间网元的分发方式；前者定义如何在一个RTP会话中打包和传输一路H.264码流，后者定义如何在一个或多个RTP会话中传输多路可伸缩H.264子码流，且子码流之间根据层级关系存在不同程度的依赖。
为避开H.264专利权的限制，2013年10月Cisco在BSD许可协议下发布了自己的视频编解码器OpenH264，允许用户在实时编解码等应用(如WebRTC)中使用其二进制代码。除了支持不同的CPU处理架构和操作系统外，在编解码特性上，OpenH264还支持时域最高达4层、空域最高达4层的多层编码；通过组合，最多可以组合成16种大小的码流。其中，时域子码流存在依赖关系，即高层子码流在编码时需要参考较低层子码流；而空域子码流不存在依赖关系，即各层子码流独立编码。OpenH264的编码码流不同于RFC6184定义的只针对单一码流，同时码流之间的依赖关系又不同于RFC6190定义的针对标准SVC码流。但是，针对OpenH264一次输出多码流的码流特点和结构，RFC6184和RFC6190都不适合。因此，需要提出一种适应于OpenH264的多码流打包和分发方法。
本发明公开了一种视频编解码器OpenH264的多码流打包和分发方法，用于解决现有技术中的负载格式和中间网元的分发方式不适合OpenH264的问题。
发明内容
鉴于上述的分析，本发明旨在提供一种openh264多码流传输方法，用以解决现有现有负载格式和中间网元的分发方式不适合OpenH264的问题。
本发明的目的主要是通过以下技术方案实现的：
提供一种openh264多码流传输方法，包括如下步骤：
步骤S1：信息发送端的OpenH264视频编解码器读取H.264视频，提取各层码流的可伸缩信息，将其作为RTP头部的扩展内容写入RTP扩展头部，将扩展后的RTP码流打包并依次发送各层数据给中间网元；
步骤S2：中间网元接收到码流后，以帧为单位，解析RTP的扩展头部，再根据目标网络转发某一层子码流到目的网络；
步骤S3：目标网络的客户端接收中间网元转发来的RTP数据包，客户端的OpenH264视频编解码器进行解码播放。
其中，
步骤S1中，所述提取各层码流的可伸缩信息进一步包括：从码流中分离出NAL单元，从NAL单元中提取可伸缩信息。
打包进一步包括：将RTP头的扩展标志X字段置为1，在加上12个字节的RTP头后，还增加8个字节的扩展头部。打包方式为：根据NAL单元的大小决定打包方式：对于小于最大传输单元的NAL单元采用Single NALU的方式进行打包；对于大于最大传输单元的NAL单元采用FU-A的方式进行打包。
所述信息发送端是客户端或服务器。
步骤S2中，判断RTP数据包的打包方式，如果是single Nalu打包方式则直接解析；如果是Fu-A打包方式，则需组包、经过完整性判断后，再解析；
选择需要转发的RTP包，并以base sequence num为基础重新填充新的序列号；
设置新的Mark标志位。
所述选择需要转发的RTP包是根据需要的子码流来选择的；其中，根据目标网络客户端的处理性能和网络状况，选择需要转发的子码流，该子码流所需的处理能力与目标网络客户端的处理能力相匹配。
所述中间网元是媒体服务器或应用网关。
步骤S3中，所述解码进一步包括：将时间戳相同，序列号连续且包含Mark标志位的RTP包去掉12字节头部和8字节头部扩展字节后，以帧为单位进行解码。
本发明有益效果如下：在应用网关或媒体服务器等网元的码流分发上，通过仅判断RTP头部信息就可以实现不同时域和空域的子码流分发，实现简单可依靠。
本发明的其他特征和优点将在随后的说明书中阐述，并且，部分的从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。
图1为OpenH264码流结构的示意图；
图2为RTP头部字段格式的示意图；
图3为头部扩展格式的示意图；
图4为header extension字段的示意图。
图5为openh264多码流传输方法的流程图。
具体实施方式
下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。
本发明具体实施例公开了一种openh264多码流传输方法，流程如图5，具体包括以下步骤：
步骤S1：信息发送端的视频编解码器OpenH264读取H.264视频，所述视频为RTP格式的码流，提取各层码流的可伸缩信息，将其作为RTP头部的扩展内容写入RTP扩展头部，将扩展后的RTP码流打包并依次发送各层数据给中间网元。
视频编解码器OpenH264经过一次编码，可以同时输出时域最高达4层、空域最高达4层的多个子码流，再通过组合，最多可以组合成16种大小的码流。OpenH264的码流结构(如图1所示)包括：序列参数集、图像参数集、Prefix及其后紧跟的NAL单元，以及多个扩展NAL单元。SVC(可伸缩视频编码)标准增加了两种NAL单元类型：prefix nalu和enhancementnalu；其中，prefix nalu指示其后紧跟的NAL单元的SVC层信息，主要为了与原H264码流兼容；enhancement nalu单元指示该NAL单元的SVC层信息。
根据上述OpenH264的码流结构特点，在获取视频后，从码流中分离出NAL单元，从NAL单元中提取可伸缩信息，将该可伸缩信息填充到RTP包的RTP扩展头部，以实现对RTP头部的扩展。在信息发送端的视频编解码器中，实现对每个RTP包填充RTP扩展头部。包括可伸缩信息的RTP数据包头部，能方便中间网元的提取和处理。所述可伸缩信息是指NAL单元中的dependency id、quality id和temporal id这三个字段的信息。
以单路RTP流将OpenH264编码器生成的多个子码流进行打包发送。通常打包标准H.264码流，只需在帧前面加上12个字节的RTP头即可。将RTP头的扩展标志X字段置为1，可以实现在RTP头部后面扩展信息。本实施例中，将RTP头的扩展标志X字段置为1，在加上12个字节的RTP头之外，还增加8个字节的扩展头部，该扩展头部是指通过上述写入可伸缩信息生成的。本实施例的打包格式与RFC6184一致，同时借鉴RFC6190的定义方式对可伸缩信息进行描述。
图2和图3分别列出了RTP头部字段格式和头部扩展格式，各字段的具体含义与RFC3550定义一致。RTP头部扩展格式定义为：defined by profile字段取值为0xbede，length字段定义为1，此两者遵照标准；header extension(图4)字段为自定义格式，长度为4个字节。各字段含义如下：
eFrameType：2bits，帧类型定义。0为保留值；当videoFrameTypeIDR＝1，代表IDR帧；当videoFrameTypeIDR＝2，代表I帧；当videoFrameTypeP＝3，代表P帧；
iLayerType：1bit，取值为0时代表非编码层，取值为1时代表编码层；
S indicator:1bits，与(Did，Tid)对应，当设置成1，表示该层子码流对应的NAL单元的开始；
E indicator：1bits，与(Did，Tid)对应，当设置成1，表示该层子码流对应的NAL单元的结束；
iNalCount:7bits，与(Did，Tid)对应，表示组成该层子码流的nal单元个数；
Did：2bits，表示某层子码流对应的Did，取值范围0～3；
Tid：2bits，表示某层子码流对应的Tid，取值范围0～3；
frame num:16bits，表示编码帧序号，取值范围0～65535。
可伸缩信息的提取方式有两种：对于实时编码，在输出编码帧时，视频编解码器OpenH264提供每个编码帧对应的码流信息，以分层方式给出各层子码流的信息，如是否VCL层，该层包含的NAL单元个数，该层的帧类型，以及给层的Did和Tid；对非实时编码的情况，需要以NAL单元为单位逐一解析，如prefix nalu和enhancement nalu分别提供主码流和子码流的层信息。获取层信息后，在RTP头部将X标志置为1，按头部扩展格式依次填充子码流层信息，S indicator和E indicator根据NalCount设置。
根据RFC6184规定，标准H.264视频的RTP打包方式分为三种类型：single nalumode，non-interleaved mode和interleaved mode。其中non-interleaved mode支持singlenalu、FU-A、STAP-A这三种方式。由于STAP-A聚合包的方式在打包时会将多个NAL单元进行组包，不便于码流的拆分；FU-A会对大小超过MTU(Maximum Transmission Unit，最大传输单元)的NAL单元进行分片，对中间网元的重排序不变。因此，本实施例中根据NAL单元的大小决定打包方式：对于小于MTU(最大传输单元)的NAL单元采用Single NALU的方式进行打包；对于大于MTU(最大传输单元)的NAL单元采用FU-A的方式进行打包。
本步骤既可以在客户端完成，也可以由服务器完成。例如：实时视频会议等交互式应用通常由客户端(此处的客户端相当于服务器所起到的功能)实现码流的打包发送；而直播、点播等应用通常由服务器实现码流的打包发送。
步骤S2：中间网元接收到RTP数据包形式的码流后，以帧为单位(时间戳相同，序列号连续，且Mark标志位为1)解析RTP的扩展头部，再根据目标网络转发某一层子码流到目的网络。中间网元可以是媒体服务器、应用网关等。用标记(Did，Tid)＝(M,N)来表示子码流，其转发规则为：
1.判断RTP数据包的打包方式，如果是single Nalu打包方式则直接解析；如果是Fu-A打包方式，则需组包、经过完整性判断后，再解析。
2.定义base sequence num，从IDR帧开始解析。依据上文所述，RTP头部扩展eFrameType字段值为1的帧，即为IDR帧。
3.选择需要转发的RTP包，并以base sequence num为基础重新填充新的序列号。所述选择需要转发的RTP包是根据需要的子码流来选择的。其中，根据目标网络客户端的处理性能和网络状况，选择需要转发的子码流，该子码流所需的处理能力与目标网络客户端的处理能力相匹配。以转发目标网络需要的子码流(Did，Tid)＝(1,1)为例，需要选择的RTP包包括：iLayerType＝0的所有RTP包，一般为序列参数集或图像参数集；Did＝1，Tid<＝1的所有RTP包。为保证可解码，所选RTP包的序列号需要重新生成且保证连续。此外，若支持丢包重传，还需纪录原RTP包序列号与新生成序列号的对应关系。
4.转发RTP包的时间戳保持不变。
5.设置新的Mark标志位。以转发目标网络需要的子码流(Did，Tid)＝(1,1)为例，将层信息符合Did＝1，Tid<＝1且E indicator值为1的RTP包的Mark标志位设为1。
由于客户端的处理性能和网络状况各异，中间网元(如媒体服务器、应用网关等)对收到的RTP数据包进行一部分或者全部转发，在做排序处理后，保证客户端仅接收与其能力匹配的某一层子码流。处理后的子码流在时间戳、序列号符合RTP传输的标准H.264码流。
步骤S3：目标网络的客户端接收中间网元转发来的RTP数据包，客户端的视频编解码器OpenH264进行解码播放。
具体地，将时间戳相同，序列号连续且包含Mark标志位的RTP包去掉12字节头部和8字节头部扩展字节后，以帧为单位进行解码。
综上所述，本发明实施例提供了一种OpenH264的多码流传输方法，针对OpenH264的码流特点，通过扩展RTP头部、再解析RTP头部扩展信息，实现针对OpenH264多码流的打包和传输。所述方法带来的有益效果如下：
实现了SST(Single Session Transport)传输多码流，与原有H.264码流的负载格式相互兼容，且比RFC6190的解析更为简便快速；
在应用网关或媒体服务器等网元的码流分发上，通过仅判断RTP头部信息就可以实现不同时域和空域的子码流分发，实现简单可依靠。
本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (8)

1.一种openh264多码流传输方法，其特征在于，包括如下步骤：
步骤S1：信息发送端的OpenH264视频编解码器读取H.264视频，提取各层码流的可伸缩信息，将其作为RTP头部的扩展内容写入RTP扩展头部，将扩展后的RTP码流打包并依次发送各层数据给中间网元，所述提取各层码流的可伸缩信息进一步包括：从码流中分离出NAL单元，从NAL单元中提取可伸缩信息，所述可伸缩信息的提取方式包括实时编码时每个编码帧对应的码流信息以分层方式给出各层子码流的信息和非实时编码时以NAL单元为单位逐一解析提供主码流和子码流的层信息；
步骤S2：中间网元接收到码流后，以帧为单位，解析RTP的扩展头部，再根据目标网络转发某一层子码流到目的网络；
步骤S3：目标网络的客户端接收中间网元转发来的RTP数据包，客户端的OpenH264视频编解码器进行解码播放。
2.根据权利要求1所述的openh264多码流传输方法，其特征在于，步骤S1中，所述打包进一步包括：将RTP头的扩展标志X字段置为1，在加上12个字节的RTP头后，还增加8个字节的扩展头部。
3.根据权利要求1所述的openh264多码流传输方法，其特征在于，步骤S1中，所述打包的打包方式为：根据NAL单元的大小决定打包方式：对于小于最大传输单元的NAL单元采用Single NALU的方式进行打包；对于大于最大传输单元的NAL单元采用FU-A的方式进行打包。
4.根据权利要求1所述的openh264多码流传输方法，其特征在于，步骤S1中，所述的信息发送端是客户端或服务器。
5.根据权利要求1所述的openh264多码流传输方法，其特征在于，步骤S2中，所述转发进一步包括：
判断RTP数据包的打包方式，如果是single Nalu打包方式则直接解析；如果是Fu-A打包方式，则需组包、经过完整性判断后，再解析；
选择需要转发的RTP包，并以base sequence num为基础重新填充新的序列号；
设置新的Mark标志位。
6.根据权利要求5所述的openh264多码流传输方法，其特征在于，所述选择需要转发的RTP包是根据需要的子码流来选择的；其中，根据目标网络客户端的处理性能和网络状况，选择需要转发的子码流，该子码流所需的处理能力与目标网络客户端的处理能力相匹配。
7.根据权利要求1所述的openh264多码流传输方法，其特征在于，所述中间网元是媒体服务器或应用网关。
8.根据权利要求1所述的openh264多码流传输方法，其特征在于，步骤S3中，所述解码进一步包括：将时间戳相同，序列号连续且包含Mark标志位的RTP包去掉12字节头部和8字节头部扩展字节后，以帧为单位进行解码。
CN201610782232.6A 2016-08-30 2016-08-30 一种openh264多码流传输方法 Active CN106303537B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610782232.6A CN106303537B (zh) 2016-08-30 2016-08-30 一种openh264多码流传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610782232.6A CN106303537B (zh) 2016-08-30 2016-08-30 一种openh264多码流传输方法

Publications (2)

Publication Number Publication Date
CN106303537A CN106303537A (zh) 2017-01-04
CN106303537B true CN106303537B (zh) 2019-05-10

Family

ID=57672313

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610782232.6A Active CN106303537B (zh) 2016-08-30 2016-08-30 一种openh264多码流传输方法

Country Status (1)

Country Link
CN (1) CN106303537B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106921843B (zh) * 2017-01-18 2020-06-26 苏州科达科技股份有限公司 数据传输方法及装置
CN110945494A (zh) * 2017-07-28 2020-03-31 杜比实验室特许公司 向客户端提供媒体内容的方法和系统
CN115834973B (zh) * 2023-01-12 2023-06-02 厦门简算科技有限公司 一种云端向本地终端数据高速传输方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101646074A (zh) * 2008-08-05 2010-02-10 中兴通讯股份有限公司 视频数据的实时传输方法
CN102595203A (zh) * 2011-01-11 2012-07-18 中兴通讯股份有限公司 一种多媒体数据的传输、接收方法及其传输、接收设备
CN103313045A (zh) * 2013-05-31 2013-09-18 哈尔滨工业大学 宽带多媒体集群系统调度台h.264视频分包方法
CN105052151A (zh) * 2013-03-29 2015-11-11 高通股份有限公司 改进的有效负载格式设计
CN105230016A (zh) * 2013-05-31 2016-01-06 高通股份有限公司 用于视频译码的具有解码次序编号的单个网络抽象层单元包

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101646074A (zh) * 2008-08-05 2010-02-10 中兴通讯股份有限公司 视频数据的实时传输方法
CN102595203A (zh) * 2011-01-11 2012-07-18 中兴通讯股份有限公司 一种多媒体数据的传输、接收方法及其传输、接收设备
CN105052151A (zh) * 2013-03-29 2015-11-11 高通股份有限公司 改进的有效负载格式设计
CN103313045A (zh) * 2013-05-31 2013-09-18 哈尔滨工业大学 宽带多媒体集群系统调度台h.264视频分包方法
CN105230016A (zh) * 2013-05-31 2016-01-06 高通股份有限公司 用于视频译码的具有解码次序编号的单个网络抽象层单元包

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"RTP Payload Format for H.264 Video";wang等;《Internet Engineering Task Force》;20110531;第5.2节

Also Published As

Publication number Publication date
CN106303537A (zh) 2017-01-04

Similar Documents

Publication Publication Date Title
US11924526B2 (en) Segment types as delimiters and addressable resource identifiers
JP6422527B2 (ja) マルチメディアシステムにおけるデータ受信方法及び装置
Bouzakaria et al. Overhead and performance of low latency live streaming using MPEG-DASH
JP5937275B2 (ja) ネットワークストリーミングのための失われたメディアデータの置換
JP4874343B2 (ja) スケーラブルビデオ符号化における、下位互換性のあるピクチャの集約
CN104639943B (zh) 一种基于h.264编码标准的通用视频加密方法及系统
KR100992002B1 (ko) 계층화된 미디어 비트스트림의 패킷화
KR101983035B1 (ko) 방송 시스템에서 멀티미디어 데이터의 수신 장치
US20150074129A1 (en) Augmenting media presentation description and index for metadata in a network environment
CN106303537B (zh) 一种openh264多码流传输方法
CN101646074B (zh) 视频数据的实时传输方法
CA2936164A1 (en) Communication apparatus, communication data generation method, and communication data processing method
EP3020188B1 (en) Endpoint information for network vqm
US11057312B2 (en) Apparatus and method for configuring MMT payload header
CN110636387A (zh) 一种基于h．264网络视频传输系统
CN105407351A (zh) 一种从实时传输协议数据包中重建编码方式的方法和装置
Paik et al. Media-aware scheduling method for transmitting signalling message over MPEG media transport-based broadcast
Edwards Standards and Specifications for Carriage of JPEG XS in RTP for IP Networks
Zhou et al. RTP Encapsulation for Scalable Video Stream and its Application in NS-2 Simulation
Wu et al. The RTP Encapsulation Based on Frame Type Method for AVS Video
Klemets RTP payload format for video codec 1 (VC-1)
Klemets RFC 4425: RTP Payload Format for Video Codec 1 (VC-1)

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant