CN113949696B - 资源分发方法、电子设备及计算机可读存储介质 - Google Patents
资源分发方法、电子设备及计算机可读存储介质 Download PDFInfo
- Publication number
- CN113949696B CN113949696B CN202111012044.2A CN202111012044A CN113949696B CN 113949696 B CN113949696 B CN 113949696B CN 202111012044 A CN202111012044 A CN 202111012044A CN 113949696 B CN113949696 B CN 113949696B
- Authority
- CN
- China
- Prior art keywords
- data stream
- stream
- request
- transcoded
- coding format
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 238000004891 communication Methods 0.000 claims abstract description 5
- 238000011144 upstream manufacturing Methods 0.000 claims description 56
- 238000004590 computer program Methods 0.000 claims description 5
- 230000001960 triggered effect Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 238000004806 packaging method and process Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
- G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
- G10L19/16—Vocoder architecture
- G10L19/173—Transcoding, i.e. converting between two coded representations avoiding cascaded coding-decoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- 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/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
-
- 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 or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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 or manipulating encoded video stream 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/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
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computational Linguistics (AREA)
- Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- Acoustics & Sound (AREA)
- Computer Networks & Wireless Communication (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
本发明实施例涉及通信技术领域，公开了一种资源分发方法、电子设备及计算机可读存储介质。本发明的部分实施例中，资源分发方法应用于内容分发网络CDN节点，包括：获取客户端的第一拉流请求；根据第一拉流请求，若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，触发对应的数据流的转码任务，以调用转码中心将对应的数据流的编码格式转化为第一拉流请求支持的编码格式，转码后的数据流被存储在CDN节点；保存转码后的数据流，并将转码后的数据流分发至客户端。本申请实施例提供的技术方案可以减少转码消耗。
Description
技术领域
本发明实施例涉及通信技术领域，特别涉及一种资源分发方法、电子设备及计算机可读存储介质。
背景技术
随着网页实时通信(Web Real-Time Communication，WEBRTC)协议越来越流行，越来越多的厂商开始关注CDN结合WEBRTC来进行直播内容的分发。而WEBRTC的音频编码采用的是OPUS编码，CDN的音频编码采用的是AAC编码。因此，将CDN和WEBRTC结合势必要进行音频转码操作，将AAC转OPUS，或者，OPUS转AAC，才可以将WEBRTC与传统直播相结合，进行大规模内容分发，包括RTMP转WEBRTC，WEBRTC转RTMP，HTTP-FLV转WEBRTC，WEBRTC转HTTP-FLV等等。而多路音频转码会给服务器带来巨大的资源消耗。
发明内容
本发明实施方式的目的在于提供一种资源分发方法、电子设备及计算机可读存储介质，可以减少转码消耗。
为解决上述技术问题，第一方面，本发明实施例提供了一种资源分发方法应用于内容分发网络CDN节点，包括：获取客户端的第一拉流请求；根据第一拉流请求，若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，触发对应的数据流的转码任务，以调用转码中心将对应的数据流的编码格式转化为第一拉流请求支持的编码格式，转码后的数据流被存储在CDN节点；保存转码后的数据流，并将转码后的数据流分发至客户端。
第二方面，本发明实施例提供了一种电子设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述实施例提及的资源分发方法。
第三方面，本发明实施例提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，实现上述实施例提及的资源分发方法。
本发明实施例提供的资源分发方法、电子设备及计算机可读存储介质，CDN节点在接收到拉流请求后，在拉流请求对应的编码格式与拉流请求对应的数据流的编码格式不同的情况下，触发转码任务，由转码中心对数据流进行转码并保存转码后的数据流，使得后续接收到该数据流的拉流请求时，可通过获取转码中心转码后的数据流响应拉流请求，减少了对相同数据流的转码消耗。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。
图1是本申请实施例中资源分发方法的流程图；
图2是本申请的另一实施例中的资源分发方法的流程图；
图3是本申请的又一实施例中的资源分发方法的流程图；
图4是本申请的一实施例中的客户端、边缘节点、上游节点和转码中心的交互示意图；
图5是本申请的一实施例中的资源分发装置的示意图；
图6是本申请实施例中电子设备的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
在本发明公开的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明公开的描述中，除非另有说明，“多个”的含义是两个或两个以上。
本申请实施例提供的如图1所示的资源分发方法，应用于CDN节点，包括如下步骤。
步骤101：获取客户端的第一拉流请求。
步骤102：根据第一拉流请求，若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，触发对应的数据流的转码任务，以调用转码中心将对应的数据流的编码格式转化为第一拉流请求支持的编码格式，转码后的数据流被存储在CDN节点。
步骤103：保存转码后的数据流，并将转码后的数据流分发至客户端。
本申请实施例中，CDN节点在接收到拉流请求后，在拉流请求所支持的编码格式与拉流请求对应的数据流的编码格式不同的情况下，触发转码任务，由转码中心对数据流进行转码并保存转码后的数据流，使得后续接收到该数据流的拉流请求时，可通过获取转码中心转码后的数据流响应拉流请求，减少了对相同数据流的转码消耗。
例如，资源分发方法如图2所示，包括如下步骤。
步骤201：获取客户端的第一拉流请求。
步骤202：根据第一拉流请求，判断第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式是否相同。若确定不是，执行步骤203，若确定是，执行步骤205。
步骤203：触发对应的数据流的转码任务，以调用转码中心将对应的数据流转化为第一拉流请求支持的编码格式的数据流，转码后的数据流被存储在CDN节点。
步骤204：保存转码后的数据流，并将转码后的数据流分发至客户端。之后结束流程。
步骤205：将对应的数据流分发至客户端。
由上述分析可知，客户端拉流时，若数据流的编码格式和客户端请求的编码格式相同，则将数据流直接下发至客户端，若编码格式不同，则触发转码任务，在接收到转码中心发送的转码后的数据流后，将转码后的数据流下发至客户端。将转码后的数据流进行保存，当再次拉取该编码格式的数据流时，可以直接将该转码后的数据流下发至客户端，可通过获取转码中心转码后的数据流响应拉流请求，省去了再次转码带来的转码开销。
在一个实施例中，触发对应的数据流的转码任务，包括：将对应的数据流的流地址和转码后的数据流的流地址发送至转码中心，以使转码中心从对应的数据流的流地址拉取对应的数据流，并将转码后的数据流推流至转码后的数据流的流地址。
具体地，CDN节点触发转码后，将需要进行转码的数据流的储存地址以及转码后的数据流的流地址组装后发送给转码中心。转码中心收到转码请求后，拉取数据流的流地址中的数据流，对数据流进行转码，并将转码后的数据流推流至转码后的数据流的流地址。
需要说明的是，本领域技术人员可以理解，CDN节点也可以直接将需要转码的数据流发送给转码中心，本实施例不限制CDN节点和转码中心之间交互数据流的具体方式。
可选择的，在将对应的数据流的流地址和转码后的数据流的流地址发送至转码中心之前，资源分发方法还包括：改写对应的数据流的流名，得到转码后的数据流的流名，以使改写后的流名指示数据流的编码格式为第一拉流请求支持的编码格式。
可选择的，在改写对应的数据流的流名之后，资源分发方法还包括：将转码后的数据流的流名和转码后的数据流的编码格式，与转码后的数据流的流地址关联。例如，CDN节点包括边缘节点和上游节点，上游节点中存储有映射表。映射表中存储有各个数据流的流名、编码格式的信息和数据流的流地址。通过数据流的流地址可找到数据流的缓存数据。当边缘节点来拉流时，根据映射表、拉流请求所携带的数据流的流名，以及拉流请求支持的编码格式，判断本地是否存在相同的流缓存，有若确定有，则从缓存中取出与该拉流请求对应的数据流发送给边缘节点，若确定没有，则向转码中心发起转码请求。
可选择的，转码后的数据流的流名的包括：对应的数据流的流名和转码后的数据流的编码格式。作为一种选择，转码后的数据流的流名的为：对应的数据流的流名_转码后的数据流的编码格式。例如，若第一拉流请求支持的编码格式为OPUS格式，对应的数据流的流名为livestream，则转码后的数据流的流名为livestream_opus，以便表明转码后的数据流的编码格式。
值得一提的是，通过流名标识转码后的数据流，使得CDN节点能够更直接地判断数据流的编码格式，提高了CDN节点的判断速度，进而提高了效率。
需要说明的是，本领域技术人员可以理解，还可以通过其他方式标识转码后的数据流，本实施例不做限制。
在一个实施例中，CDN节点包括边缘节点和上游节点；根据第一拉流请求，若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，触发对应的数据流的转码任务，包括：边缘节点根据第一拉流请求的协议类型，确定第一拉流请求支持的编码格式；根据第一拉流请求支持的编码格式，生成第二拉流请求，发送第二拉流请求至上游节点；上游节点根据第二拉流请求，确定第一拉流请求支持的编码格式；若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，触发对应的数据流的转码任务。
值得一提的是，由上游节点判断数据流的编码格式与拉流请求支持的编码格式是否相同，并在数据流的编码格式与拉流请求支持的编码格式不同的情况下，触发转码任务，减少了边缘节点的转码消耗。
需要说明的是，上游节点可以是源站，也可以是源站和边缘节点之间的CDN节点，本实施例不限制上游节点的具体类型。
在一个实施例中，第一拉流请求的协议类型为WEBRTC协议，第一拉流请求支持的编码格式包括音频编码格式，第一拉流请求支持的音频编码格式为OPUS格式。
具体地，WEBRTC协议的音频编码是OPUS格式。而CDN节点的音频格式一般为AAC格式。因此，当客户端采用WEBRTC协议拉流时，边缘节点向上游节点请求对应的数据流，上游节点若确定数据流的音频格式不是OPUS格式，则触发转码任务，将数据流发送至转码中心，对数据流进行转码。
需要说明的是，本领域技术人员可以理解，当客户端采用其他协议拉流时，第一拉流请求支持的音频编码格式和/或视频编码格式也可以是其他格式，例如，视频编码格式还可以是H265、H266等，本实施例不做限制。
可选择的，第二拉流请求为HTTP-FLV协议，HTTP-FLV协议的扩展字段被用于指示音频编码格式为OPUS格式。
具体地，客户端采用WEBRTC协议向边缘节点拉流，边缘节点采用HTTP-FLV协议向上游节点拉流。而HTTP-FLV协议标准不支持OPUS格式，本实施例中，对HTTP-FLV协议进行扩展，以支持OPUS格式。例如，可以扩展音频标识(ID)，新增一个0x0D[13]，用于表示OPUS。即当音频标识等于13，表示音频编码格式为OPUS格式。第二拉流请求中会携带音频编码参数(如audio)，用于指示需要的音频格式为OPUS格式，如audio＝opus，用于告知上游节点本次拉流请求需要的音频格式为OPUS格式。因此，上游节点接收第二拉流请求，若第二拉流请求有携带音频编码参数audio＝opus，则触发转码任务。
可选择的，将转码后的数据流分发至客户端，包括：上游节点将转码后的数据流发送给边缘节点；边缘节点若确定接收到的转码后的数据流的音频编码格式为OPUS格式，采用WEBRTC协议分发转码后的数据流。
具体地，上游节点将转码后的数据流通过HTTP-FLV协议发送给边缘节点。同时，上游节点会对转码后的数据流进行缓存，后续拉取该数据流的拉流请求都不会触发转码，直接给出转码后的数据流。边缘节点接收到上游节点发送的转码后的数据流后，判断接收到的数据流的音频格式是否为OPUS格式；若确定是，则采用WEBRTC协议将转码后的数据流分发给客户端；若确定不是，则不采用WEBRTC协议将转码后的数据流分发给客户端。
需要说明的是，本领域技术人员可以理解，边缘节点在确定转码后的数据流的音频编码格式不是OPUS格式后，可以反馈指示信息至客户端，表示拉流失败，也可以再次向上游节点发起拉流请求。本实施例不限制边缘节点在确定转码后的数据流的音频编码格式不是OPUS格式后采取的措施。
可选择的，转码中心的转码过程包括：将对应的数据流的音频由原始编码格式转码为OPUS格式；复制对应的数据流的视频；将复制的视频与转码后的音频作为转码后的数据流，发送给上游节点。具体地，上游节点在触发转码任务后，发送转码请求至转码中心。转码中心收到上游节点的转码请求后，从对应的数据流的流地址中拉取数据流的音视频数据，对数据流中的视频的处理方式是：复制(COPY)方式，对数据流中的音频采用的处理方式是：将原始音频的编码格式(如AAC格式)转码为标准OPUS格式，即音频的采样率为48000，声道为双声道，20ms一帧。转码中心将转码后的OPUS格式的音频打包到FLV封装层，采用的是上面的FLV扩展OPUS方式进行打包。HTTP-FLV协议中原来的AAC的序列头部(SEQUENCEHEADER)采用标准的OPUS头，使用HTTP-FLV协议或者RTMP协议推流到上游节点发送的转码后的数据流的流地址上。
以上各实施例可以相互结合相互引用，例如下面是各实施例结合后的例子，然并不以此为限；各实施例在不矛盾的前提下可以任意结合成为一个新的实施例。
在一个实施例中，如图3所示为CDN节点执行的资源分发方法，CDN节点包括边缘节点和上游节点，包括如下步骤。
步骤301：边缘节点获取客户端的第一拉流请求。
步骤302：边缘节点根据第一拉流请求的协议类型，确定第一拉流请求支持的编码格式；根据第一拉流请求支持的编码格式，生成第二拉流请求，发送第二拉流请求至上游节点。
步骤303：上游节点根据第二拉流请求，确定第一拉流请求支持的编码格式；若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，将对应的数据流的流地址和转码后的数据流的流地址发送至转码中心，以使转码中心从对应的数据流的流地址拉取对应的数据流，并将转码后的数据流推流至转码后的数据流的流地址。
可选择的，在将对应的数据流的流地址和转码后的数据流的流地址发送至转码中心之前，资源分发方法还包括：改写对应的数据流的流名，得到转码后的数据流的流名，以使改写后的流名指示数据流的编码格式为第一拉流请求第一拉流请求支持的编码格式。
可选择的，第一拉流请求的协议类型为WEBRTC协议，第一拉流请求支持的编码格式包括音频编码格式，第一拉流请求支持的音频编码格式为OPUS格式。
可选择的，第二拉流请求为HTTP-FLV协议，HTTP-FLV协议的扩展字段被用于指示音频编码格式为OPUS格式。
可选择的，转码中心的转码过程包括：将对应的数据流的音频由原始编码格式转码为OPUS格式；复制对应的数据流的视频；将复制的视频与转码后的音频作为转码后的数据流，发送给上游节点。
步骤304：上游节点将转码后的数据流发送给边缘节点。
步骤305：边缘节点若确定接收到的转码后的数据流的音频编码格式为OPUS格式，采用WEBRTC协议分发转码后的数据流。
例如，针对WEBRTC协议拉流场景，WEBRTC协议与CDN相结合。客户端采用RTMP或HTTP-FLV协议推流，推送的原始流的视频采用H264格式，音频采用AAC格式，从边缘节点推流到CDN的上游节点，进行全网分发。采用WEBRTC协议从边缘节点拉流时，边缘节点回上游节点拉流，上游节点进行流信息判断，如果需要OPUS音频格式，则会触发中心转码，将对应的转码请求发送到转码中心进行音频转码，将音频格式从AAC格式转为OPUS格式，然后采用HTTP-FLV或者RTMP协议将转码后的FLV数据推送到上游节点，上游节点会进行流信息关联，后续接收到该原始流的拉流请求时，上游节点直接给出转码后的FLV数据，从而减少了后续拉流请求的转码消耗。
具体地，客户端、边缘节点、上游节点和转码中心的交互示意图如图4所示，当客户端拉流时，客户端31、边缘节点32,、上游节点33和转码中心34之间的交互过程包括：
步骤401：客户端采用WEBRTC协议拉流，第一拉流请求被发送到边缘节点。
步骤402：边缘节点采用HTTP-FLV协议，向上游节点请求拉流数据。即第二拉流请求被发送至上游节点以请求拉流数据。
具体地，由于WEBRTC标准只支持OPUS音频编码，而HTTP-FLV协议不支持OPUS格式，故需要扩展HTTP-FLV以支持OPUS，例如，扩展音频ID，新增一个0x0D[13]用于表示OPUS，即在HTTP-FLV协议中扩展，赋予音频ID中的13＝opus，对于OPUS数据包类型，0表示OPUS头格式，1表示OPUS裸数据。
步骤403：上游节点收到第二拉流请求，触发音频转码。具体地，由于第二拉流请求有携带音频编码参数audio＝opus，而数据流的音频格式为AAC格式，故进行流名改写，触发音频转码。
具体地，上游节点将原来的流名改写为新的流名，如原始流名为livestream，则改写流名为livestream_opus，然后触发音频转码，将需要进行转码的数据流的流地址以及转码后的数据流的流地址组装后发送给转码中心。
步骤404：转码中心收到音频转码请求后，从需要进行转码的数据流的流地址拉取音视频数据；转码中心对视频采用COPY方式，将音频从AAC格式转码为标准OPUS格式；将OPUS格式的音频数据打包到FLV封装层，使用HTTP-FLV协议或者RTMP协议推流到上游节点的转码后的数据流的流地址上。具体地，转码中心采用上面的FLV扩展OPUS方式进行打包，FLV格式中的OPUS SEQUENCE HEADER采用标准的OPUS头。
步骤405：上游节点将转码后的OPUS音频以及原始的视频通过HTTP-FLV协议发送给边缘节点，同时会对转码后的数据流进行缓存。后续上游节点再接收到该数据流的拉流请求不会触发转码，直接给出转码后的数据流的数据。
步骤406：边缘节点收到上游节点反馈的数据流，若确定对应的音视频头部指示音频格式为OPUS格式，采用WEBRTC协议分发数据流。具体地，将读取到的FLV按标签(TAG)进行拆分，提取其中的视频数据和音频数据。视频采用90000作为时间基进行RTP打包，时间戳间隔为90000/视频帧率。音频采用48000作为时间基进行RTP打包，时间戳间隔为48000*20/1000＝960。然后将RTP包分发送给客户端，客户端解包后即可播放音视频。
本实施例中，中心转码省去了对相同流，每个客户端来拉流时都需要进行转码的消耗。具体地，上游节点和转码中心构成的中心***维护相同流的转码后的数据流的信息，当第一个客户端来拉流时，会触发音频转码，该客户端及其他客户端来拉相同的流时，边缘节点会带audio＝opus给上游节点，上游节点判断是否需要转码，若不需要(即AAC格式的音频转码为OPUS格式后被存储在上游节点)，直接给转码后的数据流的音视频数据，从而减少了边缘节点的转码消耗。
需要说明的是，本领域技术人员可以理解，上游节点也可以支持客户端推送OPUS格式的音频数据，即客户端从边缘节点推流到上游节点，推送的数据流的视频格式可例如为H264格式、H265格式或H266格式，音频格式可例如为OPUS格式。客户端从边缘节点拉流时，边缘节点同样会将需要的音频格式携带到参数传递给上游节点，如audio＝opus，上游节点判断该路流原始音频编码格式是OPUS格式，则无需触发音频转码，直接下发原始流的音视频数据给边缘节点，边缘节点收到音视频数据后，通过音视频头部判断音视频编码格式，将收到的音视频数据通过RTP协议进行打包，分发给客户进行WEBRTC拉流观看，从而省去了音频转码的开销，显著降低资源消耗，提升服务并发质量。例如，实验中，每个连接都进行音频转码时，并发请求只到500，使用中心转码后，并发请求提升到2500。
上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。
本申请实施例还提供一种资源分发装置，如图5所示，包括：获取模块501，用于获取客户端的第一拉流请求；转码模块502，用于根据第一拉流请求，若确定第一拉流请求支持的编码格式与第一拉流请求对应的数据流的编码格式不同，触发对应的数据流的转码任务，以调用转码中心将对应的数据流转化为第一拉流请求支持的编码格式的数据流，转码后的数据流被存储在CDN节点；分发模块503，用于保存转码后的数据流，并将转码后的数据流分发至客户端。
不难发现，本实施例为与上述方法实施例相对应的***实施方式，本实施例可与上述方法实施例互相配合实施。上述方法实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在上述方法实施例中。
值得一提的是，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施例中不存在其它的单元。
本申请实施例还提供一种电子设备，如图6所示，包括：至少一个处理器601；以及与至少一个处理器601通信连接的存储器602；其中，存储器存储有可被至少一个处理器601执行的指令，指令被至少一个处理器601执行，以使至少一个处理器601能够执行上述方法实施例。
其中，存储器602和处理器601采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器601和存储器602的各种电路连接在一起。总线还可以将诸如***设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器601处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器601。
处理器601负责管理总线和通常的处理，还可以提供各种功能，包括定时，***接口，电压调节、电源管理以及其他控制功能。而存储器602可以被用于存储处理器601在执行操作时所使用的数据。
本申请实施例还提供一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。
Claims (8)
1.一种资源分发方法，其特征在于，应用于内容分发网络CDN节点，所述CDN节点包括边缘节点和上游节点，包括：
获取客户端的第一拉流请求；
根据所述第一拉流请求，若确定所述第一拉流请求支持的编码格式与所述第一拉流请求对应的数据流的编码格式不同，触发所述对应的数据流的转码任务，以调用转码中心将所述对应的数据流的编码格式转化为所述第一拉流请求支持的编码格式，转码后的数据流被存储在所述CDN节点；
保存所述转码后的数据流，并将所述转码后的数据流分发至所述客户端；
其中，所述根据所述第一拉流请求，若确定所述第一拉流请求支持的编码格式与所述第一拉流请求对应的数据流的编码格式不同，触发所述对应的数据流的转码任务，包括：
所述边缘节点根据所述第一拉流请求的协议类型，确定所述第一拉流请求支持的编码格式；根据所述第一拉流请求支持的编码格式，生成第二拉流请求，发送所述第二拉流请求至所述上游节点；
所述上游节点根据所述第二拉流请求，确定所述第一拉流请求支持的编码格式；若确定所述第一拉流请求支持的编码格式与所述第一拉流请求对应的数据流的编码格式不同，触发所述对应的数据流的转码任务；
所述第一拉流请求的协议类型为网页实时通信WEBRTC协议，所述第一拉流请求支持的编码格式包括音频编码格式，所述第一拉流请求支持的音频编码格式为OPUS格式；
所述第二拉流请求为HTTP-FLV协议，所述HTTP-FLV协议的扩展字段被用于指示音频编码格式为OPUS格式。
2.根据权利要求1所述的资源分发方法，其特征在于，所述触发所述对应的数据流的转码任务，包括：
将所述对应的数据流的流地址和所述转码后的数据流的流地址发送至所述转码中心，以使所述转码中心从所述对应的数据流的流地址拉取所述对应的数据流，并将所述转码后的数据流推流至所述转码后的数据流的流地址。
3.根据权利要求2所述的资源分发方法，其特征在于，在所述将所述对应的数据流的流地址和所述转码后的数据流的流地址发送至所述转码中心之前，所述资源分发方法还包括：
改写所述对应的数据流的流名，得到所述转码后的数据流的流名，以使改写后的流名指示数据流的编码格式为所请求的编码格式。
4.根据权利要求3所述的资源分发方法，其特征在于，在所述改写所述对应的数据流的流名之后，所述资源分发方法还包括：
将所述转码后的数据流的流名和所述转码后的数据流的编码格式，与所述转码后的数据流的流地址关联。
5.根据权利要求3所述的资源分发方法，其特征在于，所述转码后的数据流的流名包括：所述对应的数据流的流名和所述转码后的数据流的编码格式。
6.根据权利要求1所述的资源分发方法，其特征在于，所述将所述转码后的数据流分发至所述客户端，包括：
所述上游节点将所述转码后的数据流发送给所述边缘节点；
所述边缘节点若确定接收到的所述转码后的数据流的音频编码格式为OPUS格式，采用WEBRTC协议分发所述转码后的数据流。
7.一种电子设备，其特征在于，包括：至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至6中任一项所述的资源分发方法。
8.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如权利要求1至6中任一项所述的资源分发方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111012044.2A CN113949696B (zh) | 2021-08-31 | 2021-08-31 | 资源分发方法、电子设备及计算机可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111012044.2A CN113949696B (zh) | 2021-08-31 | 2021-08-31 | 资源分发方法、电子设备及计算机可读存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113949696A CN113949696A (zh) | 2022-01-18 |
| CN113949696B true CN113949696B (zh) | 2023-10-20 |
Family
ID=79327768
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111012044.2A Active CN113949696B (zh) | 2021-08-31 | 2021-08-31 | 资源分发方法、电子设备及计算机可读存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113949696B (zh) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102263959A (zh) * | 2011-08-08 | 2011-11-30 | 中国电信股份有限公司 | 直播中转方法和*** |
| CN103686210A (zh) * | 2013-12-17 | 2014-03-26 | 广东威创视讯科技股份有限公司 | 实时音视频转码方法和*** |
| CN104349178A (zh) * | 2014-11-21 | 2015-02-11 | 赛特斯信息科技股份有限公司 | 实现按需实时转码和自适应码率流媒体播放的***及方法 |
| US9088634B1 (en) * | 2012-05-07 | 2015-07-21 | Amazon Technologies, Inc. | Dynamic media transcoding at network edge |
| CN109963169A (zh) * | 2019-04-04 | 2019-07-02 | 网宿科技股份有限公司 | 一种转码方法、服务器和计算机可读存储介质 |
| CN110858829A (zh) * | 2018-08-22 | 2020-03-03 | 杭州海康威视数字技术股份有限公司 | 视频处理方法、装置、***、分析服务器及转码服务器 |
| CN112995707A (zh) * | 2021-04-20 | 2021-06-18 | 北京小鸟科技股份有限公司 | 基于跨网络音视频转码调度的***、方法及设备 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8521899B2 (en) * | 2010-05-05 | 2013-08-27 | Intel Corporation | Multi-out media distribution system and method |
| US20210044640A1 (en) * | 2019-08-09 | 2021-02-11 | Guru Network Limited | Livestreaming interactive content to a digital media platform |
-
2021
- 2021-08-31 CN CN202111012044.2A patent/CN113949696B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102263959A (zh) * | 2011-08-08 | 2011-11-30 | 中国电信股份有限公司 | 直播中转方法和*** |
| US9088634B1 (en) * | 2012-05-07 | 2015-07-21 | Amazon Technologies, Inc. | Dynamic media transcoding at network edge |
| CN103686210A (zh) * | 2013-12-17 | 2014-03-26 | 广东威创视讯科技股份有限公司 | 实时音视频转码方法和*** |
| CN104349178A (zh) * | 2014-11-21 | 2015-02-11 | 赛特斯信息科技股份有限公司 | 实现按需实时转码和自适应码率流媒体播放的***及方法 |
| CN110858829A (zh) * | 2018-08-22 | 2020-03-03 | 杭州海康威视数字技术股份有限公司 | 视频处理方法、装置、***、分析服务器及转码服务器 |
| CN109963169A (zh) * | 2019-04-04 | 2019-07-02 | 网宿科技股份有限公司 | 一种转码方法、服务器和计算机可读存储介质 |
| CN112995707A (zh) * | 2021-04-20 | 2021-06-18 | 北京小鸟科技股份有限公司 | 基于跨网络音视频转码调度的***、方法及设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113949696A (zh) | 2022-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11575961B2 (en) | Reception apparatus, transmission apparatus, and data processing method | |
| JP6981257B2 (ja) | 情報処理装置および情報処理方法 | |
| US8626870B2 (en) | Method and apparatus for generating and reproducing adaptive stream based on file format, and recording medium thereof | |
| US20200336526A1 (en) | Reception device, reception method, transmission device, and transmission method for distributing signaling information | |
| US10051026B2 (en) | Real-time transcode transfer method and system based on HTTP under DLNA | |
| WO2008061416A1 (fr) | Procédé et système permettant d'accepter des données media de divers formats de codage | |
| WO2011004886A1 (ja) | 配信システムと方法とゲートウェイ装置とプログラム | |
| US11778012B2 (en) | Adaptive bitrate streaming of live content | |
| JP2004529410A5 (zh) | ||
| CN107534793B (zh) | 接收装置、传输装置以及数据处理方法 | |
| US20150327025A1 (en) | Information processing apparatus and method, program, and content supply system | |
| CN105049931B (zh) | 对移动终端中非支持格式的视频进行转换的方法及*** | |
| WO2015109847A1 (zh) | 一种分段节目快速分发的方法、服务器及客户端 | |
| CN105451096A (zh) | 网络直播***及直播方法 | |
| CN113824925A (zh) | 一种web无插件视频监控***和方法 | |
| CN101640627B (zh) | 多媒体数据串流传输的***及其方法 | |
| CN101754024B (zh) | 一种复用装置及复用方法 | |
| CN113949696B (zh) | 资源分发方法、电子设备及计算机可读存储介质 | |
| KR102373195B1 (ko) | 수신 장치, 송신 장치, 데이터 통신 방법, 및 데이터 처리 방법 | |
| CN114363289B (zh) | 一种基于规则引擎的虚拟网络智能调度*** | |
| CN107534792B (zh) | 接收设备、发送设备以及数据处理方法 | |
| CN111200562B (zh) | 导流方法、静态父节点、边缘节点以及cdn网络 | |
| WO2023071468A1 (zh) | 直播方法、内容分发服务设备及存储介质 | |
| CN109219962B (zh) | 接收装置、接收方法、再现装置、再现方法、供应装置、供应方法以及程序 | |
| KR100954687B1 (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |