Ili po "domaći" - Overflow/Underflow problemi

U okviru ovog opisa, pogledajmo VBV buffer. Put od enkodera, preko stvarnog prijenosa informacija (DVD/CD, radio ili kabelski valovi), do dekodera neizbježno ide preko "kako god se zvao" buffer-a.

Slika1: Prijenos

 
Kod klasičnog DVD-a imamo:

• Track Buffer
• Compressed Data Buffer
• Audio Buffer
• VBV Buffer
• Subpicture Buffer
• VBI Buffer
• PSI Buffer
• Host-Access Buffer
• Frame Buffer
• ....

Neću govoriti o normama i opisivati razne buffere, samo ću pokušati na jednostavna način objasniti komplicirani VBV buffer (drugim rječima pokušat ću na hrvatskom objasniti 'taj' bufer), tako da znate šta u stvari namještate i kako bi mogli možda poboljšati sliku i ton.
Punjenje VBV baffera je najsličnije brani na rijeci. Najprije treba određeno vrijeme da se napuni, a onda možemo regulirati količinu vode koja otiče kroz branu. Ljeti jako malo vode dolazi u branu, ali ista količina otiče i nivo vode pada, dok je zimi isti nivo vode bez obzira na otok vode. DVD ili SVCD ima jedan MPEG-stream, koji radi najčešće sa varijabilnim bitratom. Taj varijabilni bitrate mora se prilagoditi da radi pri konstantnom prijenosu informacija. Na obrnuti način, znači pri reproduciranju CD-a, konstantni prijenos informacija mora se prilagoditi varijabilnom bitratu.

VBV je skraćenica "Video Buffering Verifier", znači to je buffer (spremnik) za video-informacije. Podaci se samo ne spremaju, već se i provjeravaju. VBV preuzima za dekoder, (koji nam dekompresira sliku) jedan jako važan organizacijski posao.

VBV-bufferu se poklanja jako malo pažnje (ljudi ne znaju šta je, pa se odmah klasificira kao nebitna stvar), iako je od "zaslužan" za mnogobrojne teškoće i probleme (kada se na news-grupama ljudi pitaju npr. zašto im se zamrzavaju slike i/ili ton). Ako se malo pogleda ta problematika, dosta tih problema su "produkt" krivo namještenog VBV-Buffera.

Znamo već iz SVCD-datarete ranije, da DVD-Standalone-Player, ako je SVCD 'raspoložen', SVCD čita x2 i pri tome čita brzinom od 2.788,8 kBit/s. Znamo i, da protok informacija kod MPEG-a nije uvijek konstantan. Tako se može desiti da se pri jako brzim pokretima više podataka učita, nego pri sporim radnjama. O toj ravnoteži je riječ kod VBV, što znači da je cilj napraviti što je moguće bolju kvalitetu slike.
U principu si možemo predočiti, da će se informacije sa CD-a ili DVD-a čitati određenom brzinom (recimo x1). x1 znači brzinu podataka, koji će se u određenom trenutku učitai sa CD-a. Ako se scena sastoji od I-, P- i B-Frameova, koje su za svaku vrstu slike (I, P oder B) različite veličine, moramo te iste slike 'konvertirati' u harmonički ravnomjeran stream. Važno je znati, da I-Frame ne treba drugu sliku, da bi bio vidljiv, dok P-Frame je referentno povezan sa sliku ispred, a B-Frameu jsu potrebne prijašnje i sljedeće informacije o slici. Tako B-Frame može tek bit prikazan, kad dekoder ima informacije o dolazećim I ili P frameovima. Posljedica toga je da, pojedini frameovi moraju biti reorganizirani.
Sjećate se klasične GOP strukture: IBBPBBPBBPBBP ( Formati)
Dekoder mora za izračunavanjem jednog B-Framea čekati dok ne dođe do P-Framea, jer je tek tada u stanju, sekvencu "BBP" reproducirati.
Kroz reorganizaciju frameova B B P dobivamo niz P B B, koji se u bufferu snima i predaje dekoderu. Tako je dekoder u mogućnosti, izračunati dolazeće B-frameove i na kraju zadržati P-Frameove za nove B-Frameove.

 
Slika3: Izlaz informacija iz buffera
Kroz ovo 'buffer-ovanje' je moguće, dekoderu svaku informaciju dati "u roku odmah".

Kako se slika dekodira (tako se iz djelova P- i B-Frameova stvara cijela slika), tako se i reproducira na TV-u. Veličina takvog buffera je za SVCD definirana, 224Kbyte
( po IEC 62107 sa 1.835.008 (Bits) / 8 (Bits/Byte) / 1024 (Bits/KBit)).

Po ISO/IEC 13818-2; VBV se računa po ovoj formuli: B = 16 * 1024 * vbv_buffer_size

"B" zadan u bitovima i ranije definiran: 1.835.008 Bitova.

Znamo da je 1 Kbit 1024 bitova. Tako su 16 Kbit = 16 * 1024 bitova = 16.384 bitova

Sad znamo da je memorijski segment VBV buffera, 16 Kb, a ne, kao na news-grupama, 16 KB (znači KByte). Ne, to je samo 16 Kbit-ova!
Podijelimo li veličinu VBV od 1.835.008 Bit (= 224 KByte) sa 16.384 bit, dolazimo do broja memoriskih segmenata. 112 u naše primjeru.

Tako dolazimo do SVCD formule:

Dosta teretiziranja, idemo nešto probat u praksi:

Pogled na postavke AVI2MPG2 pokazuje nam, da je veličina u Kb. Šta bi to trebalo značiti? "B" kao rezultat formule ili varijable "vbv_buffer_size", kao dijela formule?

112 (kako je napisano) je: 112 bit * 1024 bit/Kbit = 114.688 bit = 14 KByte

Matematika kaže da tu nešto ne štima....

Ovdje vidite podatke o veličini VBV-Buffera u "sequenz headeru" jednog streama. Možemo pogledati bilo koji stream, koji je napravljen sa gore navedenim postavkama, jako korisnim alatom ( koga većina ima ali ih jako malo zna čemu služi) MPEGanalizzatore, i vidit ćemo sljedeću sliku:

112 je u stvari 112 bitova u varijabilnom vbv_buffer_sizu. Znači da je oznaka 112Kb u AVI2MPG2 jedna velika laž!

TMPGEnc (od verzije Beta 1.2j) definira VBV kao "VBV buffer size" u KByte, a pri tome ne misli varijabilni vbv_buffer_size gotrnje formule, več više kao sami "B".

224 kod TMPGEnc je nešto jako drugačije, nego 224 kod AVI2MPG2! 

224 KByte kod TMPGEnc su 112 bitova kod AVI2MPG2.
Pri izmjeni veličine buffera, broj uvijek mora biti djeljiv sa 16.

Usput da spomenimo i ostale VBV buffere. Ne postoje samo kod SVCDa VBV buffer. I kod DVDa ili VCDa postoji VBV buffer, koji se razlikuje smo u veličini. U ISO/IEC 13818-2 standardu, nalazimo razne "MPEG-Main profile",koje ćemo sada malo objasniti. ( Formati i Kompresije).

Oznake profila i levela kod TMPG enkodera:

Šta znače ove brojke? U samom headeru slike postoji polje vbv_delay. On regulira vremenske razlike između pipremanja/spremanja podataka u VBV, i početka dekodiranja. Ako je ovo polje 0xFFFF, onda podaci dolaze do buffera tek kad se oslobodi prostor u bufferu. Pri tome se koristi maximalni bitrate, koji stoji u headeru scene. Tek kad je buffer napunjen, počinje dekodiranje. Postoje još neke delay postavke, pr startup_delay ili end_to_end_delay - ali to ćemo ostaviti za drugi put.

Ovdje se vidi tipično pražnjenje i punjenje buffrea:

Slika4: VBV procedura

Dakle, tek kad je buffer napunjen počinje dekodiranje. Što znači da procedura dulje traje što je VBV buffer veći. Kada dekoder, duže vremena, potražuje podatke, brže nego se čitaju sa CD-a (neispravan vbv_delay ili prenizak Muxrate), tako se prazni buffer dok se skroz ne isprazni. Samim time masa podataka ne dolazi do dekodera i slika se zamrzava. Tek kad se buffer ponovo napuni, počinje ponovo reprodukcija.
Ovo se naziva buffer underflow.

Obrnuto je moguće, da se u nekim scenama, podaci brže čitaju sa CD-a, nego što se dekodiraju (neispravan vbv_delay ili previsok Muxrate).
Ili, ako jedna kompletna slika ne može stati u buffer (encoder je krivo izračunao VBV_size). Ovdje dolazi do gubitka podataka, koje se manifestiraju u isprekidanim slikana (pojedine slike se uopće ne prikazuju).
Ovo dovodi do buffer overflowa.

Na pojedinim playerima može doćo do desinkronozacije zvuka i slike. Ovdje je potreban Firmware upgrade.

Pogledajmo sada funkcioniranje buffera. 

Kada je buffer ispunjen, slike se reproduciraju u određenom redosljedu. Najprije I-frame, jer je I-frame u biti slika, koja koristi većinu memorije u bufferu. Kada je I-frame reproduciran oslobađa se veliki dio memorije, koji se opet puni podacima sa CD-a. U isto vrijeme se čitaju P i B framovi, koji dolaze iza I-framea. Tako dolazi do konstantnog punjenja i pražnjenja slika u bufferu. Iz ovoga proizlazi mogućnost, da se u kratkom vremenskom roku, ostvaruje "brže" čitanje podataka sa CD-a, nego je fizički moguće sa CD-a ( 75 ili 150 sektora u sekundi).
Ovo objašnjava prekoračenje brzine prijenosa podataka, kojim je sam player ograničen.
Tako je moguće napraviti scene/film sa 3000 kbps ili više, mada je kod SVCD-a dozvoljen maximalni datarate ( video + audio + muxingrate + itd. ) 2.788,8 kbps. U biti, u samom filmu dolazi do takozvanih "peakova", kod kojih film, za jedan kratak period ima značajno veći datarate.
Samim ovim, možemo u dosta slučajeva izbjeći ili bar minimirati 'blokove'.
Vrijeme za koje se buffer napuni/isprazni ovisi o još jednom vaznom faktoru, načinu dekodiranja GOPova. 

Sjećamo se da postoje različite veličine i strukture GOPova: 1/5/2/1 ( I P B B P B B P ...) preko 1/12/1/1 ( I P B P B P B ...) , pa sve do
1/14/0/1 ( I P P P P P P ...). Način na koji se oni dekodiraju, utiče na mogućnost, kojom brzinom se pojedine slike iz buffera dekodiraju.
Pri strukturi 1/5/2/1 B-frames se mogu pročitati tek kad se nadolazeće P ili I frameovi u bufferu.
B-frame, da bi se dekodirao, treba raniji ili kasniji I ili P frame, kao referentnu sliku. To znači, da se u ovom slučaju, u bufferu nalazi relativno dosta slika, koje se ne mogu pročitati jer im nedostaje zadnja referentna slika. Time se donekle ukida mogućnost, dodavanja datarate-a slikama, jer sve slike moraju ostati u bufferu (praktično je odrediti što veći buffer, ili kod manjeg buffera smanjiti broj B-frameova).
Iz ovoga se vidi, da je veličina buffera i broj B-frameova (čitaj: GOP postavke) jako jako bitna postavka. 
Pogledajmo scenu specifičnim alatom "Mpeg Repair" - Pixeltools,):

Možete pokušati i sa "MPEG-Analyserom" kojeg možete naći kao demo verziju, ili na http://www.mpeg.org/MPEG/companies.html u dijelu "Test Equipments, Stream Analyzers and Test Streams" mogu se takođe naći programi koje možemo koristiti u razne testne svrhe.
Ako bi snimali razne Saborske scene (u kojima nema dinamčnih scena, u biti i nema ništa vrijednoga, uopće...), i konvertirali ih TMPGom (VBV buffer je namjerno namješten na veličinu 48 kBytova), dobili bi sljedeći dijagram:

Slika5: VBV - 48 KB

Pitanje je vremena kada će doći do buffer overflowa, jer za pojedine kompletne slike nema mjesta u VBV bufferu. da ne bi kompletan stream iznova obrađivali u TMPG-u, VBV možemo optimirati pomoću VBV TMPGEnc v1.2 (od verzije 1.2 je funkcija ukinuta):

SaVBV veličinom 86, problem pojave buffer overflowa nestaje, pa dijagram izgleda ovako:

Slika6: VBV 86K

Ako svaki strem pogledamo u detalje, primjećujemo na početku streama dva headera .

Slika7: Dupli system hedaer

Očigledno je pri mjenjanju VBV-a došlo do pojave još jednog headera:

Slika8: Sadržaj system headera

Pitanje je , dali se ovo dešava kod svih aplikacija (valjda je iz ovoga razloga ovajdio i izbačen iz TMPGenc). Na newsgrupama se može pronaći alternativa, u vidu demultiplexiranja streamna, te ponovnog multiplexiranja. 

Nakon toga dobijemo ovakav dijagram:

Slika9: VBV 48 K

 
To nije bilo ništa. Nema promjene u dobivenom streamu, u pogledu VBV vrijednosti u "sequenz headeru". I korištenje AVI2MPEG2 (bbMPEG V1.24 beta 18) nije nam pomoglo. I ovdje je ostao 48 KByte VBV u "sequenz headeru". 
Očigledno je da se treba ispočetka odrediti ispravna VBV buffer veličina.

Nakon objašnjenja "overflow" problema, malo ćemo se pozabaviti "underflow" problemom, koji nastane pri Muxanju.
Možda ste dobili sljedeću grešku kod bbMPEG-a :

Multiplexing file d:\test.mpg
video PTS (59272.37ms) underflow at pack 6627 by 0.97ms
video DTS (59522.62ms) underflow at pack 6671 by 44.05ms
video PTS (59555.98ms) underflow at pack 6678 by 57.35ms
video PTS (59606.03ms) underflow at pack 6680 by 20.63ms
video DTS (59639.40ms) underflow at pack 6682 by 0.60ms
itd, itd...

Pogledajmo nastanak MPEG-a. Iz MPEG encodera izlaze (najmanje) dva streama podataka. Video i Audio bitstream, koji se nazivaji i Elementary Streams (ES). Zadatak paketizera i multiplexera je, ove dvije informacije (i još neke dodatne informacije) spoji u jedan Program Stream (PS).
Ili ako je potrebno, u dodatnom koraku pretvoriti u Transport Stream (TS).

Slika10: ES / PES / PS

Da bi ton i slika ostali sinknronizirani, moramo urediti dodatne mjere za takt (re)generaciju u decoderu i za sinkronizaciju videa i audia. Sa PES (Packetised Elementary Stream) će se označiti video, audio ili druge vrste padataka u "packetizeru". U svrhu prijenosa podataka, takve video tj. audio streamovi će se rastaviti u pakete, i u ovom slučaju (nakon Packetizera) označiti sa jednim PES headerom. Packetizer nas toliko ne interesira. Važno je da su, u sklopu tona i slike, još razne header informacije tu zastupljene, zajedno sa takozvanim "Time Stamps" - vremenskim pečatom. Neophodnost "Time Stampsa" u struji podataka dolazi zbog toga jer, videodekoder mora rekonstruirati B-Frame od prijašnjeg I-Framea i sljedećeg P-Framea, dok je redosljed u kome ih on prikazuje drugačiji.
Postoje dvije vrste "Time Stampsa": najprije imamo "Decode Time Stamp" (DTS), koji govori kada se pojedni frame treba dekodirati, i onda imamo "Presentation Time Stamp" (PTS), koji govori kada se frame treba reproducirati. Za savršeno funkcioniranje Time Stampsa, potrebaa nam je i referentni sat (Referenz Clock), "System Clock Reference" (SCR). Pojednostavljeno rečeno, SCR možemo zamisliti kao sat koji je potreban da bi se podaci sa CD-a pročitali. Greška pri upravljanju ovog vremenskog pečata vodi ka sinkronizacijskim greškama kod slike i tona.

Svaki paket sa MPEG podacima ima SCR. Ovo je vrijeme koje sistemski sat treba da bi pročitao paket podataka. U normalnom slučaju se dekoder sistemskog takta isključuje kad počinje sa čitanjem MPEG streama. U prijevodu, počinje sa nule i sa svakim paketom nadodaje +1.

Sika11: Struktura paketa

Kad je SCR ("System Clock Reference") dostigao vrijednost DTS-a (Decode Time Stamp), daje instrukcije dekoderu da počne sa dekodiranjem frameova. Trenutak kasnije će se pojaviti sliaka i ton, upravljani preko PTS-a ("Presentation Time Stamp").

Ako je SCR, kod videopodataka 100 ms, onda je to vrijeme koje je potrebno, za čitanje podatke s HDD-a ili CD-a, nakon pritiska na Play.

Recimo da je DTS/PTS = 200/280ms. Onda su podaci nakon 200 ms dekodirani , i 80 ms kasnije se poajavljuju na TV-u. U međuvremenu se podaci snimaju u buffer. "Underflows" se pojavljuje samo onda, kada je video-datarate veći od "Muxing-Ratea".
Na primjeru: 

"Muxing-Rate" iznosi 1.000.000 bits/sek. To znači da, dekoder preko VBV-a može pročitati 1.000.000 bits/sec iz videa. Ako video-datarate iznosi 2.000.000 bits/sek, potrebno je 2.000.000 bitova da bi se prikazala jedna sekunda filma, onda imamo problem !!!
Podaci se ne mogu dovoljno brzo pročitati, da bi dobili sekundu videa bez trzanja ili prekida. VBV je stalno prazan.

U ovom slučaju DTS/PTS - vremenski pečati nam govore, da se video sa istim vremeskim pečatom (čitaj: isti dio filma) treba dekodirati i reproducirati. SCR i DTS/PTS ne pašu zajedno, i pojavi se "underflow" error.

Od dekodera do dekodera ovaj problem se i ne mora pojaviti. Dekoderi bazirani na PC-u se nimalo ne brinu o SCR-u i produciraju skoro nikakve "underflowsa". Oni čitaju dalje sa HDD-a ili sa "superbrzog" CD-a. Često kod premotavanja "izgube" pregled, te se time pojavljuje desinkronizacija.

Dok se držite Datarate-a unutar SVCD specifikacija, "underflow" greška se vjerovatno neće dogoditi. Ako sa postavkama idete van specifikacija i video-datarate bude veći od "Muxing-Ratea", imat ćete problem. Problem će nastati samo onda, kada se enkoder ne pridržava specifikacija i prodicira neke maximalne vrijednosti (peaks).

Sami "Muxer" ima samo tri izbora:

• Prijavi grešku i prestane sa radom
• Ignorira taj problem, i ostavlja playeru da riješi problem.
• Izbaci pojedine podatke. Kod videa, mogu to biti kompletne slike. Ako svakoj slici pripada i mali dio tona, stvar postaje složenija i radi toga samo mali broj Muxera je "sposoban" ovo uraditi.

Nemojte me pitati, koji program reagira na koji način, ali je najvjerovatnije da će se problem ignorirati i ostaviti playeru da se misli o njemu.
Ovaj isti može reagirati zatrzavanjem i desinkrinizacijom. Newsgroupe su pune pitanja o ovom problemu. Kada želite povećati datarate, morate povećati i Muxrate, sve u cilju izbjegavanja "underflow" greške.

bbMPEG, na primjer, stavlja sljedeće postavke : 3528 za VCD i 6972 za SVCD.

Slika 11a

Šta znače ti brojevi ?

