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

[ahlstran]

Otin pakkaamattoman valokuvatiedoston ja tein uuden ison kuvan siten, että originaalin kopioita oli vierekkäin kylki kyljessä kiinni yht. 5kpl.

Tämän on tarkoitus kuvata videon aikajanaa. Jollakin omalla ohjelmalla tämä "diashow" voitais näyttää kuten elokuva.

Talletin uutena kuvana ja zippasin winzipillä. Kompressiosuhde oli 84%. Aika kova siihen nähden, että yksikään pikseli ei ole muuttunut, ja että kuvia oli vain 5 kpl. Pitempi otos laittaisi arvon helposti 98% pintaan, vaikka videossa jotain pientä liikettä olisikin.

5 erillistä jpeg-kuvaa veisi tilaa puolet vähemmän, eli pakkaussuhde olisi 92%. (MS Paint, laatuparametria ei voi vaihtaa)

Mitä lisä-arvoa mpeg:stä olisi ? Minusta tuo ajan mukana pakkaaminen on ajatusvirhe. Jos peräkkäisissä, tai missä tahansa frameissa on yhtäläisyyksiä, niin kyllä häviötön zippaus ne hyödyntää. Nuo liikkeen ennustukset yms mielestäni vaan vaikeuttaa editointia ja estää hardispakkaamisen multicore-piireillä. Eli mpeg on kohta historiaa ?

[TheKraken]

Nyt on kyllä niin sekava viesti, etten ihan taida tajuta kysymystä. Eli teitkö siis sen videon jo "jollain ohjelmalla" vai etkö tehnyt? Ja pähkäilet nyt sitä mihin muotoon se video kannattaisi laittaa? Sen voin sanoa, että raaka dv tai vastaava ja .zip ei todellakaan ole se paras vaihtoehto, oli sitten kuvia tai videota. Enkä ihan ymmärrä miksi teit tuon kylki-kylkeen homman jo ennen videosoftaan tuontia? Nythän ainut mitä videosofta voi tehdä on panoroida tuota reunasta reunaan.

Mpeg-pakkaus on ollut mennen talven lumia jo pitkään. Esim. h.264 tekee huomattavasti parempaa jälkeä huomattavasti pienempään tilaan.

Riippuu myös siitä mihin käyttöön tuo tulee. Jos se telkkarista tulee pihalle, niin eipä silloin kannata pakkailla, mutta jos sitä netissä katsellaan niin tottakai se on pakattava.

EDIT: Vai siis ajattelitko että et tee siitä videota vaan yrität jollain ohjelmalla tehdä siitä kuvan jota panoroidaan automaattisesti jollain katselulaitteella?

EDIT4: Ja h.264 on toki MPEG-johdannainen, vaikka tuosta nyt voisi muuta ymmärtää.

[ahlstran]

Yritin tuossa vaan ihmetellä, että kun zippaamalla näyttäisi saavan helposti yli 90 pakkaussuhteen häviöttömästi, niin miksi moni käyttää häviöllistä H.264-enkooderia tai muuta mpeg-johdannaista ?

Tein tuon videon (="diashown") monistamalla yhtä valokuvaa yhdeksi leveäksi bittikartaksi. Lopuksi zippasin tämän yhdistelmätiedoston.

Jos tänne palstalle saisi jotenkin kuvia, niin se selittäisi helposti. Mutta kun ne pitäisi vissiin kierrättää jonkun urlin kautta (?).

Vitsi on siinä, että videopakkausalgoritmit on aika tehottomia, kun ne etsii sitä taajuussisältöä vain pienistä blokeista. Etsisivät laajemmin. Pari proffaa ulkomailla onkin kirjoittanut 3D-pakkaamisesta. Sitä voi demota vaikka kopiomalla useita valokuvia samalle pohjalle. Yllättävän tehokkaasti pakkautuu, jopa häviöttömästi. Yleensä ajatellaan että häviötön pakkaus on vain jotain 50%. Mutta kyllä sen saa lähelle sataa.


.

[TheKraken]

Eiköhän se ongelma ole siinä, että koneiden tehot ei riittäisi täysin häviöttömässä pakkauksessa? Tai varmasti joidenkin, mutta ei kaikkien.

