WO2006012496A2 - Trickmodes and speed transitions - Google Patents
Trickmodes and speed transitions Download PDFInfo
- Publication number
- WO2006012496A2 WO2006012496A2 PCT/US2005/026011 US2005026011W WO2006012496A2 WO 2006012496 A2 WO2006012496 A2 WO 2006012496A2 US 2005026011 W US2005026011 W US 2005026011W WO 2006012496 A2 WO2006012496 A2 WO 2006012496A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- frames
- frame
- trickmode
- data
- packet
- Prior art date
Links
- 230000007704 transition Effects 0.000 title description 36
- 238000000034 method Methods 0.000 claims abstract description 134
- 238000013500 data storage Methods 0.000 claims abstract description 6
- 230000005540 biological transmission Effects 0.000 claims description 8
- 238000007906 compression Methods 0.000 claims description 6
- 230000006835 compression Effects 0.000 claims description 6
- 230000006837 decompression Effects 0.000 claims description 6
- 238000004891 communication Methods 0.000 claims description 5
- 238000012544 monitoring process Methods 0.000 claims 2
- 238000009826 distribution Methods 0.000 description 10
- 238000003780 insertion Methods 0.000 description 9
- 230000037431 insertion Effects 0.000 description 9
- 238000003860 storage Methods 0.000 description 9
- 102100037812 Medium-wave-sensitive opsin 1 Human genes 0.000 description 8
- 230000008569 process Effects 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 7
- 238000013459 approach Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000005457 optimization Methods 0.000 description 5
- 238000012163 sequencing technique Methods 0.000 description 5
- 230000000007 visual effect Effects 0.000 description 5
- 230000003139 buffering effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000001824 photoionisation detection Methods 0.000 description 3
- 238000001094 photothermal spectroscopy Methods 0.000 description 3
- 238000012935 Averaging Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000013480 data collection Methods 0.000 description 2
- 230000008707 rearrangement Effects 0.000 description 2
- 238000004904 shortening Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- UTOGVBKEQYRZJE-UHFFFAOYSA-N PPPPPPPP Chemical compound PPPPPPPP UTOGVBKEQYRZJE-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000003752 polymerase chain reaction Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
- H04N21/4347—Demultiplexing of several video 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
-
- 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/103—Selection of coding mode or of prediction mode
- H04N19/114—Adapting the group of pictures [GOP] structure, e.g. number of B-frames between two anchor frames
-
- 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/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
- H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
-
- 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/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
-
- 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/2365—Multiplexing of several video 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/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
- H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
-
- 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/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
- H04N21/26233—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving content or additional data duration or size, e.g. length of a movie, size of an executable file
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/91—Television signal processing therefor
- H04N5/93—Regeneration of the television signal or of selected parts thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/12—Systems in which the television signal is transmitted via one channel or a plurality of parallel channels, the bandwidth of each channel being less than the bandwidth of the television signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
- H04N7/17309—Transmission or handling of upstream communications
- H04N7/17336—Handling of requests in head-ends
Definitions
- the disclosure generally relates to techniques for transmitting video data.
- Video frames may be used to represent data that is capable of being fast forwarded, rewound, paused, stopped and played. The amount of data transmitted or received associated with those video frames for a given time period or timeslot may be used to determine available bandwidth.
- One type of video frame may be referred to as a "trickmode" frame, which is used in many different video transmission methods.
- Managing transmission of video frames in video transmission is one consideration in order to achieve desired video production quality.
- trickmode frames there may be unpredictably and variation in the amount of data associated with a given frame, which may contribute to management issues.
- a timeslot technique may be used where each slot has a fixed amount of bandwidth large enough to transmit the largest trickmode frames.
- Bandwidth may be unused for other shorter trickmode frame, where the timeslot is larger than required. This may result in an increased amount of unused bandwidth.
- Figure 1 provides an example video buffer level
- Figure 2 provides an example technique that increases the length of a subject Group of Pictures
- Figure 3 illustrates an effect of a sequence of video frames on a buffer level
- Figure 4 provides a distribution curve for a video stream
- Figure 5 provides an illustration of a trickmode packet adjustment
- Figure 6 is a graphical depiction representing the effect of shifting a trickmode packet on buffer levels
- Figure 7 illustrates how buffer optimization may be used to produce a trickmode stream
- Figure 8 provides an output of a trickmode video stream
- Figure 9 provides an illustration of a splicing technique
- Figure 10 is a system for communicating a data stream
- Figure 11 is a flow diagram of a method for communicating a data stream.
- Figure 12 is a flow diagram of a method for controlling a data storage level.
- the disclosed embodiments provide techniques to achieve efficient bandwidth usage in communicating video data, like trickmode video streams, while maintaining buffer levels that provide desirable video playback conditions. It should be appreciated that while the embodiments are discussed in the context of Motion Pictures Expert Group (MPEG) techniques, the described techniques may also be employed with other types of data compression/decompression techniques.
- MPEG Motion Pictures Expert Group
- video may be divided into frames.
- MPEG uses at least three different types of video frames: I-, P-, and B-frames.
- I-frames or "intra coded frames" include intra-frame macroblocks that may allow an I-frame to be decoded without any other previous or future frames in the sequence.
- a decoder may start decoding from an I-frame.
- I-frames may be inserJ&Cevle ' ry '' used to start a sequence, allowing video to be played from random positions and for trickmode features, like fast forward and reverse, for example.
- P-frames are coded as differences from previous frames.
- a new P-frame may be predicted by taking a prior frame and predicting values for a new pixel of the current frame.
- P-frames may provide a higher compression ratio depending upon the amount of motion present.
- B-frames or "bidirectional frames" are coded as differences from a previous or subsequent frame B-frames and may use previous and subsequent frames for accurate decoding.
- the order of the frames as read may not be the same as the displayed order.
- a subsequent frame may be transmitted and decoded prior to the current B-frame, but presented after the current frame.
- a display sequence of frames Ii B 2 B 3 P 4 B 5 B 6 P 7 may be reordered and transmitted as Ii P 4 B 2 B 3 P 7 B 5 B 6 .
- Sequences of MPEG video may include a Group of Pictures (GOP).
- GOP Group of Pictures
- Each GOP includes video frames.
- GOP structures are associated with the number of frames they contain (N) and the distance between two reference frames (M).
- these structures may vary and some may include, for example, P-frame only streams, like PPPPPPPP.
- a trickmode GOP is a video sequence containing an I-frame and a variable number of dummy B-frames and P-frames.
- the trickmode GOP size may be associated with the number of frames in a trickmode GOP.
- a GOP structure of IBBPPP has a GOP size of 6.
- a timeslot of a GOP or trickmode packet may be a period that goes from the I-frame DTS (decode timestamp) to the following I-frame DTS.
- a trickmode packet may be associated with a trickmode GOP, and may include data to tailor a valid transport stream.
- the trickmode packet may include a Program Allocation Table (PAT) table, a Program Map Table (PMT) table, transport stream packets that have Program Clock Reference (PCR) only ⁇ e.g., no data) for synchronization referenced as "Sync" packets, a trickmode GOP and filler null packets having variable size.
- PAT Program Allocation Table
- PMT Program Map Table
- PCR Program Clock Reference
- the size of a trickmode packet may be based on the trickmode packet itself.
- the size of the trickmode packet may also accommodate for storage overhead, network overhead, and bitrate control.
- a file segment that includes an I-frame may also contain other packet identifiers or "PIDs" ⁇ e.g., PAT, PMT, audio) that are multiplexed at the transport stream level.
- PIDs packet identifiers
- the block may be read into memory, and non-video packets may be replaced by nulls ⁇ e.g., "muting").
- a trickmode packet may also be a multiple of 1316 bytes ⁇ e.g., MPEG2 tranf ⁇ S; lrpdW@@ ⁇ er at#i;tii;!p
- Figure 1 provides an example video buffer level for I-frame-based trickmodes using fixed timeslot allocation.
- each GOP includes 7 frames. Other sizes of GOPs may be used.
- the horizontal scale (t) depicted in Figure 1 is given in frame periods (e.g., 1/30 second).
- the "trickmode GOP" structure may be IBBPPPP or an I-frame followed by 2 dummy B-frames and 4 P-frames. This structure produces seven I-frames every 30 seconds, or 4.28 I-frames per second.
- a GOP may be received before the interval at which it is ready to be decoded and presented, an interruption to the decoding process may not occur. However, because a GOP may be received before the interval at which it is ready to be decoded and presented, there may be unused bandwidth. This unused bandwidth is depicted as the cross-hatched rectangular area in Figure 1.
- the length of the GOP and timeslot may be a function of the size of the subsequent GOP. For example, as reflected by the sample distribution in Figure 1, some I-frames may require timeslots as short as two frames, while others may be as long as six frames.
- Figure 2 provides an example technique that increases the length of the subject GOP based on the GOP that follows the subject GOP.
- the amount of unused bandwidth (as indicated by the cross-hatched rectangular sections) may be reduced to just one interval length by making the total interval random for each GOP.
- the first GOP has a four frame interval
- the second GOP has 5 intervals.
- the trickmode sequence generated may introduce new I-frames that are presented at random lnter ⁇ a ⁇ . » ,. ⁇ *t> »* *... ⁇ >I.J» i> ⁇ u , , » , !• n ,,n ,>> ,, ⁇ ,,,
- Figure 1 and Figure 2 may operate on the assumption that the video buffer will be empty after every GOP is decoded, because the buffer contains the remaining dummy P-frames and B-frames that have a negligible size.
- a data ingest process may decode one frame every "N th " frame received in order to generate an "N-speed" trickmode stream. For example, in order to generate an 8x stream, the ingest process may decode frames 1, 9, 17, 25 . . . (8n+l). These frames may then be used to generate a MPEG2 transport stream, such that the resulting stream may contain, for example, 30 unique frames per second. The sequence of frames may then be encoded into a new MPEG2 transport stream that may preserve some characteristics of the original transport stream, like frame rate, bitrate, PID assignment, video format, and video buffer characteristics (e.g., buffer size and buffer level for a smooth speed transition). This technique may offer greater trickmode quality. It also may use greater processor power and additional storage overhead (e.g., typically 30%).
- I-frame-based trickmodes also may insert dummy B- frames and P-frames.
- P- and B- frames may be encoded using frame prediction, which may result in frame jitter.
- frame prediction For example, in those embodiments using broadcast television (i.e., National Television System Committee (NTSC)) each frame may be composed of two interlaced fields, giving a total of sixty fields per second.
- NTSC National Television System Committee
- a "3:2 pulldown" method may be used to convert a movie into television content.
- the "3:2 pulldown" method may convert a frame alternately into three and two fields. For example, 4 frames at 24 fps (i.e., 1 frame every 6 seconds) will produce 10 fields or 5 complete frames at 30 fps.
- a frame When using interlaced mode for encoding (as compared to progressive mode), a frame will contain two fields - A at the top and B at the bottom. If frame prediction is used to generate dummy B-frames and P-frames, the decoder may copy both fields from the reference picture or I- frame. Therefore, for example, a trickmode GOP with the structure IBBPP would cause the decoder to produce a sequence of five fields (two AB for each frame) having the structure AB AB AB AB AB.
- An I-frame may contain fields that are originated from two different pictures, a sequence of fields AB AB AB AB may cause an impression of "jitter.”
- reference frames used by B and P-frames may be broken when copying those frames to the output stream. This may be due, in part, to the fact that trickmode files may be generated by picking one frame out of N fr ⁇ pf$ llA.s"i,jf ⁇ M
- IBBPBBPBBPBBPBBIBBPBBPBBPBBPBBIBBP may be represented by IBBPBBP with respect to the trickmode sequence.
- B-frames that are in an original video frame sequence may depend on previous and subsequent I and P-frames that are not a part of the trickmode sequence file.
- some frames may be encoded differently in the trickmode file, depending on where they are inserted in the sequence.
- an I-frame in the original sequence may be encoded as a P-frame in the trickmode file and a B-frame may become a P- frame or even another B-frame with entirely different reference frames.
- Typical bandwidth rates used in the cable industry include a 3.75 Mbits/s, 30 frames per second stream that is ingested at 3.75 Mbits/s, as described in the CableLabsTM Content Specification 1.0 [4].
- VOD video-on-demand
- four encoders may be used to generate up to four different trickmode files in parallel by processing frames extracted and decoded from the original video stream.
- Each trickmode encoder may receive at 2 frames per second (fps) (30/15), 2 fps (30/15), 0.5 fps (30/60), and 0.5 fps (30/60), for a total of 5 frames per second over all four encoders.
- fps frames per second
- a 2.4 GHz PentiumTM 4 processor allows for the encoding of 12 streams with an ingest bandwidth of approximately 45 Mbits/s.
- the resulting trickmode files will be respectively about 6.7%, 6.7%, 2.2% and 2.2% of the original file size for a total of about 16.6% storage. Therefore, in some embodiments, generating standard trickmode files may require a great deal of computer processing power and sophisticated computer logic.
- the process may fully decode some frames, while others like B-frames may not be decoded.
- I-frames may be used for random access mechanisms because displaying these frames does not depend on previous or subsequent frames. Therefore, for some embodiments, trickmodes may be used by merging I-frames into a newly created stream and inserting null packets to control bitrate.
- the time to communicate an I-frame may be longer than a frame interval. For example, for an average I-frame size of 40kb, an I-frame-only trickmode stream at 30 fps would require at least 9.8Mbits/s (40kb x 8 x 30), or about 2.6 times the rate of 3.75 Mbits/s generally used in the cable industry.
- an I-frame may be displayed for two or more frame periods or intervals, allowing a subsequent I-frame to be transmitted and buffered.
- "Dummy" B-frames or P-frames that may be a copy of a last displayed frame may be inserted into the video stream.
- "Dummy" or duplicated frames in one embodiment, may be "no-motion" frames having a reduced size as compared to an average I- frame size. Dummy frames may provide processor efficiency because they may be encoded at substantially the same time, and may be inserted in the output stream to extend the size of the GOP.
- a trickmode stream with a rate of 10 I-frames/s may be accomplished via the creation of "trickmode GOPs" or trickmode sequence of video frames.
- a sequence of "trickmode GOPs” may be created with one I-frame followed by two dummy B-frames to create the following sequence: IBBIBBIBBIBBIBB, for example. If, for example, the size of the dummy B-frame is approximately 1.2kb, the average bitrate of the output stream would be 3.5Mbits/s ((40kb*8*10 I-frames/s) + (1.2kb*8*20 B-frames/s)), or within a maximum bandwidth rate of 3.75Mbits/s.
- timeslot allocation and trickmode GOP sizes are adjusted dynamically in an I-frame-based trickmode stream to facilitate efficient bandwidth usage.
- the techniques further monitor video buffer utilization by detecting and preventing buffer overflows.
- "Dummy" P-frames may be inserted.
- the techniques may also be used to maximize bandwidth utilization, while keeping buffer levels at minimum levels and increasing system responsiveness as processing speed changes. For example, in order to generate an 8x stream, the techniques may provide approximately 10 unique I-frames per second on average. The remaining frames (e.g., 20 frames per second in a 30 frame per second stream) may be dummy or non-motion B-frames and P- frames.
- the techniques are incorporated in a video stream software product.
- the techniques also may be accomplished using hardware, firmware or any combination thereof.
- a video ingest stream may be parsed using a data structure.
- a "Hinter” structure and the parsed data i.e., I-frame and stream information
- the video ingest may be conducted, for example, at approximately 300Mbits/s by a typical Pentium 4TM 2.4GHz processor.
- the HINT file flaa&'flr ⁇ t ⁇ ct ⁇ ! 4;;Jii ⁇ r,tljati
- the HINT file also may include an I- frame table that is approximately 128 bytes per I-frame and may have a pointer to the location of the associated I-frame.
- a two hour-long movie at 3.75Mbits/s having 2.0 I-frames/s (i.e., 14400 I-frames total) will produce a HINT file of approximately 1.9Mbytes in size, which is less than about 0.06% of the original file size.
- the techniques for example used in streaming software and/or hardware, may generate a trickmode stream dynamically.
- Figure 3 illustrates the effect of a sequence of I-frames on the buffer level.
- the vertical axis represents decode times of the I-frames.
- trickmode packets are "packed" by making use of buffering.
- a large sequence of I-frames may cause buffer levels to increase for a short period of time with little or no impact on the frame rate.
- dummy P- and B-frames are also transmitted and decoded, they are about 30 times smaller than I-frames or approximately 1.3k each.
- the techniques used to adjust the buffer level may be derived from a fixed timeslot trickmode sequence. Such a sequence may be similar to the sequence discussed with reference to Figure 1. Also, in order to achieve relatively greater visual quality, the techniques attempt to generate a substantially constant rate of I-frames.
- the video stream may include I-frames having any distribution, for the purposes of understanding and clarity, the following description assumes that the inputted video stream includes I-frames with a certain size distribution curve as depicted in Figure 4.
- the contemplated techniques may redistribute unused bandwidth in timeslots containing undersized I-frames to accommodate oversized I-frames. This may be accomplished, for example, by choosing an adequate trickmode timeslot size (i.e., based on GOP sizes) and selecting a large enough timeslot adjustment or window to ensure that a set of trickmode packets may be adjusted or rearranged without causing the buffer to overflow.
- an adequate trickmode timeslot size i.e., based on GOP sizes
- the contemplated techniques may employ statistical averaging to accommodate the GOP size of any sequence of trickmode packets. In one embodiment, averaging may be accomplished by ensuring that the GOP size is less than or at least equal to the size of the packet adjustment.
- the techniques may include decoding and associated buffering. Furthermore, managing the quantity of buffered data may be performed to prevent buffer overflow or underflow conditions.
- p ⁇ tP ⁇ S ⁇ l liJ ⁇ jSgirfc ⁇ p ⁇ f ap illustration of the trickmode packet adjustment.
- upper window 501 illustrates how certain oversized trickmode packets may not fit in the fixed and available timeslots. For example, although trickmode packet 506 fits within the fixed timeslot 503, trickmode packet 504 does not fit within the subsequent timeslot 505. As a result, a portion of trickmode packet 504 runs over into timeslot 507.
- Lower window 502 illustrates how the timeslots may be rearranged or reordered. Such rearrangement permits the use of available bandwidth or "nulls" from previous or subsequent trickmode packets to be used in larger trickmode packets.
- the amount of data Q that may be transmitted in a give timeslot may be represented as follows:
- the I-frame rate r may be calculated as:
- q may be maintained as an integer for better visual quality by providing a constant number of frames per GOP.
- q also may be allowed to vary (i.e., GOP size would vary) from GOP to GOP.
- Other possible embodiments may use an average value for q. For example, a value for q of 2.4 frames may be established for a sequence of GOPs having sizes 2, 3, 2, 2, 3 and providing 12.5 I-frames per second.
- ⁇ ps(ckets, and disk and network overheads may need to be considered.
- These values may be estimated.
- I-frame size in the original stream may have a certain size distribution (/, 07) that may not necessarily follow any particular distribution curve.
- Disk or storage overhead may be estimated in determining trickmode packet size.
- the above estimations may result in an overestimation of the video buffer level by approximately 10%.
- in a 40KB block obtained directly from storage it may be necessary to transmit less than or equal to 36kB of actual video data that will be stored in the video buffer.
- the remaining 4kB may include other PIDs ⁇ e.g., audio, PMT, PAT) that are embedded in the block and have been "nulled” or "muted” before sending.
- the video data may be rearranged and about 36kB of video data may be sent.
- the disclosed techniques may establish a limit a 90% of buffer capacity. This 90% limit also may prevent greater error in the described methods.
- the probability of the buffer level reaching 90% of its limit is relatively low because it requires a relatively large sequence of oversized I-frames in the trickmode sequence.
- the probability of detecting buffer overflow is increased, yet without creating much degradation in the trickmode performance.
- the total amount of streaming data (T n ) contained in the adjustment window with n timeslots may be reflected by the following equations:
- the disclosed techniques may attempt to maintain a low probability of having to execute corrections ⁇ , where ⁇ > P(T n > Q n ) to a value on the order of 10 -3 .
- n may be large enough to satisfy the following equation:
- the described techniques allow a trickmode stream at about 10 1-frames per second.
- the bandwidth utilization is approximately 97% (i.e., 44587 bytes divided by 45922 bytes).
- the actual bandwidth utilization percentage may be reduced by the need to make corrections due to buffer overflow (e.g., p-frame insertion).
- the adjustment window size (N) is set to 64 samples ⁇ is 10 ⁇ 3 and the I- frame rate allowed is calculated. This may be accomplished by collecting statistics from the stream and calculating the maximum trickmode speed.
- the I-frame statistics may be stored in a "HINT" file associated with the stream, as previously discussed.
- the buffer adjustment techniques may require a set of parameters to be calculated from each trickmode packet. These parameters may be directed to I-frame selection, I-frame data collection and initialization of control variables.
- I-frame selection a sequence of I-frames to generate a trickmode stream at certain speed (e.g., 15x, 30x, -10x%) may be determined.
- the I-frame sequence may be determined based on the speed (s), GOP size selected (q), and information extracted from the original stream, like frame rate (f r ) and average number of I-frames per second in the stream (I 1 -).
- I r may be calculated as part of the hinting process, when the MPEG2 file is first ingested and stored in the HINT file.
- the index increment may be used to calculate a sequence of I-frame indexes (x), which are also variable.
- the actual I-frame may be obtained by rounding the sequence of indexes provided in the following example.
- the resulting index increment may be less than 1.0 and cause repeating frames.
- some embodiments may handle GOP size (q) as a variable or floating point, so that the index increment may be bounded to 1.0 and q may assume a non-integer value, for example, 3.75. This will produce a sequence of GOP with sizes of 4, 4, 4, 3, etc.
- I-frame data collection once the sequence of I-frames is determined, information regarding an I-frame may be collected and some data structures may be initialized (e.g., one or more per trickmode packet). The data may be obtained from the Hint file by simply pointing to the appropriate I-frame entry.
- Start data is the offset of the transport stream packet that includes the PES header associated with an I-frame. This may be the offset where the I-frame begins.
- End data also may be collected. End data may be the last offset of the I-frame in file. This is the offset past the last I-frame video data. It should be appreciated that between the start and end offsets, other non-video transport stream packets may be present in the file. These packets may be converted into nulls before streaming.
- Size data also may be collected. Size data may be calculated as the difference (end minus start) that is the amount of data that may be sent that contains an entire I-frame. "TirfeqOd$",d4$i:$ ⁇ $$$ ftfay flessnesspllecged , , Timecode data may provide interfaces with other components that eventually query the current timecode being streamed. The timecode may be found in the GOP header and extracted during the hinting process.
- File PCR data also may be collected.
- File PCR data may be associated with the start offset to allow streaming software to perform PCR restamping.
- File DTS data may be collected and is associated with the I-frame in the original asset to perform DTS restamping and to perform smooth buffer transitions between regular play and trickmodes and back to regular play.
- File PTS data may be collected and is associated with the I-frame in the original asset to perform Presentation Time Stamp (PTS) restamping and to preserve the frame interval in all transitions.
- PTS Presentation Time Stamp
- CC Start and CC End data may be collected.
- CC Start data is transport stream continuity counter of the start packet.
- CC End is continuity counter of the end packet.
- CC Start and CC End data may be needed in some embodiments in order to perform CC restamping.
- next field data may be collected.
- I-frames may be encoded using the "repeat first field” flag, so they contain three fields rather than two.
- a field adjustment mechanism may be used in the first dummy B-frame following a transition.
- stream offset may be the total amount of data produced by the streaming software, which is different from the file offset.
- the stream PCR may be the actual PCR observed at the output stream, after the PCR restamping mechanism. Because the streaming software operates at a constant bitrate, stream offset increments may be associated with stream PCR increments.
- frames is the number of frames, or may be the GOP size of the current trickmode packet. Initially set to the number q previously calculated, this number may be incremented as needed (e.g., p-frame insertion mechanism). If q is implemented as a floating point or variable, the number of frames may be calculated based on an error propagation mechanism shown below (i.e., q_error initated with value of 0):
- the packet size may be based on the timeslot of the previous packet and may produce a non-integer number of TS packets. This may be corrected by means of an error propagation mechanism, which may take into account the excess from the previous trickmode packet. At this point a certain granularity to the entire trickmode packet may be enforced, such as 188 bytes (Transport Stream packet size) or 1316 bytes (MPEG2 over UDP packet size).
- the first trickmode packet may be treated differently, depending on the state of the streaming engine. For example, if the streaming engine was inactive (i.e., pause and stop), there may be no risk for buffer underflow since the decoder is inactive. The packet size may be set to zero and available for modification by the adjustment technique. If, on the other hand, the streaming engine was playing, the first timeslot may be calculated based on difference between the DTS of the last frame displayed at normal speed and the current PCR. In other words, the first trickmode packet may be decoded after the buffer is substantially depleted from "normal play” data. This may be the "debuffering" technique used to transition from "Play” to "Trickmodes.”
- the sequence that calculates the trickmode packet size may be based on the timeslot of the previous packet (frames[j-l]*f r ).
- the packet size and packet excess may be floating points or variable and may be calculated as follows:
- Packet excess may be a control variable used to enforce a certain granularity to trickmode packets, and may be used by the P-frame insertion technique to preserve the granularity when extending packet sizes.
- Data size may represent the total data size, including I- frame, dummy B- and P-frames, PAT, PMT and overhead associated with assembling the trickmode packet.
- Bw balance may represent available bandwidth for buffer adjustment. This may be the difference between the packet_size and the data_size. Unused bandwidth may be filleiji' ⁇ yittpiultsSi iprsetyingtfe s . tjrer ⁇ bitrate.
- Minimum size of a trickmode packet may be imposed in some embodiments. This may be accomplished by making less bandwidth available for adjustment than the actual available bandwidth calculated.
- hardware limitations such as minimum “seek time” or minimum delay between trickmode packets that may be imposed by hardware constraints may be considered when determining the size of the trickmode packet. Also, these considerations may be included in the calculation of q, because it changes some assumptions about how trickmode bandwidth may be used.
- null packets that will be available for adjustment, for example, 1316 for transport stream over UDP packets. This may depend on a particular implementation of streaming software or hardware.
- the available bandwidth may be calculated as follows:
- Bw_balance often may assume negative values representing an oversized packet.
- the negative value may be the amount of bandwidth missing for that trickmode packet that needs to be taken from other trickmode packets. This may be accomplished by balancing bandwidth required by large packets through using available bandwidth from small packets. The statistical analysis may be used to ensure that the overall balance of available bandwidth in the adjustment window is positive ( ⁇ bw_balance[i] > 0), depending on the parameter ⁇ .
- Stream offset may be the current stream offset expected for a packet. If the current packet is the first to be sent, that packet may be the stream offset taken from the streaming engine as discussed above.
- Stream PCR may be necessary for precise PCR restamping of video data retrieved from disk.
- Stream DTS may represent the decode time of the I-frame to be sent as part of the trickmode GOP.
- DTS and PTS may be in the same time base as the PCR by multiplying them by 300. If there is a transition from play to trickmodes, the DTS may need to be corrected by half of a frame in order to allow field adjustment as described before. Otherwise, the trickmode packet DTS is calculated as:
- the actual buffer level may be less than the above value.
- the buffer level may be overestimated to guard against overflow.
- buffer Jevel Q] size[j]+(frames[j]- 1)*P.
- Figure 2 illustrates a decode buffer over time.
- the described embodiment may control the buffer level before the I-frame is decoded, at the instant given by DTS[J]. This is due to buffer adjustment causing the buffer level peak to move to this position. Because the size of dummy B- and P-frames from the previous trickmode packet may be relatively small, the formula with "Stream DTS" representing the decode time may be used without risk, especially because the I-frame size is overestimated as discussed. Alternatively, to ensure the buffer will not reach overflow, the formula where "Stream offset" is the current stream may be used.
- Figure 5 illustrates how trickmode packets may be adjusted in order to rearrange the available timeslot intervals.
- the control variable bw_balancel[j] is negative, it indicates that the packet cannot be transmitted in its initially reserved timeslot.
- the inventive techniques shift and extend the packet size and consuming the available bandwidth from previous packets, while shortening the packet, as shown in Figure 5.
- C code that shifts and extends the packet size and consumes the available bandwidth from previous packets, while shortening the packet may be as follows:
- This code segment may allow the available bandwidth to be rearranged in the adjustment window, and may ensure that the trickmode packets are completely transmitted before their decode time (DTS) is due.
- DTS decode time
- the first trickmode packet bw-balance[j] may be negative, and because it is the first packet in the sequence there is may be no previous packet from which to allocate bandwidth.
- P-frame insertion and transition techniques may be used as described below.
- the control techniques calculate parameters of each trickmode packet, it may not necessarily generate the stream. This may be accomplished by a streaming engine that uses the adjustment techniques to generate the trickmode stream.
- Figure 6 is a graphical depiction representing an effect of shifting a trickmode packet on the buffer levels. Although Figure 6 discusses the effect on buffer level with respect to shifting a trickmode packet, it should be appreciated that other bandwidth control techniques as well as other data manipulation techniques may require buffer control in some embodiments.
- a top window 600 reflects the buffer level before the trickmode packet is shifted, while a bottom window 601 reflects the buffer level after the trickmode packet is shifted in accordance with bandwidth control.
- the packet 602 is not fully received until after DTS at point 603 (i.e., when the decode time is due). Shifting the trickmode packet may create a maximum buffer storage level 604 at DTS.
- the maximum buffer level may be equal to the amount of data in the trickmode packet 605 that has been shifted.
- the difference (data_size[j] -packet_size[j]) may be ready at the decoder buffer at the instant DTS[J-I] in order to allow full buffering of the trickmode packet before it can be decoded.
- Buffer levels may increase each time an oversized frame is sent (i.e., a frame with size above the reserved timeslot). Buffer overflow may occur when adjusting a long sequence of oversized frames. Once an amount of data larger than the available timeslot is determined, it may be desirable to take action to accommodate the buffer overflow. This may be accomplished using any number of techniques. The following examples are not meant to be exclusive of all techniques contemplated by the embodiments.
- P-frame insertion adds P-frames and thus extends the size of a previous GOP in order to generate additional bandwidth. Inserting additional P-frames may be accomplished in a number of ways. One technique for inserting P-frames to generate additional bandwidth will be discussed. However, the disclosed embodiments are not limited to this approach. One example is as follows.
- a trickmode stream having a 3.75Mbits/s video stream with a large trickmode be transmitted.
- the timeslot is only four frames as determined by the GOP size of the previous packet.
- the packet may be shifted and extended by two frame periods to accommodate the additional periods for transmission.
- shifting the trickmode packet two frames may cause an increase in the peak buffer level of the previous packet by approximately 30kb. For a video buffer size of 100kb and a previous packet size of 90kb, trying to buffer another 30kb would cause a buffer overflow.
- Dummy P-frames may be added in one embodiment. For example, if two extra P-frames are added, where each is approximately lkb per P- frame, the previous GOP size may be increased to six. The buffer level is increased only by 2kb up to 92kb and still within the 100kb limits. By adding the two additional dummy P-frames to the previous GOP, the current packet size may be extended to allow the entire "oversized" packet to be transmitted. In other words, this technique holds the previous frame in the screen for an extra two frame periods, allowing the oversized frame to be completely transmitted. Moreover, because each additional P-frame that is inserted may extend the subsequent trickmode packet by about one frame period, additional bandwidth may be obtained. In this example, each approximately lkb of dummy P- frame generates about 15kb of bandwidth, which represents the amount of data that can be transmitted in one frame period.
- the overall I-frame rate may be reduced and the adjustment window may be extended one frame.
- a code segment example capable of inserting an extra frame every time a buffer overflow is detected is shown below.
- Some embodiments also may be concerned with analyzing the granularity of trickmode packets that may, for example, be at least one transport stream packet (e.g., typically 188 bytes).
- the error propagation technique may generate the following sequence of packet sizes 61852, 61852, 63168, 61852, 61852, 63168, and 61852.
- the technique also may generate packet offsets of 0, 61852,123164,186332, 248184, 310036, and 373204 with bw_balance values of 35532, -31584, 21056, -10528, -21056, -19740, and -21056.
- the null sizes may be calculated as the difference (packet_size minus data size), as shown below (note: timestamps will be omitted at this time (PCR, DTS, PTS)):
- packet sizes may be recalculated based on the new GOP sizes using the same error propagation technique described above with respect to packet_size.
- Figure 7 illustrates how buffer optimization may be used to produce a trickmode stream.
- packets that require adjustment are shown cross-hatched, while successfully adjusted packets are shown dotted.
- the top window 700 shows the trickmode packets as they are first calculated, and before the buffer optimization techniques are employed.
- the second window 701 shows how the last oversized frame is extended and shifted, causing the previous frame to have its available bandwidth consumed.
- the second window 701 also shows how shifting the same packet may effect the buffer level.
- the third window 702 illustrates the successfully adjusted packets.
- Figure 8 provides an example output of a trickmode stream generated using these techniques.
- I-frame based techniques may work in "low delay" mode, so buffer levels are kept low at the decoder.
- the decoder may buffer from 0.5s to 1.0s of data. The difference in buffer levels may cause buffer underflow, which may cause the screen to roll or flicker, or even go black for a while.
- File-based trickmodes may switch between trickmode files and regular files. This technique may require buffer levels to match at the transition points, and therefore buffer levels may be controlled when trickmode files are generated. Additional logic may be added to adjust the buffer levels at the transition point.
- the buffer management technique may act to modify the last trickmode frames (typically 2-4 frames) by increasing buffer levels for a more precise transition.
- This so-called "splicing" technique may reduce the speed of the last frames, creating a bandwidth in excess that may be used for rebuffering, and level.
- This technique may be implemented in a way that does not interrupt the sense of motion, so the transition is relatively seamless.
- the play data that may be stored in a video buffer is consumed by the decoder. This occurs when the trickmode stream starts being decoded, and the data present in the video buffer is the data generated by the trickmode streaming engine.
- the first trickmode packet may be sent having its DTS set to the DTS of the last frame being played plus a frame interval. Also, the PTS may be set to the PTS of the last frame displayed plus one frame. If the "repeat first field" flag of the last frame is set to 1, PTS and DTS are incremented by a half of a frame period.
- some video streams may use some special flags "repeat first field” and “top field first” as a method of performing 3:2 pulldown.
- the certain techniques may be applied in the transition sequence.
- one technique may be used where the last frame displayed has its "top field first” set to 0 (bottom first) and its “repeat first field” set to 0. This indicates that the last frame finished displaying the top field. If the last frame has its "top field first” set to 1 (top first) and its “repeat first field” set to 1, it also may indicate that the last field displayed was the top field. In either case, the next expected field may be the bottom field. Because these techniques assume the "top field first," a field adjustment frame may be inserted.
- These techniques may be performed by setting the "top field first” flag to 0 and "repeat first field” flag to 1 in the very first trickmode frame, which may be a Dummy B-frame.
- the sequence bottom, top, bottom
- the sequence not only preserves the field sequencing from the play sequence but also may allow a subsequent frame to start with the top field.
- This field adjustment technique extends the GOP size by half a frame (i.e., one field).
- the "top field first” flag may be set to 1 and the “repeat first field” flag may be set to 0 in the I- frames, through a restamping technique that takes place after the I-frame is read from disk into memory.
- the play sequence when the play sequence operates at a relatively low buffp fw ⁇ l ⁇ thiejrilinj ⁇ ptjtieiS' ⁇ r ⁇ juih-line to transmit the first trickmode packet.
- the first trickmode packet may still be in the process of being transmitted.
- One solution is to append a sequence of P-frames to the beginning of the trickmode packet, similar to the P- frame insertion techniques. These P-frarnes may not be a part of the trickmode GOP, but extend the previous GOP (i.e., play sequence) and cause the decoder to repeat the last picture for a few frame intervals, so that the trickmode packet may be fully transmitted.
- the method used to transition from trickmodes back to normal play may be accomplished by extending the last GOPs of the trickmode sequence to create extra available bandwidth.
- the available bandwidth may be used for rebuffering video data from a new play sequence, for example, operating in high delay mode.
- the rebuffering technique attempts to hold the last trickmode packet long enough that the buffer can store the new play sequence while the decoder is busy playing dummy P-frames.
- the rebuffering technique may gradually create the bandwidth by increasing the GOP size of the last trickmode packets. If the GOP size selected is 4, it means that the last trickmode packets will have GOP sizes 5, 7, 10, etc. causing a visual impression of slowing down rather that a total stop.
- the last trickmode packets may be inserted until the total available bandwidth matches or passes the necessary bandwidth to allow full rebuffering of the play sequence.
- the I- frame selection mechanism also may change for the last trickmode packets. This may be necessary in order to avoid going too far from the requested play offset.
- the index increment may be set to a minimum of 1.0 so that each transition trickmode packet will only move the stream about 1/I r off the requested position. Typical results indicate that approximately 3 to 5 transition packets are necessary to allow rebuffering, which represents only 1.5 to 2.5s off the requested play position in a stream with I r - 2 I-frames/s.
- Another approach may be to compute the available bandwidth of a sequence of trickmode packets starting from the precise play offset, but going backwards, using index increment of -1.0. When the net bandwidth matches or passes the necessary bandwidth, the last packet will be the first packet used in the transition sequence. This technique may ensure that the transition sequence ends at the requested play offset.
- I-frames may be selected from the forward direction (increment +1.0) until there is enough bandwidth available.
- the sequence of transition packets may then be taken from the current position, backwards to the position where the actual play sequence starts.
- a "virtual trickmode packet" may be inserted in the adjustment technique with data size set to 0, trickmode packet size set to 0, but bw_balance set to the amount of data needed for buffering.
- Using the buffer optimization technique may cause the available bandwidth of the trickmode packets to be consumed and shifts the transition packets, creating space for a new play sequence.
- This technique may cause a buffer transition as shown in the bottom graph of Figure 8, where 4 transition packets may be observed with GOP sizes 6, 7, 8 and 9. Transitions from trickmodes to play using this approach may cause an impression of "slowdown," without interruption of the frame sequence.
- Video-on-Demand (VOD) server may receive feedback from a set-top box when a user releases the FF button, for example.
- VOD Video-on-Demand
- the server's buffer management algorithm may build in a lag during the transition back to normal play. In order to fill up the buffer, the number of frames coming in may exceed the number of frames being played, so it may step up the transmission of frames to fill up that buffer after it receives the signal from the user. At that point, it may switch to a normal stream.
- the techniques may reduce the speed of the last frames by generating a few extra B- and P-frames, which are relatively small, easily generated, and can be transmitted in less time than they are displayed, so that they fill up the decoder's buffer. "Slowing down” may represent sending less I-frames per second, and thus there is not impact to the actual frame rate, which typically must be constant 30fps.
- the average bitrate may be reduced by the trickmode techniques. The bandwidth in excess may then used to restore the buffer to normal levels.
- Pause and Resume may not use the above described techniques, because these modes are a transition utilizing the normal transport stream.
- Jump may require buffer adjustment because buffer levels may be different at the transition point.
- the same techniques applied to trickmodes may be applied to jumps, either by allowing debuffering or by inserting dummy B-frames and P-frames to allow rebuffering. Because buffer control is related to adequate adjustment of stream parameters such as PCR, DTS and PTS, speed transitions as well as jumps may need to be implemented by ensuring that these control variables match.
- a sequence of nulls may be inserted to allow the buffer levels to get to adequate levels.
- PCR PCR
- the jump techniques may also take into account that some GOPs may be open. In other words, the first B-frames to be displayed before the I-frame in the new play sequence may use forward reference to a frame from a previous GOP that has not been transmitted. In addition, the jump techniques may correct field sequencing to avoid the presence of 2 top fields or 2 bottom fields in sequence. Wrong field sequencing may cause the screen to undesirably roll in a set-top box, for example.
- the jump techniques may include a splicing method that ensures that the previous GOP was completely sent, avoiding incomplete pictures or sequences to be present at the decoder receive buffer. Also, the splicing method may determine that the DTS minus PCR of the new sequence is less than the current stream DTS minus PCR (i.e., from the old sequence), so the buffer level must decrease. In addition, the splicing method may retrieve the I-frame and append a sequence of dummy B-frames. The number of dummy B-frames may match the number of B-frames found in the original sequence prior to the I-frame. This may serve to avoid the problem described with respect to open GOPs.
- the splicing technique may adjust the field sequencing by setting the "top field first” and "repeat first field” flags appropriately in the first dummy B-frame. If field adjust is necessary, DTS and PTS may be adjusted accordingly. In this instance, the new play sequence may be composed of an I-frame, dummy B-frames may then be restamped to match the remaining of the new play sequence (PBBPBBP, etc.) avoiding discontinuities.
- Streaming data following the transition point may be restamped by adding the PCR_restamp amount to the PCRs and the amount (PCR restamp/300) to the DTSs and PTSs fou ⁇ ⁇ :,t ⁇ &,elfe
- Figure 9 provides an illustration as to how the splicing technique operates.
- another technique may be employed. For example, a similar process described in the P-frame insertion technique and in the transition from trickmodes to play can be used to "freeze" the last picture, allowing the new sequence to be buffered.
- the rebuffering technique may include inserting a number of P-frames followed by a short sequence of null packets. If the new sequence is transmitted right after the end of the previous sequence, starting at StreamPCR, the first frame may be decoded at instant given by StreamPCR + (DTS a-w - PCRnew)- The first frame of the new sequence is expected to be decoded at the instant given by StreamDTS, which is one frame after the last decode time from the previous sequence.
- FIG. 10 illustrates a system 1000 for communicating a data stream.
- a set-top box 1002 is in communication with a data server 1003 and with a bandwidth adjustment module 1004.
- Bandwidth adjustment module 1004 is capable of moving a portion of a data stream (e.g., a trickmode packet) to another timeslot when its designated timeslot is not sufficiently large to handle the data stream.
- the example trickmode packet may include a series of I-frames that may be communicated at a rate of approximately 10 frames per second.
- bandwidth adjustment module 1004 may insert Dummy data (e.g., B-frames and P-frames) into the trickmode packet.
- Dummy data e.g., B-frames and P-frames
- System 1000 also may include a compression/decompression coder 1005 in communication with set top box 1002.
- Compression/decompression coder 1005 may operate in accordance with MPEG standards.
- System 1000 also may include a display 1006 for displaying images from set top box 1002, and a user interface 1007 capable of communicating with set top box p jjnitjaje forward ' rewind, play, pause and stop).
- Display 1006 may be a conventional television set.
- User interface 1007 may communicate with set top box using wireless techniques.
- User interface 1007 may be a conventional remote control capable of communicating using a wireless link like infrared (IR), radio frequency (RF), or any other suitable type of link.
- IR infrared
- RF radio frequency
- FIG 11 is a flow diagram of a method of communicating a data stream.
- the described methods may further control an amount of data storage as a function of the moved portion and monitor a size of the second data stream and a size of the second timeslot.
- the methods may compress and decompress the data streams in accordance with MPEG standards, and operate to redistribute unused bandwidth in the first timeslot to the second timeslot.
- the described methods may monitor the data streams to determine a maximum rate for communicating the data streams.
- FIG. 12 is a flow diagram of a method for controlling a data storage or buffer level.
- a data frame e.g., a B- or P-frame dummy frame
- the rate of transmission the data stream is changed.
- a command to switch from the first mode to the second mode is received and in 1204 a transfer is made from a first mode to a second mode.
- the first and second modes may be a trickmode play mode and/or a normal play mode.
- the true scope of the disclosure is not limited to the illustrative embodiments disclosed herein.
- the foregoing disclosure of various techniques for creating efficient trickmode playback may be used separately or in combination with each other.
- the disclosed embodiments operate over a wide variety of picture sizes (e.g., HDTV) and frame rates.
- the contemplated techniques allow smooth transitions between different play speeds and normal play speed without generating visual artifacts, black screens, underflow, macro-blocking that is typically associated to buffer overflow, or discontinuities commonly present in transitions executed of the disclosed techniques, a different dummy B- frame and P-frame encoding may be used.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Television Signal Processing For Recording (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2005800235576A CN101010959B (en) | 2004-07-23 | 2005-07-22 | Method and device for transmitting data stream |
EP05775427A EP1772016A2 (en) | 2004-07-23 | 2005-07-22 | Trickmodes and speed transitions |
JP2007522794A JP4729570B2 (en) | 2004-07-23 | 2005-07-22 | Trick mode and speed transition |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US59050404P | 2004-07-23 | 2004-07-23 | |
US60/590,504 | 2004-07-23 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2006012496A2 true WO2006012496A2 (en) | 2006-02-02 |
WO2006012496A3 WO2006012496A3 (en) | 2006-06-15 |
Family
ID=35057113
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2005/026011 WO2006012496A2 (en) | 2004-07-23 | 2005-07-22 | Trickmodes and speed transitions |
Country Status (6)
Country | Link |
---|---|
US (1) | US20060146780A1 (en) |
EP (1) | EP1772016A2 (en) |
JP (2) | JP4729570B2 (en) |
KR (1) | KR100868820B1 (en) |
CN (1) | CN101010959B (en) |
WO (1) | WO2006012496A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2487910A1 (en) * | 2009-10-09 | 2012-08-15 | JVC KENWOOD Corporation | Image coding device and image coding method |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040006635A1 (en) * | 2002-04-19 | 2004-01-08 | Oesterreicher Richard T. | Hybrid streaming platform |
US20040006636A1 (en) * | 2002-04-19 | 2004-01-08 | Oesterreicher Richard T. | Optimized digital media delivery engine |
US7899924B2 (en) * | 2002-04-19 | 2011-03-01 | Oesterreicher Richard T | Flexible streaming hardware |
US9456243B1 (en) | 2003-06-06 | 2016-09-27 | Arris Enterprises, Inc. | Methods and apparatus for processing time-based content |
JP4409401B2 (en) * | 2004-10-08 | 2010-02-03 | 株式会社日立製作所 | Packet transfer apparatus and storage system |
US20060098739A1 (en) * | 2004-11-09 | 2006-05-11 | Lsi Logic Corporation | Video frame encoder driven by repeat decisions |
US8145778B2 (en) * | 2006-07-28 | 2012-03-27 | Cisco Technology, Inc. | Method and system for transitioning streamed digital video content between stream servers in a digital video network |
JP4827669B2 (en) * | 2006-09-19 | 2011-11-30 | 株式会社ソニー・コンピュータエンタテインメント | Movie playback method and apparatus |
KR20080035891A (en) * | 2006-10-20 | 2008-04-24 | 포스데이타 주식회사 | Image playback apparatus for providing smart search of motion and method of the same |
US8009687B2 (en) * | 2007-03-28 | 2011-08-30 | Ixia | Measurement of network performance in transporting packet streams |
US8249141B1 (en) * | 2007-07-13 | 2012-08-21 | Sprint Spectrum L.P. | Method and system for managing bandwidth based on intraframes |
US8301793B2 (en) | 2007-11-16 | 2012-10-30 | Divx, Llc | Chunk header incorporating binary flags and correlated variable-length fields |
TW200923780A (en) * | 2007-11-26 | 2009-06-01 | Realtek Semiconductor Corp | System and method for remote live pause |
US8966103B2 (en) * | 2007-12-21 | 2015-02-24 | General Instrument Corporation | Methods and system for processing time-based content |
US8238341B2 (en) * | 2008-04-25 | 2012-08-07 | Chi Mei Communication Systems, Inc. | Apparatus and method for processing voice over internet protocol packets |
JP5322518B2 (en) * | 2008-07-08 | 2013-10-23 | キヤノン株式会社 | Communication method |
WO2010051545A1 (en) * | 2008-10-31 | 2010-05-06 | Divx, Inc. | System and method for playing content on certified devices |
US9060187B2 (en) * | 2008-12-22 | 2015-06-16 | Netflix, Inc. | Bit rate stream switching |
US8463108B2 (en) | 2009-01-06 | 2013-06-11 | Microsoft Corporation | Client-side ad insertion during trick mode playback |
KR101613241B1 (en) * | 2009-10-16 | 2016-04-29 | 삼성전자 주식회사 | Display apparatus and image playing method |
US20110268427A1 (en) * | 2010-04-30 | 2011-11-03 | Brelay Herve | Methods and apparatuses for a projected pvr experience |
US20110271001A1 (en) * | 2010-04-30 | 2011-11-03 | Herve Brelay | Methods & apparatuses for a projected pvr experience |
US8543724B2 (en) | 2010-04-30 | 2013-09-24 | Digital Keystone, Inc. | Methods and apparatuses for a projected PVR experience |
US20120030723A1 (en) * | 2010-07-27 | 2012-02-02 | Motorola, Inc. | Method and apparatus for streaming video |
CN102118270B (en) * | 2011-03-04 | 2014-04-30 | 华为技术有限公司 | Method and device for measuring user QoE (Quality of Experience) |
EP2498494A1 (en) * | 2011-03-11 | 2012-09-12 | Thomson Licensing | Decoder and method at the decoder for synchronizing the rendering of contents received through different networks |
EP2536143B1 (en) * | 2011-06-16 | 2015-01-14 | Axis AB | Method and a digital video encoder system for encoding digital video data |
US20140344410A1 (en) * | 2013-05-14 | 2014-11-20 | Morega Systems Inc. | Fixed-length segmentation for segmented video streaming to improve playback responsiveness |
WO2015088265A1 (en) * | 2013-12-13 | 2015-06-18 | Samsung Electronics Co., Ltd. | Storage medium, reproducing apparatus and method for recording and playing image data |
US10804958B2 (en) | 2015-02-24 | 2020-10-13 | Comcast Cable Communications, Llc | Multi-bitrate video with dynamic blocks |
US10298475B2 (en) * | 2015-07-24 | 2019-05-21 | Nvidia Corporation | System and method for jitter-aware bandwidth estimation |
US10033709B1 (en) * | 2017-11-20 | 2018-07-24 | Microsoft Technology Licensing, Llc | Method and apparatus for improving privacy of communications through channels having excess capacity |
US20210096904A1 (en) * | 2019-09-28 | 2021-04-01 | Tencent America LLC | Method and apparatus for a step-enabled workflow |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4731783A (en) * | 1985-05-20 | 1988-03-15 | Alcatel Espace | Method and system for time division multiple access satellite telecommunications |
US5515379A (en) * | 1993-10-18 | 1996-05-07 | Motorola, Inc. | Time slot allocation method |
US5566174A (en) * | 1994-04-08 | 1996-10-15 | Philips Electronics North America Corporation | MPEG information signal conversion system |
EP0781002A2 (en) * | 1995-12-21 | 1997-06-25 | THOMSON multimedia | Optimizing performance in a packet slot priority packet transport system |
WO2000042776A1 (en) * | 1999-01-19 | 2000-07-20 | Sarnoff Corporation | Constraining video production based on compression-related information |
US20020064177A1 (en) * | 1998-07-31 | 2002-05-30 | Michael C. Bertram | Method and apparatus for forming and utilizing a slotted mpeg transport stream |
WO2002045308A1 (en) * | 2000-11-17 | 2002-06-06 | Alloptic, Inc. | Point-to-multipoint passive optical network that utilizes variable-length packets |
US6535557B1 (en) * | 1998-12-07 | 2003-03-18 | The University Of Tokyo | Method and apparatus for coding moving picture image |
US20030077068A1 (en) * | 2001-10-23 | 2003-04-24 | Shu Lin | Trick mode using dummy predictive pictures |
US6618363B1 (en) * | 1998-10-09 | 2003-09-09 | Microsoft Corporation | Method for adapting video packet generation and transmission rates to available resources in a communications network |
WO2004034707A1 (en) * | 2002-10-10 | 2004-04-22 | Koninklijke Philips Electronics N.V. | Itv trick play over digital interface |
Family Cites Families (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4800431A (en) * | 1984-03-19 | 1989-01-24 | Schlumberger Systems And Services, Inc. | Video stream processing frame buffer controller |
GB8829919D0 (en) * | 1988-12-22 | 1989-02-15 | Int Computer Limited | File system |
US5367636A (en) * | 1990-09-24 | 1994-11-22 | Ncube Corporation | Hypercube processor network in which the processor indentification numbers of two processors connected to each other through port number n, vary only in the nth bit |
US6400996B1 (en) * | 1999-02-01 | 2002-06-04 | Steven M. Hoffberg | Adaptive pattern recognition based control system and method |
US5857109A (en) * | 1992-11-05 | 1999-01-05 | Giga Operations Corporation | Programmable logic device for real time video processing |
US5768598A (en) * | 1993-09-13 | 1998-06-16 | Intel Corporation | Method and apparatus for sharing hardward resources in a computer system |
EP0790739B1 (en) * | 1993-09-16 | 2001-03-14 | Kabushiki Kaisha Toshiba | Digital video signal |
US5638516A (en) * | 1994-08-01 | 1997-06-10 | Ncube Corporation | Parallel processor that routes messages around blocked or faulty nodes by selecting an output port to a subsequent node from a port vector and transmitting a route ready signal back to a previous node |
US5848192A (en) * | 1994-08-24 | 1998-12-08 | Unisys Corporation | Method and apparatus for digital data compression |
KR100197847B1 (en) * | 1994-11-11 | 1999-06-15 | 니시무로 타이죠 | Packet data recording apparatus and reproducing apparatus therefor |
WO1996017306A2 (en) * | 1994-11-21 | 1996-06-06 | Oracle Corporation | Media server |
EP0716370A3 (en) * | 1994-12-06 | 2005-02-16 | International Business Machines Corporation | A disk access method for delivering multimedia and video information on demand over wide area networks |
US5794062A (en) * | 1995-04-17 | 1998-08-11 | Ricoh Company Ltd. | System and method for dynamically reconfigurable computing using a processing unit having changeable internal hardware organization |
US5793927A (en) * | 1995-06-07 | 1998-08-11 | Hitachi America, Ltd. | Methods for monitoring and modifying a trick play data stream to insure MPEG compliance |
US5925099A (en) * | 1995-06-15 | 1999-07-20 | Intel Corporation | Method and apparatus for transporting messages between processors in a multiple processor system |
US6138147A (en) * | 1995-07-14 | 2000-10-24 | Oracle Corporation | Method and apparatus for implementing seamless playback of continuous media feeds |
US6112226A (en) * | 1995-07-14 | 2000-08-29 | Oracle Corporation | Method and apparatus for concurrently encoding and tagging digital information for allowing non-sequential access during playback |
US6119154A (en) * | 1995-07-14 | 2000-09-12 | Oracle Corporation | Method and apparatus for non-sequential access to an in-progress video feed |
US5751951A (en) * | 1995-10-30 | 1998-05-12 | Mitsubishi Electric Information Technology Center America, Inc. | Network interface |
US5815516A (en) * | 1996-04-05 | 1998-09-29 | International Business Machines Corporation | Method and apparatus for producing transmission control protocol checksums using internet protocol fragmentation |
US6088360A (en) * | 1996-05-31 | 2000-07-11 | Broadband Networks Corporation | Dynamic rate control technique for video multiplexer |
US5781227A (en) * | 1996-10-25 | 1998-07-14 | Diva Systems Corporation | Method and apparatus for masking the effects of latency in an interactive information distribution system |
US6166730A (en) * | 1997-12-03 | 2000-12-26 | Diva Systems Corporation | System for interactively distributing information services |
US6208335B1 (en) * | 1997-01-13 | 2001-03-27 | Diva Systems Corporation | Method and apparatus for providing a menu structure for an interactive information distribution system |
US6253375B1 (en) * | 1997-01-13 | 2001-06-26 | Diva Systems Corporation | System for interactively distributing information services |
JP2000509932A (en) * | 1997-02-03 | 2000-08-02 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | Direction identifier for recording trick play signal on record carrier |
US5819049A (en) * | 1997-02-28 | 1998-10-06 | Rietmann; Sandra D. | Multi-media recording system and method |
US6101255A (en) * | 1997-04-30 | 2000-08-08 | Motorola, Inc. | Programmable cryptographic processing system and method |
US6108695A (en) * | 1997-06-24 | 2000-08-22 | Sun Microsystems, Inc. | Method and apparatus for providing analog output and managing channels on a multiple channel digital media server |
US6023731A (en) * | 1997-07-30 | 2000-02-08 | Sun Microsystems, Inc. | Method and apparatus for communicating program selections on a multiple channel digital media server having analog output |
US6222838B1 (en) * | 1997-11-26 | 2001-04-24 | Qwest Communications International Inc. | Method and system for delivering audio and data files |
US6697846B1 (en) * | 1998-03-20 | 2004-02-24 | Dataplow, Inc. | Shared file system |
US6246683B1 (en) * | 1998-05-01 | 2001-06-12 | 3Com Corporation | Receive processing with network protocol bypass |
US6498897B1 (en) * | 1998-05-27 | 2002-12-24 | Kasenna, Inc. | Media server system and method having improved asset types for playback of digital media |
US6314573B1 (en) * | 1998-05-29 | 2001-11-06 | Diva Systems Corporation | Method and apparatus for providing subscription-on-demand services for an interactive information distribution system |
WO1999062261A1 (en) * | 1998-05-29 | 1999-12-02 | Diva Systems Corporation | Interactive information distribution system and method |
US6724767B1 (en) * | 1998-06-27 | 2004-04-20 | Intel Corporation | Two-dimensional queuing/de-queuing methods and systems for implementing the same |
US6157051A (en) * | 1998-07-10 | 2000-12-05 | Hilevel Technology, Inc. | Multiple function array based application specific integrated circuit |
US6148414A (en) * | 1998-09-24 | 2000-11-14 | Seek Systems, Inc. | Methods and systems for implementing shared disk array management functions |
KR100618961B1 (en) * | 1998-12-16 | 2006-09-01 | 삼성전자주식회사 | Method for generating information so as to fast search of packet data, recording medium storing the information, and recording and/or playback apparatus using the same |
US6240553B1 (en) * | 1999-03-31 | 2001-05-29 | Diva Systems Corporation | Method for providing scalable in-band and out-of-band access within a video-on-demand environment |
US6289376B1 (en) * | 1999-03-31 | 2001-09-11 | Diva Systems Corp. | Tightly-coupled disk-to-CPU storage server |
US6233607B1 (en) * | 1999-04-01 | 2001-05-15 | Diva Systems Corp. | Modular storage server architecture with dynamic data management |
US6721794B2 (en) * | 1999-04-01 | 2004-04-13 | Diva Systems Corp. | Method of data management for efficiently storing and retrieving data to respond to user access requests |
US6820144B2 (en) * | 1999-04-06 | 2004-11-16 | Microsoft Corporation | Data format for a streaming information appliance |
US6502194B1 (en) * | 1999-04-16 | 2002-12-31 | Synetix Technologies | System for playback of network audio material on demand |
US6651103B1 (en) * | 1999-04-20 | 2003-11-18 | At&T Corp. | Proxy apparatus and method for streaming media information and for increasing the quality of stored media information |
IL130796A (en) * | 1999-07-05 | 2003-07-06 | Brightcom Technologies Ltd | Packet processor |
US6496692B1 (en) * | 1999-12-06 | 2002-12-17 | Michael E. Shanahan | Methods and apparatuses for programming user-defined information into electronic devices |
US7327761B2 (en) * | 2000-02-03 | 2008-02-05 | Bandwiz Inc. | Data streaming |
US6757291B1 (en) * | 2000-02-10 | 2004-06-29 | Simpletech, Inc. | System for bypassing a server to achieve higher throughput between data network and data storage system |
US6988188B2 (en) * | 2000-03-01 | 2006-01-17 | Realtek Semiconductor Corp. | Data object architecture and method for xDSL ASIC processor |
US7200670B1 (en) * | 2000-06-30 | 2007-04-03 | Lucent Technologies Inc. | MPEG flow identification for IP networks |
GB2366709A (en) * | 2000-06-30 | 2002-03-13 | Graeme Roy Smith | Modular software definable pre-amplifier |
JP2004514336A (en) * | 2000-11-10 | 2004-05-13 | プレディウェイブ・コーポレイション | Idle time reduction and constant bandwidth data on demand broadcast distribution matrix |
US6940873B2 (en) * | 2000-12-27 | 2005-09-06 | Keen Personal Technologies, Inc. | Data stream control system for associating counter values with stored selected data packets from an incoming data transport stream to preserve interpacket time interval information |
US20030223735A1 (en) * | 2001-02-28 | 2003-12-04 | Boyle William B. | System and a method for receiving and storing a transport stream for deferred presentation of a program to a user |
WO2002085030A1 (en) * | 2001-04-11 | 2002-10-24 | Cyber Operations, Llc | System and method for preconditioning analog video signals |
US7042899B1 (en) * | 2001-05-08 | 2006-05-09 | Lsi Logic Corporation | Application specific integrated circuit having a programmable logic core and a method of operation thereof |
US20030079018A1 (en) * | 2001-09-28 | 2003-04-24 | Lolayekar Santosh C. | Load balancing in a storage network |
US20030095783A1 (en) * | 2001-11-21 | 2003-05-22 | Broadbus Technologies, Inc. | Methods and apparatus for generating multiple network streams from a large scale memory buffer |
US6789123B2 (en) * | 2001-12-28 | 2004-09-07 | Microsoft Corporation | System and method for delivery of dynamically scalable audio/video content over a network |
US7657917B2 (en) * | 2002-05-23 | 2010-02-02 | Microsoft Corporation | Interactivity emulator for broadcast communication |
US7260576B2 (en) * | 2002-11-05 | 2007-08-21 | Sun Microsystems, Inc. | Implementing a distributed file system that can use direct connections from client to disk |
US20030108030A1 (en) * | 2003-01-21 | 2003-06-12 | Henry Gao | System, method, and data structure for multimedia communications |
US7298741B2 (en) * | 2003-02-27 | 2007-11-20 | Sharp Laboratories Of America, Inc. | Robust MPEG-2 multiplexing system and method using an adjustable time stamp |
US7444419B2 (en) * | 2003-10-10 | 2008-10-28 | Microsoft Corporation | Media stream scheduling for hiccup-free fast-channel-change in the presence of network chokepoints |
US7460531B2 (en) * | 2003-10-27 | 2008-12-02 | Intel Corporation | Method, system, and program for constructing a packet |
-
2005
- 2005-07-22 US US11/187,202 patent/US20060146780A1/en not_active Abandoned
- 2005-07-22 WO PCT/US2005/026011 patent/WO2006012496A2/en active Application Filing
- 2005-07-22 EP EP05775427A patent/EP1772016A2/en not_active Withdrawn
- 2005-07-22 CN CN2005800235576A patent/CN101010959B/en active Active
- 2005-07-22 JP JP2007522794A patent/JP4729570B2/en active Active
- 2005-07-22 KR KR1020077003898A patent/KR100868820B1/en active IP Right Grant
-
2010
- 2010-12-10 JP JP2010276408A patent/JP2011050117A/en active Pending
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4731783A (en) * | 1985-05-20 | 1988-03-15 | Alcatel Espace | Method and system for time division multiple access satellite telecommunications |
US5515379A (en) * | 1993-10-18 | 1996-05-07 | Motorola, Inc. | Time slot allocation method |
US5566174A (en) * | 1994-04-08 | 1996-10-15 | Philips Electronics North America Corporation | MPEG information signal conversion system |
EP0781002A2 (en) * | 1995-12-21 | 1997-06-25 | THOMSON multimedia | Optimizing performance in a packet slot priority packet transport system |
US20020064177A1 (en) * | 1998-07-31 | 2002-05-30 | Michael C. Bertram | Method and apparatus for forming and utilizing a slotted mpeg transport stream |
US6618363B1 (en) * | 1998-10-09 | 2003-09-09 | Microsoft Corporation | Method for adapting video packet generation and transmission rates to available resources in a communications network |
US6535557B1 (en) * | 1998-12-07 | 2003-03-18 | The University Of Tokyo | Method and apparatus for coding moving picture image |
WO2000042776A1 (en) * | 1999-01-19 | 2000-07-20 | Sarnoff Corporation | Constraining video production based on compression-related information |
WO2002045308A1 (en) * | 2000-11-17 | 2002-06-06 | Alloptic, Inc. | Point-to-multipoint passive optical network that utilizes variable-length packets |
US20030077068A1 (en) * | 2001-10-23 | 2003-04-24 | Shu Lin | Trick mode using dummy predictive pictures |
WO2004034707A1 (en) * | 2002-10-10 | 2004-04-22 | Koninklijke Philips Electronics N.V. | Itv trick play over digital interface |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2487910A1 (en) * | 2009-10-09 | 2012-08-15 | JVC KENWOOD Corporation | Image coding device and image coding method |
EP2487910A4 (en) * | 2009-10-09 | 2013-04-24 | Jvc Kenwood Corp | Image coding device and image coding method |
US8824545B2 (en) | 2009-10-09 | 2014-09-02 | JVC Kenwood Corporation | Image encoding device and image encoding method |
Also Published As
Publication number | Publication date |
---|---|
CN101010959B (en) | 2012-01-25 |
US20060146780A1 (en) | 2006-07-06 |
EP1772016A2 (en) | 2007-04-11 |
JP4729570B2 (en) | 2011-07-20 |
JP2008507922A (en) | 2008-03-13 |
KR20070064316A (en) | 2007-06-20 |
KR100868820B1 (en) | 2008-11-14 |
WO2006012496A3 (en) | 2006-06-15 |
JP2011050117A (en) | 2011-03-10 |
CN101010959A (en) | 2007-08-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100868820B1 (en) | A method and system for communicating a data stream and a method of controlling a data storage level | |
US6658199B1 (en) | Method for temporally smooth, minimal memory MPEG-2 trick play transport stream construction | |
CN110248204B (en) | Processing method, device, equipment and storage medium for live broadcast cache | |
KR100711635B1 (en) | Picture coding method | |
US7023924B1 (en) | Method of pausing an MPEG coded video stream | |
US8837586B2 (en) | Bandwidth-friendly representation switching in adaptive streaming | |
US6980594B2 (en) | Generation of MPEG slow motion playout | |
KR102218385B1 (en) | Codec techniques for fast switching | |
JP4118232B2 (en) | Video data processing method and video data processing apparatus | |
US8355452B2 (en) | Selective frame dropping for initial buffer delay reduction | |
RU2488968C2 (en) | Coding device and method of data stream generation | |
US8837660B2 (en) | Handling video transition errors in video on demand streams | |
US8254449B2 (en) | Video traffic bandwidth prediction | |
US7627227B2 (en) | Reverse presentation of digital media streams | |
US20060023729A1 (en) | Apparatus and method for adaptively controlling buffering amount according to content attribute in receiving audio-video data | |
WO2017214510A1 (en) | Transcoding using time stamps | |
JP4295079B2 (en) | Special video data processing method, special video data processing apparatus and special video data processing system | |
JP2004158929A (en) | Moving picture processing method, moving picture processor, and moving picture transmitter | |
US8401086B1 (en) | System and method for increasing responsiveness to requests for streaming media | |
EP2015305A1 (en) | A device and method for smooth reverse playback of media | |
JP2013012265A (en) | Reproduction device and reproduction method | |
JPH099215A (en) | Data multiplex method, data transmission method, multiplex data decoding method and multiplex data decoder | |
JP3671969B2 (en) | Data multiplexing method and multiple data decoding method | |
Yang et al. | AVS trick modes for PVR and VOD services | |
Psannis | Interactive Compression Algorithms for Streaming Media Over High Speed Networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2005775427 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200580023557.6 Country of ref document: CN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2007522794 Country of ref document: JP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020077003898 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2005775427 Country of ref document: EP |