Kod VCD-a imamo stalni Muxrate od 176.400 Byte/s , a kod SVCD max. 348.600 Byte/s. 'Maximalno iz razloga jer, je kod SVCD-a dozvolje varijabilni bitrate. Ako želite znati, odakle ovi brojevi, pročitajete temu "Datarate".

Bitrate je jako često određen u jedinicama od 50 bajtova, jer je u headeru jako malo mjesta. Zbog ovoga dobivamo kod
VCD 176.400 Byte/s / 50 = 3528, a kod SVCD = 6972.
Ako sa ovim postavkam imamo problema, umjesto 6972 možemo napisati "0". bbMPEG će onda potreban Muxrate automatski izračunati.
Ali ako ste van dozvoljenih specifikacija, time napuštate SVCD standard , i pravite XSVCD. Hoće li to player "prožvakati" ovisi o brzini ugrađenog CD-a i Firmware-u.

Skinuto sa http://members.home.net/beyeler/bbmpeg.html.

Prvi korak je "De-Multiplex" gotovog - sa TMPGEnc - napravljenog videa. Sa bbDMUX pokrećemo: bbdmux film.mpg
Može se i napisat: bbdmux film.mpg > sadržaj.txt (sve što ekran izbaci snima se u .txt datoteku)

Slika 11b

Ovo nam govori da se u filmu nalazi jedan video/audio/padding-stream, sa "ID-om".

Padding označava neiskorištene "pune bytove", za ispunjavanje poadatkovnih linija. Kod SVCD sekvenca (GOP) mora započeti sa punim sektorom. Što znači, da se "puni bajtovi" zapisuju između scena,koje ne sadržavaju nikakve informacije. Padding stream ćemo sada u svakom slučaju preskočiti.

DOS naredbama :

• bbdmux film.mpg 0xe0 video.m2v
• bbdmux film.mpg 0xc0 audio.m2a

izoliramo podatke u posebnu datoteku video.m2v i audio datoteku audio.m2a (ili bolje: "audio.mpa")

Startamo AVI2MPG2:

Slika 11c

Kliknemo na "Start Encoding" bez da smo učitali iti jedan fajl, i dobijemo sljedeću sliku:

Slika 11d

Pritiskom na setings biramo "Input and output files":

Slika 11e

Tu učitamo pojedine djelove i definiramo izlaznu datoteku, "MPEG Program Stream".

Pod "Program Stream Settings" biramo iz "Program stream type" SVCD format:

Slika 11f

Pritiskom na OK dolazimo na :

Slika 11g

Pritiskom na "Start" možemo započeti multiplexiranje, koje je u SVCD specifikacijama.

Onak tko je pazio na Sliku11, vidio je da TMPGEnc nije iskoristio maximalni mogući Muxrate od 348.600 Byte/s. Program je uzeo 286.500 Byte/s.
Ako je dovoljno, neka ostane.
 

 
Slika12: Paketna struktura bbMPEG

bbMPEG uzima postavke od 348.600 Byte/s. Onaj tko želi optimalni stream, može sa TMPEgom iskombinirati sa bbMPEG. Ako bbMPEG sam određuje Muxrate, tako on postavi 336.350 Byte/s kao optimum (samo u ovom primjeru).Dosta iznad TMPGenc (286.500 Byte/s) ali još uvijek unutar SVCD specifikacija. bbMPEG vas usput oslobodi , pri muxanju, od duplog headera, koji se pojavio na Slici7.

Za izmjenu VBV-a u sequenz headeru, koristite slobodno TMPGEnc beta 1.2 - morate samo još filmove iznova "muxati". 
Jedna stvar mora biti jasna, koja se "objašnjava" na Newsgrupama: novim muxanjem ne mjenjate kvalitet slike. Ona je određena samo postavkama korištenog enkodera. Muxiranje nije ništa drugo nego spajanje dva različita dijela. Znači slike su već kodirane. Dodatnim muxiranjem imate, eventualno, mogućnost ispravaka sinkronizacijskig grešaka tona i slike.

Ako vam film ubuduće bude trzao, znate koji postavku treba mjenjati.