Ja siis ymmärsin kyllä mitä tuolle kuvallesi teit. En vaan ymmärrä miksi. Vieläkään en saanu selkoa siitä teitkö siis sen videon vai et, vai puhutko edelleen vain kuvan pakkaamisesta .zipillä, jota on minusta ihan turha verrata mihinkään videon pakkaukseen.

[Teppo Tulppu]

Elokuvat on aika harvoin sellaisia, että niissä on 5 samanlaista kuvaa rinnakkain, eli sellaista ei kannata ottaa lähtökohdaksi pakkausalgoritmin optimoinnissa. Sellaisella datalla mitä elävässä elämässä tulee vastaan, ei zippi pääse 90 prosenttiin.

Pakkausalgoritmin pitää olla myös sellainen, että se toimii käytössä. Nykyisellä raudalla h.264 saa isolla resolla koneet polvilleen. Tehokkaasta pakkausalgoritmista ei ole iloa, jos vaikkapa elokuvan pakkaamiseen menee nykyraudalla monta vuotta.

Lisäksi, h.264 määrittely tukee parempaa pakkausta kuin mitä sen implementaatiot tällä hetkellä osaa tehdä - h.264 enkooderia ei väsätä hetkessä.

[Jamac]

Otin pakkaamattoman valokuvatiedoston ja tein uuden ison kuvan siten, että originaalin kopioita oli vierekkäin kylki kyljessä kiinni yht. 5kpl.

Tämän on tarkoitus kuvata videon aikajanaa. Jollakin omalla ohjelmalla tämä "diashow" voitais näyttää kuten elokuva.

Talletin uutena kuvana ja zippasin winzipillä. Kompressiosuhde oli 84%. Aika kova siihen nähden, että yksikään pikseli ei ole muuttunut, ja että kuvia oli vain 5 kpl. Pitempi otos laittaisi arvon helposti 98% pintaan, vaikka videossa jotain pientä liikettä olisikin.

5 erillistä jpeg-kuvaa veisi tilaa puolet vähemmän, eli pakkaussuhde olisi 92%. (MS Paint, laatuparametria ei voi vaihtaa)

Mitä lisä-arvoa mpeg:stä olisi ? Minusta tuo ajan mukana pakkaaminen on ajatusvirhe. Jos peräkkäisissä, tai missä tahansa frameissa on yhtäläisyyksiä, niin kyllä häviötön zippaus ne hyödyntää. Nuo liikkeen ennustukset yms mielestäni vaan vaikeuttaa editointia ja estää hardispakkaamisen multicore-piireillä. Eli mpeg on kohta historiaa ?

Ylipäätään (vaikka en ole elämässäni koskaan tehnyt videota tai mitään liikkuvaa kuvaa) tulee mieleen että eikö iMovie tee justiinsa kivoja "diashow" leffoja DVD:lle esimerkiksi ja vaikka justiin iPhoton kuvakirjastosta?

[BlueTide]

Video vie julmasti tilaa. Mutta mitä vähemmän videota pakataan, sitä vähemmän se tyypillisesti vaatii konetehoa. Mutta vastaavasti putket internetistä täytyy olla julmetusti kovemmat ja kovalevyjä täytyy alkaa raidata. Esim pakkaamattoman filmiraidan datasiirtoon tarvitaan noin 300MB/s. CD-levyn verran tavaraa hujahtaa noin kahdesssa sekunnissa (tämä siis pakkaamatonta tavaraa).

Tehokkaammat pakkaustavat ottavat huomioon yksittäisten kuvien lisäksi myös temporaalisesti vaihtuvan datan jolloin päästään paljon parempiin pakkaussuhteisiin. Otathan nimittäin huomioon, että esim Motion-JPEG A on suhteellisen huono tapa koodata videota.

Loppukateettina, häviöllisen koodaamisen taustalla on pienentää datan määrää.

[ahlstran]

Tehokkaammat pakkaustavat ottavat huomioon yksittäisten kuvien lisäksi myös temporaalisesti vaihtuvan datan jolloin päästään paljon parempiin pakkaussuhteisiin. Otathan nimittäin huomioon, että esim Motion-JPEG A on suhteellisen huono tapa koodata videota.
.

