Van de praktische aspecten heb ik geen kaas gegeten. Het leek mij alleen wel leuk om te bedenken hoe je theoretisch gezien onder de gebruikelijke datacompressie-grens zou kunnen duiken. Zou het iets zijn om steeds alleen de veranderingen t.o.v. van een aantal karakteristieke shots en acties (gezichten, locaties, handelingen, etc.) te coderen - of wordt dit al gedaan?
Wel, van ieder afzonderlijke shot zijn er zogenaamde I-beelden. Dit zijn beelden die feitelijk als foto opgeslagen zijn. Na een I-beeld heb je een hele hoop P-beelden. Dit zijn beelden die enkel afhangen van beelden die ervoor gekomen zijn. Tussen die beelden zijn er ook nog de B-beelden, dat zijn de beelden die afhangen van beelden die zowel ervoor als erna komen.
Ieder beeld wordt opgesplitst in macroblokken, en voor die macroblokken wordt dan in andere beelden gezocht naar een stukje beeld die er goed op lijkt. (aangezien het beeld in 5 frames meestal niet veel verandert, lukt dat heel goed) Dan sla je op waar je je referentieblok kunt vinden, en het verschil tussen jouw blok en het referentieblok. Dit verschil kan in de praktijk zeer gemakkelijk gecomprimeerd worden in het frequentiedomein door linear predictive coding of door de hoge frequenties uit het beeld weg te laten. In de praktijk zien we daar maar weinig/geen artefacten van.
Dit alles is afgestemd om goed te kunnen de film comprimeren, maar ook om het decoderen niet te zwaar te maken. Let er op dat je ieder beeld waaruit je later nog stukken als referentie kunnen gebruikt worden opgeslagen moeten blijven in het geheugen van de decoder. Meer zelfs, voor B-beelden moeten al beelden vooruit berekend worden. Meestal beperkt men de zoekruimte dan ook tot enkele beelden, bv enkel de I-beelden.
Dit is grotendeels de manier waarop de MPEG codecs werken. Let ook dat het codeer algoritme hier heel zwaar is. Om voor ieder macroblok op zoek te gaan in 30 beelden naar het beste stukje beeld als referentie is heel rekenintensief. Voor 30 beelden van 1 megapixel heb je dan namelijk al ongeveer 30 miljoen stukjes die als referentie kunnen dienen. Grote compressie is dus meestal ook niet geschikt om uit te voeren op bv. camera's of gsm's.
Je merkt, in het klein word je idee al gebruikt. Maar videocodecs zijn iets die zich meestal op de rand van het mogelijke zitten. Ieder beeld vereist veel geheugen, en iedere vorm van compressie en decompressie loopt al snel tegen rekentechnische grenzen aan. Vrijwel nooit is de compressie zelf de grens, meestal\altijd zijn het de rekencapaciteiten aan beide kanten voor het coderen en decoderen die de begrenzing vormen.
[quote]Van de praktische aspecten heb ik geen kaas gegeten. Het leek mij alleen wel leuk om te bedenken hoe je theoretisch gezien onder de gebruikelijke datacompressie-grens zou kunnen duiken. Zou het iets zijn om steeds alleen de [i]veranderingen[/i] t.o.v. van een aantal karakteristieke shots en acties (gezichten, locaties, handelingen, etc.) te coderen - of wordt dit al gedaan?[/quote]
Wel, van ieder afzonderlijke shot zijn er zogenaamde I-beelden. Dit zijn beelden die feitelijk als foto opgeslagen zijn. Na een I-beeld heb je een hele hoop P-beelden. Dit zijn beelden die enkel afhangen van beelden die ervoor gekomen zijn. Tussen die beelden zijn er ook nog de B-beelden, dat zijn de beelden die afhangen van beelden die zowel ervoor als erna komen.
Ieder beeld wordt opgesplitst in macroblokken, en voor die macroblokken wordt dan in andere beelden gezocht naar een stukje beeld die er goed op lijkt. (aangezien het beeld in 5 frames meestal niet veel verandert, lukt dat heel goed) Dan sla je op waar je je referentieblok kunt vinden, en het verschil tussen jouw blok en het referentieblok. Dit verschil kan in de praktijk zeer gemakkelijk gecomprimeerd worden in het frequentiedomein door linear predictive coding of door de hoge frequenties uit het beeld weg te laten. In de praktijk zien we daar maar weinig/geen artefacten van.
Dit alles is afgestemd om goed te kunnen de film comprimeren, maar ook om het decoderen niet te zwaar te maken. Let er op dat je ieder beeld waaruit je later nog stukken als referentie kunnen gebruikt worden opgeslagen moeten blijven in het geheugen van de decoder. Meer zelfs, voor B-beelden moeten al beelden vooruit berekend worden. Meestal beperkt men de zoekruimte dan ook tot enkele beelden, bv enkel de I-beelden.
Dit is grotendeels de manier waarop de MPEG codecs werken. Let ook dat het codeer algoritme hier heel zwaar is. Om voor ieder macroblok op zoek te gaan in 30 beelden naar het beste stukje beeld als referentie is heel rekenintensief. Voor 30 beelden van 1 megapixel heb je dan namelijk al ongeveer 30 miljoen stukjes die als referentie kunnen dienen. Grote compressie is dus meestal ook niet geschikt om uit te voeren op bv. camera's of gsm's.
Je merkt, in het klein word je idee al gebruikt. Maar videocodecs zijn iets die zich meestal op de rand van het mogelijke zitten. Ieder beeld vereist veel geheugen, en iedere vorm van compressie en decompressie loopt al snel tegen rekentechnische grenzen aan. Vrijwel nooit is de compressie zelf de grens, meestal\altijd zijn het de rekencapaciteiten aan beide kanten voor het coderen en decoderen die de begrenzing vormen.
