Mitä järkeä on häviöllisessä videopakkaamisessa ?

[plussa]

Sori, ei ollut tarkoitus.

Tarkoitin lähinnä ahlstrania tuolla kommentillani...

[Teppo Tulppu]

Tarkoitin lähinnä ahlstrania tuolla kommentillani...

No sori sitten vaan ahlstraninkin puolesta.

[Jamac]

Joka tapauksessa on täysin varmaa, että meitä asiantuntevammat tahot ja "rohvessoorit" on miettineet tämän kyseisen pakkausasian aika pitkälti tarpeeksi monelta kantilta ja kehittäneet kodekin joka on optimaalinen suhteessa tämän hetkisiin tarpeisiin ja laitteistovaatimuksiin.

Jo pelkästään se että yritetään ohjelmallisesti selvittää se että voidaanko jokin alue ryhmästä freimejä pitää muuttumattomana vai ei, menee jo meikäläisen normäälin päättelykyvyn ulkopuolelle.

Siihen kun liittyy monta ulkoista "muuttujaa", esimerkiksi jos kuvataan joku kohtaus "X" kahdella eritasoisella kameralla samaan aikaan, voi olla että huonolaatuinen kamera näkee tasaisen sinisen taivaan, mutta huippulaatuinen kamera taas näkee paljon eroja ja muutoksia taivaassa. videokodekki taas on 100% irrallaan tästä kontekstista ja ei pysty millään nykytieteen tuntemin keinoin tietämään kummasta tapauksesta on kyse (huonosta kamerasta, huippukamerasta, vai Sonyn ensivuonna julkaisemasta tsiperhyperlaatuisesta kamerasta).

[ahlstran]

Joka tapauksessa on täysin varmaa, että meitä asiantuntevammat tahot ja "rohvessoorit" on miettineet tämän kyseisen pakkausasian aika pitkälti tarpeeksi monelta kantilta ja kehittäneet kodekin joka on optimaalinen suhteessa tämän hetkisiin tarpeisiin ja laitteistovaatimuksiin.

Ei tarvi olla asiantuntija, että voi kommentoida. Voi esim ihmetellä että miksei rohvessoorit keksineet H.264:sta monta vuotta aikaisemmin, jos he kerran ovat niin fiksuja.

Yleiskäyttöalgoritmit on aina kompromisseja. Painotetaan hyvää pakkaussuhdetta, kuvan laatua tai purkamisen keveyttä. Kaikkia ei voi saada. Koska mobiililaitteet on nykyään komponenttikehityksen veturi, niin pian ne ovat myös algoritmikehityksen veturi. Siellä kamera ei ole jalustalla, vaan heiluu, ja energian kulutus on olennaista. Nämä vaikuttaa aika paljon.

Yleiskäyttöalgoritmeissa ei ole oikein mitään laitteistovaatimuksiin liittyviä piirteitä. Tästähän juuri kerroin, kun ennustin että mpeg kuolee, koska algoritmeja ei voi jakaa fiksusti usean coren välille. Lisäksi kannattaisi ottaa huomioon välimuistin koko jo silloin kun algortimia suunnitellaan. Joku voisi alkaa suunnittelemaan algoritmia Cavium Octeon CN5860 piirille, jossa on 16 corea. Tai Sun Niagara2 -piirille, jossa on 8 corea, ja jokainen ajaa 8 säiettä, eli yht 64 säiettä samaan aikaan.

Kun ihminen näkee koivun, niin hän ajattelee että tuolla on koivu, eikä sellaista ja sellaista pikselimössöä. Siinä on tieto tiivistetty esimerkillisesti. On ihan se ja sama, mihin suuntaan pikkuoksat sojottaa. Ketä se kiinnostaa ? Tai että heiluuko lehdet. Koivu on havaittu, se on tietyssä paikassa, ja kaikki muu on turhaa.

[Jamac]

Ei tarvi olla asiantuntija, että voi kommentoida. Voi esim ihmetellä että miksei rohvessoorit keksineet H.264:sta monta vuotta aikaisemmin, jos he kerran ovat niin fiksuja.

Ehkä kuluttajien rauta ei ollut valmis H.264:n vaatimiin tehoihin, eikä asioita yht'äkkiä keksitä, vaan asioita tehdään sitten kun siihen on rahoitusta ja asiakkaita ja ja ja...

Kysymys ei ole siitä että jotain ei osatttaisi tai pystyttäisi teoreettisella tasolla tekemään. Kyse on reaalimaailman tilanteesta.

Labrassa pystyttäisiin tekemään vaikka heti täysin futuristisia jumalattoman tehokkaita ja pieniä tietokoneprosessoreita, mutta niitä vaan ei kannata tehdä kun ne maksaisi hunajaa ja kukaan ei niitä ostaisi. Intelillä on tälläkin hetkellä sataprosenttisen varmasti valmiina muutaman vuoden päästä myyntiin tulevia prossuja, mutta ensin pitää saada myytyä vanhat pois ja kuolettamaan tuotekehityskustannukset.

[Troubleman]

Joku voisi alkaa suunnittelemaan algoritmia Cavium Octeon CN5860 piirille, jossa on 16 corea. Tai Sun Niagara2 -piirille, jossa on 8 corea, ja jokainen ajaa 8 säiettä, eli yht 64 säiettä samaan aikaan.

Saakos tuommoisen piirin asennettuna pöytälaitteeseen ~200 eurolla? (Tuo kun on se kynnyskysymys joka rajoittaa koodekkien suunnittelua)

[Jamac]

Niin, siis kodekkien pitää toimia nykyään kännykkätasoisissa laitteissa..

[kampela]

Kun ihminen näkee koivun, niin hän ajattelee että tuolla on koivu, eikä sellaista ja sellaista pikselimössöä. Siinä on tieto tiivistetty esimerkillisesti. On ihan se ja sama, mihin suuntaan pikkuoksat sojottaa. Ketä se kiinnostaa ? Tai että heiluuko lehdet. Koivu on havaittu, se on tietyssä paikassa, ja kaikki muu on turhaa.

Aika vahvasti sanottu. Kuvittelen minäkin olevani ihminen vaikka katselen koivua ihan eri tavalla. Minua kiinnostaa oksien suunta, väri ja heiluminen ja moni muukin asia.
Kun ihminen näkee koivun, hän taatusti näkee sen eri tavalla kuin toinen ihminen. Siitä pitää jo yksinomaan geeniemme erot huolen ympäristön vaikutuksista puhumattakaan.

Onneksi on sekä yleisiin tarkotuksiin, että erityistarkoituksiin olevia asioita. Markkinoilla on paljon laitteita joihin soveltuu vain jokin erityistoiminta. Minusta on mukavaa, että kuvan pakkaustavat ovat yleisiä niin, että minäkin voin katsoa elokuvia melkein minkälaisilla laitteilla tahansa enkä ole sidottu vaikkapa vain transmetan prosessoreja sisältäviin laitteisiin.

[ahlstran]

Jotta ei menisi ihan jorinaksi, niin tässä konkreettisia ehdotuksia, että mitä pitäisi tehdä.

- jos videota on tarkoitus siirtää langattomasti, niin algoritmin pitää ottaa huomioon että virheitä tulee paljon, yleensä ryöppyinä, eikä kaikkia virheitä voida korjata. Silloin pitää pelastaa niin paljon kuin voidaan, ja levittää virhe suurelle alueelle ja eri aikatasoille, jolloin silmä ei sitä havaitse. Esim ensin lähetetään aina matalan tarkkuuden kuva ja sen jälkeen tarkennusta, kuten Google Earth tekee. Lomitettu kuva piilottaa kans virheitä, siksihän PAL sitä käyttää. Pakkausalgoritmi voisi lisäksi pakata kuvan keskialueen vikasietoisemmalla tavalla, koska sinne silmä yleensä kohdistuu. Erityisesti jos jakelutie on UDP eikä TCP.

-jos langaton kaista on lisäksi niukka, niin sinne pitää sitten mahtua. Algoritmin pitää osata priorisoida että mistä tingitään, tai sallia editoijalle vaikutusmahdollisuus. Värisyvyydestä, frame ratesta, kuvan laadusta, kuvan koosta vai mistä. Ei ole katastrofi jos pellon yksityiskohdat ei näy, mutta kasvojen yksityiskohdat pitää näkyä. Väribittien seassa voisi olla tärkeysbitti, jonka editori asettaa alueille kun tekee vaikka DVD:n värierottelua. Kyllähän Quicktimea voi säätää, mutta se on yksi sovellus, tämmöistä ei ole standardoitu, joten muut playerit ei kaikkea .mov-hienouksia ymmärrä esim fast start.

-jos videota purkaa akkukäyttöinen laite (=esim känny DVB-H vastaanotossa), niin algoritmi pitää olla sellainen, että purkaminen on energiatehokasta. Energiatehokkuutteen päästään jos on monta corea, ja kaikissa pieni kellotaajuus. Myös muistin käyttö saisi olla suht pientä. Purkaminen pitää siis olla mahdollista tehdä usealla corella joko rinnakkain tai liukuhihnalla tai sekä-että. Lisäksi tietenkin laskennallisesti kevyt purkutapa mitä h.264 ei ole.

-jos videota pakkaa akkulaite, esim normaali digivideokamera, niin pakkaaminen saisi olla energiatehokasta. Ei missään nimessä täyden resoluution SAD-laskentaa, väriavaruuden muunnoksia, monimutkaisia kohinanpoistoja tai lyhyttä tarkasteluskooppia kuten DVD:ssä pikakelauksen tarpeiden takia.

- low latency pakkaus esim videokonferenssi, vaatii täysin omat algoritmit. Sekä pakkaus että purku pitää olla vahvasti rinnakkaistettua,ja algoritmin pitää osata yhdistää usean kameran kuvaa samaksi bittivirraksi. Tarvitaan tekstuuri-cache (nurmikko, asfaltti, taivas, pimeää aluetta jne =256 yleisintä taustamateriaalia. Valitaan paras, vaikka olisi väärä.

-urheilukuvauksessa pitää olla oma menetelmä. Pingispallon, tennispallon tai jalkapallon näkyminen on ykkösprioriteetti. Moni algoritmi luulee nopeaa liikettä kohinaksi ja poistaa koko pallon.

-militaarikäytössä ei saa käyttää punasilmäisyyden poistofiltteriä, koska punaiseksi itsensä maalannut vihollinen tulee täysin näkymättömäksi. Maastopukuiset näkee käytännössä vain jos on häviötön pakkaus ja paljon värisyvyyttä vihreälle. Liike pitää myös nähdä aina, joten sitä voisi jopa korostaa. Yökuvaus täysin räätälöidyt algoritmit.

-tutka-, ultraääni-, infrapuna-, röntgen ja suurnopeuskameroiden pakkaus on tehotonta. H.264 seuraajaan saisi laittaa paljon uusia parametreja ja profiileja, jos se meinataan tehdä OIKEASTI yleiskäyttöiseksi. Esim röntgen vaatii usein yli 15-bit dynamiikan harmaasävyille.

-hyvä pakkausalgoritmi osaisi kompensoida tai huomioida optiikan puutteita. Esim ei yritä esittää suurempaa kuin mihin optiikka pystyi. Esim USB-kameroiden surkeaa laatua pakataan turhankin tarkkaan. Eli adaptiivisuutta.

-liikkeen ennustus pitäisi olla sellaista, että algoritmi huomaa liikkeen, ja ennustamisen sijasta antaa liikealueelle automaattisesti lisää resoluutiota, päivitysnopeutta ja taajuuskomponentteja. Taustan (=kameran) liike kannattaa huomata sensoreilla, joiden data linkitetään lähetysvirtaan, jotta ne voidaan purkamisssa huomioida. Tarvitaan siis kuva ja ääniraidan lisäksi sensoriraita.

-pakkausalgoritmi voisi olla linjassa videoserverin ominaisuuksiin. Esim pakettikoko.

[kampela]

Jotta ei menisi ihan jorinaksi, niin tässä konkreettisia ehdotuksia, että mitä pitäisi tehdä.

Miksi pitäisi tehdä? Kuka hyötyisi siitä työstä jota pitäisi tehdä pakkausalgorytmien parantamiseksi? Kuka sen maksaisi?

Yksi ristiriita parempien pakkausmenetelmien kehittämisessä syntyy siitä, että samaan aikaan välitysverkot paranevat ja pakkauksen tarve vähenee. Esimerkkinä vaikkapa digitaaliset televisiolähetykset. Kun käytettävistä taajuuksista on pulaa, digitalisointi tällä huonolla mpeg2 pakkausmenetelmällä lisäsi kapasiteetin lähetinkohtaisesti nelinkertaiseksi. Lisäksi voidaan käyttää samoja taajuuksia lähempänä toisiaan, jolloin kanavia vapautuu taas lisää. Samaan aikaan on nähtävissä, että halukkuutta uusien kanavien käyttöön ei Suomen kokoisessa maassa ole kovin runsaasti. Kapasiteettia laadun parantamiseen, jos sellaista tarvetta tulee, on ihan riittävästi. Parempia pakkausmenetelmiä ei siis tv-lähetyksiin tarvita. Jos kysyntää ja maksukykyä löytyy, löytyy myös kiinnostusta parempien menetelmien kehittämiseen.

[j.a.j.]

esittämissäsi vaateissa koodekkia varten on aika monta ominaisuutta joista olisi varsinkin ammattikäyttäjille iloa. esim. se että käyttäjä pääsee priorisoimaan sen mistä tingitään.

tässä on kuitenkin kaksi haastetta. vaikka olisikin mahdollista luoda tehokas pakkaus jonka purkaminen on mahdollista pientä laskentatehoa vaativalla koodekilla on vaikea kuvitella että noilla kaikilla featureilla varustettu pakkaaja olisi kovinkaan kevyt. vaikka laskenta olisi jaettu useammalle corelle, niin esim. 1080p resolle REAALIAJASSA pakkaaminen kyykyttäisi sen verran monta corea että videokameroista tulisi taas raahattavia jotta kaikki mahtuvat pakettiin.

toinen haaste on se, että feature-määrä ei lisää sovelluksen ohjelmoinnin monimutkaisuutta lineaarisesti vaan eksponentiaalisesti.

[mluttinen]

Olisi kyllä mielenkiintoista seurata sivusta kuinka lämpimästi jonkun elokuvan ohjaaja ja kuvaaja ottaisivat vastaan neuvoja kuvan sisällön merkityksestä sen myöhempään pakkauslaatuun...