Vastustan myös jpegiä samasta syystä, eli että se käyttää 8x8 tai 16x16 blokkia. Itse käyttäisin vaikka 1024x1024, ja "alue" kattaisi myös naapuriframeja. Tätä on 3D pakkaus, ja sattumalta zippaavat algoritmit on näin tehneet aina kiertoteitse (oliko se huffman, entropia vai aritmeettinen koodaus blokkivaiheen jälkeen). Kun pakataan yhtä ainoaa tiedostoa, niin on luonnollista että sitä pidetään yhtenä jatkumona.

Temporaalinen pakkaus on "turha" termi. Samankaltaisuuksia etsivät algoritmit hoitavat sen automaattisesti, jos vaan etsintä-alue ulottuu oman framen lisäksi menneisiin frameihin. Tätä on just 3D-pakkaus. Jos kuvissa on esim paljon taivasta, niin koko lohko on "1". Ja kaikki nurmikkoalueet on "2". Oli alue tai frame sitten mikä tahansa.

Elokuvat on aika usein sellaisia, että niissä on 500 samankaltaista kuvaa lähes peräkkäin, jos tarkasteluaika on suht pitkä. Esim asfaltti on asfalttia, nurmikko nurmikko, vesi vettä ja taivas taivasta.

"Nykyisellä raudalla h.264 saa isolla resolla koneet polvilleen". Näin on. Motion estimation vie 70-75% tehosta, ja paljonko siitä on hyötyä ? Ei juuri ollenkaan, ellei joku esine liiku täsmälleen kohtisuorassa tasossa kameraa vastaan. Niin turha kuin olla voi.

[Jamac]

En ole tosiaan mikään asiantuntija, mutta usein kun on noita Applen keynoteja katsellut tapahtumien jälkeen, ja lähetys on tökkinyt niin näkyy selvästi miten juuri se tausta on sama ja vain liikkuva osio (yleensä Steve Jobs) muuttuu. Eli tuon perusteella olen itse noita videokodekkeja ihmetellyt että aika älykkäästi ne toimii.

[BlueTide]

Temporaalinen pakkaus on "turha" termi. Samankaltaisuuksia etsivät algoritmit hoitavat sen automaattisesti, jos vaan etsintä-alue ulottuu oman framen lisäksi menneisiin frameihin. Tätä on just 3D-pakkaus. Jos kuvissa on esim paljon taivasta, niin koko lohko on "1". Ja kaikki nurmikkoalueet on "2". Oli alue tai frame sitten mikä tahansa.

Paitsi että nämä kehittyneemmät tavat eivät pakkaa alkuperäisiä kuvia vaan differenssitietoa, jolloin noista 500 framesta useimmat sisältävät helpommin pakkautuvaa tauhkaa kuin mihin tämä sun "3D" pakkaus pystyy. Temporaalinen ei terminä ole mitenkään turha, se kuvaa sangen näppärästi miten osa pakkaamisesta tapahtuu ja mitä tietoa voidaan hyödyntää.

Mitä sitten tulee tuohon JPEG:n blokkikokoon, niin käytäntö on näyttänyt että blokin kasvaessa pikseleiden korrelaatio vähenee ja pakkaustehokkuus suhteessa laatuun heikkenee merkittävästi. Lisäksi laskennasta tulee vaativampaa. Kannattaa näet muistaa, että pöytäkoneet eivät ole ainoita laitteita joiden pitäisi noita pystyä toistamaan.

[ahlstran]

Paitsi että nämä kehittyneemmät tavat eivät pakkaa alkuperäisiä kuvia vaan differenssitietoa, jolloin noista 500 framesta useimmat sisältävät helpommin pakkautuvaa tauhkaa kuin mihin tämä sun "3D" pakkaus pystyy. Temporaalinen ei terminä ole mitenkään turha, se kuvaa sangen näppärästi miten osa pakkaamisesta tapahtuu ja mitä tietoa voidaan hyödyntää.

Mitä sitten tulee tuohon JPEG:n blokkikokoon, niin käytäntö on näyttänyt että blokin kasvaessa pikseleiden korrelaatio vähenee ja pakkaustehokkuus suhteessa laatuun heikkenee merkittävästi. Lisäksi laskennasta tulee vaativampaa. Kannattaa näet muistaa, että pöytäkoneet eivät ole ainoita laitteita joiden pitäisi noita pystyä toistamaan.

