KR20070064316A - 트릭모드 및 속도 전환 - Google Patents

트릭모드 및 속도 전환 Download PDF

Info

Publication number
KR20070064316A
KR20070064316A KR1020077003898A KR20077003898A KR20070064316A KR 20070064316 A KR20070064316 A KR 20070064316A KR 1020077003898 A KR1020077003898 A KR 1020077003898A KR 20077003898 A KR20077003898 A KR 20077003898A KR 20070064316 A KR20070064316 A KR 20070064316A
Authority
KR
South Korea
Prior art keywords
frame
frames
data
packet
data stream
Prior art date
Application number
KR1020077003898A
Other languages
English (en)
Other versions
KR100868820B1 (ko
Inventor
자퀘스 파베스
Original Assignee
비치 언리미티드 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 비치 언리미티드 엘엘씨 filed Critical 비치 언리미티드 엘엘씨
Publication of KR20070064316A publication Critical patent/KR20070064316A/ko
Application granted granted Critical
Publication of KR100868820B1 publication Critical patent/KR100868820B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)

Abstract

개시된 실시예들은 데이터 스트림을 전달하는 기술에 관한 것이다. 본 발명의 기술은 제1 데이터 스트림의 제1 타임슬롯을 결정하는 단계, 및 제2 데이터 스트림의 제2 타임슬롯을 결정하는 단계를 포함한다. 제2 데이터 스트림이 제2 타임슬롯보다 큰 경우, 제2 데이터 스트림의 일부분이 제2 타임슬롯으로 이동된다. 또한, 본 기술은 데이터 저장량을 이동된 일부분의 함수로서 제어하는 단계를 포함할 수 있다. 또한, 본 기술은 제2 데이터 스트림의 크기 및 제2 타임슬롯의 크기를 모니터할 수 있다.
비디오 데이터, 트릭모드, 속도 전환, 버퍼 최적화

Description

