CN113691832A - 一种视频数据ip化方法及系统 - Google Patents

一种视频数据ip化方法及系统 Download PDF

Info

Publication number
CN113691832A
CN113691832A CN202110976219.5A CN202110976219A CN113691832A CN 113691832 A CN113691832 A CN 113691832A CN 202110976219 A CN202110976219 A CN 202110976219A CN 113691832 A CN113691832 A CN 113691832A
Authority
CN
China
Prior art keywords
video data
video
format
stream
data
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.)
Pending
Application number
CN202110976219.5A
Other languages
English (en)
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.)
Shenzhen Xinlongpeng Technology Co ltd
Original Assignee
Shenzhen Xinlongpeng 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 Shenzhen Xinlongpeng Technology Co ltd filed Critical Shenzhen Xinlongpeng Technology Co ltd
Priority to CN202110976219.5A priority Critical patent/CN113691832A/zh
Publication of CN113691832A publication Critical patent/CN113691832A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/233—Processing of audio elementary streams
    • H04N21/2335—Processing of audio elementary streams involving reformatting operations of audio signals, e.g. by converting from one coding standard to another
    • 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/234309—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 transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4 or from Quicktime to Realvideo
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4398—Processing of audio elementary streams involving reformatting operations of audio signals
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440218—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4
    • 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/64322—IP

Abstract

本发明公开了一种视频数据IP化方法，包括以下步骤：将视频数据转化为BT1120信号；将所述BT1120信号转码为H264或H265格式的视频数据流；将所述视频数据流打包成流媒体数据；将所述流媒体数据发送至网络。本发明提供的视频数据IP化方法，将视频数据先转化为BT1120信号，通过BT1120的硬件接口输出给视频处理器，视频处理器将接收到的BT1120信号转码为H264或H265格式的视频数据流，随之将视频数据流打包成可供网络传播的流媒体数据，通过网络接口发送到网络的服务端或者客户端，从而实现将视频数据IP化的目的。

Description

