DE602004012540T2

DE602004012540T2 - Videocodierer und videocodierungsverfahren

Info

Publication number: DE602004012540T2
Application number: DE602004012540T
Authority: DE
Inventors: Sachin Govind Vancouver DESHPANDE
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2003-03-31
Filing date: 2004-03-26
Publication date: 2009-04-23
Anticipated expiration: 2024-03-27
Also published as: JP2012135009A; JP5536811B2; HK1147374A1; CN1826812A; USRE43062E1; EP2209319A3; ATE390019T1; CN101854553B; PT1611747E; EP1611747A1; JP2006519517A; USRE48953E1; JP5025289B2; PT1791369E; EP1791369B1; ES2300757T3; US7266147B2; EP2209319B1; ATE472228T1; EP1611747A4

Description

ALLGEMEINER STAND DER TECHNIK
Die vorliegende Erfindung betrifft einen hypothetischen Referenzdecodierer.
Ein digitales Videosystem weist einen Sender und einen Empfänger auf, die ein Video zusammenstellen, das Audio, Bilder und Zusatzkomponenten für eine koordinierte Präsentation an einen Anwender umfasst. Das Sendersystem weist Subsysteme auf, um die digitalen Quellendaten (die Elementar- oder Anwendungsdatenströme, die Audio-, Video- und Zusatzdatenkomponente eines Programms darstellen) zu empfangen und zu komprimieren; die Daten aus den mehreren Elementardatenströme in einen einzelnen Transportbitstrom zu multiplexen; und die Daten an den Empfänger zu senden. An dem Empfänger wird der Transportbitstrom in seine einzelnen Elementardatenströme demultiplexiert. Die Elementardatenströme werden decodiert, und die Audio- und Videodatenströme werden als synchronisierte Programmelemente an das Präsentations-Subsystem des Empfängers zur Anzeige als Teile eines koordinierten Programms geliefert.
Bei vielen Videocodierstandards wird ein konformer Bitstrom an den Decodierer von einem hypothetischen Decodierer decodiert, der mit dem Ausgang eines Codierers konzeptionell verbunden ist und aus einem Decodierpuffer, einem Decodierer und einem Sichtanzeigegerät besteht. Dieser virtuelle Decodierer ist als der hypothetische Referenzdecodierer (HRD) in H.263 und der Video Buffering Verifier (VBV) in MPEG-2 bekannt. Der Codierer erzeugt einen Bitstrom, so dass der hypothetische Decodierpuffer keinen Überlauf oder Unterlauf hat.
Demzufolge kann die Datenmenge, die der Empfänger eventuell zwischenspeichern muss, dessen Leistung (eine Speicherüberlaufbedingung) oder Durchsatzfähigkeiten übersteigen. Alternativ kann der Empfänger darin versagen, sämtliche Daten in einer Datenzugriffseinheit rechtzeitig zur Decodierung und synchronisierten Präsentation mit einem vorgegebenen Augenblick in den Audio- oder Videodatenströmen zu empfangen, was zu einem Verlust von Daten und einer unbeständigen Leistung (eine Speicherunterlaufbedingung) führt.
Bei bestehenden hypothetischen Referenzdecodierern wird der Videobitstrom mit einer vorgegebenen konstanten Bitgeschwindigkeit (gewöhnlich die Durchschnittsgeschwindigkeit in Bits/Sekunde des Stromes) empfangen und wird in dem Decodierpuffer gespeichert, bis die Pufferfülle einen gewünschten Pegel erreicht. Ein derartiger gewünschter Pegel wird als die anfängliche Decodierpufferfülle bezeichnet und ist zu der Übertragungs- oder Anlauf-(Puffer-)Verzögerung direkt proportional. An jenem Punkt entfernt der Decodierer sofort die Bits für das erste Videovollbild der Sequenz, decodiert die Bits und zeigt das Vollbild an. Die Bits für die folgenden Vollbilder werden ebenfalls entfernt, decodiert und in nachfolgenden Zeitintervallen sofort angezeigt.
Traditionelle hypothetische Decodierer arbeiten mit einer festen Bitgeschwindigkeit, Pufferlänge und anfänglichen Verzögerung. Jedoch bei vielen heutigen Videoanwendungen (z. B. Videostreaming durch das Internet oder ATM-Netze) variiert die verfügbare Bandbreite gemäß dem Netzwerkpfad (z. B. wie sich der Anwender mit dem Netz verbindet: mittels Modem, ISDN, DLS, Kabel usw.) und schwankt auch in der Zeit gemäß Netzbedingungen (z. B. Überlastung, die Zahl der angeschlossenen Anwender usw.). Des Weiteren werden die Videobitströme an eine Vielzahl von Geräten mit verschiedenen Pufferfähigkeiten (z. B. Handapparate, PDAs, PCs, Aufsatzgeräte, DVD-ähnliche Player usw.) geliefert und werden für Szenarien mit verschiedenen Verzögerungsanforderungen (z. B. Streaming mit niedriger Verzögerung, progressiver Download usw.) erzeugt. Demzufolge erfordern diese Anwendungen einen flexibleren hypothetischen Referenzdecodierer, der einen Bitstrom bei verschiedenen Spitzenbitgeschwindigkeiten und mit verschiedenen Pufferlängen und Anlaufverzögerungen decodieren kann.
Jordi Ribas-Corbera und Philip A. Chou schlugen in einer wissenschaftlichen Veröffentlichung vom 4. September 2001 mit dem Titel "A Generalized Hypothetical Reference Decoder For H.26L" ("Generalisierter hypothetischer Referenzdecodierer für H.26L"] einen modifizierten hypothetischen Referenzdecodierer vor. Der Decodierer arbeitet gemäß N- Sätzen von Geschwindigkeits- und Pufferparametern für einen vorgegebenen Bitstrom. Jeder Satz kennzeichnet was als Leaky-Bucket-Modell bekannt ist und enthält drei Werte (R, B, F), wobei R die Übertragungsgeschwindigkeit, B die Pufferlänge und F die anfängliche Decodierpufferfülle ist (F/R ist die Anlaufverzögerung oder anfängliche Pufferverzögerung). Ein Codierer kann einen Videobitstrom erzeugen, der durch einige gewünschte N-Leaky-Buckets eingegrenzt ist, oder kann einfach die N-Sätze von Parametern berechnen, nachdem der Bitstrom erzeugt worden ist. Der hypothetische Referenzdecodierer kann zwischen den Leaky-Buckets-Parametern interpolieren und kann bei jeder gewünschten Spitzenbitgeschwindigkeit, Pufferlänge oder Verzögerung arbeiten. Zum Beispiel kann der Referenzdecodierer bei einer vorgegebenen Spitzenübertragungsgeschwindigkeit R' die kleinste Pufferlänge und Verzögerung (gemäß den verfügbaren Leaky-Bucket-Daten) auswählen, die in der Lage sind, den Bitstrom zu decodieren ohne unter einem Pufferunterlauf oder -überlauf zu leiden. Umgekehrt kann der hypothetische Decodierer bei einer vorgegebenen Pufferlänge B' die minimal erforderliche Spitzenübertragungsgeschwindigkeit auswählen und bei dieser arbeiten.
Es gibt Vorteile einen derartigen generalisierten hypothetischen Referenzdecodierer zu verwenden. Zum Beispiel kann ein Inhaltanbieter einen Bitstrom einmalig erzeugen, und ein Server kann diesen an mehrere Geräte unterschiedlicher Fähigkeiten unter Verwendung einer Vielzahl von Kanälen unterschiedlicher Spitzenübertragungsgeschwindigkeiten liefern. Oder ein Server und ein Terminal können den besten Leaky Bucket für die vorgegebenen Netzbedingungen aushandeln – zum Beispiel jene, welche die niedrigste Anlauf-(Puffer-)Verzögerung erzeugen, oder jene, welche die niedrigste Spitzenübertragungsgeschwindigkeit für die vorgegebene Pufferlänge des Gerätes erfordert.
Wie in Dokument VCEG-58, Abschnitt 2.1–2.4 beschrieben, ist ein Leaky Bucket ein Modell für den Zustand (oder Fülle) eines Codier- oder Decodierpuffers als eine Funktion der Zeit. Die Fülle des Codier- und des Decodierpuffers sind Komplemente von einander. Ein Leaky-Bucket-Modell ist durch drei Parameter (R, B, F) gekennzeichnet, wobei:
R die Spitzenbitgeschwindigkeit (in Bits pro Sekunde) ist, bei der Bits den Decodierpuffer betreten. Bei konstanten Bitgeschwindigkeitsszenarien ist R oft die Kanalbitgeschwindigkeit und die durchschnittliche Bitgeschwindigkeit des Videoclips.
B die Größe des Bucket oder die Länge des Decodierpuffers (in Bits) ist, welche die Videobitgeschwindigkeitsschwankungen glättet. Diese Pufferlänge kann nicht größer sein als der physische Puffer des Decodiergerätes.
F die anfängliche Decodierpufferfülle (ebenfalls in Bits) ist, bevor der Decodierer damit beginnt, Bits aus dem Puffer zu entfernen. F und R bestimmen die anfängliche Verzögerung oder Anlaufverzögerung D, wobei D = F/R Sekunden.
Bei einem Leaky-Bucket-Modell betreten die Bits den Puffer mit einer Geschwindigkeit R, bis der Pegel der Fülle F ist (d. h. für D Sekunden), und dann werden b0-Bits für das erste Vollbild sofort entfernt. Die Bits betreten weiter den Puffer mit einer Geschwindigkeit R, und der Decodierer entfernt b1, b2, ..., bn – 1 Bits für die folgenden Vollbilder bei einigen vorgegebenen Zeitaugenblicken, typischerweise (aber nicht notwendigerweise) alle 1/M Sekunden, wobei M die Vollbildgeschwindigkeit des Videos ist. 1 stellt die Decodierpufferfülle entlang der Zeit eines Bitstromes dar, der in einem Leaky Bucket von Parametern (R, B, F) eingeschränkt ist.
Lassen Sie Bi die Decodierpufferfülle unmittelbar vor dem Entfernen von B₁ Bits bei Zeit t₁ sein. Ein generisches Leaky-Bucket-Modell arbeitet gemäß den folgenden Gleichungen: B0 = F Bi+1 = min (B, Bi – bi + R(ti+1 – ti)), i = 0, 1, 2, ... (1)Typischerweise ist t_i+1 – t_i = 1/M Sekunden, wobei M die Vollbildgeschwindigkeit (normalerweise in Vollbildern/Sekunde) für den Bitstrom ist.
Ein Leaky-Bucket-Modell mit Parametern (R, B, F) enthält einen Bitstrom, falls es keinen Unterlauf des Decodierpuffers gibt. Da die Codier- und Decodierpufferfülle Komplemente von einander sind, entspricht dies keinem Überlauf des Codierpuffers. Jedoch wird dem Codierpuffer (dem Leaky Bucket) erlaubt leer zu werden, oder entsprechend darf der Decodierpuffer voll werden, an welchem Punkt keine weiteren Bits von dem Codierpuffer an den Decodierpuffer gesendet werden. Somit hört der Decodierpuffer auf Bits zu empfangen, wenn er voll ist, weshalb der min Operator in Gleichung (1) aufgenommen ist. Ein voller Decodierpuffer bedeutet einfach, dass der Codierpuffer leer ist.
Die folgenden Beobachtungen können gemacht werden:
Ein vorgegebener Videostrom kann in vielen Leaky Buckets enthalten sein. Ist zum Beispiel ein Videostrom in einem Leaky Bucket mit Parametern (R, B, F) enthalten, ist dieser auch in einem Leaky Bucket mit einem größeren Puffer (R, B', F), B' > B, oder in einem Leaky Bucket mit einer höheren Spitzenübertragungsgeschwindigkeit (R', B, F), R' > R, enthalten.
Das System kann für jede Bitgeschwindigkeit R immer eine Pufferlänge finden, die den (zeitbeschränkten) Videobitstrom enthält. In dem Worst Case (R' geht auf 0) muss die Pufferlänge genauso groß sein wie der Bitstrom selbst. Anders ausgedrückt, ein Videobitstrom kann mit jeder Geschwindigkeit (ungeachtet der durchschnittlichen Bitgeschwindigkeit des Clips) gesendet werden, so lange wie die Pufferlänge groß genug ist.
Angenommen, dass das System F = aB für sämtliche Leaky Buckets festlegt, wobei a ein gewisser gewünschter Bruchteil der anfänglichen Pufferfülle ist. Für jeden Wert der Spitzenbitgeschwindigkeit R kann das System die Mindestpufferlänge B_min finden, die den Bitstrom unter Verwendung von Formel (1) enthält. Die grafische Darstellung der Kurve von R-B-Werten wird in 2 gezeigt.
Per Beobachtung ist die Kurve von (R_min, B_min) Paaren für jeden Bitstrom (wie zum Beispiel der in 2) stückweise linear und konvex. Folglich kann der Decodierer, wenn N-Punkte der Kurve bereitgestellt werden, die Werte linear interpolieren, um zu einigen Punkten (R_interp, B_interp) zu gelangen, die etwas, aber sicher größer sind als (R_min, B_min). Auf diese Weise kann man die Bufferlänge und folglich auch die Verzögerung durch eine Größenordnung in Bezug auf einen einzelnen Leaky Bucket reduzieren, der den Bitstrom mit seiner durchschnittlichen Geschwindigkeit enthält. Alternativ kann man für dieselbe Verzögerung die Spitzenübertragungsgeschwindigkeit um einen Faktor vier reduzieren oder eventuell sogar den Rauschabstand um mehrere dB verbessern.
MPEG Video Buffering Verifier (VBV)
Der MPEG Video Buffering Verifier (VBV) kann in zwei Betriebsarten arbeiten: konstante Bitgeschwindigkeit (CBR) und variable Bitgeschwindigkeit (VBR). MPEG-1 unterstützt nur die CBR-Betriebsart, während MPEG-2 beide Betriebsarten unterstützt.
Der VBV arbeitet in der CBR-Betriebsart, wenn der Bitstrom in einem Leaky-Bucket-Modell von Parametern (R, B, F) enthalten ist, und:
R = R_max = die durchschnittliche Bitgeschwindigkeit des Stroms.
Der Wert B ist in dem Syntaxparameter vbv_Puffer_Länge unter Verwendung einer speziellen Längeneinheit (d. h. 16 × 1024 Biteinheiten) gespeichert.
Der Wert F/R ist in dem Syntaxelement vbv_Verzögerung gespeichert, das mit dem ersten Videovollbild in der Sequenz unter Verwendung einer speziellen Zeiteinheit (d. h. Anzahl von Perioden eines 90 KHz Takts) verbunden ist.
Die Decodierpufferfülle folgt den folgenden Gleichungen: B0 = F Bi+1 = Bi – bi + Rmax/M, i = 0, 1, 2, ... (2)
Der Codierer muss sicherstellen, dass B_i – b_i stets größer als oder gleich Null ist, während B_i stets kleiner als oder gleich B ist. Mit anderen Worten, der Codierer stellt sicher, dass der Decodierpuffer keinen Unterlauf oder Überlauf hat.
Der VBV arbeitet in der VBR-Betriebsart, wenn der Bitstrom in einem Leaky-Bucket-Modell von Parametern (R, B, F) eingeschränkt ist, und:
R = R_max = die Spitzen- oder maximale Geschwindigkeit. R_max ist höher als die durchschnittliche Geschwindigkeit des Bitstroms.
F = B, d. h. der Puffer füllt sich anfangs auf.
Der Wert B ist in dem Syntaxparameter vbv_Puffer_Länge dargestellt, wie in dem CBR-Fall.
Die Decodierpufferfülle folgt den folgenden Gleichungen: B0 = B Bi+1 = min (B, Bi – bi + Rmax/M), i = 0, 1, 2 ... (3)
Der Codierer stellt sicher, dass B_i – b_i stets größer als oder gleich Null ist. Das heißt, der Codierer muss sicherstellen, dass der Decodierpuffer keinen Unterlauf hat. Jedoch muss der Codierer in diesem VBR-Fall nicht sicherstellen, dass der Decodierpuffer nicht überläuft. Ist der Decodierpuffer voll, dann wird angenommen, dass der Codierpuffer leer ist und daher werden keine weiteren Bits von dem Codierpuffer an den Decodierpuffer übertragen.
Die VBR-Betriebsart ist für Geräte nützlich, die Daten bis zu der Spitzengeschwindigkeit R_max lesen können. Zum Beispiel weist eine DVD VBR-Clips auf, wobei R_max ungefähr 10 MBits/Sekunde beträgt, was der maximalen Lesegeschwindigkeit des Plattenlaufwerks entspricht, auch wenn die durchschnittliche Geschwindigkeit des DVD-Videostroms nur ungefähr 4 MBits/Sekunde beträgt.
Auf 3A und 3B Bezug nehmend, werden grafische Darstellungen einer Decodierpufferfülle für einige Bitströme, die in der CBR- bzw. VBR-Betriebsart arbeiten, gezeigt.
Allgemein gesprochen kann die CBR-Betriebsart als ein Sonderfall von VBR angesehen werden, wobei R_max die durchschnittliche Geschwindigkeit des Clips ist.
H.263's hypothetischer Referenzdecodierer (HRD)
Das hypothetische Referenzmodell für H.263 ähnelt der CBR-Betriebsart des zuvor erörterten VBV von MPEG, mit Ausnahme des folgenden:
Der Decodierer kontrolliert die Pufferfülle in gewissen Zeitintervallen und decodiert ein Vollbild, sobald sämtliche Bits für das Vollbild verfügbar sind. Dieser Ansatz führt zu einigen Vorteilen: (a) die Verzögerung wird minimiert, da F gewöhnlich nur etwas größer ist als die Anzahl an Bits für das erste Vollbild, und (b), sofern Frame Skipping üblich ist, wartet der Decodierer einfach bis zum nächsten verfügbaren Vollbild. Letzteres ist auch in der Low-Delay-Betriebsart des VBV von MPEG aktiviert.
Die Prüfung auf Pufferüberlauf erfolgt, nachdem die Bits für ein Vollbild aus dem Puffer entfernt worden sind. Dies lockert die Einschränkung zum Senden von großen I-Vollbildern von Zeit zu Zeit, aber es gibt einen Höchstwert für das größte Vollbild.
H.263's HRD kann im Wesentlichen einem Typ von Leaky-Bucket-Modell mit niedriger Verzögerung zugeordnet werden.
Einschränkungen früherer hypothetischer Referenzdecodierer
Früher bestehende hypothetische Referenzdecodierer arbeiten nur an einem Punkt (R, B) der Kurve in 2. Demzufolge haben diese Decodierer die folgenden Nachteile:
Ist die in dem Kanal R vorhandene Bitgeschwindigkeit niedriger als R (zum Beispiel ist dies für Internet-Streaming und progressivem Download üblich, oder wenn ein MPEG-VBR-Clip mit einer Geschwindigkeit übertragen werden muss, die niedriger ist als die Spitzengeschwindigkeit), könnte der hypothetische Decodierer streng genommen den Bitstrom nicht decodieren.
Ist die verfügbare Bandbreite R' größer als R (zum Beispiel ist dies auch für Internet-Streaming sowie für lokales Playback üblich), könnten die früheren hypothetischen Decodierer in der VBR-Betriebsart arbeiten und den Bitstrom decodieren. Wären jedoch mehr Informationen über die Geschwindigkeits-Puffer-Kurve verfügbar, könnten die Pufferlänge und die damit verbundene Anlaufverzögerung, die zur Decodierung des Bitstroms erforderlich ist, beträchtlich reduziert werden.
Ist die physische Pufferlänge in einem Decodiergerät kleiner als B, kann das Gerät jenen Bitstrom nicht decodieren.
Ist die Pufferlänge größer als B, kann das Gerät den Bitstrom decodieren, aber die Anlaufverzögerung ist dieselbe.
Allgemeiner kann ein Bitstrom, der gemäß einem Leaky Bucket (R, B, F) erzeugt wurde, gewöhnlich nicht durch verschiedene Netzwerke mit einer Bitgeschwindigkeit kleiner als R und an eine Vielzahl von Geräten mit Pufferlängen kleiner als B verteilt werden. Auch die Anlaufverzögerung wird nicht minimiert.
Generalisierter hypothetischer Referenzdecodierer (GHRD)
Ein generalisierter hypothetischer Referenzdecodierer (GHRD) kann angesichts der Informationen von N-Leaky-Bucket-Modellen arbeiten, (R1, B1, F1), (R2, B2, F2), ..., (RN, BN, FN) (4)wobei jede davon den Bitstrom enthält. Ohne Verlust von Generalität lassen Sie uns annehmen, dass diese Leaky Buckets von der kleinsten zu der größten Bitgeschwindigkeit geordnet sind, d. h. Ri < R_i+1. Lassen Sie uns ferner annehmen, dass der Codierer diese Leaky-Bucket-Modelle und somit B_i < B_i+1 richtig berechnet.
Der gewünschte Wert N kann von dem Codierer ausgewählt werden. Ist N = 1, entspricht der GHRD im Wesentlichen dem VPP von MPEG. Der Codierer kann wählen: (a) die Leaky-Bucket-Werte vorzuwählen und den Bitstrom mit einer Geschwindigkeitssteuerung zu codieren, die sicherstellt, dass sämtliche Leaky-Bucket-Einschränkungen erfüllt werden, (b) den Bitstrom zu codieren und dann Formel (1) zu verwenden, um einen Satz von Leaky Buckets zu berechnen, die den Bitstrom bei N-verschiedenen Werten von R enthalten, oder (c) beides zu tun. Der erste Ansatz (a) kann für eine Live- oder on-Demand-Übertragung verwendet werden, während (b) und (c) nur für on-Demand zutreffen.
Die Anzahl an Leaky Buckets N und die Leaky-Bucket-Parameter (4) werden in den Bitstrom eingefügt. Auf diese Weise kann der Decodierer bestimmen, welchen Leaky Bucket er zu verwenden wünscht, indem er die Spitzenbitgeschwindigkeit, die ihm zur Verfügung steht, und/oder seine physische Pufferlänge kennt. Die Leaky-Bucket-Modelle in (4) sowie sämtliche linear interpolierten oder extrapolierten Modelle stehen zur Verwendung zur Verfügung. 4 stellt einen Satz von N Leaky-Bucket-Modellen und deren interpolierte oder extrapolierte (R, B) Werte dar.
Die interpolierte Pufferlänge B zwischen den Punkten k und k + 1 folgt der geraden Linie: B = {(Rk+1 – R)/(Rk+1 – Rk)}Bk + {(R – Rk)/(Rk+1 – Rk)}Bk+1 Rk < R < Rk+1
Ebenso kann die anfängliche Decodierpufferfülle F linear interpoliert werden: F = {(Rk+1 – R)/(Rk+1 – Rk)}Fk + {(R – Rk)/(Rk+1 – Rk)}Fk+1 Rk < R < Rk+1
Der resultierende Leaky Bucket mit Parametern (R, B, F) enthält den Bitstrom, da die Mindestpufferlänge B_min sowohl in R und F konvex ist, das heißt, die Mindestpufferlänge B_min, die jeder konvexen Kombination (R, F) = a(R_k, F_k) + (1 – a)(R_k+1, F_k+1), 0 < a < 1, entspricht, ist kleiner als oder gleich B = aB_k + (1 – a)B_k+1.
Es wird beobachtet, dass wenn R größer ist als R_N, der Leaky Bucket (R, B_N, F_N) ebenfalls den Bitstrom enthält, und somit sind B_N und F_N die Pufferlänge und die empfohlene anfängliche Decodierpufferfülle, wenn R > = R_N. Ist R kleiner als R₁, kann die obere Grenze B = B₁ + (R₁ – R)T bewirkt werden (und sobald F = B eingestellt werden kann), wobei T die Zeitlänge des Stroms in Sekunden ist. Diese (R-, B-) Werte außerhalb der Reichweite der N-Punkte werden ebenfalls in 4 gezeigt.
Der Arbeitsentwurf Nummer 2, Revision 0 (WD-2), des Joint Video Team von ISO/IEC MPEG und ITU-T VCEG nahm viele der Konzepte des von Jordi Ribas-Cobera et al. von Microsoft Corporation vorgeschlagenen hypothetischen Decodierers auf, der durch Bezugnahme hier aufgenommen wird. Das WD-2 Dokument ähnelt dem von Jordi Ribas-Cobera et al. von Microsoft Corporation vorgeschlagenem Decodierer, obwohl die Syntax etwas modifiziert ist. Des Weiteren beschreibt WD-2 einen Beispielalgorithmus zur Berechnung von B und F bei einer vorgegebenen Geschwindigkeit R.
Die U.S. Patentanmeldung mit der Veröffentlichungsnummer US 2003/0053416A beschreibt die Verwendung von zwei Leaky-Bucket-Modellen. Der erste eingestellte Leaky-Bucket-Parameter würde eine Übertragung des Videos über einen Kanal mit konstanter Bitgeschwindigkeit mit einer Verzögerung von ungefähr 22,5 Sekunden zulassen. Der zweite Satz von Leaky-Bucket-Parametern würde eine Übertragung des Videos über ein geteiltes Netzwerk mit einer Spitzengeschwindigkeit von 2.500 kbps zulassen oder würde ein lokales Playback aus einem 2 × CD mit einer Verzögerung von ungefähr 0,9 Sekunden zulassen.
Eine wissenschaftliche Veröffentlichung von Ribas-Corbera, J. et al, "A flexible decoder buffer model for JVT video coding" [Flexibles Decodierpuffermodell für JVT-Videocodierung), Internationale Bildverarbeitungskonferenz ICIP 2002, Band 2, 22.–25. Sept. 2002, S. 11–493 bis 11–496, XP002375851, offenbart einen hypothetischen Referenzdecodierer für JVT.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Videocodierer bereitgestellt, der wie folgt aufweist:

(a) ein Mittel zum Definieren eines ersten Satzes von Mehrfachwerten, die für eine Übertragungsgeschwindigkeit eines ersten Abschnitts eines Videosegments charakteristisch sind;
(b) ein Mittel zum Definieren eines zweiten Satzes von Mehrfachwerten, die für eine Pufferlänge des ersten Abschnitts des Videosegments charakteristisch sind;
(c) ein Mittel zum Definieren eines dritten Satzes von Mehrfachwerten, die für eine anfängliche Pufferfülle des ersten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis der erste Abschnitt des Videosegments präsentiert wird;
(d) ein Mittel zum Auswählen eines Wertes des Satzes von ersten Werten, eines Wertes des Satzes von zweiten Werten und eines Wertes des Satzes von dritten Werten, so dass der erste Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist;
(e) ein Mittel zum Definieren eines vierten Satzes von Mehrfachwerten, die für eine anfängliche Pufferfülle eines zweiten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis ein zweiter Abschnitt des Videosegments präsentiert wird; und
(f) ein Mittel zum Auswählen eines Wertes des Satzes von vierten Werten, so dass der zweite Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist.

Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zur Videocodierung bereitgestellt, das wie folgt aufweist:

(a) das Definieren eines ersten Satzes von Mehrfachwerten, die für eine Übertragungsgeschwindigkeit eines ersten Abschnitts eines Videosegments charakteristisch sind;
(b) das Definieren eines zweiten Satzes von Mehrfachwerten, die für eine Pufferlänge des ersten Abschnitts des Videosegments charakteristisch sind;
(c) das Definieren eines dritten Satzes von Mehrfachwerten, die für eine anfängliche Pufferfülle des ersten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis der erste Abschnitt des Videosegments präsentiert wird;
(d) das Auswählen eines Wertes des Satzes von ersten Werten, eines Wertes des Satzes von zweiten Werten und eines Wertes des Satzes von dritten Werten, so dass der erste Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist;
(e) das Definieren eines vierten Satzes von Mehrfachwerten, die für eine anfängliche Pufferfülle eines zweiten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis ein zweiter Abschnitt des Videosegments präsentiert wird; und
(f) das Auswählen eines Wertes des Satzes von vierten Werten, so dass der zweite Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist.

KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt eine Decodierpufferfülle dar.
2 stellt eine R-B-Kurve dar.
3A und 3B stellen grafische Darstellungen einer Decodierpufferfülle für einige Bitströme dar, die in der CBR- bzw. VBR-Betriebsart arbeiten.
4 stellt einen Satz von N_Leaky-Bucket-Modellen und deren interpolierte oder extrapolierte (R-, B-) Werte dar.
5 stellt eine anfängliche Pufferung B_j für jeden beliebigen Punkt des Decodierers dar, den der Anwender sucht, wenn die Geschwindigkeit R_j ist.
6 stellt Sätze von (R, B, F) dar, die auf eine vorwärtsblickende Weise für den jeweiligen Videostrom definiert sind.
7 stellt die anfängliche Pufferfülle (in Bits) für ein Videosegment dar.
8 stellt die Auswahlkriterien eines Satzes von 10 Punkten für 7 dar.
9 stellt Auswahlkriterien dar.
10 stellt Verzögerungsreduzierungen dar.
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Wie zuvor beschrieben, erlaubt der JVT-Standard (WD-2) die Speicherung von (N > = 1) Leaky Buckets, (R₁, B₁, F₁), ..., (R_N, B_N, F_N) Werten, die in dem Bitstrom enthalten sind. Diese Werte können in dem Anfangsblock gespeichert sein. Das Verwenden von F_i als die anfängliche Pufferfülle und B_i als die Pufferlänge garantiert, dass der Decodierpuffer keinen Unterlauf hat, wenn der Eingangsstrom mit der Geschwindigkeit R_i eingeht. Dies ist der Fall, wenn der Anwender wünscht, das codierte Video von Anfang bis Ende zu präsentieren. Bei einer typischen Video-on-Demand-Anwendung kann der Anwender wollen, verschiedene Abschnitte des Videostroms zu suchen. Der Punkt, den der Anwender zu suchen wünscht, kann als der Zugriffspunkt bezeichnet werden. Während des Vorgangs des Empfangens von Videodaten und des Aufbauens von Videovollbildern schwankt die Datenmenge in dem Puffer. Nach Überlegung kam der vorliegende Erfinder zu der Erkenntnis, dass wenn der F_i-Wert der anfänglichen Pufferfülle (wenn die Kanalgeschwindigkeit R_i ist) verwendet wird, bevor begonnen wird, das Video von dem Zugriffspunkt zu decodieren, dann ist es möglich, dass der Decodierer einen Unterlauf hat. Zum Beispiel kann an dem Zugriffspunkt oder irgendwann danach die Menge an Bits, die für einen Videowiederaufbau notwendig ist, größer sein als die Bits, die momentan in dem Puffer sind, was zu einem Unterlauf und der Unfähigkeit führt, Videovollbilder auf eine zeitgemäße Weise zu präsentieren. Ebenso kann gezeigt werden, dass in einem Videostrom der Wert der anfänglichen Pufferfülle, die benötigt wird, um sicherzustellen, dass es an dem Decodierer keinen Unterlauf gibt, auf der Grundlage des Punkts variiert, an dem der Anwender sucht. Dieser Wert ist von dem B_i begrenzt. Dementsprechend ist die Kombination von B und F, die für die ganze Videosequenz bereitgestellt wird, sofern für einen Zwischenpunkt in dem Video verwendet, wahrscheinlich nicht geeignet, was zu einem Unterlauf und somit zu dem Einfrieren von Vollbildern führt.
Auf der Grundlage dieses zuvor nicht erkannten Unterlaufpotenzials kam der vorliegende Erfinder dann zu der Erkenntnis, dass wenn nur ein Satz von R-, B- und F-Werten für ein ganzes Videosegment definiert ist, dann das System warten sollte, bis der Puffer B für die entsprechende Geschwindigkeit R voll oder im Wesentlichen voll ist (oder mehr als 90% voll), um zu beginnen, Vollbilder zu decodieren, wenn ein Anwender auf einen Zugriffspunkt springt. Auf diese Weise ist die anfängliche Fülle des Puffers auf einem Höchstwert, und somit gibt es kein Unterlaufpotenzial während des nachfolgenden Decodierens ab dem Zugriffspunkt. Dies kann ohne irgendwelche zusätzlichen Änderungen an dem bestehenden Bitstrom erreicht werden, wodurch bestehende Systeme nicht beeinträchtigt werden. Entsprechend verwendet der Decodierer den Wert der anfänglichen Pufferung B_j für jeden beliebigen Punkt, den der Anwender sucht, wenn die Geschwindigkeit R_j ist, wie in 5 gezeigt. Jedoch führt dies leider manchmal zu einer beträchtlichen Verzögerung, bis Videovollbilder präsentiert werden, nachdem eine andere Stelle (zum Beispiel Zugriffspunkt), ab der das Video zu präsentieren ist, ausgewählt worden ist.
Die anfängliche Pufferfülle (F) kann gleichfalls als eine Verzögerung bis die Videosequenz präsentiert wird bezeichnet werden. Die Verzögerung ist ihrem Wesen nach temporär in Bezug auf die Zeit, die notwendig ist, um die anfängliche Pufferfülle (F) zu erreichen. Die Verzögerung und/oder F kann mit dem ganzen Video oder den Zugriffspunkten verbunden sein. Es versteht sich ebenfalls von selbst, dass F in sämtlichen hier beschriebenen Ausführungsformen durch Verzögerung ersetzt werden kann (zum Beispiel (R, B, Verzögerung)). Ein bestimmter Wert für die Verzögerung kann als Verzögerung = F/R unter Verwendung einer speziellen Zeiteinheit (Einheiten von 90 KHz Takt) berechnet werden.
Um die potentielle Verzögerung zu reduzieren kam der vorliegende Erfinder zu der Erkenntnis, dass Sätze von (R, B, F) für einen bestimmten Videostrom an jedem Zugriffspunkt definiert werden können. Auf 6 Bezug nehmend sind diese Sätze von (R, B, F) bevorzugt auf eine vorwärtsblickende Weise für den jeweiligen Videostrom definiert. Zum Beispiel kann ein Satz von (R-, B-, F-) Werten auf die früher bestehende Weise für den Videostrom als ganzes berechnet werden, des Weiteren kann ein Satz von F-Werten für dieselben (R-, B-) Werte wie jene für den ganzen Videostrom auf die früher bestehende Weise für den Videostrom in Bezug auf den Videostrom ab Position "2" nach vorne blickend usw. berechnet werden. Derselbe Vorgang kann für die verbleibenden Zugriffspunkte verwendet werden. Die Zugriffspunkte können jedes Vollbild in der Videosequenz, I-Vollbilder der Sequenz, B-Vollbilder der Sequenz oder P-Vollbilder der Sequenz sein (I-, B- und P-Vollbilder werden typischerweise in der Videocodierung auf MPEG-Basis verwendet). Dementsprechend kann der Anwender einen der Zugriffspunkte auswählen und danach das jeweilige F_ij für die gewünschte anfängliche Fülle (in der Annahme, dass die Puffer B_i und die Geschwindigkeit R_i unverändert bleiben) oder andernfalls einen Satz von zwei oder mehreren von R_i, B_i, F_ij verwenden.
Der Index "i" repräsentiert jeden Leaky Bucket, und der Index "j" repräsentiert jeden Direktzugriffspunkt. Nimmt man an, dass der Puffer B_i und die Geschwindigkeit R_i unverändert bleiben, ist ein Mehrfachsatz von Werten (B_i, R_i, F_il), wobei i = 1, 2, ..., N und F_il die anfängliche Pufferfülle repräsentiert, an dem Anfangsblock gespeichert. Dann ist F_ij, wobei j = 2, 3, ..., an jedem Zugriffspunkt j gespeichert. Andererseits, wenn man annimmt, dass der Puffer B_i und die Geschwindigkeit R_i an jedem Zugriffspunkt j geändert werden, kann ein Mehrfachsatz von Werten (B_ij, R_ij, F_ij) an dem Zugriffspunkt gespeichert werden. Der Vorteil des ersteren Falls ist, dass er die Datenmenge speichert, da nur ein Mehrfachsatz von F_ij an jedem Zugriffspunkt gespeichert ist, und der Vorteil des letzteren Falls ist, dass er den Satz von Werten für jeden Zugriffspunkt zweckdienlicher abgleichen kann. Wird die Verzögerung (D) bis die Videosequenz präsentiert wird statt der anfänglichen Pufferfülle (F) verwendet, ist es möglich, die vorliegende Erfindung zu verwirklichen, indem F_ij durch D_ij ersetzt wird. In diesem Fall repräsentiert Du den Wert der Verzögerung. Dann, wenn man annimmt, dass der Puffer B_i und die Geschwindigkeit R_i unverändert bleiben, wird (B_i, R_i, D_ij) an dem Anfangsblock gespeichert, und D_ij wird an jedem Zugriffspunkt j gespeichert. Nimmt man an, dass der Puffer B_i und die Geschwindigkeit R_i an jedem Zugriffspunkt j geändert werden, kann ein Mehrfachsatz von Werten (B_ij, R_ij, D_ij) an dem Zugriffspunkt gespeichert werden.
Diese Sätze von R-, B-, F-Werten für jeden Zugriffspunkt können an jeder geeigneten Stelle, wie zum Beispiel an dem Beginn der Videosequenz, zusammen mit Sätzen von (R-, B-, F-) Werten für den ganzen Videostrom oder vor jedem Zugriffspunkt angeordnet sein, was den Bedarf nach einem Index verhindert; oder auf eine Weise außerhalb des Videostroms selbst gespeichert sein, die für eine Server-/Client-Umgebung besonders geeignet ist.
Diese Technik kann durch das folgende Modell gekennzeichnet sein: (R₁, B₁, F₁, M₁, f_1l, t_1l, ... f_M1l, t_M1l) ..., (R_N, B_N, F_N, M_N, F_1N, t_1N, ..., f_MNN, t_MNN), wobei f_kj den anfänglichen Pufferfüllenwert bei einer Geschwindigkeit R_j an einem Zugriffspunkt t_kj (Zeitstempel) bezeichnet. Die Werte von M_j können als ein Eingabeparameter bereitgestellt werden oder können automatisch ausgewählt werden. Zum Beispiel kann M_j die folgenden Optionen umfassen:

(a): M_j kann gleich der Anzahl an Zugriffspunkten eingestellt sein. Auf diese Weise können die Werte von f_kj für jeden Zugriffspunkt bei jeder Geschwindigkeit R_j gespeichert sein (entweder zu Beginn des Videostroms, in dem Videostrom, verteilt durch den Videostrom, oder andernfalls an jeder Stelle).
(b): M_j kann gleich Null eingestellt sein, falls keine Suchfähigkeitsunterstützung gewünscht wird.
(c): M_j-Werte für jede Geschwindigkeit R_j können automatisch ausgewählt werden (später beschrieben).

Das System kann bei einem vorgegebenen R_j eine anfängliche Pufferfülle verwenden, die f_jk entspricht, falls der Anwender einen Zugriffspunkt t_kj sucht. Dies ereignet sich, wenn der Anwender auswählt, an einem Zugriffspunkt zu beginnen, oder andernfalls stimmt das System die Wahl des Anwenders auf einen der Zugriffspunkte ab.
Es wird bemerkt, dass für den Fall, dass eine variable Bitgeschwindigkeit (in dem Bitstrom) verwendet wird, der anfängliche Pufferfüllenwert (oder die Verzögerung) bevorzugt anders ist als die Pufferlänge (oder die von der Pufferlänge berechnete Verzögerung), obgleich er auch derselbe sein kann. Im Falle einer variablen Bitgeschwindigkeit in MPEG-2, wird der VBV-Puffer gefüllt, bis er voll ist, d. h. F = B (der Wert B wird von vbv_Puffer_Länge repräsentiert).
Bei der vorliegenden Erfindung kann der anfängliche Pufferfüllenwert an jedem Direktzugriffspunkt zweckdienlich ausgewählt werden, um jeglichen Pufferunterlauf und -überlauf zu vermeiden. Wird die Verzögerung, bis die Videosequenz präsentiert wird, anstatt der Pufferfülle verwendet, wird der Verzögerungswert an jedem Direktzugriffspunkt zweckdienlich ausgewählt, um jeglichen Pufferunterlauf und -überlauf zu vermeiden. Im Allgemeinen bedeutet dies, dass eine niedrigere Verzögerung an jedem Direktzugriffspunkt als das Füllen des VBV-Puffers, bis er voll ist, erreicht wird. Daher hat das Bestimmen des Pufferfüllenwertes (oder der Verzögerung), der kleiner ist als die Pufferlänge (oder die von der Pufferlänge berechnete Verzögerung) der vorliegenden Erfindung den Vorteil einer niedrigen Verzögerung, da weniger Daten als im Stand der Technik zwischengespeichert werden müssen, bevor das Decodieren begonnen wird.
Falls das System zulässt, dass der Anwender zu jedem beliebigen Vollbild des Videos auf der Weise eines Zugriffspunkts springt, dann müsste der Decodierdatensatz für jedes einzelne Vollbild bereitgestellt werden. Obwohl zulässig, wäre der resultierende Datensatz übermäßig groß und würde eine beträchtliche Menge der für die Daten verfügbaren Bitgeschwindigkeit verbrauchen. Ein vernünftigerer Ansatz wäre den Anwender auf spezielle Zugriffspunkte in dem Videostrom zu begrenzen, wie zum Beispiel jede Sekunde, alle 10 Sekunden, jede Minute usw. Obwohl eine Verbesserung kann der resultierende Datensatz immer noch etwas umfangreich sein, was zu übermäßigen Daten für Geräte mit begrenzter Bandbreite, wie zum Beispiel mobile Kommunikationsgeräte, führt.
Für den Fall, dass der Anwender eine Position auswählt, die nicht einer der Zugriffspunkt mit einem zugehörigen Datensatz ist, dann kann die anfängliche Pufferfülle gleich max_{(fkj,f(k+1)j)} für einen Zeitraum zwischen t_kj und t_(k+1)j sein, besonders, wenn die Zugriffspunkte richtig gewählt sind. Auf diese Weise wird garantiert, dass das System einen Satz von Werten hat, die frei davon sind, zu einer Unterlaufbedingung zu führen, oder andernfalls die Wahrscheinlichkeit einer Unterlaufbedingung zu reduzieren, wie nachstehend erklärt.
Um einen Satz von Werten auszuwählen, die keine Unterlaufbedingung sicherstellen (oder andernfalls reduzieren), wenn die oben genannten Auswahlkriterien verwendet werden, wird auf 7 Bezug genommen. 7 stellt die anfängliche Pufferfülle (in Bits) für ein Videosegment dar, wobei die vorwärtsblickende anfängliche Pufferfülle für 10-Sekunden-Erhöhungen berechnet wird. Dann wählt das System bevorzugt einen Zugriffspunkt an dem Beginn der Videosequenz und einen Zugriffspunkt an dem Ende des Videosegments aus. Zwischen dem Beginn und dem Ende des Videosegments wählt das System die lokalen Höchstwerte aus, um diese als Zugriffspunkte aufzunehmen. Auch kann das System die lokalen Mindestwerte auswählen, um diese als Zugriffspunkte aufzunehmen. Wenn ein begrenzter Satz von Zugriffspunkten gewünscht wird, wählt das System bevorzugt zuerst die lokalen Höchstwerte, dann die lokalen Mindestwerte aus, was dabei hilft, keinen Unterlauf sicherzustellen. Danach kann das System Zwischenpunkte, wie gewünscht, weiter auswählen.
Auf der Grundlage der Auswahlkriterien kann ein Satz von 10 Punkten für 7 ausgewählt werden, wie in 8 angezeigt. Auf 9 Bezug nehmend werden die 10 ausgewählten Punkte durch die gestrichelte Kurve angezeigt. Die resultierenden anfänglichen Pufferfüllenwerte an sämtlichen Zugriffspunkten werden durch die ununterbrochene Kurve angezeigt. Die ununterbrochene Kurve stellt einen "sicheren" Satz von Werten für sämtliche Punkte in dem Video dar, so dass der Decodierpuffer keinen Unterlauf hat. Falls sich extreme Schwankungen in der Bitgeschwindigkeit des tatsächlichen Bitstroms ereigneten, die in der Verarbeitung nicht erfasst wurden, wie zum Beispiel ein scharfer Zacken, dann ist es möglich, dass dies zu einem Unterlauf führt, obwohl normalerweise unwahrscheinlich. Die optimalen anfänglichen Pufferfüllenwerte an sämtlichen Zugriffspunkten werden durch die strichpunktierte Kurve angezeigt. Eine erhebliche Reduzierung der Pufferungszeitverzögerung wird im Gegensatz zur Erfordernis eines vollen Puffers erreicht, wenn auf einen Zugriffspunkt zugegriffen wird, wie in 10 dargestellt.
Des Weiteren, falls die Bitgeschwindigkeit und die Pufferlänge dieselbe bleiben, während ein anderer Zugriffspunkt ausgewählt wird, dann muss nur die modifizierte Pufferfülle F bereitgestellt oder anderweitig bestimmt werden.
Sämtliche hier genannten Bezugnahmen sind durch Bezugnahme aufgenommen.
Der Umfang der Erfindung wird durch die Ansprüche, die folgen, definiert.

Claims

Videocodierer, umfassend: (a) ein Mittel zum Definieren eines ersten Satzes von Mehrfachwerten (Ri), die für eine Übertragungsgeschwindigkeit eines ersten Abschnitts eines Videosegments charakteristisch sind; (b) ein Mittel zum Definieren eines zweiten Satzes von Mehrfachwerten (B_i), die für eine Pufferlänge des ersten Abschnitts des Videosegments charakteristisch sind; (c) ein Mittel zum Definieren eines dritten Satzes von Mehrfachwerten (F_il, D_il), die für eine anfängliche Pufferfülle des ersten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis der erste Abschnitt des Videosegments präsentiert wird; (d) ein Mittel zum Auswählen eines Wertes des Satzes von ersten Werten, eines Wertes des Satzes von zweiten Werten und eines Wertes des Satzes von dritten Werten, so dass der erste Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist; (e) ein Mittel zum Definieren eines vierten Satzes von Mehrfachwerten (F_ij, D_ij), die für eine anfängliche Pufferfülle eines zweiten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis ein zweiter Abschnitt des Videosegments präsentiert wird; und (f) ein Mittel zum Auswählen eines Wertes des Satzes von vierten Werten, so dass der zweite Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist.
Codierer nach Anspruch 1, bei dem der erste Abschnitt des Videosegments ein ganzer Abschnitt des Videos ist.
Codierer nach Anspruch 1, bei dem der zweite Abschnitt des Videosegments einen Direktzugriffspunkt des Videos bildet.
Codierer nach Anspruch 1, bei dem es mehrere zweite Abschnitte des Videosegments gibt.
Verfahren zur Videocodierung, umfassend: (a) das Definieren eines ersten Satzes von Mehrfachwerten (Ri), die für eine Übertragungsgeschwindigkeit eines ersten Abschnitts eines Videosegments charakteristisch sind; (b) das Definieren eines zweiten Satzes von Mehrfachwerten (B_i), die für eine Pufferlänge des ersten Abschnitts des Videosegments charakteristisch sind; (c) das Definieren eines dritten Satzes von Mehrfachwerten (F_il, D_il), die für eine anfängliche Pufferfülle des ersten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis der erste Abschnitt des Videosegments präsentiert wird; (d) das Auswählen eines Wertes des Satzes von ersten Werten, eines Wertes des Satzes von zweiten Werten und eines Wertes des Satzes von dritten Werten, so dass der erste Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist; (e) das Definieren eines vierten Satzes von Mehrfachwerten (F_ij, D_ij), die für eine anfängliche Pufferfülle eines zweiten Abschnitts des Videosegments charakteristisch sind oder für eine Verzögerung charakteristisch sind, bis ein zweiter Abschnitt des Videosegments präsentiert wird; und (f) das Auswählen eines Wertes des Satzes von vierten Werten, so dass der zweite Abschnitt des Videosegments frei von einer Unterlaufbedingung und einer Überlaufbedingung ist.
Verfahren nach Anspruch 5, bei dem der erste Abschnitt des Videosegments ein ganzer Abschnitt des Videos ist.
Verfahren nach Anspruch 5, bei dem der zweite Abschnitt des Videosegments einen Direktzugriffspunkt des Videos bildet.
Verfahren nach Anspruch 5, bei dem es mehrere zweite Abschnitte des Videosegments gibt.