트릭모드 및 속도 전환{TRICKMODES AND SPEED TRANSITIONS}
<상호 참조>
본 출원은 2004년 7월 23일자로 출원되고 그 전체가 참조로써 여기에 포함된, 발명의 명칭이 "버퍼 최적화된 트릭모드 및 속도 전환(Buffer Optimized Trickmodes and Speed Transitions)"인 미국 가출원 제60/590,504호에 대한 우선권을 주장한다.
<기술분야>
본 발명은 일반적으로 비디오 데이터를 전송하는 기술에 관한 것이다.
고속 감기(fast forward), 되감기(rewind), 일시정지(pause), 정지(stop) 및 재생(play)될 수 있는 데이터를 나타내는 데 비디오 프레임이 사용될 수 있다. 주어진 기간 또는 타임슬롯 동안 이들 비디오 프레임과 연관된 전송 또는 수신되는 데이터량을 이용하여 가용 대역폭을 결정할 수 있다. 한 유형의 비디오 프레임은 "트릭모드(trickmode)" 프레임으로 지칭될 수 있으며, 이는 많은 상이한 비디오 전송 방법들에서 사용된다.
비디오 전송에서 비디오 프레임의 전송을 관리하는 것은 원하는 비디오 생성 품질을 달성하기 위한 한가지 고려 사항이다. 트릭모드 프레임의 경우, 주어진 프 레임과 연관된 데이터량에 예기치못한 변동이 있을 수 있으며, 이는 관리 문제에 영향을 줄 수 있다. 예를 들어, 트릭모드 프레임이 이용가능한 타임슬롯 내에 들어맞도록 하기 위해, 각각의 슬롯이 최대 트릭모드 프레임을 전송할 정도로 충분히 큰 고정된 양의 대역폭을 갖는 타임슬롯 기술이 사용될 수 있다. 그렇지만, 필요한 것보다 타임슬롯이 큰, 그외의 짧은 트릭모드 프레임에 대해서는 대역폭이 사용되지 않을 수 있다. 이로 인하여 미사용 대역폭의 양이 증가할 수 있다.
또한, 트릭모드 프레임이 전송되기 전에 그 트릭모드 프레임을 버퍼링하는 데 필요한 메모리량을 측정하기가 어려운 경우가 종종 있다. 그 결과, 어떤 때에는, 버퍼링되는데 필요한 데이터량이 이용가능한 메모리보다 더 클 수 있으며, 그에 의해 "버퍼 오버플로우(buffer overflow)" 상태를 야기하게 된다. 버퍼 오버플로우 상태의 결과, 점프(jump) 및 지터(jitter)와 같은 여러가지 바람직하지 않은 시각적 상태가 야기될 수 있다.
도 1은 예시적인 비디오 버퍼 레벨을 나타낸 도면.
도 2는 대상 GOP(Group of Picture)의 길이를 증가시키는 예시적인 기술을 나타낸 도면.
도 3은 비디오 프레임 시퀀스의 버퍼 레벨에 대한 영향을 나타낸 도면.
도 4는 비디오 스트림의 분포 곡선을 나타낸 도면.
도 5는 트릭모드 패킷 조정의 예시를 나타낸 도면.
도 6은 트릭모드 패킷을 이동하는 것의 버퍼 레벨에 대한 영향을 나타낸 그 래프.
도 7은 트릭모드 스트림을 생성하기 위해 버퍼 최적화가 어떻게 사용될 수 있는지를 나타낸 도면.
도 8은 트릭모드 비디오 스트림의 출력을 나타낸 도면.
도 9는 스플라이싱(splicing) 기술의 예시를 나타낸 도면.
도 10은 데이터 스트림을 전달하는 시스템의 도면.
도 11은 데이터 스트림을 전달하는 방법의 흐름도.
도 12는 데이터 저장 레벨을 제어하는 방법의 흐름도.
개시된 실시예들은, 바람직한 비디오 재생 조건을 제공하는 버퍼 레벨을 유지하면서, 트릭모드 비디오 스트림과 같이, 비디오 데이터를 전달함에 있어서 효율적인 대역폭 사용을 달성하는 기술을 제공한다. 이 실시예들이 MPEG(Motion Picture Experts Group) 기술과 관련하여 기재되어 있지만, 기재된 기술들이 또한 다른 유형의 데이터 압축/복원(compression/decompression) 기술에서도 사용될 수 있다는 것이 이해될 것이다.
어떤 비디오 압축/복원 기술에서, 비디오는 프레임으로 분할될 수 있다. 예를 들어, MPEG은 적어도 3개의 서로 다른 유형의 비디오 프레임, 즉 I-프레임, P-프레임 및 B-프레임을 사용한다. I-프레임, 즉 "인트라 코딩된 프레임(intra coded frame)"은, 시퀀스에서의 임의의 다른 이전 프레임 또는 이후 프레임 없이, I-프레임이 디코딩될 수 있게 해주는 인트라-프레임 매크로블록(intra-frame macroblock)을 포함한다. MPEG 비디오의 랜덤 재생의 경우, 디코더는 I-프레임으로부터 디코딩을 시작할 수 있다. I-프레임은 매 12개 내지 15개 프레임마다 삽입될 수 있으며, 시퀀스를 시작하는 데 사용되어, 랜덤한 위치로부터 비디오가 재생될 수 있게 해주고, 예를 들어 고속 감기(fast forward) 및 되감기(reverse)와 같은 트릭모드 특징을 가능하게 해준다.
P-프레임은 이전 프레임과의 차분으로서 코딩된다. 이전 프레임을 받아서 현재 프레임의 새로운 픽셀에 대한 값을 예측함으로써 새로운 P-프레임이 예측될 수 있다. P-프레임은 존재하는 움직임의 양에 따라서 보다 높은 압축비를 제공할 수 있다.
B-프레임, 즉 "양방향 프레임"은 B-프레임의 이전 또는 후속 프레임과의 차분으로서 코딩되고, 정확한 디코딩을 위해 이전 및 후속 프레임을 사용할 수 있다. 따라서, 판독된 프레임들의 순서는 표시된 순서와 동일하지 않을 수 있다. 이것은 후속 프레임이 현재 B-프레임보다 이전에 전송되고 디코딩될 수 있지만 현재 프레임 후에 표시된다는 것을 의미한다. 예를 들어, 프레임 I1 B2 B3 P4 B5 B6 P7의 표시 시퀀스가 재정렬되어 I1 P4 B2 B3 P7 B5 B6으로서 전송될 수 있다.
MPEG 비디오의 시퀀스는 GOP(Group of Pictures)를 포함할 수 있다. 각각의 GOP는 비디오 프레임을 포함한다. GOP 구조는 이 구조가 포함하는 프레임의 수(N) 및 2개의 참조 프레임들 간의 거리(M)와 연관되어 있다. 예를 들어, 일반적인 GOP 구조는 IBBPBBPBBPBBPBBP(N = 15이고 M = 3임) 및/또는 IBBPBBPBBPBB(N = 12이고 M = 3임)일 수 있다. 물론, 이들 구조는 변할 수 있으며, 어떤 것은 예를 들어 PPPPPPPP와 같은 P-프레임만 있는 스트림을 포함할 수 있다.
트릭모드 GOP는 I-프레임 및 가변적인 수의 더미 B-프레임 및 P-프레임을 포함하는 비디오 시퀀스이다. 트릭모드 GOP 크기는 트릭모드 GOP 내의 프레임의 수와 연관되어 있을 수 있다. 예를 들어, IBBPPP의 GOP 구조는 GOP 크기가 6이다. GOP 또는 트릭모드 패킷의 타임슬롯은 I-프레임 DTS(디코드 타임스탬프)로부터 그 다음 I-프레임 DTS까지의 기간일 수 있다.
트릭모드 패킷은 트릭모드 GOP와 연관되어 있을 수 있으며, 또 유효 전송 스트림(valid transport stream)을 조정하기 위한 데이터를 포함할 수 있다. 트릭모드 패킷은 PAT(Program Allocation Table, 프로그램 할당 테이블) 테이블, PMT(Program Map Table, 프로그램 맵 테이블) 테이블, "동기(Sync)" 패킷이라고 하는 동기화만을 위한(예를 들어, 데이터는 아님) PCR(Program Clock Reference, 프로그램 클럭 참조)을 갖는 전송 스트림 패킷, 트릭모드 GOP, 및 가변 크기를 갖는 필러 널 패킷(filler null packet)을 포함할 수 있다.
트릭모드 패킷의 크기는 트릭모드 패킷 자체에 기초할 수 있다. 트릭모드 패킷의 크기는 또한 저장 오버헤드, 네트워크 오버헤드, 및 비트레이트 제어를 수용할 수 있다. 예를 들어, I-프레임을 포함하는 파일 세그먼트는 전송 스트림 레벨에서 멀티플렉스되는(multiplexed) 다른 패킷 식별자, 즉 PID(예를 들어, PAT, PMT, 오디오)도 포함할 수 있다. 이 블록은 메모리 내로 판독될 수 있으며, 비디오가 아닌 패킷은 널(null)(예를 들어, "뮤팅(muting)")로 대체될 수 있다.
트릭모드 패킷은 또한 1316 바이트(예를 들어, 사용자 데이터그램 프로토콜, 즉 UDP를 통한 MPEG2 전송 스트림)의 배수일 수 있다.
도 1은 고정된 타임슬롯 할당을 사용하는 I-프레임-기반 트릭모드에 대한 예시적인 비디오 버퍼 레벨을 나타낸 것이다. 도 1에 도시한 바와 같이, 각각의 GOP는 7개의 프레임을 포함한다. 다른 크기의 GOP가 사용될 수 있다. 도 1에 나타낸 수평 스케일(t)은 프레임 주기(예를 들어, 1/30초) 단위로 주어진다. 예를 들어, "트릭모드 GOP" 구조는 IBBPPPP, 즉 I-프레임 다음에 2개의 더미 B-프레임 및 4개의 P-프레임이 따르는 구조일 수 있다. 이 구조는 매 30초마다 7개의 I-프레임, 초당 4.28개의 I-프레임을 생성한다.
도 1에서 수직 파선으로 도시된 바와 같이, 제1 GOP는 t=2에서 수신된다. GOP 구조가 7개 프레임으로 설정되어 있기 때문에, 이는 t=7이 될 때까지 디코딩 되지 않고 또 표시되지 않는다. 제2 GOP 구조는 t=13에서 수신된다. 이 예에서, t=7부터 t=13까지, 디코더는 제1 GOP를 표시하는 반면, 제2 GOP는 전송 및 버퍼링되고 있다. t=14에서, 제2 GOP는 이미 버퍼링되어 디코딩될 준비가 되어 있다.
GOP는 디코딩되어 표시될 준비가 되어 있는 구간 전에 수신될 수 있으며, 디코딩 프로세스에 대한 중단이 일어나지 않을 수 있다. 그렇지만, GOP가 디코딩되어 표시될 준비가 되어 있는 구간 전에 수신될 수 있기 때문에, 미사용 대역폭이 있을 수 있다. 이 미사용 대역폭은 도 1에서 교차 해칭된 직사각형 영역으로 도시되어 있다.
대역폭 낭비 문제를 해결하기 위한 한가지 방법은, 예를 들어 타임슬롯 및/또는 GOP 크기를 감소시킴으로써, 초당 더 많은 I-프레임을 전송하는 것일 수 있다. 예를 들어, 도 1을 참조하면, GOP를 6개 프레임으로 감소시키면 제1 GOP에 의한 미사용 대역폭의 양을 한 프레임만큼 감소시키게 된다. 그렇지만, t=13.5까지 제2 GOP가 전송될 준비가 되지 않는데, t=13.5는 제2 GOP가 디코딩되고 표시되어야 할 시점의 이후이다. 제2 GOP가 전송되는 데 약 6.5 프레임 구간(즉, 13.5 - 7) 걸리기 때문에, 제1 GOP는 t=12에서 불완전한 제2 GOP가 디코더에 표시되게 한다. 불완전한 제2 GOP를 디코더에 제공하게 되면 "버퍼 언더플로우"를 야기할 수 있다. 일 실시예에서, GOP 및 타임슬롯의 길이는 후속 GOP의 크기의 함수일 수 있다. 예를 들어, 도 1에서 샘플 분포로 반영되어 있는 바와 같이, 어떤 I-프레임은 2프레임 정도로 짧은 타임슬롯을 필요로 할 수 있으며, 그외의 것들은 6프레임 길이의 타임슬롯을 필요로 할 수 있다.
도 2는 대상 GOP에 후속하는 GOP에 기초하여 대상 GOP의 길이를 증가시키는 예시적인 기술을 나타낸 것이다. 도 2에 나타낸 바와 같이, 동일한 GOP 시퀀스를 사용하여, 총 구간을 각각의 GOP에 대해 랜덤으로 만드는 것에 의해 (교차 해칭된 직사각형 영역으로 표시된 바와 같이) 미사용 대역폭의 양이 단지 한 구간 길이로 감소될 수 있다. 상세하게는, 제1 GOP는 4개의 프레임 구간을 가지며, 제2 GOP는 5개의 구간을 갖는다. 발생된 트릭모드 시퀀스는 랜덤한 간격으로 표시되는 새로운 I-프레임을 가질 수 있다.
도 1 및 도 2에 예시된 기술은 모든 GOP가 디코딩된 후에 비디오 버퍼가 비게 된다는 가정 하에 동작할 수 있는데, 그 이유는 버퍼가 무시할 정도의 크기를 갖는 나머지 더미 P-프레임 및 B-프레임을 포함하기 때문이다.
데이터 입력 프로세스(data ingest process)는 "N-속도" 트릭모드 스트림을 발생하기 위해 수신되는 매 "N번째" 프레임마다 하나의 프레임을 디코딩할 수 있다. 예를 들어, 8배속 스트림을 발생하기 위해, 입력 프로세스는 프레임 1, 9, 17, 25,...(8n+1)을 디코딩할 수 있다. 이들 프레임은 이어서 그 결과 얻어지는 스트림이, 예를 들어 초당 30개의 고유 프레임을 포함할 수 있도록 MPEG2 전송 스트림을 발생하는 데 사용될 수 있다. 프레임의 시퀀스는 이어서 프레임 레이트, 비트레이트, PID 할당, 비디오 포맷, 및 비디오 버퍼 특성(예를 들어, 원활한 속도 전환을 위한 버퍼 크기 및 버퍼 레벨)과 같은, 원래의 전송 스트림의 일부 특징을 보존할 수 있는 새로운 MPEG2 전송 스트림으로 인코딩될 수 있다. 이 기술은 더 높은 트릭모드 품질을 제공할 수 있다. 이는 또한 더 높은 프로세서 용량 및 부가적인 저장 오버헤드(예를 들어, 일반적으로 30%)를 사용할 수 있다.
일부 실시예들에서, I-프레임-기반 트릭모드는 또한 더미 B-프레임 및 P-프레임을 삽입할 수 있다. 또한, 그 실시예들 중의 일부에서, P-프레임 및 B-프레임은 프레임 예측을 사용하여 인코딩될 수 있으며, 이로 인해 프레임 지터가 일어날 수 있다. 예를 들어, 방송 텔레비전(즉, NTSC(National Television System Committee))을 사용하는 그 실시예들에서, 각각의 프레임은 2개의 인터레이스된 필드로 이루어져 있을 수 있으며, 초당 총 60개 필드를 제공한다. 영화에서의 24 fps와 텔레비전에서의 30 fps 프레임 레이트 간의 차이의 결과로서, 영화를 텔레비전 컨텐츠로 변환하기 위해 "3:2 풀다운" 방식이 사용될 수 있다.
"3:2 풀다운" 방식은 프레임을 교대로 3개 필드 및 2개 필드로 변환할 수 있다. 예를 들어, 24 fps에서의 4개의 프레임(즉, 매 6초마다 1개의 프레임)은 30 fps에서 10개의 필드, 즉 5개의 완전한 프레임을 생성한다. (프로그레시브 모드와 비교하여) 인코딩을 위해 인터레이스 모드를 사용하는 경우, 프레임은 2개의 필드(위쪽이 A이고 아래쪽이 B임)를 포함한다. 더미 B-프레임 및 P-프레임을 발생하기 위해 프레임 예측이 사용되는 경우, 디코더는 참조 픽처(reference picture) 또는 I-프레임으로부터 양쪽 필드를 복사할 수 있다. 따라서, IBBPP 구조를 갖는 트릭모드 GOP는 디코더로 하여금 ABABABABAB 구조를 갖는 5개 필드(각각의 프레임에 대해 2개의 AB)로 된 시퀀스를 생성하게 한다.
I-프레임은 2개의 서로 다른 픽처로부터 비롯된 필드를 포함할 수 있으며, 필드 ABABABABAB의 시퀀스는 "지터"의 느낌을 야기할 수 있다.
일부 실시예들에서, 트릭모드 특징을 시작할 때, B-프레임 및 P-프레임에 의해 사용되는 참조 프레임은, 그 프레임을 출력 스트림으로 복사할 때, 파손될 수 있다. 이것은 부분적으로는 트릭모드 파일이 N개의 프레임으로부터 하나의 프레임을 선택함으로써 생성될 수 있다는 사실로 인한 것일 수 있다. 그 결과, B-프레임 및 P-프레임이 출력 스트림에 더 이상 존재하지 않을 수 있기 때문에, 참조를 갖지 않는 이들 프레임은 완전히 디코딩되어야 하고, 이어서 상이한 참조 프레임을 사용하여 트릭모드 스트림과 관련하여 재인코딩되어야만 한다.
예를 들어, 비디오 프레임 시퀀스 IBBPBBPBBPBBPBBIBBPBBPBBPBBPBBIBBP는 트릭모드 시퀀스와 관련하여 IBBPBBP로 표현될 수 있다. 원래의 비디오 프레임 시퀀스에 있는 B-프레임은 트릭모드 시퀀스 파일의 일부가 아닌, 이전의 그리고 후속의 I-프레임 및 P-프레임에 의존할 수 있다. 또한, 어떤 프레임은, 이 프레임이 시퀀스에서 어디에 삽입되는지에 따라, 트릭모드 파일에서 서로 다르게 인코딩될 수 있다. 예를 들어, 원래의 시퀀스에서의 I-프레임은 트릭모드 파일에서 P-프레임으로 인코딩될 수 있고, B-프레임은 P-프레임 또는 심지어 완전히 상이한 참조 프레임을 갖는 다른 B-프레임이 될 수 있다.
케이블 업계에서 사용되는 일반적인 대역폭 레이트는 3.75 Mbits/s, 즉 CableLabs™ Content Specification 1.0[4]에 기술된 바와 같이 3.75 Mbits/s로 입력되는 초당 30 프레임의 스트림을 포함한다. 4개의 트릭모드 파일(예를 들어, 속도 15배속, -15배속, 60배속 및 -60배속)을 필요로 할 수 있는 주문형 비디오(VOD) 서버의 경우, 원래의 비디오 스트림으로부터 추출 및 디코딩된 프레임을 처리함으로써 4개까지의 서로 다른 트릭모드 파일들을 병렬로 생성하기 위해 4개의 인코더가 사용될 수 있다.
각각의 트릭모드 인코더는 4개의 인코더 전부에 걸쳐 초당 총 5개의 프레임이 되도록, 초당 2 프레임(fps)(30/15), 2 fps(30/15), 0.5 fps(30/60) 및 0.5 fps(30/60)을 수신할 수 있다. 일반적으로, 예를 들어 2.4 GHz 펜티엄™ 4 프로세서로부터의 거의 모든 프로세싱을 사용하면 대략 45 Mbits/s의 입력 대역폭을 갖는 12개 스트림의 인코딩이 가능하다. 그 결과 얻어지는 트릭모드 파일들은 각각 원래의 파일 크기의 대략 6.7%, 6.7%, 2.2% 및 2.2%가 되어 총 약 16.6% 저장이 되게 한다. 따라서, 일부 실시예에서, 표준 트릭모드 파일을 생성하는 것은 상당한 컴퓨터 처리 용량 및 복잡한 컴퓨터 로직을 필요로 할 수 있다. 게다가, 이 프로세스는 일부 프레임들은 완전히 디코딩할 수 있는 반면, B-프레임과 같은 그외의 프레임들은 디코딩되지 않을 수 있다.
랜덤 액세스 메카니즘을 위해 I-프레임이 사용될 수 있는데 그 이유는 이들 프레임을 표시하는 것이 이전 또는 후속 프레임에 의존하지 않기 때문이다. 따라서, 일부 실시예들에 있어서, I-프레임을 새로 생성된 스트림에 병합하고 비트레이트를 제어하기 위해 널 패킷을 삽입함으로써 트릭모드가 사용될 수 있다.
I-프레임을 전달하는 시간은 프레임 구간보다 더 길 수 있다. 예를 들어, 평균 I-프레임 크기가 40kb인 경우, 30 fps의 I-프레임만으로 된 트릭모드 스트림은 적어도 9.8 Mbits/s(40kb x 8 x 30), 즉 케이블 업계에서 일반적으로 사용되는 3.75 Mbits/s의 레이트의 약 2.6배를 필요로 한다.
어떤 실시예들에서, 30 fps와 같은 더 높은 프레임 레이트를 유지하기 위해, I-프레임 레이트는 초당 약 10개의 I-프레임으로 감소될 수 있다. 예를 들어, 나머지 I-프레임 대신에 그외의 프레임을 삽입함으로서 레이트가 유지될 수 있다. 예를 들어, 2개 이상의 프레임 기간 또는 구간 동안에 I-프레임이 표시될 수 있으며, 이것은 후속 I-프레임이 전송 및 버퍼링될 수 있게 된다. 마지막 표시된 프레임의 복사본일 수 있는 "더미" B-프레임 또는 P-프레임이 비디오 스트림에 삽입될 수 있다. "더미" 또는 복제 프레임은, 일 실시예에서, 평균 I-프레임 크기와 비교하여 감소된 크기를 갖는 "움직임이 없는(no-motion)" 프레임일 수 있다. 더미 프레임은, 이들이 거의 동시에 인코딩될 수 있고 또 GOP의 크기를 확장시키기 위해 출력 스트림에 삽입될 수 있기 때문에, 프로세서 효율성을 제공할 수 있다.
10 I-프레임/초의 레이트를 갖는 트릭모드 스트림은 비디오 프레임의 "트릭모드 GOP" 또는 트릭모드 시퀀스의 생성을 통해 달성될 수 있다. 예를 들어, 이하의 시퀀스 IBBIBBIBBIBBIBB를 생성하기 위해, 하나의 I-프레임 및 그 뒤에 오는 2개의 더미 B-프레임으로 "트릭모드 GOP"의 시퀀스가 생성될 수 있다. 예를 들어 더미 B-프레임의 크기가 대략 1.2kb인 경우, 출력 스트림의 평균 비트레이트는 3.5 Mbits/s((40kb * 8 * 10 I-프레임/초 ) + (1.2kb * 8 * 20 B-프레임/초))이거나, 또는 3.75 Mbits/s의 최대 대역폭 레이트 내에 있다.
일부 실시예에서, 타임슬롯 할당 및 트릭모드 GOP 크기는 효율적인 대역폭 사용을 용이하게 해주기 위해 I-프레임-기반 트릭모드 스트림에서 동적으로 조정된다. 이 기술들은 또한 버퍼 오버플로우를 검출 및 방지함으로써 비디오 버퍼 이용도를 모니터한다. 일 양상에서, "더미" P-프레임이 삽입될 수 있다.
이들 기술은 또한, 버퍼 레벨을 최소 레벨로 유지하고 처리 속도가 변할 때 시스템 응답성을 향상시키면서, 대역폭 이용도를 최대화하기 위해 사용될 수 있다. 예를 들어, 8배속 스트림을 생성하기 위해, 이 기술은 평균적으로 초당 대략 10개의 고유한 I-프레임을 제공할 수 있다. 나머지 프레임(예를 들어, 초당 30 프레임의 스트림에서 초당 20 프레임)은 더미 또는 움직임이 없는 B-프레임 및 P-프레임일 수 있다.
일 실시예에서, 이 기술은 비디오 스트림 소프트웨어 제품에 포함된다. 이 기술은 또한 하드웨어, 펌웨어 또는 이들의 임의의 조합을 사용하여 달성될 수 있다.
비디오 입력 스트림은 데이터 구조체를 사용하여 파싱될 수 있다. 예를 들어, "힌터(Hinter)" 구조체 및 파싱된 데이터(즉, I-프레임 및 스트림 정보)는 "HINT" 파일이라고 하는 파일에 저장될 수 있다. 비디오 입력이 예를 들어 일반적인 펜티엄 4™ 2.4 GHz 프로세서에 의해 대략 300 Mbits/s로 수행될 수 있다는 것이 이해될 것이다. HINT 파일은 대략 64k일 수 있는 헤더를 포함할 수 있다. HINT 파일은 또한 I-프레임당 대략 128 바이트인 I-프레임 테이블을 포함할 수 있고 또 연관된 I-프레임의 위치에 대한 포인터를 가질 수 있다. 3.75 Mbits/s에서 2.0 I-프레임/초(즉, 총 14400개 I-프레임)를 갖는 2시간 길이의 영화는 원래의 파일 크기의 약 0.06%보다 더 작은, 크기가 대략 1.9 Mbyte인 HINT 파일을 생성한다. 그렇지만, 트릭모드가 입력 시에 발생될 수 없기 때문에, 예를 들어 스트리밍 소프트웨어 및/또는 하드웨어에서 사용되는 이 기술은 트릭모드 스트림을 동적으로 생성할 수 있다.
도 3은 I-프레임 시퀀스의 버퍼 레벨에 대한 영향을 나타낸 것이다. 수직축은 I-프레임의 디코드 시간을 나타낸다. 도 3에 도시된 바와 같이, 트릭모드 패킷은 버퍼링을 사용하여 "패킹"된다. I-프레임 시퀀스가 크면, 프레임 레이트에 거의 또는 전혀 영향을 주지 않고, 단기간에 버퍼 레벨이 증가하게 될 수 있다. 더미 P-프레임 및 B-프레임도 역시 전송 및 디코딩되지만, 이들은 각각 대략 1.3k 정도이고, 즉, I-프레임보다 30배 정도 작다.
일부 실시예에서, 버퍼 레벨을 조정하는 데 사용되는 기술은 고정된 타임슬롯 트릭모드 시퀀스로부터 도출될 수 있다. 이러한 시퀀스는 도 1을 참조하여 기술된 시퀀스와 유사할 수 있다. 또한, 비교적 높은 시각적 품질을 달성하기 위해, 이 기술은 거의 일정한 레이트의 I-프레임을 생성하려고 시도한다. 비디오 스트림이 임의의 분포를 갖는 I-프레임을 포함할 수 있지만, 이해 및 명확성을 위해, 이하의 설명에서는 입력된 비디오 스트림이 도 4에 나타낸 바와 같이 어떤 크기 분포 곡선을 갖는 I-프레임을 포함하는 것으로 가정한다.
고안된 기술은 과잉 크기의 I-프레임(oversized I-frame)을 수용하기 위해 과소 크기의 I-프레임(undersized I-frame)을 포함하는 타임슬롯에서의 미사용 대역폭을 재분배시킬 수 있다. 이것은 예를 들어 적절한 트릭모드 타임슬롯 크기를 선택하고(즉, GOP 크기에 기초함) 버퍼가 오버플로우하지 않게 하면서 트릭모드 패킷의 세트가 조정 또는 재배열될 수 있는 것을 보장하기 위해 충분히 큰 타임슬롯 조정 또는 창을 선택함으로써 달성될 수 있다.
전송 이전에 트릭모드 패킷의 시퀀스를 재정렬함으로써, 대역폭 이용도가 향상될 수 있다. 또한, 고안된 기술은 임의의 트릭모드 패킷 시퀀스의 GOP 크기를 수용하기 위해 통계적 평균을 구할 수 있다. 일 실시예에서, 평균을 구하는 것은 GOP 크기가 패킷 조정의 크기보다 작거나 또는 적어도 동일하게 되도록 함으로써 달성될 수 있다.
거의 고정된 타임슬롯으로부터 I-프레임의 이러한 재분배 및 재정렬의 결과, 이 기술은 디코딩 및 관련 버퍼링을 포함할 수 있다. 게다가, 버퍼 오버플로우 또는 언더플로우 조건을 방지하기 위해 버퍼링된 데이터 양의 관리가 수행될 수 있다.
도 5는 트릭모드 패킷 조정의 예시를 나타낸 것이다. 도 5에 도시된 바와 같이, 위쪽 창(501)은 어떤 과잉 크기의 트릭모드 패킷이 고정된 이용가능한 타임슬롯에 어떻게 들어맞지 않는지를 나타낸 것이다. 예를 들어, 트릭모드 패킷(506)이 고정된 타임슬롯(503) 내에 들어맞더라도, 트릭모드 패킷(504)은 후속 타임슬롯(505) 내에 들어맞지 않는다. 그 결과, 트릭모드 패킷(504)의 일부분이 타임슬롯(507)으로 넘어가게 된다.
아래쪽 창(502)은 타임슬롯이 어떻게 재배열 또는 재정렬될 수 있는지를 나타낸 것이다. 이러한 재배열은 보다 큰 트릭모드 패킷에서 사용되도록 이전 또는 후속 트릭모드 패킷으로부터의 이용가능한 대역폭 또는 "널"의 사용을 가능하게 해준다.
이하의 설명은 기술된 개념을 수학적 항으로 정량화한다. 그렇지만, 본 발명이 이들 방정식의 조작 또는 사용에 한정되지 않는다는 것이 이해될 것이다. 그 대신에, 이하의 설명은 새로운 개념에 대한 추가적인 이해를 얻기 위해 제공된 것이며, 예시적인 방정식은 본 실시예들에 의해 고안된 단지 하나의 가능한 방식을 제공한다.
비트레이트 br, 프레임 레이트 fr, 및 GOP 크기가 q 프레임인 데이터 스트림에 있어서, 주어진 타임슬롯에 전송될 수 있는 데이터 양 Q는 다음과 같이 표현될 수 있다.
Figure 112007014746317-PCT00001
I-프레임 레이트 r은 다음과 같이 계산될 수 있다.
Figure 112007014746317-PCT00002
어떤 상황에서는 GOP당 일정한 수의 프레임을 제공함으로써 보다 나은 시각적 품질을 위해 q를 정수로서 유지하는 것이 바람직할 수 있다. 대안적으로, q는 또한 GOP마다 변하게 할 수 있다(즉, GOP 크기가 변한다). 다른 가능한 실시예는 q에 대한 평균 값을 사용할 수 있다. 예를 들어, 크기 2, 3, 2, 2, 3을 가지며 초당 12.5 I-프레임을 제공하는 GOP의 시퀀스에 대해 2.4 프레임의 q의 값이 설정될 수 있다.
br = 3.75 Mbits/s, fr = 30 fps 및 q = 3인 비디오 스트림에 대해 상기 방정식을 적용하면, I-프레임 레이트가 r = 10 I-프레임/초인 경우 각각의 타임슬롯으로 46,875 바이트가 전송될 수 있게 된다.
n개 트릭모드 패킷을 갖는 조정 창에 대해 요구되는 대역폭을 추정하기 위해, 많은 측면의 추정이 고려될 필요가 있을 수 있다. 예를 들어, I-프레임 크기, 더미 B-프레임 및 P-프레임의 수 및 이들의 크기, PAT, PMT, PCR 패킷 등의 오버헤드 데이터의 크기, 및 디스크 및 네트워크 오버헤드가 고려될 필요가 있을 수 있다. 이들 값들은 추정될 수 있다. 예를 들어, 원래의 스트림에서의 I-프레임 크기가, 반드시 어떤 특정의 분포 곡선을 따를 필요는 없는 어떤 크기 분포 (I, σ 1 )를 가질 수 있는 것으로 추정될 수 있다. 트릭모드 패킷 크기를 결정함에 있어서 디스크 또는 저장 오버헤드가 추정될 수 있다.
상기 추정의 결과 대략 10% 정도의 비디오 버퍼 레벨의 과대 추정이 얻어질 수 있다. 그 결과, 일부 실시예들에서, 저장 장치로부터 직접 획득된 40kB 블록에 있어서, 비디오 버퍼에 저장될 36kB보다 작거나 같은 실제 비디오 데이터를 전송할 필요가 있을 수 있다. 나머지 4kB는 블록에 내장되어 있고 전송 전에 "널링(null)" 및 "뮤팅(mute)"되어 있는 다른 PID(예를 들어, 오디오, PMT, PAT)를 포함할 수 있다. 대안적으로, 비디오 데이터는 재정렬될 수 있고, 약 36kB의 비디오 데이터가 전송될 수 있다.
버퍼 오버플로우를 회피하기 위해, 개시된 기술은 한계를 버퍼 용량의 90%로 설정할 수 있다. 이 90% 한계는 또한 기술된 방법에서의 보다 큰 에러도 방지할 수 있다. 버퍼 레벨이 그의 한계의 90%에 도달할 가능성이 비교적 낮은데 그 이유는 트릭모드 시퀀스에서 과잉 크기의 I-프레임의 비교적 큰 시퀀스를 필요로 하기 때문이다. 게다가, 버퍼 레벨을 과대 추정함으로써, 버퍼 오버플로우를 검출할 가능성이 증가되지만, 트릭모드 성능의 열화를 그다지 야기하지 않는다.
n개의 랜덤한 I-프레임의 시퀀스에서의 각각의 I-프레임의 크기를 결정함에 있어서, 총 크기
Figure 112007014746317-PCT00003
는 분포
Figure 112007014746317-PCT00004
를 갖는 확률 변수이다. n의 값이 커질수록, 확률 분포(random distribution)(Sn)는 정규 분포에 더 가깝게 된다. 이 추정으로부터 얻어지는 임의의 에러는 P-프레임 삽입으로 정정될 수 있다.
게다가, 더미 P-프레임 및 B-프레임(P) 및 오버헤드 데이터(OH)의 크기를 추정함으로써, n개의 타임슬롯을 갖는 조정 창에 포함된 스트리밍 데이터의 총 양
Figure 112007014746317-PCT00005
은 이하의 방정식에 의해 반영될 수 있다.
Figure 112007014746317-PCT00006
Figure 112007014746317-PCT00007
조정 창에서 이용가능한 대역폭은 이하의 방정식으로 반영될 수 있다.
Figure 112007014746317-PCT00008
트릭모드 패킷의 시퀀스가 지정된 조정 창에 들어 맞을 확률을 최대화하기 위해, 일부 실시예에서, 개시된 기술은 정정을 실행해야만 하는 저확률(low probability) ε(단, ε>P(Tn>Qn)임)을 10-3 차수의 값으로 유지하도록 시도할 수 있다.
Sn이 정규 분포로 간주될 수 있도록 n이 충분히 크다고 가정할 때, n은 이하의 방정식을 만족시킬 정도로 충분히 클 수 있다.
Figure 112007014746317-PCT00009
이하의 실수 값, 즉 Br = 3.75 Mbits/s, fr = 29.97 fps, q = 3 프레임, I = 40491 바이트, σT = 10835 바이트, P = 1.0kb, OH = 2.0kb를 상기 방정식에 넣으면, 이하의 식들이 얻어진다.
Figure 112007014746317-PCT00010
Figure 112007014746317-PCT00011
Figure 112007014746317-PCT00012
ε=10-3인 경우, 조정 창은 다음과 같이 된다.
Figure 112007014746317-PCT00013
Figure 112007014746317-PCT00014
Figure 112007014746317-PCT00015
Figure 112007014746317-PCT00016
I-프레임의 평균 크기가 선택된 타임슬롯 크기보다 단지 약간 작은 경우, 설명된 기술은 약 10 I-프레임/초의 트릭모드 스트림을 가능하게 해준다. 또한, 이 예에서, 대역폭 이용도는 대략 97%(즉, 44587 바이트/45922 바이트)이다. 실제 대역폭 이용도 퍼센트는 버퍼 오버플로우로 인한 정정(예를 들어, p-프레임 삽입)을 해야 할 필요성에 의해 감소될 수 있다.
이하의 예는 조정 창 크기를 선택하고 최대 트릭모드 속도 또는 최소 GOP 크기(q)를 결정함으로써 다른 방식을 갖는다.
Figure 112007014746317-PCT00017
Figure 112007014746317-PCT00018
Figure 112007014746317-PCT00019
Figure 112007014746317-PCT00020
Figure 112007014746317-PCT00021
Figure 112007014746317-PCT00022
여기서, 조정 창 크기(N)는 64 샘플로 설정되고, ε는 10-3이며, 허용된 I-프레임 레이트가 계산된다. 이것은 스트림으로부터 통계를 수집하고 최대 트릭모드 속도를 계산함으로써 달성될 수 있다. I-프레임 통계는, 앞서 기술한 바와 같이, 스트림과 연관된 "HINT" 파일에 저장될 수 있다. q = 3.127의 결과는 대략 9.6 I-프레임/초일 수 있으며, 비규칙적인 GOP 크기, 예를 들어 3,3,3,3,3,4,3,3을 생성하는 것을 가능하게 해준다. 그외의 실시예에서, 이 결과는 올림되어(round up) 그 다음 정수인 q = 4로 될 수 있으며, 그 결과 초당 7.5 I-프레임이 얻어진다.
버퍼 조정 기술은 파라미터들의 세트가 각각의 트릭모드 패킷으로부터 계산될 것을 필요로 할 수 있다. 이들 파라미터들은 I-프레임 선택, I-프레임 데이터 수집 및 제어 변수의 초기화에 관한 것일 수 있다.
I-프레임 선택과 관련하여, 일정한 속도(예를 들어, 15x, 30x, -10x...)로 트릭모드 스트림을 발생하기 위한 I-프레임의 시퀀스가 결정될 수 있다. 속도(s), 선택된 GOP 크기(q), 그리고 프레임 레이트(fr) 및 스트림에서의 초당 I-프레임의 평균 수(Ir)와 같은, 원래의 스트림으로부터 추출된 정보에 기초하여 I-프레임 시퀀스가 결정될 수 있다. Ir은 MPEG2 파일이 처음으로 입력되고 HINT 파일에 저장되는 힌팅 프로세스의 일부로서 계산될 수 있다.
더 잘 이해하기 위해 이하의 예시적인 실시예가 제공된다. 초당 2 I-프레임의 평균 및 10 I-프레임/초로 발생되는 트릭 모드 스트림을 가정하면, 모든 I-프레임이 선택되는 경우, 트릭모드 스트림은 속도 5x로 발생된다. 만약, 대안적으로 하나 걸러 하나씩 I-프레임이 선택되는 경우(즉, 증분이 2임), 10x의 트릭모드 스트림이 발생될 수 있다. 마지막으로부터 첫 번째까지 하나 걸러 하나씩 I-프레임을 선택하면(역방향 순서, 증분 -2) -10x의 트릭모드 속도가 얻어진다.
트릭모드 속도(s)에서의 I-프레임/초(Ir)의 평균을 갖는 비디오 스트림의 경우, 인덱스 증분(i) 부동 소수점은 i=sqIr/fr로서 계산될 수 있다. 인덱스 증분은 그 역시 변수인 I-프레임 인덱스(x)의 시퀀스를 계산하는 데 사용될 수 있다. 실제 I-프레임은 하기의 예에서 제공되는 인덱스의 시퀀스를 라운딩(rounding)함으로써 얻어질 수 있다.
Ir = 2 I-프레임/초이고, b = 3 또는 10 I-fps이며, fr = 30 fps이다. 트릭모드가 I-프레임 번호 600(즉, 영화의 시작으로부터 대략 5분)에서 시작하여 속도 -16x로 실행되는 경우(즉, 고속 되감기), I-프레임 인덱스의 시퀀스는 600이고, I = 3.2 = -16 x 3 x 2/30이다. 따라서, 생성되는 인덱스의 시퀀스는 600.0, 596.8, 593.6, 590.4, 587.2, 584.0 등이다. 또한, 버퍼 조정 알고리즘에 대해 선택된 I-프레임의 시퀀스는 600, 597, 594, 590, 587, 584 등이다.
트릭모드 재생 속도가 더 작은 경우, 예를 들어 4배속인 경우, 그 결과 얻어지는 인덱스 증분은 1.0보다 작을 수 있으며 프레임의 반복을 야기할 수 있다. 이들 경우에, GOP 크기(q)는 계산된 인덱스 증분에 기초하여 I-프레임 선택 동안에 수정될 수 있다. 예를 들어, 상기 값들을 사용하면, GOP 크기(q)는 3.75로 수정되어 4.0으로 올림될 수 있다. 이것은 초당 I-프레임의 평균 수를 초당 10 I-프레임에서 초당 7.5 I-프레임으로 감소시킬 수 있다. 이것에 의해 인덱스 증분이 약 i = 1.067로 된다.
또한, 일부 실시예들은 GOP 크기(q)를 변수 또는 부동 소수점으로 처리할 수 있으며, 따라서 인덱스 증분이 1.0으로 제한되고 q가 정수 아닌 값, 예를 들어 3.75를 가질 수 있다는 것이 이해될 것이다. 이것에 의해 4,4,4,3 등의 크기를 갖는 GOP의 시퀀스가 생성된다.
I-프레임 데이터 컬렉션과 관련하여, I-프레임의 시퀀스가 결정되면, I-프레임에 관한 정보가 수집될 수 있고 어떤 데이터 구조체가 초기화될 수 있다(예를 들어, 트릭모드 패킷당 하나 이상). 데이터는 단지 적절한 I-프레임 엔트리를 가리킴으로써 HINT 파일로부터 획득될 수 있다.
이하의 설명은 사용될 수 있는 데이터 정보의 유형의 일부 예들을 제공한다. "시작" 데이터가 수집될 수 있다. 시작 데이터는 I-프레임과 연관된 PES 헤더를 포함하는 전송 스트림 패킷의 오프셋이다. 이것은 I-프레임이 시작하는 오프셋일 수 있다. "종료" 데이터도 역시 수집될 수 있다. 종료 데이터는 파일에서의 I-프레임의 마지막 오프셋일 수 있다. 이것은 마지막 I-프레임 비디오 데이터를 지난 오프셋이다. 시작 오프셋과 종료 오프셋 사이에, 다른 비디오가 아닌 전송 스트림 패킷이 파일에 존재할 수 있다는 것이 이해될 것이다. 이들 패킷은 스트리밍 이전에 널(null)로 변환될 수 있다.
"크기" 데이터도 역시 수집될 수 있다. 크기 데이터는 전체 I-프레임을 포함하는 전송될 수 있는 데이터량인 차이(종료 - 시작)로서 계산될 수 있다. "타임코드(timecode)" 데이터도 역시 수집될 수 있다. 타임코드 데이터는 스트리밍되고 있는 현재 타임코드를 결국에는 질의하는 다른 컴포넌트와의 인터페이스를 제공할 수 있다. 타임코드는 GOP 헤더에서 발견될 수 있고 또 힌팅 프로세스 동안에 추출될 수 있다.
"파일 PCR" 데이터도 역시 수집될 수 있다. 파일 PCR 데이터는, 스트리밍 소프트웨어가 PCR 재스탬핑(restamping)을 수행할 수 있도록 하기 위해, 시작 오프셋과 연관되어 있을 수 있다. "파일 DTS" 데이터가 수집될 수 있고 이 데이터는 DTS 재스탬핑을 수행하기 위해 또 정규의 재생과 트릭모드 사이의 원활한 버퍼 전환 그리고 다시 정규의 재생으로의 전환을 수행하기 위해 원래의 자료(asset)에서의 I-프레임과 연관되어 있다. "파일 PTS" 데이터가 수집될 수 있고, 이 데이터는 PTS(Presentation Time Stamp, 현재 시각 스탬프) 재스탬핑을 수행하기 위해 또 모든 전환에서 프레임 구간을 보존하기 위해 원래의 자료에서의 I-프레임과 연관되어 있다.
"CC 시작" 및 "CC 종료" 데이터가 수집될 수 있다. CC 시작 데이터는 시작 패킷의 전송 스트림 연속성 카운터이다. CC 종료는 종료 패킷의 연속성 카운터이다. CC 시작 및 CC 종료 데이터는 일부 실시예에서 CC 재스탬핑을 수행하기 위해 필요할 수 있다.
"다음 필드" 데이터가 수집될 수 있다. 다음 필드 데이터의 경우, I-프레임은 "첫 번째 필드 반복" 플래그를 사용하여 인코딩될 수 있으며, 따라서 이들은 2개가 아닌 3개의 필드를 포함한다. 전환 동안에 필드의 시퀀스를 유지하기 위해, 전환 이후의 첫 번째 더미 B-프레임에서 필드 조정 메카니즘이 사용될 수 있다.
제어 변수의 초기화와 관련하여, 일정한 스트리밍 변수를 추적하는 것이 바람직할 수 있다. 예를 들어, 스트림 오프셋, 스트림 PCR, 스트림 DTS, 및 스트림 PTS이 있다. 스트림 오프셋은 스트리밍 소프트웨어에 의해 생성되는 총 데이터량일 수 있으며, 이는 파일 오프셋과는 다르다. 스트림 PCR은, PCR 재스탬핑 메카니즘 이후에 출력 스트림에서 관찰되는 실제 PCR일 수 있다. 스트리밍 소프트웨어가 일정한 비트레이트로 동작하기 때문에, 스트림 오프셋 증분은 스트림 PCR 증분과 연관될 수 있다.
일부 필드가 시작될 수 있다. 예를 들어, "frames"은 프레임의 수일 수 있거나, 현재 트릭모드 패킷의 GOP 크기일 수 있다. 처음에, 이 숫자는 이전에 계산된 숫자인 q로 설정되지만, 필요에 따라 증분될 수 있다(예를 들어, p-프레임 삽입 메카니즘). q가 부동 소수점 또는 변수로서 구현되는 경우, 프레임의 수는 이하에 나타낸 에러 전파 메카니즘에 기초하여 계산될 수 있다(즉, q_error는 0의 값으로 초기화됨).
Figure 112007014746317-PCT00023
Figure 112007014746317-PCT00024
q=2.6666...이면, 생성되는 시퀀스는 프레임={2,3,3,2,3,3 등}으로 된다.
패킷 크기 필드는 총 패킷 크기를 나타낸다. 패킷 크기는 이전 패킷의 타임슬롯에 기초할 수 있으며, 정수가 아닌 수의 TS 패킷을 생성할 수 있다. 이것은 이전의 트릭모드 패킷으로부터의 초과를 고려할 수 있는 에러 전파 메카니즘에 의해 정정될 수 있다. 이 때, 188 바이트(전송 스트림 패킷 크기) 또는 1316 바이트(UDP를 통한 MPEG2 패킷 크기) 등의 전체 트릭모드 패킷에 대한 일정한 세분화(granularity)가 시행될 수 있다.
제1 트릭모드 패킷은, 스트리밍 엔진의 상태에 따라 다르게 처리될 수 있다. 예를 들어, 스트리밍 엔진이 비활성(즉, 일시정지 및 정지)인 경우에는, 디코더가 비활성이기 때문에 버퍼 언더플로우의 위험이 없을 수 있다. 패킷 크기는 0으로 설정될 수 있으며 조정 기술에 의해 수정될 수 있다. 한편, 스트리밍 엔진이 동작하고 있는 경우, 제1 타임슬롯은 정상 속도로 표시되는 마지막 프레임의 DTS와 현재 PCR 간의 차이에 기초하여 계산될 수 있다. 다시 말해, 제1 트릭모드 패킷은 버퍼가 "정상 재생" 데이터로부터 거의 고갈된 이후에 디코딩될 수 있다. 이것은 "재생"으로부터 "트릭모드"로 전환하는 데 사용되는 "디버퍼링(debuffering)" 기술일 수 있다.
이 경우에, 트릭모드 패킷 크기를 계산하는 시퀀스는 이전 패킷 (frames[j-1]*fr)의 타임슬롯에 기초할 수 있다. 패킷 크기 및 패킷 초과(packet excess)는 부동 소수점 또는 변수일 수 있으며, 다음과 같이 계산될 수 있다.
Figure 112007014746317-PCT00025
패킷 초과는 트릭모드 패킷에 대해 일정한 세분화를 시행하는 데 사용되는 제어 변수일 수 있으며, 패킷 크기를 확장할 때 세분화를 보존하기 위해 P-프레임 삽입 기술에 의해 사용될 수 있다. 데이터 크기는 I-프레임, 더미 B-프레임 및 P-프레임, PAT, PMT 및 트릭모드 패킷을 조립하는 것과 연관된 오버헤드를 포함하는 총 데이터 크기를 나타낼 수 있다. data_size는 다음과 같이 계산될 수 있다.
Figure 112007014746317-PCT00026
"bw_balance"는 버퍼 조정을 위해 이용가능한 대역폭을 나타낼 수 있다. 이것은 packet_size와 data_size 간의 차이일 수 있다. 미사용 대역폭은 널로 채워질 수 있으며, 그에 의해 스트림 비트레이트를 유지할 수 있다.
일부 실시예에서 트릭모드 패킷의 최소 크기가 부과될 수 있다. 이것은 계산된 실제의 가용 대역폭보다 더 적은 대역폭이 조정될 수 있게 함으로써 달성될 수 있다. 일부 실시예에서, 트릭모드 패킷의 크기를 결정할 때 하드웨어 제약에 의해 부과될 수 있는 최소 "탐색 시간" 또는 트릭모드 패킷들 간의 최소 지연 등의 하드웨어 제한이 고려될 수 있다. 또한, 이들 고려사항이 q의 계산에 포함될 수 있는데, 그 이유는 그것이 트릭모드 대역폭이 어떻게 사용될 수 있는지에 관한 어떤 가정을 변경하기 때문이다.
또한, 예를 들어 UDP 패킷을 통한 전송 스트림에 대해 1316인, 조정될 수 있는 일정한 세분화가 널 패킷에 부과될 수 있다. 이것은 스트리밍 소프트웨어 또는 하드웨어의 특정의 구현에 의존할 수 있다. 가용 대역폭은 다음과 같이 계산될 수 있다.
Figure 112007014746317-PCT00027
bw_balance는 종종 과잉 크기의 패킷을 나타내는 마이너스 값을 가질 수 있다. 마이너스 값은 다른 트릭모드 패킷으로부터 가져올 필요가 있는 그 트릭모드 패킷에 대해 모자라는 대역폭의 양일 수 있다. 이것은 작은 패킷으로부터의 가용 대역폭을 사용하는 것을 통해 큰 패킷에 의해 요구되는 대역폭의 균형을 맞춤으로써 달성될 수 있다. 파라미터 ε에 따라 조정 창에서의 가용 대역폭의 전체적인 균형이 플러스(Σbw_balance[i]>0)가 되도록 하기 위해 통계적 분석이 사용될 수 있다.
"스트림 오프셋"은 패킷에 대해 예상되는 현재의 스트림 오프셋일 수 있다. 현재 패킷이 전송될 첫 번째 것인 경우, 그 패킷은 상기한 바와 같은 스트리밍 엔진으로부터 가져온 스트림 오프셋일 수 있다.
Figure 112007014746317-PCT00028
"스트림 PCR"은 디스크로부터 검색된 비디오 데이터의 정확한 PCR 재스탬핑을 위해 필요할 수 있다.
Figure 112007014746317-PCT00029
"스트림 DTS"는 트릭모드 GOP의 일부로서 전송될 I-프레임의 디코드 시간을 나타낼 수 있다. DTS 및 PTS는 이들에 300을 곱함으로써 PCR과 동일 시간 기반에 있을 수 있다. 재생으로부터 트릭모드로의 전환이 있는 경우, 전술한 바와 같이 필드 조정을 가능하게 해주기 위해 DTS는 프레임의 1/2만큼 정정될 필요가 있을 수 있다. 그렇지 않으면, 트릭모드 패킷 DTS는 다음과 같이 계산될 수 있다.
Figure 112007014746317-PCT00030
"스트림 PTS"는 다음과 같이 I-프레임의 정확한 표시 시간을 나타낸다.
Figure 112007014746317-PCT00031
"버퍼 레벨"은 디코더에서의 최대 버퍼 레벨일 수 있으며, 비디오 데이터의 마지막 블록이 peak_offset[j] = stream_offset[j]+data_size[j]에 의해 주어진 오프셋에서, 디코더에 의해 수신되는 순간에 달성될 수 있다.
버퍼는 이전의 GOP로부터의 어떤 더미 B-프레임 및 P-프레임을 포함할 수 있으며, 최대 버퍼 레벨은 bufferlevel[j] = size[j]+(frames[i]-1)*P+(frames[i-1]-1)*P로서 계산될 수 있다. 현재의 트릭모드 패킷이 전송되고 있는 동안에 이전의 GOP로부터의 더미 B-프레임 및 P-프레임이 소모되는 것을 고려하면, 실제 버퍼 레벨은 상기 값보다 작을 수 있다. 버퍼 레벨은 오버플로우로부터 보호하기 위해 과대 평가될 수 있다. 현재의 트릭모드 패킷의 DTS(즉, I-프레임 DTS)에서, 이전의 GOP로부터의 데이터가 소모될 수 있고, 버퍼 레벨은 bufferlevel[j] = size[j]+(frames[j]- 1)*P일 수 있다.
도 2는 시간에 따른 디코드 버퍼를 나타낸 것이다. 상기한 실시예는 DTS[j]에 의해 주어진 순간에, I-프레임이 디코드되기 이전에 버퍼 레벨을 제어할 수 있다. 이것은 버퍼 레벨 피크가 이 위치로 이동하게 하는 버퍼 조정으로 인한 것이다. 이전의 트릭모드 패킷으로부터의 더미 B-프레임 및 P-프레임의 크기가 비교적 작을 수 있기 때문에, 디코드 시간을 나타내는 "스트림 DTS"를 갖는 공식이 무리없이 사용될 수 있는데, 그 이유는 특히 I-프레임 크기가 상기한 바와 같이 과대 평가되기 때문이다. 대안적으로, 버퍼가 오버플로우에 이르지 않도록 하기 위해, "스트림 오프셋"이 현재 스트림인 공식이 사용될 수 있다.
상기한 바와 같이, 도 5는 이용가능한 타임슬롯 구간을 재배열하기 위해 트릭모드 패킷이 어떻게 조정될 수 있는지를 나타낸 것이다. 상기한 바와 같이, 제어 변수 bw_balance[j]가 마이너스인 경우, 이는 패킷이 그의 처음에 지정된 타임슬롯에서 전송될 수 없음을 나타낸다. 본 발명의 기술은, 도 5에 나타낸 바와 같이, 패킷을 단축시키면서, 패킷 크기를 변경 및 확장하고 이전의 패킷으로부터의 가용 대역폭을 소모한다.
패킷을 단축시키면서, 패킷 크기를 변경 및 확장하고 이전이 패킷으로부터의 가용 대역폭을 소모하는 C 코드의 일례는 다음과 같을 수 있다.
Figure 112007014746317-PCT00032
이 코드 세그먼트는 조정 창에서 가용 대역폭이 재배열될 수 있게 해줄 수 있으며, 또 트릭모드 패킷이, 그의 디코드 시간(DTS)이 되기 이전에, 완전히 전송될 수 있게 보장해줄 수 있다.
또한, 대역폭을 재배열하는 것 이외에 버퍼 레벨을 고려하는 것이 요망될 수 있다. 또한, 일부 실시예에서, 첫 번째 트릭모드 패킷 bw_balance[j]는 마이너스일 수 있으며, 그것이 시퀀스에서 첫 번째 패킷이기 때문에, 대역폭을 할당받을 이전의 패킷이 없을 수 있다. 이하에서 기술하는 바와 같이 P-프레임 삽입 및 전환 기술이 사용될 수 있다. 게다가, 제어 기술이 각각의 트릭모드 패킷의 파라미터를 계산하고 있지만, 그것이 반드시 스트림을 생성해야 하는 것은 아닐 수 있다. 이것은 트릭모드 스트림을 발생하기 위해 조정 기술을 사용하는 스트리밍 엔진에 의해 달성될 수 있다.
도 6은 트릭모드 패킷을 이동하는 것의 버퍼 레벨에 대한 영향을 나타내는 그래픽 표현이다. 도 6이 트릭모드 패킷을 이동하는 것과 관련하여 버퍼 레벨에 대한 영향을 설명하고 있지만, 일부 실시예들에서 다른 대역폭 제어 기술은 물론 다른 데이터 조작 기술이 버퍼 제어를 필요로 할 수 있다는 것을 잘 알 것이다.
도 6에 도시한 바와 같이, 위쪽 창(600)은 트릭모드 패킷이 이동되기 이전의 버퍼 레벨을 반영한 것인 반면, 아래쪽 창(601)은 트릭모드 패킷이 대역폭 제어에 따라 이동된 후의 버퍼 레벨을 반영한 것이다. 위쪽 창(600)에 표시된 바와 같이, 패킷(602)은 시점(603)에서 DTS 이후(즉, 디코드 시간이 될 때)까지 완전히 수신되지 않는다. 트릭모드 패킷을 이동하는 것은 DTS에서 최대 버퍼 저장 레벨(604)을 생성할 수 있다. 게다가, 최대 버퍼 레벨은 이동된 트릭모드 패킷(605)에서의 데이터 양과 같을 수 있다. 트릭모드 패킷이 디코드될 수 있게 되기 전에 이 트릭모드 패킷의 완전한 버퍼링을 가능하게 해주기 위해 그 차이(data_size[j]-packet_size[j])가 DTS[j-1] 시점에서 디코더 버퍼에 준비되어 있을 수 있다.
이하의 코드는 최대 버퍼 레벨을 추정하는 단지 한 예일 수 있다.
Figure 112007014746317-PCT00033
과잉 크기의 프레임(즉, 지정된 타임슬롯을 넘는 크기를 갖는 프레임)이 전송될 때마다 버퍼 레벨이 증가할 수 있다. 과잉 크기의 프레임의 긴 시퀀스를 조정할 때 버퍼 오버플로우가 일어날 수 있다. 이용가능한 타임슬롯보다 큰 데이터 양이 결정되면, 버퍼 오버플로우를 수용하기 위한 조치를 취하는 것이 바람직할 수 있다. 이것은 임의의 수의 기술을 사용하여 달성될 수 있다. 이후의 예들은 본 실시예들에 의해 고려된 모든 기술들을 배제하려는 것이 아니다.
버퍼 오버플로우를 처리하는 한가지 기술은 P-프레임 삽입을 포함할 수 있다. P-프레임 삽입은 P-프레임을 추가하며 따라서 부가적인 대역폭을 생성하기 위해 이전의 GOP의 크기를 확장한다. 부가적인 P-프레임을 삽입하는 것은 다수의 방식으로 달성될 수 있다. 부가적인 대역폭을 발생하기 위해 P-프레임을 삽입하는 한가지 기술에 대해 설명할 것이다. 그렇지만, 개시된 실시예들은 이 방식에 한정되지 않는다. 한가지 예는 다음과 같다.
큰 트릭모드 패킷을 갖는 3.75 Mbits/s 비디오 스트림을 갖는 트릭모드 스트림은 6 프레임 주기를 전송할 필요가 있을 수 있다. 그렇지만, 타임슬롯이 이전 패킷의 GOP 크기에 의해 결정되는 바와 같이 단지 4 프레임일 수 있다. 전술한 바와 같이, 전송을 위한 부가의 기간을 수용하기 위해 패킷이 2 프레임 주기만큼 이동 및 확장될 수 있다. 전술한 바와 같이, 트릭모드 패킷을 2 프레임 이동시키는 것은 대략 30kb만큼의 이전 패킷의 피크 버퍼 레벨의 증가를 야기할 수 있다. 100kb의 비디오 버퍼 크기 및 90kb의 이전의 패킷 크기에 있어서, 또 다른 30kb를 버퍼링하려고 하는 것은 버퍼 오버플로우를 야기하게 된다.
일 실시예에서, 더미 P-프레임이 부가될 수 있다. 예를 들어, 2개의 부가의 P-프레임이 추가되면, 각각이 P-프레임당 대략 1kb인 경우, 이전의 GOP 크기는 6으로 증가될 수 있다. 버퍼 레벨은 단지 2kb만큼 증가하여 92kb가 되며, 여전히 100kb 제한 내에 있다. 이전의 GOP에 2개의 부가의 더미 P-프레임을 추가함으로써, "과잉 크기의" 패킷 전체가 전송될 수 있도록 현재의 패킷 크기가 확장될 수 있다. 다시 말해, 이 기술은 부가의 2 프레임 주기 동안 이전의 프레임을 스크린에 유지시키며, 과잉 크기의 프레임이 완전히 전송될 수 있게 해준다. 게다가, 삽입되는 각각의 부가의 P-프레임이 약 1 프레임 주기만큼 후속 트릭모드 패킷을 확장시킬 수 있기 때문에, 부가의 대역폭이 획득될 수 있다. 이 예에서, 약 1kb의 더미 P-프레임 각각이 약 15kb의 대역폭을 생성하며, 이는 하나의 프레임 주기에 전송될 수 있는 데이터 양을 나타낸다.
또한, 더미 P-프레임을 삽입함으로써, 전체 I-프레임 레이트가 감소될 수 있고 조정 창이 한 프레임 확장될 수 있다. 버퍼 오버플로우가 검출될 때마다 여분의 프레임을 삽입할 수 있는 코드 세그먼트 예가 이하에 나타내어져 있다.
Figure 112007014746317-PCT00034
일부 실시예들은 또한 예를 들어 적어도 하나의 전송 스트림 패킷(예를 들어, 일반적으로 188 바이트)일 수 있는 트릭모드 패킷의 세분화를 분석하는 것과 관련될 수 있다. P-프레임을 삽입함으로써 생성된 대역폭은 이하의 식에 의해 결정될 수 있다.
increment = (b/8)*(1/fr)
상기 예에서, 증분은 15,625바이트이다. 각각의 트릭모드 패킷 크기가 처음에 에러 전파 기술을 사용하여 결정되었기 때문에, 보다 정확한 양의 메모리를 계산하기 위해 유사한 방식이 고려될 수 있다. 예를 들어, 이것은 트릭모드 GOP 크기 q = 4, 비디오 버퍼 크기 110kb, 및 1316 바이트의 패킷 세분화를 갖는 크기 25kb, 90kb, 40kb, 70kb, 80kb, 80kb 및 80kb의 트릭모드 데이터(예를 들어, 단일의 UDP 패킷 내의 7개의 전송 스트림 패킷)에 대해 결정될 수 있다.
계산된 타임슬롯은 62,500 바이트 = 4*15,625 바이트이다. 따라서, 에러 전파 기술은 다음의 61852, 61852, 63168, 61852, 61852, 63168 및 61852의 크기를 갖는 패킷의 시퀀스를 생성할 수 있다. 이 기술은 또한 35532, -31584, 21056, -10528, -21056, -19740 및 -21056의 bw_balance 값을 갖는 0, 61852, 123164, 186332, 248184, 310036, 및 373204의 패킷 오프셋을 생성할 수 있다. 버퍼 레벨이 처음에 트릭모드 데이터 크기와 동일한 것으로 추정되는 경우 마지막 패킷(인덱스 6, 0-기반 인덱스)으로부터 시작하여 버퍼 조정 기술을 적용하면, 널 크기는 이하에 나타낸 바와 같이 차이(packet_size - data_size)로서 계산될 수 있다(유의할 점은 타임스탬프가 이 때 생략된다는 것이다(PCR, DTS, PTS)).
Figure 112007014746317-PCT00035
두 번째 단계에서, 이하의 것이 행해질 수 있다.
Figure 112007014746317-PCT00036
이 때, 여분의 더미 P-프레임이 트릭모드 패킷 4 상에 삽입될 수 있으며, 따라서 그의 GOP 크기는 5로 변한다. 1316 바이트의 P-프레임 크기를 가정하면, 이하의 시퀀스를 제공한다.
(P-프레임 삽입)
Figure 112007014746317-PCT00037
삽입된 P-프레임으로 인해 이하의 부가적인 대역폭이 제공될 수 있다.
(P-프레임 삽입)
Figure 112007014746317-PCT00038
(삽입된 P-프레임으로 인해 대역폭을 부가함)
Figure 112007014746317-PCT00039
(프레임 삽입을 후속 패킷으로 전파함)
Figure 112007014746317-PCT00040
세분화가 관심사인 실시예에서, packet_size와 관련하여 상기한 동일한 에러 전파 기술을 사용하여 새로운 GOP 크기에 기초하여 패킷 크기가 재계산될 수 있다.
도 7은 트릭모드 스트림을 생성하는 데 버퍼 최적화가 어떻게 사용될 수 있는지를 나타낸 것이다. 도 7에 나타낸 바와 같이, 조정을 필요로 하는 패킷은 교차 해칭되어 나타내져 있는 반면, 성공적으로 조정된 패킷은 점을 찍어 나타내어져 있다. 위쪽 창(700)은 버퍼 최적화 기술이 이용되기 이전에 트릭모드 패킷이 처음으로 계산될 때의 트릭모드 패킷을 나타낸 것이다. 두 번째 창(701)은 마지막 과잉 크기의 프레임이 어떻게 확장되고 이동되어 이전 프레임이 그의 가용 대역폭을 소모하게 하는지를 나타낸 것이다. 두 번째 창(701)은 또한 동일한 패킷을 이동시키는 것이 버퍼 레벨에 어떻게 영향을 줄 수 있는지도 나타내고 있다. 세 번째 창(702)은 성공적으로 조정된 패킷을 나타낸 것이다. 도 8은 이들 기술을 사용하여 생성된 트릭모드 스트림의 예시적인 출력을 나타낸 것이다.
I-프레임 기반 기술이 "저지연" 모드에서 동작할 수 있으며 따라서 버퍼 레벨이 디코더에서 낮게 유지된다는 것이 이해될 것이다. 정상 재생에서 영화를 재시작하기 위해, 디코더는 0.5s 내지 1.0s의 데이터를 버퍼링할 수 있다. 버퍼 레벨에서의 차이는 버퍼 언더플로우를 야기할 수 있으며, 이는 화면이 흔들리거나 깜박거리게 할 수 있거나 심지어 잠시동안 검게 될 수 있다.
파일-기반 트릭모드는 트릭모드 파일과 정규 파일 간에 전환할 수 있다. 이 기술은 전환 시에 버퍼 레벨이 일치해야 할 것을 필요로 할 수 있고, 따라서 트릭모드 파일이 발생될 때 버퍼 레벨이 제어될 수 있다. 전환 시에 버퍼 레벨을 조정하기 위해 부가의 로직이 추가될 수 있다.
일 실시예에서, 정상 재생을 재개할 때, 버퍼 관리 기술은, 보다 정밀한 전환을 위해 버퍼 레벨을 증가시킴으로써, 마지막 트릭모드 프레임(일반적으로 2-4 프레임)을 수정하는 동작을 할 수 있다. 이러한 소위 "스플라이싱(splicing)" 기술은 마지막 프레임의 속도를 감소시킬 수 있고, 재버퍼링을 위해 사용될 수 있는 대역폭을 과도하게 생성할 수 있으며 비디오 버퍼가 정상 레벨로 복원하게 해줄 수 있다. 이 기술은 움직임의 감각을 방해하지 않는 방식으로 구현될 수 있으며, 따라서 전환이 비교적 매끄럽다.
재생 시퀀스 이후에 트릭모드를 재생하기 시작하기 위해, 비디오 버퍼에 저장되어 있을 수 있는 재생 데이터가 디코더에 의해 소모될 수 있다. 트릭모드 스트림이 디코딩되기 시작할 때 이러한 일이 일어나며, 비디오 버퍼에 존재하는 데이터는 트릭모드 스트리밍 엔진에 의해 생성되는 데이터이다. 재생되고 있는 마지막 프레임의 DTS + 프레임 구간으로 DTS가 설정되어져서 첫 번째 트릭모드 패킷이 전송될 수 있다. 또한, PTS는 표시되는 마지막 프레임의 PTS + 한 프레임으로 설정될 수 있다. 마지막 프레임의 "첫 번째 필드 반복" 플래그가 1로 설정되어 있는 경우, PTS 및 DTS는 프레임 주기의 1/2만큼 증분된다.
이하의 식, 즉 frame_size[0] = ((StreamDTS - StreamPCR)/27000000.0)* (bI/8)을 사용하여 첫 번째 트릭모드 패킷 크기를, 현재 위치(PCR)로부터 재생 버퍼가 비어 있고 또 첫 번째 트릭모드 프레임이 예상되는 때(예를 들어, 상기한 DTS)까지 전송될 수 있는 데이터 양으로 설정함으로써 디버퍼링(de-buffering) 기술이 구현될 수 있다.
어떤 비디오 스트림(예를 들어, MPEG2)이, 3:2 풀다운을 수행하는 방법으로서, 어떤 특수 플래그 "첫 번째 필드 반복" 및 "상부 필드 우선"을 사용할 수 있다는 것이 이해될 것이다. 그 스트림에서 필드 연속성을 유지하기 위해, 전환 시퀀스에서 어떤 기술이 적용될 수 있다.
예를 들어, 표시된 마지막 프레임이 "상부 필드 우선"이 0으로 설정되어 있고(하부 필드 우선) "첫 번째 필드 반복"이 0으로 설정되어 있는 한가지 기술이 사용될 수 있다. 이것은 마지막 프레임이 상부 필드의 표시를 완료하였음을 나타낸다. 마지막 프레임이 "상부 필드 우선"이 1로 설정되어 있고(상부 우선) "첫 번째 필드 반복"이 1로 설정되어 있는 경우, 이 또한 표시된 마지막 필드가 상부 필드이었음을 나타낼 수 있다. 어느 경우든지, 그 다음으로 예상된 필드가 하부 필드일 수 있다. 이들 기술이 "상부 필드 우선"을 가정하고 있기 때문에, 필드 조정 프레임이 삽입될 수 있다.
이들 기술은 더미 B-프레임일 수 있는 바로 그 첫 번째 트릭모드 프레임에서 "상부 필드 우선" 플래그를 0으로 설정하고 "첫 번째 필드 반복" 플래그를 1로 설정함으로써 수행될 수 있다. 이 시퀀스(하부, 상부, 하부)는 재생 시퀀스로부터 필드 시퀀싱을 유지할 뿐만 아니라 후속 프레임이 상부 필드부터 시작할 수 있게 해줄 수 있다.
이 필드 조정 기술은 GOP 크기를 1/2 프레임(즉, 한 필드)만큼 확장시킨다. 디스크로부터 판독된 모든 I-프레임이 적절한 필드 시퀀싱을 갖도록 하기 위해, I-프레임이 디스크로부터 메모리로 판독된 후에 행해지는 재스탬핑 기술을 통해, I-프레임에서 "상부 필드 우선" 플래그가 1로 설정될 수 있고 "첫 번째 필드 반복" 플래그가 0으로 설정될 수 있다.
일부 실시예들에서, 재생 시퀀스가 비교적 낮은 버퍼 레벨에서 동작할 때, 첫 번째 트릭모드 패킷을 전송하기에 충분한 시간이 없을 수 있다. 재생 시퀀스로부터의 마지막 프레임이 소모될 때쯤에, 첫 번째 트릭모드 패킷은 여전히 전송되고 있는 중일 수 있다. 한가지 해결책은, P-프레임 삽입 기술과 유사하게, P-프레임의 시퀀스를 트릭모드 패킷의 시작에 첨부하는 것이다. 이들 P-프레임은 트릭모드 GOP의 일부가 아닐 수 있지만, 트릭모드 패킷이 완전히 전송될 수 있도록 이전 GOP(즉, 재생 시퀀스)를 확장하고 디코더로 하여금 몇 프레임 구간 동안 마지막 픽처를 반복하게 한다.
게다가, 트릭모드로부터 다시 정상 재생으로 전환하기 위해 사용되는 방법은 여분의 가용 대역폭을 생성하기 위해 트릭모드 시퀀스의 마지막 GOP를 확장하는 것에 의해 달성될 수 있다. 예를 들어 고지연 모드에서 동작하는 새로운 재생 시퀀스로부터 비디오 데이터를 재버퍼링하기 위해 가용 대역폭이 사용될 수 있다.
재버퍼링 기술은, 디코더가 더미 P-프레임을 재생하느라 바쁜 동안에 버퍼가 새로운 재생 시퀀스를 저장할 수 있을 정도로 충분히 길게 마지막 트릭모드 패킷을 보유하려고 시도한다. 재버퍼링 기술은 마지막 트릭모드 패킷의 GOP 크기를 증가시킴으로써 점차적으로 대역폭을 생성할 수 있다. 선택된 GOP 크기가 4인 경우, 이는 마지막 트릭모드 패킷이 GOP 크기 5, 7, 10 등을 가져 완전한 정지가 아니라 느려지는 시각적 인상을 야기한다는 것을 의미한다.
재생 시퀀스의 완전한 재버퍼링을 가능하게 해주기 위해 전체 가용 대역폭이 필요한 대역폭과 일치하거나 그를 초과할 때까지 마지막 트릭모드 패킷이 삽입될 수 있다. I-프레임 선택 메카니즘도 역시 마지막 트릭모드 패킷에 대해 변화할 수 있다. 이것은 요청된 재생 오프셋으로부터 너무 멀어지지 않도록 하기 위해 필요할 수 있다. 각각의 전환 트릭모드 패킷이 요청된 위치로부터 약 1/Ir만큼만 스트림을 이동시키도록 인덱스 증분은 최소 1.0으로 설정될 수 있다. 일반적인 결과로부터 재버퍼링을 가능하게 해주기 위해 대략 3 내지 5 전환 패킷이 필요함을 알 수 있으며, 이는 Ir = 2 I-프레임/초를 갖는 스트림에서 요청된 재생 위치로부터 단지 1.5 내지 2.5s 떨어져 있음을 나타낸다.
다른 방식은 정확한 재생 오프셋으로부터 시작하여 -1.0의 인덱스 증분을 사용하여 뒤로 가면서 트릭모드 패킷의 시퀀스의 가용 대역폭을 계산하는 것일 수 있다. 순 대역폭이 필요 대역폭과 일치하거나 이를 초과할 때, 마지막 패킷은 전환 시퀀스에서 사용되는 첫 번째 패킷이 된다. 이 기술은 전환 시퀀스가 요청된 재생 오프셋에서 끝나도록 보장해줄 수 있다.
동일한 기술에서, 트릭모드가 마이너스 속도로 재생되는 경우(예를 들어, 되감기), 충분한 가용 대역폭이 있을 때까지 I-프레임이 전방 방향으로부터 선택될 수 있다(증분 +1.0). 이어서, 전환 패킷의 시퀀스가 현재 위치로부터 뒤쪽으로 실제의 재생 시퀀스가 시작하는 위치로 이동될 수 있다. 전환 트릭모드 패킷의 시퀀스가 결정되고 버퍼 최적화 기술에 로드되면, 데이터 크기가 0으로 설정되어 있고 트릭모드 패킷 크기가 0으로 설정되어 있으며 bw_balance가 버퍼링을 위해 필요한 데이터 양으로 설정되어 있는 조정 기술에서 "가상 트릭모드 패킷"이 삽입될 수 있다.
버퍼 최적화 기술을 사용하면 트릭모드 패킷의 가용 대역폭이 소모되게 할 수 있으며 전환 패킷을 이동시켜 새로운 재생 시퀀스를 위한 공간을 생성한다. 이 기술은 도 8의 아래쪽 그래프에 나타낸 바와 같이 버퍼 전환을 야기할 수 있으며, 여기서 GOP 크기 6, 7, 8 및 9에서 4개의 전환 패킷이 관찰될 수 있다. 이 방식을 사용하여 트릭모드에서 재생으로 전환하는 것은 프레임 시퀀스의 중단없이 "느려짐"의 인상을 야기할 수 있다.
고속 감기 및 되감기는 상기한 기술을 이용할 수 있다. 이 경우에, 주문형 비디오(VOD) 서버는, 예를 들어 사용자가 FF 버튼을 놓을 때, 셋톱 박스로부터 피드백을 수신할 수 있다. 그렇지만, 서버의 버퍼 관리 알고리즘은 다시 정상 재생으로의 전환 동안에 지연을 가져올 수 있다. 버퍼를 채우기 위해, 들어오는 프레임의 수는 재생되는 프레임의 수를 초과할 수 있고, 따라서 이 알고리즘은 버퍼가 사용자로부터 신호를 수신한 후에 그 버퍼를 채우기 위해 프레임의 전송을 촉진시킬 수 있다. 그 때, 이 알고리즘은 정상 스트림으로 전환할 수 있다.
이 기술은 비교적 작으며 용이하게 발생되고 또 표시되는 시간보다 더 적은 시간에 전송될 수 있는 몇개의 부가적인 B-프레임 및 P-프레임을 발생함으로써 마지막 프레임의 속도를 감소시킬 수 있으며, 따라서 디코더의 버퍼를 채우게 된다. "느려짐"은 초당 더 적은 I-프레임을 전송하는 것을 나타낼 수 있으며, 따라서 일반적으로 30 fps로 일정해야만 하는 실제의 프레임 레이트에 대한 영향이 없다. 모든 I-프레임과 함께 전송되는 B-프레임 및 P-프레임의 수(비교적 작음)를 증가시킴으로써, 평균 비트레이트는 트릭모드 기술에 의해 감소될 수 있다. 과잉 대역폭은 이어서 버퍼를 정상 레벨로 복원하는 데 사용될 수 있다.
어떤 경우에, 일시 정지(Pause) 및 재시작(Resume)은 상기한 기술을 사용하지 않을 수 있는데, 그 이유는 이들 모드가 정상적인 전송 스트림을 이용하는 전환이기 때문이다. 반면에, 점프는 버퍼 조정을 필요로 할 수 있는데, 그 이유는 버퍼 레벨이 전환 시점에서 서로 다를 수 있기 때문이다. 또한, 디버퍼링을 가능하게 해줌으로써 또는 재버퍼링을 가능하게 해주기 위해 더미 B-프레임 및 P-프레임을 삽입함으로써, 트릭모드에 적용되는 동일한 기술들이 점프에 적용될 수 있다. 버퍼 제어가 PCR, DTS 및 PTS 등의 스트림 파라미터의 적절한 조정과 관련되어 있기 때문에, 점프뿐만 아니라 속도 전환도, 이들 제어 변수가 일치하도록 보장함으로써 구현될 필요가 있을 수 있다.
전환 시점 이후의 버퍼 레벨이 이전의 버퍼 레벨보다 낮은 경우, 버퍼 레벨이 적절한 레벨에 도달할 수 있도록 해주기 이해 널의 시퀀스가 삽입될 수 있다. 이 기술은 전환 이후에 원래의 스트림의 차이(DTS - PCR)를 유지한다. 새로운 시퀀스의 디코딩은 이전 시퀀스의 마지막 프레임이 디코딩되고나서 약 한 프레임 후에 시작한다. 프레임의 시퀀스에서의 중단을 방지하기 위해, 전환 이후의 첫 번째 패킷의 PTS는 이전 시퀀스의 마지막 프레임이 표시되고 나서 한 프레임 후에 발생할 수 있다.
점프 기술도 역시 어떤 GOP가 열려 있을 수 있음을 고려할 수 있다. 다시 말해, 새로운 재생 시퀀스에서의 I-프레임 이전에 표시될 첫 번째 B-프레임은 전송되지 않은 이전의 GOP로부터의 프레임에 대한 전방 참조를 사용할 수 있다. 게다가, 점프 기술은 2개의 상부 필드 또는 2개의 하부 필드가 연속하여 존재하는 것을 방지하기 위해 필드 시퀀싱을 정정할 수 있다. 잘못된 필드 시퀀싱은 예를 들어 셋톱 박스에서 화면이 바람직하지 않게 흔들리게 할 수 있다.
점프 기술은 디코더 수신 버퍼에 불완전한 픽처 또는 시퀀스가 존재하는 것을 회피하기 위해 이전의 GOP가 완전히 전송되도록 보장하는 스플라이싱 방법을 포함할 수 있다. 또한, 스플라이싱 방법은 새로운 시퀀스의 DTS - PCR이 현재 스트림의 DTS - PCR(즉, 이전 시퀀스로부터 온 것임)보다 작다고 판정할 수 있으며, 따라서 버퍼 레벨은 감소 되어야 한다. 게다가, 스플라이싱 방법은 I-프레임을 검색할 수 있고 또 더미 B-프레임의 시퀀스를 첨부할 수 있다. 더미 B-프레임의 수는 원래의 시퀀스에서 I-프레임 이전에 발견되는 B-프레임의 수와 일치할 수 있다. 이것은 열린 GOP와 관련하여 기술된 문제를 회피하는 데 도움이 될 수 있다.
스플라이싱 기술은 첫 번째 더미 B-프레임에서 "상부 필드 우선" 및 "첫 번째 필드 반복" 플래그를 적절히 설정함으로써 필드 시퀀싱을 조정할 수 있다. 필드 조정이 필요한 경우, DTS 및 PTS가 그에 따라 조정될 수 있다. 이 경우에, 새로운 재생 시퀀스는 I-프레임으로 구성될 수 있고, 더미 B-프레임은 새로운 재생 시퀀스(PBBPBBP 등)의 나머지와 일치하도록 재스탬핑되어 불연속성을 방지할 수 있다. 스플라이싱 방법은 이하의 방정식을 사용하여, 버퍼 레벨을 조정하기 위해 삽입될 수 있는 널의 양을 계산한다.
Figure 112007014746317-PCT00041
스플라이싱 기술은 이하의 방정식을 사용하여, 스트림 연속성을 보존하기 위해 새로운 시퀀스에 부가되어야 하는 재스탬핑 오프셋을 계산할 수 있다.
Figure 112007014746317-PCT00042
전환 시점 이후의 스트리밍 데이터는 PCR_restamp 양을 PCR에 부가하고 그 양(PCR_restamp/300)을, 오디오를 비롯한 프로그램과 연관된 기본 스트림에서 발견되는 DTS 및 PTS에 부가함으로써 재스탬핑될 수 있다.
도 9는 스플라이싱 기술이 어떻게 동작하는지에 관한 예시를 나타낸 것이다. 새로운 시퀀스에서의 버퍼 레벨이 이전 시퀀스에서의 버퍼 레벨보다 높은 경우, 또하나의 기술이 사용될 수 있다. 예를 들어, P-프레임 삽입 기술에서 또 트릭모드에서 재생으로의 전환에서 기술된 유사한 프로세스가 마지막 픽처를 "프리즈(freeze)"하여 새로운 시퀀스가 버퍼링될 수 있게 하는데 사용될 수 있다.
재버퍼링 기술은 다수의 P-프레임 및 그 다음에 오는 짧은 널 패킷 시퀀스를 삽입하는 것을 포함할 수 있다. 이 새로운 시퀀스가 StreamPCR에서 시작하는 이전 시퀀스의 종료 직후에 전송되는 경우, 첫 번째 프레임은 StreamPCR + (DTSa -w - PCRnew)에 의해 주어지는 순간에 디코딩될 수 있다. 새로운 시퀀스의 첫 번째 프레임은 이전 시퀀스로부터의 마지막 디코드 시간보다 한 프레임 이후인 StreamDTS에 의해 주어지는 순간에 디코딩될 것으로 예상된다. 방정식으로 표현하면, 이것은 StreamPCR + (DTSnew - PCRnew) > StreamDTS 또는 (DTSnew - PCRnew) > (StreamDTS - StreamPCR)인 경우, 디코더가 디코딩을 중단하는 구간이 있다(즉, 버퍼 언더플로우).
필드 예측된 움직임이 없는 P-프레임 및 B-프레임 또는 더미 프레임이 픽처 구조에서 "프레임"으로서 인코딩될 수 있고 매크로블록이 예측 유형에서 "필드"로서 인코딩될 수 있다는 것을 이해될 것이다. 이것은 P-프레임 매크로블록이 움직임 벡터 = (0,0)를 갖는 "상부 필드"를 순방향(forward) 참조하는 "상부 필드", 및 움직임 벡터 = (0,0)를 갖는 "상부 필드"를 순방향 참조하는 "하부 필드"로 인코딩되는 경우 달성될 수 있다. B-프레임 매크로블록은 움직임 벡터 = (0,0)를 갖는 "상부 필드"를 역방향(backward) 참조하는 "상부 필드" 및 움직임 벡터 = (0,0)를 갖는 "상부 필드"를 역방향 참조하는 "하부 필드"로 인코딩될 수 있다.
도 10은 데이터 스트림을 전달하는 시스템(1000)을 나타낸 것이다. 도 10에 도시한 바와 같이, 셋톱 박스(1002)는 데이터 서버(1003)와, 그리고 대역폭 조정 모듈(1004)과 통신하고 있다. 대역폭 조정 모듈(1004)은, 그것의 지정된 타임슬롯이 데이터 스트림을 처리하기에 충분히 크지 않을 때, 데이터 스트림(예를 들어, 트릭모드 패킷)의 일부분을 다른 타임슬롯으로 이동시킬 수 있다. 예시적인 트릭모드 패킷은 초당 약 10 프레임의 레이트로 전달될 수 있는 일련의 I-프레임을 포함할 수 있다. 또한, 대역폭 조정 모듈(1004)은 더미 데이터(예를 들어, B-프레임 및 P-프레임)를 트릭모드 패킷에 삽입시킬 수 있다.
시스템(1000)은 또한 셋톱 박스(1002)와 통신하고 있는 압축/복원 코더(1005)를 포함할 수 있다. 압축/복원 코더(1005)는 MEPG 표준에 따라 동작할 수 있다. 시스템(1000)은 또한 셋톱 박스(1002)로부터의 이미지를 표시하기 위한 디스플레이(1006), 및 트릭모드 재생(예를 들어, 고속 감기, 되감기, 재생, 일시정지, 및 정지)을 개시하기 위해 셋톱 박스와 통신할 수 있는 사용자 인터페이스(1007)를 포함할 수 있다. 디스플레이(1006)는 종래의 텔레비전 세트일 수 있다. 사용자 인터페이스(1007)는 무선 기술을 사용하여 셋톱 박스와 통신할 수 있다. 사용자 인터페이스(1007)는 적외선(IR), 무선 주파(RF), 또는 임의의 다른 적당한 유형의 링크와 같은 무선 링크를 사용하여 통신할 수 있는 종래의 리모콘일 수 있다. 개시된 방법, 장치 및 시스템은 또한 컴퓨터 또는 비디오 데이터를 표시할 수 있는 휴대용이나 핸드핼드 장치, 예를 들어 개인 휴대 단말기(PDA), 랩톱 및 모바일 전화기에서 사용될 수 있다.
도 11은 데이터 스트림을 전달하는 방법의 흐름도이다. 1101에서, 제1 데이터 스트림의 제1 타임슬롯이 결정되고, 1102에서 제2 데이터 스트림의 제2 타임슬롯이 결정된다. 1103에서, 제2 데이터 스트림이 제2 타임슬롯보다 큰지 여부가 판정된다. 제2 데이터 스트림이 제2 타임슬롯보다 크지 않은 경우, 1104에서 제2 데이터 스트림은 제2 타임슬롯으로 전송된다. 반면에 제2 데이터 스트림이 제2 타임슬롯보다 큰 경우, 1105에서 제2 데이터 스트림의 일부분이 제1 타임슬롯으로 이동된다. 1106에서, 제2 데이터 스트림이 전송된다.
게다가, 상기한 방법은 또한 데이터 저장량을 이동된 일부분의 함수로서 제어할 수 있고 또 제2 데이터 스트림의 크기 및 제2 타임슬롯의 크기를 모니터할 수 있다. 이 방법은 MPEG 표준에 따라 데이터 스트림을 압축 및 복원할 수 있으며, 제1 타임슬롯에서의 미사용 대역폭을 제2 타임슬롯으로 재분배한다. 상기한 방법은 데이터 스트림을 전달하기 위한 최대 레이트를 결정하기 위해 데이터 스트림을 모니터할 수 있다.
도 12는 데이터 저장 또는 버퍼 레벨을 제어하는 방법의 흐름도이다. 1201에서, 데이터 프레임(예를 들어, B-프레임 또는 P-프레임 더미 프레임)이 I-프레임을 포함하는 데이터 스트림에 부가된다. 1202에서, 데이터 스트림의 전송 레이트가 변경된다. 1203에서, 제1 모드에서 제2 모드로 전환하라는 커맨드가 수신되고, 1204에서 제1 모드에서 제2 모드로의 전송이 행해진다. 제1 및 제2 모드는 트릭모드 재생 모드 및/또는 정상 재생 모드일 수 있다.
본 발명의 진정한 범위는 본 명세서에 개시된 예시적인 실시예들에 한정되지 않는다. 예를 들어, 효율적인 트릭모드 재생을 생성하는 여러가지 기술들의 상기한 설명은 개별적으로 또는 서로 조합하여 사용될 수 있다. 또한, 개시된 실시예들이 광범위한 픽처 크기(예를 들어, HDTV) 및 프레임 레이트에 걸쳐 동작한다는 것이 이해될 것이다. 고안된 기술들이 시각적 아티팩트, 블랙 스크린, 언더플로우, 버퍼 오버플로우와 일반적으로 연관되어 있는 매크로-블록킹 또는 버퍼 관리 없이 실행되는 전환에서 통상적으로 존재하는 불연속성을 발생하지 않고 상이한 재생 속도들과 정상 재생 속도 사이의 원활한 전환을 가능하게 해준다는 것이 이해될 것이다. 또한, 개시된 기술의 일부로서, 다른 더미 B-프레임 및 P-프레임 인코딩이 사용될 수 있다. 예를 들어, 일부 실시예에서는, 상기한 바와 같이 "움직임이 없는" 프레임으로서 프레임 예측된 B-프레임 및 P-프레임을 사용하지 않고, 다른 인코딩을 사용하는 것이 본 발명의 범위 내에 속한다. 이것은 예를 들어 인터레이스 픽처와 같은 일정 유형의 포맷에 대해 제공될 수 있다.
게다가, 당업자라면 잘 알고 있는 바와 같이, 본 명세서에 개시된 본 발명의 측면들 중 다수가 스트리밍 미디어 또는 주문형 비디오의 목적으로 이용되지 않는, 소프트웨어 또는 하드웨어 솔루션으로서 컴퓨터 시스템에서 적용될 수 있다. 마찬가지로, 본 실시예들은 VOD 개념을 이용하는 시스템, 또는 특정 유형의 컴퓨터, 프로세서, 스위치, 저장 장치, 메모리, 알고리즘 등을 이용하는 시스템에 한정되지 않는다. 디지털 프로세싱, 네트워킹 및 저장 기능의 비용이 급격하게 떨어지는 것을 고려할 때, 본 발명의 시스템의 동작을 변경하지 않고 예를 들어 특정의 기능에 대한 프로세싱 및 저장을 본 명세서에 기술된 기능 요소 중 하나로부터 다른 기능 요소로 이전하는 것이 가능하다. 많은 경우에, 본 명세서에 기술된 구현 장소(즉, 기능 요소)는 단지 설계자의 선호일 뿐이며 어려운 요건이 아니다. 따라서, 이들이 명백하게 그렇게 제한될 수 있는 것을 제외하고는, 보호 범위가 상기한 특정 실시예로 한정되는 것으로 보아서는 안 된다.