一种视频数据IP化方法及系统
技术领域
本发明涉及计算机网络技术领域，尤其是涉及一种视频数据IP化方法及系统。
背景技术
在传统的视频系统中，各厂商们采用不同的通讯方式和控制协议，这使得不同的技术和产品之间就像一座座信息孤岛，相互之间不能互通的主要原因是因为它们所传送数据的格式不同，要将彼此之间连接起来，就需要配置复杂的转换设备或者对相应系统进行再开发，使得成本升高，并且降低了工作效率。
随着智能终端普及程度的提高和5G网络覆盖程度的增加，视频数据的应用广度以及项目规模也在不断扩大，各类视频数据设备及产品层出不穷，如何在不同技术和产品之间实现有效的互联互通，便成为影响视频数据的应用及推广的重要因素。
而视频数据的IP化即视频IP化恰恰解决了这一问题。IP化实际上是各个开放接口采用IP协议进行通信，而IP协议本质上是一套由软件程序组成的协议软件，它把各种不同格式的数据统一转换成IP数据包格式，具有开放性的特点，从而实现不同技术和产品的互联互通，其能让各种不同系统通过网络实现无缝连接，使得各种设备能轻松的连接到同一网络基础架构中。
相关技术中，基于海思芯片的视频IP化解决方案占据着市场的主要地位，缺乏其它种类的视频IP化解决方案。由于市场限制，基于系统或产品的多样化需求，提供一种在海思芯片方案之外的便捷且有效的视频数据IP化方法，是本领域技术人员函待解决的问题。
发明内容
为了满足基于系统或产品的多样化需求，解决由于基于海思芯片的视频IP化解决方案占据着市场的主要地位，缺乏其它种类的视频IP化解决方案的问题，提供在海思芯片方案之外的便捷且有效的视频数据的IP化方法，本发明提供了一种视频数据IP化方法，包括以下步骤：
将视频数据转化为BT1120信号；
将所述BT1120信号转码为H264或H265格式的视频数据流；
将所述视频数据流打包成流媒体数据；
将所述流媒体数据发送至网络。
通过上述技术方案，将视频数据先转化为BT1120信号，通过BT1120的硬件接口输出给视频处理器，视频处理器将接收到的BT1120信号转码为H264或H265格式的视频数据流，随之将视频数据流打包成可供网络传播的流媒体数据，通过网络接口发送到网络的服务端或者客户端，从而实现将视频数据IP化的目的。
优选的，所述将所述BT1120信号转码为H264或H265格式的视频数据流具体为：
处理所述BT1120信号，形成底层视频流；
将所述底层视频流转换成预设格式的视频数据；
将所述视频数据转码为H264或H265格式的所述视频数据流；
其中所述预设格式包括分辨率大小和缩放倍数。
通过上述技术方案，接收BT1120信号之后，对其进行处理，使其生成相应的底层视频流，再将底层视频流转换成预设格式的视频数据，由于预设格式包括分辨率大小和缩放倍数，使得转码为H264或H265格式的视频数据流，能够具有不同的分辨率和缩放倍数，进而使得打包形成的流媒体数据，满足服务端或客户端对分辨率和缩放倍数的各种不同要求。
进一步的，在所述将所述底层视频流转换成预设格式的视频数据之后，还包括：
将所述视频数据按照不同的预设格式分别通过对应的接口输出，形成设备文件暴露给上层应用；
上层应用通过输入输出控制打开所述设备文件，获取所述视频数据。
通过上述技术方案，将视频数据按照不同的预设格式，分别通过对应的接口输出，上层应用通过输入输出控制打开暴露的设备文件，获取视频数据，从而实现上层应用可以通过不同接口获得对应的各个预设格式的视频数据，同时由于是采用设备文件形式暴露给上层应用，使得可以通过输入输出控制直接打开设备文件，从而快捷方便的进行取流操作。
进一步的，在所述上层应用通过输入输出控制打开所述设备文件，获取所述视频数据之后，还包括：
对所述视频数据按照目的格式进行对应处理；
其中，所述对应处理包括分辨率调整、视频裁剪、视频翻转中的至少一种。
通过上述技术方案，在获取视频数据后，按照所需的目的格式，对其进行分辨率调整、视频裁剪、视频翻转等对应处理，从而进一步满足不同服务端或者客户端在呈现视频数据的具体要求，即当视频数据的呈现要求不在之前的预设格式范围中时，可以直接根据服务端或者客户端的目的格式进行对应处理。
优选的，所述上层应用通过输入输出控制打开所述设备文件，获取所述视频数据具体为：
所述上层应用通过输入输出控制打开所述设备文件；
依据配置文件的预设配置，获取所述视频数据。
通过上述技术方案，使得上层应用可以在对应的配置文件中的预设配置下，获取到不同格式和/或参数的视频数据，提高视频数据的适用度。
优选的，所述流媒体数据的协议格式为RTSP和RTMP中的至少一种。
在上述方案中，采用RTSP是直接推流到设备端或客户端，而采用RTMP可以推流到服务器端，这样会对网络带宽会有很好的平衡作用。
优选的，在所述将视频数据转化为BT1120信号之前，还包括：
混合源视频数据和源音频数据，形成HDMI格式的音视频数据；
解析所述音视频数据，获得所述视频数据。
通过上述技术方案，将源视频数据和源音频数据，形成HDMI格式的音视频数据，使得可以选择PC，或者具有HDMI输出接口的音视频设备作为信号源的输入设备。
进一步的，还包括如下步骤：
解析所述音视频数据，获得所述音频数据；
将音频数据转化为I2S信号；
将所述I2S信号转码为AAC格式的音频数据流；
其中，所述将所述视频数据流打包成流媒体数据具体为，将所述视频数据流和所述音频数据流打包成流媒体数据。
通过上述方案，将音频数据转化为I2S信号，通过I2S的硬件接口输出给音频处理器，音频处理器将接收到的I2S信号转码为AAC格式的音频数据流，随之将视频数据流和音频数据流打包成可供网络传播的流媒体数据，通过网络接口发送到网络的服务端或者客户端，从而实现将音视频数据IP化的目的。
本发明还提供了一种视频数据IP化系统，包括：
转化模块，用于将视频数据转化为BT1120信号；
转码模块，用于将所述BT1120信号转码为H264或H265格式的视频数据流；
打包模块，用于将所述视频数据流打包成流媒体数据；
发送模块，用于将所述流媒体数据发送至网络。
通过上述方案，转化模块将视频数据先转化为BT1120信号，通过BT1120的硬件接口输出给视频处理器，视频处理器的转码模块，将接收到的BT1120信号转码为H264或H265格式的视频数据流，随之打包模块将视频数据流打包成可供网络传播的流媒体数据，发送模块通过网络接口发送到网络的服务端或者客户端，从而实现将视频数据IP化的目的。
进一步的，所述转码模块包括：
处理单元，用于处理所述BT1120信号，形成底层视频流；
转换单元，用于将所述底层视频流转换成预设格式的视频数据；
转码单元，用于将所述视频数据转码为H264或H265格式的所述视频数据流；
其中所述预设格式包括分辨率大小和缩放倍数。
通过上述方案，接收BT1120信号之后，处理单元对其进行处理，使其生成相应的底层视频流，转换单元再将底层视频流转换成预设格式的视频数据，由于预设格式包括分辨率大小和缩放倍数，使得转码单元转码为H264或H265格式的视频数据流，能够具有不同的分辨率和缩放倍数，进而使得打包形成的流媒体数据，满足服务端或客户端对分辨率和缩放倍数的各种不同要求。
进一步的，所述转码模块还包括：
输出单元，用于将所述视频数据按照不同的所述预设格式分别通过对应的接口输出，形成设备文件暴露给所述上层应用；
获取单元，用于使得所述上层应用通过输入输出控制打开所述设备文件，获取所述视频数据。
通过上述技术方案，输出单元将视频数据按照不同的预设格式，分别通过对应的接口输出，获取单元则对接上层应用，通过输入输出控制打开暴露的设备文件，获取视频数据，从而实现上层应用可以通过不同接口获得对应的各个预设格式的视频数据，同时由于是采用设备文件形式暴露给上层应用，使得可以通过输入输出控制直接打开设备文件，从而快捷方便的进行取流操作。
进一步的，所述转码模块还包括：
格式处理单元，用于对所述视频数据按照目的格式进行对应处理；
其中，所述对应处理包括分辨率调整、视频裁剪、视频翻转中的至少一种。
通过上述技术方案，格式处理单元在获取视频数据后，按照所需的目的格式，对其进行分辨率调整、视频裁剪、视频翻转等对应处理，从而进一步满足不同服务端或者客户端在呈现视频数据的具体要求，即当视频数据的呈现要求不在之前的预设格式范围中时，可以直接根据服务端或者客户端的目的格式进行对应处理。
优选的，所述获取单元用于使得所述上层应用通过输入输出控制打开所述设备文件，并依据依据所述配置文件的所述预设配置，获取所述视频数据。
通过上述技术方案，获取单元使得上层应用可以在对应的配置文件中的预设配置下，获取到不同格式和/或参数的视频数据，提高视频数据的适用度。
优选的，所述打包模块打包成的所述流媒体数据的协议格式为RTSP和RTMP中的至少一种。
在上述方案中，采用RTSP协议是直接推流到设备端或客户端，而采用RTMP协议可以推流到服务器端，这样会对网络带宽会有很好的平衡作用。
优选的，还包括：
混合模块，用于混合源视频数据和源音频数据，形成HDMI格式的音视频数据；
解析模块，用于解析所述音视频数据，获得所述视频数据。
通过上述技术方案，混合模块将源视频数据和源音频数据，形成HDMI格式的音视频数据，使得可以选择PC，或者具有HDMI输出接口的音视频设备作为信号源的输入设备。
进一步的，所述解析模块6还用于解析音视频数据，获得音频数据；
所述转化模块还用于将所述音频数据转化为I2S信号；
所述转码模块还用于将所述I2S信号转码为AAC格式的音频数据流；
其中，打包模块用于将所述视频数据流和所述音频数据流打包成所述流媒体数据。
通过上述方案，转化模块将音频数据转化为I2S信号，通过I2S的硬件接口输出给转码模块，而转码模块将接收到的I2S信号转码为AAC格式的音频数据流，打包模块随之将视频数据流和音频数据流打包成可供网络传播的流媒体数据，发送模块通过网络接口发送到网络的服务端或者客户端，从而实现将音视频数据IP化的目的。
综上所述，本申请通过将视频数据先转化为BT1120信号，通过BT1120的硬件接口输出给视频处理器，视频处理器将接收到的BT1120信号转码为H264或H265格式的视频数据流，随之将视频数据流打包成可供网络传播的流媒体数据，通过网络接口发送到网络的服务端或者客户端，从而实现将视频数据IP化的目的。
附图说明
图1是本申请实施例中的其中一种视频数据IP化方法的流程示意图；
图2是本申请实施例中的其中一种视频数据IP化方法的流程示意图；
图3是本申请实施例中的其中一种视频数据IP化方法的步骤S2022的流程示意图；
图4是本申请实施例中的其中一种视频数据IP化方法的实施示意图；
图5是本申请实施例中的其中一种视频数据IP化方法的实施示意图；
图6是本申请实施例中的其中一种视频数据IP化方法的流程示意图；
图7是本申请实施例中的其中一种视频数据IP化系统的示意图；
图8是本申请实施例中的其中一种视频数据IP化系统的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
本发明实施例提供了一种视频数据IP化方法，如图1所示，包括以下步骤：
S101.将视频数据转化为BT1120信号；
S102.将BT1120信号转码为H264或H265格式的视频数据流；
S103.将视频数据流打包成流媒体数据；
S104.将流媒体数据发送至网络。
在实际使用中，可使用FPGA编码系统执行步骤S101，同时使用RK1126/RK1109系统执行步骤S102至步骤S104，而发送至网络的流媒体数据由处于网络中的服务器端或客户端获取，即使用的是FPAG转换编码的BT1120，这种接口更具有通用性和普遍性。
需要说明的是，FPGA(FieldProgrammableGateArray，现场可编程门阵列)是在PAL、GAL等可编程器件的基础上进一步发展的产物。它是作为专用集成电路领域中的一种半定制电路而出现的，既解决了定制电路的不足，又克服了原有可编程器件门电路数有限的缺点。
而RK1126/RK1109系统，是采用视觉处理器RV1109/RV1126芯片的视频处理系统，其中RV1126和RV1109都是人工智能下机器视觉分支的SoC，都内置独立NPU，RV1126可提供1.5TOPS算力，RV1109可提供1.2TOPS算力。
现阶段网络视频的应用要求逐步提升，各种个性化需求也在不断出现，相较于传统的基于海思芯片的视频IP化解决方案，采用RK1126/RK1109系统，对硬解FLASH以及H265上都做到完美兼容，同时其还能支持3D播放，且由于海思芯片的市场限制因素，其已经难以再跟进应用要求和个性化需求的逐步更新，研发人员对应进行后续开发的难度越来越高，例如其支持H265的方案或者支持3D播放的方案迟迟未能出现，从技术上难以得到突破。
而本实施例所采用的FPGA编码系统，具备接收视频数据的视频接口，同时其编码功能可以将视频数据转化为BT1120信号，再通过BT1120的硬件接口输出给RK1126/RK1109系统。除RV1109/RV1126芯片外，本实施例的RK1126/RK1109系统还设置有用于发送流媒体数据的网络接口，例如RJ45接口。
本实施例提供的视频数据IP化方法，将视频数据先转化为BT1120信号，通过BT1120的硬件接口输出给视频处理器，视频处理器将接收到的BT1120信号转码为H264或H265格式的视频数据流，随之将视频数据流打包成可供网络传播的流媒体数据，通过网络接口发送到网络的服务端或者客户端，从而实现将视频数据IP化的目的。
在本实施例的其中一种实施方式中，如图2所示，步骤S102即将BT1120信号转码为H264或H265格式的视频数据流具体为：
S201.处理BT1120信号，形成底层视频流；
S202.将底层视频流转换成预设格式的视频数据；
S203.将视频数据转码为H264或H265格式的视频数据流；
其中预设格式包括分辨率大小和缩放倍数。
通过上述技术方案，处理BT1120信号之后，使其生成相应的底层视频流，再将底层视频流转换成预设格式的视频数据，由于预设格式包括分辨率大小和缩放倍数，使得转码为H264或H265格式的视频数据流，能够具有不同的分辨率和缩放倍数，进而使得打包形成的流媒体数据，满足服务端或客户端对分辨率和缩放倍数的各种不同要求。
在实际使用中，经过步骤S201处理后的底层视频流，上层应用例如服务端及客户端，通常可以直接从接口/dev/video0即基础视频接口取到视频数据。但是为了上层能取到不同分辨率和样式的视频数据流，需要通过步骤S202将底层视频流转换成预设格式的视频数据，本实施例中可以输出4种不同格式的视频数据，分别是：不支持设置分辨率、不支持缩放的第一种,可支持最大width为3264、可支持最大8倍缩放的第二种，可支持最大width为1280、可支持最大8倍缩放的第三种，以及可支持最大width为900、可支持最大8倍缩放的第四种。从而在执行步骤S203即将视频数据转码为H264或H265格式的视频数据流之后，转码后的视频数据流也同样具备上述4种不同格式。
需要注意的是，底层视频流本身存在不支持调整分辨率和缩放倍数的有可能性，因此上述的4种不同格式的视频数据，在此种情况下，只会存在一种格式即不支持设置分辨率、不支持缩放的第一种，而原定的其它三种即第二种至第四种，可以选择同样转变成第一种，也可以选择不进行转换或者不进行输出，实际的处理方式可视具体情况选择，在此不再累述。
在本实施例的其中一种实施方式中，如图2所示，在步骤S202即将底层视频流转换成预设格式的视频数据之后，还包括：
S2021.将视频数据按照不同的预设格式分别通过对应的接口输出，形成设备文件暴露给上层应用；
S2022.上层应用通过输入输出控制打开设备文件，获取视频数据。
通过上述技术方案，将视频数据按照不同的预设格式，分别通过对应的接口输出，上层应用通过输入输出控制打开暴露的设备文件，获取视频数据，从而实现上层应用可以通过不同接口获得对应的各个预设格式的视频数据，同时由于是采用设备文件形式暴露给上层应用，使得可以通过输入输出控制直接打开设备文件，从而快捷方便的进行取流操作。
例如本实施例中，如图4和图5所示，bt1120信号会在代码中会通过在配置文件中定义的模块avafpga进入到模块hw:rkcif,其中模块hw:rkcif包括了子模块rkcif_dvp和rkcif_dvp_sditf。而avafpga通过接口cam_para_out2和cif_para_in与rkcif_dvp建立链路上的联系，使视频流可以从avafpga进入到了rkcif_dvp模块，然后视频流会从/dev/video0中出来，此时上层的应用app可以从接口/dev/video0取到视频流。但是为了上层能取到不同分辨率和格式的数据流，因此需要后面模块的继续级联：rkcif_dvp_sditf，模块hw:rkisp中的rkisp_vir0，以及模块hw:rkispp中的rkispp_vir0，最后可以输出4个接口的视频流。
然后，步骤S2021使得不同预设格式的视频数据分别在对应接口进行输出，输出时采用设备文件的方式暴露给上层应用。而步骤S2022具体实现如下：上层的用户层的应用，诸如mediaserver、V4L2-media、UAC、UVC会通过输入输出控制即IOctrl的方式打开设备文件，以对对应的设备文件进行取流即获取视频数据的操作。当前的网络推流系统中会以mediaserver作为主进程进行对应的设备的打开、设置、取流和关闭等操作。
本实施例中，前述的4种不同分辨率和样式的视频数据，其分别对应的输出接口具体为：不支持设置分辨率、不支持缩放的m_bypass(即/dev/video20),可支持最大width为3264、可支持最大8倍缩放的Scale0(即/dev/video21)，可支持最大width为1280、可支持最大8倍缩放的Scale1(即/dev/video22)，以及可支持最大width为900、可支持最大8倍缩放的Scale2(即/dev/video23)。当然，输出接口的数量及视频数据的预设格式数量，可以根据实际需要进行选择，也可以采用多路视频数据通过同一个输出接口进行输出，具体设置及配置方法在此不再累述。
在本实施例的其中一种实施方式中，如图2所示，在步骤S2022即上层应用通过输入输出控制打开设备文件，获取视频数据之后，还包括：
S2023.对视频数据按照目的格式进行对应处理；
其中，对应处理包括分辨率调整、视频裁剪、视频翻转中的至少一种。
通过上述技术方案，在获取视频数据后，按照所需的目的格式，对其进行分辨率调整、视频裁剪、视频翻转等对应处理，从而进一步满足不同服务端或者客户端在呈现视频数据的具体要求，即当视频数据的呈现要求不在之前的预设格式范围中时，可以直接根据服务端或者客户端的目的格式进行对应处理。
之所以要对视频数据进行目的格式的对应处理，是因为上层的应用(比如web的相关配置)会需要设置视频的分辨率，视频的裁剪，视频的上下左右的翻转，而进行目的格式的处理正是提供了此种类型的操作，满足了对应的要求，在本实施中，采用RGA转换作为步骤S206的具体实现方式，具体的转换步骤在此不再累述。
需要注意的是，对视频数据进行目的格式的对应处理时，可以单独进行分辨率调整、视频裁剪、视频翻转中的其中一种处理，也可以进行分辨率调整、视频裁剪、视频翻转中的其中两种处理，当然也可以全部三种都进行，具体情况依实际需要进行选择，在此不再累述。
在本实施例的其中一种实施方式中，如图3所示，步骤S2022即上层应用通过输入输出控制打开设备文件，获取视频数据具体为：
S20221.上层应用通过输入输出控制打开设备文件；
S20222.依据配置文件的预设配置，获取视频数据。
通过上述技术方案，使得上层应用可以在对应的配置文件中的预设配置下，获取到不同格式和/或参数的视频数据，提高视频数据的适用度。
在实际运用中，配置文件的配置条件、参数等可以根据具体需要进行选择，例如本实施例中，可从数据源接口m_bypass，即接口/dev/video20取到视频数据(同理也可以从其他的接口如video21，video22等接口取流)，取流的内存分配方式为MEMORY_MMAP，取流分辨率是：1920x1080,并且以nv12的格式提供给上层应用mediaserver。
需要注意的是，与上述举例不同，配置文件的配置条件、参数可以只针对格式及参数中的其中一种选择处理，例如取流的内存分配方式为MEMORY_MMAP，取流分辨率是：1920x1080，而格式不进行具体处理，就直接提供给上层应用mediaserver，也可以是不设置内存分配方式，取流分辨率是：1920x1080,并且以nv12的格式提供给上层应用mediaserver，或者取流的内存分配方式为MEMORY_MMAP，按照原分辨率取流，并且以nv12的格式提供给上层应用mediaserver。
在本实施例的其中一种实施方式中，流媒体数据的协议格式为RTSP和RTMP中的至少一种。
在上述方案中，采用RTSP协议是直接推流到设备端或客户端，而采用RTMP协议可以推流到服务器端，这样会对网络带宽会有很好的平衡作用。
需要注意的是，流媒体数据具体采用哪种协议格式，应根据实际的网络环境选择，例如在网络带宽充裕和/或客户端数量较少时，对带宽的要求相对较低，可以选择采用RTSP协议直接推流到设备端或客户端；而在网络带宽有限和/或客户端数量较多时，对带宽的要求会相对较高，可以选择RTMP协议推流到服务器端。
在本实施例的其中一种实施方式中，如图6所示，在将视频数据转化为BT1120信号之前，还包括：
S301.混合源视频数据和源音频数据，形成HDMI格式的音视频数据；
S302.解析音视频数据，获得视频数据。
通过上述技术方案，将源视频数据和源音频数据，形成HDMI格式的音视频数据，使得可以选择PC，或者具有HDMI输出接口的音视频设备作为信号源的输入设备。
在本实施例的其中一种实施方式中，如图6所示，还包括如下步骤：
S303.解析音视频数据，获得音频数据；
S304.将音频数据转化为I2S信号；
S305.将I2S信号转码为AAC格式的音频数据流；
其中，步骤S103即将视频数据流打包成流媒体数据具体为，S1031.将视频数据流和音频数据流打包成流媒体数据。需要注意的是，I2S信号在其它文件或者资料中，也会被写作I2S信号，两种标识在本实施中属于同一个名词，均为同一种音频信号。
通过上述方案，将音频数据转化为I2S信号，通过I2S的硬件接口输出给音频处理器，音频处理器将接收到的I2S信号转码为AAC格式的音频数据流，随之将视频数据流和音频数据流打包成可供网络传播的流媒体数据，通过网络接口发送到网络的服务端或者客户端，从而实现将音视频数据IP化的目的。
本发明实施例还提供了一种视频数据IP化系统，如图7所示，包括：
转化模块1，用于将视频数据转化为BT1120信号；
转码模块2，用于将BT1120信号转码为H264或H265格式的视频数据流；
打包模块3，用于将视频数据流打包成流媒体数据；
发送模块4，用于将流媒体数据发送至网络。
各模块的连接关系可根据信号或者数据的走向即发送/接收进行确定，本实施例中，转化模块1与转码模块2连接，转码模块2与打包模块3连接，打包模块3与发送模块4连接，需要注意的是，此处所述的连接，并不限定具体的连接方式，可以是采用电路方式的有线连接，也可以是采用蓝牙通讯的无线连接，即连接表示的是逻辑联系关系，各模块之间只要能够实现信号或数据的传输，实际的连接方式及具体的设置不做限定。
通过上述方案，转化模块1将视频数据先转化为BT1120信号，通过BT1120的硬件接口输出给视频处理器，视频处理器的转码模块2将接收到的BT1120信号转码为H264或H265格式的视频数据流，随之打包模块3将视频数据流打包成可供网络传播的流媒体数据，发送模块4通过网络接口发送到网络的服务端或者客户端，从而实现将视频数据IP化的目的。
在实际使用中，经过转化模块1转换后的BT1120信号，会通过在配置文件中代码所定义的接入模块进入到RK1126/RK1109系统，RK1126/RK1109系统中包括转码模块2、打包模块3和发送模块4，从而实现将BT1120信号转码为H264或H265格式的视频数据流后，将视频数据流打包成流媒体数据并发送至网络的功能。
在本实施例的其中一种实施方式中，如图8所示，转码模块2包括：
处理单元21，用于处理BT1120信号，形成底层视频流；
转换单元22，用于将底层视频流转换成预设格式的视频数据；
转码单元23，用于将视频数据转码为H264或H265格式的视频数据流；
其中预设格式包括分辨率大小和缩放倍数。
通过上述方案，在输出BT1120信号之前，处理单元21按照预设格式进行预处理，使其生成相应的底层视频流，转换单元22再将底层视频流转换成预设格式的视频数据，由于预设格式包括分辨率大小和缩放倍数，使得转码单元23转码形成的H264或H265格式的视频数据流，能够具有不同的分辨率和缩放倍数，进而使得打包形成的流媒体数据，满足服务端或客户端对分辨率和缩放倍数的各种不同要求。
在实际使用中，转换单元22可以包括依次设置的第一转换组块和第二转换组块，其中第一转换组块用于对底层视频流进行分辨率大小的转换，而第二转换组块则用于对底层视频流进行缩放倍数的转换，当然，转换组块的具体数量及实际功能，也可以根据需要进行选择，例如还可以再包括第三转换组块，而其负责对底层视频流进行颜色的转换，甚至第三转换组块还可以同时进行视频大小裁剪的转换，具体的方法及类型在此不再累述。
需要注意的是，底层视频流本身存在不支持调整分辨率和缩放倍数的有可能性，因此转换单元22中所述的各个转换组块也可以仅仅是将底层视频流转换成视频数据，而不对分辨率和缩放倍数做任何调整。
在本实施例的其中一种实施方式中，如图8所示，转码模块2还包括：
输出单元24，用于将视频数据按照不同的预设格式分别通过对应的接口输出，形成设备文件暴露给上层应用；
获取单元25，用于使得上层应用通过输入输出控制打开设备文件，获取视频数据。
通过上述技术方案，输出单元24将视频数据按照不同的预设格式，分别通过对应的接口输出，获取单元25则对接上层应用，通过输入输出控制打开暴露的设备文件，获取视频数据，从而实现上层应用可以通过不同接口获得对应的各个预设格式的视频数据，同时由于是采用设备文件形式暴露给上层应用，使得可以通过输入输出控制直接打开设备文件，从而快捷方便的进行取流操作。
在实际使用中，上层的用户层的应用，诸如mediaserver、V4L2-media、UAC、UVC会通过输入输出控制即IOctrl的方式打开设备文件，以对对应的设备文件进行取流即获取视频数据的操作。当前的网络推流系统中会以mediaserver作为主进程进行对应的设备的打开、设置、取流和关闭等操作。
前述的4种不同分辨率和样式的视频数据，其分别对应的输出接口具体为：不支持设置分辨率、不支持缩放的m_bypass(即/dev/video20),可支持最大width为3264、可支持最大8倍缩放的Scale0(即/dev/video21)，可支持最大width为1280、可支持最大8倍缩放的Scale1(即/dev/video22)，以及可支持最大width为900、可支持最大8倍缩放的Scale2(即/dev/video23)。当然，输出接口的数量及视频数据的预设格式数量，可以根据实际需要进行选择，也可以采用多路视频数据通过同一个输出接口进行输出，具体设置及配置方法在此不再累述。
在本实施例的其中一种实施方式中，如图8所示，转码模块2还包括：
格式处理单元26，用于对视频数据按照目的格式进行对应处理；
其中，对应处理包括分辨率调整、视频裁剪、视频翻转中的至少一种。
通过上述技术方案，格式处理单元26在获取视频数据后，按照所需的目的格式，对其进行分辨率调整、视频裁剪、视频翻转等对应处理，从而进一步满足不同服务端或者客户端在呈现视频数据的具体要求，即当视频数据的呈现要求不在之前的预设格式范围中时，可以直接根据服务端或者客户端的目的格式进行对应处理。
之所以要对视频数据进行目的格式的对应处理，是因为上层的应用(比如web的相关配置)会需要设置视频的分辨率，视频的裁剪，视频的上下左右的翻转，而进行目的格式的处理正是提供了此种类型的操作，满足了对应的要求，在本实施中，采用RGA转换作为目的格式对应处理的具体实现方式，具体的转换步骤在此不再累述。
需要注意的是，格式处理单元26对视频数据进行目的格式的对应处理时，可以单独进行分辨率调整、视频裁剪、视频翻转中的其中一种处理，也可以进行分辨率调整、视频裁剪、视频翻转中的其中两种处理，当然也可以全部三种都进行，具体情况依实际需要进行选择，在此不再累述。
在本实施例的其中一种实施方式中，获取单元25用于使得上层应用通过输入输出控制打开设备文件，并依据依据配置文件的预设配置，获取所述视频数据。
通过上述技术方案，获取单元25使得上层应用可以在对应的配置文件中的预设配置下，获取到不同格式和/或参数的视频数据，提高视频数据的适用度。
在实际运用中，配置文件的配置条件、参数等可以根据具体需要进行选择，例如本实施例中，可从数据源接口m_bypass，即接口/dev/video20取到视频数据(同理也可以从其他的接口如video21，video22等接口取流)，取流的内存分配方式为MEMORY_MMAP，取流分辨率是：1920x1080,并且以nv12的格式提供给上层应用mediaserver。
需要注意的是，与上述举例不同，配置文件的配置条件、参数可以只针对格式及参数中的其中一种选择处理，例如取流的内存分配方式为MEMORY_MMAP，取流分辨率是：1920x1080，而格式不进行具体处理，就直接提供给上层应用mediaserver，也可以是不设置内存分配方式，取流分辨率是：1920x1080,并且以nv12的格式提供给上层应用mediaserver，或者取流的内存分配方式为MEMORY_MMAP，按照原分辨率取流，并且以nv12的格式提供给上层应用mediaserver。
在本实施例的其中一种实施方式中，打包模块3打包成的流媒体数据的协议格式为RTSP和RTMP中的至少一种。
在上述方案中，采用RTSP协议是直接推流到设备端或客户端，而采用RTMP协议可以推流到服务器端，这样会对网络带宽会有很好的平衡作用。
需要注意的是，流媒体数据具体采用哪种协议格式，应根据实际的网络环境选择，例如在网络带宽充裕和/或客户端数量较少时，对带宽的要求相对较低，可以选择采用RTSP协议直接推流到设备端或客户端；而在网络带宽有限和/或客户端数量较多时，对带宽的要求会相对较高，可以选择RTMP协议推流到服务器端。
在本实施例中，打包为RTSP协议的流媒体数据的监听对应端口为554端口，而打包为RTMP协议的流媒体数据的监听对应端口为1935端口。
具体说明如下：对应RTSP时，当前的系统通过监听554端口来提供RTSP的服务，这里假定设备的ip地址为192.168.1.100，而在客户端可以通过软件VLC并且打开URL：rtsp://192.168.1.100:554/live/mainstream，具体实际的需要根据实际设备的ip地址来确定URL。
而对应RTMP时，当前的系统通过监听1935端口来提供RTMP的服务，这里假定设备的ip地址为服务器端的ip即192.168.1.6(当然可以通过web进行服务器端推流地址的配置),当前的音视频流推送到服务器端的URL地址：rtmp://192.168.1.6:1935/live/mainstream，而在客户端可以通过软件VLC并且打开URL：rtmp://192.168.1.6:1935/live/mainstream，与设备地址192.168.1.100是不一样的，这样的好处是，对此音视频感兴趣的客户端可以去服务器端去拉流，而不是从设备这边拉流，这样会对网络带宽会有很好的平衡作用。
在本实施例的其中一种实施方式中，如图8所示，还包括：
混合模块5，用于混合源视频数据和源音频数据，形成HDMI格式的音视频数据；
解析模块6，用于解析音视频数据，获得视频数据。
通过上述技术方案，混合模块5将源视频数据和源音频数据，形成HDMI格式的音视频数据，使得可以选择PC，或者具有HDMI输出接口的音视频设备作为信号源的输入设备。
在本实施例的其中一种实施方式中，解析模块6还用于解析音视频数据，获得音频数据；
转化模块1还用于将音频数据转化为I2S信号；
转码模块2还用于将I2S信号转码为AAC格式的音频数据流；
其中，打包模块3用于将视频数据流和音频数据流打包成流媒体数据。
通过上述方案，转化模块1将音频数据转化为I2S信号，通过I2S的硬件接口输出给转码模块2，而转码模块2将接收到的I2S信号转码为AAC格式的音频数据流，打包模块3随之将视频数据流和音频数据流打包成可供网络传播的流媒体数据，发送模块4通过网络接口发送到网络的服务端或者客户端，从而实现将音视频数据IP化的目的。
在实际运用中I2S信号直接通过硬件中的三个直连的GPIO：I2S0_SCK、I2S0_LRCK和I2S0_SDI进入到dummy_codec,然后通过DMA(DirectMemoryAccess，直接存储器访问)进入到CPU处理，最后对用户层暴露可以取流的接口/dev/pcmC0D0c，至此用户层可以通过/dev/pcmC0D0c来取到FPGA发送过来的音频数据。
类似的，获取单元25使得上层应用可以在对应的配置文件中的预设配置下，获取到不同格式和/或参数的音频数据，提高音频数据的适用度。
具体的，音频数据的取流过程也可以在配置文件中对应相应的配置，例如音频从数据源接口default，即接口/dev/pcmC0D0c取到音频数据，音频的通道为双通道，采样率为48KHz，并且以PCM或PCM_FLTP的格式提供给上层的应用mediaserver，后续将PCM或PCM_FLTP格式的音频数据再转码为AAC格式的音频数据流。
本实施例还公开了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现如上述任一项视频数据IP化方法的步骤。
本申请实施例所涉及的计算机可读存储介质包括随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种视频数据IP化方法，其特征在于，包括以下步骤：
将视频数据转化为BT1120信号；
将所述BT1120信号转码为H264或H265格式的视频数据流；
将所述视频数据流打包成流媒体数据；
将所述流媒体数据发送至网络。
2.根据权利要求1所述的视频数据IP化方法，其特征在于，所述将所述BT1120信号转码为H264或H265格式的视频数据流具体为：
处理所述BT1120信号，形成底层视频流；
将所述底层视频流转换成预设格式的视频数据；
将所述视频数据转码为H264或H265格式的所述视频数据流；
其中所述预设格式包括分辨率大小和缩放倍数。
3.根据权利要求2所述的视频数据IP化方法，其特征在于，在所述将所述底层视频流转换成预设格式的视频数据之后，还包括：
将所述视频数据按照不同的预设格式分别通过对应的接口输出，形成设备文件暴露给上层应用；
上层应用通过输入输出控制打开所述设备文件，获取所述视频数据。
4.根据权利要求3所述的视频数据IP化方法，其特征在于，在所述上层应用通过输入输出控制打开所述设备文件，获取所述视频数据之后，还包括：
对所述视频数据按照目的格式进行对应处理；
其中，所述对应处理包括分辨率调整、视频裁剪、视频翻转中的至少一种。
5.根据权利要求3所述的视频数据IP化方法，其特征在于，所述上层应用通过输入输出控制打开所述设备文件，获取所述视频数据具体为：
所述上层应用通过输入输出控制打开所述设备文件；
依据配置文件的预设配置，获取所述视频数据。
6.根据权利要求1所述的IP化方法，其特征在于，所述流媒体数据的协议格式为RTSP和RTMP中的至少一种。
7.根据权利要求1所述的视频数据IP化方法，其特征在于，在所述将视频数据转化为BT1120信号之前，还包括：
混合源视频数据和源音频数据，形成HDMI格式的音视频数据；
解析所述音视频数据，获得所述视频数据。
8.根据权利要求7所述的视频数据IP化方法，其特征在于，还包括如下步骤：
解析所述音视频数据，获得所述音频数据；
将音频数据转化为I2S信号；
将所述I2S信号转码为AAC格式的音频数据流；
其中，所述将所述视频数据流打包成流媒体数据具体为，将所述视频数据流和所述音频数据流打包成流媒体数据。
9.一种视频数据IP化系统，其特征在于，包括：
转化模块，用于将视频数据转化为BT1120信号；
转码模块，用于将所述BT1120信号转码为H264或H265格式的视频数据流；
打包模块，用于将所述视频数据流打包成流媒体数据；
发送模块，用于将所述流媒体数据发送至网络。
10.根据权利要求9所述的视频数据IP化系统，其特征在于，所述转码模块包括：
处理单元，用于处理所述BT1120信号，形成底层视频流；
转换单元，用于将所述底层视频流转换成预设格式的视频数据；
转码单元，用于将所述视频数据转码为H264或H265格式的所述视频数据流；
其中所述预设格式包括分辨率大小和缩放倍数。
CN202110976219.5A 2021-08-24 2021-08-24 一种视频数据ip化方法及系统 Pending CN113691832A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110976219.5A CN113691832A (zh) 2021-08-24 2021-08-24 一种视频数据ip化方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110976219.5A CN113691832A (zh) 2021-08-24 2021-08-24 一种视频数据ip化方法及系统

Publications (1)

Publication Number Publication Date
CN113691832A true CN113691832A (zh) 2021-11-23

Family

ID=78582023

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110976219.5A Pending CN113691832A (zh) 2021-08-24 2021-08-24 一种视频数据ip化方法及系统

Country Status (1)

Country Link
CN (1) CN113691832A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106791931A (zh) * 2017-01-05 2017-05-31 上海浦东软件园汇智软件发展有限公司 一种数据流转码的方法及设备
CN106790226A (zh) * 2017-01-15 2017-05-31 刘小艳 一种便携移动式音视频教学交互设备
CN206212193U (zh) * 2016-10-24 2017-05-31 常州海图电子科技有限公司 基于h265的hdmi编码器
CN109412979A (zh) * 2018-11-16 2019-03-01 广东电网有限责任公司 一种多媒体信号的传输方法、传输系统及相关装置
JP2019201309A (ja) * 2018-05-16 2019-11-21 日本電気株式会社 Ｉｐビデオルータ、放送局システム、ｉｐビデオ転送方法及びプログラム
CN111316224A (zh) * 2018-03-19 2020-06-19 广州视源电子科技股份有限公司 数据传输装置以及数据传输方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN206212193U (zh) * 2016-10-24 2017-05-31 常州海图电子科技有限公司 基于h265的hdmi编码器
CN106791931A (zh) * 2017-01-05 2017-05-31 上海浦东软件园汇智软件发展有限公司 一种数据流转码的方法及设备
CN106790226A (zh) * 2017-01-15 2017-05-31 刘小艳 一种便携移动式音视频教学交互设备
CN111316224A (zh) * 2018-03-19 2020-06-19 广州视源电子科技股份有限公司 数据传输装置以及数据传输方法
JP2019201309A (ja) * 2018-05-16 2019-11-21 日本電気株式会社 Ｉｐビデオルータ、放送局システム、ｉｐビデオ転送方法及びプログラム
CN109412979A (zh) * 2018-11-16 2019-03-01 广东电网有限责任公司 一种多媒体信号的传输方法、传输系统及相关装置

