WO2017161122A1 - Système de transmission vidéo en continu en direct au moyen de codes fontaines compatibles avec le retard - Google Patents

Système de transmission vidéo en continu en direct au moyen de codes fontaines compatibles avec le retard Download PDF

Info

Publication number
WO2017161122A1
WO2017161122A1 PCT/US2017/022715 US2017022715W WO2017161122A1 WO 2017161122 A1 WO2017161122 A1 WO 2017161122A1 US 2017022715 W US2017022715 W US 2017022715W WO 2017161122 A1 WO2017161122 A1 WO 2017161122A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
daf
data
node
future
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.)
Ceased
Application number
PCT/US2017/022715
Other languages
English (en)
Inventor
Dapeng Oliver Wu
Kairan SUN
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.)
University of Florida
University of Florida Research Foundation Inc
Original Assignee
University of Florida
University of Florida Research Foundation Inc
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 University of Florida, University of Florida Research Foundation Inc filed Critical University of Florida
Publication of WO2017161122A1 publication Critical patent/WO2017161122A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/35—Unequal or adaptive error protection, e.g. by providing a different level of protection according to significance of source information or by adapting the coding according to the change of transmission channel characteristics
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/373—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35 with erasure correction and erasure determination, e.g. for packet loss recovery or setting of erasures for the decoding of Reed-Solomon codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/3761—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35 using code combining, i.e. using combining of codeword portions which may have been transmitted separately, e.g. Digital Fountain codes, Raptor codes or Luby Transform [LT] codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/63—Joint error correction and other techniques
    • H03M13/6312—Error control coding in combination with data compression
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/115—Selection of the code volume for a coding unit prior to coding
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/149—Data rate or code amount at the encoder output by estimating the code amount by means of a model, e.g. mathematical model or statistical model
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/177—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a group of pictures [GOP]
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • 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
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available

Definitions

  • FEC Forward Error Correction
  • fountain codes such as Luby transform (LT) code [2] and Raptor code [3].
  • LT Luby transform
  • Raptor code 3
  • fountain codes encoded packets are generated from a given set of native packets, such that the original file can ideally be recovered as long as the number of the received packets is equal to or only slightly larger than the number of native packets.
  • the RaptorQ codes [4] For example, given a file consisting of a sufficiently large number of native packets k , with the latest generation of fountain codes, the RaptorQ codes [4], the chance of decoding failure is less than 1% upon receiving k packets, and less than one in a million upon receiving k + 2 packets [5].
  • a major advantage of fountain codes is ratelessness, i.e., the coding rate can automatically adapt to the wireless condition without demanding acknowledgments (ACKs) or retransmissions.
  • traditional fountain codes are designed for file transfer rather than video streaming. Under the current fountain codes paradigm, the users may not start to watch it until the whole video file is successfully decoded.
  • window-based fountain codes In order to accommodate fountain codes to video streaming, several window-based fountain codes have been proposed.
  • block coding [6], [7] divides the video file into fixed-length data blocks and separately sends them using fountain codes;
  • expanding window [11], [12] expands the previous window to include new packets.
  • the block size is fixed in block coding, virtually extended in sliding window, and keeps growing in expanding window.
  • a network system for increasing data throughput and decreasing transmission delay along a data link from a source node to a sink node via a relay node may comprise a first node configured to: predict at least one future video encoding characteristic of a video source over a finite number of future frames, encode a plurality of video data packets using rateless coding based on the predicted at least one future video encoding characteristic by adaptively adjusting at least one parameter of the rateless coding based on the predicted at least one future video encoding characteristic, and transmit the plurality of video data packets, wherein the video source is a video source of the plurality of video data packets.
  • At least one computer-readable storage medium encoded with executable instructions that, when executed by at least one processor, cause the at least one processor to perform a method for transmitting a video stream over a data link from a source node to a sink node via a relay node.
  • the method may comprise: predicting at least one future video encoding characteristic of a video source over a finite number of future frames; encoding a plurality of video data packets using rateless coding based on the predicted at least one future video encoding characteristic by adaptively adjusting at least one parameter of the rateless coding based on the predicted at least one future video encoding characteristic; and transmitting the plurality of video data packets, wherein the video source is a video source of the plurality of video data packets.
  • FIG. 1 is a block diagram illustrating an exemplary source node, relay nodes, and a sink
  • FIG. 2 is a flowchart of an exemplary method of increasing data throughput and decreasing transmission delay along a data link from a source node to a sink node according to some embodiments.
  • FIG. 3 is a flowchart of an additional exemplary method of increasing data throughput and decreasing transmission delay along a data link from a source node to a sink node according to some embodiments.
  • FIG. 4 is a flowchart of an exemplary fountain code process according to some embodiments.
  • FIG. 5 is a set of charts illustrating a comparison between bit rates and sampling distributions using (a) foreman, (b) DAF-O, (c) DAF-M, and (d) DAF according to some embodiments.
  • FIG. 6 is a chart illustrating exemplary comparisons of DAF-L, DAF-O, DAF-M, and DAF according to some embodiments.
  • FIG. 7 is a chart illustrating exemplary comparisons of DAF-L, DAF-O, DAF-M, DAF, and Block coding according to some embodiments.
  • FIG. 8 is a set of charts illustrating exemplary comparisons of DAF, DAF-L, DAF-O, and DAF-M according to some embodiments.
  • FIG. 9 is a chart illustrating a comparison of exemplary fountain code schemes according to some embodiments.
  • FIG. 10 is a diagram illustrating a computer system on which some embodiments of the invention may be implemented.
  • window-based fountain codes may introduce extra play delay due to window size and decoding time.
  • window-based fountain codes for video streaming may trade delay for higher decoding performance. The reason is that larger block size may introduce longer delay, but may also provide higher coding gain at the same time [13].
  • video streaming applications may have different levels of delay tolerance.
  • Some applications may be very delay- sensitive, such as live video chat, cloud gaming, etc., all of which are characterized by bi-directional communication [14].
  • Some uni-directional applications on the other hand, have a loose tolerance on end-to-end delay, such as TV broadcasting, Internet live streams. The others, such as the streaming of pre-recorded content, are the least sensitive to delay.
  • DAF codes may be suitable for video streaming, as proposed in [10]. Different from the other sliding window fountain codes schemes, DAF codes do not treat the sliding windows as homogeneous. By adaptively selecting the window length and adjusting the sampling pattern according to the ongoing video bit rate, DAF codes may deliver significantly higher video decoding ratio than existing schemes.
  • the inventors have recognized and appreciated, however, that the high-complexity global optimization process of DAF codes may prevent its applications in delay-sensitive video streaming (e.g., live streaming). As a result, the inventors have recognized and appreciated that reduceing complexity while maintaining relatively high coding performance may improve the video watching experience for delay- sensitive video streaming. The inventors have recognized and appreciated that using Model Predictive Control (MPC) may be most appropriate.
  • MPC Model Predictive Control
  • MPC has developed considerably over the recent years. As an advanced method of process control, it has been successfully used in the control process of chemical plants, oil refineries, power plants, etc. [15]. Besides, there are also some successful applications in academia, ranging from energy management [16] to automatic vehicle control [17]. Despite the popularity in automatic control community, MPC has never been used in the domain of multimedia communication. The inventors have recognized and appreciated that integrating MPC with DAF codes may improve video streaming performance, while maintaining low complexity. In MPC, actions may be optimized according to a state sequence over a horizon. Based on that idea, two schemes are discussed herein, i.e., DAF-M and DAF-O.
  • DAF-M may improve upon adjusting the sampling pattern for fountain codes according to the ongoing video bit rate, so as to deliver a consistent video watching experience.
  • the computational complexity may be affordable for live streaming because the objective function may be minimized over a limit-sized horizon, which may not grow with the video length.
  • DAF-0 may be implemented based on the prediction of future bit rate.
  • DAF-0 may provide a decoding ratio that is significantly higher than existing online video streaming schemes.
  • FIG. 1 is a diagram illustrating a system 100 that may employ techniques for increasing data throughput and decreasing transmission delay from a source node to a sink node via a relay node as described herein.
  • a source node 110 (which may be referred to as first node) may encode data packets for transmission.
  • the source node 110 may encode the data packets using fountain coding (as illustrated at stage 210 of FIG. 2).
  • any suitable coding including rateless coding, may be used to encode the data packets.
  • the source node 110 may also transmit the data packets to a first relay node 130 via connection 120 (as illustrated at stage 220 of FIG. 2), which may be a wireless connection.
  • connection 120 as illustrated at stage 220 of FIG. 2
  • any suitable connection or communication technology may be used to communicate among the nodes.
  • the first relay node 130 may receive at least one of the data packets from the source node 110. In addition, the first relay node 130 may relay or transmit the data packets to a second relay node 150 via connection 140, which may be a wireless connection. The second relay node 150 may receive at least one of the data packets from the first relay node 130. In addition, the second relay node 150 may relay or transmit the data packets to a sink node 170 via connection 160, which may be a wireless connection.
  • source node 110 may be a server, such as a streaming video server and/or a live streaming video server streaming live video content.
  • source node 110 may include a network ingress point, such as a gateway to a wireless network (e.g., a base station in a wireless network).
  • sink node 170 may be a client, such as a video receiver and/or playback device.
  • sink node 170 may be a client of the server referred to as source node 110.
  • Sink node 170 may be a wireless device, such as a smartphone, tablet, laptop computer, or desktop computer.
  • relay nodes such as first relay node 130 and/or second relay node 150, may include network routers and/or network switches.
  • relay nodes such as first relay node 130 and/or second relay node 150, may include hubs, and/or any other suitable components.
  • relay nodes may include other cell transceivers in a cellular network, such as a 5G network.
  • the first relay node 130 and/or the second relay node 150 may regenerate, re-encode, and relay the data packets conditionally, based on the quantity of the data packets received at the given relay node. For example, the first relay node 130 and/or the second relay node 150 may receive a subset of the data packets, and based on the subset of the data packets, the first relay node 130 and/or the second relay node 150 may regenerate the data packets, re-encode the regenerated data packets, and transmit the regenerated, re-encoded data packets.
  • the sink node 170 may receive one or more data packets from the second relay node 150. If the sink node 170 has received a sufficient quantity of the data packets, the sink node 170 may regenerate and decode the data packets.
  • FIG. 1 shows only two relay nodes, the first relay node 130 and the second relay node 150. This number of relay nodes is shown for simplicity of illustration. It should be appreciated that a network system may have many more nodes and relay nodes.
  • source node 110 may predict at least one future video encoding characteristic of a video source over a finite number of future frames (as illustrated at stage 210 of FIG. 2).
  • a video encoding characteristic may include any characteristic or property of how a video source is encoded, such as frame rate, number of frames in a group of pictures, video bit rate, and so on.
  • source node 110 may encode a plurality of video data packets using rateless coding (as described above) based on the predicted at least one future video encoding characteristic of the video source (as illustrated at stage 220 of FIG. 2) by adaptively adjusting at least one parameter of the rateless coding based on the predicted at least one future video encoding characteristic (as illustrated at stage 225 of FIG. 2).
  • the video source may be a video source of the plurality of video data packets. Additionally, source node 110 may transmit the video data packets. For example, source node 110 may transmit the video data packets over a data link to a second node, which may be first relay node 130, second relay node 150, and/or sink node 170 (as illustrated at stage 220 of FIG. 2).
  • the second node may be a sink node configured to receive one or more of the plurality of video data packets from the streaming video server via at least one relay node, or at least one relay node configured to receive at least one of the plurality of video data packets from the streaming video server.
  • the data link is at least partially wireless.
  • the rateless coding may comprise fountain coding.
  • the video source may include video data, such as a video file.
  • at least one video data packet of the plurality of video data packets comprises at least 100 bits, although any number of bits may be used.
  • the plurality of overlapping sliding data windows may be non-homogeneous, as discussed herein. For example, the plurality of overlapping sliding data windows may collectively have more than one length and/or more than one sampling distribution.
  • source node 110 may obtain at least one video encoding characteristic by preprocessing the video source, and source node 110 may use the at least one video encoding characteristic as well as the predicted at least one future video encoding characteristic.
  • source node 110 may predict the at least one future video encoding characteristic based on at least one video encoding characteristic of the video source.
  • adaptively adjusting the at least one parameter of the rateless coding may comprise adaptively selecting a first length of a first data window and a second length of a second data window of a plurality of overlapping sliding data windows (as illustrated at stage 226 of FIG. 3). Additionally, the selecting may use model predictive control based on the predicted at least one future video encoding characteristic. In some embodiments, the selecting may be based on a number of bits in frames of the video source and/or on a first number of frames in the video source.
  • the first length may comprise a second number of frames that the first data window can accommodate, and the second length may comprise a third number of frames that the second data window can accommodate.
  • source node 110 may store the first length of the first data window in a header of a first packet of the first data window and may store the second length of the second data window in a header of a second packet of the second data window.
  • source node 110 may store the first sampling distribution in the header of the first packet of the first data window as a first slope factor and may store the second sampling distribution in the header of the second packet of the second data window as a second slope factor.
  • adaptively adjusting the at least one parameter of the rateless coding may comprise adaptively adjusting a first sampling distribution for the first data window and a second sampling distribution for the second data window (as illustrated at stage 227 of FIG. 3).
  • the at least one future video encoding characteristic may include a future video bit rate of the video source.
  • the adjusting may be based on a future video bit rate of the video source.
  • the future video bit rate may be variable.
  • source node 110 may segment data from the frames of the video source into the plurality of video data packets based on at least the first length and the second length (as illustrated at stage 228 of FIG. 3).
  • the at least one video encoding characteristic may comprise a past frame rate of the video source, a number of frames in a group of pictures of the video source, and/or a past video bit rate of the video source. Additionally, the past video bit rate may be variable.
  • DAF codes are delay-aware fountain codes that may improve streaming high quality video over lossy wireless networks. DAF codes deeply integrate channel coding and video coding. In some embodiments, DAF codes include two techniques: time-based sliding window and optimal window-wise sampling strategy.
  • a basic idea of DAF codes is to segment the video file into overlapping windows, and then encode and send them consecutively with fountain codes. While the non-overlapping block coding scheme has a relatively small block size, the overlap between sliding windows may allow the decoded packets in a previous window to help the decoding of future windows. By doing so, the block size may be virtually extended.
  • the window size W in DAF codes is defined by the maximum tolerable latency T Dday (in the unit of time or number of frames to be transmitted in the window), instead of a fixed number of packets. Therefore this technique is named time-based sliding window.
  • T Dday the maximum tolerable latency
  • the step size between two consecutive windows is At .
  • At 1 herein. This is because both the video length T and window size W are defined to be integral multiples of At , if At > 1 , all the parameters can be down-sampled by a factor of At , and all formulas still hold.
  • the fountain codes algorithm may randomly choose the native packets and combine them into a coded packet, according to degree distribution and sampling probability [2]. Because the windows are overlapping, the total sampling probability of a frame is related to all the windows that cover it, as shown in (1).
  • ASP or accumulated sampling probability
  • the sampling probabilities in each window need to be adjusted in order to obtain a uniform overall ASP.
  • the slope-only description is proposed: the distribution is approximated by a linear function defined by the slope factor
  • the resulting ASP for each frame can be computed by (2).
  • ASP t) s ⁇ t)- a+ DM (2)
  • ⁇ denotes the dot product of the two vectors of ( ⁇ - W + 1) elements
  • DAF codes may aim to find a set of slope factors a , for which the variance of the sampling probabilities of all packets attains its minimum value.
  • the optimization problem is defined in (4). argmin ⁇ ⁇ ASP S (i) - ASP s,a J
  • IDR in-time decoding ratio
  • FDR file decoding ratio
  • DAF and DAF-L can improve the quality of video streaming over lossy wireless network, the inventors have recognized and appreciated areas of improvement:
  • DAF-L decoding performance of DAF-L may be considered relatively low. Although its performance is higher than other delay-aware schemes, there is still a notable gap between DAF and DAF-L ( 10% maximum in decoding ratio). That is because DAF-L does not use the window-wise sampling distribution optimization as in DAF. In exchange, DAF-L is a low-complexity and online algorithm.
  • Some embodiments may reduce the complexity of DAF in order to improve performance for delay- sensitive video streaming and for long videos.
  • the global optimization function of DAF brings the complexity of ⁇ ⁇ ) . Since the computational scale grows cubically with the video length T , the inventors have recognized and appreciated that alternatives may be more practical for long videos.
  • DAF may be an offline scheme. Because the bit rate information of all frames is required to perform the optimization, the whole video file may need to be available before being encoded by fountain codes. Therefore, some embodiments of DAF may not be appropriate or possible for live video streaming applications.
  • MPC Model Predictive Control
  • the minimization function usually takes the form of a quadratic function of the error between the prediction and the target value.
  • the algorithm is iteratively executed each time a new instant is sampled.
  • Various MPC algorithms may only differ with each other in the horizon length, predictive model, and the objective function to be minimized. Note that it is in general not a globally optimal algorithm, since the control decisions are made only based on the history values and the prediction of a finite future horizon.
  • MPC provides a locally optimal online solution to any objective-function-minimizing process control problem, which the inventors have recognized and appreciated as supporting a solution to problems described herein.
  • DAF-M may be considered an offline algorithm.
  • the prediction of bit rate and other practical problems for online algorithms will be discussed further below.
  • ⁇ the index of current time (also the index of current sliding window). Since the window size is W , the frame that was newly added to the encoding buffer is the
  • window size W and horizon length H are independent parameters that serve different purposes.
  • W is typically chosen in accordance with the longest tolerable end-to-end delay. It is specified by the user, so it is an input value that does not change in a communication session.
  • H is a parameter to balance the computational complexity and desired performance. It is chosen by the application according to the computing power, network condition, quality demand, etc.
  • a good target may be similar to the global optimization problem in (4), which is minimizing the variance of ASP.
  • the objective function is limited to a local range. Because the slopes in the horizon [ ⁇ , ⁇ + ⁇ - ⁇ ] can affect the ASP of the frames in [T, T + H + W - 2] , the objective function is the variance over that range as in (5).
  • af denotes the H -length slope vector for the windows starting from ⁇ .
  • P denotes the vector of ASP in the range of [f, ⁇ + H + W - 2] , including both past and predictive values. The calculation of P will be discussed in the following part.
  • P H is the average value over s,a r
  • the process model may play a decisive role in a MPC controller.
  • the chosen model may need to be capable of capturing the process dynamics so as to precisely predict the future outputs.
  • ASP s a (t) is defined in (2).
  • Vector length is equal to the length of a . In the calculation of ASP, s needs to contain W - 1 more elements than a .
  • ASP model is deterministic if we know all the bit rates s and slope parameters a in the future, the process model may no longer be deterministic when a finite horizon is imposed.
  • the ASP in the range of objective function in (5) consists of three parts, all of which may be (H + W - 1) -length vectors representing a part of ASP within the range of [T, T + H + W - 2] . Some of the components only have a part of non-zero elements in that range, which will be pointed out later. • ⁇ ⁇ : the initial ASP that already sampled by previous windows.
  • Non-zero range [f, ⁇ + W - 2] . f*mit - ASP (s ⁇ +! , a _ w+i ), (7) where the index notation in s and a means the elements in these two vectors are the t* to (t + l - if 1 elements from vectors s and a , respectively. Because V init is computed based on known s and previous selections of a , it may have no variable parameter.
  • Non-zero range [ ⁇ , ⁇ + H +W where a is the H -length slope vector to be optimized as in (5).
  • Non-zero range [ ⁇ + ⁇ , ⁇ + H + W
  • only the first element ⁇ ⁇ ( ⁇ ) may be chosen to encode the 7 th window.
  • the optimal slope (11) can be solved by Karush-Kuhn-Tucker (KKT) conditions. Because there are H variables to optimize and 2H conditions for KKT conditions, the optimization process yields a system of equations with 3H equations. If we omit constant factors, the solution involves the generation of a parameter matrix of H x H and the computation of its inverse matrix. The algorithm will be executed iteratively for each window for T times. As a result, the total computational complexity is Since H - T and H does not increase with video length, it can be considered as a linear complexity algorithm for time T . Comparatively, DAF-M may have a much lower complexity than ⁇ ( ⁇ 3 ) of DAF.
  • the DAF encoder may be implemented in an ASIC, an FPGA, or a similar integrated circuit chip.
  • the system may be implemented as a driver controlling network interface hardware or in any other suitable way.
  • the prediction of bit rate in DAF-0 is only ⁇ ( ⁇ ), so the online algorithm may not increase the total
  • FIG. 5a shows the bit rates for CIF video sequence foreman coded with H.264/AVC standard.
  • the inventors have recognized and appreciated that (i) the first W -I slopes in DAF-M (FIG. 5c) and DAF-0 (FIG. 5b) are uniform distributions. That is because there may not be enough past ASP to calculate P init in that range (see (7)), so the slopes in that range are set to 0 as a warm-up period; (ii) the latter part of DAF-M is very similar to that in the globally optimal result of DAF in FIG. 5d, whilst DAF-0 is not, because of its lack of information about the future bit rates.
  • FIG. 6 shows the resulting ASP using the optimized slopes from FIG. 5b-d (including DAF-L, which uses all uniform distributions).
  • the numbers following scheme names in the legend are corresponding variations of ASP, and there is
  • [ ⁇ ] is an Iverson bracket notation, which is defined to be 1 if the condition in square brackets is satisfied, and 0 otherwise.
  • p(c) gives the ratio of frames whose ASP surpasses lc . It is a monotonically increasing function, and its output values are in the range of [0,l] : if c ⁇ lP m£ « , the output value is 0 ; if c ⁇ ⁇ P min , the output value is 1 (where P max and P min denote the maximum and minimum values in P respectively).
  • P max and P min denote the maximum and minimum values in P respectively.
  • ASP reflects the average accumulated sampling probability for a frame, so, under the same code rate, greater ASP of a frame indicates higher probability for it to be sampled than others. It also means, in order to be sampled into at least one coded packet, a frame with higher ASP expects lower code rate, and ASP is inversely proportional to expected code rate. Therefore, if the ASP of a frame is higher than the reciprocal of code rate lc , that frame is likely to be sampled in coded packets under code rate c , thus it has the chance to be decoded on the receiver side. As a result, p(c) represents the ratio of frames that could be decoded under code rate c .
  • FIG. 7 shows the coverage ratio curves of ASP from FIG. 6 and block coding, c is normalized to the range of [ ⁇ , l] .
  • the inventors have recognized and appreciated that the result justifies the gains brought by the proposed DAF codes: when c is greater than 60% of lP min
  • the ASP coverage ratios are over 60% and there is DAF > DAF- M > DAF- O > DAF- L . That means in terms of the ratio of possible decoded frames within that code rate range, in some embodiments, DAF outperforms DAF-M, DAF-M outperforms DAF-O, and DAF-0 outperforms DAF-L.
  • this metric does not fully represent the actual decoding ratio in video communication. It only considers the sampling probability, but (i) it does not imply when the frames are decoded, so it does not represent in-time decoding ratio ( IDR ); (ii) it does not consider the factors of fountain codes, such as degree distribution, codeword length, etc. That is the reason why the p curve of block coding does not look significantly worse than DAF-L in FIG. 7, while the IDR results of block coding is far inferior to any other schemes, as we will see in the next section.
  • the encoding/decoding parts of some embodiments may generally follow the DAF framework in [10], with changes made to the Video Preprocessing Module, especially with implementation of a different optimization algorithm in some embodiments.
  • VMs are connected to the virtual network as a source (or encoder/sender) node running the client application, and a destination (or decoder/receiver) node running the server application.
  • a video is streamed from client to server using different schemes.
  • EMANE is used for emulation of IEEE 802.1 lb on PHY and MAC layer of each wireless node. Because of the forward error correction (FEC) nature of fountain codes, we disable the retransmission mechanism of 802.1 lb for all fountain-code-based schemes. The adaptive rate selection mechanism of 802.1 lb is also disabled. Ad-hoc On-Demand Distance Vector (AODV) protocol is used for routing.
  • FEC forward error correction
  • AODV Ad-hoc On-Demand Distance Vector
  • the communication path from the source to the destination has one hop.
  • the distance between the two nodes is carefully set so that the packets with 1024-byte payload will experience a 10% loss rate.
  • DAF the full optimization version of delay-aware fountain codes in [10].
  • DAF-M the MPC-based DAF codes as described herein.
  • DAF-O the online version of MPC-based DAF codes as described herein.
  • DAF-L the non-optimized version of DAF codes. All the windows may use uniform distributions in some embodiments.
  • S-LT the sliding window LT code from [8].
  • Block the block coding for fountain codes.
  • TCP uses TCP protocol to stream video. In order to add delay awareness, the video file is also segmented into the blocks like in "Block” scheme, but they are sent using TCP.
  • IDR in-time decoding ratio
  • Results of DAF-M and DAF-0 are plotted with dashed lines and dotted lines, resepectively.
  • the different horizon lengths H are indicated by the width of lines and the brightness of colors: the thicker and darker lines indicate larger H , and the thinner and lighter lines indicate smaller H .
  • Various values of H may be chosen for MPC-0 and MPC-M.
  • Table 2 IDR comparisons of DAF-based schemes using different horizon lengths.
  • the decoding ratio of all the schemes is an increasing function of T Dday , and also a decreasing function of C . That means larger delay and lower code rate lead to higher overall performance, which meets our expectation.
  • the performance of DAF may be the highest in some embodiments, while DAF-L may be the lowest in some embodiments.
  • the results of DAF-M and DAF-0 may generally be between those of DAF and DAF-L in some embodiments.
  • the relationships of decoding ratios is consistent with the ASP coverage ratios as seen in FIG. 7.
  • DAF-M may outperform DAF-0 under the same horizon length. That is because DAF-M can be deemed as DAF-0 with "perfect" bit rate prediction. As a result, the gap between DAF and DAF-M is only caused by local bit rate knowledge, while the performance drop from DAF to DAF-0 may come from both limited horizon length and inaccuracy of bit rate prediction.
  • FIG. 9 shows five surfaces of the online schemes.
  • Table 3 IDR comparisons of proposed schemes and existing video streaming algorithms.
  • DAF may have the highest performance, followed by DAF-M, both of which are offline algorithms. Considering the computational complexity of DAF-M may be orders of magnitude lower than DAF in some embodiments, DAF-M may be a more practical offline algorithm in some embodiments.
  • DAF-0 may have the highest performance, followed by DAF-L. As shown in FIG. 9, the surface of DAF-0 is almost always higher than any other scheme.
  • TCP The performance of TCP is relatively low. The reason is that TCP is not suitable for wireless channels where packet loss rate is high [31]. Its congestion control mechanism does not help the performance.
  • Block coding scheme performs the lowest among all schemes, although its ASP coverage ratio is not very low compared to others. The reason is that the blocks are too small and non-overlapping, so the coding overhead is very large [13].
  • FIG. 1 illustrates a system implemented with multiple computing devices, which may be distributed and/or centralized.
  • FIGS. 2 and 3 illustrate algorithms executing on at least one computing device.
  • FIG. 19 illustrates an example of a suitable computing system environment 300 on which embodiments of these algorithms may be implemented.
  • This computing system may be representative of a computing system that implements the described technique of increasing data throughput and decreasing transmission delay from a source node to a sink node via a relay node.
  • computing system environment 300 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 300 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 300.
  • the invention is operational with numerous other general purpose or special purpose computing system environments or configurations.
  • Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments, or cloud-based computing environments that include any of the above systems or devices, and the like.
  • the techniques described herein may be implemented in whole or in part within network interface 370.
  • the computing environment may execute computer-executable instructions, such as program modules.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including memory storage devices.
  • an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 310. Though a programmed general purpose computer is illustrated, it should be understood by one of skill in the art that algorithms may be implemented in any suitable computing device. Accordingly, techniques as described herein may be implemented in a system for increasing data throughput and decreasing transmission delay along a data link from a source node to a sink node. These techniques may be implemented in such network devices as originally manufactured or as a retrofit, such as by changing program memory devices holding programming for such network devices or software download. Thus, some or all of the components illustrated in FIG. 19, though illustrated as part of a general purpose computer, may be regarded as representing portions of a node or other component in a network system.
  • Components of computer 310 may include, but are not limited to, a processing unit 320, a system memory 330, and a system bus 321 that couples various system components including the system memory 330 to the processing unit 320.
  • the system bus 321 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • bus architectures include Industry Standard Architecture (ISA) bus, Micro Channel
  • MCA Multimedia Architecture
  • EISA Enhanced ISA
  • VESA Video Electronics Standards Association
  • PCI Peripheral Component Interconnect
  • Computer 310 typically includes a variety of computer readable media.
  • Computer readable media can be any available media that can be accessed by computer 310 and includes both volatile and nonvolatile media, removable and non-removable media.
  • Computer readable media may comprise computer storage media and communication media.
  • Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by computer 310.
  • 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 includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct- wired connection, and wireless media such as acoustic, radio frequency (RF), infrared (IR), and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
  • wired media such as a wired network or direct- wired connection
  • wireless media such as acoustic, radio frequency (RF), infrared (IR), and other wireless media.
  • the system memory 330 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 331 and random access memory (RAM) 332.
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system 333
  • RAM 332 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 320.
  • FIG. 19 illustrates operating system 334, application programs 335, other program modules 336, and program data 337.
  • the computer 310 may also include other removable/non-removable,
  • FIG. 19 illustrates a hard disk drive 341 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 351 that reads from or writes to a removable, nonvolatile magnetic disk 352, and an optical disk drive 355 that reads from or writes to a removable, nonvolatile optical disk 356 such as a CD-ROM or other optical media.
  • Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
  • the hard disk drive 341 is typically connected to the system bus 321 through an non-removable memory interface such as interface 340, and magnetic disk drive 351 and optical disk drive 355 are typically connected to the system bus 321 by a removable memory interface, such as interface 350.
  • the drives and their associated computer storage media discussed above and illustrated in FIG. 19, provide storage of computer readable instructions, data structures, program modules, and other data for the computer 310.
  • hard disk drive 341 is illustrated as storing operating system 344, application programs 345, other program modules 346, and program data 347. Note that these components can either be the same as or different from operating system 334, application programs 335, other program modules 336, and program data 337.
  • Operating system 344, application programs 345, other program modules 346, and program data 347 are given different numbers here to illustrate that, at a minimum, they are different copies.
  • a user may enter commands and information into the computer 310 through input devices such as a keyboard 362 and pointing device 361, commonly referred to as a mouse, trackball, or touch pad.
  • Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
  • These and other input devices are often connected to the processing unit 320 through a user input interface 360 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).
  • a monitor 391 or other type of display device is also connected to the system bus 321 via an interface, such as a video interface 390.
  • computers may also include other peripheral output devices such as speakers 397 and printer 396, which may be connected through an output peripheral interface 395.
  • the computer 310 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 380.
  • the remote computer 380 may be a personal computer, a server, a router, a network PC, a peer device, or some other common network node, and typically includes many or all of the elements described above relative to the computer 310, although only a memory storage device 381 has been illustrated in FIG. 19.
  • the logical connections depicted in FIG. 19 include a local area network (LAN) 371 and a wide area network (WAN) 373, but may also include other networks.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise- wide computer networks, intranets, and the Internet.
  • the computer 310 When used in a LAN networking environment, the computer 310 is connected to the LAN 371 through a network interface or adapter 370. When used in a WAN networking environment, the computer 310 typically includes a modem 372 or other means for establishing communications over the WAN 373, such as the Internet.
  • the modem 372 which may be internal or external, may be connected to the system bus 321 via the user input interface 360, or other appropriate mechanism.
  • program modules depicted relative to the computer 310, or portions thereof may be stored in the remote memory storage device.
  • FIG. 19 illustrates remote application programs 385 as residing on memory device 381. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
  • Such services may include streaming multimedia, such as video and/or audio, over a network such as the Internet between a streaming server and a client.
  • a streaming service may be over a different network, such as a LAN, where the streaming server may be installed on a computer within the premises of a customer, such as a house or office building.
  • the streaming server may be geographically remote relative to the clients, and the connection between the server and clients may be a dedicated wireless connection.
  • the connection may be over a shared network such as a 5G cellular network.
  • the above-described embodiments of the present invention can be implemented in any of numerous ways.
  • the embodiments may be implemented using hardware, software or a combination thereof.
  • the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.
  • processors may be implemented as integrated circuits, with one or more processors in an integrated circuit component.
  • a processor may be implemented using circuitry in any suitable format.
  • a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone, or any other suitable portable or fixed electronic device.
  • PDA Personal Digital Assistant
  • a computer may have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.
  • Such computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet.
  • networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks, or fiber optic networks.
  • the various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.
  • the invention may be embodied as a computer readable storage medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs (CD), optical discs, digital video disks (DVD), magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above.
  • a computer readable storage medium may retain information for a sufficient time to provide computer-executable instructions in a non-transitory form.
  • Such a computer readable storage medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.
  • computer-readable storage medium encompasses only a computer-readable medium that can be considered to be a manufacture (i.e., article of manufacture) or a machine.
  • the invention may be embodied as a computer readable medium other than a computer-readable storage medium, such as a propagating signal.
  • program or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.
  • Computer-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • functionality of the program modules may be combined or distributed as desired in various embodiments.
  • data structures may be stored in computer-readable media in any suitable form.
  • data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that conveys relationship between the fields.
  • any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags, or other mechanisms that establish relationship between data elements.
  • the invention may be embodied as a method, of which an example has been provided.
  • the acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

L'invention concerne un système de réseau destiné à augmenter un débit de données et à réduire un retard de transmission le long d'une liaison de données, d'un nœud source à un nœud puits, par l'intermédiaire d'un nœud relais. Le système de réseau peut comprendre : un premier noeud conçu pour : prédire au moins une caractéristique de codage vidéo future d'une source vidéo sur un nombre fini de trames futures, coder une pluralité de paquets de données vidéo à l'aide d'un codage sans débit sur la base de l'au moins une caractéristique de codage vidéo future prédite par ajustement adaptatif d'au moins un paramètre du codage sans débit sur la sur la base de l'au moins une caractéristique de codage vidéo future prédite, et transmettre la pluralité de paquets de données vidéo, la source vidéo étant une source vidéo de la pluralité de paquets de données vidéo.
PCT/US2017/022715 2016-03-16 2017-03-16 Système de transmission vidéo en continu en direct au moyen de codes fontaines compatibles avec le retard Ceased WO2017161122A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662309069P 2016-03-16 2016-03-16
US62/309,069 2016-03-16

Publications (1)

Publication Number Publication Date
WO2017161122A1 true WO2017161122A1 (fr) 2017-09-21

Family

ID=59851216

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/022715 Ceased WO2017161122A1 (fr) 2016-03-16 2017-03-16 Système de transmission vidéo en continu en direct au moyen de codes fontaines compatibles avec le retard

Country Status (1)

Country Link
WO (1) WO2017161122A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110191342A (zh) * 2019-07-02 2019-08-30 北京字节跳动网络技术有限公司 视频编码方法及设备、视频解码方法及设备
CN113068065A (zh) * 2021-02-25 2021-07-02 北京邮电大学 一种基于视点预测的低时延流媒体传输方法
CN114900273A (zh) * 2022-03-30 2022-08-12 上海交通大学 一种基于覆盖窗和非均匀采样喷泉码的连续可靠传输方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110170591A1 (en) * 2008-09-16 2011-07-14 Dolby Laboratories Licensing Corporation Adaptive Video Encoder Control
US20130322287A1 (en) * 2011-02-17 2013-12-05 Blackberry Limited Packet Delay Optimization in the Uplink of a Multi-Hop Cooperative Relay-Enabled Wireless Network
US20150179183A1 (en) * 2006-12-12 2015-06-25 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Encoder, decoder and methods for encoding and decoding data segments representing a time-domain data stream
WO2016022982A1 (fr) * 2014-08-08 2016-02-11 University Of Florida Research Foundation, Inc. Codage fontaine et codage réseau conjoints pour un étalement d'informations tolérant à l'affaiblissement

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150179183A1 (en) * 2006-12-12 2015-06-25 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Encoder, decoder and methods for encoding and decoding data segments representing a time-domain data stream
US20110170591A1 (en) * 2008-09-16 2011-07-14 Dolby Laboratories Licensing Corporation Adaptive Video Encoder Control
US20130322287A1 (en) * 2011-02-17 2013-12-05 Blackberry Limited Packet Delay Optimization in the Uplink of a Multi-Hop Cooperative Relay-Enabled Wireless Network
WO2016022982A1 (fr) * 2014-08-08 2016-02-11 University Of Florida Research Foundation, Inc. Codage fontaine et codage réseau conjoints pour un étalement d'informations tolérant à l'affaiblissement

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110191342A (zh) * 2019-07-02 2019-08-30 北京字节跳动网络技术有限公司 视频编码方法及设备、视频解码方法及设备
CN113068065A (zh) * 2021-02-25 2021-07-02 北京邮电大学 一种基于视点预测的低时延流媒体传输方法
CN114900273A (zh) * 2022-03-30 2022-08-12 上海交通大学 一种基于覆盖窗和非均匀采样喷泉码的连续可靠传输方法
CN114900273B (zh) * 2022-03-30 2024-05-24 上海交通大学 一种基于覆盖窗和非均匀采样喷泉码的连续可靠传输方法

Similar Documents

Publication Publication Date Title
CN110620892B (zh) 视频通信中的视频标注技术
EP1709783B1 (fr) Procedes et systemes employant des informations concernant des paquets de donnees afin de determiner un ordre d'envoi des paquets de donnees
CN105393516B (zh) 在自适应流送中用缓冲器和范围约束来进行质量优化的方法、装置及计算机可读存储介质
US20080101466A1 (en) Network-Based Dynamic Encoding
US9510028B2 (en) Adaptive video transcoding based on parallel chunked log analysis
Sun et al. MPC-based delay-aware fountain codes for real-time video communication
Ahmad et al. Adaptive unicast video streaming with rateless codes and feedback
Darabkh et al. Efficient PFD-based networking and buffering models for improving video quality over congested links
Chakareski Wireless streaming of interactive multi-view video via network compression and path diversity
WO2017161124A1 (fr) Système de diffusion de vidéo en continu utilisant des codes fontaine sensibles au retard
WO2017161122A1 (fr) Système de transmission vidéo en continu en direct au moyen de codes fontaines compatibles avec le retard
Sun et al. MPC-based delay-aware fountain codes for live video streaming
JP4732428B2 (ja) 多重記述トランスコーディングのためのトランスコーディング・ノード及びトランスコーディング方法
Nguyen et al. Scalable 360 video streaming using http/2
Darabkh et al. Improving UDP performance using intermediate QoD‐aware hop system for wired/wireless multimedia communication systems
WO2025259937A1 (fr) Systèmes et procédés dynamiques pour distribution de contenu de protocole de transport en temps réel à faible latence ou à ultra faible latence sensible au support
Wang et al. Adaptive VR video data transmission method using mobile edge computing based on AIoT cloud VR
Kurdoglu et al. Perceptual quality maximization for video calls with packet losses by optimizing FEC, frame rate, and quantization
CN112040235B (zh) 视频资源的编码方法和装置，视频资源的解码方法和装置
Sun et al. Unequal error protection for video streaming using delay-aware fountain codes
Roder et al. Branch and bound algorithms for rate-distortion optimized media streaming
남우승 Exploring Compressive Transmission with Neural Compression for Efficient Data Communication
CN106875416B (zh) 用户终端和用户终端的基于多播的内容接收方法
Kovács et al. Receiver heterogeneity helps: Network coding for wireless multi-layer multicast
Lima et al. Optimal rate allocation for p2p video streaming

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17767526

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17767526

Country of ref document: EP

Kind code of ref document: A1