Claims (32)

  1. 데이터 스트림을 전달하는 방법으로서,
    제1 데이터 스트림의 제1 타임슬롯을 결정하는 단계;
    제2 데이터 스트림의 제2 타임슬롯을 결정하는 단계; 및
    상기 제2 데이터 스트림이 상기 제2 타임슬롯보다 클 때, 상기 제2 데이터 스트림의 일부분을 상기 제1 타임슬롯으로 이동시키는 단계
    를 포함하는 방법.
  2. 제1항에 있어서,
    데이터 저장량을 상기 이동된 일부분의 함수로서 제어하는 단계를 더 포함하는 방법.
  3. 제1항에 있어서,
    상기 제2 데이터 스트림의 크기 및 상기 제2 타임슬롯의 크기를 모니터하는 단계를 더 포함하는 방법.
  4. 제1항에 있어서,
    MPEG(Motion Picture Experts Group) 표준에 따라 상기 데이터 스트림을 압축 및 복원(compressing and decompressing)하는 단계를 더 포함하는 방법.
  5. 제1항에 있어서,
    상기 제1 및 제2 데이터 스트림은 트릭모드(trickmode) 스트림들인 방법.
  6. 제1항에 있어서,
    상기 데이터 패킷은 트릭모드 패킷인 방법.
  7. 제1항에 있어서,
    상기 제1 타임슬롯에서의 미사용 대역폭을 상기 제2 타임슬롯으로 재분배하는 단계를 더 포함하는 방법.
  8. 제1항에 있어서,
    상기 방법은 컴퓨터 실행가능한 명령어들을 갖는 컴퓨터 판독가능한 매체에 의해 수행되는 방법.
  9. 제1항에 있어서,
    고정-길이 타임슬롯을 제공하는 단계를 더 포함하는 방법.
  10. 제1항에 있어서,
    상기 데이터 스트림을 전달하기 위한 최대 레이트를 결정하기 위해 상기 데 이터 스트림을 모니터하는 단계를 더 포함하는 방법.
  11. 데이터 스트림을 전달하는 시스템으로서,
    셋톱 박스;
    상기 셋톱 박스와 통신하는 데이터 서버; 및
    상기 셋톱 박스 및 상기 데이터 서버와 통신하는 대역폭 조정 모듈
    을 포함하며,
    상기 대역폭 조정 모듈은, 제2 데이터 스트림이 제2 타임슬롯보다 클 때, 제2 데이터 스트림의 일부분을 제1 타임슬롯으로 이동시킬 수 있는 시스템.
  12. 제11항에 있어서,
    상기 제2 데이터 스트림은 트릭모드 패킷인 시스템.
  13. 제12항에 있어서,
    상기 트릭모드 패킷은 I-프레임을 포함하는 시스템.
  14. 제13항에 있어서,
    상기 I-프레임은 초당 10 프레임의 레이트로 전달되는 시스템.
  15. 제12항에 있어서,
    상기 대역폭 조정 모듈은 더미 데이터를 상기 트릭모드 패킷에 삽입시키는 시스템.
  16. 제15항에 있어서,
    상기 더미 데이터는 B-프레임 및 P-프레임을 포함하는 시스템.
  17. 제11항에 있어서,
    압축/복원 디코더를 더 포함하는 시스템.
  18. 제17항에 있어서,
    상기 압축/복원 디코더는 MPEG 표준에 따라 동작하는 시스템.
  19. 제11항에 있어서,
    트릭모드 재생을 개시하기 위해 상기 셋톱 박스와 통신할 수 있는 사용자 인터페이스를 더 포함하는 시스템.
  20. 제19항에 있어서,
    상기 사용자 인터페이스는 무선인 시스템.
  21. 제19항에 있어서,
    상기 트릭모드 재생은 고속감기, 되감기, 재생, 일시정지 및 정지 중 적어도 하나를 포함하는 시스템.
  22. 제11항에 있어서,
    상기 데이터 서버는 비디오 스트림을 제공하는 시스템.
  23. 제11항에 있어서,
    상기 셋톱 박스와 통신하는 디스플레이 장치를 더 포함하는 시스템.
  24. 데이터 저장 레벨을 제어하는 방법으로서,
    데이터 스트림에 데이터 프레임을 부가하는 단계;
    상기 데이터 스트림의 전송 레이트를 변경하는 단계; 및
    제1 모드에서 제2 모드로 전환하는 단계
    를 포함하는 방법.
  25. 제24항에 있어서,
    상기 제1 모드에서 상기 제2 모드로 전환하라는 커맨드를 수신하는 단계를 더 포함하는 방법.
  26. 제24항에 있어서,
    MPEG 표준에 따라 상기 데이터 스트림을 압축 및 복원하는 단계를 더 포함하는 방법.
  27. 제24항에 있어서,
    상기 데이터 프레임은 더미 프레임인 방법.
  28. 제27항에 있어서,
    더미 프레임은 B-프레임 및 P-프레임 중 적어도 하나인 방법.
  29. 제27항에 있어서,
    상기 데이터 스트림은 I-프레임을 포함하는 방법.
  30. 제24항에 있어서,
    상기 데이터 스트림은 비디오 스트림인 방법.
  31. 제25항에 있어서,
    상기 모드는 트릭모드 재생 및 정상 재생 모드 중 적어도 하나인 방법.
  32. 제25항에 있어서,
    거의 유사한 프레임들을 연속적으로 표시하는 단계를 더 포함하는 방법.
