Zuumi H.264 struktuur

[jaan]

Huvi pärast võrdlesin zuumist salvestatud Eetertv ja Astra LuxeTv HD klippe. Mõlemad on avc/H.264, kuid esimene neist tavaresoga 720x576 teine aga 1440x1080 interleaved. Kodumaine tavareso on pakitud AVC main 3.0 ja väljamaine poolHDreso main 4.0 profile tasemel.

Loomulikult oleks võrdluseks parem sama resoga striimid, kuid H.264 tavaresoga mujal maailmas eriti ei kasutata veel. Ja pealegi tuleb just selle võrdluse juures huvitav eripära välja.

Salvestasin klipid DVBviewer-iga transportstreamina ning eraldasin TSConverteri abil raw H.264 videostriimi, et audiopaketid ei segaks.

Need raw H.264 videostriimid laadisin Elecard StreamEye Toolsi

MPEG4 AVC/H.264 framestructure võrdlevast PILDIST on näha, et zuumi LuxeTV puhul on frame struktuur ühtlane (ajaskaala on piltidel erinev, et oleks paremini näha zuumi struktuuri)

I BBB P BBB P BBB I

I- Intra (punased) pildid e. I-pildid kodeeritakse kasutades ainult piltides eneses sisalduvat informatsiooni
P- Predicted (sinised) ehk etteennustatavad pildid on kodeeritud võttes aluseks eelmise I- või P-pildi. P-pildid kasutavad seega liikumis kompensatsiooni, mis võimaldab paremat kompressiooni kui I-pildid. Erinevalt I-piltidest võivad P-pildid levitada kodeerimisvigu, kuna nad ise on tuletatud ja ka neid kasutatakse tuletamiseks.
B- Biderectional (rohelised) ehk kahesuunalised pildid on kaadrid, mille tuletamiseks kasutatakse nii eelmist kui ka järgmist kaadrit. B-piltidega saavutatav kompressioon on suurim ja ei levita kodeerimisvigu, kuna nad ei ole kunagi võetud järgmise kaadri aluseks. Kahesuunaline ennustamine vähendab ka müra kuna ta moodustab kaadri kahe kaadri keskmise põhjal.
Kirjeldavad seletused võetud
Moving Picture Experts Group tutvustus

Zuumi Eetertv videostriimi struktuur on aga korrapäratu. Sisaldab rohkelt siniseid P ehk etteennustatavaid pilte. Intra (punased) piltite kaugus üksteisest on muutuv, vahel on neid vähe ja siis järsku 2 järjest.

StreamEye teatab LuxeTv korral "declared bitrate=8 728 576" (minu lõigu keskmine oli siiski 6,7 mega) , kuid zuumi striimi korral StreamEye ei teata keskmist (mõõdetud kesmine oli umbes 2,5 megabit/s). Suur erinevus muidugi mõistetav kuna resod erinevad aga ühel on märge striimis, teisel pole.

Ühesõnaga paistab, et pakkimise ideoloogia on täiesti erinev. Kas peabki nii olema arvestades 3.0 ja 4.0 AVC main profile kodeerimist ma esialgi öelda ei oska.

Loodan, et see inf on huvitav ja annab mõtlemisainet miks zuumi pilt on just selline nagu ta on.

P.S. Kui keegi ütleks ühe hea uploadi, siis paneks sinna paar zuumi klippi vaatamiseks.

[kanajuurikas]

P.S. Kui keegi ütleks ühe hea uploadi, siis paneks sinna paar zuumi klippi vaatamiseks.

http://www.gigasize.com/

[jaan]

eriti hull MTV klipp (12,6 MB)

Animal Planet (7,6 MB)

Eelmisele jutule liskaks. Tahan just rõhutada, et zuumi videostriimides on väga palju P ehk etteennustatavaid pilte, mis võimaldab suurt kompressiooni, samas aga tekitab digimüra ja pildi kvaliteet kannatab.
Tavalise MPEG2 korral on struktuur ühtlane nagu luxetv korralgi.

[wookie]

Eelmisele jutule liskaks. Tahan just rõhutada, et zuumi videostriimides on väga palju P ehk etteennustatavaid pilte, mis võimaldab suurt kompressiooni, samas aga tekitab digimüra ja pildi kvaliteet kannatab.

Jama.

Predicted frame'ga saab edasi anda täpselt samasugust informatsiooni nagu Intra frame abil. Tõsi, see ei ole alati eriti ökonoomne - mõnikord on juba lihtsam I frame teha. Seega on väide oma olemauselt vale - pilt pole kehv(või kannatada saanud kvaliteediga) mitte seetõttu, et seal on palju predicted frame'e vaid seetõttu, et see pilt on pakitud väikese bitrate'ga, mis tingib suured quantizer'i väärtused ja seega suure kompressiooni. Ehk siis - nendes P kaadrites ei ole piisavalt infot.

