MPEG-4 weiterentwickelt?

Zitat

mir geistert derzeit eine art Moving Object Peeler
und Object Surface Splitter durch den Kopf..
sodass der stream in mehrere objektebenen zertrennt wird
und so zum beispiel in einem idealfall sogar besser als das
original werden kann...

Zitat

ich möchte mein arsch verwetten das sowas nicht in mpeg-4 drin ist..

=> SpriteCoding, was in Mpeg4 schon lange vorgesehen ist,...
(aber was will man mit Deinem Hintern?)

Die Diskussion ist meiner Ansicht nach hinfällig, sollange Du Dir nicht mal die Sachen durchgelesen hast die in Mpeg4&AVC/h.264 geplant sind.

Zitat

tut mir leid das ich mir keine englischen kompendien reinziehe
die so dick sind das man sie als mordwaffe benutzen kann (wenns als papier gäbe)...

Muss Dir ja nicht leid tun, dass Dein Interesse am Thema so niedrig ist. Aber Dokumentationen von Kompressionsverfahren sind nunmal was umfangreicher. Und vorallem wenn man später nicht wegen Patentverletzungen probleme kreigen will, sollte man mal abchecken, was sonst so implementiert wurde/wird.

Cu Selur

Nur als Nebeninfo :

matroska kennt 16 unterschiedliche frame Typen, von denen im Augenblick nur 4 verwendet werden ( I, P, B, D ). Du könntest einen neuen frame type einführen, der sich auf frames weit vorne im Film bezieht, d.h. ausselhalb seines GOP/VOP. Das würde aber bedeuten daß Du ziemlich heftig in den codec selbst eingreifen müsstest, da einzelne frames über lange Zeit zwischen gebuffert werden müssten, sonst wird der Film von CD wegen der langen Suchzeiten unspielbar.

Das matroska frame type concept könnte einen neuen I frame definieren, der im Buffer verbleiben soll um für einen P/B frame in der Zukunft wiederverwendet werden zu können. Wie gesagt, das wäre gleichzusetzen mit einer codec Neuentwicklung, also besser gleich auf AVC/h.264 warten ;).

Eine andere Lösung, und leicht zu machen, wäre die geplanten 'control tracks' zu verwenden, damit können dann einzelne Sequenzen in einem Film, die sich immer wieder wiederholen, einfach nochmal abgespielt werden. War ursprünglich hauptsächlich für intro/outro gedacht, wenn mehrere eps auf einer CD liegen sollen, könnte aber auch dafür zweckentfremdet werden. Vorteil : Würde mit jedem codec funktionieren, und ohne Änderungen.....

DJ oSSi:
bitte lese dir mal das hier zu MPEG4 durch. Für das was du hier beschreibst, kannst du die 2D und 3D Funktionen nutzen.

AC-Chan(Robert Vincenz)

Es gibt ein Problem mit MPEG4. Es ist zuvielfältig.
Wenn du willst kann ich dir mal die letzten Draft vor dem Standard schicken. Damit du mal siehst was noch alles dazu gehört. Auch ist MPEG4 noch nicht abgeschlossen(MPEG1 und 2 übrigens auch noch nicht). So das sich noch keiner daran machen konnte alles zu implementieren. Also hat man erstmal mit dem begonnen was man relative leicht aus bisherigem weiterentlickeln konnte und was wichtig ist.
Über den Stand der Dinge ist eigentlich https://localhost/www.chiariglione.org/mpeg recht gut, leider ist die Seite im Moment down(letzte woche lief sie noch). Chiariglione ist übrigens der "Vorsitzende/Leiter" von MPEG.

Wegen des Editieren des Titels. Das soll gehen, frag mich aber nicht wie.

AC-Chan(Robert Vincenz)

Als ich es geschrieben hatte, hatte ich es versucht und mehrfach timeouts bekommen.

AC-Chan(Robert Vincenz)

Zu Spritecoding:
Ich hab mich mal vor ner weile damit beschäftigt und auch mit einigen cleveren Köpfen die sich mit Bild- und Videoverarbeitung gut auskennen unterhalten und dabei sind wir zu folgenden Schlussfolgerungen gekommen:

1. wenn man nicht die Sprites vordem Encoden schon als solche hat, besser noch als 3D Modelle ist es sehr schwer und rechenintensiv diese zu extrahieren => hat man die Sprites nicht schon ist die Fehlerrate beim extrahieren wahrscheinlich so hoch, dass der Aufwand sich nicht lohnt

2. vorallem bei komplexeren Sprites wird sich höchstwahrscheinlich kein Kompressionsgewinn gemacht, beim Spritecoding als Feature geht es vielmehr darum die möglichkeit zu haben Sprites auszutauschen als bessere Kompression (bei gleicher Qualität) zu erziehlen. (Kompressionsgewinne sind nur bei einfachen Zeichentrick/Anime clips wirklich zu erwarten.)

=> wir sind dann alle geschlossen zu der Ansicht gelangt, dass man anstatt sich mit Spritecoding zu beschäftigen man sich lieber H264 widmen sollte.

Cu Selur

Ps.: Ich will euch aber nicht davon abbringen die Idee weiter zu verfolgen, da ich es witzig fände später mal in nem Film Schauspieler mit vergleichbarer Statur in Filmen auszuwechseln.

Zitat

Ps.: Ich will euch aber nicht davon abbringen die Idee weiter zu verfolgen, da ich es witzig fände später mal in nem Film Schauspieler mit vergleichbarer Statur in Filmen auszuwechseln.