No ensinnäkin tavallinen gzip tai winzip tallettaa koko clipin kuin yhtenä differenssipätkänä, joten en sitä vastusta, todellakaan. Mutta se toimii vain jos kaikki framet on samassa jatkumossa, eikä erikseen omina tiedostoina. Siksi yhdistin framet samaan kuvaan, jotta ne saatais samaan tiedostoon. Hakemiston tai tar-tiedoston zippaus ei jostain syystä pakannut tehokkaasti.

Pieni blokkikoko on fiksu, jos on varma että filmissä esiintyvää pienen pientä blokkia ei koskaan enää tule uudestaan. Esim taivaan palaa, seinän palaa, nurmikkoa, asfalttia tai vaikka varjoista pimeää kujaa (=mustaa aluetta).

[spindle]

OFFTOPIC:

onpas outoa juttua

[BlueTide]

Ei millään pahalla, mutta sun viesteistä alkaa olla enenevissä määrin hankalampaa ottaa selvää mitä oikein ajat takaa, mikä tässä nyt on epäselvää tai mikä on pointtisi. Kommenteissasi tuntuu myös olevan jatkuvasti asiavirheitä jotka tosin voivat olla aluperäiselle kysymyksellesi toissijaisia.

Kuten on jo todettu, puhdas MPEG alkaa olla menneen talven lumia, häviöllisen pakkauksen idea on pienetää tiedostokokoa ja kyllä, aikaisempia parempia pakkausmenetelmiä tulee vastaan aina silloin tällöin - en mä näe tässä nyt hirveästi mitään epäselvää.

[Fixx]

Ei tämä nyt niin epäselkoista ole... kysymys on vaan pakkausfilosofisesta kskustelusta. Vakinaamat vaan suhtautuu nyt tähän liian pragmaattisesti.

Ja ne mun viis senttiä: häviötön pakkaus toimii ihan hyvin jos videon sorsamateriaali on pakkaamatonta animaatiota. Sen sijaan mikä hyvänsä kuvattu materiaali sisältää sen verran kohinaa ja muuta muuttuvaa dataa, että framet ei kertakaikkiaan pysy lähelläkään identtistä. Sen takia joudutaan tekemään häviöllistä pakkausta -- jo ilmeisin toimenpide eli peräkkäisten freimien keskiarvoistus (esim kohinanpoisto) pienten muutosten osalta on tällaista häviöimistä.

Datan kohdalla ei voi ajatella, että "ruoho on ruohoa ja taivas taivasta", nuo ovat merkityksiä eikä mitään kuvadataa. Vaikka merkitys pysyy samana, kuvadatan sisältö voi muuttua rajusti, ruohot saattaa huojua tavalla, jota mikään algoritmi ei pysty ennustamaan.

Tietysti, jos tuohon suuntaan kuitenkin lähdetään tekniikkaa kehittämään, tullaan pakkausmetodeihin, joissa kuvadataa mallinnetaan korkeammalla tasolla. Eli kuva ei enää olekaan "todellista" vaan algoritmin alkuperäisen kuvadatan pohjalta luomaa simulaatiota.

[ahlstran]

> Datan kohdalla ei voi ajatella, että "ruoho on ruohoa ja taivas taivasta", nuo ovat merkityksiä eikä mitään kuvadataa. Vaikka merkitys pysyy samana, kuvadatan sisältö voi muuttua rajusti, ruohot saattaa huojua tavalla, jota mikään algoritmi ei pysty ennustamaan.

Esim H.264 yrittää ennustaa heilumista, eli kuvassa voi olla viittauksia max 32 framen päähän taakse. Tällai esim musiikkivideon välkkymiset pakkaantuu hyvin. Mutta skooppi yltää vain sekunnin päähän ja se on vähän. On oletettu että muisti on kallista. Ei se ole, voitais ihan hyvin viitata vaikka minuutin päähän taakse. Eteenpäin en viittaisi, koska se lisäisi latenssia. Sovellukseni on muuten valvontakamera. Kamera jököttää paikallaan, hyvin vähän liikettä. Korkeintaan pilvi menee auringon eteen, mutta kun pakkaa YUV-tasossa, niin värit ei muutu, pelkästään valoisuus.

