HU228606B1 - Eljárás és berendezés adatáram konverziójára, eljárás és berendezés adatrögzítésre és adatrögzítési közeg - Google Patents

Description

A találmány multimédia adatok, többek között mozgóképi (videó) adatok, állöképi adatok, audio adatok rögzítésére szolgáló, olvasható és irható adathordozó közeggel, valamint műsorszórással továbbítandó adatok formázásával kapcsolatos. A találmány tárgya továbbá rendszer és eljárás adatok ilyen hordozóközegen történő rögzítésére.

Míg a korábbiakban 4,7 GB volt a maximális adattárolási kapacitás az újraírható optikai lemezek esetén, a fázisváltó DVD-RAM lemezek ma már több tíz GB tárolási kapacitással rendelkeznek. A DVD-RAM lemezeket már tárolási közegként használják a számítógép-iparban is, és várhatóan rövid időn belül adatrögzítő és lejátszó közegként használják majd az audío-vídeo (AV) alkalmazásokban, tekintettel arra, hogy időközben az MPEG-1 és MPEG-2 digitális AV adatok kódolási szabványait implementáló, gazdaságosan gyártható kódolókat és dekódolókaf fejlesztettek ki.

A digitális műsorszórás már megkezdődött Japánban, ami tehetővé teszi videó, audio és számos különböző program adatainak multípiexelését egy MPEG szállítási adatfolyamban (MPEG Transpsrt Stream, MPEG-TS). Szintén rendelkezésre állnak digitális műsorszórással továbbított adatokat rögzítő berendezések, melyek merevlemez-meghajtókat vagy DVD-meghajtókat használnak,

A digitális műsorszórást rögzítő, következő generációs berendezések a műsorszórással továbbított tartalmat' annak, eredeti formátumában, az. MPEG szállítási adatfolyam konvertálása nélkül rögzítik. Annak érdekében, hogy az adatrögzítő berendezésnek ne kelljen belsőleg feldolgoznia mind az MPEG szállítási adatfolyamat, mind az MPEG program adatfolyamot, az ilyen adatrögzítő berendezéseknek a vonalbemeneti csatlakozóra érkező, külső analóg AV jelet, vagyis a felhasználói tartalmat is konvertálniuk keli MPEG szállítási adatfolyammá az adatrögzítéshez.

A jelenlegi elméleti DVD szabványok, például a DVD-Videó, a DVD-Audio, a DVD Video-adatrőgzítés (DVD Videó Recording) és a DVD adatfolyam-rögzítés

99397-t 44Ö7/HG/GL

2~ (DVD Stream Recording) szabványok az MPEG program adatfolyamot (MPEG Program Stream, MPEG-PS) használják az audio-video adatfolyamok rögzítésére. Ez azt jelenti, hogy például az MPEG szállítási adatfolyam felhasználásával rögzített tartatomnak - például a fent említett digitális műsorszórással továbbított adatfolyamnak ~~ a DVD Videó formátummá történő átalakításához az MPEG szállítási adatfolyamot át kell alakítania MPEG program adatfolyammá.

Az MPEG szállítási adatfolyamban multiplexeivé továbbított tartalom MPEG program adatfolyammá történő konvertálása azonban bonyolult számításokat tesz szükségessé a dekódoló pufferkezelője számára. A konverziós folyamat ezért hosszú ideig tart, és az elemi adatfolyam újrakódoíását teszi szükségessé. Emiatt csökkenhet a kép- és hangminőség, így ezt a konverziót általában nehéz végrehajtani.

A találmánnyal célunk a fent említett problémák kiküszöbölése és olyan hordozóközeg megvalósítása, amelyre MPEG szállítási adatfolyam rögzíthető, ezáltal egy MPEG szállítási adatfolyam formátumban rögzített tartalom gyorsan és egyszerűen átalakítható MPEG program adatfolyam formátumra. A találmánnyal további célunk olyan rendszer és eljárás kidolgozása, amellyel a fent említett hordozóközeg felhasználásával adatok rögzíthetők, konvertálhatók és játszhatók le.

A kitűzött célokat egyrészt olyan adatfolyam-konvertáló berendezés megvalósításával énük el, amely multiplexeit videó adatokból és audio adatokból álló első adatfolyamnak egy bordozóközegen eltárolandó második adatfolyamra történő átalakítására szolgál. Az első adatfolyamnak első blokkokra felosztot adatok tárolására alkalmas szerkezete van, a második adatfolyamnak második blokkokra felosztott adatok tárolására alkalmas szerkezete van. Az első és második blokkok maximális adatmérete eltérő. Az első adatfolyam formátuma egy, a második adatfolyamra történő átalakításra alkalmas, előre meghatározott formátum.

Az előre meghatározott formátumban az első adatfolyam meghatározott számú, egymást követő első blokkjai egy muitiplexelési egységet alkotnak. A meghatározott szám úgy van megválasztva, hogy a muitiplexelési egységet alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban lévő adatok mennyiségét. Az egy muitiplexelési egységben lévő összes adat ugyanahhoz a

-3videó adatfolyamhoz vagy audio adatfolyamhoz tartozik. Az első adatfolyam átalakításának eredményeként adódó második blokknak a rendszer dekódolőjába történő bevitelének kezdési időpontja azonos egy első lehetséges időpont és egy második lehetséges időpont közöl a későbbivel, ahol az első lehetséges időpont az aktuálisan átalakítandó moltiplexeíésí egységnek a rendszer dekódolőjába történő bevitelének kezdési időpontja, míg a második lehetséges időpont az az időpont, amikor az aktuális multíplexelésí egység átalakításának eredményeként adódó második blokkot közvetlenül megelőző második blokknak a rendszer dekódolőjába történő bevitele véget ér.

A hordozóközegen olyan jelzőbit van eltárolva, amely megadja, hogy az első adatfolyam az előre meghatározott formátumban van~e eltárolva..

A adetfoíyam-konvertálő berendezés a bordozőközegről az első adatfolyamot beolvasását végző olvasó egységet; a beolvasott első adatfolyamot második adatfolyamra átalakító konvertáló egységet; és az átalakított második adatfolyamot a horodözőkőzegen eltároló adatrögzítő egységet tartalmaz. A konvertáló egység a jelzőéit értéke alapján meghatározza, hogy az első adatfolyam az előre meghatározott formátumban van-e eltárolva. Ha az első adatfolyam az előre meghatározott formátum szerint van eltárolva, akkor a multiptexeiési egységet alkotó első blokkokat az első blokkok multíplexelésí sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra alakítja át és a második blokknak a rendszer dekódolőjába történő bevitelének kezdési időpontjaként - mint az átalakított második blokkhoz tartozó ídőoímke információ - az első és a második lehetséges időpont közül a későbbit választja ki.

Az első adatfolyam egymást követő multipiexelési egységei olyan zárt egységet alkotnak, amelybe egy vezérlőblökk van beszúrva, A multíplexelésí egység elején elhelyezkedő első blokk olyan első időcímke információt (ATS[ij) tartalmaz, amely egy első referenciaérték alapján megadja a rendszer dekódolőjába történő bevitel kezdési időpontját. A vezérlőblokk tartalmazza az első referenoiaértéken alapuló első ídőoímke Információt (ATSJip), továbbá tartalmaz egy, az első referenciaértéktöl eltérő, második reféreneíaértéken alapuló második Időcímke információt (PORJíp), Az egyes multíplexelésí egységek elején elhelyezkedő első blokkok második időclmke Információja (calculatedJPCR(ij) és az első adatfolyam átalakításával adódó második adatfolyamban lévő minden egyes második blokknak a rendszer dekódolójába történő bevitelének kezdési Időpontja (SCRpj) az alábbi képletek alapján van kiszámítva:

SCR[1 j = calctoated„PCR[1]

SCRpJ = max {SORjM] * T, catouíated^PCR© oaioulated„PCR[íj~ PCR Jip * (ATSji'j - ATS.tip + C), ahol i olyan egész szám, amelynek értéke legalább 2, T egy második blokk minimális átviteli ideje, C pedig egy korrekciós tényező az ÁTSflj túlcsordulásához.

Á konvertáló egység az első adatfolyamnak a második adatfolyamra történő átalakításhoz átkódolja az első adatfolyamot, ha a jelzőbit vizsgálatával megállapítja, hogy az első adatfolyam formátuma nem az előre meghatározott formátum.

A kitűzött célokat másrészt olyan adatrögzítő berendezés megvalósításával érjük el, amely videó információ és audio információ multipiexelésére és az információk hordozókőzegen előre meghatározott formátum szerinti első adatfolyamként történő eltárolására szolgát Az előre meghatározott formátum lehetővé teszi az első adatfolyamnak egy második adatfolyamra történő átalakítását, ahol az első adatfolyamnak első blokkokra felosztott adatok tárolására alkalmas szerkezete van, míg a második adatfolyamnak második blokkokra felosztott adatok tárolására alkalmas szerkezete van. Az első és második blokkok maximális adatmérete eltérő. Az előre meghatározott formátumban az első adatfolyam meghatározott számú, egymást követő első blokkjai egy multlplexeiési egységet alkotnak, amely meghatározott szám úgy van megválasztva, hogy a multlplexeiési egységet alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban lévő adatok mennyiségét. Az egy multlplexeiési egységben lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik.

Az első adatfolyam egymást követő multlplexeiési egységei, amelyek dekódolást egységet alkotó videó adatokat tartalmaznak, olyan zárt egységet alkotnak, amelybe egy vezérlő-blokk van beszúrva, ahol a vezériőblokk olyan «* jelzőbitet tartalmaz, amely megadja, hogy az első adatfolyam az előre meghatározott formátumban van-e eltárolva.

Az első adatfolyam átalakításának eredményeként adódó második blokknak a rendszer dekődoléjába történő bevitelének kezdési Időpontja azonos egy első lehetséges Időpont és egy második tehetséges időpont közül a későbbivel, ahol az első lehetséges Időpont az aktuálisan átalakítandó mulfiplexeiési egységnek a rendszer dekődoléjába történő bevitelének kezdési időpontja, míg a második tehetséges időpont az az időpont, amikor az aktuális mulfiplexeiési egység átalakításának eredményeként adódó második blokkot közvetlenül megelőző második blokknak a rendszer dekődoléjába történő bevitele véget ér.

Az első adatfolyam úgy van a második adatfolyamra átalakítva, hogy a multipiexelési egységet alkotó első blokkok az első blokkok multipiexelési sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra vannak átalakítva és a második blokknak a rendszer dekódolójaba történő bevitelének kezdési időpontjaként - mint az átalakított második blokkhoz tartozó időcímke információ - az első és a második lehetséges időpont közül a későbbi van kiválasztva.

Az adatrögzítő berendezés az előre meghatározott formátum szerinti első adatfolyamként rögzítendő videó információ és audio információ kódolását végző kódoló egységet; a kódolt első adatfolyamot a hordozóközegen eltároló adatrögzítő egységet; és a kódoló egység, valamint az adatrögzítő egység vezérlését végző vezérlő egységet tartalmaz. A vezérlő egység az első adatfolyamban lévő videó információ és audio információ kódolásakor előre kiszámítja az első adatfolyam kódolt videó információjából és audio információjából átalakított második adatfolyamot, és ezt követően úgy kódolja az első adatfolyamban lévő videó információt és audio információt, hogy a ködőit első adatfolyam és az előre kiszámított második adatfolyam egyikénél se lépjen fel puffer-aluicsordulás és/vagy puffer-túlcsordulás.

A kitűzött célokat továbbá olyan bordozőközeg megvalósításával érjük el, amelyen első adatfolyamként multiplexeit videó adatok és audio adatok vannak rögzítve olyan előre meghatározott formátumban, amely tehetővé teszi az első

-δadatfolyamnak egy második adatfolyamra történő átalakitását, ahol az első adatfolyamnak első blokkokra felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak pedig második blokkokra felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok maximális adatmérete eltérő.

Az előre meghatározott formátumban az első adatfolyam meghatározott számú, egymást követő első blokkjai egy multiplexelési egységet alkotnak, amely meghatározott szám úgy van megválasztva, hogy a mulfiplexelési egységet alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban lévő adatok mennyiségét. Az egy mulfiplexelési egységben lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik. Az első adatfolyam egymást kővető mulfiplexelési egységei, amelyek dekódolás! egységet alkotó videó adatokat tartalmaznak, olyan zárt egységet alkotnak, amelybe egy vezérlöblokk van beszúrva, ahol a vezérlőblokk olyan jelzöbifet tartalmaz, amely megadja, hogy az első adatfolyam az előre meghatározott formátumban van-e eltárolva.

Az első adatfolyam átalakításának eredményeként adódó második blokknak a rendszer dekódolőjába történő bevitelének kezdési időpontja azonos egy első lehetséges időpont és egy második lehetséges időpont közöl a későbbivel, ahol az első lehetséges időpont az aktuálisan átalakítandó multiplexelési egységnek a rendszer dekódolőjába történő bevitelének kezdési időpontja, míg a második lehetséges időpont az az időpont, amikor az aktuális multiplexelési egység átalakításának eredményeként adódó második blokkot közvetlenül megelőző második blokknak a rendszer dekódolojába történő bevitele véget ér.

Az első adatfolyam úgy van a második adatfolyamra átalakítva, hogy a multiplexelési egységet alkotó első blokkok az első blokkok multiplexelési sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra vannak átalakítva és a második blokknak a rendszer dekódolőjába történő bevitelének kezdési időpontjaként ~~ mint az átalakított második blokkhoz tartozó időcímke információ - az első és a második tehetséges időpont közül a későbbi van kiválasztva.

X ** « * X ♦ < X· « '♦♦<·'* * « i

A kitűzött célokat továbbá olyan adatfolyam átalakítására szolgáló eljárással érjük el, amely során hordozóközegen tárolt multiplexeit audio adatokat és videó adatokat tartalmazó első adatfolyamot egy második adatfolyamra alakítunk át, ahol az első adatfolyamnak első blokkokra felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak második blokkokra felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok maximális adatmérete eltérő.

Az első adatfolyam formátuma egy, a második adatfolyamra történő átalakításra alkalmas, előre meghatározott formátum.

Az előre meghatározott formátumban az első adatfolyam meghatározott számú, egymást követő első blokkjaiból egy multiplexelési egységet képezünk, amely meghatározott számot úgy választjuk meg, hogy a multiplexelési egységet alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban lévő adatok mennyiségét. Az egy multiplexelési egységben lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik. Az első adatfolyam átalakításának eredményeként adódé második blokknak a rendszer dekődolójába történő bevitelének kezdési időpontját egy első lehetséges időpont és egy második lehetséges időpont közül a későbbivel tesszük egyenlővé, ahol az első lehetséges időpont az aktuálisan átalakítandó multiplexelési egységnek a rendszer dekódolőjába történő bevitelének kezdési időpontja, míg a második lehetséges időpont az az időpont, amikor az aktuális multiplexelési egység átalakításának eredményeként adódó második blokkot közvetlenül megelőző második blokknak a rendszer dekódolőjába történő bevitele véget ér.

A hordozóközegen olyan jelzöbltet tárolunk el, amely megadja, hogy az első adatfolyam az előre meghatározott formátumban van~e eltárolva.

Az eljárás során az első adatfolyam második adatfolyamra történő átalakításához megvizsgáljuk a jelzőéit értékét, és ha azt állapítjuk meg, hogy az első adatfolyam az előre meghatározott formátumban van eltárolva, akkor a multiplexelési egységet alkotó első blokkokat az első blokkok multiplexelési sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra alakítjuk át; és a második blokknak a rendszer dekódolőjába történő bevitelének

- 8kezdési időpontjaként - mint az átalakított második blokkhoz tartozó idöeimke információ - az első és a második tehetséges időpont közül a későbbit választjuk,

A kitűzött célokat továbbá olyan adatrögzítési eljárással érjük el, amely videó információ és audio információ mulfípiexelésére szolgái az információk bordozókőzegen előre meghatározott formátum szerinti első adatfolyamként történő eltárolásához, Az előre meghatározott formátum lehetővé teszi az első adatfolyamnak egy második adatfolyamra történő átalakítását, ahol az első adatfolyamnak első blokkokra felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak második blokkokra felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok maximális adatmérete eltérő.

Az előre meghatározott formátumban az első adatfolyam meghatározott számú, egymást kővető első blokkjaiból egy multiplexelési egységet képezünk, amely meghatározott számot úgy választjuk meg, hogy a multiplexeiésl egységet alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban lévő k mennyiségét. Az egy multípíexeíési egységben lévő összes ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik. Az első adatfolyam egymást követő multiplexelési egységeiből, amelyek dekódolás! egységet alkotó videó adatokat tartalmaznak, olyan zárt egységet képezünk, amelybe egy vezérlöblokk van beszúrva, ahol a vezérlőblokk olyan > tartalmaz, amely megadja, hogy az első adatfolyam az előre formátumban van-e eltárolva.

Az első adatfolyam átalakításának eredményeként adódó második blokknak a rendszer dekódolójába történő bevitelének kezdési időpontját egy első lehetséges időpont és egy második lehetséges Időpont közül a későbbivel tesszük egyenlővé, ahol az első lehetséges időpont az aktuálisan átalakítandó multiplexelési egységnek a rendszer dekódolójába történő bevitelének kezdési időpontja, míg a második lehetséges időpont az az időpont, amikor az aktuális multiplexelési egység átalakításának eredményeként adódó második blokkot közvetlenül megelőző második blokknak a rendszer dekódolójába történő bevitele véget ér.

~9 # . ·* « * φ φ φ φ * « φ **** > « * * *#* ♦ Α ΪΦ* β > *#

Az első multiplexelési

úgy alakítjuk át a második adatfolyamra, hogy a alkotó első blokkok az első blokkok multiplexelési nélkül, blokkonként egyetlen második blokkra dik blokknak a rendszer dekódoiőjába történő bevitelének mint az átalakított második blokkhoz tartozó időcímke

kezdési információ ~ az első és a második lehetséges időpont közül a későbbit választjuk.

Az adatrögzítési eljárás során az első adatfolyamban lévő videó információ és audio Információ kódolásakor előre kiszámítjuk az első adatfolyam kódolt videó információjából és audio információjából átalakított második adatfolyamot, és ezt kővetően úgy kódoljuk az első adatfolyamban lévő videó információt és audio információt, hogy a kódolt első adatfolyam és az előre kiszámított második adatfolyam- egyikénél se lépjen fel puffer-aluícsorduíás és/vagy puffer-tülcsordulás.

A kitűzött célokat végül olyan számítógépi programmal érjük el, amely a találmány szerinti adatfolyam-konverziós eljárás számítógépen történő

A találmány szerinti rendszerben az MPEG adatfolyamot tartalmazó hordozóközegen olyan jelzőbitet tárolunk el, amely azt jelzi, hogy az adatfolyam olyan formátumban van rögzítve, amely lehetővé az első adatfolyam, például MPEG szállítási adatfolyam egyszerű konvertálását a második adatfolyamra, például MPEG program adatfolyamra. Ezt a jelzőbitet egy előre meghatározott vezérlő csomagban helyezzük el. Ily módon az hordozőkőzegen eltárolt adatok elemzése nélkül is könnyen meghatározható, hogy az adatok az említett formátummal rendelkeznek-e. A találmány révén tehát hatékony formátumvlzsgálő eljárást valósítunk meg.

A találmányt a továbbiakban a rajz alapján ismertetjük részletesen. A rajzon;

- az 1. ábra egy DVD adatrögzítő berendezés és más, ahhoz használható komponens közötti interfész egy lehetséges változatának vázlatrajza;

- a 2. ábra egy DVD felvevő meghajtójának blokkvázlata;

- a -3A ábra egy lemez összetartozó adaterületeit szemlélteti;

~ a 38 ábra egy sáypufferben tárolt adatok mennyiségének változását szemléltető grafikon;

- a 4, ábra félvezető memóriakártyával és merevlemezes meghajtóval rendelkező DVD felvevő blokkvázlata;

- az 5A ábra egy tipikus lemez fizikai felépítését szemlélteti;

- az 58 ábra egy tipikus lemez adatformátumát szemléltet;

- a 6A és 68 ábrák a lemez logikai adafferületeít szemléltetik;

- a 7A ábra a lemez könyvtárát mutatja;

- a 78 ábra a fájlszerkezetet szemlélteti;

- a 8. ábra egy videó objektum felépítését mutatja;

- a 9. ábra az MPEG szabvány szerinti adatfolyam felépítését mutatja;

~ a 1ÖA-10C ábrák az MPEG szállítási adatfolyam (MPEG-TS) felépítését szemléltetik:

~ a 11A-11C ábrák az MPEG programozási adatfolyam (MFEG~PS) felépítését

- a 12.A-12D ábrák egy szállítási adatfolyam csomagjának felépítését mutatják;

- a 13A_: 138, 13C1 és 13C2 ábrák egy PAT táblázatra és egy PMAP táblázatra mutatnak be példákat;

- a 14A-14C ábrák videó objektumok elrendezését szemléltetik egy lemezen;

- a ISA és 158 ábrák a videó management információ adatszerkezetét szemléltetik;

- a 18A és 18B ábrák a videó management információ adatszerkezetét ismertetik;

~ a 17. ábra egy objektum, az objektum információ és a videó management információban lévő PGG információ közötti összefüggést szemlélteti;

- a 18. ábra egy lejátszó berendezés funkcionális blokkvázlata;

- a 19. ábra egy adatrögzítő berendezés funkcionális blokkvázlatát szemlélteti;

- a 20. ábra egy MPEG programozási adatfolyammá könnyen konvertálbatóan kódolt MPEG szállítási adatfolyam és a konverzió utáni MPEG program adatfolyam közötti összefüggést szemlélteti;

- a 21. ábra a találmány szerinti adatrögzítő berendezés kódolójának blokkvázlata;

- a 22. ábra egy saját-kódolású MPEG szállítási adatfolyamnak DVD formátumokra történő konvertálási folyamatainak különbözőségét szemlélteti, ami a rendszerkódolásban mutatkozó különbségekből adódik;

- a 23. ábra egy Tip csomag adatszerkezetét szemlélteti;

- a 24. ábra az adaptation_field mezé adatszerkezetét mutatja;

- a 25. ábra a DataJD mező adatszerkezetét mutatja;

- a 26. ábra a display_and__copy._info mező adatszerkezetét matatja;

-a 27. ábra az eneodejnío mező adatszerkezetét szemlélteti;

- a 28, ábra a MarkersPrívateData mező adatszerkezetét szemlélteti;

- a 29A ábra egy Tip csomag osomagazonosítőjának tartalmát szemlélteti;

- a 2SB ábra egy Tip csomag stream Jype azonosítójának tartalmát mutatja;

- a 30. ábra egy előre meghatározott formátumú SE8F adatfolyamban lévő PES csomag fejrészét alkotó mezők értékeit adja meg;:

- a 31. ábra egy előre meghatározott formátumú SESF adatfolyamban a PES„extensíonJiag és a PES_headérjjataJ:ength mezők tartalmát szemlélteti;

- a 32. ábra olyan MPEG szállítási adatfolyamra mutat példát, amely úgy van sajábkódolva, hogy ne illeszkedjen a T_STÖ modellhez;

- a 33.A és 33B ábrák olyan MPEG program adatfolyamra mutatnak példát, amely úgy van konvertálva egy MPEG szállítási adatfolyamból, hogy az MPEG program adatfolyam ne Illeszkedjen a F_STD modellhez;

- a 34. ábra az SOR számítás menetét szemlélteti;

- a 35. ábra egy előre meghatározott formátumú SESF elemi adatfolyamattribútumait mutatja, amikor az encode__condrtíon = „11b”;

- a 36. ábra egy élőre megbatározott formátumú SESF elemi adatfolyamattribútumait mutatja, amikor az encode_oondltion = „01b”;

- a 37. ábra a szabványos adatfolyam-szerkezetet szemlélteti DVD Videó adatfolyam esetén;

- a 38. ábra az MPEG-2 program: adatfolyamban lévő csomag fejrészének adatszerkezetéből szemléltet egy részt;

- a 39. ábra egy MPEG-2 program adatfolyamban továbbított csomag fejrészének adatszerkezetéből mutat egy részt;

- a 40A és 4ÖB ábrák egy videó blokk (videó paok) esetén az előre meghatározott formátumú SESF adatfolyamból az MPEG program adatfolyamra történő átalakítást szemléltetik;

φ * * ♦ ♦ χ χ Φ * « > Φ κ φ * » « < Φ » * Φ Φ * Α Α Φ Φ Φ Φ Α Α Φ Φ φ*

- a 41A és 41Β ábrák egy audio blokk (audio pack) esetén az előre meghatározott formátumú SESF adatfolyamtól az MPEG program adatfolyamra történő átalakítást szemléltetik;

- a 42. ábra az előre megbatározott formátumú SESF adatfolyam által megengedett audio bitsebességeket, valamint egy audio PES csomag esetén a megfelelő bitsebességek mellett az AC-3 és MPEG-1 audio adatfolyamokhoz használható maximális adatmező-hosszúságokat tartalmazó táblázat;

- a 43. ábra a teljes TS2PS konverziós folyamatot bemutató folyamatábra;

~ a 44. ábra a TS2PS konverziós folyamat inicializáló folyamatának folyamatábrája;

- a 45. ábra egy zárt egység (capsuie unit) TS2PS konverzió során történő feldolgozását bemutató folyamatábra;

- a 48. ábra a blokkegység (paok unit) feldolgozását bemutató folyamatábra;

- a 47. ábra az SOR számítási folyamatot bemutató folyamatábra;

- a 48. ábra a biokkfejrész (paok header) feldolgozását bemutató folyamatábra;

- a 49. ábra a csomagfejrész (packet header) feldolgozását bemutató folyamatábra;

- az 50. ábra az adatfolyam-azonosító feldolgozását bemutató folyamatábra;

~ az 51. ábra egy PES csomaggal kezdődő adatfolyam feldolgozását bemutató folyamatábra;

- az 52. ábra egy nem PES csomaggal kezdődő adatfolyam feldolgozását bemutató folyamatábra;

- az 53. ábra az adatmező feldolgozását bemutató folyamatábra;

- az 54. ábra a kitöltő csomag feldolgozását bemutató folyamatábra;

- az 55. ábra az előre meghatározod formátumú SESF adatfolyam formátumát szemlélteti;

- az 58. ábra az MPEG szabvány szerinti PES csomag adatszerkezetét szemlélteti;

- az 57A ábra egy korlátozás nélküli MPEG szállítási adatfolyamnak egy MPEG program adatfolyamra történő konvertálását szemlélteti;

~ az 578 ábra egy előre meghatározott formátumú MPEG szállítás! adatfolyamnak egy MPEG program adatfolyamra történő konvertálását szemlélteti;

- az 58Á ábra az MPEG szállítási adatfolyam és az előre kiszámított MPEG program adatfolyam pufferkezelését szemlélteti, amikor a konvertálás alatt állő MPEG szállítási adatfolyam és az eredményül kapott MPEG program adatfolyam bitsebessége azonos és puffer-tűlosordolás következik be;

- az 588 ábra az MPEG szállítási adatfolyam és az előre kiszámított MPEG program adatfolyam pufferkezelését szemlélteti, amikor a konvertálás alatt álló MPEG szállítási adatfolyam és az eredményül kapott MPEG program adatfolyam bitsebessége azonos, de puffer-tüicsordoiás nem következik be;

- az 59A ábra az MPEG szállítási adatfolyam és az előre kiszámított MPEG program adatfolyam pufferkezelését szemlélteti, amikor a konvertálás alatt álló MPEG szállítási adatfolyam bitsebessége nagyobb, mint az eredményül kapott MPEG program adatfolyam bitsebessége, és amikor puffer-túlcsordulás csak az MPEG program adatfolyamnál következik be;

- az 598 ábra az MPEG szállítási adatfolyam és az előre kiszámított MPEG program adatfolyam pufferkezelését szemlélteti, ha a konvertálás alatt álló MPEG szállítási adatfolyam bitsebessége nagyobb, mint az eredményül kapott MPEG program adatfolyam bitsebessége, azonban nem történik pufferdülcsorduiás;

~ a 8ÖA ábra a konvertált MPEG program adatfolyam blokkjaiban beállított idocimke információ (SCR> meghatározását szemlélteti, amikor az MPEG szállítási adatfolyam és az MPEG program adatfolyam bitsebessége azonos;

- a 60B ábra a konvertált MPEG program adatfolyam blokkjaiban beállított időcímke információ (SCR) meghatározását szemlélteti, amikor az MPEG szállítási adatfolyam átviteli sebessége nagyobb, mint az MPEG program adatfolyamé; és ~ a 61, ábra az egyes szállítási adatcsomagokhoz hozzáadott relatív átviteli Időpontja (ATS) és a multiplexelesi egységben lévő első szállítási adatcsomag átviteli időpontja (calcuíated_PCR(n j) közötti összefüggést szemlélteti,

A DVD lemezt, a DVD felvevőt és a DVD lejátszót a leírás további részében az ábrák segítségével a találmány szerinti hordozóközeg, adatrögzítő rendszer és lejátszó rendszer konkrét kiviteli alakjain keresztül Ismertetjük.

* « li 9

X * * * Μ

4. X « « V « W

A találmány lényeges jellemzőit a 8. és a 9. fejezetben Ismertetjük. Megjegyezzük azonban, hogy a továbbiakban az összes kiviteli alak a találmány egyegy lehetséges változata, bár az egyes kiviteli alakoknak a találmányhoz való kötődése eltérő mértékű. A leírás további része az alábbi fejezetekből áll:

1. DVD felvevő rendszer rövid bemutatása

2. A DVD felvevő funkcionális ismertetése

3. Egy DVD lemez rövid bemutatása

4. Reprodukált AV adatok bemutatása

5. AV adatok management információjának és lejátszás-vezérlésének rövid bemutatása

8. A lejátszási funkció alapvető működése

7. Az adatrögzítési funkció alapvető működése

8. A találmány jellemzőinek összefoglalása

9. Az egyes kiviteli alakok részletes ismertetése

Megjegyezzük, hogy az egyszerűség kedvéért a továbbiakban az MPEG szállítási adatfolyam (MPEG-TS) MPEG program adatfolyammá (MPEG-PS) történő konvertálását „TS2PS konverziónak nevezzük, illetve a „DVD formátum” mind a DVD Videó szabvány szerinti formátumot, mind pedig a DVD Videó adatrögzítési szabvány szerinti formátumot jelöli, ahol mindkét formátum az MPEG program adatfolyam formátumot követi.

1. A DVD adatrögzítő rendszer rövid ismertetése

Az 1. ábrán egy DVD felvevő, valamint a DVD felvevő és más berendezések közötti interfész látható vázlatosan.

Amint az 1. ábrán látható, a DVD optikai lemezt be lehet helyezni a videó adatok rögzítésére és reprodukálására szolgáló DVD felvevőbe. A DVD felvevőt

A DVD felvevőbe a videó adatok eljuttathatók analóg jelek formájában, például analóg műsorszórásból származó jelekkel, illetve digitális jelek formájában, például digitális műsorszórásból származó jelekkel. Az analóg műsor jeleit általában egy televíziókészülékbe beépített vevőegység fogadja, majd demoduiálja és a DVD

-15felvevő számára bemenetként továbbítja IMTSC vagy más típusó analóg videojel formájában. A digitális műsor jelelt a vételt követően egy set-top box (STB) vevőegység digitális jellé alakítja át demod liládéval és bemeneti jelként továbbítja a DVD felvevő számára, amely rögzíti a beérkező jeleket.

A DVD lemezen rögzített videó adatokat a fentiekhez hasonló módon reprodukálja és kimenetként szolgáltatja a DVD felvevő. A videojel nemcsak a bemenetén, hanem a kimeneten is előállítható analóg és digitális jel formájában. Az analóg kimeneti jel közvetlenül továbbítható a televíziókészüléknek, míg a digitális kimeneti jelet át keli vezetni az STB egységen keresztül annak érdekében, hogy a digitális jel analóg jellé legyen átalakítva, mielőtt megtekintés céljából a televízió bemenetére kerülne.

A DVD felvevőkön kívül DVD kamerák és személyi számítógépek Is használhatók a videó adatok DVD íemezeken történő rögzítésére, illetve azokról történő lejátszására. A nem DVD felvevővel rögzített videó adatokat tartalmazó DVD lemezek szintén behelyezhetek lejátszás céljából a DVD felvevőbe,

A videó adatokkal együtt az audio adatokat is rögzítik mind az analóg, mind pedig a digitális műsorok esetén. Ezek az audio adatok hasonló módon rögzíthetők és reprodukálhatók a DVD felvevővel, mint a videó adatok,

A videó adatok általában mozgóképi adatok, például videofilm, de lehetnek vagy tartalmazhatnak állóképeket Is. Ezeket az állóképeket például a DVD kamera állókép-készítő funkciójának felhasználásával lehet rögzíteni.

Az STB egység és a DVD felvevő összekapcsolására különböző digitális interfészek használhatók, mint például az IEEE 1394 szabvány szerinti, az AT API vagy az SCSI interfész.

Megjegyezzük, hogy a DVD felvevő és a televízió közötti jeltovábbításra nem csak a fent említett ÍMTSC kompozít videojel használható, hanem olyan kompozít jel is, amelyben elkülönítve fényerősség! jel és színkülönbségi jel is továbbítható.

A videojeleknek egy AV berendezés és egy televízió közötti továbbítására analóg interfész helyett digitális Interfészt, például OVI interfészt fejlesztettek ki, és a DVD felvevők, valamint a televíziókészülékek várhatóan rövid időn belül ilyen digitális ínterfésszel lesznek összekapcsolva.

» * * * » Φ * V

V A φ Φ X X φ # « φ φ- ♦ φ ψ Φ A *

Φ » Μ * « φ φ *φ φ * lg*

2. A DVD felvevő funkcióinak rövid ismertetése

A 2. ábrán egy DVD felvevő funkcióinak blokkvázlata látható. Egy tipikus DVD meghajtó egy DVD-RAM 100 lemezről adatokat beolvasó optikai 101 tejátszófejet, hibajavító kódot (ECC) feldolgozó 102 processzort, 103 sávpuffert, a 103 sávpuffert bemenetre, Illetve kimenetre kapcsoló 104 kapcsolót, 105 kódolót és 106 dekódolót tartalmaz.

Ahogy a 2. ábrán látható, az adatokat szektorokban rögzítjük a DVD-RAM 100 lemezen, ahol a szektor a legkisebb adatrögzítési egység. Egy szektor 2 kB adatot tartalmaz. A szektorokat ezután ECC blokkokba csoportosítjuk úgy, hogy mindegyik ECC blokk 32 szektort tartalmazzon. Az ECC 1Ö2 processzor az egyes ECC blokkok hibajavítását végzi.

A DVD felvevő a DVD lemezeken kívül félvezető-memória kártyákat vagy merevlemezes meghajtókat is használhat adattárolási közegként. A 4. ábrán olyan DVD felvevő blokkvázlata látható, amely a DVD lemezmeghajtón kívül félvezetőmemória kártyát és merevlemezes meghajtót Is tartalmaz.

Szükségesnek tartjuk megjegyezni, hogy egy szektor tehet Sí2 bájtos, 8 kBos vagy egyéb méretű is. Az egyes ECC blokkok tartalmazhatnak egyetlen szektort 18 szektort, 64 szektort vagy más számú szektort, Mivel a lemezen eltárolható adatmennyiség egyre növekszik, várhatóan növekedni fog a szektorméret és az egyes ECC blokkokon belül eltárolható szektorok száma is.

A 103 sávputfer különböző bitsebességgel rögzíti az AV adatokat, így az AV adatok hatékonyabban írhatók a DVD-RAM 100 lemezre. A DVD-RAM 100 lemez olvasási/írásí sebessége (Vaj rögzített, azonban az AV adatok bitsebessége (Vb) a tartalom komplexitásától, például videó adatok esetén a képek komplexitásától függően változik, A 103 sávpuffert ezért olyan pufferkénl használják, amely kiegyenlíti az olvasási/irási sebesség (Va) és az AV adatok bitsebessége (Vb) közötti

A 103 sávputfer hatékonyabb felhasználása révén az AV adatok szakaszosan is rögzíthetők a 10Ö lemezre, ahogy ezt a 3A és 3B ábrák segítségével az alábbiakban ismertetjük.

A 3A ábrán egy optikai lemez címezhető tárterülete látható. Amikor adatokat rögzítünk az [al, a2] folytonos területre és ez attól elválasztott [a3, a4] folytonos területre, ahogy ez a 3Á ábrán látható, az a2 pont utáni a3 pont keresése közben az AV adatok folyamatos lejátszása úgy tartható fenn, hogy az adatokat a 108 dekódoló 103 sávpufferében felhalmozott adatokból vesszük. Ennek időbeli lefolyása látható a

Az AV adatok kiolvasását az a1 címtől kezdjük, és az adatokat ti időponttól kezdjük betölteni a W3 sávpufferbe, miközben a 103 sávpufferből megkezdjük az adatok kiolvasását is. így az adatok mennyisége a 103 sávpufferben Va-Vb sebességgel, vagyis a 103 sávpuffer bemeneti Va sebességének és a 103 sávpoffer kimeneti Vb sebességének különbségével nő. Ez a folyamat az [a1, a2] folytonos terület a2 című végének eléréséig, vagyis a i2 Időpontig folytatódik. Ha ez alatt az idő alatt a 103 sávpufferben felhalmozódott adatok mennyisége S(t2), akkor az adatok a 108 dekódoló számára a 12 és t3 időpont közötti Időtartam alatt biztosíthatók, és az a3 címtől kezdődő kiolvasás során elkezd fogyni a 103 sávpufferben eltárolt B(t2) mennyiségű adat.

Magyarán, ha legalább egy bizonyos minimális mennyiségű adatot (fal, a2.l) eltárolunk a keresési művelet előtt, akkor az AV adatok folyamatosan biztosíthatók a dekódoló számára, amikor a keresés alatt is.

Annak a folytonos területnek a mérete, amely lehetővé teszi, hogy a dekódoló számára folyamatosan biztosítsuk az AV adatokat, amikor az adatokat N_ecc számú ECC blokká kívánjuk átalakítani, az alábbi egyenlet alapján határozható meg:

Njecc = W*T}/((N„sec^w3*S„slze}*'(1-VbAZa)) ahol N__sec az ECC blokkban lévő szektorok száma, Sjsíze a szektorméref és Tj a maximális keresési Idő.

A folytonos területen lehet sérült szektor is. Ennek a tényezőnek a figyelembevételével az összefüggő terület mérete az alábbi egyenlet alapján határozható meg:

N ecc = dH_ eccWb* (Tj+Ts)/((N seo*8*S.. síze}*(1 -Vb/Vaj) ahol dN eec a tolerált sérült szektorméret, Ts pedig a folytonos területen lévő sérült szektor elugrásához szükséges idő. Az így kapott méret kifejezhető az ECC blokkok számában Is.

«X « * * * «· ♦ Μ- *

18Az adatoknak a DVD-RAM lemezről történő olvasása, vagyis reprodukálása a fent ismertetett példa szerint történik, azonban nyilvánvaló, hogy ugyanaz az elv érvényes az adatoknak a DVD-RAM lemezre történő írása, vagyis rögzítése esetén is.

Nyilvánvaló, hogy a nem folytonosan rögzített AV adatok is folytonosan reprodukálhatok egy DVD-RAM lemezről, Illetve folytonosan rögzíthetők arra, amennyiben egy meghatározott minimális mennyiségű adat összefüggően van rögzítve a lemezen. A DVD lemezek esetén ezt a területet összefüggő lemezterületnek (oontíguous disc area, CDA) nevezik.

3.

A DVD lemez

Az 5A ábrán az írható optikai lemezek egyik típusát képviselő DVD-RAM lemez látható felülnózetben, míg az 5B ábrán egy ilyen lemez fizikai felépítése látható. Szükségesnek tartjuk megjegyezni, hogy a DVD-RAM lemezt egy lemezkazettában elhelyezve kell betenni a DVD felvevőbe a lemez adatrögzítési felületének megóvása érdekében. Amennyiben az adatrögzítési felületet valamilyen más eszközzel védik vagy bizonyos mennyiségű felületi sérülés tolerálható, a lemez közvetlenül, lemezkazetta használata nélkül is behelyezhető a DVD felvevőbe.

A DVD-RAM lemezek fázísválfo hordozóközegek. Az ilyen lemezeken kezelik, és az adatok címezhető módon vannak rögzítve. Mint korábban említettük, 32 szektor együttesen alkot egy hibajavító egységet, amely hibajavító kóddal van ellátva. Az ilyen egységet ECC blokknak nevezik.

Az 5A ábrán egy DVD-RAM lemez adatrögzítési területe látható felülnózetben, ahol a DVD-RAM lemez egy lehetséges írható optikai lemez. A DVD-RAM lemeznek bevezető területe van középen, a belső kerülete mentén, továbbá kivezető területe van a külső kerülete mentén és adatterülete van a bevezető területe és a kivezető területe között A bevezető területen az optikai fejátszőfej lemezhez való hozzáférésekor a szervomotort stabilizáló referenciajelek, valamint az optikai lemez típusának azonosítását lehetővé tevő kozegazonositó jelek vannak rögzítve, Ugyanezek a referenciajelek és közegazonosltó jelek rögzítve vannak a kivezető *

~ 19 ~ 'Τ *♦ területen is. Az adatterület szektorokra van felosztva, mindegyik szektor 2048 bájtot tartalmaz, és a szektor jelenti a legkisebb hozzáférési egységet.

A DVD-RAM lemez adatterülete zónákra is fel van osztva úgy, hogy, az ón. Z~ CLV (Zene Constant Linear Velocity) forgásvezédési eljárást lehessen használni adatrögzítésre és lejátszásra.

Az 5Ά ábra a DVD-RAM lemezen koncentrikusan kialakított zónákat szemlélteti. Ennél a példánál a DVD-RAM lemez 24 zónára van osztva, melyeket 0tói 23--ig számoztunk. A DVD-RAM: szögsebessége eltérő a különböző zónákban. A szögsebesség nagyobb a belső kerület közelében. A szögsebessége állandó, miközben az optikai lejátszóiéi ugyanazon zónán belül olvas adatokat. Ennek köszönhetően megnő a DVD-RAM adatrögzítési sűrűsége, és a felvétel, valamint a lejátszás során a lemezforgatás egyszerűbb vezérlése válik lehetővé.

Az 5B ábra az 5A ábrán koncentrikusan elhelyezett 0-23 zónákat, valamint a bevezető területet és a kivezető területet szemlélteti a lemez közepétől a lemez külső széle felé, a lemez sugara mentén.

Mind a bevezető terület, mind a kivezető terület tartalmaz egy séröléskezelö területet (defect management area, DMA). A sérüléskezelő terület olyan információk rögzítésére szolgál, amelyek megadják a sérülést tartalmazó szektor elhelyezkedését, továbbá a helyettesítő szektor helyére vonatkozó információt tartalmaznak, amely megadja, hogy a sérült szektort helyettesítő szektor melyik helyettesítő területen helyezkedik el.

Mindegyik zóna tartalmaz egy felhasználói területet a zóna közepén, továbbá egy helyettesítő területet és egy használaton kívüli területet a zóna szélén. A felhasználói terület olyan terület, amelyet a fájlrendszer használhat adatrögzítési területként. A helyettesítő terület olyan terület, amely a zónában lévő sérült szektor helyettesítésére szolgál. A használaton kívüli terület olyan terület, amelyet nem használunk adatrögzítésre és amely körülbelül két sáv szélességű. Egy zónán belül a szektorcímet a szomszédos sávokban azonos pozícióban rögzítjük, de a Z-CLV eljárás a szektorcímeket a zóna szélének közelében lévő sávokban eltérő pozícióba rögzíti. Ez a használaton kívüli terület így a zóna szélének közelében lévő sávokban a szektorcím olvasási hibák kiküszöbölésére szolgál.

* X < X *♦ XX X XX

20Vannak tehát olyan szektorok a zóna szélén, melyeket nem használunk adatrögzítésre. A ÖVD-RAM felhasználói területen lévő fizikai szektorok mindegyikéhez egy logikai szektorszám (LSN) van hozzárendelve annak érdekében, hogy folytonosan lehessen azonosítani azokat a szektorokat, melyeket a belső kerülettől kiindulva egymás utáni adatrögzítésre használunk.

A 6A és 8B ábra logikai szektorokat tartalmazó ÖVD-RAM lemez logikai adatterüietét szemlélteti. A logikai adatterületet „tárterületnek” nevezzük és felhasználói adatok rögzítésére használjuk.

A tárterületen rögzítek, adatokat fájlrendszerrel kezeljük. Á tárterület elején és végén a térszerkezetre vonatkozó információt rögzítünk, amely az adatokat tároló szektorok csoportjainak mint „fájloknak, valamint fájlok csoportjainak mint „könyvtárnak” a kezelésével kapcsolatos. A találmánynak ennél a kiviteli alakjánál az MDF fájlrendszert használjuk, melyet az ISO 13348 szabvány specifikál.

el a tárterületen belül, vagyis feldarabolható különálló részekre. Az egyes fájlokat alkotó szektorokból adódóan a fájlrendszer a tárterületen lévő összefüggő szektorokból álló minden egyes csoportot külön egységként kezel, és az egyes

A 7 A és 7B ábrán a DVD-RAM lemezen rögzített könyvtár és fájl szerkezete látható, A gyökérkönyvtár alatt található a VIDEÓÉRT könyvtár, és a VIDEÓÉRT könyvtáron belül különböző lejátszási adatokat tartalmazó objektumfájlok, valamint management információt, például lejátszást szekvenciát és különböző attribútumokat tartalmazó VIDEÓ Manager fájl található.

Az objektumok olyan adatszerkezetek, melyek illeszkednek az MPEG szabványokhoz: például PS__VO8, TS1„VO8, TS2_VOB, AOB, POB és MNF

Á PS__VGB, az AOB és a POB objektumok MPEG program adatfolyamok, míg a TS1__VO8 és a TS2__VOB objektumok MPEG szállítási adatfolyamok. A program adatfolyam olyan adatszerkezettel rendelkezik, amely az AV adatok csomagok formájában történő rögzítésére szolgál, A szállítási adatfolyamnak olyan adatszerkezete van, amely kommunikációs közegeknél alkalmazható.

A PS„VOB, a TS1„V08 és a TS2„V0B olyan objektumok, amelyek elsősorban videó adatokat tartalmaznak, azonban videó adatok mellett audio adatokat is tartalmaznak. Elvileg a TS1_VOB objektumokat a DVD felvevő kódolja egy explicit módon kezelt belső képstruktúrával, A TS2_VOB objektumok a DVD felvevőn kívül kerülnek kódolásra, és a belső képstruktüra, valamint az adatstruktúra egy része ismeretlen.

A TS1_VGB tipikusan olyan objektum, amelyet a DVD felvevő egy külső bemeneti analóg videojelből szállítási adatfolyammá kódolt át, illetve a TS2.VOB olyan objektum, amelyet a DVD felvevő kívülről érkező bemeneti digitális videojel kódolás nélküli, közvetlenül a lemezre történő rögzítésével hoz létre.

.Az AOB és a PÖB objektumok MPEG program adatfolyamok. Az AGB objektumok elsősorban audio adatokat, míg a RGB objektumok elsősorban állóképeket tartalmaznak.

Az MNP objektum egy konkrét gyártóra vonatkozó információt tartalmaz.

„Elsősorban videó adat” és „elsősorban audio adat” alatt a fentiekben azt értjük, hogy nagy bitsebességet allokálunk. A VOB objektumot mozgóképben és hasonló alkalmazásokban használjuk, míg az AGB objektumot zenei alkalmazásokban használjuk.

4. Reprodukált AV adatok rövid ismertetése

A 8. ábrán egy DVD lemezre AV objektumok formájában rögzített MPEG adatok szerkezete látható.

Amint a 8. ábrán látható, a videó adatfolyam és az audio adatfolyam szegmentálva és multiplexeivé van. Az MPEG szabvány a multiplexeit adatfolyamokat rendszer adatfolyamnak (system stream) nevezi, A DVD lemez esetén a rendszer adatfolyamot, amelyben DVB-speoífikus információ van elhelyezve, videó objektumnak (VOB) nevezik. A szegmentálás! egységet blokknak (pack) vagy csomagnak (packet) nevezik, és annak mérete körülbelül 2 kB.

A videó adatfolyamot az MPEG szabvány szerint kódolják, és változó bitsebességgel tömörítik esszévé úgy, hogy a bitsebesség nagyobb a bonyolult képek, például sok mozgást tartalmazó képek esetén, A képeket az MPEG

Κί

-22adatfolyamban í-képként, P~képkéní vagy B~képként: kódolják. Az l-képeket térbeli alapon tömörítik és azok véget érnek az egyes kereteken belül. A P~képeket és a B~ képeket időbeli alapon tömörítik a keretek közötti hasonlóságok felhasználásával Egy legalább egy l-képet tartalmazó képsort az MPEG szabványban képcsoportnak (Group of Píotures, GOP) neveznek. A képcsoport hozzáférési pontot jelent a gyors lejátszáshoz és más különleges lejátszási módokhoz, amiket a legalább egy, kereten belüli tömörítéssel elöáílltott l-kép jelenléte tesz lehetővé.

A DVD audio adatfolyam az MPEG audio kódoláson kívül kódolható még az AC-3 kódolással az LPCM kódolással vagy más kódolási eljárással

Amint a 8. ábrán látható, a videó objekíumegység (VOBU) olyan adategység, amely egy képcsoport videó adatait és az azokhoz tartozó audio adatokat multiplexelve tartalmazza. A VOBU tartalmazhat olyan információt is, amelyet fejrész információként ér el, és amely a mozgókép egy szakaszának kezelésére szolgál

A program adatfolyam és a szállítási adatfolyam a 8. ábrán bemutatott rendszer adatfolyam részét képezi. Mint korábban említettük, a program adatfolyam olyan adatszerkezettel rendelkezik, amely csomagokban rögzített adatokat tároló közeg esetén alkalmazható, míg a szállítási adatfolyam adatszerkezete kommunikációs közegekben történő felhasználásra van kialakítva.

A 9. ábra a program adatfolyam és a szállítási adatfolyam adatszerkezeteinek koncepcióját szemlélteti.

A program adatfolyam azonos hosszúságú blokkokat (paek) tartalmaz, amelyek az adatátvitel és a multiplexelés szempontjából a legkisebb egységek. Mindegyik blokk egy vagy több csomagot tartalmaz. A blokkoknak és a csomagoknak fejrésze és adatrésze van. Az adatterületet az MPEG szabványban adatmezőnek (payload) nevezik. A szektormérethez való kompatibilitás érdekében a DVD lemezen a blokkok hosszúsága azonosan 2 kB. Egy blokk több csomagot tartalmazhat, de mivel a DVD videó és audio adatokat tartalmazó blokkok csak egyetlen csomagot tartalmaznak, a különleges esetektől eltekintve 1 blokk megfelel 1 csomagnak,

A szállítási adatfolyam adatátviteli és multipiexelési adategysége azonos hosszúságú szállítási adatfolyam-csomagokat tartalmaz. A szállítási adatfolyamcsomag mérete 188 bájt az ATM átvitelhez mint kommunikációs szabványhoz való * *· » s * ♦ ♦ * »*·*·«

kompatibilitás érdekében. Egy vagy több szállítási adatfolyam-csomag együttesen alkot egy PES csomagot.

A PES csomag szerepe azonos a program adatfolyam és a szállítási adatfolyam esetén, és az adatszerkezete is megegyezik a két adatfolyam-típus esetén. Á program adatfolyam blokkjaiban tárolt csomagok közvetlenül PES csomagokat alkotnak, míg egy vagy több szállítási adatfolyam-csomagból álló csoport együttesen alkot egy PES csomagot.

A PES csomag a legkisebb kódolási egység, és azonosan kódolt videó adatokat, illetve aodio adatokat tartalmaz. Ez azt jelenti, hogy ugyanabban a PES csomagban nincsenek eltérő kódolási eljárással kódolt videó adatok és audio adatok. Ha viszont a kódolási eljárás azonos, nem szükséges megadni a képhatárokat és az audio keretek határait. Ahogy a 9. ábrán látható, egyetlen PES csomagban több keret is eltárolható.

A 1ÖA-1ÖC ábrákon, valamint a 11A-11C ábrákon a szállítási adatfolyam, illetve a program adatfolyam adatszerkezete láthatók.

Ahogy a 1ÖA-10C, valamint a 12A-12D ábrákon látható, mindegyik szállítási adatfolyam-csomag tartalmaz egy TS osomagfejrészt, egy adaptációs mezőt és egy adatmezőt. A TS csomagfejrész tartalmaz egy csomagazonosítóf (PID), amelynek segítségévei azok a videó, audio vagy egyéb adatfolyamok azonosíthatók, amelyekhez a szállítási adatfolyam-csomag tartozik.

Az adaptációs mezőben a program referencia ide (Program Clock Reference, PCR) van eltárolva. A PCR egy referencia érték az adatfolyamot dekódoló eszköz rendszerórája (system tíme olock, STC) számára. A dekódoló eszköz tipikusán a PCR idő alapján demcltlplexell a rendszer adatfolyamot, majd ezt követően összeállítja a videó adatfolyamot és az egyéb adatfolyamokat.

A dekódolást idöcímke (Deooding Time Stamp, DTS) és a megjelenítési időcimke (Presentatíon Time Stamp, PTS) a PES fejrészben van eltárolva. A DTS a PES csomagban eltárolt kép vagy audio keret dekódolást idejét adja meg, míg a PTS a videó vagy audio kimenet megjelenítési Idejét tartalmazza.

Szükségesnek tartjuk megjegyezni, hogy a PTS és a DTS értékeket nem szükséges eltárolni minden egyes PES csomag fejrészében. A dekódolás és a kimenet előállítása akkor lehetséges, ha a PTS és a DTS el van tárolva annak a PES φ ·*

« csomagnak a fejrészében, amelyben az l-kép első adata van el tárolva.

A szállítási adatfolyam-csomag szerkezete a 12A-12D ábrákon látható részletesen.

Amint a 12B-12D ábrákon látható, az adaptációs mező tartalmazza a PCR paramétert. Az adaptációs mező egy véletlen hozzáférésű megjelenítési jelzőbitet is tartalmaz. Ez a jelzőbíf azt adja meg, hogy a videó vagy audio keret elején lévő és egy hozzáférési pontként felhasználható adat el van-e tárolva a megfelelő adatmezőben. A fent említett PID paraméteren kívül a szállítási adatfolyam csomagfejrésze tartalmaz egy egységkezdetet jelző bitet is, amely egy PES csomag kezdetét jelzi, valamint egy adaptációs mező vezérlési adatot, amely azt jelzi, hogy adaptációs mező következik-e.

A 11A-11C ábrák a program adatfolyam blokkjainak szerkezetét szemléltetik. A blokk az SCR mezőt a fejrészében tartalmazza, míg a streamjd paramétert a blokkban eltárolt csomag fejrésze tartalmazza. Az SCR paraméter tulajdonképpen azonos a szállítási adatfolyam PCR paraméterével, és a streamjd paraméter azonos a PÍD paraméterrel. A PES adatcsomag szerkezete Is megegyezik a szállítási adatfolyam adatszerkezetével, továbbá a PTS és a DTS paraméterek a PES fejrészben vannak eltárolva.

A program adatfolyam és a szállítási adatfolyam közötti alapvető különbség az, hogy a szállítási adatfolyam lehetővé tesz több programot is. Ez azt jelenti, hogy programegységekben kifejezve a program adatfolyam csak egy programot szállíthat, míg a szállítási adatfolyam egyidejűleg több programot továbbíthat. Ez azt jelenti, hogy a lejátszó eszköznek képesnek kell lennie a szállítási adatfolyamban továbbított minden egyes programhoz tartozó videó adatfolyam és audio adatfolyam azonosítására,

A 13A és 138 ábra az egyes programok audio adatfolyamának és videó adatfolyamának adatszerkezetére vonatkozó információ továbbításához használt FAT táblát és PMAP táblát szemlélteti. Amint a 13A és 138 ábrán látható, a PMAP táblázat az egyes programokban felhasznált videó és audio adatfolyamok együttesére vonatkozó információt tárol, míg a ΡΆΤ táblázat a programokkal és a PMAP táblázatokkal kapcsolatos Információkat tartalmaz. A lejátszó eszköz ily « X X « χ χ. χ * -β * ♦ .> χ χ ·χ * > ♦ χ*· χ»Χχ <# ·Λ módon a ΡΑΤ táblázatra és a PMAP táblázatra hivatkozhat a megjelenítendő programhoz tartozó videó és audio adatfolyamok felismerése céljából.

A 14A-14C ábrák segítségével azt mutatjuk be, hogy a fent ismertetett program adatfolyam-blokkok és szállítási adatfolyam-csomagok miként vannak elrendezve egy lemezen.

Amint a 14A ábrán látható, egy ECC blokkban 32 szektor van.

Amint a 14B ábrán látható, egy program adatfolyam videó objektumát alkotó blokkok, vagyis PS blokkok a szektorok határán helyezkednek el Ennek oka az, hogy mind a blokkméret, mind a szektorméret 2 kB.

A szállítási adatfolyamban lévő videó objektumok, vagyis TS1 VÖB és TS2_VO8 objektumok 138 bájfos csomagok formájában vannak rögzítve, amely csomagokhoz a dekódoló bemeneti időpontját megadó 4 bájtos beérkezési időcímke (Arrival Time Stamp, ATS) van társítva. Egy külsőleg kódolt adatfolyam rögzítésekor az ATS paramétert a DVD felvevő állítja elő és társítja az egyes csomagokhoz, ahol az ATS paraméter azt az Időpontot adja meg, amikor a csomag egy külső forrástól megérkezett a DVD felvevőbe.

5. Az AV adat management információ és a lejátszásvezérlés összefoglalása

A 15A és 1SB ábrák, valamint a 16A és 16B ábrák a 7A, illetve 7B ábrákon látható videó management információs fájl (Videó Manager) adatszerkezetét szemléltetik.

A videó management információ olyan, az objektumra vonatkozó információt tartalmaz, mint például az objektumok tárolási helye a lemezen. A lejátszás vezérlési információ az objektumok lejátszási sorrendjét adja meg.

A 15. ábra olyan példát mutat be, amelynél a lemezre PESJVÖB41PS„VOB#n, TS-LVOB#1-TS1..VOB#n, valamint TS2-VOS#1-TS2...VOB#n objektumok vannak rögzítve.

Amint a 15A és 158 ábrán látható, az objektumok típusainak megfelelően külön PSJv'OB információs táblázat, TS1 „VÖB információs táblázat és TS2_VÖB információs táblázat van eltárolva. A táblázatok mindegyike az egyes objektumokra vonatkozó VÖB Információkat tárol.

X φ Α χ. ·χ Φ « « ν '* * Φ Φ Φ Φ φ * Φ * * < Φ φ #- * *·'*

V* ***Φ 4 **

A VGB információ a megfelelő objektummal kapcsolatos általános információt objektum attribútum adatokat, az objektum lejátszási idejét egy, a lemezen található címre átalakító hozzáférési térképet, valamint a hozzáférési térképhez tartozó management információt tartalmaz. Az általános információ a megfelelő objektumra és az objektum rögzítési idejére vonatkozó azonosítót tartalmaz. Az attribútum adatok videó adatfolyam attribútumokat (V.ATR), például a videó adatfolyam kódolási módját, az audio adatfolyamok számát (ASTJMs), valamint audio adatfolyam attribútumokat (A.ATR), például az audio adatfolyam kódolási módját tartalmazza.

A hozzáférési térkép két okból is szükséges. Az első ok az, hogy a programlánoölásí információ (vagyis a lejátszási útvonalat meghatározó lejátszási útvonal információ) kerüli az objektumok rögzítési pozícióinak a szektor címértéken alapuló közvetlen hivatkozását, és ehelyett az objektum lejátszási ideje alapján indirekt módon hivatkozik az objektumok helyeire. Az objektumok rögzítési pozíciói a RÁM közegtől függően változók lehetnek, például az objektum szerkesztéséből adódóan. Ez megnöveli a programláncolásl információ mennyiségét, amit frissíteni kell, ha a programláncolásl információ az objektum rögzítési pozíciókra közvetlenül a szektorcímek alapján hivatkozik. Ha viszont az objektumokra indirekt módon a lejátszási idő alapján hivatkozunk, nem szükséges frissíteni a programláncolásl információt, így elegendő csak a hozzáférési térképet frissíteni.

A második ok az, hogy az audio adatfolyamnak tipikusan két hivatkozási alapja van, egyrészt az időalap, másrészt az adat (bitfolyam) alap, azonban a közötti korreláció nem tökéletes.

Az MPEG-2 videó, vagyis a videó adatfolyamok kódolására szolgáló nemzetközi szabvány esetén például a változtatható bitsebesség kezd a norma lenni, vagyis egy olyan eljárás, amelynél a kép bonyolultságától függően változtatják a bitsebességet. Ebben az esetben nincs arányos összefüggés az adatfolyam kezdetétől beolvasott adatok mennyisége és a lejátszási idő között, így az időalapú véletlen hozzáférés nem lehetséges. Ennek a problémának a megoldására egy olyan hozzáférési térképet használunk, amely átváltást biztosit az í<

(bitfolyam) alap között.

és az adat ’s : , ζ _s* .

Φ *· V * fc * ♦ « Φ 4t <

» *#♦·>. »«*Φ Λ xjí

Amint a iési információ a felhasználó által definiált programláneolási információs táblázatot, eredeti programláneolási Információs táblázatot,, valamint címkereső pointert tartalmaz.

Amint a 18A ábrán látható, a programláneolási információnak két típusa van; az egyik a DVD felvevő által automatikusan előállitotí, az objektumok rögzítése során az összes rögzített objektumot leíró, eredetileg definiált programláneolási információ, a másik pedig a felhasználó számára egy konkrét lejátszási sorrend szabad meghatározását lehetővé tevő, felhasználó által definiálható programláneolási információ. A programláneolási információ e két típusát egységesen PGC információnak nevezzük a DVD lemez esetén, és a felhasználó által definiált programláneolási Információt U._PGC információnak, az eredeti programláneolási információt pedig G__PGC információnak nevezzük. Az U_PGC információ és az O_PGC információ olyan táblázat, amely az objektumok lejátszási ideje alatt a cellákat leíró cellainformációk listáját tartalmazza. Az 0_P6C információ által megadott objektumlejátszási időtartamot eredeti cellának (Ö_CELt) nevezzük, mig az U PGC információ által megadott objektumiejátszási időtartamot felhasználói cellának (Ll.. CELL) nevezzük.

végpontját a fent említett hozzáférési térkép alakítja át az aktuális helyet megadó címre, ahol az objektum el van tárolva a lemezen.

Amint a 16B ábrán látható, a PGC Információ által megadott ceJJacsoport a táblázatban megadott elemek sorrendje alapján egymás után előállított folytonos lejátszási szekvenciát határozza meg.

A 17. ábra az objektumok, a cellák, a PGC információk és a hozzáférési térkép közötti öí Amint a 17

82,63 celiainformációt szemlel látható, az 50 eredeti PGC információ legalább egy 60, 61, tartalmaz.

Az egyes 80-83 cellainformációk a reprodukálandó objektumot, valamint az objektum típusát és az objektum lejátszási időtartamát határozzák meg. Az 50 PGC információban lévő cellainformációk sorrendje meghatározza az egyes cellák által definiált objektumok lejátszási sorrendjét az objektumokat reprodukálásakor.

* ♦ «V • ·* * *

Az egyes celiainfcrmáciők. például a 68 ceílainformáció 88a tlpusmezöt tartalmaz, amely megadja a konkrét objektum típusát, 88b objektumazonosító mezőt tartalmaz, amely egy adott objektumot azonosít, 60c prezentációkezdési időpontot tartalmaz, valamint 68d prezentációbefejezési időpontot tartalmaz, ez utóbbi kettőt időbeli alapon megadva.

Az adatok lejátszása során a 80 cellainformációt egymás utáni sorrendben olvassuk ki az 58 PGC információból, és az egyes cellák által meghatározott objektumokat a cella által meghatározott lejátszási időpontban reprodukáljuk.

A 68c hozzáférési térkép a cetíaínformáeiőban lévő kezdeti és befejezési időpontokra vonatkozó információt alakítja át a lemezen található objektumok címeire.

A 80c hozzáférési térkép a fent említett leképezési információ. A hozzáférési térképet az objektumok rögzítésekor állítjuk elő és tároljuk el. A térkép előállítása érdekében analizálni kell az objektumadatok képszerkezetét. Pontosabban szólva, a 9. ábrán látható i-kép helyének detektálása, valamint a PTS és más időcímke adatok detektálása szükséges, vagyis a 10. és 11, ábrán látható l-képek lejátszási

A továbbiakban azokat a problémákat ismertetjük, amelyek a PS. VGB, a TS1_VOB és a TS2_VGB leképezési információ előállításakor merülnek fal.

Amint korábban az 1. ábra kapcsán említettük, a PS__VO8 és TS1JVOB paramétereket elsősorban a DVD felvevő állítja elő, amely a beérkező analóg műsort MPEG adatfolyammá kódolja át Az i-képet és az ídócímke adatokat így tehát a DVD felvevő állítja elő, és mivel az adatfolyam belső adatszerkezetét a DVD felvevő Ismén, a leképezési Információ probléma nélkül előállítható.

Amint szintén az 1, ábra kapcsán korábban említettük, a TS2JVOB objektum olyan digitális műsor, amelyet a DVD felvevő közvetlenül a lemezre rögzít közbenső kódolás nélkül. Mivel a DVD felvevő Ilyenkor nem állítja elő az időclmke információt és nem határozza meg az l-képek helyeit, ahogy azt abban az esetben tenné, ha P5...7Ö8 objektumot rögzítene, a DVD felvevő nem ismeri az adatfolyam belső adatszerkezetét, ezért ezt az információt a rögzített digitális adatfolyamból kell kiolvasnia.

* X * * « « « * * ♦ * ♦ * ♦» # ♦ ♦ Μ »♦*» φ»» β <

Ennek érdekében a DVD felvevő a TS2_VOB objektum leképezési információjának előállításához egy, a felvevő számára külsőleg kódolt adatfolyam eszlel az iá es az információt.

Először Is meghatározzuk az i-képekeí a 12. ábrán látható szállítási adatfolyam-csomag adaptációs mezőjének véletlen hozzáférést jelzó információja (random_accessjndicator) alapján, vagy a szállítási adatfolyam-csomag fejrészében levő egységkezdetet jelző információ (paylöad__unit_startjndicator) vizsgálatával. Áz időclmkét a PES fejrészben lévő PTS paraméter észlelése révén észleljük, Megjegyezzük, hogy a PTS paraméter helyett ídőcimkeként használható az adaptációs mezőből kiolvasott POR érték vagy a szállítási adatfolyam-csomag DVD felvevőbe történő beérkezési ideje Is. A DVD felvevő mindkét esetben egy magas szintű rendszerrétegben lévő információ alapján észleli az l-kerefek helyeit és nem szükséges analizálnia az MPEG adatfolyam videó rétegének adatszerkezetét. Ennek oka az, hogy nagyméretű az a tőbbletadat, amely a videó rétegnek a leképezési információ előállítása érdekében történő analizálásához szükséges.

Vannak olyan esetek is, amikor a rendszerréteg észlelése nem lehetséges. Ilyen esetekben a leképezési információ nem állítható elő, és ezért szükség van annak jelzésére, hogy nincs érvényes leképezési információ. Ezt a DVD felvevő a 15{to) ábrán látható leképezés management információ felhasználásával jelzi.

A 15(b) ábrán látható leképezés management információ leképezés érvényességi információt és saját kódolás jelzőbitet tartalmaz, A saját kódolás jelzőbit azt jelzi, hogy egy objektumot a DVD felvevő kódolt-e, és ezáltal azt jelzi, hogy a belső képszerkezet ismert és a leképezési információ, az időcímke információ és az l-kép helyére vonatkozó információ pontos. A leképezés érvényesség információ azt is jelzi, hogy van-e érvényes hozzáférési térkép vagy nincs.

A rendszerréteg például akkor nem észlelhető, ha az adaptációs mező nincs beállítva vagy amikor a digitális adatfolyam nem MPEG szállítási adatfolyam. A világon számos különböző digitális műsorszórási szabványt és formátumot használnak, és természetesen lesznek olyan esetek, amikor a DVD felvevő olyan objektumokat rögzít, amelyek számára nem tud térképet generálni. Ha például egy, a japán piacra tervezett és Japánban sugárzott digitális műsorokat rögzítő DVD

3δfelvevőt az Egyesült Államokban használnak az ottani digitális műsorok rögzítésére, nyilvánvalóan lesznek olyan esetek, amikor a DVD felvevő nem tud generálni térképet a rögzített objektumok számára.

A DVD felvevő azonban egymás után reprodukálhatja az objektumokat azokból a kezdő objektumokból, amelyekhez leképezési információ nincs előállítva. Ebben az esetben a rögzített digitális adatfolyamból származó videó adatfolyam előállítható oly módon, hogy azt egy digitális Interfészen keresztül az adatfolyamnak megfelelő STB-hez továbbítjuk.

működése

A fent említett optikai lemezen rögzített tartalom reprodukálására alkalmas DVD feívevő/iejáíszö lejátszási funkcióját ismertetjük a továbbiakban a 18. ábra

Amint a 18. ábrán látható, a DVD lejátszónak a 108 optikai lemezről adatokat leolvasó 281 optikai lejátszófejet a beolvasott adatok hibajavító feldolgozását végző 202 ECG processzort:, a hibajavítást kővetően a beolvasott adatokat átmenetileg eltároló 203 sávpuffért:, a videó objektumokat (PS_VO8) és más program adatfolyamokat reprodukáló 285 PS dekódolok a digitális műsorszórás objektumokat (TS_VOB) és más szállítási adatfolyamokat reprodukáló 286 TS dekódolót, az audio objektumokat (AOB) reprodukáló 207 audio dekódolót, az állóképi objektumokat (POB) dekódoló 208 állóképi dekódolót, a 205-208 dekódolok közötti átkapcsolást végző 210 kapcsolóeszközt, valamint a DVD lejátszó különböző egységeinek vezérlését ellátó 211 vezérlőegységet: tartalmaz.

A 180 optikai lemezen rögzített adatokat beolvassuk a 201 optikai olvasófejjel:, átvezetjük a 202 ECO processzoron és eltároljuk a 283 sávpufferben. A 203 sávpufferben eltárolt adatokat ezután a 285 PS dekódoloha, a 286 TS dekődoíőha, a 207 audio vagy a 208 állóképi dekódoióba továbbítjuk, ott dekódoljuk, majd dekódolt kimenetel állítunk elő.

A 211 vezérlőegység meghatározza, hogy a 16A és 18B ábrákon látható programláncolási információ (PGC) által meghatározott lejátszási szekvencia alapján mely adatokat kell beolvasni. A 16A és 188 ábrán látható példa alapján a 211 ♦ X « * > X

- 31 vezérlőegység így először a VOB#1 CELL#1 részét, majd a VQ8#3 CELL#2 részéi, végül a VOB#2 CELL#3 részét reprodukálja,

A 17. ábrán látható programláncolási információ (PGC) cella információjának felhasználásával a 211 vezérlőegység meghatározza a reprodukált cella típusát, a megfelelő objektumokat, valamint az objektumok lejátszásának kezdő és végpontját. A 211 vezérlőegység a ceííainformácíó alapján azonosított objektum periódushoz bemeneti adatokat szolgáltat a megfelelő dekódolőnak,

A 211 vezérlőegység azonosítja azokat az objektumokat ís, amelyeket a cellainformácló objektum azonosítója alapján kell reprodukálni. A 211 vezérlőegység azt a cellát is azonosítja, amelyik a beazonosított objektum lejátszási periódusa. Ezt a cellainformáció Starí_PTM és End_PTM paramétereinek a lemezen lévő címre történő átalakításával, a megfelelő VOB információ hozzáférési térképére történő hivatkozással végzi el,

A találmány ezen kiviteli alakja szerinti lejátszónak olyan 204 digitális interfésze ís van, amely ÁV adatfolyamot szolgáltat egy külső eszköz számára. Ily módon lehetővé válik az AV adatfolyamnak egy külső eszközhöz az IEEE 1394, az IEC 958 vagy más kommunikációs eszközön keresztül történő továbbítása. Ezt például úgy végezzük, hogy amikor a lejátszó nem rendelkezik olyan saját deködoíöval. amellyel a felvevö/lejátszó által nem kódolt TS2_VOB objektumot dekódolni képes, akkor a TS2_VOB objektumot közvetlenül továbbítjuk a kimenetre anélkül, hogy a 204 digitális interfészen keresztül egy dekódolást és megjelenítést végző, külső STB egységnek továbbítanánk.

Amikor a digitális adatokat közvetlenül egy külső eszköznek továbbítjuk, a 211 vezérlőegység meghatározza, hogy a 15(b) ábrán látható leképezési információ alapján lehetséges-e a véletlen hozzáférésű lejátszás. Ha a hozzáférési pont adat jelzőéit (véletlen hozzáférés jelenlétét jelző bit) érvényes, a hozzáférési térkép í~kép helyére vonatkozó információt tartalmaz. Ebben az esetben a 211 vezérlőegység hozzá tud férni az l-képet tartalmazó digitális adatokhoz és azokat egy külső eszköznek továbbítja a digitális interfészen keresztül, amennyiben a külső eszköztől gyors lejátszás iránti vagy más kérés érkezik. Ezenkívül időalapú hozzáférés is lehetséges, ha az időalapú hozzáférési információ jelzőbitje érvényes. Ebben az egy megf * átárazott lejátszási időponthoz

X X tartozó képadatokat tartalmazó digitális adatokhoz és azokat a digitális interfészen keresztül egy külső eszköznek továbbíthatja, amennyiben a külső eszköztől időalapú hozzáférési kérés érkezik.

7. A rögzítési funkció alapvető működése

A továbbiakban a 19. ábra segítségével a találmány szerinti DVD felvevő konfigurálását és működését ismertetjük, amely DVD felvevő adatok optikai lemezre történő rögzítésére és optikai lemezen tárolt adatok reprodukálására alkalmas.

Amint a 19. ábrán látható, a DVD felvevőnek felhasználói kéréseket fogadó, valamint a felhasználó számára információt és fogadójelet megjelenítő 222 felhasználói interfésze, a DVD felvevőt vezérlő és annak teljes működését felügyeld 212 rendszervezérioje, VHF és UHF műsorok vételére szolgáló 213 analóg hangolója, az analóg jeleket digitális jelekké átalakító és a digitális jeleket MPEG program adatfolyammá átkódoló 214 kódolója, digitális műholdas műsorok vételére alkalmas 215 digitális hangolója, digitális műsort továbbító műhold által elküldött MPEG szállítási adatfolyamot interpretáló 216 analizátora, 217 prezentáló egysége, például televíziókészüléke vagy hangszórója, valamint az ÁV adatfolyamot dekódoló 21S dekódöloja van. A 218 dekódolónak első és második dekődoíöja van, ahogy ez a

18. ábrán látható. A DVD felvevőnek ezenkívül 219 digitális interfésze, az írási adatokat átmenetileg eltároló 220 sávputtere, az adatokat lemezre író 221 meghajtója, valamint 223 konvertere van. A 219 digitális interfész egy IEEE 1394 szabvány szerinti interfész vagy más kommunikációs interfész, amellyel adatok küldhetők egy külső eszköznek, A 223 konverter a szállítási adatfolyamot a 37. ábrán látható és később részletesen bemutatásra kerülő folyamatábra alapján program adatfolyammá alakítja át.

A 222 felhasználói interfészt tartalmazó DVD felvevővel először egy kérést fogadunk a felhasználótól. A 222 felhasználói interfész a kérést a 212 rendszervezérlőnek továbbítja, majd a 212 rendszervezérlö interpretálja a felhasználói kérdést és a különböző modulokat a megfelelő folyamatok végrehajtására utasítja.

Az adatrögzítés során vagy sajátkódolást végzünk, amikor is a DVD felvevő saját maga kódolja a beérkező digitális adatokat, vagy külső kódolást végzünk, amikor is a már kódolt digitális adatokat további kódolás nélkül rögzítjük a lemezre.

7,1 Adatrögzítés saját kódolással először a sajátkódolással történő adatrögzítést ismertetjük egy olyan példán keresztül, amelynél egy analóg műsort PS_VÖB adatfolyammá kódolunk át, majd rögzítünk.

A 212 rendszervezérlő vételi utasítási küld a 213 analóg bangóiénak és kódolási utasítást küld a 214 kódolónak. A 214 kódoló a 213 analóg bangóiétól kapott AV adatokon videó kódolást, audio kódolást és rendszerkódolást végez, majd a kódolt adatokat a 220 sávpuffernek továbbítja.

Rögtön a kódolás megkezdését kővetően a 214 kódoló a ködolás alatt álló program adatfolyam kezdetéhez tartozó idöoimke adatot elküldi a 212 rendszervezérlonek mint lejátszási kezdési idő (PS__VOB__V_S_PTM) paramétert, majd ezzel egyidejűleg a kódolási folyamat a hozzáférési térkép létrehozásához szükséges adatokat elküldi a 212 rendszervezérlőnek. Ezt az értéket a 17, ábrán látható celiainformácíó StarfoPTM mezőjében állítjuk be és később ismertetett módon állítjuk elő. Az Időcímke információ általában a PTS, de ahelyett az SCR is használható.

A 212 rendszervezédő ezután elküld egy írási utasítást a 221 meghajtónak, amely a 220 sávpufferből kiolvassa az abban összegyűjtött adatokat és rögzíti azokat a DVD-RAM 100 lemezen. Mivel a lemez írható területén a korábban említett összefüggő adatterüiet (CDA) Is található, az adatokat a kiválasztott folytonos

Az adatrögzítés tipikusan akkor ér véget, amikor a felhasználó az adatrögzítés leállítására vonatkozó utasítást ad ki. A felhasználó az adatrögzítés leállítására vonatkozó utasítást a 220 felhasználói Interfészen keresztül küldi el a 212 rendszervezértőnek, amely ez aí hangolónak és a 214 kódolónak.

egy leállító utasítást a 213 analóg

A 214 kódoló akkor állítja ie a kódolást, ha a 212 rendszervezériotöl a kódolás leállítására vonatkozó utasítást kap. Ekkor a 214 kódoló az utoljára kódolt MPEG program adatfolyamban lévő utolsó adat időcímke adatát elküldi a 212 rendszervezérlőnek mint a lejátszási végpont (PS__VOB_V.. EJPTM) paramétert. Ezt az értéket a 17. ábrán látható cellaínformáoíő End_PTM mezőjében tároljuk el. Az időcímke információhoz általában a PTS-í használjuk, de ahelyett az SCR is használható.

A kódolási folyamat befejeztével a 212 rendszervezérlő előállítja a íejétszásvezérlő információt és a VOB Információt (PS_VÖBi) a 15. ábrán látható program adatfolyam videó objektum (PS VOB) számára.

Az így előállított VOB Információ leképezési management Információt és az objektum típusának megfelelő hozzáférési térképet tartalmaz. A 212 rendszervezéríő a leképezés management Információ leképezés érvényességi információját „érvényesre” állítja és a sajátkődolás jelzőbítjét aktiválja.

Lejátszásvezédési információként az eredeti lejátszási Információt (O_PGC információ, lásd a ISA és 17B ábrát) állítjuk elő, amelyben a rögzítendő objektum egyike a lejátszandó objektumoknak. Ezt az OJPGC információt hozzáadjuk az eredeti programiáncolási információs táblázathoz. Az eredeti programfáncolási információ (O_PGC információ) cellainformációt tartalmaz. A cellaínformáció típusát a PS__VÖ8 objektumnak megfelelően állítjuk be.

A 212 rendszervezéríő ezután a 221 meghajtót arra utasítja, hogy állítsa le a 220 sávpufferben lévő adatok rögzítését és rögzítse a program adatfolyam videó objektumhoz tartozó VOB információt (PSJ/OBi), valamint a lejátszásvezédési információt. A 221 meghajtó ezt követően rögzíti az említett információkat és a 220 sávpufferben maradó adatokat a 100 optikai lemezen, majd ezzel a rögzítési folyamat véget ér.

Nyilvánvaló, hogy az analóg műsor átkódolható TS1_VOB adatokká. Ebben az esetben a 214 kódolónak olyan eszköznek kell lennie, amely az analóg jeleket digitális jelekké képes átalakítani, valamint a digitális jeleket MPEG szállítási adatfolyammá képes átkódolni, miközben a ceílainformáciőban lévő típus információértékéi TS1...VOB értékre állítja. A Start_PTM és az End..PTM paraméterekhez a PTS vagy a PCR használható fel.

35»*

7,2 Adatrögzítés külső kódolással

A továbbiakban digitális műsor rögzítésén keresztül a külső kódolással történő adatrögzítést ismertetjük, A rögzített objektumtipus ebben az esetben TS2__VÖB.

A felhasználótól érkező, digitális műsor rögzítése iránti kérést a 222 felhasználói interfésztol a 212 rendszervezérlőnek továbbitjük, A 212 rendszervezérlő arra utasítja a 215 digitális bangóiét, hogy fogadja az adatokat, illetve arra utasítja a 216 analizátort, hogy analizálja a beérkező adatokat.

A 215 digitális hangolótói érkező MPEG szállítási adatfolyamot a 216 analizátoron keresztül a 220 sávpüfíerbe továbbítsuk.

A digitális műsorként beérkező, kódolt MPEG szállítási adatfolyam (TS2„VÖB) VOB információjának (TS2_VOBl) előállításához a 216 analizátor először kiolvassa az időcímke adatot a szállítási adatfolyam elejéről, amely adat kezdési időpont információként (TS2_VOB .V_S_PTM) szolgál, majd ezt az adatot elküldi a 212 rendszervezérlőnek. Ezt a kezdési időpont értéket a 17. ábrán látható, később előállított cellaínformáció Start_FTM mezőjében tároljuk el. Az időcímke információ a POR vagy a PTS. Időcímke információként az az időpont is használható, amikor az objektumot elküldjük a DVD felvevőnek.

A 216 analizátor ezután analizálja az MPEG szállítási adatfolyam rendszerrétegét és meghatározza azt az információt, amely a hozzáférési térkép előállításához szükséges. Az objektumban lévő l-képek helyeit a korábban említett szállítási adatfolyam-csomag fejrészében lévő adaptációs mező véletlen hozzáférési jelzése (random_acceasjndícator) alapján észleljük, vagy a szállítási adatfolyamcsomag fejrészében léve egységkezdés jelző információ (payload jjml_startJndícator) alapján észleljük.

A 212 rendszervezérlő ezután Írási utasítást küld a 221 meghajtónak, amely kiolvassa a 220 sávpufferben lévő adatokat és azokat a DVD-RAM 1ÖŐ lemezre írja. A 212 rendszervezérlő olyan utasítást is ad a 221 meghajtónak, hogy a fájlrendszer allokációs adatok alapján a 100 lemez mely részére írjon. Mivel a 100 lemez adatrögzítési területen a korábban említett folytonos adatterület (CDA) is van, az adatokat a kiválasztott folytonos adatterületre rögzítjük.

·’?·

tés tipikusan akkor ér véget, amikor a felhasználó az leállítására vonatkozó utasítást ad ki. A felhasználó által kiadott, az leállítására vonatkozó utasítást a 222 felhasználói Interfészen keresztül a 212 rendszervezérionek továbbítjuk, amely ezután leállító utasítást küld a 215 digitális bangóidnak és a 216 analizátornak.

A 212 rendszesvezédőtöl érkező leállító utasítás beérkezését követően a 218 analizátor befejezi a beérkező adatok analizálását és az utoljára analizált MPEG szállítási adatfolyam végén időcímke adatot küld a 212 rendszervezérlőnek, amely adat lejátszási végpont (TS2_VO8__V_E__PTM) paraméterként szolgál. Ezt az értéket a 17. ábrán látható celíalnformáclö End_PTM mezőjében tároljuk el Az időcímke információként felhasználható a PCR vagy a PTS, de ahelyett megadható az az is, amikor az objektumot elküldjük a DVD felvevőnek.

A digitális műsor vételi folyamatának befejeződését követően a 212 a 15, ábrán látható módon, a 218 analizátortól érkező Információ alapján előállítja a lejátszásvezédési információt és a TS2JVOB objektumhoz tartozó

VOB információt (TS2„ VOBI).

Az így előállított VOB információ leképezés managemenf információt és az objektum típusának megfelelő hozzáférési térképet tartalmaz. A 212 rendszervezérlö a leképezés managemenf információ leképezés érvényességi információjának értékét „érvényesre állítja be, amikor az objektumban l-képek helyeit észleli, majd ezt követően előállítható a hozzáférési térkép. A sajátkódolás jelzőbitjét ekkor nem al elő, a örvényes „érvénytelenre” állítjuk. Érvényes hozzáférési térkép például akkor nem állítható elő, amikor nem fogadunk megfelelő digitális műsort vagy amikor nincs véletlen hozzáférési információ beállítva az adaptációs mezőben. Amikor a jelet közvetlenül a digitális interfészen keresztül vezetjük be, a jel az MPEG szállítási adatfolyamtól eltérő formátumú is lehet, és a leképezés érvényességi jelzőbitet ebben az esetben is „érvénytelenre” állítjuk be.

A rögzített objektumhoz minta lejátszási objektumok egyikéhez tartozó, a 18A és 18B ábrán látható, eredeti lejátszási Információt (OJPGC információ) lejátszásvezédési Információként állítjuk elő. Ezt az O__PGC információt eltároljuk az eredeti programláncolásí információs táblázatban. Az eredeti programláncolási **♦* ***« ♦ *

információ (O_PGC információ) olyan cellainformációt tartalmaz, melynek információs típusa a TS2_VOB értékre van állítva,

A 212 rendszervezérlő ezután a 221 meghajtót arra utasítja, hogy fejezze be a 22Ö sávpufferben lévő adatok rögzítését és rögzítse a TS2_VOB objektumokhoz tartozó VOB információt (TS2_VGBI), valamint a lejátszásvezérlési információt. A 221 meghajtó rögzíti az említett információkat és a 220 sávpufferben megmaradó adatokat a 100 optikai lemezre, és ezzel az adatrögzítési folyamat véget ér.

Bár a fenti adatrögzítési műveleteket adatrögzítés elindítására és leállítására vonatkozó felhasználói utasítások alkalmazásával Ismertettük, nyilvánvaló, hogy ugyanez a működés elv érvényes az időzített felvétel készítésére is, például egy videokamerában alkalmazott, Időzített felvétel készítésére. Ebben az esetben a rendszervezérlő automatikusan adja ki az adatrögzítés elindítására és leállítására vonatkozó utasításokat a felhasználó helyett. Más lényeges eltérés nincs a DVD felvevő működésében.

8, A találmány elvének Ismertetése

A találmány szerinti bordozóközeg olyan közeg, amelyen számos különböző formátumú adat, például analóg vagy digitális mösortartaiom, valamint egy analog/digítálls Interfészen keresztül érkező, különböző típusú adatok rögzíthetők. A találmány szerinti adatrögzítő berendezés olyan berendezés, amellyel az imént említett hordozóközegre AV adatok rögzíthetők.

A találmány szerinti adatrögzítő berendezésnél a kívülről érkező AV adatokat MPEG szállítási adatfolyamként rögzítjük és a találmány szerinti hordozóközegen minden egyes MPEG szállítási adatfolyam-csomaghoz egy, az adott csomagra vonatkozó dekódoló bemeneti időlnformácíót (Időcimke információ) rögzítünk. Az MPEG szállítási adatfolyam-csomaghoz hozzárendelt időcimke információ és az MPEG szállítási adatfolyam blokkjaihoz a konverzió után hozzárendelt Időcimke információ egy speciális összefüggés alapján áll kapcsolatban egymással,

A 20. ábrán egy MPEG szállítási adatfolyam és annak MPEG program adatfolyammá történő átalakítása látható. Amint a 20. ábrán látható, az MPEG szállítási adatfolyam tartalmaz egy PS1 (program specifikus információ) csomagot,

amely az MPEG szállítási adatfolyamra vonatkozó vezérlés! információt tartalmaz, továbbá az MPEG szállítási adatfolyamban adatrögzítő-specifikus és tartatomspecifikus információ található egy magán célú felhasználásra szánt adatfolyamban (Tip csomag)· Ezenkívül az MPEG szállítási adatfolyam minden egyes csomagban tartalmaz dekódoló beviteli időpontot (ATS) a halmozott idő megadására alkalmas formátumban,

A multiplexeit MPEG szállítási adatfolyam MPEG program adatfolyammá történő egyszerű átalakítása érdekében meghatározott számú, egy vagy több MPEG szállítási adatfolyam-csomagot rendszerkódolással egyetlen folytonos egységgé alakítunk át, melyet a multíplexeiésí egységbe történő multíplexeiést kővetően MPEG szállítási adatfolyamként rögzítünk. A multlptexelési egységet úgy alakítjuk ki, hogy a multiplexelésí egység adatmennyisége megfeleljen az MPEG program adatfolyam adatblokkjának adatmennyiségének. Az ilyen multíplexeiésí egység bevezetésével egyszerűvé válik az MPEG szállítási adatfolyamnak MPEG program adatfolyammá történő átalakítása oly módon, hogy a multíplexeiésí egységekben lévő MPEG szállítási adatfolyam-csomagokat egyszerűen átalakítjuk MPEG program adatfolyam videó, illetve audio blokkjaira, így az MPEG szállítási adatfolyam könnyen átalakítható MPEG program adatfolyammá.

9. A találmány részletes ismertetése

9.1 A kódoló kialakítása

Az alábbiakban a találmány szerint adatrögzítő berendezés kódolóját mutatjuk be egy olyan példán keresztül, amelynél az AV hemenetet saját kódolással alakítjuk át MPEG szállítási adatfolyammá.

A találmány szerinti adatrögzítő berendezés kódolójának felépítése a 21. ábrán látható. A 21. ábrán látható kódoló videó, audio és képkioitási Időközt (VBi) meghatározó jelet fogad és azokat szállítási adatfolyammá kódolja át,

A kódoló az alábbi üzemmódokban működhet: DVD Videó szabvánnyal kompatíbilis üzemmód, DVD Videó adatrögzítés szabvánnyal kompatibilis üzemmód, valamint normál üzemmód. Ha a berendezés DVD Videó kompatibilis üzemmódban * *·<

» ♦ >

működik, a kódoló olyan MPEG szállítási adatfolyamot állít elő, amely könnyen átalakítható az alább ismertetett eljárással a DVD Videó szabvány szerinti adatfolyammá. Ha a berendezés DVD Videó adatrögzítés szabvánnyal kompatíbilis üzemmódban működik, akkor a kódoló olyan MPEG szállítási adatfolyamot állít ele, amely az említett eljárással könnyen átalakítható DVD Videó adatrögzítés (DVD VR) szabvány szerinti adatfolyammá. Ha a berendezés normál üzemmódban működik, akkor a kódoló olyan MPEG szállítási adatfolyamot állít elő, amelynek speciális attribútumai vannak. Amikor a berendezés normál üzemmódban végez adatrögzítést, elfogadható a DVD szabvány által definiált eljárásoktól eltérő audio kódolási eljárások alkalmazása Is, és a videó kódolási eljárásoknál alkalmazott tolerancia értékek, például a GOP hosszúság, kívül eshet a DVD szabványok által definiált értékhatárokon.

9.2 Saját kódolású MPEG szállítási

Az alábbiakban a találmány szerinti adatrögzítő berendezés által előállított, sajáíkódolásű MPEG szállítási adatfolyam formátumának egyik lehetséges változatát ismertetjük, melynek során kiemeljük a normái MPEG szállítási adatfolyam (SESF) és az MPEG program adatfolyammá könnyen átalakítható, előre meghatározott formátumú MPEG szállítási adatfolyam (előre meghatározott formátumú SESF) közötti különbséget.

Az alábbi példában mindkét típusú MPEG szállítási adatfolyam tartalmaz olyan Információt, amely az adatfolyam kódolási feltételeit iga le egy attribútum információkat tartalmazó VOBI információban. A kódolási feltételeket leíró, a management információban lévő információ Ilyen, vagyis az adatfolyamon kívül történő eltárolása révén gyorsan, az adatfolyam analizálása nélkül meghatározható, hogy az adatfolyam egyszerűen átalakítható-e DVD videó vagy DVD VR formátummá. Az adatfolyam kódolási tulajdonságaira vonatkozó információ eltárolható a Tip csomagban, melyet később ismertetünk.

Az adatfolyam kódolására vonatkozó jellemzők egy 2 bites „encode^condition” jelző bitben vannak eltárolva. A jelzcbit értékel az alábbiak lehetnek;

00b; normál MPEG szállítási adatfolyam (SESF)

ϊ.

« *

01b; MPEG szállítási adatfolyam, amely könnyen átalakítható DVD VR formátumú adatfolyammá (előre meghatározott formátumú SESF)

1Öb: foglalt

11b: MPEG szállítás! adatfolyam, amely könnyen átalakítható DVD Videó formátumú adatfolyammá (előre meghatározott formátumú SESF).

Az, hogy egy adatfolyam könnyen átaíakithatö-e DVD Videó vagy DVD VR adatfolyam formátumra, könnyen meghatározható a VOB1 információ „eneode_eonditlon^!> mezőjének kiolvasásával. Megjegyezzük, hogy a „könnyen konvertálható” kifejezés alatt az alábbi bemutatásra kerülő eljárással végrehajtható konvertálást értjük.

9,3 Előre meghatározott SESF adatfolyam-formátum

Az előre meghatározott SESF szállítási adatfolyam szerkezete az 55. ábrán látható. Egy előre meghatározott formátumú SESF adatfolyam számos SESF blokkot tartalmaz. Az SESF blokk egy később részletesen bemutatásra kerülő Tip csomaggal kezdődik és meghatározott számú multiplexelési egységet tartalmaz. Mindegyik SESF blokk megjelenítési idöcímkéje (PTS) és a Tip csomag cím információja egy cimtérkép alapján áll összefüggésben egymással. Amint később világossá válik, a TS2PS átalakításnál minden egyes SESF blokkra vonatkozóan egy konverziós folyamatot hajtunk végre,

A 20. ábrán egy SESF blokkban lévő csomagok és az MPEG program adatfolyam blokkjai közötti összefüggés látható. Amint a 20. ábrán látható, egy szállítási adatfolyam-csomag, melyet a továbbiakban Tip csomagnak nevezünk, specifikus információt tárol az adatfolyamra vonatkozóan. Ez az Információ be van szúrva egy előre meghatározott formátumú SESF adatfolyamba. A Tip csomagok egy előre megbatározott formátumú SESF adatfolyamba vannak beágyazva. A Tip csomagokat az alábbiakban a 23-29. ábrák segítségével ismertetjük.

A 23. ábrán egy Tip csomag teljes szerkezete látható. Amint az ábrán látható, mindegyik Tip csomag tartalmaz egy olyan BataJD azonosítót, amely a csomagot Tip csomagként azonosítja, egy, a DVD VR DCÍ__CC1 mezőjének megfelelő, megjeíenífésvezérlésre és másolásvezédésre vonatkozó információt tartalmazó •í«

-41 displayjsné^copyjnío mezöt, az adatfolyam kódolására vonatkozó információt tároló encodejnfo mezőt, valamint a gyártó által megadott és a gyártóra jellemző adatot tároló MakersPrivateData mezőt.

Amint a 23. és 24. ábrán látható, a később bemutatásra kerülő SCR számításhoz szükséges POR érték a Tsp csomag adaptációs mezőjében van eltárolva. Ez az adaptációs mező egy rögzített hosszúságú mező, és lehetővé teszi a Tsp csomagban lévő különböző információkhoz való hozzáférést egy rögzített cím felhasználásával.

A 25. ábrán a DataJD mező szerkezete látható. A DataJD mező a csomagot Tip csomagként azonosító Data_ldentiűer mezőt tartalmaz, A Datajdentifier mező 3 bájt hosszúságú és a „0x544950” értéket tartalmazza, amely a „TIP” karaktersorozat ASCII kódja. A lejátszási meghajtó dekódolója a Tip csomagokat ezen mezőben tárolt érték kiolvasásával azonosítja.

A 28, ábra a dispiay_and_oopyjnfo mező szerkezetét szemlélteti. Az előre meghatározott formátumú SESF adatfolyamnak a DVD VR formátumú adatfolyammá történő átalakításakor az RDI blokkok előállítását elősegítjük oly módon, hogy a DVD VR szabványban definiált RDI egység DC1__CCI mezőjében eltároljál azonos szerkezetet és információt írunk a díspíayjand_copyjnfo mezőbe. Megjegyezzük, hogy a DVD VR szabvány DCfoCCI mezőjével kapcsolatos részletek megtalálhatók a „DVD specifikáció: Az üjraírhatő/újrarögzíthetö lemez, 3. rész, Videó adatrögzítés” dokumentumban, valamint a 3P~3,162,044 sz. japán szabadalmi leírásban. Bár egyes mezők nevei eltérhetnek az említett dokumentumokban alkalmazott elnevezésektől, a mezők definíciói azonosak azokéval, és így lehetővé teszik a DVD VR formátumra történő közvetlen átalakítást.

A 27. ábra az encodejnfo mező szerkezetét mutatja. A videojesoiutíon mező a Tip csomagot követő videó adatfolyam felbontását adja meg. Az enoodejnfo mező értékel az alábbiak lehetnek:

0000b: 720x480 (NTSC), 720x576 (PÁL)

0001b: 704x480 (NTSC), 704x576 (PÁL)

0010b: 352x480 (NTSC), 352x578 (PÁL)

0011b: 352x240 (NTSC), 352x288 (FAL)

0100b: 544x480 (NTSC), 544x576 (PÁL)

X #

♦ *** * * ·* * ♦ ·*** '♦ X < «βί>

0101b: 480x480 (NTSC), 480x578

A DVD VR formátum lehetővé teszi a felbontás megváltoztatását egyetlen folytonos adatrögzítés alatt is. A különböző felbontású adatfolyamokat különböző videó objektumokban kezeljük és a felvevő által végrehajtott lejátszás során biztosítjuk az adatfolyamok varratmentes összekapcsolását. Ha a felbontás az előre meghatározott formátumú SESF adatfolyam rögzítése során változik, ezt a video_resoiution mezőt használjuk a DVD VR formátumra történő átalakításkor annak a pontnak az azonosítására, amelytől kezdve a videó objektum felbontását meg kell változtatni.

Az adatfolyamon belül a felbontás megváltoztatása nem megengedett az olyan előre meghatározott formátumú SESF adatfolyamban, amely a DVD Videó formátumra történő átalakítás megkönnyítése céljából van rögzítve (encode^condifion ~ 11b),

Az encode.eondition mező ugyanazt az információt tartalmazza, mint ami a VÖBI információban van. Ez az információ nemcsak az adatfolyam management információban van eltárolva, hanem ez adatfolyamba is be van ágyazva. Ennek oka ez, hogy így az adatfolyamot fogadó adatrögzítő berendezés a Tip csomag encode...coodifion mezőjének kiolvasásával még ekkor is egyszerűen hogy az adatfolyam könnyen átalakítható-e DVD formátumra, ha ez adatfolyamot egy digitális interfészen, például az IEEE 1394 szabvány szerinti interfészen keresztül másoljuk át. Az adatrögzítő meghatározhatja legalább e beérkező adatfolyamban bármely Tip csomagja és az azt követő Tip csomag közötti elemi adatfolyamok (vagyis az SESF blokk) kódolási tulajdonságait.

A DVD VR szabvány VOBU.. S.. PTívl mezőjét az FVFPST mezőben tároljuk el. Ily módon kiküszöböljük azt, hogy e Tip csomagot követő, kódolt videó adatfolyamot analizálni kelljen az első bemutatott videó mező lejátszási Idejének kiszámításához, amikor egy előre megbatározott formátumú SESF adatfolyamot DVD Videó vagy

Az megjelenítési 1 mező tartalmaz egy 32 bites részt, amely a videó mező 30 kHz felbontással adja meg, és egy további 18 bites részt, amely a 32 bites résszel együtt már 27 MHz felbontással képes a megjelenítési időt megadni.

A 28. ábra a MakersPnvateQata szerkezetét szemlélteti. Amint az ábrán látható, a MakersPrtvateData mező tartalmaz egy makerJD mezőt, amely azt a gyártót azonosítja, amely az előre meghatározott formátumú SESF adatfolyamot előállította, továbbá egy makerjmvate dala mezőt, amely a gyártó által megadott további specifikus információkat tartalmaz.

A 2SA és 29B ábrán a Tlp csomag FID azonosítóját és az adatfolyam típusát megadó streamjype értékekre látható példa. Mivel mind a PID, mind a stream Jype értékek foglaltak az MPEG és más szabványok révén, a felhasznált értékeket úgy választjuk meg, hogy ne ütközzenek ezekkel a foglalt értékekkel és az MPEG szabványon kívül eső privát adatokat adjanak meg.

Nyilvánvaló, hogy különböző adatfolyam-attribútumok kerülnek kiolvasásra és az előre meghatározott formátumú SESF adatfolyam Tlp csomagjaiban eltárolásra. A továbbiakban azt ismertetjük részletesen, hogy egy DVD formátumra történő átalakítás során hogyan használjuk a fent említett mezőket.

9.4 A rendszerkódolás jellemzői

Az alábbiakban az előre meghatározott formátumú SESF adatfolyam rendszerkódolási jellemzőit ismertetjük. Szükségesnek tartjuk megjegyezni, hogy a rendszerkódolási jellemzők nem alkalmazhatók olyan SESF adatfolyam esetén, amelynél az encode_oondifíon mező nem a „01b vagy a „11b értékre van állítva, vagyis olyan SESF adatfolyamokra, amelyek nem előre meghatározott formátumú SESF adatfolyamok.

Egy előre meghatározott formátumú SESF adatfolyam elemi adatfolyamait tároló minden egyes szállítási adatfolyam-csomagnak van egy adatok meiíípíexelésére szolgáló egysége, egy ún, multiplexelési egysége, amely a DVD formátumnak megfelelő 2 kB-os blokkokból álló adatokat tartalmaz.

Az 57A és 57B ábrák segítségével azt mutatjuk be, hogy miért alkalmazunk ilyen multiplexelési egységeket. Az 57A ábrán egy formátumra vonatkozó korlátozás nélküli MPEG szállítási adatfolyamnak MPEG program adatfolyammá történő

- 44 ***A VV ♦ ♦

átaíakítása látható. Az MPEG szállítási adatfolyamnak MPEG program adatfolyammá történő átalakításához az MPEG szállítási adatfolyam muitíplexelési egységeit jelentő szállítási adatfolyam-csomagok {videó csomagok és audio csomagok) muiíiplexeíési sorrendjét úgy keli megváltoztatni, hogy az MPEG program adatfolyamban lévő minden egyes blokk csak egy adott típusú adatot tartalmazzon. Erre azért van szükség, mert az MPEG szállítási adatfolyam muitíplexelési egységeit alkotó 188 bájfos szállítási adatfolyam-csomagok kisebbek, mint az MPEG program adatfolyam muitíplexelési egységeit alkotó 2 kB~os blokkok. Ily módon az MPEG szállítási adatfolyamból csak a videó csomagokat kell kigyűjteni és MPEG program adatfolyam videó blokkjaivá (V_PCK) átalakítani, illetve csak az audio csomagokat kell kigyűjteni és MPEG program adatfolyam audio blokkjaivá (A__PCK) átalakítani. Ahogy az 57A ábrán látható, az MPEG szállítási adatfolyamban lévő audio adatokat eltároló audio csomagok (A-csomagok) multiplexeit sorozata megváltozik a konvertált MPEG program adatfolyamban, és az adatfolyam végén lévő A_PCK#1 audio blokkban kerülnek eltárolásra.

Az 57B ábra egy előre meghatározott formátumú MPEG szállítási adatfolyam MPEG program adatfolyamra történő konvertálását szemlélteti. Ennél a formátumnál 11 egymást kővető szállítási adatfolyam-csomagot egyetlen muitíplexelési egységként kezelünk. Az egy mukipfexelésí egységben eltárolt összes adatmennyiséget úgy határozzuk meg, hogy az ne haladja meg az egy blokkban eltárolt adatmennyiséget. Szükségesnek tartjuk megjegyezni, hogy az itt említett adatmennyiség (vagy adafméref) nem tartalmazza a blokk vagy csomag fejrészét, vagyis csak a videó vagy audio adatokat jelenti. Ezenkívül az egy muitíplexelési egységként kezelt 11 egymást követő szállítási adatfolyam-csomag mindegyike azonos típusú adatot, videó vagy audio adatot tartalmaz.

Nyilvánvaló, hogy a fent említett multipiéxelési egységek alkalmazása révén szükségtelenné válik az MPEG szállítási adatfolyam muitíplexelési egységeit alkotó szállítási adatfolyam-csomagok muitíplexelési sorrendjének megváltoztatása, amikor egy előre megahatározott formátumú MPEG szállítási adatfolyamot MPEG program adatfolyamra konvertálunk át.

Amint a 20. ábrán látható, az egy muitíplexelési egységen belül eltárolt szállítási adatfolyam-csomagok mindegyike csak egy adott típusú elemi adatfolyamot * Λ «βΦ * tartalmaz, vagyis a különböző típusú elemi adatfolyamokat tartalmazó szállítási adatfolyam-csomagok nem ugyanabban a multiplexelési egységben vannak eltárolva. Szükségesnek tartjuk megjegyezni azt is, hogy egy multiplexelési egység az adatfolyam utolsó részét eltaroló multiplexelési egység) esetén lehet egy ún. null csomag eltárolására, és a null csomagnak a multiplexelési egységhez történő hozzáadása emiatt nincs megtiltva. A null csomag alkalmazása amiatt is szükséges, hogy tisztázzuk a mulfiplexelési egység és a blokkok közötti viszonyt.

Egy mulfiplexelési egység így 11 egymást követő szállítási adatfolyamcsomagot tartalmaz, és az egyes mulfiplexelési egységekben lévő elemi adatfolyamok egésze (az adatmező adatai) egyetlen megfelelő blokkban kerülnek eltárolásra, Hasonló korlátozások vonatkoznak a blokkokra is.

A PES csomag fejrészét tároló szállítási adatfolyam-csomag a multiplexelési egység első szállítási adatfolyam csomagja. Ez az összefüggés kapcsolatot teremt a blokkban lévő csomag fejrésze (az MPEG szállítási adatfolyamban lévő PES csomag fejrésze) és az előre meghatározott formátumú SESF adatfolyamban lévő PES csomag fejrésze között, és lehetővé teszi, hogy az egymás után következő szállítási adatfolyam-csomagokat könnyen konvertáljuk egymás után.

Ha a videó adatfolyamot eltároló PES csomagok több multiplexelési egységre vannak felosztva, a PES csomag utolsó bájtját tartalmazó multiplexelési egység kivételével az összes multiplexelési egység 2024 bájt (184 x 11 = 2024) adatot tárol a szállítási adatfolyam-csomag adatmezőjében. Ily módon lehetővé válik az adatfolyam lehető leghatékonyabb továbbítása, és a szállítási adatfolyam-csomag egységek egymás utáni feldolgozása egyszerűbbé válik a TS2PS konverzió során. Ha az utolsó multiplexelési egységen kívül más multiplexelési egységben is megengedünk 2024 bájtnál kevesebb adatot, akkor nem lehet meghatározni menet közben az MPEG program adatfolyam egyes blokkjaiban lévő csomagok fejrészében eltárolt PES__packet_length mező értékét a mulfiplexelési egység első szállítási adatfolyam-csomagjának a TS2PS konverzió során történő konvertálásakor.

Az audio adatfolyamot tartalmazó PES csomag egy multiplexelési egység első szállítási adatfolyam-csomagjánál kezdődik és még ugyanabban a multiplexelési egységben ér véget. Ennek megértése könnyű, ha azt feltételezzük, hogy egy *’*í Ζ *·$ * ·« $ « adatfolyamot tartalmazó PES csomagot több muitipiexelési egységben tárolunk et Ha egy audio PES csomag több muitipiexelési egységre van felosztva, az audio adatfolyam belső szerkezetét nem szükséges elemezni, amikor a második és a további muitipiexelési egységeket MPEG program adatfolyam blokkokra konvertáljuk, mivel a PTS paramétert vagy az egy blokkon belüli audio keretek számát meg kell határozni a csomag fejrészének előállításához.

A muitipiexelési egységet ezért a fenti módon definiáljuk. Egy előre meghatározott formátumú SESF adatfolyamot előállító kódoló a muitipiexelési egység fent említett korlátozásait figyelembe véve hajtja végre a rendszerkődolásf.

9.5 Egy előre meghatározott formátumú SESF adatfolyamban lévő PES csomag fejrészére vonatkozó megszorítások

A továbbiakban egy előre meghatározott formátumú SESF adatfolyamban továbbított PES csomag fejrészében lévő mezők értékeire vonatkozó megszorításokat ismertetjük.

Amint a 30 ábrán látható, bizonyos PES csomagok fejrészében lévő mezők csak fix értékeket tárolhatnak. Ezáltal kiküszöbölhető a szükségfelen feldolgozás a DVD formátumra történő konvertálás során. „Szükségtelen feldolgozás” alatt azoknak a mezőknek a feldolgozását érjük, amelyek eltérnek a DVD formátum által meghatározott mezőktől. Ilyenek a hozzáadott vagy a törölt mezők. Magyarán, a PES csomag fejrészére vonatkozó iménti megszorítások célja azon mezők számának a minimalizálása, amelyek a TS2PS konverzió során a fejrészhez hozzáadódnak vagy azokból törölni kell.

Szükségesnek tartjuk megjegyezni, hogy a PES__packetJength mező értéke beállítható ő-ra egy MPEG szállítási adatfolyam videó adatait tartalmazó PES csomagban. A PES...packetjength mezőben eltárolt értéket ezért a TS2PS konverzió során a blokkban eltárolt csomagfejrész hosszúsága alapján és az adatmezőben lévő adatok bájtszáma alapján keli kiszámítani.

A PTS_DT8_flags mező azt adja meg, hogy a PTS vagy a DTS paraméter van-e definiálva. A PTS.JDTS .ííags mező értéke az előre meghatározott formátumú SESF adatfolyamban az alábbi szabályok szerint kerül beállításra

Ha a PES csomag videó adatfolyamot tárol, a PTS_DTS__flags értéke „Uh” az alábbi feltétetek valamiyikének teljesülése esetén;

1) egy keret-kódolású l-kép van eltárolva a PES csomagban;

2} egy keret-kódolású P-kép van eltárolva a PES csomagban;

3) egy pár mező-kódolásé l-kép van eltárolva a PES csomagban;

4) egy pár mező-kódolásé P-kép van eltárolva a PES csomagban; vagy

5) egy mező-kódolású I-képet egy mező-kódolású P-kép követ a PES csomagban.

Ha a PES csomag audio adatfolyamot tartalmaz, egy vagy több audio keret mindig a PES csomagban kezdődik, és a PTS_DTS_flags mező értéke „1öb”~re van állítva, illetve „11b”, ha a DTS van definiálva.

A PES_extension__flag mezőre és a PES_header_datajength mezőre vonatkozóan szintén vannak megszorítások annak érdekében, hogy lehetővé tegyük a TS2PS konverzió során a szekvenciális feldolgozást szállítási adatfolyam-csomag egységenként Ezeket a megszorításokat a 31, ábrán látható táblázat tartalmazza.

Amint a 31. ábrán látható, a mezőértékek az elemi adatfolyam típusának, a PES csomag helyének és az encode_condition mező értékének megfelelően vannak

A 31, ábrán látható Ví változó a PES csomagban lévő PTS mező és DTS mező bájtban kifejezett hosszúságának összege. Ez azt jelenti, hogy ha a PTS„DTS_flags = 00b, akkor VI ~ 0; ha a PTS_DTS_fiags ~ 10b, akkor V1 = 4; ha a PTS_DTSJtegs ~ 11b, akkor V1 ~ 10.

Ez a megszorítás azért szükséges, hogy a DVD Videó vagy DVD VR formátumra történő konvertáláskor lehetővé tegyük a szállítási adatfolyamcsomagonként történő szekvenciális feldolgozást a blokkokat kompliáiása helyett, amit az egyes blokkokban lévő adatmezők hosszúságainak meghatározását kővetően kellene végrehajtani

A PES csomag fejrészét ezért a fent említett módon definiáljuk. Egy előre meghatározott formátumé SESF adatfolyamot előállító kódoló a rendszerkődolást a fent említett megszorítások figyelembevételével hajija végre.

-48 ~

9.8 A Típ csomag beszúrás? időközére vonatkozó megszorít

Az alá

***V ·»< 4* ♦ * * * « » » * * $ # ** « ««

Típ csomagoknak egy előre meghatározott formátumú SESF csomag ATS (ATS1) paramétere által megadott dekődöíő-bemeneti és a Típ csomag után a deködoíóba elsőként beérkező, videó vagy audio adatfolyamot tartalmazó Típ csomag ATS (ATS2) paramétere által megadott dekódolő-bemenetí Időpontja között az alábbi összefüggésnek kell teljesülnie;

ATS1 + T <- ATS2, ahol T egy program adatfolyam-blokk minimális átviteli ideje. A T minimális átviteli idő az a legrövidebb Idő, amely a deködoíóba által fogadott program adatfolyam-blokk kezdete és vége között eltelik. Magyarán, a fenti képlet azt jelenti, hogy az egyes szállítás? adatfolyam-csomagok ATS Intervallumának nagyobbnak kell lenni, mint annak az intervallumnak, amely lehetővé teszi legalább a konvertált program t A T értékét az alábbi képlet alapján számítjuk ki;

T ~ (PS^5ack_size*8*system_clock_frequency) /PSrate, ahol a PS_pack_síze a TS2PS konverzió során előállított MPEG program adatfolyam-blokk hosszúsága bájtban kifejezve, a systeny. clockjrequency paraméter az MPEG program adatfolyam dekódoíójában lévő referencia óra frekvenciája, a PSrate paraméter pedig a TS2PS konverzió által előállított MPEG program adatfolyam multlplexeiési sebessége.

megfelelően a PS_pack...síze, a system_olock_frequency az alábbiak;

A DVD és a PSrate

PS_pack_síze systernjslockjrequency = 27 MHz

Az ATS 1 és A' értéke között így az alábbi összefüggés ATS1 + 43885.714... «= ÁTS2, ik;

vagyis az ATS2 minimális értéke ATS1 * 43886 = ATS2,

Az alább bemutatásra kerülő TS2FS konverzió a Típ csomagot 2 kB-os

NVPCK csomagokra konvertálja DVD Videó formátumra történő átalakítás esetén, * •'♦V Λ φ >$· « * * ♦ « Μ > * φ > X ** « * ΊΜβ ♦: <

— 49 illetve RDIJPCK csomagokra DVD VR formátumra történő átalakítás esetén, és amennyiben a fenti egyenlőtlenség nem teljesül, akkor a következő elemi adatfolyam továbbítása hamarabb megkezdődik és meghaladhatja a DVD rendszer 10,08 IWsos átviteli sebességét

Szükségesnek tartjuk megjegyezni, hogy ugyanaz a hatás érhető el akkor is, ha az AV adatok átvitele között a fent említett időközt az egyes Típ csomagok előtt és után szúrjuk be. A találmány nem korlátozódik az AV adatokat nem továbbító időköznek a Típ csomagok átvitele utáni beszúrására.

Két egymást követő Tip csomag közé, vagyis egy SESF blokkba egész számú GOP-t illesztünk, ^gy egy Tip csomagtól a következő Tip csomagot közvetlenül megelőző szállítási adatfolyam-csomagig terjedő adatok megfelelnek a DVD formátum szerinti VOBU-nak, és így az előre meghatározott formátumú SESF adatfolyamban is megvalósítunk DVD formátumú VOBU-t. A DVD formátum, például DVD VR formátum szerinti VOBU-nak egész számú GOP-t keli tartalmaznia.

A lejátszási Időt alapul véve egy Tip csomag és a következő Típ csomag közötti időnek 0,4 másodpercnek vagy annál hosszabbnak, de legfeljebb 1,0 másodpercnek kell lennie. Az utolsó Tip csomagot követő adatmező adataihoz tartozó lejátszási időnek legalább 0,4 másodpercnek, de legfeljebb 1,2 másodpercnek kell lenni, ha az encode__condifen = 11b (DVD Videó vagy DVD VR üzemmód), illetve legfeljebb 1,0 másodpercnek kell lennie, ha az encodejxsnditton 01b (DVD VR üzemmód). Ennek oka az, hogy a Tip csomag jelenti egy VOBU kezdetét, továbbá az, hogy illeszkedjünk mindegyik DVD formátumhoz.

Az idő-cím konverzióhoz tartozó hozzáférési térkép egyértelműen mutat minden egyes Tip csomagra. így a TS2PS konverzió azonnal megkezdődhet a DVD formátumú VOBU egységenként

Szükségesnek tartjuk megjegyezni, hogy a hozzáférési térképnek nem szükséges minden egyes Tip csomagra rámutatnia. Egy előre meghatározott formátumú SESF adatfolyamban lévő utolsó Típ csomagot követő AV adatok például eltérő módon vannak kezelve a többi Tip csomagtól, mivel az a többi Tip csomagtól például az eltérő lejátszási idő, a kővetkező Tip csomag elmaradása, stb. miatt különbözik. A hozzáférési térképben az utolsó Tip csomag regisztrálásának elmaradása így nem okoz problémát a lejátszás vagy a konverzió során, és az * «η* * Λ ί « _Α' « V * * * ί -> Α· « e * * * « **»* -ί * ** 4 W « / «?

hardverének a tervezésekor kivételként kezelhető. Az is ap olyan külső tényezők miatt nem mutat rá mindegyik ép méretére vonatkozó korlátozás, vonatkozó megszorítások a fent említett előre meghatározott formátumú SESF adatfolyamot a fent említett megszorítások figyelembevételével lehet, hogy a hozzáférési Tip csomagra, mint példát:

A Tip csórna módon vannak definiálva, előállító kódoló a

9.7 A dekódoló vezérlésével kapcsolatos:

az előre

Az a dekódolójának vezérlésére, különösen a formátumú SESF adatfolyam vonatkozó korlátozásokat

Az MPEG szállítási adatfolyam standard dekódoló modellje (T_STD) által meghatározott szabványok kielégítése céljából előre meghatározott formátumú SESF adatfolyamot kell előállítani. Ez lehetővé teszi például, hogy egy TJSTD modellhez illeszkedő dekódolóvai rendelkező STB egység az előre

SESF az adatfolyam típusa kompatibilis.

Az MPEG szállítási adatfolyam standard dekódoló modellje (TJ3TD) és az MPEG program adatfolyam standard dekódoló modellje (P__STD) lényegében azonos működésű és feldolgozási kapacitású, azonban különböznek a dekődolöba továbbított audio adatfolyam bemeneti sebességében, Amint a 18. ábrán látható, az AAC (Advanced Audio Godíng) kódolást kivéve az audio dekódoló előtt elhelyezkedő szállítási pufferböl az audio pufferbe történő adattovábbítás átviteli sebessége a T STD modellben fix 2 Mb/s. A P_STD modell azonban az egyes adatfolyamokat a dekődolóba a rendszer sebességével tudja továbbítani, ami DVD esetén 10,08 Mb/s.

Ez azt jelenti, hogy az előre meghatározott formátumú SESF adatfolyam és a DVD formátumú adatfolyam esetén nem alkalmazható ugyanaz a puffé rkezelési módszer.

Bár az előre meghatározott formátumú SESF adatfolyam és a DVD formátumú adatfolyam esetén általában nem alkalmazható ugyanaz a pofferkezelésí módszer, rendkívül gyors és egyszerű konverzió érhető el, amikor egy előre

«.i *

<->»<$ « >*· meghatározott formátumú SESF adatfolyamot DVD formátumú adatfolyammá alakítunk át a rendszerkődoíásí folyamat Ismétlése nélkül, feltéve, hogy a konvertált blokkok dekodolóba érkezésének kezdő időpontját megadó SCR (System Clock Referenoe) paraméter kiszámítható az egyes szállítási adatfolyam-csomagokhoz hozzárendelt ATS felhasználásával. Az SCR értékének az ATS felhasználásával történő kiszámítását az alábbiakban Ismertetjük részletesen.

A találmány szerint!, előre meghatározott formátumú SESF adatfolyamot előkódolnl kell annak érdekében, hogy illeszkedjen a TJ3TD modellhez, illetve, hogy az alábbiakban bemutatásra kerülő konverziós folyamat által előállított MPEG program adatfolyam illeszkedjen a PJBTD modellhez.

Az előre meghatározott formátumú SESF adatfolyam olyan adatfolyam, amely MPEG szállítás! adatfolyammá van kódolva úgy, hogy illeszkedik a P_STD modellhez is, amennyiben az alább bemutatásra kerülő folyamattal lett konvertálva MPEG program adatfolyammá.

A továbbiakban az előre meghatározott formátumú SESF adatfolyamhoz kapcsolódó pufferkezelésre vonatkozó korlátozásokat ismertetjük. Szükségesnek tartjuk megjegyezni, hogy az SESF adatfolyam ügy van kódolva, hogy a fenti korlátozások ismerete nélkül ís Illeszkedjen a TJ3TD modellhez.

A továbbiakban a TJSTÖ és a FJ3TD modellekhez nem illeszkedő MPEG szállítási adatfolyamra és MPEG program adatfolyamra mutatunk be példát.

Először a 32. ábra segítségével olyan MPEG szállítási adatfolyamot mutatunk be, amely sajátkódolással van kódolva úgy, hogy lehetővé tegye egy MPEG program adatfolyamra történő átalakítást, azonban ne illeszkedjen a 7J3TD modellhez.

A TS1 adatfolyam olyan MPEG szállítási adatfolyam, amely a T_STD modellnek megfelelően rendszerkódolással van kódolva. A TS2 adatfolyam olyan MPEG szállítási adatfolyam, amely nem illeszkedik a T_STD modellhez.

A TS2 adatfolyam ATS[47j~ATS{57j értékei úgy vannak beállítva, hogy meghaladják az MPEG szállítási adatfolyam megengedhető audio adatátviteli sebességét. Ennek következtében az audio szállítási puffer (lásd a 18. ábrát) túlcsordul, így nem teljesít! a TJSTÖ modellre vonatkozó előírásokat. A TS1 adatfolyam ATS[47]~ATS[57j értékel azonban az MPEG szállítási adatfolyamban megengedett audio adatátviteli sebességekre vannak beállítva. Ez az adatfolyam így

-52™ *«»« .Λ ·» -X A

‘/Íj **<

helyesen konvertálható a P....STD modellhez Illeszkedő MPEG program adatfolyammá (PS1) a később bemutatásra kerülő SOR konverziós algoritmus felhasználásával. A TS2 adatfolyam sem illeszkedik a TJ3TD modellhez, azonban a később bemutatásra kerülő SCR konverziós algoritmus felhasználásával átalakítható PS1 adatfolyammá. Annak érdekében, hogy a TS2 adatfolyamot a TJ3TD modellhez Illeszkedő MPEG szállítási adatfolyammá tudjuk átalakítani, az ATSj4?]~ATS{57J értékek által specifikált audio csomagok átviteli időközeit ügy kell szétosztani, hogy a szállítási puffer túlcsordulása ne következzen be.

A továbbiakban a 33A és 338 ábra segítségével olyan példát mutatunk be, amelynél az MPEG szállítási adatfolyam Illeszkedik a TJ3TD modellhez, az MPEG szállítási adatfolyamból átalakított MPEG program adatfolyam azonban nem illeszkedik a PJSTD modellhez. A TS3 adatfolyam egy MPEG szállítási adatfolyam, a PSS adatfolyam pedig egy, a TS3 MPEG szállítási adatfolyamból átalakított MPEG program adatfolyam. A 338 ábrán a videó adafpuffer állapotának változása látható a két adatfolyam dekódolása esetén, A PES#1 képdekódolás időpontja SCR [2], míg a PES#2 képdekődoiás időpontja az SCR (4j és SCR [5] közé esik.

Amint a 33B ábrán látható, a TS3 szállítási adatfolyamban a PES#1 és a PES#2 adatátvitele véget ér a PES# 1 -ben és PES#2~ben lévő képi adatok dekódolásának kezdetekor. A PS3 program adatfolyamban azonban a V__PCK#1 adatot sikeresen továbbítjuk a dekődolőba a PES#Í részére, azonban a PES#2 dekódolásakor a V_PCK#4 adatot nem továbbítjuk időben, és a puffer alulcsordul, mivel a dekódolás azelőtt kezdődik meg, hogy az adatátvitel véget ért volna. A program adatfolyam ezért nem illeszkedik a P....S7D modellhez. Ennek elkerülése céljából, valamint annak biztosítása érdekében, hogy a PES#2 átvitele időben befejeződjön, az MPEG szállítási adatfolyamban lévő egyes szállítási adatfolyamcsomagok V PCK#2-V_PCK#4 csomagokká átalakított ATS csomagjai (ATS[14j, ATS[25j, ATS(3Sj) eltolhatok a PES#2 képi adatok dekódolása előtti Időpontra.

Mivel mind a kódolt MPEG szállítási adatfolyamhoz, mind pedig az abból konvertált MPEG program adatfolyamhoz szükség van a puffer túlcsordulását, illetve alulcsordulását megakadályozó pufferkezeiésre, az MPEG szállítási adatfolyam kódolásakor előre keli látni mind a kódolt MPEG szállítási adatfolyamot, mind pedig az abból konvertált MPEG program adatfolyamot.

««»« «4 ss

Az 58A és 58B ábrán az MPEG szállítási adatfolyam es az előre kiszámított MPEG program adatfolyam pufferkezelését Ismertetjük abban az esetben, amikor a konverzió előtti MPEG szállítási adatfolyam és a konverzió utáni MPEG program adatfolyam azonos bitsebességgel rendelkezik. Az előre kiszámított MPEG program adatfolyam pufferkezelésérői ennél a kiviteli alaknál azt feltételezzük, hogy megegyezik a kódolt MPEG szállítási adatfolyam pufferkezelésévek Ennek oka az, hogy az MPEG program adatfolyammá konvertált MPEG szállítási adatfolyam muitíplexelési egységeiben beállított idöcímke információ (calculated_PCR) és a konverzió utáni MPEG program adatfolyam-blokkokban beállított időcímke információ megegyezik.

Az 58A ábrán olyan példa látható, amelynél puffer-alulcsordulás következik be. A kódolt MPEG szállítási adatfolyam adatátvitele nem fejeződik be a K1 célídöpontig, vagyis a DTS Időzítésig. Ezért azt feltételezzük, hogy a konvertált MPEG program adatfolyam adatátvitele szintén nem fejeződik be Időben.

A pufféi fent említett ablcsordulásának kiküszöbölése érdekében az MPEG szállítási adatfolyam idöcímke információját úgy keli beállítani, hogy az átvitel befejeződjön a K1 Időpontra, vagyis a DTS időzítésre, ahogy ez az SSB ábrán látható. Ehhez azt feltételezzük, hogy a konvertált MPEG program adatfolyam esetén szintén nem következik be a puffer alulcsordulása.

Az 59A és 598 ábrán az MPEG szállítási adatfolyam és az előre kiszámított MPEG program adatfolyam pufferkezelését ismertetjük abban az esetben, amikor a konvertálás alatt álló MPEG szállítási adatfolyam bitsebessége nagyobb, mint az eredményül kapott MPEG program adatfolyamé. Az előre kiszámított MPEG program adatfolyam pufferkezelésérői ebben az esetben nem feltételezhető, hogy megegyezik a kódolt MPEG szállítási adatfolyam pufferkezelésévek Az MPEG program adatfolyam számára ezért külön pufferkezelésre van szükség.

Az MPEG program adatfolyam feldolgozásakor csak az 59A ábrán látható esetben következik be a puffer alulcsordulása. A kódolt MPEG szállítási adatfolyam adatátvitele véget ér a KI célídöpontig (DTS időzítés), így a puffer alulcsordulása nem következik be. A konvertált MPEG program adatfolyam adatátvitele azonban nem ér véget a Ki célidőpontig (DTS időzítés), így a puffer alulcsordul. Emiatt az adatátvitelt be kell fejezni a K1 célídöpontig, s DTS időzítésig, annak érdekében, κ«

Ha az

hogy az MPEG program adatfolyam esetén ís kiküszöböljük a puffér aluicsoröulását PEG program adatfolyam a DVD szabvány által használt a rendszer adatátviteli sebessége nem növelhető. Ezért épsebesség csökkentése szükséges, le kell csökkenteni az átviteli adatok teljes adatok egésze időben továbbítható legyen a

Az alábbiakban a program adatfolyam blokkjaiban lévő SCR értékek meghatározására szolgáló eljárást ismertetjük, amikor egy előre meghatározott formátumú SESF adatfolyam van program adatfolyammá alakítva. Szükségesnek tartjuk megjegyezni, hogy mivel az SCR~t csak akkor számítjuk ki, amikor új blokkok vannak előállítva, vagyis az SCR-t csak akkor kell kiszámítani, amikor a mukipíexeiés! egységben lévő első szállítási adatfolyam-csomagot konvertáljuk.

Először az SCR meghatározásának alapeívét ismertetjük. A SOA és 8ÖB ábrán két különböző esetet mutatunk be arra, hogy a konverzió utáni MPEG program adatfolyam blokkjaiban hogyan van beállítva az időcimke információ (SCR).

A 8ÖA ábrán olyan eset látható, amelynél az MPEG szállítási adatfolyam és az MPEG program adatfolyam bitsebessége megegyezik. Ilyenkor az MPEG szállítási adatfolyam megfelelő muttiplexeiési egységében beállított ídőcímke információ (caículated_PCR) értékével azonos érték van beállítva az MPEG program adatfolyam blokkjainak időcimke információjaként (SCR).

A SGB ábrán olyan eset látható, amelynél az MPEG szállítási adatfolyam átviteli sebessége nagyobb, mint az MPEG program adatfolyam átviteli sebessége. Ilyenkor a konverzió utáni program adatfolyamban lévő mindegyik blokk <V_PCK) a közvetlenül megelőző blokk pufferbemeneti feldolgozási idejét (i-1jVT) tároljuk el. Hogy az SCR értékét miért így álíítíuk be, azt az alábbié

Ha az SCRji] értéknek megfelelő multíplexeiési egység calculated__PCR(lj értéke a SOA ábrán bemutatott módon van beállítva, a közvetlenül megelőző blokk pufferbemeneti feldolgozási idejénél (SCRp-IRT) korábbi időpont lesz beállítva az SCR~ben. Ha az SCR erre az időzítésre van beállítva, az adatfolyam nem játszható le a jelenlegi DVD felvevőkkel, így ezt a helyzetet ki kell küszöbölni. Szükségesnek megjegyezni, hogy az MPEG szállítási adatfolyam bitsebessége nagyobbra van állítva, mint az MPEG program adatfolyamé, mivel a maximális adatátviteli sebesség audio adatok esetén kisebb, mint a videó adatok esetén.

A továbbiakban az SCR meghatározását ismertetjük részletesen.

Amint az 55. ábrán látható, az előre meghatározott formátumú SESF adatfolyamban egy SESF blokk egy Tip csomagot és multiplexelési egységet alkotó, előre meghatározott számú szállítási adatfolyam-csomagot tartalmaz, Mivel az adatfolyam a dekódoló SIC referencia idejével szinkron módon van továbbítva, az adatfolyam PCR csomagot tartalmaz az SIC referencia időpont alaphelyzetbe állítására.

Amint a 14. ábrán látható, mindegyik szállítási adatfolyam-csomaghoz hozzá van adva egy első időcímke információ (ATS), amely a dekódolőhoz történő továbbítás időpontját adja meg. Ennek az első Ídőcímke információnak a referencia időpontja eltér a dekódoló referencia időpontjától.

Ily módon a Tip csomag tartalmaz egy, a dekódoló referencia időpontjától függő második időcímke információt (PCRJip), valamint egy olyan első ídőcímke információt (ATSJíp), amely ugyanazon a referencia időponton alapúi, mint a szállítási adatfolyam-csomag. A Tip csomagra való hivatkozással a dekódoló ki tudja számítani az egyes szállítási adatfolyam-csomagok eiső ídőcímke információiból (ATS) a második időcimke információt (PCR),

Amint a 61. ábrán látható, az egyes szállítási adatfolyam-csomagoknak a multiplexelési egység fejrészében elhelyezkedő eiső időcimke információjából (ÁTSpj) számított második ídőcímke információ lesz az egyes muítiplexeíési egységek második ídőcímke információja, melyet a továbbiakban „calculated PCRjij” paraméternek nevezünk.

A szállítási adatfolyam-csomag PCR értékét (PCR(ij) például az alábbi egyenlet alapján számíthatjuk ki egy SESF blokkban lévő eiső Típ csomag PCR (PCRJip) és ATS (ÁTSJip) értékének, valamint a következő szállítási adatfolyamcsomag ATS (ATS(ij) értékének felhasználásával, ha az ATS érték átvitelét (oszloptúíesöfduiást) nem vesszük figyelembe:

PCR[ij PCRJip + (ATSjlj - ATSJíp)

-58Αζ első multipiexelési egység dekódcíóba történő beviteli időpontját a 81 ábrán látható esetben megadó caicutated_PCRf1] érték meghatározására például az alábbi képlet használható:

ealculated _.PCR(1 j = PCR[2j = RCRJip + (ATS[2| - ATSJip).

Mindegyik multipiexelési egység calcuíafed_PCR értékét hasonló módon számítjuk ki, miközben figyelembe vesszük az ATS oszloptülcsordulást.

A 34. ábrán a caicuiatedJPCR és az SCR közötti összefüggés látható, amikor egy előre meghatározott formátumú SESF adatfolyamot MPEG program adatfolyammá alakítunk át. Az 55. ábrán a blokk első része látható. Az adatfolyam kezdetétől az egyes multipiexelési egységek kezdetén lévő szállítási adatfolyamcsomagokig emelkedő sorrendben egymást követő ATS adatokat a 34. ábrán ATSfkj jelöléssel illettük. Hasonló jelölést alkalmaztunk a ealculated. PCR és az SCR adatok jelölésére is. Az egyes multipiexelési egységekben lévő első szállítási adatfolyamcsomagokhoz tartozó, a megjelenés sorrendjében számított PCR értékeket a 34. ábrán ealculafedJPCRpj (I ~ 1, 2, ...) adatok formájában tüntettük fel. A konvertált blokkok SCR adatát, hasonlóan az előbbiekhez, SCR[i] formában jelöltük.

Mint korábban említettük, a videó adatfolyam T_STD modell által megengedett maximális átviteli sebessége 15 Mb/s. A multiplexelö puffertől a videó pufferhez történő továbbítás adatátviteli sebessége nem haladhatja meg a 15 Mb/s sebességet az MP@ML esetén, és az audio adatfolyam bemeneti sebessége úgy van korlátozva, hogy a videó adatfolyam bemeneti sebességénél kisebb legyen, A szállítási puffertől az audio pufferhez továbbított adatok átviteli sebessége nem haladja meg a 2 Mb/s-ot, kivéve az AAC esetén, így a videó adatokat tartalmazó multipiexelési egységgel ellentétben az audio adatokat tartalmazó multipiexelési egység kis sebességgel kerül továbbításra. Ha a videó adatok átviteli sebességét a DVD formátum 8,8 Mb/s-os maximális átviteli sebességének közelébe kell emelni, akkor a videó adatokhoz tartozó szállítási adatcsomagokat a DVD átviteli sebességnél (10,08 Mb/s) nagyobb sebességgel kell továbbítani annak érdekében, hogy elegendő átviteli időt biztosítsunk az audio adatok számára, amelyek kisebb átviteli sebességgel továbbítódnak, emiatt azok továbbítása hosszabb ideig tart.

»χ :*♦ »* « ♦♦ * » » # ν « ·.« » * w ♦ » χ χ « <· 4 Λ ♦ ♦ ♦ *

X X ♦ * « «« X » * > >

Amint a 34. ábrából kitűnik, az előre meghatározott formátumú SESF adatfolyam és a DVD formátum átviteli ideje! eltérnek egymástól.

Egy mulfiplexelési egység első szállítási adatfolyam-csomagjának calculated_PCR dekódoióba történő beérkezési időpontja és az említett szállítási adatfolyam-csomagból konvertált blokkok SCR értéke között az alábbi összefüggésnek kell fennállnia:

SCRjl j = ealculated_PCRp}

SCRiil = max(SCR[i-1] + T, ca!culated„PCR(ij) (m 2, 3,,,.) oaloulated_PCRpj = PCRJip * ATS(íj - ATS ..íip + WA* BS)

T - PS_pack_size*8*system_clock freguency / PSrate, ahol a PCR__tip és az ATSJsp a konvertálás alatt álló multiplexelési egységet közvetlenül megelőző Tip csomag PCR értéke, illetve az ilyen Tip csomag ATS értéke; WA azt adja meg, hogy az i-edlk multiplexelési egységben lévő első szállítási adatfolyam-csomaghoz hozzárendelt ATS (ATS[ij) és az ATSjöp közötti ATS-nél hányszor következett be túlcsordulás. Az ATS érték tehát egy véges bitszáma érték, így korlátozott számú túlcsordulás adható csak meg. Az ilyen túlcsordulások bekövetkezésének számát a WA paraméterrel adjuk meg. BS az egy ATS túlcsordulásnak megfelelő adafméret A max(a,b) függvény az a és b érték közül a nagyobbat megadó függvény.

Az SCR[i] (í - 2, 3, ...) összefüggésben szereplő P$_pack_síze paraméter a TS2PS konverziós folyamat során előállított kimeneti MPEG program adatfolyamban szereplő blokk bájtban kifejezett hosszúsága; a sysfem_clook_frequency az MPEG program adatfolyam dekődolőjának referencia órájának frekvenciája; és a PSrate a TS2PS konverzió által előállított MPEG program adatfolyam mulfiplexelési sebessége. Az imént említett paraméterek értékei a következők:

PSj>ack_size - 2048 bájt system_clock ..freguency - 27 MHz PSrate -10,08 Mb/s.

Az első blokk után következő blokkok továbbítására két módszer lehetséges. Az egyik módszernél a blokkokat az előző blokk elküldési időpontját követően, az átviteli sebesség által meghatározott minimális átviteli idő kivárása után továbbítjuk, míg a másik módszernél a blokkokat az egyes blokkokban lévő első szállítási * fc V ♦ ”r

- 53 adatfolyam-csomag dekódoló-bemenetí időpontjában továbbítjuk. A blokk elküldése előtt minimális átviteli Időt kiváró módszert akkor választjuk, amikor a blokkokat azelőtt küldjük el, mielőtt a videó adatokat DVD formátumra alakítanánk át. Ha például a blokkokat a videó adatok DVD formátumra történő átalakítása előtti időpontban továbbítjuk, akkor az első módszert választjuk, vagyis a megelőző blokk elküldési időpontja után az átviteli sebesség által megbatározott minimális átviteli idő kivárását követően továbbítjuk a blokkokat.

A TS2PS konverzióval előállított program adatfolyamnak illeszkednie kell a fent említed P_STD modellhez, és az SCR értéke emiatt egy bizonyos értéktartományon belüli értékekre korlátozódik, így az előre meghatározott formátumú SESF adatfolyam minden egyes csomagjához hozzárendelt ATS értékeket a fenti ATS-SCR összefüggésnek megfelelően kell beállítani.

9,8 Az elemi adatfolyamra vonatkozó korlátozások

Az alábbiakban az előre meghatározott formátumú SESF adatfolyam elemi adatfolyamára vonatkozó korlátozásokat ismertetjük.

Mivel az elemi adatfolyamok újrakődolása rendkívül időigényes folyamat, csak az MPEG-2 Videó formátum megengedet a videó adatok számára, illetve az AC-3, az MPEG-1 audio és az LPCM formátumok megengedették az audio adatok számára.

Az előre meghatározott formátumú SESF adatfolyam figyelmen kívül hagyja az LPCM adatokat, így az elemi adatfolyam újrakődolása szükségtelen, és a pufferkezelés egyszerűbben elvégezhető. Az előre meghatározott formátumú SESF adatfolyam számára megengedett adatfolyamok így videó adatok esetén kizárólag az MPEG-2 videó formátumra, míg audio adatok esetén az AC-3 és az MPEG-1 audio formátumra korlátozódnak.

A 35. ábrán az elemi adatfolyam attribútumai láthatók abban az esetben, ha az enoode_condltion - „11b.

Mivel a 35. ábrán látható attribútumok úgy vannak beállítva, hogy az elemi adatfolyam szintjén kompatibilitást biztosítsanak a DVD Videó vagy a DVD VR szabvánnyal, az ábrán látható attribútum értékekkel rendelkező előre meghatározott

formátumú SESF adatfolyam (encode_condition = „11b”) nem teszi szükségessé az elemi adatfolyam újrakódolását a DVD Videó vagy DVD VR formátumokra történő konverzióhoz, ily módon nagysebességű konverzió válik lehetővé.

A 36. ábrán az elemi adatfolyam attribútumai láthatók abban az esetben, amikor az encode.oondltiton ~ „ölb”.

Mivel a 38. ábrán látható attribútumok úgy vannak beállítva, hogy az elemi adatfolyam szintjén kompatibilitást biztosítsanak a DVD VR szabvánnyal, az ilyen attribútum értékekkel rendelkező előre megbatározott formátumú SESF adatfolyam (encode__condltion = ,,Ö1b”) nem teszi szükségessé az elemi adatfolyam újrakódolását a DVD VR formátumra történő konverzióhoz, igy nagysebességű konverzió válik lehetővé.

a 35. és 38. ábrákhoz tartozó megjegyzéseket Ismertetjük.

1. megjegyzés: Az attribútum nem változhat meg egy VÖB-n belül.

2. megjegyzés: Az attribútum megváltozhat a Tlp csomagot kővető első elemi adatfolyamot eltároló szállítási adatfolyam-csomagban. Az attribútum csak az SESF blokkban lévő első videó vagy audio szállítási adatfolyam-csomagban változhat meg.

3. megjegyzés· A sequence_end_code mező nem szúrható be a sequence_headers mezők közé, ahol a horízontaLsize, a vertical_slze és az aspecf_rafiojnformafion megegyezik.

4. megjegyzés: Az attribútum megváltozhat egy VOB-on belül.

A fentiekben egy előre meghatározott formátumú SESF adatfolyam elemi adatfolyamaira vonatkozó megszorításokat ismertettük. Szükségesnek tartjuk megjegyezni, hogy a fent ismertetett kódolási feltételek alkalmazása révén a DVD formátumra történő gyors és egyszerű konverziót lehetővé tevő, előre meghatározott formátumú SESF adatfolyam állítható elő.

A 37. ábra AV adatc : tartalmazó szállítási adatfolyam-csomagokból (multiplexelési egységek) program adatfolyam-blokkokat előállító folyamat lépéseit bemutató folyamatábrát szemléltet.

Amint a 37. ábrán látható, egy AV adatokat tartalmazó, előre meghatározott formátumú SESF adatfolyam szállítási adatfolyam-csomagja AV adatokat tartalmazó kB-os Ml van konvertálva a feldolgozási egységként szereplő multiplexelési egység felhasználásával. Ezt a folyamatot az alábbiakban lépésről lépésre ismertetjük.

54200 lépés: Az előre megbatározott formátumú SESF adatfolyam konverziójának kezdőpontjáról kiolvasunk egy szállítási adatfolyam-csomagot.

54201 lépés: Meghatározzuk, hogy a kiolvasott szállítási adatfolyam-csomag tartalmaz-e AV adatokat, és hogy egy multiplexeiésl egység első szállítási adatfolyam-esomagja-e.

Azt, hogy a kiolvasott szállítási adatfolyam-csomag fartaímaz-e AV adatokat, a szállítási adatfolyam-csomag FID értékének vizsgálatával határozzuk meg, amely csomagot a PMT AV adatok eltárolására jelöl ki.

Ha a kővetkező szállítási adatfolyam-csomag egy Tip csomag, PSI/SI csomag vagy PCR csomag, az azt követő szállítási adatfolyam-csomagot, amely AV adatokat tartalmaz, úgy tekintjük, mint a multiplexelési egységben lévő első száilifásl adatfolyam-csomag. Mivel a konverzió kezdőpontjának egy Tip csomagot tekintünk, a multiplexelési egység kezdete észlelhető a szállítási adatfolyam-csomagok egymás utáni kiolvasásával. Ez azt jelenti, hogy az első szállítási adatfolyam-csomag, amely közvetlenül a Tip csomag után jön és AV adatokat tartalmaz, mindig egy multiplexelési egység kezdetét jelenti.

Ha az S4201 lépésben azt állapítjuk meg, hogy a szállítási adatfolyamcsomag nem egy multiplexeiésl egység kezdete, vagy ha a konverzió nem egy Tip csomagtól kezdődik, és a multiplexelési egység kezdete nem azonosítható, a vezérlés visszatér az S42ÖÖ lépésbe, és a folyamat a következő szállítási adatfolyam-csomag beolvasásával folytatódik.

Ha egy multiplexeiésl egység elejét megtaláltuk, a folyamat a következő S4202 lépéssel folytatódik.

Szükségesnek tartjuk megjegyezni, hogy bár a folyamatábrán nem látható, a fent ismertetett SOR konverziós eljárást alkalmazó konverzió nem alkalmazható még a multiplexelési egység elején lévő szállítási adatfolyam-csomag esetén sem, ha a Tip csomag helyét előzőleg nem határoztuk meg. Ekkor a konverzió azonban a Tlp csomag feldolgozása helyett folytatódhat a PCR csomag feldolgozásával.

54202 lépés: A multiplexelési egységben lévő első szállítási adatfolyamcsomaghoz hozzárendelt ATS felhasználásával kiszámítjuk az abból a csomagból r

konvertált MPEG program adatfolyam-blokkhoz tartozó dekódoló-bemeneti időt (SOR). Ezt az SCR értéket a fent ismertetett módon számítjuk ki. Miután az SCR értékét meghatároztuk, a 38. ábrán látható blokk fejrésze teljes lesz. Ennek oka az, hogy az SCR paramétert kivéve a blokk fejrészben csak fix értékek megengedettek.

S4203 lépés: Előállítjuk a csomag fejrészét,

A csomag fejrészét az előre meghatározott formátumú SESF adatfolyam PES csomag fejrésze alapján állítjuk elő. Az így kapott csomag fejrészt a 39. ábrán látható mezőértékekkel formázni kell. Ennek oka az, hogy ha a fejrész hossza vagy más adatfolyamból történő konverzió sem tesz állandó, és ez a pufferkezelést is befolyásolja. Szükségesnek tartjuk megjegyezni, hogy a rajzon nem látható mezők konstans értékeket tárolnak, és emiatt ezekkel itt nem foglalkozunk.

A PES csomag fejrészében lévő mezők értékei részletesen definiálva vannak az előre meghatározott formátumú SESP adatfolyamban annak érdekében, hogy minimalizáljuk az MPEG szállítási adatfolyam PES csomag fejrészének MPEG program adatfolyam-csomag fejrészére történő átalakításához szükséges feldolgozást.

Ha egy PES csomag mérete nagyobb, mint egy blokk mérete, akkor a PES csomagot több blokkra konvertáljuk. Ebben az esetben a második és az azt követő blokkok csomagfejrészeinek alábbi paramétereit módosítjuk: a PES csomagból előállított első csomag fejrészében lévő FTSJ3TS_flags mező értékét „00 b” értékre állítjuk; a PES__extensionJ)ag értékét „Oöb’-re állítjuk; a stuífing_byte lengtb értéket megfelelően beállítjuk; és a PES_header_dataJength értéket korrigáljuk.

A csomagok fejrészeit igy a PES csomag fejrészéből az első csomag fejrészének részleges módosításával, illetve az első csomag fejrészéből a második és további csomagok fejrészeinek részleges módosításával állítjuk elő.

S4204 lépés: A szállítási adatfolyam-csomag adatmezőjét átmásoljuk a

S42G5 lépés: Beolvasunk egy TS csomagot

54206 lépés; A szállítási adatfolyam-csomag adatmezőjét hozzáadjuk a program adatfolyam-blokk adatmezőjéhez.

54207 lépés: Megvizsgáljuk, hogy vége van-e a multipiexelési egységnek.

előre

Az S42Ö5-S42G7 lépéseket addig ismételjük, amíg a muitipiexelési egység véget nem ér, vagyis a 11 szállítási adatfolyam-csomag fel nem lett dolgozva. Mivel az adatfolyamban null csomag is lehet, a null csomag PID azonosítóját (0x1 FFF) érvényessé tesszük, és a szállítási adatfolyam-csomag adatmezőjéből az adatokat a szokásos módon átmásoljuk.

Célszerűen csak annak a szállítási adatfolyam-csomagnak van adaptációs mezője, amely egy PES csomagban lévő utolsó adatot tárolja el Ez azt jelenti, hogy egy PES csomagban lévő utolsó adatot eltároló szállítási adatfolyam-csomag kivételével az összes szállítási adatfolyam-csomag fix hosszúságú, 184 bájtot tartalmazó adatmezővel rendelkezik, így az adatmező adatainak kiolvasása egyszerűbb.

S4208 lépés; Kiszámítjuk az így kapott program adatfolyam-blokk bájtban kifejezett méretét, amikor az adatmező adatainak a muitipiexelési egység végére történő átmásolása befejeződött. Ha a blokk hossza 2G4S bájt, akkor a blokk elkészült. Ha a bájtban kifejezett hosszúság nem 2048 bájt, akkor az eljárás a S42Ö9 lépéssel folytatódik.

épés: Ha a blokk mérete kisebb, mint 2048 bájt, akkor az adatmező töltő csomagokat adunk hozzá ügy, hogy a blokk hossza 2048 bájt legyen.

Az AV adatokat tartalmazó muitipiexelési egység konverzióját az imént ismertetett módon végezzük. Ezt a folyamatot csak akkor ismételjük mindaddig, amíg az előre meghatározott formátumú SESF adatfolyam kijelölt részének feldolgozása véget nem ér, ha muitipiexelési egységet észleltünk.

A fent ismertetett konverziós folyamatot részletesen ismertetjük különböző típusú blokkok feldolgozása esetén.

A 4ÖA és 408 ábrán egy előre meghatározott formátumú SESF adatfolyam MPEG program adatfolyamra történő konverziója látható. Amint a 40A ábra szemlélteti, egy videó PES csomag mérete normális esetben nagyobb, mint 2 kB, és ezért tipikusan főbb muitipiexelési egységre osztjuk fel az előre meghatározott formátumú SESF adatfolyamra történő muítipíexeléskor.

Egy videó PES csomagban lévő utolsó muitipiexelési egység kivételével az meghatározott formátumú SESF adatfolyamot úgy definiáljuk, hogy mindegyik plexelésí egységbe a lehető legtöbb PES csomag adat legyen beszúrva. Az * ν * Φ «X -Φ ♦

utolsó muitíplexelési egység kivételével ezért az összes muitíplexelési egység 184 x 11 = 2Ö24 bált adatot tárol.

Az előre megbatározott formátumú SESF adatfolyam ily módon történő meghatározásával a PES packet Jéngth és a stuffíng~byte mezők értéke előre meghatározható a TS2PS konverzió során.

A videó PES csomag adatait tároló utolsó muitíplexelési egység a megmaradó területet egy adaptációs mezővel és null csomagokkal tölti ki a teljes muitíplexelési egység létrehozása céljából.

Amint a 40A és 40B ábrán látható, az egy videó PES csomagban lévő muitíplexelési egységeknek három típusa van, melyek a következők.

Az egyik multiplexeíésí egység a PES csomagban lévő első adatokat tárolja a 40. ábrán), a másik típusú muitíplexelési egység a PES csomag középső részében lévő adatokat tárolja (MU#n, ahol n = 2, 3, N~i a 40. ábrán), míg a harmadik típusú muitíplexelési egység a PES csomagban lévő utolsó adatokat tárolja

A 408 ábrán az említett három különböző típusú muitíplexelési egységnek megfelelően a 7S2PS konverzió során átal tPEG program adatfolyam blokkiéi

Az MU#1 muitíplexelési egységből átalakított blokk mindig legalább 10 bájtnyi üres területet tartalmaz, Így annak a végéhez kitöltő csomag van hozzáadva.

Ha egy DVD formátumú blokkban 7 vagy annál kevesebb bájt hosszúságú üres hely marad, a csomag fejrészének utolsó mezőjébe bájtokat szúrunk be úgy, hogy összesen 2048 bájt legyen. Ha 8 vagy annál több bájt üres, akkor a blokkhoz kitöltő csomagot adunk hozzá.

Az MU#n típusú muitíplexelési egységből előállított blokkokhoz egyetlen beszúrt bájt van hozzáadva a blokk teljessé tétele érdekében, Az MU#N típusú muitíplexelési egységből előállított blokkhoz egy kitöltő csomag van hozzáadva, mivel általában legalább 8 bájt hosszúságú üres része van, amikor a blokkot előállítjuk.

A 41A és 418 ábrán egy előre meghatározott formátumú SESF adatfolyam MPEG program adatfolyammá történő átalakítása látható. Amint az ábrán látható, az egy vagy több audio keretet tartalmazó audio PES csomag mérete kisebb, mint a muitíplexelési egységé.

Mível az audio PES csomag beilleszthető egy multiplexeíési egységbe, nem szükséges olyan bonyolult konverziót alkalmazni, mint például a videó PES csomag konverziója. Ez azt jelenti, hogy az előállított blokkokba mindig beszúrunk kiegészítő csomagot, ahogy ez a 41 δ ábrán látható.

Mivel a PES packetjength paraméter értéke nem változik meg a TS2PS konverzió során, a konverzióhoz szükséges számítás az MPEG-1 audio átalakítás során a stream__ld paraméter megfelelő beállítására korlátozódik.

A 42. ábrán egy előre meghatározott formátumú SESF adatfolyamban megengedett audio bitsebesség, valamint egy audio PES csomagban eltárolt maximális hosszúságú adatmező látható, amikor AC-3 és MPEG-1 audio adatok vannak eltárolva. Kitöltő csomagot minden esetben beszúrunk, mivel a rajzon látható maximális bájthosszúságokat meghaladó méretű audio adatokat nem egyetlen audio

A továbbiakban a 43-54, ábrákon látható folyamatábrák segítségével a TS2PS konverziós folyamatot ismertetjük.

A 43. ábrán a fő TS2PS konverziós folyamat folyamatábrája látható. A folyamat úgy indul, hogy a felhasználó TS2PS konverzió iránti kérést ad ki. Az első S11 lépésben megkeressük az első SESF zárt egységet (SESF capsule), ahol a konverzió kezdődik. Az S12 lépésben megvizsgáljuk, hogy van-e a feldolgozható SESF zárt egység. Ha nincs, akkor a folyamat véget ér. Ha van, akkor az S13 lépésben elindítunk egy inicializáló folyamatot, majd az S14 lépésben egy zárt egységet feldolgozó folyamatot. Az S15 lépésben megvizsgáljuk, hogy a konverzió véget ért-e. Ha igen, a folyamatnak vége, ha nem, akkor visszatérünk az Sí2

A 44. ábrán a 43. ábra Sí3 miciahzalas látható. Ez a folyamat beállítja és inicializálja a későbbi folyamatokban felhasznált változókat. Az S21 lépésben meghatározzuk, hogy be lett-e olvasva egy Tip csomag. Ha Tip csomag nem lett beolvasva, akkor az S22 lépésben beolvasunk egy Tip csomagot. Ezt követően az S23 k a Tip csomag ATS mezőjébe beírjuk az

ATSTip értékét, az S24 a Tip értéké, az S25 •igozaí *-» * “3

meghatározó MU_num változó értékét 0-ra állítjuk, végül az S26 lépésben az ATS túlcsordulások számát megadó WA változó értékét szintén Ö-ra állítjuk.

A 45. ábrán a 43. ábra $14 lépéseként említett, a zárt egység feldolgozását végzó folyamat folyamatábrája látható. Ez a folyamat az előzőhöz hasonlóan szintén egy szállítási adatfolyam-csomag beolvasásával kezdődik az S31 lépésben. Az $32 lépésben megvizsgáljuk, hogy a beolvasod szállítási adatfolyam-csomag Tip csomag-e. Ha a beolvasott csomag Tip csomag, a feldolgozás véget ér. Ha a beolvasott csomag nem Tip csomag, akkor az $33 lépésben megvizsgáljuk, hogy a beolvasott szállítási adatfolyam-csomag tartalmaz-e audio csomagot vagy videó csomagot. Ha a szállítási adatfolyam-csomag sem audio, sem videó csomagot nem tartalmaz, visszalépünk az $31 lépéshez, és egymás után olvasunk be szállítási adatfolyam-csomagokat mindaddig, amíg olyan adatcsomagot nem észlelünk, amely tartalmaz audio vagy videó csomagot. Ha a szállítási adatfolyam-csomag tartalmaz audio vagy videó csomagot, akkor az $34 lépésben beolvassuk a kővetkező 10 szállítási adatfolyam-csomagot is. Ezt kővetően az $35 lépésben eggyel megnöveljük az Mü__num értékét. Az $38 lépésben a multipiexelési egységben lévő első szállítási adatfolyam-csomag ATS mezőjébe beírjuk az ATS[MU__numj értéket. Az $37 lépésben a multipiexelési egység PES csomagjában lévő adatmező bájtban kifejezett bosszúságát beállítjuk a payíoadjen értékre. Ezután az $38 lépésben lefuttatjuk az egyes blokkok feldolgozását végző eljárást.

A 46. ábrán a 48. ábra $38 lépésében végrehajtott blokkegység feldolgozási folyamat lépései láthatók. Ez a blökkegység feldolgozási folyamat őt szubrutinból áll: az $41 lépésben végrehajtott SCR számításból, az $42 lépésben végrehajtott blokkfejrész feldolgozásból, az $43 lépésben végrehajtott csomagfejrész feldolgozásból, az $44 lépésben végrehajtott adatmező feldolgozásból, valamint az $45 lépésben végrehajtott kitöltő csomag feldolgozásból. Az egyes szubrutinok működését az alábbiakban Ismertetjük.

A 47. ábrán az SCR számítást végző folyamat látható. Ez a folyamat a blokk SCR értékét határozza meg.

Az $51 lépésben a blokkban lévő első multipiexelési egység megkereséséhez először megvizsgáljuk az MU„num változó értékét. Ha az első multipiexelési ~88~ egységről van szó, akkor az S51 lépésben az ATSTip értéket beírjuk az ATS[Ö] mezőbe, az S53 lépésben pedig a PCRTip értéket beírjuk az SCRjöj mezőbe.

Ezt követően az S55 lépésben összehasonlítjuk az ATS[MU_num] és ATS(MU_num-1j változó értékét. A muitiplexelési egység első csomagjában lévő ATS értéket az ATSjij változóban tároljuk. Az ATS érték megadja egy adott csomagra vonatkozó relatív átviteli időzítést. Egy későbbi csomagban lévő ATS érték így általában nagyobb, mint a korábbi csomag ATS értéke. Mivel azonban az ATS egy véges, 30 bites érték, átvitel (oszloptúlcsordulás) következhet be, Ebben az esetben a későbbi csomag ATS értéke kisebb lehet, mint egy korábbi csomag ATS értéke. Az S54 lépésben az ATS értékeknek ezt az irányváltását figyeljük és ezáltal megállapítjuk, hogy keletkezett-e átvitel (oszlopfúicsorduiás). Ha az ATS[MU_numj < ÁTSjMUjium-l], vagyis ha túlcsordulást észlelünk, az S55 lépésben a WA mező értékét eggyel megnöveljük.

Az S58 lépésben az SCR[MU_numj változóba beírjuk az SCR{MU__num-1 j-*T érték és a (PCRTip + ÁTS(MU_numj - ATSTip + WA x BS érték közűi a nagyobbat.

A továbbiakban 48. ábra segítségévei a blokkfejrész feldolgozását végző folyamatot ismertetjük.

Ez a folyamat a blokk fejrész adatokat a 38. ábrán látható adatszerkezet, alapján szerkeszti. Az S81 lépésben az SCR__extensíon mezőbe beirjuk az SCR érték 3ÖO~zai történő osztásának maradékát, míg az S62 lépésben az SCR__base mezőbe beírjuk az iménti osztás hányadosát. Az S83 lépésben a programjmux.j3te mezőbe „0x6270” értéket írunk, míg az 884 lépésben a páck_siufTingJenglh változóba „000b” értéket írunk. Az S85 lépésben a blokkfejrész adatainak kitöltése céljából a többi meze értékét is megadjuk.

A továbbiakban a 49. ábra alapján a csomagfejrész feldolgozását ismertetjük.

Ez a folyamat az S71 lépésben az adatfolyam azonosítóját beállító szubrutinnal kezdődik. Az S72 lépésben megvizsgáljuk, hogy a muitiplexelési egység első szállítási adatfolyam-csomagja tartalmaz-e PES csomagfejrészt. Ha a muitiplexelési egység első szállítási adatfolyam-csomagja tartalmaz PES csomagfejrészt, akkor az S78 lépésben lefuttatjuk a PES csomaggal kezdődő adatfolyamot feldolgozó folyamatot, egyébként az S74 lépésben a nem PES csomaggal kezdődő adatfolyam feldolgozását hajtjuk végre. Azt, hogy a multiplexelési egységben lévő első szállítási adatfolyam-csomag tartalmaz-e PES csomag fejrészt, ágy határozzuk meg, hogy megvizsgáljuk a szállítási adatfolyamcsomag fejrészében lévő payioad_unít__start_indicator mező értékét, vagy közvetlenül megvizsgáljuk, hogy el van-e tárolva a PES csomag fejrész kezdőkód.

Az alábbiakban az SO. ábra segítségével az adatfolyam azonosítójának beállítását végző folyamatot Ismertetjük.

Ez a folyamat a stream JD mező értékét állítja be. Ha az S81 lépésben azt állapítjuk meg, hogy a feldolgozás alatt álló adatfolyam típusa „MPEG-2 videó, akkor a streamjd értékét az S82 lépésben „őxEö” értékre állítjuk. Ha az 583 lépésben azt állapítjuk meg, hogy az adatfolyam típusa „AC3~audíö”, akkor az S84 lépésben a streamjd értékét „8xBD”-re állítjuk be. Ha az 585 lépésben azt állapítjuk meg, hogy az adatfolyam típusa „MPEG-1 audio és az 588 lépésben megállapítjuk, hogy az adatfolyam „Prlmary audio”, akkor az S87 lépésben a streamjd értékét „OxCO értékre állítjuk be. Ha az S85 lépésben azt állapítjuk meg, hogy az adatfolyam típusa „MPEG-1 audio” és az 588 lépésben azt állapítjuk meg, hogy az adatfolyam típusa „Seoondary audio, akkor az 589 lépésben a stream.

A továbbiakban az 51. ábra segítségével a PES csomaggal kezdődő adatfolyam feldolgozását ismertetjük,

Az MPEG szabvány szerinti PES csomag szerkezetét az 88, ábra szemlélteti részletesen. Az Ilyen, PES csomaggal kezdődő adatfolyamot feldolgozó folyamat a mezők értékeit az 58, ábrán látható adatszerkezetnek megfelelően szerkeszti.

Amint az 51. ábrán látható, az S91 lépésben először megvizsgáljuk, hogy az adatfolyam típusa „MPEG-2 video‘-e. Ha igen, akkor az 892 lépésben az alábbi egyenlet alapján kiszámított értéket beírjuk a PES_packetJengfh mezőbe:

PES_packetJength ~ (3 + PES__header_dataJength} + payload len

Az S93 lépésben a konverzió előtti szállítási adatfolyam-csomag egyes mezőiben lévő „íö értéktől a PE8__header_dsfaJength értékig terjedő 3 bájtot közvetlenül átmásoljuk a konvertált MPEG program adatfolyam-blokkban lévő csomag fejrészének megfelelő mezőjébe. Az 594 lépésben a konverzió előtti szállítási adatfolyam-csomagban lévő PTSJŐTSJÍags értékének vizsgálatával eldöntjük, hogy van-e PTS, Ha van, akkor azt az S95 lépésben közvetlenül

ί.

»* átmásoljuk a konvertált MPEG program adatfolyam-blokkjában lévő csomagfejrész megfelelő mezőjébe. Hasonló módon, az S98 lépésben a PTSjDTSJtegs paramétert is megvizsgáljuk annak eldöntéséhez, hogy van-e DTS. Ha van, akkor azt közvetlenül az SS? lépésben átmásoljuk a konvertált MPEG program adatfolyamblokkjában lévő csomagfejrész megfelelő mezőjébe. Az S98 lépésben megvizsgáljuk a PES__extension_flag értékét, és ha „Γ-re van állítva, akkor az eljárást az S99 lépésben folytatjuk, egyébként a folyamat véget ér.

Az S99 lépésben újból megvizsgáljuk az adatfolyam típusát és a PES j?rivate_ dala Jlag értékétől a P__STD_buffer_fiag értékig terjedő 3 bájtot az adatfolyam típusának megfelelően felülírjuk. Ez azt jelenti, hogy ha az S99 lépésben azt állapítjuk meg, hogy az adatfolyam típusa „MPEG-2 videó”, akkor a PESj}nvate_data__flag-foí a PJTFDJjufferJIag-lg terjedő 3 bájtot az S10O lépésben a „öxlESGES” értékkel Írjuk felül. Ha az S101 lépésben azt állapítjuk meg, hogy az adatfolyam típusa ,AC3-audíö”, akkor az S102 lépésben az említett 3 bájtot a „0.X1E8Ö3A” értékkel írjuk felül. Ha az Sí03 lépésben azt állapítjuk meg, hogy az adatfolyam típusa „MPEG-i audio”, akkor az Sí 04 lépésben a szóban forgó 3 bájtot a „ÖX1E4020” értékkel írjuk felül,

A továbbiakban az 52. ábra segítségével a nem PES csomaggal kezdődő adatfolyam feldolgozását ismertetjük.

Az Sí 11 lépésben az „10” értéktől a PES csomagban lévő P£8jsxtenslon_flag értékig fartő 2 bájtot „0x8000” értékre állítjuk be, és az S112 lépésben megvizsgáljuk, hogy a payloadjen paraméter értéke kisebb-e, mint 2018. A payloadjen paraméter az egy multiplexelési egységben lévő PES csomag adathosszúságát adja meg és maximális értéke 184 x 11 ~ 2024 bájt lehet. Ha a payloadjen értéke kisebb, mint 2018, akkor az S113 lépésben a PESJieader_dataJength változó értékét ö-ra állítjuk. Ha a payloadjen értéke nagyobb vagy egyenlő, mint 2018, akkor az S114 lépésben a PESJieader daíajength értékét a (2025-payload Jen) értékre állítjuk be, és az S115 lépésben a PES csomagot feltöltjük a PESJieaderJataJengíh változóban megadott számú bájttal. Az S116 lépésben az alábbi képlet alapján kiszámított értéket adjuk a PES_paoketJength változónak'.

PES_packetJength ~ (3 + PES_header_dataJength) * payloadjen az 53, ábra segítségével az adatmező feldolgozását

Az S121 lépésben először az l változó értékét í-re állítjuk be. Az S122 ezután az i-edik szállítási adatfolyam-csomagban eltárolt PES csomag adatait kiolvassuk, és azokat az 8123 lépésben hozzáadjuk a blokk adataihoz. Az S124 lépésben az I változó értékét eggyel megnöveljük, Az S122-S125 lépéseket addig: Ismételjük, amíg az Sí25 lépésben azt állapítjuk meg, hogy i<12, Ha 1-12, akkor az egy multiplexelésl egységben lévő összes szállítási adatfolyam-csomagot fel lett dolgozva és a folyamat véget ér.

A továbbiakban az 54. ábra segítségével a kitöltő csomagok

Az 8131 lépésben először megvizsgáljuk, hogy a PES_packetJength értékét. Ha a P£S_packetJength paraméter értéke nem 2028, akkor az S132 lépésben a kitöltő csomag PES__packef_length mezőjét a {(2Ö28~PE8_packef__length)-8} értékre állítjuk, majd az 8133 lépésben a kitöltő csomagot hozzáadjuk az adatmezőhöz. Ha az S131 lépésben a PES_packetJength paraméter értéke 2028, akkor a folyamat azonnal véget ér.

Bár a jelen találmányt a leírásban különböző kiviteli alakokon keresztül, a rajz segítségével mutattuk be, nyilvánvaló, hogy a szakmában jártas szakember a találmányt számos módon módosíthatja. A találmány tetszőlegesen módosítható az igénypontok által meghatározott oltalmi körön belül

Claims (8)

1. SZABADALMI IGÉNYPONTOK

   1, Adatfolyam-konvertáló berendezés multiplexeit videó adatokból és audio adatokból álló első adatfolyamnak (300) egy hordozókőzegen (100) eltárolandó második adatfolyamra (400) történő átalakítására, ahol az első adatfolyamnak <300) első blokkokra (310) felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak (400) második blokkokra (410) felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok (310, 410) maximális adatmérefe eltérő, azzal jellemezve, hogy az első adatfolyam (300) formátuma egy, a második adatfolyamra (400) történő átalakításra alkalmas, előre meghatározott formátum:

   amely előre meghatározott formátumban az első adatfolyam (300) meghatározott számú, egymást követő első blokkjai (310) egy multlplexeiési egységet (250) alkotnak, amely meghatározott szám úgy van megválasztva, hogy a multlplexeiési egységet (250) alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban (410) lévő adatok mennyiségét, továbbá az egy multlplexeiési egységben (250) lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik;

   az első adatfolyam (300) átalakításának eredményeként adódó második blokknak (410) a rendszer dekódolójába (218) történő bevitelének kezdési időpontja azonos egy első lehetséges időpont és egy második lehetséges időpont közöl a későbbivel, ahol az első lehetséges időpont az aktuálisan átalakítandó multlplexeiési egységnek (250) a rendszer dekódolójába (21S) történő bevitelének kezdési időpontja, míg a második lehetséges időpont az az időpont, amikor az aktuális multlplexeiési egység (250) átalakításának eredményeként adódó második blokkot (410) közvetlenül megelőző második blokknak (410) a rendszer dekódolójába (218) történő bevitele véget ér;

   Φ * * * * *

   Φ* χφφ van e az előre ^határozott amely adahoíyam-konvertálő berendezés a hordozóközegrői (löö) az első

   Ivasásét végző olvasó egységet (221);

   a beolvasott első adatfolyamot (300) második adatfolyamra (400) átalakító konvertáló egységet (214); és az átalakított második adatfolyamot (400) a horodozőközegen eltároló adatrögzítő egységet (221) tartalmaz;

   amely konvertáló egység (214) a jelzőbít (320) értéke alapján meghatározza, hogy az első adatfolyam (300) az előre meghatározott formátumban van-e eltárolva; és ha az első adatfolyam (300) az előre meghatározott formátum szerint van eltárolva, akkor a multiplexelési egységet (250) alkotó első blokkokat (310) az első blokkok (310) multiplexelési sorrendjének megváltoztatása nélkül blokkonként egyetlen második blokkra (410) alakítja át és a második blokknak (410) a rendszer dekódoiőjába (218) történő bevitelének kezdési időpontjaként - mint az átalakított második blokkhoz (410) tartozó időcimke információ ~ az első és a második lehetséges időpont közűi a későbbit választja ki,
2. 2. Az 1. igénypont szerinti adatfolyam-konvertáló berendezés, azzal jellemezve, hogy az első adatfolyam (300) egymást követő multiplexelési egységei (250) olyan zárt egységet (200) alkotnak, amelybe egy vezérfőblokk (251) van beszúrva;

   a multiplexelési egység (250) elején elhelyezkedő első blokk (310) olyan első Időcimke információt (ATSjíj) tartalmaz, amely egy első refórenciaérték alapján megadja a rendszer dekódoiőjába (128) történő bevitel kezdési időpontját; a vezérlöblokk (251) tartalmazza az első referenciaértéken alapuló eiső

   Időcimke információt (ATSJíp), továbbá tartalmaz egy, az első referenciaértéktől eltérő, második referenciaértéken alapuló második ídőcímke információt (PCR Jip); és ‘•I * » Φ * » X * * * ♦ az egyes multiplexelési egységek (250) elején elhelyezkedő első blokkok (310} második idöeimke információja (calculated_PCRÍij) és az első adatfolyam .{300} átalakításával adódó második adatfolyamban (4Ö0) lévő minden egyesmásodik blokknak (418) a rendszer dekódolójába (218) történő bevitelének kezdési időpontja (SCR(ij) az alábbi képletek alapján van kiszámítva:

   SCR(1] = calcuiafedjP€R(1]

   SORpJ = max {SCRji-1] + T, calculated_PCR[íj} caiculated~PCR(i] = RCRJIp + (ATSjij - ATSJíp + C).

   ahol i olyan egész szám, amelynek értéke legalább 2, T egy második blokk (418) minimális átviteli ideje, C pedig egy korrekciós fényező az ATSjjj túlcsordulásához.
3. 3. Az 1. igénypont szerinti adatfolyam-konvertáló berendezés, azzal jellemezve, hogy a konvertáló egység (214) az első adatfolyamnak (388) a második adatfolyamra (400) történő átalakításhoz átkódolja az első adatfolyamot (388), ha a jelzőbit (320) vizsgálatával megállapítja, hogy az első adatfolyam (300) formátuma nem az előre meghatározott formátum.
4. 4. Adatrögzítő berendezés videó Információ és audio információ multiplexelésére az információk hordozőközegen (100) előre meghatározott formátum szerinti első adatfolyamként (380) történő eltárolásához, amely előre meghatározott formátum lehetővé teszi az első adatfolyamnak (308) egy második adatfolyamra történő átalakítását, ahol az első adatfolyamnak (300) első blokkokra (310) felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak (480) második blokkokra (410) felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok (310, 418) maximális adatmérete eltérő, azzal jellemezve, hogy az előre meghatározott formátumban az első adatfolyam (300) meghatározott számú, egymást követő első blokkjai (318) egy multiplexeiésl egységet (238) alkotnak, amely meghatározott szám úgy van megválasztva, hogy a multiplexelési * « * 5 * «·*!♦ ~73~ egységet (250) alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban (410) lévő adatok mennyiségét, továbbá az egy multipiexelési egységben (250) lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik;

   az első adatfolyam (300) egymást követő multipiexelési egységei (250), amelyek dekódolás! egységet alkotó videó adatokat tartalmaznak, olyan zárt egységet (200) alkotnak, amelybe egy vezérlőblökk (251) van beszúrva, ahol a vezérlőblökk (251) olyan jelzőbitet (320) tartalmaz, amely megadja, hogy az első adatfolyam (300) az előre megbatározott formátumban van-e eltárolva;

   az első (218) történő bevitelének kezdési időpontja azonos egy első sges időpont közül a az aktuálisan egységnek (250) a rendszer dekódolóiába (218) történő és az első lexelési kezdési időpontja, míg a második lehetséges időpont az az Időpont, amikor az aktuális multipiexelési egység (250) átalakításának eredményeként adódó második blokkot (410) közvetlenül megelőző második blokknak (410) a rendszer dekódolőjába (218) történő bevitele véget ér; és az első adatfolyam (300) úgy van a második adatfolyamra (400) átalakítva, hogy a multipiexelési egységet (250) alkotó első blokkok (310) az első blokkok (310) mulfiplexelésí sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra (410) vannak átalakítva és a második blokknak (410) a rendszer dekódolőjába (218) történő bevitelének kezdési időpontjaként - mint az átalakított második blokkhoz (410) tartozó Ídőoímke információ ~ az első és a második lehetséges időpont közül a későbbi van kiválasztva;

   amely «φ ‘ί »-⁴ ~~74 «·*$* ♦ * az előre meghatározott formátum szerinti első adatfolyamként rögzítendő videó információ és audio információ kódolását végző kódoló egységet (214);

   a kódolt első adatfolyamot (300) a hordozoközegen (100) eltároló adatrögzítő egységet (221); és a kódoló egység (214), valamint az adatrögzítő egység (221) vezérlését végző vezérlő egységet (212) tartalmaz:

   amely vezérlő egység (212) az első adatfolyamban (300) lévő videó információ és audio információ kódolásakor előre kiszámítja az első adatfolyam (300) kódolt videó információjából és audio Információjából átalakított második adatfolyamot (4ÖÖ), és ezt követően úgy kódolja az első adatfolyamban (300) lévő videó információt és audio információt, hogy a kódolt első adatfolyam (3ÖÖ) és az előre kiszámított második adatfolyam (400) egyikénél se lépjen fel puffer-alulcsordulás és/vagy puffertúlcsordulás,
5. 5. A 4. igénypont szerinti adatrögzítő berendezés, azzal jellemezve, hogy az első adatfolyam (380) egymást kővető muitíplexelési egységei (250) olyan zárt egységet (200) alkotnak, amelybe egy vezédőblokk (251) van beszórva;

   a muitíplexelési egység (250) elején elhelyezkedő első blokk (31Ö) olyan első időcímke információt (ATSpj) tartalmaz, amely egy első referenciaérték alapján megadja a rendszer dekódolójába (128) történő bevitel kezdési időpontját; a vezérlőbiokk (251) tartalmazza az első referenciaértéken alapuló első időcimke információt (ATSfolp), továbbá tartalmaz egy, az első referenciaértéktöl eltérő, második referenciaértéken alapuló második időcimke információt (PGRJíp); és az egyes muitíplexelési egységek (250) elején elhelyezkedő első blokkok (310) második időcimke információja (caiculafed__PCR(lj) és az első adatfolyam (300) átalakításával adódó második adatfolyamban (4ÖÖ) lévő minden egyes második blokknak (410) a rendszer dekódolójába (213) történő bevitelének kezdési időpontja (SCRpj) az alábbi képletek alapján van kiszámítva:

   SCRMj = caícolated„RCR(1j «·.* * » * * $ * * » 4 » * * * » *

   V «»*'« ♦ **« S

   SCRjij = max {SCR[i-1 j + T_s caiculaíed__PCRp]} caiculafed_.PCR{ij ~ PCRJIp + (ATSpj - ATS_tip + Q, ahol i olyan egész szám, amelynek értéke legalább 2, T egy második blokk (410) minimális átviteli ideje, C pedig egy korrekciós tényező az ATSpj túlcsordulásához.
6. 6. Hordozőközeg (100), amelyen első adatfolyamként (300) multiplexeit videó adatok és audio adatok vannak rögzítve olyan előre meghatározott formátumban, amely lehetővé teszi az első adatfolyamnak (3ÖÖ) egy második adatfolyamra (400) történő átalakítását, ahol az első adatfolyamnak (300) első blokkokra (310) felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak (400) második blokkokra (410) felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok (310, 410) maximális adatmérete eltérő, azzal jellemezve, hogy az előre meghatározott formátumban az első adatfolyam (300) meghatározott számú, egymást követő első blokkjai (310) egy muitiplexelési egységet (250) alkotnak, amely meghatározott szám úgy van megválasztva, hogy a muitiplexelési egységet (250) alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban (410) lévő adatok mennyiségét, továbbá az egy muitiplexelési egységben (250) lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik; az első adatfolyam (300) egymást kővető muitiplexelési egységei (250), amelyek dekődolási egységet alkotó videó adatokat tartalmaznak, olyan zárt egységet (200) alkotnak, amelybe egy vezérlöblokk (251) van beszúrva, ahol a vezérlöbiokk (251) olyan jelzőbítet (320) tartalmaz, amely megadja, hogy az első adatfolyam (300) az előre meghatározott formátumban van-e eltárolva; az első adatfolyam (300) átalakításának eredményeként adódó második blokknak (410) a rendszer dekódolojába (213) történő bevitelének kezdési időpontja azonos egy első lehetséges időpont és egy második lehetséges Időpont közül a későbbivel, ahol az első .♦ *· ψ·*^τΦ

   Φ· X 4 & » « ♦ ·Μ·* * tehetséges időpont az aktuálisan átalakítandó muitipiexelési egységnek (250) a rendszer dekódoíőjába (218) történő bevitelének kezdési időpontja, míg a második lehetséges időpont az az Időpont, amikor az aktuális multiptexelési egység (250) átalakításának eredményeként adódó második blokkot (410) közvetlenöl megelőző második blokknak (410) a rendszer dekódoiéjába (218) történő bevitele véget ér: és az első adatfolyam (300) ügy van a átalakítva, hogy a muitipiexelési egységet (258) alkotó első blokkok (310) az első blokkok (310) muitipiexelési sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra (410) vannak átalakítva és a második blokknak (410) a rendszer deködoíőíába (218) történő bevitelének kezdési időpontjaként - mint az átalakított második blokkhoz (410) tartozó idöcímke információ ~ az első és a második lehetséges Időpont közül a későbbi van kiválasztva.
7. 7. Eljárás adatfolyam átalakítására, amely során hordozóközegen (100) tárolt multiplexeit audio adatokat és videó adatokat tartalmazó első adatfolyamot (300) egy második adatfolyamra (400) alakítunk át, ahol az első adatfolyamnak (300) első blokkokra (310) felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak (400) második blokkokra (410) felosztott adatok tárolására alkalmas szerkezete van, és az első és második blokkok (310, 410) maximális adatmérete eltérő, azzal jellemezve, hogy az első adatfolyam (300) formátuma egy, a második adatfolyamra (400) történő átalakításra alkalmas, előre meghatározott formátum;

   amely előre meghatározott formátumban az első adatfolyam (3GÖ) megbatározott blokkjaiból (318) egy muitipiexelési megbatározott számot úgy választjuk egységet (250) alkotó adatok teljes r számú, egymást kővető első >éget (250) képezünk, amely meg, hogy a muitipiexelési mennyisége ne haladja meg az **»$ * > * tffc «μ egy második blokkban (410} lévő adatok mennyiségét, továbbá ahol egy multipiexelési egységben (250) lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik; az első adatfolyam (300) átalakításának eredményeként adódó második blokknak (410) a rendszer dekódolójába (218) történő bevitelének kezdési időpontját egy első lehetséges időpont és egy második lehetséges időpont közöl a későbbivel tesszük egyenlővé, ahol az első lehetséges időpont az aktuálisan átalakítandó multipiexelési egységnek (250) a rendszer dekódolójába (218) történő bevitelének kezdési Időpontja, míg a második lehetséges időpont az az időpont, amikor az aktuális multipiexelési egység (250) átalakításának eredményeként adódó második blokkot (410) közvetlenül megelőző második blokknak (410) a rendszer dekódolójába (218) történő bevitele véget ér;

   sgen (100) olyan jelzőbitet (320) tárolunk el, amely hogy az első adatfolyam (300) az előre meghatározott formátumban van~e eltárolva; továbbá amely eljárás során az első adatfolyam (300) második adatfolyamra (400) történő átalakításához megvizsgáljuk a jelzőöif (320) értékét, és ha azt állapítjuk meg, hogy az első adatfolyam (300) az előre meghatározott formátumban van eltárolva, akkor a multipiexelési egységet (250) alkotó első blokkokat (310) az első blokkok (31 ö) multipiexelési sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra (410) alakítjuk át; és a második blokknak (410) a rendszer dekódolójába (218) történő bevitelének kezdési mint az átalakított második blokkhoz (410) tartozó időcímke Információ - az első és a második rögzítési eljárás videó I multíplexelésére az információk és audio információ előre ♦,**»' -·\ ·** φ* * * * $ » * 4* ·»’ »%. Η* formátum szerinti első adatfolyamként (300) történő eltárolásához, amely előre meghatározott formátum lehetővé teszi az első adatfolyamnak (3ÖQ) egy második adatfolyamra történő átalakítását, ahol az első adatfolyamnak (3ÖÖ) első blokkokra (310) felosztott adatok tárolására alkalmas szerkezete van, a második adatfolyamnak (4ÖQ) második blokkokra (410) felosztott adatok tárolására alkalmas szerkezete van. és az első és második blokkok (310, 410) maximális adatmérete eltérő, azzal jellemezve, hogy az első adatfolyam (300) meghatározott számú, egymást követő első blokkjaiból (31 ö) egy multiplexelésí egységet (250) képezünk, amely meghatározott számot úgy választjuk meg, hogy a multíplexeiési egységet (250) alkotó adatok teljes mennyisége ne haladja meg az egy második blokkban (418) lévő adatok mennyiségét, és az egy multíplexeiésí egységben (250) lévő összes adat ugyanahhoz a videó adatfolyamhoz vagy audio adatfolyamhoz tartozik:

   lyam (30Ö) egymást követő multiplexelésí egységeiből dekődolási egységet alkotó videó adatokat tartalmaznak, olyan zárt egységet (200) képezünk, amelybe egy vezérlőblokk (251) van beszúrva, ahol a vezérlőblokk (251) olyan jeízobítet (320) tartalmaz, amely megadja, hogy az első adatfolyam (300) az előre meghatározott formátumban van-e eltárolva; az első adatfolyam (300) átalakításának eredményeként adódó második blokknak (410) a rendszer dekódolójába (218) történő bevitelének kezdési időpontját egy első lehetséges időpont és egy második lehetséges Időpont közül a későbbivel tesszük egyenlővé, ahol az első lehetséges időpont az aktuálisan átalakítandó multiplexelésí egységnek (250) a rendszer dekódolójába (218) bevitelének kezdési időpontja, míg a második lehetséges az az időpont, amikor az aktuális multipiexelési egység (250) átalakításának eredményeként adódó második blokkot (41Ö) az első közvetlenül megelőző második blokknak (410) a rendszer dekődolójába (218) történő bevitele véget ér: és az első adatfolyamot (300) úgy alakítjuk át a második adatfolyamra (400), hogy a multiplexelési egységet (250) alkotó első blokkok (310) az első blokkok (31 ö) multiplexelési sorrendjének megváltoztatása nélkül, blokkonként egyetlen második blokkra (410) alakítjuk át és a második blokknak (410) a rendszer dekődolójába (218) történő bevitelének kezdési Időpontjaként - mint az átalakított második blokkhoz (410) tartozó Időcímke információ - az első és a második lehetséges időpont közül a későbbit választjuk;

   amely adatrögzítési eljárás során az első adatfolyamban (3ÖÖ) lévő videó információ és audio információ kódolásakor előre kiszámítjuk az első adatfolyam (300) kódolt videó információjából és audio információjából átalakított második adatfolyamot (400), és ezt követően úgy kódoljuk az első adatfolyamban (300) lévő videó információt és audio információt, hogy a kódolt első adatfolyam (300) és az előre kiszámított második adatfolyam (400) egyikénél se lépjen fel puffer-aiulcsorduíás és/vagy pufferfúlosordúlás.
8. 9. Számítógépi program a 7. vagy 8. igénypont szerinti eljárás számítógépen történő végrehajtására.