Auch wenn du es als Spass makiert hast, zeigt sich eigentlich genau dort das Problem des ganzen. Denn Sprites (ist das die mehrzahl eine getränkes? dürfen keine eigenveränderung haben. Diese sind aber immer vorhanden. Bei hand gezeichnetem durch die Digitalisierung und bei Computergeneriertem durch diverse Schritte wie zoom und ähnlichem(die Bilder/Elemente sind meist nicht in der größe wie sie dann im Werk zu sehen sind). Es werden sich als mit größter Warscheinlichkeit solche sprites nie wirklich extrahieren lassen.
Dies alles bezog sich auf fertige videos.

AC-Chan(Robert Vincenz)

Zitat

hintergründe (backgrounds) nicht neu aufgebaut

Das wird aber auch nicht viel mehr bringen als wenn man es mit P-Frames komprimiert. Und wenn du damit meinst, die Hintergründe aus einer vorherigen Szene verwenden, dann will ich mal dran erinnern, was schon des öfteren im englischen Forum von den XviD Entwicklern gesagt wurde: "I-Frames machen nur einen kleinen Teil des kompletten Films aus".
Ich würde nicht so viel Zeit mit Sprite-Coding verschwenden, ich glaub als erstes müssen mal Wavelet-I-Frames her, dann glaub ich, dass man mit nicht blockbasierenden Bewegungsvectoren mehr erreichen kann. Dann sollte man auch noch die bisherige DCT durch eine Integer basierende ersetzen. Wenn das interesiert, kann sich meine Quellcodebeispiele mal anschauen.

Zitat

ann sollte man auch noch die bisherige DCT durch eine Integer basierende ersetzen.

und dann geht's in Richtung h264

Was auch cool wäre, ist wenn sich ein paar Leut hinsetzen und mal versuchen skals Codec ordentlich zum laufen zu bringen. (mit GUI )

Cu Selur

Zitat

Was auch cool wäre, ist wenn sich ein paar Leut hinsetzen und mal versuchen skals Codec ordentlich zum laufen zu bringen. (mit GUI )

jup!
Das wuerde ich auch verdammt cool finden.

DJ oSSi
Du koenntest dir ja mal ein paar Gedanken ueber ein HVS-Model machen, da es nach XviD1.0 in dem Bereich weitergehen soll. Die XviD Devels (besonders sysKin) wuerden sich sicher ueber Ideen freuen.

Mein Vorschlag wäre die erweiterung mit den menu Funktionen(Wie sie GAPAC schon implementiert hat).

AC-Chan(Robert Vincenz)

nur mal so gefragt:
1. Haste Dir mal überlegt, ob und wieviel Deine 'Wünsche' an Einsparungne bringen könnten und wieviel Overhead sie erzeugen?
2. Haste Dir mal h264 angeguckt?
3. Haste Dir mal überlegt ob Deine Vorschläge nur was bringen wenn man das Roh-/Studiomaterial oder auch wenn man ne DVD als Quelle hat?

HVS = Human Visual System
Dabei geht es grob gesagt darum die Einschränkungen der Optischen Wahrnehmung auszunutzen.
z.B.:
- Luminanzunterschiedewerden früher erkannt als hrominanzunterschiede
- Unterschiede im Vordergrund sind sichtbarer als solche im Hintergrund
- Unterschiede in Flächen sind eher erkennbar als solche in hoch frequenten Bildteilen
- Unterschiede in stehenden Bildteilen sind eher erkennbar als solche in bewegten Bildteilen

Ganz nett zu lesen:
http://www.irt.de/IRT/aktuelles/…_d-Fernsehb.pdf
( DJ oSSi: Achtung dies ist ein Text der ganze 17 Seiten enthält, es ist also durchaus verständlich, wenn Dein Interesse nicht so hoch ist, dass Du Dich aufraffst ihn zu lesen. Es gibt auch bessere, danna ber umfangreichere und neglische Texte zu dem Thema.)

Allen die sich für HVS interessieren sei auch ans Herz gelegt sich über allgemeine Qualitätstestverfahren zu informieren, da in diesem Bereich öfter gute Informationen in Richtung HVS gesammelt werden.

Cu Selur

Zitat

ich wünsche mir zusätzliche bewegugsvektoren die veränderungen
im helligkeitsbereich erfassen

Wenn nur eine Änderung der Helligkeit in einem Macroblock auftritt, dann sind alle Werte bis auf den 1. Null (im Idealfall, nach der Quantizierung aber auf jeden fall), somit kann man sie einfach weg lassen, und den 1. Wert könnte man dann als deinen "Bewegungsvektor für Helligkeit" bezeichnen. Nur muss man in der Bewegungsvectorensuche auch darauf achten, denn oft wird eine Bewegung wargenommen, aber es hat sich nur die Helligkeit geändert. Hier muss man dann einen Algorithmus verwendet, der auf so etwas nicht "rein fällt". SAD (Summe aller absoluten Differenzen) z.B. ist hier recht anfällig, wenn man jedoch vor dem SAD die durchschnittliche Differenz berechnet und dann die Summer aller absoluten Differenzen von der durchschnittlichen Differenz berechnet kommt man dem realen Vector schon näher.

  DJ oSSi
Es müssen nicht umbedingt neue Features eingeführt werden, erst sollten die vorhanden bis an ihre Grenzen ausgenutzt werden.