Otsus, millal teha I, millal P ja millal B kaader, tehakse (tavaliselt) sõltumata sellest, millise bitrate sisse peab tulemus ära mahtuma vaid hoopis lähtuvalt sellest, kui palju suudetakse kaadrist leida "ennustatavat" liikumist. Ehksiis, kui palju suudetakse liikumist kompenseerida lihtsalt juba olemasolevate makroblokkide liigutamise teel. Sellise liikumise otsimise algoritmi (motion search) ülesanne on leida kaadrist võimalikult palju alasid, mida ei pea uuesti saatma vaid võib liigutada.

Ehki Predicted kaader on tuletatud eelnevatest kaadritest, ei tähenda see automaatselt seda, et pakkimisvead peavad olema alati ja igal pool kulmineeruva iseloomuga. Nimelt võime me vaadata Intra kaadrit (mis ei ole mitte millestki tuletatud), kui erikujulist Predicted kaadrit - sellist, mille mitte ükski makroblokk ei saa oma väärtust liikumisvektori abil I kaadrist või mõnest eelmisest P kaadrist (jah, makroblokk, mis ei liigu, on liikunud 0 ühiku jagu; jah, mpeg4-avc korral ei pea P kaadri referents kaadriks olema eelmine P kaader).
Seega kirjutatakse ka P kaadrites infot osaliselt üle - kohtades, kus ei ole otstarbekas või võimalik saada soovitud tulemust mõnd olemasolevat makroblokki liigutades, saadetakse uus makroblokk, mis on samahea kui need, mis on I kaadris (tuletatus eelmisest kaadrist pole sellise makrobloki juures enam oluline). Seega on pakkimisvead suure arvu järjestikkuste P kaadrite korral häirivalt kulmineeruvad vaid nendes kohtades, kus pilt liigub väga vähe (näiteks hästi staatilised taustad). Kuid jällegi - suurendage lubatud bitrate'i ja selliste piltide staatilisuse defekt kaob.

Intra kaadriga algavat ning P või P ja B kaadritest koosnevat jada nimetatakse GOP'isk - Group Of Pictures.
MPEG2 süsteemides on GOP pikkus ja struktuur fikseeritud. MPEG2 puhul ei ole liikumise otsimine just mitte ilmtingimata väga täpne ning liikumisvektorite esitus on üsna piiratud, mistõttu tuleb Intra kaadreid saata tihedalt.
MPEG4 korral (nii ASP kui ka AVC süsteemides) on tavaliselt lühema GOP'i kui sadakond kaadrit tegemine puhas raiskamine - infot, mis ei muutu, pole mõtet uuesti saata. Kuna MPEG4 süsteemides saab GOP olla muutuva pikkusega, siis otsustabki pakkija alati, mis on otstarbekam, kas teha P või B kaader või alustada uut GOP'i.

Seega kokkuvõtteks kajastab GOP'i struktuur videoklipi omadusi, pakkija omadusi ning ka teatud määral käideldavuskompromisse (näiteks, mida pikem on GOP, seda kauem võib kesta kanalivahetus - uut kanalit ei saa enne näitama hakata kui I kaader on saabunud), kuid kvaliteeti määrab pigem siiski bitrate.

Muidugi, kui väikese bitrate sisse õnnestub pakkijal video piisavalt kvaliteetselt suruda, sõltub MPEG pakkija implementatsioonist ning häälestusel tehtud kompromissidest.

Ei saa väita, et väiksem Predicted kaadrite arv tagab alati parema kvaliteedi. Ei saa ka väita, et väiksem Predicted kaadrite arv tagab alati suurema bitrate

On tõenäoline, et kui me mõni neist jubedatest striimidest oleks pakitud suurema bitratega ega oleks enam nii jube, oleks neis endiselt samapalju P kaadreid.

Et võrrelda kahe erineva MPEG pakkija omadusi ja oskusi kaadritüüpide valikul ning üleüldse nende poolt produtseeritud streamist saadud visuaalset tulemust, on vaja neile sisendisse anda sama lähtesignaal.

P.S.

Tõesti, bidirectional kaadrid ei levita pakkimisvigu, kuid nad aitavad nende tekkimisele kaasa. Mida rohkem me topime P kaadrite vahele B kaadreid, seda pikemaks muutuvad liikumisvektorid ning seda ebatäpsem on nende abil saadud tulemus.
Üldiselt tundub, et on leitud, et maksimaalselt kaks järjestikkust B kaadrit on parim kompromiss - üks on liiga vähe (B kaadritel pole sellisena mõtet - nad ei annaks erilist kokkuhoidu), kolm on liiga palju (P kaadrites hakkaks liikumisvektorid mõttetult pikaks ja kasutuks minema - liiga palju saadetaks uusi makroblokke). MPEG4 korral antakse pakkijale tavaliselt ette just maksimaalne B kaadrite arv, mitte nõutud arv (pakkija võib näiteks max. 2 korral teha kõrvuti kas 0, 1 või 2 B kaadrit).

[jaan]

Tundub, et sa nagu oleks seda õppinud ja jagad üht-teist.

Seleta siis mulle, miks HDTV AVC/H.264 programmide GOP strukuur on ühtlane nagu minu esitatud LuxeTV HD.

Kui nüüd võrrelda LuxeTV HD bitrate ja zuumi oma taandatult per pixel, siis nagu vahet ei olegi. Vahe on aga visuaalne - pildis olulisemalt vähem artefakte luxe korral.

Ma ei tea kui pädev selline võrdlus on:

Luxetv HD 1440x1080=1 555 200
zuumi eetertv 720x576=414 720

1 555 200 / 414 720 = 3,75 korda pikslite erinevus

Ligikaudne keskmine bitrate:
Luxe 6,7mb/s
Eeter 2,5 mb/s

6,7/2,5=2,68

Ehk siis luxetv korral on piksleid 3,75 korda rohkem kui zuumi eetertv korral. Aga bitrate suhe on väiksema erinevusega. Luxetv korral on bitrate per pixel isegi kehvem kui zuumi korral. OK loeme, et bitrate suhe on ka umbes sama. Aga visuaalselt pole luxetv korral pakkimise jälgi nii tugevalt märgata kui zuumi korral.

Kas põhjus on erinevas kodeerimise algoritmis? Lihtsalt silmapete tingituna reso erinevusest? Või annab nii tugevalt tunda mpeg2 >H.264 ümberpakkimine zuumi korral?

Loomulikult oleks õige võrrelda täpselt sama klippi ja sama resoga erinevate pakkimis algodega. Kuid võrdlen seda mis kätte sattunud.

[wookie]

Seleta siis mulle, miks HDTV AVC/H.264 programmide GOP strukuur on ühtlane nagu minu esitatud LuxeTV HD.

Kas see on nõnda kõikide HDTV kanalite korral? Ma ei oska öelda, miks see antud kanali korral nii on. Kindlalt võib öelda vaid üht, kuna ilmselgelt on tahetud, et I frame'e oleks tihedalt, siis võiks IBBBPBBBPBBB tüüpi GOP struktuur üpris õigustatud olla. 3'e B kaadrit kõrvuti võib õigustada see, et MPEG4-AVC's võib referentskaadreid üsna vabalt valida.

Võimalikud põhjused sellise struktuuri kasutamiseks, mis mulle, ilma tausta teadmata, tõenäolised tunduvad:
* See pakkija, mis seda kanalit pakib, lihtsalt ei oska teisiti
* On soovitud, et pakkimisel tekkiv latency oleks võimalikult väike, mistõttu on GOP tehtud lühike (ja kui ta juba lühike on, siis miks mitte fikseeritud struktuuriga) - kuna mpeg4-avc korral saab referentskaadreid vabalt valida, peavad nad selleks olemas olema, mistõttu peab pika GOP'i korral signaali tugevalt puhverdama, mistõttu muutub latency suureks.
* On tahetud, et kanalivahetus oleks kiire - et vastuvõtja saaks peaaegu kohe I frame'i ja ei peaks ootama.
* On tahetud, et bitrate oleks ühtlane ja loodetakse, et fikseeritud GOP struktuur aitab sellele kaasa - kui palju selle kanali bitrate ajas kõigub?
* See signaal läheb mõnesse vastuvõtjasse, mis väga tahab, et GOP struktuur oleks fikseeritud (mis iganes põhjusel).

Kui nüüd võrrelda LuxeTV HD bitrate ja zuumi oma taandatult per pixel, siis nagu vahet ei olegi. Vahe on aga visuaalne - pildis olulisemalt vähem artefakte luxe korral.

Üks võimalik põhjus on see, et Luxe signaal sisaldab vähem müra. Müra on just see, mis teeb igasuguse digitv pakkimise keeruliseks.
Luxe esitab HDTV saateid, seetõttu on arvata, et see signaal tuleb HDTV kaamerast. HDTV kaamera võiks olla väga kvaliteetne ja müravaene seade. Seda signaali võiks olla töödeldud vaid digitaalselt, mistõttu töötlusel ehk müra lisandunud ei ole. Seetõttu on tõenäoline, et Luxe signaali on lihtsam pakkida kui kui zuumi kanaleid, mille lähtesignaal võib kurat teab kust pärit olla.

