WO2023083143A1 - 入向码流码率获取方法、收流处理方法、电子设备、介质 - Google Patents

入向码流码率获取方法、收流处理方法、电子设备、介质 Download PDF

Info

Publication number
WO2023083143A1
WO2023083143A1 PCT/CN2022/130363 CN2022130363W WO2023083143A1 WO 2023083143 A1 WO2023083143 A1 WO 2023083143A1 CN 2022130363 W CN2022130363 W CN 2022130363W WO 2023083143 A1 WO2023083143 A1 WO 2023083143A1
Authority
WO
WIPO (PCT)
Prior art keywords
code rate
stream
incoming
code
time interval
Prior art date
Application number
PCT/CN2022/130363
Other languages
English (en)
French (fr)
Inventor
陈奇
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2023083143A1 publication Critical patent/WO2023083143A1/zh

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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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
    • 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/234381—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 altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/64—Addressing
    • H04N21/6405—Multicasting
    • 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/64—Addressing
    • H04N21/6408—Unicasting

Definitions

  • Embodiments of the present disclosure relate to the field of Internet technology.
  • IPTV Internet Protocol Television
  • IPTV Internet Protocol Television
  • packet loss recovery and buffer overflow are introduced between streaming media servers and terminals Mechanisms.
  • the mechanism for multicast packet loss recovery is forward error correction (FEC, Forward Error Correction)
  • the mechanism for unicast packet loss recovery is automatic request retransmission (ARQ, Automatic Repeat reQuest)
  • ARQ Automatic Repeat reQuest
  • unicast to avoid caching up and down
  • the overflow mechanism is flow control.
  • these mechanisms do not take into account the problem of packet errors in stream receiving and processing caused by changes in the code rate of the stream media server in the live broadcast business scenario.
  • Embodiments of the present disclosure provide a method for acquiring a code rate of an incoming code stream, a method for processing an incoming code stream, an electronic device, and a computer-readable storage medium.
  • an embodiment of the present disclosure provides a method for acquiring the code rate of an incoming code stream, the method including: calculating the average code rate corresponding to this time interval; The average bit rate corresponding to the time interval calculates the weight coefficient of this bit rate fluctuation; and determines the incoming bit stream bit rate and the next time interval according to the weight coefficient of this bit rate fluctuation, and presets the bit rate after the delay After the time interval, the step of calculating the average code rate corresponding to the next time interval is performed.
  • the embodiment of the present disclosure provides a stream receiving processing method, the method includes: calculating the maximum number of received packets corresponding to this task according to the code rate of the current incoming code stream, wherein the current incoming code stream The stream code rate adopts the current incoming code stream code rate determined by the above-mentioned incoming code stream code rate acquisition method; The packet of the task is received and processed.
  • an embodiment of the present disclosure provides an electronic device, which includes: at least one processor; and a memory, on which at least one program is stored, and when the at least one program is executed by at least one processor, the above-mentioned goal is realized A method for obtaining a code rate of a code stream, or implementing the above method for receiving and processing streams.
  • an embodiment of the present disclosure provides a computer-readable storage medium, on which a computer program is stored.
  • the computer program is executed by a processor, the above-mentioned method for obtaining the code rate of the incoming stream is implemented, or the above-mentioned Incoming stream processing method.
  • FIG. 1 is a schematic diagram of an architecture corresponding to a live broadcast service scenario according to an embodiment of the present disclosure
  • FIG. 2 is a schematic diagram of an architecture corresponding to a live broadcast service scenario according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram of an architecture corresponding to a live broadcast service scenario according to an embodiment of the present disclosure
  • FIG. 4 is a flowchart of a method for acquiring a code rate of an incoming code stream according to an embodiment of the present disclosure
  • FIG. 5 is a flow chart of a stream processing method according to an embodiment of the present disclosure.
  • Fig. 6 is a block diagram of a streaming media server according to an embodiment of the present disclosure.
  • the operation and maintenance personnel of the streaming media server need to input the bit rate of the incoming stream into the streaming server, and then the streaming server constructs the receiving stream information according to the bit rate of the incoming stream, and then the streaming server According to the flow receiving information, the packets in the incoming code stream are received and processed.
  • the incoming code rate used by the streaming media server to construct the incoming stream information will generally not change, but because the operation and maintenance personnel may enter the wrong code rate, the actual incoming code rate may also change.
  • there is a large gap between the bit rate of the incoming bit stream input by the operation and maintenance personnel and the actual bit rate of the incoming bit stream resulting in a decline in the quality of the live broadcast service.
  • Fig. 1 is a schematic diagram of an architecture corresponding to a live broadcast service scenario according to an embodiment of the present disclosure.
  • the incoming code stream is the incoming multicast code stream
  • the outgoing code stream is the outgoing multicast code stream.
  • Two or more terminals will send the incoming multicast code stream
  • the multicast switch sends the incoming multicast code stream to the streaming media server
  • the streaming media server receives the incoming multicast code stream, and performs receiving processing on the incoming multicast code stream to obtain the outgoing multicast code stream , sending the outbound multicast code stream to the multicast switch, and the multicast switch sends the outbound multicast code stream to two or more terminal two.
  • Fig. 2 is a schematic diagram of an architecture corresponding to a live broadcast service scenario according to an embodiment of the present disclosure.
  • the incoming code stream is the incoming unicast code stream
  • the outgoing code stream is the outgoing multicast code stream.
  • Terminal 3 sends the incoming unicast code stream to the streaming media server, and the stream
  • the media server receives the incoming unicast code stream, receives and processes the incoming unicast code stream to obtain the outgoing multicast code stream, and sends the outgoing multicast code stream to the multicast switch, and the multicast switch sends the outgoing multicast code stream to Give two or more terminals four.
  • Fig. 3 is a schematic diagram of an architecture corresponding to a live broadcast service scenario according to an embodiment of the present disclosure.
  • the incoming code stream is the incoming unicast code stream
  • the outgoing code stream is the outgoing unicast code stream.
  • Terminal 5 sends the incoming unicast code stream to the streaming media server.
  • the media server receives the incoming unicast code stream, performs receiving processing on the incoming unicast code stream to obtain the outgoing unicast code stream, and sends the outgoing unicast code stream to terminal six.
  • the incoming code stream can be the incoming multicast code stream, or the incoming unicast code stream, and the outgoing code stream can be the outgoing multicast code stream , can also be an outgoing unicast stream.
  • Fig. 4 is a flowchart of a method for acquiring a code rate of an incoming code stream according to an embodiment of the present disclosure.
  • the method for obtaining the code rate of an incoming code stream includes steps 400 to 402.
  • step 400 the average code rate corresponding to the current time interval t is calculated.
  • the average code rate cur_b corresponding to the current time interval t is calculated according to the total size recvlen of all packets received within the current time interval t and the current time interval t.
  • the average code rate cur_b corresponding to this time interval t is the ratio of the total size recvlen of all packets received within this time interval t to this time interval t, that is
  • the current time interval t can be initialized to t0.
  • step 401 the weight coefficient of the current code rate fluctuation is calculated according to the code rate of the last incoming code stream and the average code rate corresponding to the current time interval.
  • the bit rate of the last incoming bit stream can be initialized to the average bit rate corresponding to the first time interval.
  • calculating the weight coefficient of this bit rate fluctuation according to the bit rate of the last incoming bit stream and the average bit rate corresponding to this time interval includes: according to the formula Calculate the weight coefficient of this bit rate fluctuation, where flucoeff is the weight coefficient of this bit rate fluctuation, cur_b is the average bit rate corresponding to this time interval, and last_b is the last incoming bit stream bit rate.
  • step 402 determine the code rate of the incoming code stream and the next time interval according to the weight coefficient of the current code rate fluctuation, and perform the calculation of the average code rate corresponding to the next time interval after delaying the preset time interval step.
  • determining the code rate of the incoming code stream and the next time interval according to the weight coefficient of the current code rate fluctuation includes: when the weight coefficient of the current code rate fluctuation is less than a preset threshold, It shows that the current incoming code rate does not fluctuate much. Make sure that the incoming code rate is the same as the last incoming code rate, and make sure that the next time interval is the same as this time interval; If the weight coefficient of the fluctuation is greater than or equal to the preset threshold, it means that the bit rate of the current incoming bit stream fluctuates greatly. Determine the bit rate of the incoming bit stream this time and the average bit rate corresponding to this time interval. Determine the following A time interval is smaller than this time interval.
  • determining that the next time interval is shorter than the current time interval includes: determining the next time interval according to the current time interval and the weight coefficient of the current code rate fluctuation. For example, the formula Determine the next time interval, t next is the next time interval, t cur is the current time interval, and flucoeff is the weight coefficient of the current code rate fluctuation.
  • the preset threshold can be set according to actual conditions, for example, the preset threshold is set to 0.1.
  • the preset time can be 0, that is, the average code rate corresponding to the next time interval is directly calculated without delay, or it can be this time interval, or the next time interval, and each delay
  • the preset times can be the same or different.
  • the method for acquiring the code rate of the incoming code stream provided by the embodiments of the present disclosure performs adaptive evaluation on the code rate of the incoming code stream, and lays a foundation for subsequent stream receiving processing.
  • FIG. 5 is a flow chart of a method for processing incoming streams according to an embodiment of the present disclosure.
  • the stream processing method according to the embodiment of the present disclosure includes steps 500 and 501 .
  • step 500 calculate the maximum number of received packets corresponding to this task according to the code rate of the incoming code stream.
  • the code rate of the incoming code stream is determined by the above-mentioned code rate acquisition method Code stream code rate.
  • recvpktcnt is the maximum number of received packets corresponding to this task
  • recviter is the fixed receiving interval
  • b cur is the code rate of the incoming stream
  • pktlen is the rate of each packet Size
  • recvcoeff is a fixed reception coefficient
  • the calculation of the maximum number of received packets corresponding to this task according to the code rate of this incoming code stream includes at least one of the following: when it is determined that the code rate of this incoming code stream does not fluctuate, determine the The maximum number of received packets corresponding to the task is the same as the maximum number of received packets corresponding to the previous task; when it is determined that the bit rate of the incoming stream fluctuates this time, according to the formula Calculate the maximum number of received packets corresponding to this task, recvpktcnt is the maximum number of received packets corresponding to this task, recviter is the fixed receiving interval (that is, the time interval between the start times of two adjacent tasks), b cur is the code rate of the incoming stream, pktlen is the size
  • determining that there is no fluctuation in the code rate of the incoming code stream this time includes: the code rate of the incoming code stream this time is the same as the code rate of the last incoming code stream.
  • determining that the code rate of the incoming code stream fluctuates this time includes: the code rate of the incoming code stream this time is different from the code rate of the last incoming code stream.
  • step 501 according to the maximum number of received packets corresponding to the current task, the packets belonging to the current task in the incoming code stream are received and processed.
  • receiving and processing the packets belonging to this task in the incoming code stream includes: reading received packets from the kernel protocol stack sequentially to perform Receive flow processing until there is no readable packet in the kernel protocol stack, or until the number of packets read from the kernel protocol stack is greater than or equal to the maximum number of received packets corresponding to this task.
  • the packets in the incoming code stream after receiving the packets in the incoming code stream, they are first stored in the kernel protocol stack, and then the packets are sequentially read from the kernel protocol stack to perform streaming processing.
  • the stream receiving and processing method performs stream receiving and processing based on the adaptively evaluated incoming code rate, without requiring the operation and maintenance personnel to input the incoming code rate, and then according to the incoming code rate input by the operation and maintenance personnel.
  • the code rate of the code stream is constructed and received for stream processing, so that the matching degree between the adaptively evaluated incoming code rate and the actual incoming code rate is small, thereby improving the quality of live broadcast services.
  • flucoeff 1 is the weight coefficient of the first code rate fluctuation
  • b 1 is the average code rate corresponding to the first time interval
  • b 0 is the 0th incoming code stream code rate (initialized to b 1 ).
  • the secondary time interval t 2 is t 0 .
  • b 2 is the average code rate corresponding to the second time interval
  • recvlen 2 is the total size of all packets received in the second time interval
  • t 2 is the second time interval.
  • flucoeff 2 is the weight coefficient of the second code rate fluctuation
  • b 2 is the average code rate corresponding to the second time interval
  • b 0 is the first incoming stream code rate (which was determined as b 0 in the last calculation).
  • the weight coefficient flucoeff 2 of the second bit rate fluctuation is less than 0.1, it means that the current incoming code rate fluctuates little, and the second incoming bit rate is still b 0 , and the third time interval t 3 is still t 0 .
  • the weight coefficient flucoeff 2 of the second bit rate fluctuation is greater than or equal to the preset threshold (0.1), it means that the bit rate of the current incoming bit stream fluctuates greatly, and the bit rate of the second incoming bit stream is b 2 , the third time interval t 3 is
  • b 3 is the average code rate corresponding to the third time interval
  • recvlen 3 is the total size of all packets received in the third time interval
  • t 3 is the third time interval.
  • flucoeff 3 is the weight coefficient of the third code rate fluctuation
  • b 3 is the average code rate corresponding to the third time interval
  • b 2 is the code rate of the second incoming code stream (It was determined as the average code rate b 2 corresponding to the second time interval during the last calculation).
  • the weight coefficient flucoeff 3 of the third bit rate fluctuation is less than 0.1, it means that the current incoming code rate fluctuates little, and the third incoming bit rate is still b 2 , and the fourth time interval t 4 is still t 3 .
  • the weight coefficient flucoeff 3 of the third bit rate fluctuation is greater than or equal to 0.1, it means that the current incoming bit stream fluctuates greatly, the third incoming bit stream bit rate is b 3 , and the fourth time The interval t4 is
  • recvpktcnt 1 is the maximum number of received packets corresponding to this task
  • recviter is a fixed receiving interval
  • b 1 is the first time Incoming code rate
  • pktlen is the size of each packet
  • recvcoeff is a fixed receiving coefficient
  • Receive stream processing by sequentially reading received packets from the kernel protocol stack until there is no readable packet in the kernel protocol stack, or until the number of packets read from the kernel protocol stack is greater than or equal to the first entry The maximum number of received packets corresponding to this task corresponding to the code rate of the stream.
  • Receive stream processing by sequentially reading received packets from the kernel protocol stack until there is no readable packet in the kernel protocol stack, or until the number of packets read from the kernel protocol stack is greater than or equal to the second entry The maximum number of received packets corresponding to this task corresponding to the code rate of the stream.
  • the present disclosure provides an electronic device, the electronic device includes: at least one processor and a memory, at least one program is stored in the memory, and when the at least one program is executed by at least one processor, the above-mentioned method for acquiring the code rate of the incoming stream is realized , or implement the above stream processing method.
  • a processor is a device capable of data processing, including but not limited to a central processing unit (CPU) and the like.
  • Memory is a device with data storage capability, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH).
  • RAM random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • FLASH flash memory
  • the processor and the memory are connected to each other through a bus, and further connected to other components of the computing device.
  • the present disclosure provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above-mentioned method for obtaining the code rate of an incoming bit stream is realized, or the above-mentioned method for processing an inbound stream is realized.
  • Fig. 6 is a block diagram of a streaming media server according to an embodiment of the present disclosure.
  • the streaming media server includes: a code rate detection module 601 of an incoming code stream, a stream receiving module 602 and a stream sending module 603 .
  • the code rate detection module 601 of the incoming code stream is used to implement the above method for obtaining the code rate of the incoming code stream
  • the stream receiving module 602 is used to implement the above stream receiving and processing method
  • the stream sending module 603 is used to send the received and processed packets.
  • the incoming code rate detection module 601 may update the incoming code rate each time, or first determine whether the fluctuation of the current incoming code rate is large. If the fluctuation is not large, no update is required. Incoming code rate; if the fluctuation is large, update the incoming code rate.
  • the incoming code rate detection module 601 can send the incoming code rate obtained this time to the stream receiving module 602 every time it obtains the incoming code rate, or it can first determine the Whether the code rate of the incoming code stream obtained is the same as the code rate of the incoming code stream obtained last time, if the code rate of the incoming code stream obtained this time is not sent to the stream receiving module 602; Send the code rate of the incoming code stream obtained this time to the stream receiving module 602 .
  • the stream receiving module 602 When implementing, if the stream receiving module 602 does not receive a new incoming code rate, then calculate the maximum number of received packets corresponding to this task according to the incoming code rate received last time, according to the current The maximum number of received packets corresponding to the task is received and processed; if the received stream module 602 receives a new code rate of the incoming code stream, it calculates the maximum number of received packets corresponding to this task according to the new code rate of the incoming code stream, Stream receiving processing is performed according to the maximum number of received packets corresponding to this task.
  • the functional modules/units in the system, and the device can be implemented as software, firmware, hardware, and an appropriate combination thereof.
  • the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be composed of several physical components. Components cooperate to execute.
  • Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit .
  • Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • computer storage media includes both volatile and nonvolatile media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. permanent, removable and non-removable media.
  • Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, tape, magnetic disk storage or other magnetic storage, or can be used Any other medium that stores desired information and can be accessed by a computer.
  • communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

本公开提供了一种入向码流码率获取方法、收流处理方法、电子设备、计算机可读存储介质。该入向码流码率获取方法包括：计算与本次时间间隔对应的平均码率；根据上一次入向码流码率和与本次时间间隔对应的平均码率计算本次码率波动的权重系数；并根据本次码率波动的权重系数确定本次入向码流码率和下一次时间间隔，并在延迟预设时间间隔后，执行计算与下一次时间间隔对应的平均码率的步骤。

Description

入向码流码率获取方法、收流处理方法、电子设备、介质
相关申请的交叉引用
该专利申请要求于2021年11月12日在中国国家知识产权局提交的中国专利申请202111337644.6的优先权，该中国专利申请的公开以引用方式全文并入本文中。
技术领域
本公开实施例涉及互联网技术领域。
背景技术
随着网络协议电视(IPTV，Internet Protocol Television)的快速发展，特别是用户数的不断增长，为了给用户带来更好的体验，在流媒体服务器和终端间引入丢包恢复和避免缓存上下溢的机制。例如，针对组播丢包恢复的机制是前向纠错(FEC，Forward Error Correction)，针对单播丢包恢复的机制是自动要求重传(ARQ，Automatic Repeat reQuest)，针对单播避免缓存上下溢的机制是流量控制。但是这些机制并没有考虑到直播业务场景下流媒体服务器因为码流码率的变化而导致的收流处理的包出错的问题。
发明内容
本公开实施例提供一种入向码流码率获取方法、收流处理方法、电子设备、计算机可读存储介质。
第一方面，本公开实施例提供一种入向码流码率获取方法，该方法包括：计算与本次时间间隔对应的平均码率；根据上一次入向码流码率和与所述本次时间间隔对应的平均码率计算本次码率波动的 权重系数；以及根据所述本次码率波动的权重系数确定本次入向码流码率和下一次时间间隔，并在延迟预设时间间隔后，执行计算与下一次时间间隔对应的平均码率的步骤。
第二方面，本公开实施例提供一种收流处理方法，该方法包括：根据本次入向码流码率计算与本次任务对应的最大接收包数量，其中，所述本次入向码流码率为采用上述入向码流码率获取方法确定的本次入向码流码率；以及根据与所述本次任务对应的最大接收包数量将入向码流中属于所述本次任务的包进行收流处理。
第三方面，本公开实施例提供一种电子设备，该设备包括：至少一个处理器；以及存储器，存储器上存储有至少一个程序，当至少一个程序被至少一个处理器执行时，实现上述入向码流码率获取方法，或实现上述收流处理方法。
第四方面，本公开实施例提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述入向码流码率获取方法，或实现上述收流处理方法。
附图说明
图1为根据本公开的实施例的与直播业务场景对应的架构示意图；
图2为根据本公开的实施例的与直播业务场景对应的架构示意图；
图3为根据本公开的实施例的与直播业务场景对应的架构示意图；
图4为根据本公开的实施例的入向码流码率获取方法的流程图；
图5为根据本公开的实施例的收流处理方法的流程图；
图6为根据本公开的实施例的流媒体服务器的组成框图。
具体实施方式
为使本领域的技术人员更好地理解本公开的技术方案，下面结合附图对本公开提供的入向码流码率获取方法、收流处理方法、电子设备、计算机可读存储介质进行详细描述。
在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现且不应当被解释为限于本文阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。
在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。
如本文所使用的，术语“和/或”包括至少一个相关列举条目的任何和所有组合。
本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加至少一个其它特征、整体、步骤、操作、元件、组件和/或其群组。
除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。
在介绍本公开实施例的入向码流码率获取方法和收流处理方法之前，首先介绍本公开实施例的入向码流码率获取方法和收流处理方法所适用的几种直播业务场景。
针对直播业务场景，目前需要由流媒体服务器的运维人员将入向码流码率输入到流媒体服务器中，然后由流媒体服务器根据入向码流码率构建收流信息，继而流媒体服务器根据收流信息对入向码流中 的包进行收流处理。这种方式中流媒体服务器用来构建收流信息的入向码流码率一般不会发生变化，但是由于运维人员有可能输入错误的码率，也有可能实际的入向码流码率发生变化，从而导致运维人员输入的入向码流码率与实际的入向码流码率的匹配程度差距很大，导致直播业务质量下降。
图1为根据本公开的实施例的与直播业务场景对应的架构示意图。如图1所示的直播业务场景1中，入向码流为入向组播码流，出向码流为出向组播码流，两个或两个以上终端一将入向组播码流发送给组播交换机，组播交换机将入向组播码流发送给流媒体服务器，流媒体服务器接收入向组播码流，对入向组播码流进行收流处理以得到出向组播码流，将出向组播码流发送给组播交换机，组播交换机将出向组播码流发送给两个或两个以上终端二。
图2为根据本公开的实施例的与直播业务场景对应的架构示意图。如图2所示的直播业务场景2中，入向码流为入向单播码流，出向码流为出向组播码流，终端三将入向单播码流发送给流媒体服务器，流媒体服务器接收入向单播码流，对入向单播码流进行收流处理得到出向组播码流，将出向组播码流发送给组播交换机，组播交换机将出向组播码流发送给两个或两个以上终端四。
图3为根据本公开的实施例的与直播业务场景对应的架构示意图。如图3所示的直播业务场景3中，入向码流为入向单播码流，出向码流为出向单播码流，终端五将入向单播码流发送给流媒体服务器，流媒体服务器接收入向单播码流，对入向单播码流进行收流处理得到出向单播码流，将出向单播码流发送给终端六。
根据以上描述的三种直播业务场景，在本公开实施例中，入向码流可以是入向组播码流，也可以是入向单播码流，出向码流可以是出向组播码流，也可以是出向单播码流。
图4为根据本公开的实施例的入向码流码率获取方法的流程图。
参照图4，根据本公开的实施例的入向码流码率获取方法包括步 骤400至402。
在步骤400，计算与本次时间间隔t对应的平均码率。
在一些示例性实施例中，根据在本次时间间隔t内接收的所有包的总大小recvlen和本次时间间隔t计算与本次时间间隔t对应的平均码率cur_b。例如，与本次时间间隔t对应的平均码率cur_b为在本次时间间隔t内接收的所有包的总大小recvlen和本次时间间隔t的比值，即
Figure PCTCN2022130363-appb-000001
第一次和第二次计算时，本次时间间隔t可以初始化为t0。
在步骤401，根据上一次入向码流码率和与本次时间间隔对应的平均码率计算本次码率波动的权重系数。
第一次计算时，上一次入向码流码率可以初始化为与第1次时间间隔对应的平均码率。
在一些示例性实施例中，根据上一次入向码流码率和与本次时间间隔对应的平均码率计算本次码率波动的权重系数包括：按照公式
Figure PCTCN2022130363-appb-000002
计算本次码率波动的权重系数，其中，flucoeff为本次码率波动的权重系数，cur_b为与本次时间间隔对应的平均码率，last_b为上一次入向码流码率。
在步骤402，根据本次码率波动的权重系数确定本次入向码流码率和下一次时间间隔，并在延迟预设时间间隔后，执行计算与下一次时间间隔对应的平均码率的步骤。
在一些示例性实施例中，根据本次码率波动的权重系数确定本次入向码流码率和下一次时间间隔包括：在本次码率波动的权重系数小于预设阈值的情况下，说明当前入向码流码率的波动不大，确定本次入向码流码率与上一次入向码流码率相同，确定下一次时间间隔与本次时间间隔相同；在本次码率波动的权重系数大于或等于预设阈值的情况下，说明当前入向码流码率的波动较大，确定本次入向码流码 率为与本次时间间隔对应的平均码率，确定下一次时间间隔小于本次时间间隔。
在本次码率波动的权重系数大于或等于预设阈值的情况下，本公开实施例对下一次时间间隔的具体取值不作限定，只要下一次时间间隔小于本次时间间隔即可，这样可以保证在入向码流码率波动剧烈时减少检测周期，从而达到快速收敛入向码流码率的目的。例如，确定下一次时间间隔小于本次时间间隔包括：根据本次时间间隔和本次码率波动的权重系数确定下一次时间间隔。例如，可以按照公式
Figure PCTCN2022130363-appb-000003
确定下一次时间间隔，t next为下一次时间间隔，t cur为本次时间间隔，flucoeff为本次码率波动的权重系数。
在一些示例性实施例中，预设阈值可以根据实际情况设置，例如设置预设阈值为0.1。
在一些示例性实施例中，预设时间可以是0，即不作延迟直接计算与下一次时间间隔对应的平均码率，也可以是本次时间间隔，也可以是下一次时间间隔，每一次延迟的预设时间可以相同，也可以不相同。
本公开实施例提供的入向码流码率获取方法，对入向码流码率进行了自适应评估，为后续进行收流处理奠定了基础。
图5为根据本公开的实施例的收流处理方法的流程图。
参照图5，根据本公开的实施例的收流处理方法包括步骤500和501。
在步骤500，根据本次入向码流码率计算与本次任务对应的最大接收包数量，本次入向码流码率为采用上述入向码流码率获取方法确定的本次入向码流码率。
在一些示例性实施例中，可以在未确定本次入向码流码率是否有波动的情况下，直接按照公式
Figure PCTCN2022130363-appb-000004
计算 与本次任务对应的最大接收包数量，recvpktcnt为与本次任务对应的最大接收包数量，recviter为固定收流间隔，b cur为本次入向码流码率，pktlen为每个包的大小，recvcoeff为固定收流系数。
在一些示例性实施例中，为了减少计算资源，也可以先确定本次入向码流码率是否有波动，再确定是否需要重新计算与本次任务对应的最大接收包数量。也就是说，根据本次入向码流码率计算与本次任务对应的最大接收包数量包括以下至少之一：在确定本次入向码流码率没有波动的情况下，确定与本次任务对应的最大接收包数量和与上一次任务对应的最大接收包数量相同；在确定本次入向码流码率有波动的情况下，按照公式
Figure PCTCN2022130363-appb-000005
计算与本次任务对应的最大接收包数量，recvpktcnt为与本次任务对应的最大接收包数量，recviter为固定收流间隔(即相邻两次任务的开始时间之间的时间间隔)，b cur为本次入向码流码率，pktlen为每个包的大小，recvcoeff为固定收流系数。
在一些示例性实施例中，确定本次入向码流码率没有波动包括：本次入向码流码率与上一次入向码流码率相同。
在一些示例性实施例中，确定本次入向码流码率有波动包括：本次入向码流码率与上一次入向码流码率不同。
在步骤501，根据与本次任务对应的最大接收包数量将入向码流中属于本次任务的包进行收流处理。
在一些示例性实施例中，根据本次任务对应的最大接收包数量将入向码流中属于本次任务的包进行收流处理包括：通过依次从内核协议栈中读取接收的包来进行收流处理，直到内核协议栈中没有可读取的包，或直到从内核协议栈中读取的包数量大于或等于与本次任务对应的最大接收包数量。
在本公开实施例中，接收到入向码流中的包后先存入内核协议栈中，再从内核协议栈中依次读取包来进行收流处理。
本公开实施例提供的收流处理方法，基于自适应评估的入向码流码率进行收流处理，而不需要运维人员输入入向码流码率，继而根据运维人员输入的入向码流码率构建收流进行进行收流处理，从而自适应评估的入向码流码率与实际的入向码流码率的匹配程度差距较小，从而提升了直播业务质量。
为了使得本公开实施例的入向码流码率获取方法和收流处理方法更直观的呈现，下面通过具体示例详细说明具体的实现过程，所列举的示例不用于限定本公开实施例的保护范围。
示例1
初始化第1次时间间隔t 1为t 0。
按照公式
Figure PCTCN2022130363-appb-000006
计算与第1次时间间隔t 1对应的平均码率b 1，b 1为与第1次时间间隔对应的平均码率，recvlen 1为在第1次时间间隔内接收的所有包的总大小，t 1为第1次时间间隔。
按照公式
Figure PCTCN2022130363-appb-000007
计算第1次码率波动的权重系数，flucoeff 1为第1次码率波动的权重系数，b 1为与第1次时间间隔对应的平均码率，b 0为第0次入向码流码率(初始化为b 1)。
由于第1次码率波动的权重系数flucoeff 1小于预设阈值(0.1)，说明当前入向码流码率的波动不大，确定第1次入向码流码率为b 0，确定第2次时间间隔t 2为t 0。
延迟t 0时间后按照公式
Figure PCTCN2022130363-appb-000008
计算与第2次时间间隔t 2对应的平均码率b 2，b 2为与第2次时间间隔对应的平均码率，recvlen 2为在第2次时间间隔内接收的所有包的总大小，t 2为第2次时间间隔。
按照公式
Figure PCTCN2022130363-appb-000009
计算第2次码率波动的权重系数，flucoeff 2为第2次码率波动的权重系数，b 2为与第2次时间间隔对应的平均码率，b 0为第1次入向码流码率(其在上一次计算时被确定为 b 0)。
在第2次码率波动的权重系数flucoeff 2小于0.1的情况下，说明当前入向码流码率的波动不大，第2次入向码流码率仍然为b 0，第3次时间间隔t 3仍然为t 0。
在第2次码率波动的权重系数flucoeff 2大于或等于预设阈值(0.1)的情况下，说明当前入向码流码率的波动较大，第2次入向码流码率为b 2，第3次时间间隔t 3为
Figure PCTCN2022130363-appb-000010
下面基于第2次码率波动的权重系数flucoeff 2大于或等于0.1的情况进行描述。
延迟t 3时间后按照公式
Figure PCTCN2022130363-appb-000011
计算与第3次时间间隔t 3对应的平均码率b 3，b 3为第3次时间间隔对应的平均码率，recvlen 3为在第3次时间间隔内接收的所有包的总大小，t 3为第3次时间间隔。
按照公式
Figure PCTCN2022130363-appb-000012
计算第3次码率波动的权重系数，flucoeff 3为第3次码率波动的权重系数，b 3为第3次时间间隔对应的平均码率，b 2为第2次入向码流码率(其在上一次计算时被确定为与第2次时间间隔对应的平均码率b 2)。
在第3次码率波动的权重系数flucoeff 3小于0.1的情况下，说明当前入向码流码率的波动不大，第3次入向码流码率仍然为b 2，第4次时间间隔t 4仍然为t 3。
在第3次码率波动的权重系数flucoeff 3大于或等于0.1的情况下，说明当前入向码流码率的波动较大，第3次入向码流码率为b 3，第4次时间间隔t 4为
Figure PCTCN2022130363-appb-000013
以此类推一直检测下去。
示例2
在得到第1次入向码流码率后，按照公式
Figure PCTCN2022130363-appb-000014
计算与第1次入向码流码率对应的本次任务对应的最大接收包数量，recvpktcnt 1为与本次任务对应的最大接收包数量，recviter为固定收流间隔，b 1为第1次入向码流码率，pktlen为每个包的大小，recvcoeff为固定收流系数。
通过依次从内核协议栈中读取接收的包来进行收流处理，直到内核协议栈中没有可读取的包，或直到从内核协议栈中读取的包数量大于或等于与第1次入向码流码率对应的本次任务对应的最大接收包数量。
在每一次从内核协议栈中读取接收的包来进行收流处理后，判断内核协议栈中是否还有可读取的包。如果没有可读取的包则结束本次任务，如果有可读取的包则判断从内核协议栈中读取的包数量是否大于或等于与第1次入向码流码率对应的本次任务对应的最大接收包数量。如果是，则结束本次任务；如果不是，则继续从内核协议栈中读取接收的包进行收流处理。
在得到第2次入向码流码率后，判断第2次入向码流码率与第1次入向码流码率是否相同，如果相同，则直接采用与第1次入向码流码率对应的本次任务对应的最大接收包数量作为与第2次入向码流码率对应的本次任务对应的最大接收包数量；如果不相同，则按照公式
Figure PCTCN2022130363-appb-000015
计算与本次任务对应的最大接收包数量，recvpktcnt 2为与第2次入向码流码率对应的本次任务对应的最大接收包数量，recviter为固定收流间隔，b 2为第2次入向码流码率，pktlen为每个包的大小，recvcoeff为固定收流系数。
通过依次从内核协议栈中读取接收的包来进行收流处理，直到内核协议栈中没有可读取的包，或直到从内核协议栈中读取的包数量大于或等于与第2次入向码流码率对应的本次任务对应的最大接收 包数量。
在每一次从内核协议栈中读取接收的包来进行收流处理后，判断内核协议栈中是否还有可读取的包。如果没有可读取的包，则结束本次任务，如果有可读取的包，则判断从内核协议栈中读取的包数量是否大于或等于第1次入向码流码率对应的本次任务对应的最大接收包数量。如果是，则结束本次任务，如果不是，则继续从内核协议栈中读取接收的包进行收流处理。
以此类推一直持续下去。
本公开提供一种电子设备，该电子设备包括：至少一个处理器和存储器，存储器上存储有至少一个程序，当至少一个程序被至少一个处理器执行时，实现上述入向码流码率获取方法，或实现上述收流处理方法。
处理器为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等。存储器为具有数据存储能力的器件，其包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)。
在一些实施例中，处理器、存储器通过总线相互连接，进而与计算设备的其它组件连接。
本公开提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述入向码流码率获取方法，或实现上述收流处理方法。
图6为根据本公开的实施例的流媒体服务器的组成框图。
参照图6，根据本公开的实施例的流媒体服务器包括：入向码流码率检测模块601、收流模块602和发流模块603。
入向码流码率检测模块601用于实现上述入向码流码率获取方法，收流模块602用于实现上述收流处理方法，发流模块603用于发送收流处理后的包。
在实现时，入向码流码率检测模块601可以每一次均更新入向 码流码率，也可以先判断当前入向码流码率的波动是否大，如果波动不大，则不需要更新入向码流码率；如果波动较大，则更新入向码流码率。
在实现时，入向码流码率检测模块601可以在每一次得到入向码流码率时，将本次获得的入向码流码率发送给收流模块602，也可以先判断本次获得的入向码流码率是否与上一次获得的入向码流码率相同，如果相同，则不将本次获得的入向码流码率发送给收流模块602；如果不相同，则将本次获得的入向码流码率发送给收流模块602。
在实现时，收流模块602如果没有收到新的入向码流码率，则根据上一次收到的入向码流码率计算与本次任务对应的最大接收包数量，根据与本次任务对应的最大接收包数量进行收流处理；收流模块602如果接收到新的入向码流码率，则根据新的入向码流码率计算与本次任务对应的最大接收包数量，根据与本次任务对应的最大接收包数量进行收流处理。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、 CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储器、或者可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。
本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其它实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (14)

  1. 一种入向码流码率获取方法，包括：
    计算与本次时间间隔对应的平均码率；
    根据上一次入向码流码率和与所述本次时间间隔对应的平均码率计算本次码率波动的权重系数；以及
    根据所述本次码率波动的权重系数确定本次入向码流码率和下一次时间间隔，并在延迟预设时间间隔后，执行计算与下一次时间间隔对应的平均码率的步骤。
  2. 根据权利要求1所述的入向码流码率获取方法，其中，与所述本次时间间隔对应的平均码率为在所述本次时间间隔内接收的所有包的总大小和所述本次时间间隔的比值。
  3. 根据权利要求1所述的入向码流码率获取方法，其中，根据所述上一次入向码流码率和与所述本次时间间隔对应的平均码率计算所述本次码率波动的权重系数包括：
    按照
    Figure PCTCN2022130363-appb-100001
    计算所述本次码率波动的权重系数，
    其中，flucoeff为所述本次码率波动的权重系数，cur_b为与所述本次时间间隔对应的平均码率，last_b为所述上一次入向码流码率。
  4. 根据权利要求1所述的入向码流码率获取方法，其中，根据所述本次码率波动的权重系数确定所述本次入向码流码率和所述下一次时间间隔包括：
    在所述本次码率波动的权重系数小于预设阈值的情况下，确定所述本次入向码流码率与所述上一次入向码流码率相同，并确定所述下一次时间间隔与所述本次时间间隔相同；以及
    在所述本次码率波动的权重系数大于或等于所述预设阈值的情况下，确定所述本次入向码流码率为与所述本次时间间隔对应的平均码率，并确定所述下一次时间间隔小于所述本次时间间隔。
  5. 根据权利要求4所述的入向码流码率获取方法，其中，确定所述下一次时间间隔小于所述本次时间间隔包括：
    按照
    Figure PCTCN2022130363-appb-100002
    确定所述下一次时间间隔；
    其中，t next为所述下一次时间间隔，t cur为所述本次时间间隔，flucoeff为所述本次码率波动的权重系数。
  6. 一种收流处理方法，包括：
    根据本次入向码流码率计算与本次任务对应的最大接收包数量，其中，所述本次入向码流码率为采用根据权利要求1-5中任意一项所述的入向码流码率获取方法确定的本次入向码流码率；以及
    根据与所述本次任务对应的最大接收包数量将入向码流中属于所述本次任务的包进行收流处理。
  7. 根据权利要求6所述的收流处理方法，其中，根据所述本次入向码流码率计算与所述本次任务对应的最大接收包数量包括：
    在确定所述本次入向码流码率没有波动的情况下，确定与所述本次任务对应的最大接收包数量和与上一次任务对应的最大接收包数量相同；以及
    在确定所述本次入向码流码率有波动的情况下，按照
    Figure PCTCN2022130363-appb-100003
    计算与所述本次任务对应的最大接收包数量，其中，recvpktcnt为与所述本次任务对应的最大接收包数量，recviter为固定收流间隔，bcur为所述本次入向码流码率，pktlen 为每个包的大小，recvcoeff为固定收流系数。
  8. 根据权利要求7所述的收流处理方法，其中，确定所述本次入向码流码率没有波动包括：所述本次入向码流码率与上一次入向码流码率相同。
  9. 根据权利要求7所述的收流处理方法，其中，确定所述本次入向码流码率有波动包括：所述本次入向码流码率与上一次入向码流码率不同。
  10. 根据权利要求6所述的收流处理方法，其中，根据与所述本次任务对应的最大接收包数量将所述入向码流中属于所述本次任务的包进行所述收流处理包括：
    通过依次从内核协议栈中读取接收的包来进行所述收流处理，直到所述内核协议栈中没有可读取的包，或直到从所述内核协议栈中读取的包数量大于或等于与所述本次任务对应的最大接收包数量。
  11. 一种电子设备，包括：
    至少一个处理器；以及
    存储器，所述存储器上存储有至少一个程序，当所述至少一个程序被所述至少一个处理器执行时，实现根据权利要求1-5中任意一项所述的入向码流码率获取方法。
  12. 一种电子设备，包括：
    至少一个处理器；以及
    存储器，所述存储器上存储有至少一个程序，当所述至少一个程序被所述至少一个处理器执行时，实现根据权利要求6-10任意一项所述的收流处理方法。
  13. 一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1-5中任意一项所述的入向码流码率获取方法。
  14. 一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求6-10中任意一项所述的收流处理方法。
PCT/CN2022/130363 2021-11-12 2022-11-07 入向码流码率获取方法、收流处理方法、电子设备、介质 WO2023083143A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111337644.6 2021-11-12
CN202111337644.6A CN116132717A (zh) 2021-11-12 2021-11-12 入向码流码率获取方法、收流处理方法、电子设备、介质

Publications (1)

Publication Number Publication Date
WO2023083143A1 true WO2023083143A1 (zh) 2023-05-19

Family

ID=86299565

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/130363 WO2023083143A1 (zh) 2021-11-12 2022-11-07 入向码流码率获取方法、收流处理方法、电子设备、介质

Country Status (2)

Country Link
CN (1) CN116132717A (zh)
WO (1) WO2023083143A1 (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130094565A1 (en) * 2011-10-17 2013-04-18 Google Inc. Rate-distortion-complexity optimization of video encoding guided by video description length
CN106028085A (zh) * 2016-06-14 2016-10-12 浙江工业大学 基于dash的多客户端码率自适应及震荡补偿方法
CN107026856A (zh) * 2017-03-30 2017-08-08 上海七牛信息技术有限公司 一种网络推流质量的优化方法及优化系统
CN107277568A (zh) * 2017-08-16 2017-10-20 广州市千钧网络科技有限公司 一种推流配置参数动态调整方法及装置
CN110913245A (zh) * 2019-11-08 2020-03-24 网宿科技股份有限公司 一种控制视频转码码率的方法和装置
CN111193673A (zh) * 2020-04-10 2020-05-22 亮风台（上海）信息科技有限公司 数据传输速率控制方法、系统和用户设备
CN113347138A (zh) * 2020-03-02 2021-09-03 广州虎牙科技有限公司 转码数据流的传输方法、装置、计算机设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130094565A1 (en) * 2011-10-17 2013-04-18 Google Inc. Rate-distortion-complexity optimization of video encoding guided by video description length
CN106028085A (zh) * 2016-06-14 2016-10-12 浙江工业大学 基于dash的多客户端码率自适应及震荡补偿方法
CN107026856A (zh) * 2017-03-30 2017-08-08 上海七牛信息技术有限公司 一种网络推流质量的优化方法及优化系统
CN107277568A (zh) * 2017-08-16 2017-10-20 广州市千钧网络科技有限公司 一种推流配置参数动态调整方法及装置
CN110913245A (zh) * 2019-11-08 2020-03-24 网宿科技股份有限公司 一种控制视频转码码率的方法和装置
CN113347138A (zh) * 2020-03-02 2021-09-03 广州虎牙科技有限公司 转码数据流的传输方法、装置、计算机设备及存储介质
CN111193673A (zh) * 2020-04-10 2020-05-22 亮风台（上海）信息科技有限公司 数据传输速率控制方法、系统和用户设备

Also Published As

Publication number Publication date
CN116132717A (zh) 2023-05-16

Similar Documents

Publication Publication Date Title
US9872198B2 (en) Systems and methods for data transmission
US20220309025A1 (en) Multi-path rdma transmission
US10148598B2 (en) Efficient packet processing at video receiver in multimedia communications over packet networks
US7929436B2 (en) Network communication control methods and systems
US20140348049A1 (en) Rate Adaptive Transmission of Wireless Broadcast Packets
CN110445722B (zh) 拥塞控制方法、装置、设备及存储介质
US20170346601A1 (en) Data transmission method and computing apparatus having data transmission function
US20040017773A1 (en) Method and system for controlling the rate of transmission for data packets over a computer network
KR20160133454A (ko) 확장된 송신 제어 기능을 구현하는 송신 가속기
JP2024509728A (ja) データ再送処理方法、装置、コンピュータ機器及びコンピュータプログラム
US8873590B2 (en) Apparatus and method for correcting jitter
CN110830460B (zh) 一种连接建立方法、装置、电子设备及存储介质
US9350484B2 (en) Transport accelerator implementing selective utilization of redundant encoded content data functionality
US20190058663A1 (en) Flowlet-Based Load Balancing
US10574706B2 (en) Method and system for upload optimization
WO2023083143A1 (zh) 入向码流码率获取方法、收流处理方法、电子设备、介质
CN116318545A (zh) 视频数据传输方法、装置、设备及存储介质
CN108667563B (zh) 一种前向纠错包个数获取方法及装置
CN112351049B (zh) 数据传输方法、装置、设备及存储介质
US9264939B2 (en) Communication over a wireless connection
WO2021164405A1 (zh) 数据编解码方法、相关设备及系统
US11190426B2 (en) Network evaluating apparatus, network evaluating method, and program
CN110418164B (zh) 数据传输方法及装置
CN115801683A (zh) 视频处理方法、装置、电子设备及存储介质
CN117896548A (zh) 数据帧的传输方法、装置、电子设备和可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22891937

Country of ref document: EP

Kind code of ref document: A1