Similar Documents

Publication Publication Date Title
TWI565310B (zh) 無線通訊系統中的視訊流送
US6278478B1 (en) End-to-end network encoding architecture
JP6219310B2 (ja) ワイヤレスディスプレイのためのユーザ入力バックチャネルを介した双方向トンネリング
CN111212258B (zh) 使用互联网协议的外围总线视频通信
KR102301333B1 (ko) 브로드캐스트 채널을 통한 ｄａｓｈ 콘텐츠 스트리밍 방법 및 장치
CN110022297B (zh) 一种高清视频直播系统
WO2015134649A1 (en) Systems and methods for media format substitution
WO2014139423A1 (en) Live system, method based on mobile terminal and mobile terminal
US20210297468A1 (en) Technologies for end of frame detection in streaming content
CN105577819A (zh) 一种虚拟化桌面的分享系统、分享方法以及分享装置
CN107197139B (zh) 全景相机的数据处理方法
US20150341634A1 (en) Method, apparatus and system to select audio-video data for streaming
KR20140126827A (ko) Dvb 시스템에서 mmt를 이용하여 방송 서비스를 송수신하는 방법 및 장치
CN107276990B (zh) 一种流媒体直播方法及装置
WO2023160361A1 (zh) Rtc数据的处理方法以及装置
CN111711870B (zh) 一种跨网络边界的实时流传输方法
WO2024022317A1 (zh) 视频流的处理方法及装置、存储介质、电子设备
CN104244085B (zh) 基于现场可编程门阵列的多媒体数据传输方法及装置
CN113691832A (zh) 一种视频数据ip化方法及系统
CN115396621A (zh) 一种基于rk628d的网络推流控制方法、装置、设备及存储介质
CN114501091B (zh) 远程驾驶画面的生成方法、装置及电子设备
CN115134664A (zh) 实时视频流的播放方法及系统、非易失性存储介质
JP6404915B2 (ja) データの自動圧縮
WO2023029689A1 (zh) 多媒体数据的共享方法、媒体共享服务器、终端、电子设备和计算机可读存储介质
KR20170059504A (ko) 클라우드 컴퓨팅을 이용한 멀티미디어 컨텐츠 인코딩 및 트랜스코딩 방법, 이를 위한 시스템 및 장치

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination