[C++] MPEG rotatie

[riezebosch]

Ik heb een digitale camera waarmee ik filmpjes kan opnemen, maar ze niet kan draaien als ik hem op z'n kant heb gehouden. De enige software die ik hiervoor gevonden heb is een java programma wat .mov uitpoept. Nu wil ik dus (proberen) zelf een programmaatje te schrijven wat gewoon netjes de MPEG roteerd.

In eerste instantie leek het me wel leuk zelf uit te zoeken hoe de MPEG in mekaar zit, maar dat gaat me nogal te diep denk ik. Hiervoor had ik deze gevonden. Toen kwam ik op GoT deze tegen met een kant en klare MPEG encoder + decoder.

Maar mijn vraag is nu: is het echt nodig dat ik eerst het filmpje helemaal decodeer, roteer en daarna weer encodeer? Is het niet mogelijk gewoon de gecodeerde film te roteren? Heb sowieso nog niet uitgezocht met wat voor functies ik dat roteren zal moeten doen, zal wel iets met DirectX zijn...

[GarBaGe]

Is natuurlijk lastig... In principe is heb je voor iedere "beeld bewerkende actie" een decode en re-encode nodig, met kwaliteitsverlies....

Echter, ik weet dat IrfanView een lossless JPEG rotation functie heeft... En aangezien MPEG deels gebaseerd is op JPEG, is er wellicht een mogelijkheid om dat te doen...

[.oisyn]

Volgens mij kan het vrij makkelijk, als ik het goed heb verdeeld MPEG (en JPEG idd) een frame op in gelijke blokken, en doet daar vervolgens een frequentie-analyse op en haalt hier een aantal parameters uit, zodat het blokje tijdens het decoderen aan de hand van die parameters weer gereconstrueerd kan worden.

Als je een plaatje roteert verandert er natuurlijk weinig aan die parameters, je zult (even simpel gezegd) de parameters voor de x- en y-richting alleen even om moeten wisselen, en waar nodig negatief maken.

[riezebosch]

Dat was idd ook mijn idee. Maar ik weet niet goed hoe het bestand is opgebouwd en of ik dat zelf uit kan lezen. Misschien moet ik daarvoor de genoemde decoder is bekijken en of ik nuttige info eruit kan halen...

Maar is het niet zo dat de MPEG niet uit allemaal losse frames opgebouwd is? Dat zou het werk mijns inziens wel flink vergemakkelijken Maar ik dacht dat meer de verschillen tussen frames wordt bijgehouden (of is dat alleen bij DivX?).

[ Voor 37% gewijzigd door riezebosch op 24-02-2004 16:28 ]

[johnwoo]

Waarom niet gewoon virtualdub gebruiken met het rotate filter?

[Ernie98]

Of Adobe After Effects?

[riezebosch]

Haha, ik begreep ook van verschillende forums dat er niet echt veel programma's voor waren... Maar nu ik het idee heb opgevat, lijkt het me wel leuk om te maken Ook gelijk JPEG ratator erin en voila: heb ik mooie viewer voor m'n digicam (Sony DSC-P72 overigens).

[MSalters]

Nee, het is waarschijnlijk niet helemaal nodig. MPEG (MPEG2 in elk geval) deelt het signaal inderdaad in blokken op. Na wat initiele bewerkingen wordt het scherm opgedeeld in viekante blokken, waarna er een 2D fourier transformatie op wordt losgelaten. De stap die je jezelf kunt besparen is de Inverse FFT van het decoderen, en de FFT+quantisatie van het coderen. In plaats daarvan kun je de FFT vectoren zelf roteren.

[riezebosch]

