Het wordt misschien wat technisch, maar H.264 gebruikt bijv. arithmetic coding (een techniek om via kansberekening een bepaalde eenheid aan gegevens zo effectief mogelijk op te slaan
Om het nog maar wat technischer te maken: wat je zegt klopt ook niet helemaal. De vorm van arithmetic coding die door H264 gebruikt kan worden (variable length coding is overigens ook nog steeds mogelijk met H264), is niet gebaseerd op kansberekening, maar op frequentie en re-normalisatie. Met andere woorden: door te tellen welke symbolen hoe vaak worden gecodeerd, en deze statistieken on-the-go bij te werken. Er wordt dus nooit iets voorspeld, en er komt geen kansberekening bij kijken.
eigenlijk een implementatie van de theorie van Shannon dat entropy (de onvoorspelbaarheid van informatie) uitgedrukt kan worden in een getal)
Het tweede gedeelte van je opmerking klopt, het eerste deel is nogal nietszeggend omdat simpele variable-length coding (zoals bijvoorbeeld run-length coding, waarbij je niet 10,10,10,10 opslaat maar bijvoorbeeld -1,10,4) op precies dezelfde manier is gerelateerd aan de theorie van Shannon. In principe elke vorm van compressie is dat eigenlijk.
terwijl de oudere MPEG4 varianten een andere encoding geimplementeerd hebben die voor een PC beter performd, maar waarbij de compressie slechter is
Vergelijkbare encoding manieren zijn nog steeds ook onderdeel van de H264 specs, en in sommige profielen zelfs de enige optie (bijvoorbeeld de profielen die specifiek voor low-bitrate streaming video zijn), inderdaad vooral omdat arithmetic coding behoorlijk zwaar is en bepaalde profielen specifiek voor low-power devices bedoeld zijn.
Maargoed los van dit hele technische verhaal gaat dit alleen maar over het comprimeren van de bitstream, en dit is maar een relatief klein gedeelte van de efficientie van een encoder. Veruit de meeste winst valt te halen in het in de eerste plaats zoveel mogelijk beperken van die (ongecodeerde) bitstream, vooral door zoveel mogelijk redundatie uit het signaal te halen, en de data van je video-signaal op een andere manier te representeren, zodat je meer redundantie kunt creeeren zonder al te veel signaalverlies te introduceren.
Het verschil in de compressie van de bitstream tussen een complexe, zware encoding zoals CABAC (context-adaptive binary arithmetic coding) zoals gebruikt kan worden met H264, vergeleken met een veel envoudigere run-length encoding, is hooguit 10%. En dat is dan niet 10% op de ongecodeerde video, maar 10% op de bitstream na het encoden van de video. Dat is zeker niet waar H264 zijn grote winst haalt, de motion prediction (forward en backward tot ik geloof 4 frames), subpixel motion vectors, meer motion vectors per macroblock, en het veel uitgebreidere gebruik van slices (aaneengeschakelde macroblocks) maken echt veruit het grootste verschil.
Edit: @dj_tjerk:
Dat klopt inderdaad, een typische videocodec met zowel forward als backward-prediction kan doorgaans 3 verschillende 'frames' bevatten: I-frames, P-frames en B-frames, en deze frames worden samen gebundeld in een group-of-pictures (GOP), die typisch 1 I-frame plus een aantal P en/of B-frames bevat. De I-frame is grofweg gecodeerd als een JPEG-plaatje en heeft dus minimaal kwaliteitsverlies, het enige verlies aan kwaliteit komt uit de compressie van het plaatje, en er is geen kwaliteitsverlies door motion compensation. Een P (predicted) frame bevat een veld van motion vectors, die naar macroblokken in een vorig frame verwijzen, en slechts het verschil tussen het gewenste blok in het het P-frame met het frame waar naar wordt verwezen, wordt gecodeerd. Omdat dit verschil veel kleine waarden en veel 0-en bevat, is het heel efficient te coderen. Een B (bi-predicted) frame werkt hetzelfde maar kan zowel naar vorige als naar volgende frames verwijzen. De frames waarnaar verwezen wordt zijn trouwens altijd I- of P- frames, een predicted frame kan nooit naar een B-frame verwijzen.
Een typische GOP bevat zo rond de 15 frames en begint altijd met een I-frame, gevolgd door een aantal P-frames, gevolgd door een aantal B-frames De codeer volgorde hoeft niet hetzelfde te zijn als de display volgorde, en bij B-frames is dit per definitie niet zo. Een GOP die gecodeerd is als IPPPBBB, zou bijvoorbeeld heel goed als IBPBPBP kunnen worden weergegeven, waarmee de mogelijkheid van frames die naar toekomstige frames verwijzen is verklaard ;-)
[Reactie gewijzigd door johnbetonschaar op 29 juli 2024 01:31]