Ma ei tea kui pädev selline võrdlus on:

Luxetv HD 1440x1080=1 555 200
zuumi eetertv 720x576=414 720

Kui me vaataks vaid heleduskanalit, siis selline võrdlus kehtib. Tegelikult kehtib suhe ka värvuste korral, sest on tõenäoline, et mõlemate värviskeem on 4:2:0.

Ehk siis luxetv korral on piksleid 3,75 korda rohkem kui zuumi eetertv korral. Aga bitrate suhe on väiksema erinevusega. Luxetv korral on bitrate per pixel isegi kehvem kui zuumi korral. OK loeme, et bitrate suhe on ka umbes sama. Aga visuaalselt pole luxetv korral pakkimise jälgi nii tugevalt märgata kui zuumi korral.

Nagu öeldud, on tõenäoline, et Luxe lähtesignaal on oluliselt parem kui zuumi oma.

Kas põhjus on erinevas kodeerimise algoritmis? Lihtsalt silmapete tingituna reso erinevusest? Või annab nii tugevalt tunda mpeg2 >H.264 ümberpakkimine zuumi korral?

Jah, igasugune ümberpakkimine tekitab lisamoonutusi. Me kõik oleme näinud, milline pask on need MPEG2 kanalid, mis satilt tulevad - vaevalt, et need feedid, kust zuum oma kanaleid võtab, kuigipalju paremad on. Ümberpakkimisel reeglina kõik vead ainult süvenevad...

[greedy]

elik taheti s*tast saia teha aga välja tuli isegi mitte sepik vaid miski käkerdis

[wookie]

elik taheti s*tast saia teha aga välja tuli isegi mitte sepik vaid miski käkerdis

Võrrandi: X + sitt = sitt korral on X'i määramispiirkonnaks kogu reaalarvude hulk.

[tonuj]

eriti hull MTV klipp (12,6 MB)

Animal Planet (7,6 MB)

Eelmisele jutule liskaks. Tahan just rõhutada, et zuumi videostriimides on väga palju P ehk etteennustatavaid pilte, mis võimaldab suurt kompressiooni, samas aga tekitab digimüra ja pildi kvaliteet kannatab.
Tavalise MPEG2 korral on struktuur ühtlane nagu luxetv korralgi.

Mis programmiga seda kõvakettale salvestatud trasportstreemi vaada saaks

[jyri403]

Mul endal on Elecard mpeg player, sinna tuleb juurde installida veel mpeg4-avc plugin (http://www.elecard.com).

[tonuj]

eriti hull MTV klipp (12,6 MB)

Animal Planet (7,6 MB)

Eelmisele jutule liskaks. Tahan just rõhutada, et zuumi videostriimides on väga palju P ehk etteennustatavaid pilte, mis võimaldab suurt kompressiooni, samas aga tekitab digimüra ja pildi kvaliteet kannatab.
Tavalise MPEG2 korral on struktuur ühtlane nagu luxetv korralgi.

Ehk oled nõus ka ETV-d Zuumi pealt ühe lõigu salvestama

[jaan]

AK 5 min 116MB
http://www.gigasize.com/get.php/1193190 ... 700_ETV.TS

päris video lõpus ruudud tingitud ilmselt minu arvutist, kuna tegelesin salvestamise ajal liiga palju muude progedega

[tonuj]

AK 5 min 116MB
http://www.gigasize.com/get.php/1193190 ... 700_ETV.TS

päris video lõpus ruudud tingitud ilmselt minu arvutist, kuna tegelesin salvestamise ajal liiga palju muude progedega

Elecard ei taha seda millegipärast mängida, eelmisi mängis ilusti.
Ei aidanud ka uuest alla laadimine.

[andres66]

Neid MTV,Animal Planet ja ETV .ts faile saab viimase Nero 7-ga ka vaadata,
kes asjast huvitatud.

[jaan]

Elecard ei taha seda millegipärast mängida, eelmisi mängis ilusti.
Ei aidanud ka uuest alla laadimine.

AK klipp on salvestatud AltDvb-ga, eelmised aga DVBViewer-ga. Ilmselt mingi erinevus ts faili koostamisel.

Mediaplayer Classic näitab neid oma sisemise MPEG PS/TS/PVA source filter -ga koos eraldi installitud H.264 dekoodriga (Cyberlink, CoreAVC, Elecard-Mainconcept).