Maar is MPEG dan uit allemaal losse frames opgebouwd (allemaal JPEG's achtermekaar gepklakt), of is het meer opgebouwd uit overgangseffecten?

@MSalters: ik zal nog ff op de termen die je gebruikt verder zoeken, heb namelijk nog niet van fourier transformatie, inverse fft en quantisatie gehoord...

[ Voor 38% gewijzigd door riezebosch op 24-02-2004 19:51 ]

[MSalters]

MPEG 2 is uit m'n hoofd een combinatie van I, B en P frames, waarvan een soort zelfstandige frames zijn en de rest overgangseffecten. MPEG 4 is ingewikkelder, wegens motion estimation.

[riezebosch]

Heb het gelezen ja, van I, B en P frames. Intra, Predicted en Bidirectional frames. Weet dus ook niet welke MPEG er uit m'n camera komen rollen. Zal wel MPEG2 zijn toch? MPEG4 is toch DVD?

edit:

Lees net in de specs dat het MPEG1 is

[ Voor 15% gewijzigd door riezebosch op 25-02-2004 23:25 ]

[Verwijderd]

Voordat je hieraan wilt beginnen moet je behoorlijk wat MPEG kennen. Ga d'r maar vanuit dat decoden, rotaten en encoden sneller is dan de voleldige MPEG-1 system & video specs leren.

En je kan blocks niet draaien omdat blocks ook een x en y richting hebben. Om die te draaien moet je elk blok alsnog decoden, en... Juist ja. . Ook de motion estimation routines moet je dan opnieuw doen omdat de x/y richting van je block verandert is en de motion richting (en dus de index uit je table) dus ook. Misschien valt er een minieme winst te pakken, maar ik zie niet in waarom je daar moeite in zou steken, want het kwaliteitsverlies heb je inmiddels toch al vanwege de block decoding.

[The Third Man]

riezebosch schreef op 25 februari 2004 @ 23:05:
Heb het gelezen ja, van I, B en P frames. Intra, Predicted en Bidirectional frames. Weet dus ook niet welke MPEG er uit m'n camera komen rollen. Zal wel MPEG2 zijn toch? MPEG4 is toch DVD?

edit:

Lees net in de specs dat het MPEG1 is

Nope DVD is echt MPEG2 hoor, VCD = MPEG1 en SVCD is ook MPEG2 (alleen heeft een lagere resolutie en max bitrate dan DVD). Kijk eens rond op dvdrhelp.com voor wat meer formaten kennis.

Allerlei JPEGs achter elkaar waar jij het over had is MJPEG (hetzelfde als animated GIF), wat vooral voor het capturen van tv output van consoles (Xbox/PS2 enz) wordt gebruikt, dit omdat de interlacing een MPEG compressie compleet in de soep zou laten lopen.

MPEG1 is redelijk simpele compressie, ik denk dat je mbv deze site wel genoeg te weten kan komen: http://www.chiariglione.org/mpeg/standards/mpeg-1/mpeg-1.htm

[riezebosch]

Nu is mijn vraag: waarom is er kwaliteitsverlies bij decoden en opnieuw encoden? Het hoeft toch niet zo te zijn dat er wanneer je algoritme er opnieuw overheen haalt weer meer informatie weggegooid wordt?

Klopt het dat er in DirectX (DirectShow) wel een MPEG decoder maar geen encoder zit? Anders zou ik misschien mooi hiermee alles kunnen doen...

edit:
Uit MSDN maak ik idd op dat er alleen een decoder in zit, en DirectX schijnt ook met zulk soort dingen supertraag te zijn...

Verwijderd schreef op 26 februari 2004 @ 02:14:
...En je kan blocks niet draaien omdat blocks ook een x en y richting hebben. Om die te draaien moet je elk blok alsnog decoden, en... Juist ja. . Ook de motion estimation routines moet je dan opnieuw doen omdat de x/y richting van je block verandert is en de motion richting (en dus de index uit je table) dus ook...

Maar als je het formaat goed doorhebt, moet het toch ook mogelijk zijn gewoon die motion richting te kantelen? (Heb me er nog niet zover in verdiept dat ik hier iets zinnigs over kan zeggen...)

[ Voor 59% gewijzigd door riezebosch op 26-02-2004 11:40 ]

[MSalters]

Verwijderd schreef op 26 februari 2004 @ 02:14:
En je kan blocks niet draaien omdat blocks ook een x en y richting hebben. Om die te draaien moet je elk blok alsnog decoden, en... Juist ja. . Ook de motion estimation routines moet je dan opnieuw doen omdat de x/y richting van je block verandert is en de motion richting (en dus de index uit je table) dus ook. Misschien valt er een minieme winst te pakken, maar ik zie niet in waarom je daar moeite in zou steken, want het kwaliteitsverlies heb je inmiddels toch al vanwege de block decoding.

Het probleem waar je tegenaan loopt is dat decoden nog wel goedkoop is, maar encoden, inclusief eventuele motion estimation e.d. nogal duur is.
Een rotatie over 90 graden daarentegen is de transformatie (x,y)->(y,-x) danwel (x,y)->(-y, x). Dat is numeriek triviaal; je 8x8 blokken bijven 8x8 enzo.

[The Third Man]

riezebosch schreef op 26 februari 2004 @ 10:40:
Nu is mijn vraag: waarom is er kwaliteitsverlies bij decoden en opnieuw encoden? Het hoeft toch niet zo te zijn dat er wanneer je algoritme er opnieuw overheen haalt weer meer informatie weggegooid wordt?

Nou, wat er gebeurt is dat de encoder een bepaalde bitrate moet halen, deze kan variabel zijn of constant.

Bij een constante bitrate gaat de encoder kijken hoe hij de beeldinformatie zo kan rangschikken en onderverdelen in B, I en P frames om zich aan die bitrate te houden, met zo min mogelijk kwaliteit verlies. Bij een variabele bitrate moet de encoder steeds weer een filtertje toepassen (meestal gebaseerd op hoe een mens details bekijkt) om zuinig met de bitrate om te gaan, of juist een wat hogere bitrate te gebruiken om de kijker het verschil niet te laten zien.

Welnu, als jij een film hebt naar MPEG hebt omgezet, is daarbij kwaliteit verloren gegaan, doordat er JPEG compressie op een frame is toegepast, en dat kan ook op de vervolgframes nog zijn gebeurd (als de bitrate nog te hoog was). Ga jij dat nu opnieuw encoderen, dan moeten al die artifacts (meestal te zien als wazige hagelslag rond dingen die bewegen) óók worden geencodeerd.

Dit wordt een probleem, want de encoder is niet zo intelligent om het verschil te zien tussen een artifact en een origineel detail. Op die manier worden er dus bij de hercompressie details die bij de 1e keer niet zijn vervaagd, alsnog vervaagd. Weliswaar is het minder ingrijpend dan in theorie (de encoder heeft namelijk soms wel door dat een artifact een artifact is doordat het een egaal blokje is), maar het is wel degelijk zichtbaar.

Je kan het zelf testen met JPEG, zoek een foto in png/bmp, zet die om naar JPEG, weer terug naar BMP en nog een keer naar JPEG.

[riezebosch]

Ik moet wel ff vermelden dat dit project tamelijk hoog gegrepen is voor mij. Het windows gedeelte zal nog meevallen, maar het uitzoeken van het MPEG formaat en de functies voor rotatie e.d. zal wat tijd kosten.
Daarnaast heeft het niet echt hoge prioriteit voor me, en is het ook meer een vorm van bezigheidstherapie Iig bedankt voor alle reacties, en als ik wat verder kom (of juist niet) laat horen jullie het weer

@MSalters: wat in je/uw laatste post staat was eigenlijk ook precies wat ik bedoelde, bij een 90 graden rotatie veranderd de film in principe niet. Alleen moeten de 8x8 blokken gekanteld en op andere positie geplaatst worden (en natuurlijk de motion-richting gewijzigd). Maar voor zover ik zie is dit wiskundig niet een hoogstaand algoritme...