Archiv verlassen und diese Seite im Standarddesign anzeigen : Kann man h264 noch verbessern oder ist das Ende erreicht?
Was meint ihr geht in der Videokompression noch was oder ist langsam das Ende erreicht?
Wenn ihr Ideen habt Beispiele bitte.
raum für verbesserungen gibt es immer, das kosten-nutzen-verhältnis wird allerdings bei kompressionen immer schlechter.
ob es für herkömliche videos noch breitflächige verbesserungen in der kompression geben wird ist schwer abzuschätzen.
interessant wird es allerdings wenn (stereo)3D-filme für die breite masse kommen. da gibt es in den beiden videostreams natürlich jede menge redundanzen die sich schön komprimieren lassen, solche algorithmen sind auch schon in entwicklung.
Das Ende der Fahnenstange ist im Großen und Ganzen eigentlich erreicht.
Klar gibt es hier und da wieder ein paar kleine Optimierungen aber
Algorithmentechnisch gesehen hat man inzwischen das beste ausgereizt.
Alles andere was es danach sonst noch so gäbe rechnet sich vom
Aufwand/Nutzen Verhältnis einfach nicht mehr. Auch nicht mit superschnellen Rechnern.
Shink
2008-11-05, 21:14:35
Ich würde sagen es geht noch wesentlich besser als h264 - vor allem wenn die Auflösungen steigen.
h264 war ja auch nur einer von vielen Vorschlägen für den "neuen" Videocodec-Standard von MPEG 4. Gesiegt hat er nicht wegen der besten Effizienz sondern weil er (im Gegensatz zu Wavelet-basierten Codecs) doch noch recht einfach in Hardware zu gießen ist.
Es geht immer besser. Allerdings ist es gerade bei Videokompressionen wichtig, daß sie halbwegs effizient sind, um auch mit DSPs und nicht-Tophardware vernünftig decodieren zu können. Videodecodierung muß ja in Echtzeit laufen und idealerweise ist dann noch etwas Platz für Zusatzfeatures, man kann also immer nur so viel optimieren, wie die aktuelle Hardware hergibt.
h.264 ist zwar ordentlich, aber eben mittlerweile schon nicht mehr modern--in den nächsten Jahren wird sich also weiterhin so viel tun wie bisher.
-huha
Es geht immer besser. Allerdings ist es gerade bei Videokompressionen wichtig, daß sie halbwegs effizient sind, um auch mit DSPs und nicht-Tophardware vernünftig decodieren zu können. Videodecodierung muß ja in Echtzeit laufen und idealerweise ist dann noch etwas Platz für Zusatzfeatures, man kann also immer nur so viel optimieren, wie die aktuelle Hardware hergibt.
h.264 ist zwar ordentlich, aber eben mittlerweile schon nicht mehr modern--in den nächsten Jahren wird sich also weiterhin so viel tun wie bisher.
-huha
Worauf beruhen deine Aussagen?
Pinoccio
2008-11-05, 22:03:44
Worauf beruhen deine Aussagen?Erfahrung.
Es gab (und gibt) immer wieder Fortschritte bei Algorithmen, die so vorher undenkbar scheinen. Die Chance, daß dies auch bei Video-Komprimieren passiert würde ich, und offenbar auch huha, als recht hoch einschätzen.
mfg
Skinner
2008-11-11, 20:37:42
VC-1 wird in Fachkreisen eine bessere Qualität nachgesagt. Obs stimmt, muss man wohl mit der Lupe suchen. Bei VC-1 gibts ja leider wirklich guten Open Source encoder, so wie den x264 für h264.
VC-1 wird in Fachkreisen eine bessere Qualität nachgesagt.
bei gleicher bitrate? sicher nicht, VC-1 ist im grunde nichts anderes als WMV und damit ein MPEG4-ASP-abkömling.
Das lässt sich jetzt noch nicht wirklich abschätzen, allerdings sollte mit steigender Rechenleistung widerum ein anderer Algorithmus alltagstauglich werden, der zum jetzigen Zeitpunkt noch undenkbar scheint.
Bei den Packprogrammen ist es ähnlich, es gibt da zwar RAR und 7z, aber auch schon bessere. Diese sind jedoch extrem langsam oder im Experimentierstatus. Wenn jedoch genügend CPU Leistung und RAM zur Verfügung steht, würden sie alle anderen übertrumpfen.
Ich finde diesen Bereich sehr interessant, auf der einen Seite wächst die Speicherkapazität extrem an, auf der anderen Seite werden die files immer kleiner oder qualitativer.
Das lässt sich jetzt noch nicht wirklich abschätzen, allerdings sollte mit steigender Rechenleistung widerum ein anderer Algorithmus alltagstauglich werden, der zum jetzigen Zeitpunkt noch undenkbar scheint.
Dieser potentielle Algorithmus wäre dann aber schon bekannt.
Wie lautet er?
Wenn du jetzt keinen nennen kannst, dann ist das Ende mit h264 und dem ganzen Waveletzeug, wie z.b. Dirac & Schrödinger erreicht.
Bei den Packprogrammen ist es ähnlich, es gibt da zwar RAR und 7z, aber auch schon bessere. Diese sind jedoch extrem langsam oder im Experimentierstatus. Wenn jedoch genügend CPU Leistung und RAM zur Verfügung steht, würden sie alle anderen übertrumpfen.
Welche sollen das sein?
Bzw. wie heißen die?
Wenn du jetzt keinen nennen kannst, dann ist das Ende mit h264 und dem ganzen Waveletzeug, wie z.b. Dirac & Schrödinger erreicht.
Quatsch. Wir konnten auch schon damals nicht vorhersagen, was in ein paar Jahren sein würde (galt auch bei Prozessoren).
Du brauchst noch nicht einmal etwas gänzlich neues, mit steigender Rechenleistung kannst du unter anderem in Echtzeit dafür sorgen, das bildinformationen durch berechnungen ergänzt werden und so ein qualitativ besseres bild entsteht. Beispielsweise ist Blöckchengrafik ja oft ein Zeichen von starker komprimierung, ließe sich mit ausreichender rechenleistung aber auf ein minimum reduzieren.
Welche sollen das sein?
Bzw. wie heißen die?
Da es schätzungsweise 200 formate gibt, von denen du noch nicht einmal etwas gehört hast, schau am besten erstmal hier nach :)
http://www.maximumcompression.com/index.html
drmaniac
2008-11-12, 14:55:21
Wer hätte mal gedacht, dass es
JPG
gibt :D Früher ein kleiner Scan in bunt mal eben 15+MB, dann auf einmal 78kb ;) Juchu, ich konnte Bilder per Diskette zu einem Freund tragen ;) Ok, das entpacken dauerte Sekunden und das packen selber Minuten..hehehe aber heute normal
MP3
wau! Früher eine Vinyl Scheibe einzulesen..undenkbar, Platten waren zu klein (paar hundert MB) ein Lied hätte locker 50MB verschlungen. Dann der Zauber Encoder und das Lied war bei 3 (mono) bzw 6 (stereo) MB :) Ok, um 5 lieder zu "mpeggen" mussten wir eine Nacht bis morgens um 10 in der Disko verbringen, aber als wir zurück kamen, war die Batch durch ;) Wer hätte das gedacht... Mein Traum damals war "oh man, wenn man MP3 mal in ECHTZEIT..." ;)
Da selbe spiel bei MPG oder jetzt H264...
Neue Codecs und Verfahren werden immer mal wieder kommen.
Jetzt schon zu sagen, wir sind am Ende wäre grob...unwahr ;)
.
Berni
2008-11-12, 19:15:18
Also das beste Verfahren ist sicherlich WPEG: http://www.dangermouse.net/esoteric/wpeg.html ;)
PatkIllA
2008-11-12, 20:22:57
Bei Video könntest du noch jede Menge rausholen, wenn man Objekte erkennt.
Dann könnte man Personen Fahrzeuge in nur wenigen Einstellungen speichern und dann nur noch die Unterschiede speichern. Zugleich könnte man dann den Hintergrund als ein Bild speichern und müsste nicht wenn eine bereits sichtbar gewese Stelle verdeckt und wieder wieder sichtbar wird neu gespeichert werden.
Das kann man fürs Streaming aber knicken und löst auch so ein bisschen den Typ von Video als einfache Abfolge von Bildern ab.
Da hab ich sogar schon mal was von gehört, aber ich glaube nicht, dass das mittelfristig praktisch umgesetzt wird.
Funky Bob
2008-11-12, 21:05:37
Köntne man sowas nicht sehr gut bei Comics o.ä. nutzen? Stelle es mir relativ einfach vor, nur Vektoren der Figuren mit den geplanten "Animationen" und den Bewegungen zu verschicken und in echtzeit frei skalierbar nutzen zu können.
Im 2D-Bereich sollte das doch möglich sein?!
PatkIllA
2008-11-12, 21:07:48
Das Konzept ginge auch bei ganz normalem Video, aber bei Comic wäre es wohl einfacher und man könnte das auch effizient encoden, da man nicht erst die Erkennung machen müsste.
Stelle es mir relativ einfach vor, nur Vektoren der Figuren mit den geplanten "Animationen" und den Bewegungen zu verschicken und in echtzeit frei skalierbar nutzen zu können.
Im 2D-Bereich sollte das doch möglich sein?!
Gibts doch schon, Flash.
grandmasterw
2008-11-12, 21:44:35
Fehlt nur ein encoder, der ein unkomprimiertes Comic-Video frisst, es dir in Echtzeit vektorisiert, und nicht abstürzt, wenn dann die Werbung kommt.:wink:
Neue Codecs und Verfahren werden immer mal wieder kommen.
Jetzt schon zu sagen, wir sind am Ende wäre grob...unwahr ;)
.
Man sieht, daß ihr alle kein Informatik Studium genossen habt.
Mathematische Verfahren und Algoirthmen sind schon Jahre vorher bekannt, ehe es die CPUs mit ausreichend Rechenpower gibt um diese zu verwirklichen.
Alles was in der Wavelet-Kompression und h264 enthalten ist, ist aus mathematischer Sicht ein alter Hut.
Und wenn es in Jahren später neue viel bessere Codecs geben würde, wofür man aber heute noch auf die Hardware warten muß, dann wären auch heute schon diese Verfahren bekannt.
Das neue mathematische Verfahren (man beachte, das sind Grundlagen)
gefunden werden ist zwar nicht unmöglich aber doch eher unwahrscheinlich.
Ihr könnt das auch gut an den 3d APIs wie z.b. OpenGL sehen.
Alle 3d Verfahren was in den letzten 10 Jahren bei den 3d Grafikkarten in Hardware verwirklicht wurde, gab es schon vor 20 oder mehr Jahren als mathematische Idee oder Algorithmus, nur war die Hardware noch nicht so weit.
Und so ist es auch bei Videocodecs.
Also, würde es heute mathematische Verfahren geben, die noch nicht wegen der Hardware genutzt werden konnten, dann währen diese heute schon bekannt.
Wer also behauptet, daß es in 10 Jahren wieder viel bessere Codecs geben wird, der muß auch jetzt in der Lage sein zu sagen, auf welchen bekannten mathematischen Verfahren diese beruhen.
Ansonsten ist das nonsense was ihr da behauptet.
Shink
2008-11-13, 17:50:24
Man sieht, daß ihr alle kein Informatik Studium genossen habt.
unwahr:P
Mathematische Verfahren und Algoirthmen sind schon Jahre vorher bekannt, ehe es die CPUs mit ausreichend Rechenpower gibt um diese zu verwirklichen.
Verfahren und Algorithmen schon. Anforderungen die die Anwendung notwendig machen können allerdings durchaus erst zeitnah bekannt werden.
Du willst doch nicht wirklich sagen dass der h264-Codec schon seit Jahrzehnten (in Fortran ausprogrammiert) in den Schubladen der Unis liegt die nur darauf warteten dass endlich eine Hardware schnell genug dafür war?
Klar, die Grundlagen schon.
TheGoD
2008-11-13, 18:04:42
@#20
Es gibt zur Zeit noch nicht viele auf Wavelet basierende Codecs, so dass ich mir gerade in diesem Bereich noch größere Entwicklungen vorstellen kann, wie sie auch bei MPEG 1 auf AVC/VC1 zu beobachten waren.
Außerdem sind auch beim Postprocessing noch Fortschritte durch die Nutzung der heutige sowie zukünftig vorhandenen Rechenleistung zu erwarten, was wiederum als Verbesserung der Komprimierung gesehen werden kann.
Bumsfalara
2008-11-13, 18:44:56
VC-1 wird in Fachkreisen eine bessere Qualität nachgesagt. Obs stimmt, muss man wohl mit der Lupe suchen. Bei VC-1 gibts ja leider wirklich guten Open Source encoder, so wie den x264 für h264.
Mit ner Lupe? -> Nein, das ist purer Unsinn. Spätestens seit der Implementierung von Psychovisuellen Features wie Psy-rdo oder psy-tellis ist h264 (in diesem Falle x264) VC1 in allen Belangen überlegen.
Würde echt mal gerne wissen, was für "Fachkreise" sowas behaupten...
MrMostar
2008-11-13, 18:54:52
Zur Eingangsfrage:
Natürlich gehts weiter!
Sources say that H.265 would be desired to be 50% more efficient than H.264. (http://en.wikipedia.org/wiki/H.265)
:massa:
edit:
http://www.h265.net/
Shink
2008-11-13, 18:56:41
Naja, psychovisuelle Features können jeden Codec (anders) aufwerten. Da hat sich ja sogar in MPEG2 noch viel getan seit es auf dem Markt ist.
Pinoccio
2008-11-13, 20:16:23
Alles was in der Wavelet-Kompression [...] enthalten ist, ist aus mathematischer Sicht ein alter Hut.Auja, als Alfréd Haar 1909 sein Wavelet vorstellte, dachten alle gleich "Au man! Schnelle Hardware und wir machen da eine Bildkompression drauß!"
:rolleyes:
mfg
Mit ner Lupe? -> Nein, das ist purer Unsinn. Spätestens seit der Implementierung von Psychovisuellen Features wie Psy-rdo oder psy-tellis ist h264 (in diesem Falle x264) VC1 in allen Belangen überlegen.
Würde echt mal gerne wissen, was für "Fachkreise" sowas behaupten...
Das werden wahrscheinlich alle die Leute behaupten, die sehr viele HDDVDs bzw. Blu-rays auf sehr gutem Ausgabeequipment gesehen haben. Suche dir mal eine Liste mit Bildqualitätsbewertungen und sehe dann mal nach welcher Codec bei den Filmen verwendet wurde. Bei den meisten Filmen ist es wohl VC1 (mir fällt kein Film mit h264 ein).
H264 kann wahrscheinlich besser aussehen. Die von dir genannten Features werden aber wohl noch nicht benutzt. Es geht hier nicht um das neuencoden (herunterrechnen), sondern kaufbare HD-Quelllen.
TheGoD
2008-11-13, 22:21:53
Das ist doch aber auch kein gültiger Vergleich. Actionfilm X aus dem Jahr 2002 bei einer Länge von 140 Minuten von Firma A mit AVC auf 30 GB komprimiert vs. Romanze Y aus dem Jahr 2008 bei einer Länge von 130 Minuten von Firma B mit VC1 auf 36 GB komprimiert.
Einen Codecs kann man immer nur durch das verwenden von gleichen Quellmaterial bei jeweils entweder optimalen, praxisnahen oder in Relation zur zu Verfügung stehender Rechenleistung angepassten Optionen mit einem anderem Codecs vergleichen.
Du willst doch nicht wirklich sagen dass der h264-Codec schon seit Jahrzehnten (in Fortran ausprogrammiert) in den Schubladen der Unis liegt die nur darauf warteten dass endlich eine Hardware schnell genug dafür war?
Das nicht, aber die Grundelemente aus denen er aufgebaut ist, also die mathematischen Ideen, Verfahren, Algorithmen etc.
Klar, die Grundlagen schon.
Eben.
D.h. wäre theoretisch ein besserer Codec als h.264 und wavelet vorhanden, dann hätte man jetzt schon Ansätze für zukünftige Rechnergenerationen.
Avalox/Gast
2008-11-14, 11:27:02
Du willst doch nicht wirklich sagen dass der h264-Codec schon seit Jahrzehnten (in Fortran ausprogrammiert) in den Schubladen der Unis liegt die nur darauf warteten dass endlich eine Hardware schnell genug dafür war?
H.264 ist ja auch kein innovatives Produkt als solches, es ist schlicht eine Detailverbesserung an aktuelle Umstände angepasste Implementierung. Es ist eben nur die Ebene womit der Benutzer in Berührung kommt und deshalb ist es dem gemeinen Benutzer so geläufig.
H.264 (auch AVC) nutzt keinerlei Technik welche nicht schon seit Jahrzehnten, vielleicht sogar schon 50Jahren und länger bekannt und genutzt werden.
Natürlich hat niemand einen H.264 AVC Codec vor 50 Jahren codiert, schlicht gab es dort weder eine Plattform noch die Notwendigkeit.
Allerdings hätte man dieses dort schon mit tun können.
Deshalb ist der Weg in die heutige Mathematik zu sehen auch der einzig richtige, um über zukünftige Verfahren zu spekulieren.
Ein entscheidender Faktor dabei ist auch die Physiologie. Viele Ergebnisse der heutigen Medienkompression basieren ja schlicht darauf, dass die Qualität sehr weit zurück gefahren wurde.
Dieses aber halt in Bereichen, welche den Menschen nicht auffallen. Dort stehen nicht in erster Linie mathematische Erkenntnisse, als vielmehr human physiologische Erkenntnisse im Vordergrund.
Dieses ist der zweite Bereich den man betrachten muss.
Der HeinZ
2008-11-14, 13:01:36
(mir fällt kein Film mit h264 ein).
.
X-MEN 3, Pirates of the Caribbian 1,2 oder 3, Transformers etc. ich könnte dir da noch wesentlich mehr auflisten... Fällt auf das das alles EXTREM CGI und vorallem Actionlastige Filme sind. (die ich da aufgezählt habe.) Macht ja auch Sinn, hier geht es um Optik die wahrscheinlich mit nem VC-1 nicht zu erreichen oder schwerlich zu erreichen ist. Und ich meine auch das der VC-1 doch nur ein extended-WMV ist also nix was ein Divx oder XVID nicht auch locker, wenn nicht besser hinbekommen müßte, zeit und einstellungen natürlich vorausgesetzt. Und selbst da hinkt der Vergleich ziemlich weil schalte ich ein Low-End Profil bei H.264 (x.264) drauf und ein high end Profil bei DIVX, tun sich die beiden Formate bei entsprechender Datenrate nicht viel, wenn nicht sogar ist H.264 trotzdem besser. Allerdings rechnet x.264 auch erheblich länger, was aber eher an den fehlenden optimierungen liegt. Kann man mit dem Performance Monitor sehr gut erkennen. Hier nutzt DIVX sehr viel SSE und X.264 X87, zumindest in meinem Build.
X-MEN 3, Pirates of the Caribbian 1,2 oder 3, Transformers etc. ich könnte dir da noch wesentlich mehr auflisten... Fällt auf das das alles EXTREM CGI und vorallem Actionlastige Filme sind. (die ich da aufgezählt habe.) Macht ja auch Sinn, hier geht es um Optik die wahrscheinlich mit nem VC-1 nicht zu erreichen oder schwerlich zu erreichen ist. Und ich meine auch das der VC-1 doch nur ein extended-WMV ist also nix was ein Divx oder XVID nicht auch locker, wenn nicht besser hinbekommen müßte, zeit und einstellungen natürlich vorausgesetzt. Und selbst da hinkt der Vergleich ziemlich weil schalte ich ein Low-End Profil bei H.264 (x.264) drauf und ein high end Profil bei DIVX, tun sich die beiden Formate bei entsprechender Datenrate nicht viel, wenn nicht sogar ist H.264 trotzdem besser. Allerdings rechnet x.264 auch erheblich länger, was aber eher an den fehlenden optimierungen liegt. Kann man mit dem Performance Monitor sehr gut erkennen. Hier nutzt DIVX sehr viel SSE und X.264 X87, zumindest in meinem Build.
Meine Aussage oben bezog sich auf Filme mit hervorragender Bildqualität. Sehe dir im Vergleich mal Shooter oder Crank an. Transformers hat dagegen ein lausiges Bild, was eigentlich nicht sein sollte, weil er viel CGI enhält. Auch Pirates of the Caribbean 3 hat ein unscharfes Bild, was auch an der sehr niedrigen Datenrate liegen wird.
Spasstiger
2008-11-15, 00:46:05
Man vermutet ja, dass in einigen Zahlen - wie z.B. der Zahl Pi - jede beliebige Information drinsteckt. Man müsste nur an die richtige Stelle springen und hätte dann einen kompletten Film.
Damit könnte man natürlich enorm effiziente Codierungen umsetzen. Problem ist nur, dass man extrem viel Rechenzeit braucht, um überhaupt mal an die entsprechende Stelle zu kommen.
Nehmen wir z.B. mal den Namen "GOTT". Würde man ihn in einem Alphabet speichern, das ausschließlich aus 27 Großbuchstaben und Zeichen besteht, so bräuchte man mindestens 4,755 Bit pro Buchstabe (unter der Annahme, dass alle Buchstaben in diesem Alphabet gleich häufig auftreten). Der Name Gott belegt also in dieser Codierung mindestens 19 Bit.
Sucht man nun aber entsprechend einer Codierung, die ein Alphabet mit 27 Buchstaben verwendet, den Namen "GOTT" in der Zahl Pi, so findet man ihn an Stelle 78487 einer ebenso codierten Repräsentation von Pi (siehe hier (http://www.dr-mikes-maths.com/pisearch.html)). Mit dem Wissen, dass man einen Namen mit 4 Buchstaben sucht, könnte man nun einfach nur die Zahl 78487 speichern. Dazu braucht man mindestens 16,2 Bit. Selbst wenn man noch die Information dazu speichert, dass das Wort vier Buchstaben hat, kämen nur 2 Bit hinzu und man wäre bei 18,2 Bit. Also weniger als die direkte Codierung erfordert (19 Bit).
Ist natürlich nur Theorie, ob sich daraus mal sinnvolle Algorithmen entwickeln, kann ich nicht beurteilen. Man könnte mit dieser Technik auf jeden Fall auch bezogen auf den Informationsgehalt bereits optimal komprimierte Informationen weiter komprimieren, sofern die Bitfolgen/Zeichenfolgen in der Zahl Pi an günstiger Stelle auftauchen.
/EDIT: Seit 1996 gibt es auch einen Algorithmus, mit dem man jede beliebige Stelle einer binären Repräsentation von Pi berechnen kann, ohne die vorigen Stellen zu kennen:
http://crd.lbl.gov/~dhbailey/
H.264 (auch AVC) nutzt keinerlei Technik welche nicht schon seit Jahrzehnten, vielleicht sogar schon 50Jahren und länger bekannt und genutzt werden.
Natürlich hat niemand einen H.264 AVC Codec vor 50 Jahren codiert, schlicht gab es dort weder eine Plattform noch die Notwendigkeit.
Allerdings hätte man dieses dort schon mit tun können.
Wie siehts denn z.B. mit CABAC aus, welches in der Entropy-Stage verwendet wird? CABAC baut auf arithmetischer Codierung auf, zu welcher 1975 von Rissanen erste Grundlagen gelegt wurden.
Wer sagt außerdem, dass die Integration vieler schon bestehender Techniken zu einem neuen, erheblich besseren Verfahren nicht innovativ ist. Ich frage mich wirklich, was sich manche Leute vorstellen. Ich schlage mal ein Grundlagenbuch auf, nehme alle interessanten Techniken und heraus kommt ein Algorithmus, der alles bisherige in den Schatten stellt und dabei noch praktikabel ist!?
Gerade Sachen wie die Modellierung in der Entropy-Stage sind enorm innovativ. Man nehme z.B. Packer: PPMd, 7-zip, OptimFrog, ... Die Grundlagen sind alle schon vorher bekannt gewesen, die 'Mischung' aber machts.
Man vermutet ja, dass in einigen Zahlen - wie z.B. der Zahl Pi - jede beliebige Information drinsteckt. Man müsste nur an die richtige Stelle springen und hätte dann einen kompletten Film.
Und die Kodierung der Position, an denen die Daten hinterlegt sind, lohnt sich natürlich? Und das klappt auch immer? ;)
Da ich zu schreibfaul bin: http://www.faqs.org/faqs/compression-faq/part1/ unter Punkt [9.2]
Avalox
2008-11-15, 09:33:35
Wer sagt außerdem, dass die Integration vieler schon bestehender Techniken zu einem neuen, erheblich besseren Verfahren nicht innovativ ist.
Innovativ als Ingenieursleistung, aber eben nicht die Mathematik dahinter.
@Spasstiger
Damit könnte man dann auch endlich einen guten Matrix 3 Teil sehen obwohl nie gedreht, oder jeden Tag eine Fortsetzung von Star Wars.
Was für ein Ärger, wenn dann jemand Star Wars 7 in Pi gefunden hat und die letzten 5 Minuten fehlen.
ollix
2008-11-15, 14:06:07
Damit könnte man dann auch endlich einen guten Matrix 3 Teil sehen obwohl nie gedreht, oder jeden Tag eine Fortsetzung von Star Wars.
Was für ein Ärger, wenn dann jemand Star Wars 7 in Pi gefunden hat und die letzten 5 Minuten fehlen.;D Dann kann man sich entscheiden, ob man besser nach den letzten 5 Minuten sucht oder den Film nochmal komplett. Und dann findet man ihn nur auf spanisch oder der Anfang ist richtig und ab der 5 Minute ist es dann ein Porno ... voll der Mist ist das alles.
Was meint ihr geht in der Videokompression noch was oder ist langsam das Ende erreicht?
Wenn ihr Ideen habt Beispiele bitte.Das kann man nicht pauschal beantworten.
Jede verlustbehaftete Komprimierung ist für eine bestimmte Zielbitrate optimiert. Bei schwach komprimiert Bildern sind zum Beispiel JPEG und JPEG2000 einigermaßen gleichwertig, eher mit Vorteilen für JPEG. Bei stark komprimierten Bildern ist JPEG2000 klar im Vorteil.
Bei schwach komprimierter Musik sind Formate wie MP3 ganz gut. Bei stark komprimierter Musik liefern andere Formate eine deutlich bessere Qualität als MP3. Bei sehr schwach komprimierter Musik ist MP2 besser als MP3.
Wie siehts denn z.B. mit CABAC aus, welches in der Entropy-Stage verwendet wird? CABAC baut auf arithmetischer Codierung auf, zu welcher 1975 von Rissanen erste Grundlagen gelegt wurden. Das ist bei Videokomprimierung nicht der Bringer. In erster Linie muss man die Bildinformation intelligent reduzieren. Da kann man folgendes tun:
- Die räumliche Farbauflösung senken
- Die Helligkeitsquantisierung an den lokalen Kontrast anpassen (starke Kontraste – grobe Quantisierung, schwache Kontraste – feine Quantisierung.)
- Auf Bildinformationen aus alten (oder erst noch kommenden Bildern) verweisen
- Bildinhalte nicht neu speichern sondern mit einem Bewegungsvektor versehen
- Dies kombinieren mit zwei Bildern und die Interpolations-Stärke angeben (bei Überblendungen sinnvoll)
Speichert man nun die reduzierten Informationen, könnte man einen LZ-Algo (Wörterbuch-Komprimierung) mit Huffman-Optimierung (Indizierung häufig genutzter Wörter mit kurzen Bitlängen) nehmen oder statt Huffman eben algebraische Komprimierung nutzen (so dass man nicht immer auf ein ganzes Bit länge aufrunden muss.)
H.264 ist ja auch kein innovatives Produkt als solches, es ist schlicht eine Detailverbesserung an aktuelle Umstände angepasste Implementierung. Es ist eben nur die Ebene womit der Benutzer in Berührung kommt und deshalb ist es dem gemeinen Benutzer so geläufig.
H.264 (auch AVC) nutzt keinerlei Technik welche nicht schon seit Jahrzehnten, vielleicht sogar schon 50Jahren und länger bekannt und genutzt werden.
Natürlich hat niemand einen H.264 AVC Codec vor 50 Jahren codiert, schlicht gab es dort weder eine Plattform noch die Notwendigkeit.
Allerdings hätte man dieses dort schon mit tun können.
Deshalb ist der Weg in die heutige Mathematik zu sehen auch der einzig richtige, um über zukünftige Verfahren zu spekulieren.
Ein entscheidender Faktor dabei ist auch die Physiologie. Viele Ergebnisse der heutigen Medienkompression basieren ja schlicht darauf, dass die Qualität sehr weit zurück gefahren wurde.
Dieses aber halt in Bereichen, welche den Menschen nicht auffallen. Dort stehen nicht in erster Linie mathematische Erkenntnisse, als vielmehr human physiologische Erkenntnisse im Vordergrund.
Dieses ist der zweite Bereich den man betrachten muss.
Danke, wenigstens einer der mich versteht.
Man erkennt das du Informatiker oder Mathematiker bist oder in einem dieser Bereiche arbeitest.
Spasstiger
2008-11-16, 23:08:35
Und die Kodierung der Position, an denen die Daten hinterlegt sind, lohnt sich natürlich? Und das klappt auch immer? ;)
Immer wird es nicht klappen. Aber in manchen Fällen vielleicht schon, siehe mein Beispiel oben. Naja, ich bin zu wenig Mathematiker als dass ich darüber urteilen kann.
Bei rein zufälligen Daten lohnt sich die Codierung im Mittel vermutlich nicht.
Also ich finde man sollte alle Leute die die Zahl Pi im Internet zum Download anbieten verklagen.
Immerhin begehen sie eine Urheberrechtsverletztung, da sie meinen Film und mein Lied
in der Zahlenfolge Pi auf Binäre Weise versteckt haben.
Spasstiger
2008-11-17, 01:08:46
Also ich finde man sollte alle Leute die die Zahl Pi im Internet zum Download anbieten verklagen.
Immerhin begehen sie eine Urheberrechtsverletztung, da sie meinen Film und mein Lied
in der Zahlenfolge Pi auf Binäre Weise versteckt haben.
Hehe, trifft zwar heute noch nicht zu, weil man sogar in den ersten 4 Milliarden digitalen Stellen von Pi gerade mal Namen mit 6 Buchstaben wiederfindet. Aber irgendwann könnte das echt zu einem Problem werden. ;D
In dem bisschen Pi das schon berechnet wurde finden sich ganz sicher keine Filme.
...
Das ist bei Videokomprimierung nicht der Bringer.
CABAC war nur ein Beispiel für den anderen Gast, dass nicht alle Techniken schon vor 50 Jahren bekannt waren.
CABAC war ein Beispiel für den anderen Gast, dass nicht vor 50 Jahren schon alle Techniken bekannt waren.
Aber natürlich ist eine gute Entropy Stage auch für einen Video Codec sehr wichtig.
Ich versuche das mal grob an JPEG zu erklären, da es ja schon verwandt mit dem Thema ist. Nach der Abbildung in den YUV-Farbraum wird bei JPEG der DCT durchgeführt und dann die Koeffizienten quantisiert. Bis hierhin erzielt lediglich die Farbraumtransformation durch eine geringere Samplingrate der Farbinformationen eine moderate Datenreduktion. DCT+Quantisierung führen aber zu KEINER Volumenreduktion der Daten. Allerdings führt die Transformation zu einer Darstellung der Daten, die in der Entropy Stage dann hervorragend ausgenutzt werden kann. Ich vernachlässige hier einfach mal Sachen wie ZigZag und Co.
Bei Videokompression spielt natürlich die VBSMC und Anhang sehr stark mit herein. Aber man sollte nicht den Fehler machen und annehmen, dass die Daten vor der Entropystage schon ein sehr kleines Volumen haben müssen. Die Transformationen+MC+RDO+... stellen natürlich das Herzstück eines Videocodecs dar, trotzdem bringt das alles ohne einen ordentlichen EC nur wenig.
In erster Linie muss man die Bildinformation intelligent reduzieren. Da kann man folgendes tun:
- Die räumliche Farbauflösung senken
- Die Helligkeitsquantisierung an den lokalen Kontrast anpassen (starke Kontraste – grobe Quantisierung, schwache Kontraste – feine Quantisierung.)
- Auf Bildinformationen aus alten (oder erst noch kommenden Bildern) verweisen
- Bildinhalte nicht neu speichern sondern mit einem Bewegungsvektor versehen
- Dies kombinieren mit zwei Bildern und die Interpolations-Stärke angeben (bei Überblendungen sinnvoll)
Das stimmt.
Speichert man nun die reduzierten Informationen, könnte man einen LZ-Algo (Wörterbuch-Komprimierung) mit Huffman-Optimierung (Indizierung häufig genutzter Wörter mit kurzen Bitlängen) nehmen oder statt Huffman eben algebraische Komprimierung nutzen (so dass man nicht immer auf ein ganzes Bit länge aufrunden muss.)
Man könnte natürlich als Entropy-Stage LZ+Huffmann oder LZ+Arithmetische Kodierung nutzen, allerdings wäre dies Zeitverschwendung. Das Wörtbuchmodell funktioniert auf allgemeinen Daten gut, ist aber spezialisierten Algorithmen wie CABAC stark unterlegen. Das liegt daran, dass CABAC auf die Verteilung der Daten nach der Transformation optimiert wurde.
Allgemeine Verfahren sind spezialisierten Ansätzen sehr häufig unterlegen. Man vergleiche die Packraten und Geschwindigkeiten von z.B. 7-zip und Monkey Audio auf Audiodaten (7-Zip = LZ + bin. AC mit MRU; MAC = Transformation+Rice-Coding). Auch hier bei MAC führt die Transformation (LPC ähnlich) zu keiner Reduktion der Daten. Die Darstellung der Daten kann das extrem simple und schnelle Rice-Coding aber hervorragend ausnutzen, da es für residuale Daten recht gut geeignet ist.
Aber nun auch mal zum Thema:
IMO wird sich vor allem für kleine Datenraten bestimmt immer wieder etwas tun. Wavelets haben die Eigenschaft bei sehr kleinen Datenraten angenehme Artefakte zu erzeugen. Allerdings ist H.264 durch den integralen Deblocking Filter hier auch schon ganz gut aufgestellt. Auch von Wavelets sollten keine Wunder erwartet werden.
Objekt-basierte Video-Kompression ist mMn Zukunftsmusik. Solange niemand bessere und vor allem schnellere Algorithmen für diesen Ansatz (er)findet, wird es nicht mehr als ein Papiertiger bleiben.
Bei fast transparenter Videokompression sieht es aber wesentlich schwieriger aus.
DCT+Quantisierung führen aber zu KEINER Volumenreduktion der Daten.
Falsch
Die Darstellung der Daten kann das extrem simple und schnelle Rice-Coding aber hervorragend ausnutzen, da es für residuale Daten recht gut geeignet ist.
1. Darstellung des Fehlers
2. MAC benutzt keine Rice-Codierung sondern arithmetische Codierung inkl. statischem Order-0 Modell
Falsch
Richtig, da der DCT eine Transformation ist. Die Quantisierung führt ebenfalls nur zu einer *möglichen* Reduktion des Wertebereichs der Koeffizienten. Ob nun schön viele Nullen entstehen hängt dann wohl doch vom Eingabesignal und der Quantisierungsmatrix ab. Ob man dies nun aber sinnvoll in eine Volumenreduktion der Daten umwandeln kann, hängt letztendlich vom Entropy-Coder ab, oder etwa nicht? ;)
1. Darstellung des Fehlers
Was in dem Kontext residuale Daten sind, sollte eigentlich jeder wissen.
2. MAC benutzt keine Rice-Codierung sondern arithmetische Codierung inkl. statischem Order-0 Modell
Leider falsch, siehe http://www.monkeysaudio.com/smf/index.php?topic=388.0. Matt (der Entwickler) schreibt selber:
MAC uses Rice coding, but the overflows from the Rice part get range coded instead of stored as a simple stream of bits. (111 for 3, 1111 for 4, etc.)
Allgemein gilt aber, dass sofern man die Verteilung der Daten kennt, simple, spezialisierte Algorithmen einem Wörterbuchverfahren vorgezogen werden sollte.
Die Quantisierung führt ebenfalls nur zu einer *möglichen* Reduktion des Wertebereichs der Koeffizienten. Ob nun schön viele Nullen entstehen hängt dann wohl doch vom Eingabesignal und der Quantisierungsmatrix ab.
Quantisierung ist eine injektive Abbildung, und dient, der Darstellung einer Größe in einem diskreten (hier kleineren) Wertebereich, ergo Datenreduktion.
Was in dem Kontext residuale Daten sind, sollte eigentlich jeder wissen.
residuale Daten steht nicht da
Leider falsch, siehe http://www.monkeysaudio.com/smf/index.php?topic=388.0. Matt (der Entwickler) schreibt selber:
der Link ist von 2002, schonmal in den Quellcode von MAC 4.x geschaut ?
Allgemein gilt aber, dass sofern man die Verteilung der Daten kennt, simple, spezialisierte Algorithmen einem Wörterbuchverfahren vorgezogen werden sollte.
Beweis? Oder ist das nur eine der vielen fälschlichen Annahmen in diesem Thread, ich hab mir nur ein Posting rausgezogen :D
Quantisierung ist eine injektive Abbildung, und dient, der Darstellung einer Größe in einem diskreten (hier kleineren) Wertebereich, ergo Datenreduktion.
Das stimmt ja auch, wenn man nur die Quantisierung alleine betrachtet. Aber denk einfach mal darüber nach (bitte DENKEN!!), welche allgemeinen Aussagen Du über den Wertebereich der Koeffizienten nach DCT+Quantisierung machen kannst? Der Wertebereich kann durch den DCT je nach Eingabedaten sogar noch zunehmen. z.B. ist es nicht unüblich, dass der Wertebreich der Koeffizienten der tiefen im Eingabesignal enthaltenen Frequenzen sogar zunimmt. Zudem wird ein weiteres Bit für ein mögliches Vorzeichen benötigt.
Wenn man nun nur leicht quantisiert, was ja sein kann, sollte es ziemlich problematisch sein, mal einfach nur 8 bit für die Koeffizienten zu nehmen. Das sollte doch sogar Dir einleuchten. Was macht man also? Man nimmt ein statistisches Modell - oder in anderen Worten, einen Entropy Coder, um die durch die Transformation gewonnene Informationsredundanz auszunutzen. Punkt.
residuale Daten steht nicht da
Wer lesen kann...
der Link ist von 2002, schonmal in den Quellcode von MAC 4.x geschaut ?
Die Frage gebe ich einfach mal zurück. ;) Und Dir ist hoffentlich ebenfalls bewusst, dass MAC 2002 schon bei Version 3.97 war und keine grundlegenden Änderungen mehr an der Engine durchgeführt wurden. Nein, dass dachte ich mir.
Beweis? Oder ist das nur eine der vielen fälschlichen Annahmen in diesem Thread, ich hab mir nur ein Posting rausgezogen :D
LOL. Fang besser mal bei Deinem Halbwissen an.
Pinoccio
2008-11-17, 16:28:09
[text]Wenn man die DCT-Koeffizienten in 8 Bit abspeichert und nach der Quantisierung auch wieder in 8 Bit, so hat man in der Tat noch keinen Platz gespart.Quantisierung ist eine injektive Abbildung, und dient, der Darstellung einer Größe in einem diskreten (hier kleineren) Wertebereich, ergo Datenreduktion.Nein. Wenn ich {123, 45, 17,8,3,...} mittels meiner fiktiven "Matrix" 1/12 quantisiere auf { 10, 3, 1, 0, 0,...} so geht da Information verloren, aber wenn ich die Zahlen weiterhin in 8 bit speichere, und das tut man ja, so spare ich keinen Platz. In dem Punkt hat der Gast durchaus recht.LOL. Fang besser mal bei Deinem Halbwissen an.o.O
Dein Ton ist völlig unangemessen.
Zudem wird ein weiteres Bit für ein mögliches Vorzeichen benötigt. Halbwissen. ;-) Das Vorzeichen kommt erst im Schritt nach der Quantisierung.In dem bisschen Pi das schon berechnet wurde finden sich ganz sicher keine Filme.Kunstbanause! ;-)
Also ich finde man sollte alle Leute die die Zahl Pi im Internet zum Download anbieten verklagen.Immerhin begehen sie eine Urheberrechtsverletztung, da sie meinen Film und mein Lied
in der Zahlenfolge Pi auf Binäre Weise versteckt haben.Wegen purer Zahlen klagen wollen? Da biste nicht der erste ... (http://www.heise.de/newsticker/Primzahl-entschluesselt-DVDs--/meldung/16226)
Immer wird es nicht klappen. Aber in manchen Fällen vielleicht schon, siehe mein Beispiel oben. Naja, ich bin zu wenig Mathematiker als dass ich darüber urteilen kann.
Bei rein zufälligen Daten lohnt sich die Codierung im Mittel vermutlich nicht.Verlustfreie Kodierung lohnt sich im Mittel nie. ;-)
Pi dürfte sich schon deshalb nicht lohnen, weil es voll mit vielen Gesetzmäßigkeiten ist (siehe z.B. die von dir verlinkte Vorschrift zur Darstellung oder überhaupt die vielen Reihendarstellungen).
mfg
Wenn man nun nur leicht quantisiert, was ja sein kann, sollte es ziemlich problematisch sein, mal einfach nur 8 bit für die Koeffizienten zu nehmen. Das sollte doch sogar Dir einleuchten.
auch eine leichte Quantisierung führt zu einer Informationsverringerung.
Die Representation der Daten ist ein Problem der Kodierung.
Der Informationsgehalt nach der DCT (von die Diskrete Kosinustransformation) ist, Rundungsfehler ausgeschlossen, exakt der Selbe.
edit:
Nein. Wenn ich {123, 45, 17,8,3,...} mittels meiner fiktiven "Matrix" 1/12 quantisiere auf { 10, 3, 1, 0, 0,...} so geht da Information verloren, aber wenn ich die Zahlen weiterhin in 8 bit speichere, und das tut man ja, so spare ich keinen Platz. In dem Punkt hat der Gast durchaus recht.o.O
Ich finde diese Argumentation undurchsichtig. Ich kann auch 1000 Nullen in jeweils 32-Bit speichern. Aber ich glaube ich kann nachvollziehen was er sagen wollte.
Was macht man also? Man nimmt ein statistisches Modell - oder in anderen Worten, einen Entropy Coder, um die durch die Transformation gewonnene Informationsredundanz auszunutzen. Punkt.
wieder so ein Käse. Die Transformation dient einzig und allein dazu, durch den Vorgang Trans/Quant/Dequant/Detrans entstehendes Quantisierungsrauschen zu minimieren.
Die Frage gebe ich einfach mal zurück. ;)
Und Dir ist hoffentlich ebenfalls bewusst, dass MAC 2002 schon bei Version 3.97 war und keine grundlegenden Änderungen mehr an der Engine durchgeführt wurden. Nein, dass dachte ich mir.
klar, sonst würde ich die Frage nicht stellen.
Version 3.99 (April 29, 2004)
1. Changed: Decoding engine better at handling corrupt streams / loss of internet connection while playing.
2. Changed: Simplified assembly code building for 3rd party developers.
3. NEW: Improved entropy coder for increased compression.
4. Changed: Removed RKAU support. (since it is no longer commonly used)
LOL. Fang besser mal bei Deinem Halbwissen an.
Gäste :rolleyes:
auch eine leichte Quantisierung führt zu einer Informationsverringerung.
Die Representation der Daten ist ein Problem der Kodierung.
Der Informationsgehalt nach der DCT (von die Diskrete Kosinustransformation) ist, Rundungsfehler ausgeschlossen, exakt der Selbe.
Es hat niemand gesagt, dass der Informationsgehalt sich ändert - bitte richtig lesen. Außerdem hast Du leider nicht nachgedacht. Nimm doch mal an, dass jedes Eingabesample vor der DCT 8 Bit hat. Na, wieviel Bit benötigt man NACH der Transformation? Genau, hängt von den Eingabedaten ab und kann deutlich mehr als 8 Bit sein. Hmm, wenn ich nun Quantisiere, wieviel Bit brauche ich dann? Oh, kann man ja auch nicht sagen, sofern man nicht unbedingt mit riesigen Werten quantisiert. Und wie will jetzt der liebe Herr Pest die Koeffizienten von DCT+Quant. allgemein mit wesentlich weniger Speicher darstellen? Und das ohne Entropy Coder? Ja, geht nicht, gell.
wieder so ein Käse. Die Transformation dient einzig und allein dazu, durch den Vorgang Trans/Quant/Dequant/Detrans entstehendes Quantisierungsrauschen zu minimieren.
Das mag eine Eigenschaft sein, aber irgendwie hast Du den Sinn der DCT nicht ganz verstanden. Stichwort: spatiale Dekorrelation. Meine Güte!
Wenn Du Dich weiterhin mit Deinem Pseudowissen profilieren möchtest, dann rede doch mit einer Wand. Vielleicht kannst Du die ja beeindrucken. Für mich ist das hier verschwendete Zeit.
klar, sonst würde ich die Frage nicht stellen.
Dann helfe ich Dir ein letztes Mal auf die Sprünge, da Du das ja anscheinenend auch nur mehr schlecht als recht Quellcode lesen kannst. Aus dem aktuellen SDK von MAC (maclib/bitarray.cpp):
/******************************************************************************** ****
Encode a value
******************************************************************************** ****/
int CBitArray::EncodeValue(int nEncode, BIT_ARRAY_STATE & BitArrayState)
{
// convert to unsigned
...
// get the working k
...
// update nKSum
...
// update k
...
// store the overflow
...
// code the base
}
Hier nur die Kommentare, damit die Rice-Coding Struktur besonders leicht zu erkennen ist. Aber echt, immer diese Member, die meinen sie wüssten alles. Was eine Pest! ;)
Pinoccio
2008-11-17, 17:33:30
Ich finde diese Argumentation undurchsichtig. Ich kann auch 1000 Nullen in jeweils 32-Bit speichern. Aber ich glaube ich kann nachvollziehen was er sagen wollte.Im Grunde wird es sogar noch schlimmer durch die DCT. Das Bild liegt in 8 Bit Auflösung vor und die Ergebnisse der DCT werden zur weiteren Verwendung i.d.R. als float (oft 32 oder 64 Bit) im Speicher abgelegt. Der tatsächliche Speicherplatz steigt also in diesem Schritt.
mfg
o.O
Dein Ton ist völlig unangemessen.
Ich muss mich dafür entschuldigen, aber es frustriert ungemein, wenn jemand wie Pest von MAC erzählt und dabei absolut keine Ahnung hat.
Halbwissen. ;-) Das Vorzeichen kommt erst im Schritt nach der Quantisierung.
Sowas ist leider der Grund, warum man schnell gefrustet ist. Deine Aussage stimmt einfach nicht *seufz*. Natürlich können durch die DCT auch negative Koeffizienten entstehen. Das liegt doch in der Natur der Sache.
Pinoccio
2008-11-17, 17:55:02
Sowas ist leider der Grund, warum man schnell gefrustet ist. Deine Aussage stimmt einfach nicht *seufz*. Natürlich können durch die DCT auch negative Koeffizienten entstehen. Das liegt doch in der Natur der Sache.Hm, stimmt. 'tschuldigung.
mfg
Das mag eine Eigenschaft sein, aber irgendwie hast Du den Sinn der DCT nicht ganz verstanden. Stichwort: spatiale Dekorrelation. Meine Güte!
Das Wort gibt es gar nicht im Deutschen, aber nunja. Die Dekorrelation führt zwangsläufig zu dem was ich behauptet habe. Wie sie zu einer gewonnene Informationsredundanz führt musst du mir Pseudowisser aber noch erklären.
Dann helfe ich Dir ein letztes Mal auf die Sprünge, da Du das ja anscheinenend auch nur mehr schlecht als recht Quellcode lesen kannst.
das ist kein Rice-Kodierer. Und Das hast du oben behauptet.
Das es einen Wert ähnlich wie bei http://urchin.earth.li/~twic/Golombs_Original_Paper/ in "Mostsignificant+LeastSignificant-Part" unterteilt, stimmt. Mehr aber auch nicht wirklich.
Jetzt schreibst du RiceCoding-Struktur, damit kann ich mich anfreunden,
und ich habe gewiss' ne Menge Ahnung davon, ich hab nen besseren Kodierer als MAC geschrieben, da rede ich auch viel lieber mit der Wand :D
Im Grunde wird es sogar noch schlimmer durch die DCT. Das Bild liegt in 8 Bit Auflösung vor und die Ergebnisse der DCT werden zur weiteren Verwendung i.d.R. als float (oft 32 oder 64 Bit) im Speicher abgelegt. Der tatsächliche Speicherplatz steigt also in diesem Schritt.
mfg
Also die meisten Programme die ich aus dem OpenSource-Bereich so kenne, benutzen alle Festkomma zur Berechnung, aber egal
RGB->YUV führt also zu einer Speicherplatzerhöhung?! Informatiker! ;)
Das Wort gibt es gar nicht im Deutschen, aber nunja. Die Dekorrelation führt zwangsläufig zu dem was ich behauptet habe. Wie sie zu einer führt musst du mir Pseudowisser aber noch erklären.
Spatial und Dekorrelation sollte Dir doch etwas sagen, oder? Außerdem denke ich, dass ich schon zu viel Zeit aufgewendet, Dir etwas zu erklären. Leider bist Du in Deiner (oftmals falschen) Meinung festgefahren und denkst einfach nicht über das nach, was der andere schreibt.
das ist kein Rice-Kodierer. Und Das hast du oben behauptet.
Das es einen Wert ähnlich wie bei http://urchin.earth.li/~twic/Golombs_Original_Paper/ in "Mostsignificant+LeastSignificant-Part" unterteilt, stimmt. Mehr aber auch nicht wirklich.
Meine Güte, selbst der Entwickler schreibt, dass es Rice ist, aber der Pest, der weiß es natürlich noch besser. Du bist echt ne Nummer.
Jetzt schreibst du RiceCoding-Struktur, damit kann ich mich anfreunden,
und ich habe gewiss' ne Menge Ahnung davon, ich hab nen besseren Kodierer als MAC geschrieben, da rede ich auch viel lieber mit der Wand :D
Name und Link. Kann ja jeder schreiben.
Alles weitere dann bitte an die Wand richten. ;)
Pinoccio
2008-11-17, 18:39:37
Also die meisten Programme die ich aus dem OpenSource-Bereich so kenne, benutzen alle Festkomma zur Berechnung, aber egal[/QUOTE]Hm. Hier (http://www.w3.org/Graphics/JPEG/itu-t81.pdf) hab ich dauernd was von "real implementation" gelesen und dabei an die Implementierung von real-Zahlen im Computer gedacht. Wobei es mich wundert, daß die Präzissionsanforderungen mit fixpoint erreicht werden.Informatiker!Spar dir deine Beleidigung! ;-)
(Ist das mit der Wand reden auf mich bezogen?)
mfg
Außerdem denke ich, dass ich schon zu viel Zeit aufgewendet, Dir etwas zu erklären.
Noch habe ich Nichts gelernt. Das wäre jetzt der Fall gewesen...
Leider bist Du in Deiner (oftmals falschen) Meinung festgefahren und denkst einfach nicht über das nach, was der andere schreibt.
Ich brauche einfach viel zu lange um zu Begreifen was du mir in mehreren aufeinanderfolgenden Posts sagen möchtest, weil es oft etwas Anderes ist.
DCT+Quantisierung führen aber zu KEINER Volumenreduktion der Daten.
das ergibt mit deinem letzten Post zu dem Thema sogar Sinn.
Die Quantisierung führt ebenfalls nur zu einer *möglichen* Reduktion des Wertebereichs der Koeffizienten.
das ist z.B. schlichtweg falsch, wenn du Koeffizienten als das Resultat der DCT ansiehst
aber genug von dem Thema jetzt
Meine Güte, selbst der Entwickler schreibt, dass es Rice ist, aber der Pest, der weiß es natürlich noch besser. Du bist echt ne Nummer.
es ist eine Variante, kann ich doch Nichts für.
Rice-Codes benutzen explizit als Teiler eine Zahl 2^m, MAC definitiv nicht!
Genauso wie der MS-Teil kodiert wird.
Name und Link. Kann ja jeder schreiben.
Klappe zu, Affee tot!
(http://www.forum-3dcenter.org/vbulletin/showthread.php?t=417530)
Ist das mit der Wand reden auf mich bezogen?
lol, meine neue Sig
CABAC war ein Beispiel für den anderen Gast, dass nicht vor 50 Jahren schon alle Techniken bekannt waren.
Aber natürlich ist eine gute Entropy Stage auch für einen Video Codec sehr wichtig.
Ich versuche das mal grob an JPEG zu erklären, da es ja schon verwandt mit dem Thema ist. Nach der Abbildung in den YUV-Farbraum wird bei JPEG der DCT durchgeführt und dann die Koeffizienten quantisiert. Bis hierhin erzielt lediglich die Farbraumtransformation durch eine geringere Samplingrate der Farbinformationen eine moderate Datenreduktion. DCT+Quantisierung führen aber zu KEINER Volumenreduktion der Daten. Allerdings führt die Transformation zu einer Darstellung der Daten, die in der Entropy Stage dann hervorragend ausgenutzt werden kann. Ich vernachlässige hier einfach mal Sachen wie ZigZag und Co.Bei üblicherweise genutztem Farbsubsampling (pro 2x2-Pixelblock nur eine Farbe) reduziert man die Rohdaten bereits um 50%.
Die Quantisierung reduziert natürlich die Anzahl der verbleibenden möglichen Werte so dass man jeden Wert mit im Durchschnitt weniger als 8 Bit speichern kann. Die Zigzag-Anordnung wird genutzt weil es wahrscheinlich ist, dass die ganzen Werte hinten Null sind welche man natürlich nicht mehr speichert. Das würde ich jetzt nicht hochtragen Entropiekodierung nennen. Dass sich gröber quantisierte Daten besser komprimieren lassen ist klar.
Der Trick besteht darin, wo man die Daten weglässt. Würde man die Farbauflösung oder die räumliche Auflösung stark senken, fällt das sofort auf. Nutzt man eine gröbere Quantisierung der Frequenzanteile, fällt das nicht so auf. Niedrige Frequenzen sollte fein quantisiert werden, hohe Frequenzen kann man grob quantisieren. Darauf basiert Texturkomprimierung, welche ganz ohne Entropiekodierung auskommt.
Man kann auch sagen dass wir schlecht darin sind, absolute Helligkeiten (oder Farben) zu erkennen. In einem Gebiet "wo viel los ist", es also feine Details mit harten Kontrasten gibt, muss lediglich die Struktur noch gut erkennbar sein. Ob Farbton und Helligkeit nun genau getroffen werden oder nicht, spielt weniger eine Rolle.
Bei Videokompression spielt natürlich die VBSMC und Anhang sehr stark mit herein. Aber man sollte nicht den Fehler machen und annehmen, dass die Daten vor der Entropystage schon ein sehr kleines Volumen haben müssen. Die Transformationen+MC+RDO+... stellen natürlich das Herzstück eines Videocodecs dar, trotzdem bringt das alles ohne einen ordentlichen EC nur wenig.Entropieoptimierung vor der Komprimierung mit der Burrows-Wheeler-Transformation zu betreiben oder eine möglichst gute Entropiekodierung zu nutzen (wobei arithmetische Komprimierung Huffman natürlich überlegen ist) bietet kaum Ansätze zur Steigerung der Video-Komprimierungsrate, da die verlustfreie Komprimierung schon ziemlich ausgereizt ist. Größere Wörterbücher etc. steigern den Rechenaufwand und den Speicherbedarf aber bringen nur noch wenig Zusatznutzen. Auch die allerschlauesten Ansätze (ohne Wörterbücher oder mit irgendwelchen Transformationen vor LZ + Huffman/arithmetische Komprimierung) können nur begrenzt was bringen, da mit n Bits nur 2^n Zustände darstellbar sind.
Man ist bemüht eine Abbildungsvorschrift (Transformation und/oder Algorithmus) zu finden die häufig vorkommenden Muster mit möglichst wenig Bits beschreiben kann.
Das stimmt.
Man könnte natürlich als Entropy-Stage LZ+Huffmann oder LZ+Arithmetische Kodierung nutzen, allerdings wäre dies Zeitverschwendung. Das Wörtbuchmodell funktioniert auf allgemeinen Daten gut, ist aber spezialisierten Algorithmen wie CABAC stark unterlegen. Das liegt daran, dass CABAC auf die Verteilung der Daten nach der Transformation optimiert wurde.
Allgemeine Verfahren sind spezialisierten Ansätzen sehr häufig unterlegen. Man vergleiche die Packraten und Geschwindigkeiten von z.B. 7-zip und Monkey Audio auf Audiodaten (7-Zip = LZ + bin. AC mit MRU; MAC = Transformation+Rice-Coding). Auch hier bei MAC führt die Transformation (LPC ähnlich) zu keiner Reduktion der Daten. Die Darstellung der Daten kann das extrem simple und schnelle Rice-Coding aber hervorragend ausnutzen, da es für residuale Daten recht gut geeignet ist.Ja, und Rar hat nicht umsonst spezielle Algorithmen für bestimmte Medienformate wie Wave oder Bitmap. Trotzdem muss man den Informationsgehalt komplett wiederherstellbar kodieren, womit der Komprimierungsrate unabhängig vom Ansatz Grenzen gesetzt sind.
Aber nun auch mal zum Thema:
IMO wird sich vor allem für kleine Datenraten bestimmt immer wieder etwas tun. Wavelets haben die Eigenschaft bei sehr kleinen Datenraten angenehme Artefakte zu erzeugen. Allerdings ist H.264 durch den integralen Deblocking Filter hier auch schon ganz gut aufgestellt. Auch von Wavelets sollten keine Wunder erwartet werden.
Objekt-basierte Video-Kompression ist mMn Zukunftsmusik. Solange niemand bessere und vor allem schnellere Algorithmen für diesen Ansatz (er)findet, wird es nicht mehr als ein Papiertiger bleiben.
Bei fast transparenter Videokompression sieht es aber wesentlich schwieriger aus.Da die verfügbaren Datenträger aus der Massenproduktion immer größere Kapazitäten haben und man keine beliebig hohe Videoauflösung braucht, dürfte außer für Nischenanwendungen kaum Bedarf nach einem neuen Komprimierungswunder bestehen.
RGB->YUV führt also zu einer Speicherplatzerhöhung?! Informatiker! ;)Da der RGB-Würfel nur rund 1/4 des YPbPr-Raumes ausmacht, verliert man mit einer Transformation RGB (888) auf YPbPr (888) Farbauflösung (von durchschnittlich zwei Bit.)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.