KR1020077003898A 2004-07-23 2005-07-22 데이터 스트림을 전달하는 방법 및 시스템과 데이터 저장 레벨을 제어하는 방법 KR100868820B1 (ko)

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
KR20070064316A true KR20070064316A (ko) 2007-06-20
KR100868820B1 KR100868820B1 (ko) 2008-11-14

Family

ID=35057113

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077003898A KR100868820B1 (ko) 2004-07-23 2005-07-22 데이터 스트림을 전달하는 방법 및 시스템과 데이터 저장 레벨을 제어하는 방법

Country Status (6)

Country Link
US (1) US20060146780A1 (ko)
EP (1) EP1772016A2 (ko)
JP (2) JP4729570B2 (ko)
KR (1) KR100868820B1 (ko)
CN (1) CN101010959B (ko)
WO (1) WO2006012496A2 (ko)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7899924B2 (en) * 2002-04-19 2011-03-01 Oesterreicher Richard T Flexible streaming hardware
US20040006636A1 (en) * 2002-04-19 2004-01-08 Oesterreicher Richard T. Optimized digital media delivery engine
US20040006635A1 (en) * 2002-04-19 2004-01-08 Oesterreicher Richard T. Hybrid streaming platform
US9456243B1 (en) 2003-06-06 2016-09-27 Arris Enterprises, Inc. Methods and apparatus for processing time-based content
JP4409401B2 (ja) * 2004-10-08 2010-02-03 株式会社日立製作所 パケット転送装置及びストレージシステム
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 (ja) * 2006-09-19 2011-11-30 株式会社ソニー・コンピュータエンタテインメント 動画再生方法および装置
KR20080035891A (ko) * 2006-10-20 2008-04-24 포스데이타 주식회사 움직임의 스마트 서치를 지원하는 영상 재생 장치 및 방법
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
WO2009065144A1 (en) 2007-11-16 2009-05-22 Divx, Inc. 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 (ja) * 2008-07-08 2013-10-23 キヤノン株式会社 通信方法
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
JP5257319B2 (ja) 2009-10-09 2013-08-07 株式会社Ｊｖｃケンウッド 画像符号化装置及び画像符号化方法
KR101613241B1 (ko) * 2009-10-16 2016-04-29 삼성전자 주식회사 디스플레이장치 및 영상재생방법
US20110271001A1 (en) * 2010-04-30 2011-11-03 Herve Brelay Methods & apparatuses for a projected pvr experience
US20110268427A1 (en) * 2010-04-30 2011-11-03 Brelay Herve Methods and 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 (zh) * 2011-03-04 2014-04-30 华为技术有限公司 一种度量用户体验质量QoE的方法及装置
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

Family Cites Families (79)

* Cited by examiner, † Cited by third party
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
FR2582175A1 (fr) * 1985-05-20 1986-11-21 Alcatel Espace Procede et dispositif de telecommunications par satellite en acces multiple a repartition dans le temps
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
DE69426894T2 (de) * 1993-09-16 2001-07-26 Toshiba Kawasaki Kk Digitales Videosignal
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
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 (ko) * 1994-11-11 1999-06-15 니시무로 타이죠 패킷데이타의 기록장치 및 재생장치
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
US6119154A (en) * 1995-07-14 2000-09-12 Oracle Corporation Method and apparatus for non-sequential access to an in-progress video feed
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
US5751951A (en) * 1995-10-30 1998-05-12 Mitsubishi Electric Information Technology Center America, Inc. Network interface
US5729292A (en) * 1995-12-21 1998-03-17 Thomson Multimedia, S.A. Optimizing performance in a packet slot priority packet transport system
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
US6253375B1 (en) * 1997-01-13 2001-06-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
US6166730A (en) * 1997-12-03 2000-12-26 Diva Systems Corporation System for interactively distributing information services
JP2000509932A (ja) * 1997-02-03 2000-08-02 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 記録担体上にトリックプレイ信号を記録するための方向識別子
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
US6314572B1 (en) * 1998-05-29 2001-11-06 Diva Systems Corporation Method and apparatus for providing subscription-on-demand services, dependent services and contingent services for an interactive information distribution system
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
US7035278B2 (en) * 1998-07-31 2006-04-25 Sedna Patent Services, Llc Method and apparatus for forming and utilizing a slotted MPEG transport stream
US6148414A (en) * 1998-09-24 2000-11-14 Seek Systems, Inc. Methods and systems for implementing shared disk array management functions
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
JP2000175189A (ja) * 1998-12-07 2000-06-23 Univ Tokyo 動画符号化方法およびそれに用いる動画符号化装置
KR100618961B1 (ko) * 1998-12-16 2006-09-01 삼성전자주식회사 패킷 데이터의 고속 탐색을 위한 정보 생성 방법과 이 정보를 저장하는 기록 매체, 이를 이용하는 기록 및/또는 재생 장치
US6785338B1 (en) * 1999-01-19 2004-08-31 Sarnoff Corporation Constraining video production based on compression-related information
US6289376B1 (en) * 1999-03-31 2001-09-11 Diva Systems Corp. Tightly-coupled disk-to-CPU storage server
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
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
US6233607B1 (en) * 1999-04-01 2001-05-15 Diva Systems Corp. Modular storage server architecture with dynamic data management
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
US6965960B2 (en) * 2000-03-01 2005-11-15 Realtek Semiconductor Corporation xDSL symbol processor and method of operating same
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
AU2001271600A1 (en) * 2000-11-10 2002-05-21 Prediwave Corp. Decreased idle time and constant bandwidth data-on-demand broadcast delivery matrices
US7031343B1 (en) * 2000-11-17 2006-04-18 Alloptic, Inc. Point-to-multipoint passive optical network that utilizes variable-length packets
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
US20020180891A1 (en) * 2001-04-11 2002-12-05 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
US7174086B2 (en) * 2001-10-23 2007-02-06 Thomson Licensing Trick mode using dummy predictive pictures
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
AU2003263489A1 (en) * 2002-10-10 2004-05-04 Koninklijke Philips Electronics N.V. Itv trick play over digital interface
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

