Für meine Bachelor-Arbeit implementiere ich eine Huffman-Dekodierung für MP3s in VHDL. Dabei sind als Nebenprodukt angepasste Huffman-Tabellen für den Helix MP3 Dekoder abgefallen. Ich habe mir den Dekoder genommen um meine berechneten Tabellen zu prüfen. Das Prinzip der Dekodierung ist im Grunde das gleiche geblieben wie beim original Code. Folgende Dateien habe ich im Dekoder geändert: hufftabs.c - Neue Huffman-Tabellen huffman.c - Anpassung der Big-Value Dekodierung (DecodeHuffmanPairs) coder.h - HuffTabLookup-Typ und Definitionen für hufftabs.c geändert In der Funktion DecodeHuffman habe ich noch eine ganz kleine Optimierung bei der Berechnung der Region-Grenzen gemacht, aber macht eigtl. keinen Unterschied. Im Anhang ist das komplette Projekt in Visual C++ 2010 Express. Die EXE öffnet test.mp3 und spielt sie ab. Zum Kompilieren wird SDL für die Sound-Ausgabe benötigt. Der Helix-Dekoder benötigt für die Huffman-Tabellen 4242 16-Bit Wörter (8484 Bytes). Dafür werden viele Codes aber bereits mit einem Look-Up in der Tabelle dekodiert (vor allem für die kleineren Huffman-Tabellen). Aus irgend einen Grund unterscheidet der Dekoder allerdings zwischen Loop-Tabellen (mehrere Look-Ups) und One-Shot (ein Look-Up). Das erhöht wiederum die Code-Größe. Die kleinere von meinen beiden Tabellen benötigt 1874 16-Bit Wörter (3748 Bytes) und jeder Code wird in maximal 4 Look-Ups dekodiert. Die etwas größere Tabelle benötigt 2108 16-Bit Wörter (4216 Bytes) und jeder Code wird in maximal 3 Look-Ups dekodiert. Also in jeden Fall spart man sich ca. 4 kByte. Wenn man den Dekoder für einen Controller mit wenig ROM kompiliert kann das schon etwas helfen. Wenn jemand das mit den angepassten Tabellen mal auf einem Mikrocontroller ausprobieren könnte und hier eine Rückmeldung geben könnte wäre das super. Würde mich mal interessieren, ob es ein wirklicher Performance-Verlust ist. Die Huffman-Kodierung ist eigentlich nicht das rechenintensivste bei der MP3 Dekodierung, von daher sollte der Performance-Verlust sich in Grenzen halten. Die Daten für meine Tabellen passen auch in 12-Bit - damit spare ich auf dem FPGA Resourcen, für den Helix-Dekoder bringt das natürlich nix. Das Programm, welches die Tabellen erzeugt, ermittelt die optimale Größe der Tabellen und Unter-Tabellen für eine beschränkte Look-Up-Tiefe. Dazu gehe ich im Programm stumpf alle Möglichen Kombinationen durch (ein besserer Algorithmus ist mir nicht eingefallen :)). Das Programm will ich aber noch nicht hier rein stellen, für den Code schäme ich mich etwas :)
:
Verschoben durch Admin
Den Code für die Einbindung des Helix-Dekoders habe ich mir von hier geklaut und ein wenig ausgedünnt/angepasst: Beitrag "STM32F4 Discovery MP3 Player - komplett mit Code" In der Tabelle mit 3 Ebenen hat sich noch ein Fehler eingeschlichen. Die Quad-Values sind auch in der Tabelle gelandet, da ich die auf dem FPGA auch mit der Tabelle dekodieren will. Hier die Tabelle ohne die Quad-Values (werden im Code nicht genutzt, da ich die Original Funktion vom Helix-Dekoder für die Quads nutze).
:
Bearbeitet durch User
Noch zur Info: Es sind insgesamt 1393 Huffman-Codes im Standard definiert. Der Helix-Dekoder hat also eine Redundanz von 3,045 Die 3-Ebenen Tabelle hat eine Redundanz von 1,513 Die 4-Ebenen Tabelle hat eine Redundanz von 1,345 Die minimal mögliche Größe sind 1820 Tabellen-Einträge bei 8 Ebenen. Ich glaube besser geht nicht - das wäre eine Redundanz von 1,307 und lohnt sich nicht wirklich im Vergleich zur 4-Ebenen-Tabelle.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.