>Tietysti, jos tuohon suuntaan kuitenkin lähdetään tekniikkaa kehittämään, tullaan pakkausmetodeihin, joissa kuvadataa mallinnetaan korkeammalla tasolla. Eli kuva ei enää olekaan "todellista" vaan algoritmin alkuperäisen kuvadatan pohjalta luomaa simulaatiota.

Mulle oli melkoinen yllätys ja oivallus tajuta että tavallinen huffman-koodaus etsii automaattisesti kaikki yhtäläisyydet ja etsii korkeimman tason mitä voi olla. On vaan tärkeää antaa sille laaja aineisto, eli ei pilkota kuvaa blokkeihin ja käsitellään menneet framet kuten nykyinenkin. Saadaan loistavat pakkaussuhteet vaikka onkin häviötön.

Voit kokeilla parhaiten PC-ympäristössä tekemällä panoraamakuvia Irfanview:llä. Siinä on valmis nappula. Laita sama kuva vaikka 5kpl ja talleta BMP. Sitten zippaa. Saat 85% häviöttömän pakkaussuhteen, mistä olen yli-innoissani, jos joku ei ole sitä huomannut.

Teen tässä omaa videoserveriä ja clienttiä. Voit määrittää ruudulle eri alueita, esim tähän suuri fps, tänne lossless alue, muualle normaali. Kaikki on ihan vapaata, ja toimii internetin yli.

[Teppo Tulppu]

Kaikkien yhtäläisyyksien etsiminen on vaan kallista. Jos vaikka hyväresoluutioinen leffa on 1920 x 1080 pikseliä, 24 framea sekunnissa ja kesto 100 minuuttia. Kysymys kuuluu onko siinä tismalleen samanlaisia 16 x 16 pikselin blokkeja. Joudutaan tekemään (n*(n-1))/2 vertailua missä n = (1920 x 1080 x 24 x 60 x 100)/(16 x 16) ja se on ISO luku. Tämä on tietenkin ääriesimerkki, mutta parhaan huffamann-koodauksen tekeminen on tuollaiselle datamäärälle kohtuullisen aikaavievä operatsiooni. Hakuavaruutta ei voi muuttaa mielivaltaisuuden suureksi ilman että laskenta alkaa viedä ikuisuuksia.

[Troubleman]

Elokuvat on aika usein sellaisia, että niissä on 500 samankaltaista kuvaa lähes peräkkäin, jos tarkasteluaika on suht pitkä. Esim asfaltti on asfalttia, nurmikko nurmikko, vesi vettä ja taivas taivasta.

No tuo nyt ei pidä alkuunsakaan paikkansa. Mitä isommaksi reso kasvaa sitä tarkemmin alkaa näkymään esim. filmin rae, joka taas on täysin satunnainen ilmiö ja muuttuu joka framessa.

Paras algoritmi lienee se joka saa filmirakeesta ja videokohinasta miellyttävimmän näköisen lopputuloksen.

Se virhe tehdään monesti televisiossa että kuvaa terävöitetään liikaa ja pakataan sen jälkeen, kun pitäisi tehdä niin että kuva pakataan "pehmeänä" ja terävöitetään katsomisvaiheessa.

[Troubleman]

Vastustan myös jpegiä samasta syystä, eli että se käyttää 8x8 tai 16x16 blokkia. Itse käyttäisin vaikka 1024x1024, ja "alue" kattaisi myös naapuriframeja. Tätä on 3D pakkaus, ja sattumalta zippaavat algoritmit on näin tehneet aina kiertoteitse (oliko se huffman, entropia vai aritmeettinen koodaus blokkivaiheen jälkeen). Kun pakataan yhtä ainoaa tiedostoa, niin on luonnollista että sitä pidetään yhtenä jatkumona.

No jos vertaa zip-pakatun TIFFin ja melko hyvälaatuisen jpegin tiedostokokoa (esim. photoshopissa laatu 9-10) niin ymmärtää kyllä syyn jpegin suosiolle zip-systeemeihin verrattuna.

Sitäpaitsi jpegissä ei ole käytännössä mitään vikaa, saa kyllä tosi tarkasti tihrustaa jos meinaa erottaa maksimilaadulla pakatun jpegin 8-bittisestä TIFFistä.

Takavuosinahan oli tulossa uusi formaatti JPEG2000, joka jäi tosin lyömättä läpi.

[ahlstran]