Also Published As

Publication number Publication date
JP2008507922A (ja) 2008-03-13
WO2006012496A3 (en) 2006-06-15
KR100868820B1 (ko) 2008-11-14
CN101010959A (zh) 2007-08-01
CN101010959B (zh) 2012-01-25
WO2006012496A2 (en) 2006-02-02
JP4729570B2 (ja) 2011-07-20
JP2011050117A (ja) 2011-03-10
EP1772016A2 (en) 2007-04-11
US20060146780A1 (en) 2006-07-06

Similar Documents

Publication Publication Date Title
KR100868820B1 (ko) 데이터 스트림을 전달하는 방법 및 시스템과 데이터 저장 레벨을 제어하는 방법
US10623785B2 (en) Streaming manifest quality control
US8837586B2 (en) Bandwidth-friendly representation switching in adaptive streaming
US7023924B1 (en) Method of pausing an MPEG coded video stream
KR100711635B1 (ko) 화상 부호화 방법
EP1002424B1 (en) Processing coded video
US6327421B1 (en) Multiple speed fast forward/rewind compressed video delivery system
US6937770B1 (en) Adaptive bit rate control for rate reduction of MPEG coded video
RU2488968C2 (ru) Кодирующее устройство и способ генерирования потока данных
US7197072B1 (en) Systems and methods for resetting rate control state variables upon the detection of a scene change within a group of pictures
US8355452B2 (en) Selective frame dropping for initial buffer delay reduction
US7406124B1 (en) Systems and methods for allocating bits to macroblocks within a picture depending on the motion activity of macroblocks as calculated by an L1 norm of the residual signals of the macroblocks
US8331442B2 (en) Optimal rate allocation for a group of channels
US6269120B1 (en) Method of precise buffer management for MPEG video splicing
US8254449B2 (en) Video traffic bandwidth prediction
US20060023729A1 (en) Apparatus and method for adaptively controlling buffering amount according to content attribute in receiving audio-video data
JP2006025401A (ja) デジタルメディアストリームの逆提示
KR20150126860A (ko) 고속 전환을 위한 코덱 기법
US7388912B1 (en) Systems and methods for adjusting targeted bit allocation based on an occupancy level of a VBV buffer model
US11871079B2 (en) Client and a method for managing, at the client, a streaming session of a multimedia content
JP4064604B2 (ja) 画像処理方法及び装置

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20121030

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20131030

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20150930

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20161028

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20170929

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20180928

Year of fee payment: 11

FPAY Annual fee payment

Payment date: 20190924

Year of fee payment: 12