1) Yksittäinen kuva ei zipillä paljon pienene. Mutta kun otat toisen, joka on melkein samanlainen (esim 300fps:llä ne on hyvin samanlaisia), niin jälkimmäinen kuva lisää pakettia pariaatteessa pari tavua. Miksi joku kuvaisi 300fps ? Siksi jotta kuvat olisi samanlaisia.

2) HDTV-tasoinen video voi olla pienen pieni, jos osaa kuvata, kuten Applen PC vs MAC mainokset. Ei ole sattumaa, että ne esitetään tasavärisen taustan edessä, ja jopa lattia ei erotu takaseinästä.

Koska tausta ei liiku, niin eihän sen pitäisi viedä kaistaa. Kerran lähetetty ja sillä selvä. Mutta koska noita pääframeja lähetetään muutaman sekunnin (tai 1) välein (aargh), niin siksi on edullista laittaa tasavärinen tausta. Kyllä ne Applella osaa nämä kiertotiet, kun pitää tehdä mainos nettilevitykseen.

[ahlstran]

Voisko joku (TheKraken?) katsoa parista Mac vs PC mainosclipistä, että paljonko tavuja menee ääniraidalle, ja paljonko kuvalle.

Kiitos, en osaa itse eikä ole ohjelmiakaan.

Jos joku teistä tekee mainosta tai draamaa mobiili-tv:hen, niin suosikaa Kaurismäki-elokuvien tyyppistä keskustelutahtia. "Arvotaan seuraava lause".

Ja suosi iltakuvauksia. 80% ruutua saa olla mustaa. Näyttäkää paljon taivasta, mutta vältä veden kuvaamista. Vesi on aika ärsyttävän herkkäliikkeistä, pakkaantuu huonosti, varsinkin jos aurinko kimaltelee.

[Troubleman]

1) Yksittäinen kuva ei zipillä paljon pienene. Mutta kun otat toisen, joka on melkein samanlainen (esim 300fps:llä ne on hyvin samanlaisia), niin jälkimmäinen kuva lisää pakettia pariaatteessa pari tavua. Miksi joku kuvaisi 300fps ? Siksi jotta kuvat olisi samanlaisia.

Mutta kun ne kuvat ei ole samanlaisia varsinkaan filmillä jos niitä syynätään tarpeeksi läheltä vaan randomia filmiraetta. Jo DVD-resoluutiolla aiheuttaa nopean filmin rae kaikenlaista hankaluutta. Riippuu sitten masteroinnista ja bittivirrasta miten siedettävää sen katsominen on.

Ei ole sattumaa, että ne esitetään tasavärisen taustan edessä, ja jopa lattia ei erotu takaseinästä.

Niin, samasta syystä lienee suuri osa Applen brändistä rakentuu valkoiseen väriin?

[ahlstran]

Niin, samasta syystä lienee suuri osa Applen brändistä rakentuu valkoiseen väriin?

Valkoinen tai vihreä, pääasia että on tasavärinen.

Onhan se vähän outoa jos sisältö sovitetaan siirtotiehen, mutta kun ei ole vedetty valokaapeleita koteihin, niin tässä sitä ollaan.

Nämä minun zippausjutut toimii siis lähinnä valvontakameroissa, ei yleiskäytössä. On ajatusvirhe pyrkiä yleiskäyttöön. Yksi vakiokaapu kaikille vaatteeksi ? Toimiihan se, mutta räätälöinti johtaa parempaan lopputulokseen.

[Teppo Tulppu]

Jos joku teistä tekee mainosta tai draamaa mobiili-tv:hen, niin suosikaa Kaurismäki-elokuvien tyyppistä keskustelutahtia. "Arvotaan seuraava lause".

Ja suosi iltakuvauksia. 80% ruutua saa olla mustaa. Näyttäkää paljon taivasta, mutta vältä veden kuvaamista. Vesi on aika ärsyttävän herkkäliikkeistä, pakkaantuu huonosti, varsinkin jos aurinko kimaltelee.

Näyttelijöille pitää myös muistaa sanoa, etteivät he saa liikkua.

[plussa]

Jatkakaa samaan malliin, näin levotonta läppää on hauska seurata...

[Teppo Tulppu]

Jatkakaa samaan malliin, näin levotonta läppää on hauska seurata...

Sori, ei ollut tarkoitus.