neues Kompressionsverfahren - 20x besser als MPEG [Archiv]

Mark

2005-02-05, 19:26:59

grade eben auf 3sat gesehn:
http://www.3sat.de/3sat.php?http://www.3sat.de/neues/sendungen/spezial/75626/index.html

Wir gingen natürlich sehr skeptisch an die Sache heran und brachten einen Pampers Spot mit. Uwe produzierte wie versprochen eine sehr kleine Datei. Dann spielte er die Datei ab. Und die Datei lief wunderbar. Doch was hier interessant ist, war nicht nur die beeindruckend geringe Größe der Datei. Uwe hat es geschafft, die kodierte Datei, die wir ihm gaben, die auch noch weniger als die volle Bildschirmauflösung hatte, besser zu machen. Der Clip hatte eine bessere Auflösung. Die Graphiken, die vorher ein wenig weich waren, wurden plötzlich scharf. Und einige Aspekte des Bildes waren deutlich besser. Und da wusste ich sofort, dass wir es mit einer völlig neuen Methode der Komprimierung zu tun hatten. Eine ganz neue Herangehensweise.

also die technik hört sich her gut an, auch das es schon nen prototyp gibt.
irgendwie freu ich mich auf die zukunft ;)

Lokadamus

2005-02-05, 19:38:19

mmm...

Ehrlich gesagt finde ich das nicht ganz so spannend. Die Technik selber wurde mal in einer ct als Aprilscherz vorgestellt, wenn ich mich richtig erinnere. Auch steht dort nicht dabei, wieviel Rechenleistung minimum gebraucht wird und was es überhaupt für ein Film war (ein Comic ala Simpsons dürfte nicht schwer sein, in hoher Qualität wiederzugeben, ein Actionfilm mit schnellem Szenenwechsel und einer Explosion ist eher interessant, weil dabei ein schneller Wechsel der Farben/ des Bildes geschieht, was bei MPEG schnell zu hässlichen Artefakten führt) . Ebenso könnte man mit heutiger Rechenleistung das Videobild noch durch ein paar Filter schicken, was zu einem angenehmeren Bild führen würde, aber gleichzeitig Highend- Hardware vorraussetzen würde.

Duran05

2005-02-05, 19:41:13

Wenn man sich Text durchliest, könnte man auf die Idee kommen, das hier ein DAU am Werk war. ;)

Doch nun will einer das Verfahren von Grund auf revolutionieren. Uwe Prochnow will Videos in Fernsehqualität so komprimieren, dass sie ohne nennenswerten Qualitätsverlust durch jede gewöhnliche Telefonleitung passen. Experten galt dies bisher als unmöglich.

;D
Was ist eine "gewöhnliche" Telefonleitung? Die Daten passen auch jetzt schon durch, es dauert bloß länger. :tongue:
Sogenannte "Experten"? In dem Artikel jedenfalls nicht. ;)

GUNDAM

2005-02-05, 19:46:07

Hoffe nur das derjenige, der diesen Artikel geschrieben hat, nicht auch den Codec geschrieben hat :D

Muh-sagt-die-Kuh

2005-02-05, 19:57:21

Sounds like Bullshit...was da beschrieben wird ist in Echtzeit keinesfalls machbar.

Duran05

2005-02-05, 20:08:31

Seit 1992 betreiben wir Fernsehkanäle ausschließlich für Banken. Hier haben wir zum Beispiel einen Mitarbeiterkanal, der für Schulungen benutzt wird, und dort haben wir einen Kanal, der sich an den Kunden in der Filiale wendet. Wir nutzen MPEG-1 Kodierungen und haben dadurch sehr große Dateien. Ein 10-Minuten- Programm ist ungefähr 250 MB groß.

... dass wir zum Spitzenprodukt eine 20-fache höhere Komprimierung erreichen, unter gleichen Leistungsmerkmalen wie das Ausgangsmaterial dazu ist.

Das könnte man so verstehen, das die Datei ca. 20x kleiner ist als die ursprüngliche MPEG-1 Datei.

Angekündigt wurde schon vieles (wo bleibt der 100 GHz Prozessor? ;)), glauben sollte man das erst, wenn es wirklich jeder nutzen kann.

Momo

2005-02-05, 20:18:21

aber sowas von aaaalt...

Linien statt Pixel: PAL-Qualität über die Telefonleitung

Eine neuartige Form der Videocodierung hat die Essener Firma Atvisican entwickelt. Die Entwicklung von Firmenchef Uwe Prochnow löst die Pixelstruktur des Bildes auf und berechnet statt dessen Linien und Kurven, statt vieler Bilder pro Sekunde nur Bewegungsrichtung und Geschwindigkeit. Damit lässt sich ein TV-Bild so weit komprimieren, dass es über eine normale ISDN-Telefonleitung von 64 kbit/s geschickt werden kann – ohne Ton allerdings. Das, was auf der anderen Seite ankommt, ist freilich nur eine Annäherung ans Original-Bild, wenn auch eine erstaunlich scharfe; schließlich sind Kurven immer scharf. Aber der Hintergrund kann dann schon mal durch einen simplen Farbverlauf ersetzt werden. Dem Vordergrund, den der Codec an seinen scharfen Konturen erkennt, widmet das System dagegen die ganze Aufmerksamkeit, zumindest den größeren Strukturen. Ein einzelnes Haar dagegen, dessen Berechnung möglicherweise genauso viel Leistung erfordert wie der gesamte Umriss eines Kopfes, wird abgeschnitten, wenn nur wenig Datenrate zur Verfügung steht.

Die Codierung taugt aber nicht nur für möglichst niedrige Datenraten, sondern auch für beste Bildqualität. Damit kann man Bilder perfekt skalieren und sogar Bildwiederholraten anpassen. Diesem Zweck dient sie im Allcanview ACV-1SE, einer Art Home Server der Luxusklasse. Uwe Prochnow tritt mit diesem Gerät gern den Beweis an, dass hier keine Pixel verrechnet werden: Mit einem Lupenwerkzeug lässt sich jedes Detail in einem Bild vergrößern – und es kommen keine Bildpunkte zum Vorschein, egal wie hoch man den Faktor wählt. Ob die Technik wirklich bei Hochskalierung zum Beispiel einer DVD auf einem 720-Zeilen-Display eine dramatische Verbesserung bringt, müsste man noch im Detail untersuchen. Höchste Weihen hat der Atvisican-Codec jedenfalls schon erhalten: Der MDR in Leipzig will sein komplettes Archiv, inklusive von HDTV-Aufnahmen, auf diese Weise digitalisieren.
(Quelle (http://www.loehneysen.de/archiv/2004/acv/story.html))

also ganz so toll wie bei 3sat dargestellt isses wohl ned... entweder klein und schlecht oder groß und gut.

Crazy_Bon

2005-02-05, 20:30:36

Wieso sollte die Technologie nicht besser sein? Die bekannten Codecs für Videos leiten mehr oder weniger alle von Mpeg ab.
Wenn wir denken schon das optimalste aus einem Bild rausholen zu können, dann stimmt das schon einmal nicht wenn das Verfahren von Mpeg nicht optimal ist.

Wenn zum Beispiel das grösste Softwareunternehmen gewisse Begrenzungen in ihre Betriebssysteme haben (z.B. maximale Speicheradressierung, kein OpenSource, zu lahm, weiss der Geier was), betrifft das nicht die alternativen Betriebsysteme, die völlig anders (vor allem ohne Altlasten) aufgebaut sind.

Momo

2005-02-05, 20:40:57

kann mir schon vorstellen dass es besser is, aber bestimmt nich in dem maße dass man dvd-quali durch telefonleitungen kriegt.

wie gut es genau is, sollte man mal ausprobieren... die technik is immerhin schon mindestens ein jahr alt?
schon fast verdächtig, dass es da noch keine richtigen vergleiche gibt :confused:

für richtig gute qualität halte ich das verfahren eh eher ungegeignet, weil größere flächen mit kaum sichtbaren, aber sehr vielen farbübergängen einfach überproportional viel aufwand benötigen würden... aber für akzeptable qualität auf kleineren bildschirmen is das sicher ein interessanter ansatz :)

Crazy_Bon

2005-02-05, 20:56:21

Interessant finde ich neben der Komprimierung auch die Schärfung und Skalierung des Bildes. Erinnert mich an HQ2/3/4x Filter von Emulatoren, die um aus dem niedrig aufgelösten Pixelbrei scharf gezeichnete Vollbilder hervorzaubern.
für richtig gute qualität halte ich das verfahren eh eher ungegeignet, weil größere flächen mit kaum sichtbaren, aber sehr vielen farbübergängen einfach überproportional viel aufwand benötigen würden... aber für akzeptable qualität auf kleineren bildschirmen is das sicher ein interessanter ansatz
Du scheinst die vorletzte Seite überlesen zu haben.

Momo

2005-02-05, 21:13:56

Du scheinst die vorletzte Seite überlesen zu haben.
ich muss gestehen, ich hatte nur seite 1 gelesen und die anderen nich gesehen :ugly:

jetz hab ich alles gelesen, das ändert aber auch nich wirklich was an meiner meinung...

Ikon

2005-02-05, 21:16:19

1) Unmenschlich hohe Rechenleistung notwendig.

2) Das Bild dürfte wesentlich mehr als bei MPEGx entfremdet werden. Der Kodierer muss hier schließlich Objekte erkennen und kategorisieren (Kante, Farbverlauf, einfarbige Fläche, ...), während MPEGx im Prinzip nur zwischen bewegten und statischen Bildfragmenten unterscheidet.
Der Artikel spricht über einen Werbe-Spot, der nach der Kodierung plötzlich deutlich schärfer war - was aber wenn Unschärfe gerade gewünscht ist? Ich bezweifele, dass sich dieses Verfahren für "normales" Filmmaterial eignet -> höchstens für Cartoons/Animes/Zeichentrick wäre es wohl sinnvoll einsetzbar. Oder auch für (Ultra-)Low-Bitrate-Streaming-Videos, wo weniger auf eine akkurate Nachbildung des Quellmaterials ankommt ...

maximAL

2005-02-05, 21:34:53

/leicht offtopic
ich hatte vor jahren mal irgendein programm, dass mit einem eigenen format daherkam, welches wesentlich besser als jpeg komprimiert hat. also wesentlich kleiner, bei gleicher qualität. wer weiss, wo das abgeblieben ist...

Coda

2005-02-05, 22:12:41

Öhm. Man kann normale Fernseherbilder nicht in Vektorgrafik zerlegen. Das geht vielleicht mit Zeichentrick, aber auch da isses schon reichlich schwierig.

Mark

2005-02-05, 23:49:39

es geht ja nicht direkt um vektorgrafik, sondern dadrum das objekte erkannt werden die dann spätere nicht nochmal übertragen werden müssen sofern sie sich nicht verändern.

naja, die zeit wirds zeigen, hoffen wir einfach mal das beste

tombman

2005-02-06, 00:09:51

Also ich habs auch gesehen und war schon beeindruckt...

Und warum soll das nicht in Vektorgrafik zerlegbar sein? Außerdem gehts ja hauptsächlich darum Objekte zu kategorisieren und nicht wie mpeg Pixelblöcke zu bearbeiten.

Und ich glaub kaum, daß Leute wie TI bei dem Typen vorbeischauen wenn es nur bullshit wäre.

Aquaschaf

2005-02-06, 00:32:14

Außerdem gehts ja hauptsächlich darum Objekte zu kategorisieren und nicht wie mpeg Pixelblöcke zu bearbeiten.

...was noch komplizierter ist als aus einem Bild eine Vektorgrafik zu machen.

Crazy_Bon

2005-02-06, 01:23:08

Also wenn einer 12.800€ übrig hat, der kann mal ein solches Gerät anschaffen und für uns antesten.

Mark

2005-02-06, 23:16:59

Also wenn einer 12.800€ übrig hat, der kann mal ein solches Gerät anschaffen und für uns antesten.

omg, da hat 3sat aber nen bösen schreibfehler reingebracht. im bericht haben die gemeint das teil kostet 1.280€ und nicht 12800....

außerdem ist das nur ein gerät der firma, was quasi als standalone-gerät funktioniert, aber nicht die neue technik an sich

irgendwie versteh ich die leute net die gleih sofort sagen das es das nicht gibt und das das nicht gehn wird. warum sollte es nicht gehn? warum sollte man das nicht machen können? wohlmöglich is der typ ein genie und weiß halt wie man das anpacken muss damit esa auch mit moderater rechenleistung funktioniert

Mark

2005-02-06, 23:34:42

also das prinzip dürfte in etwa so sein

im grunde funktioniert es wie mpeg, nur das der speicher für die bildinformationen größer ist. bei mpeg werden nur sich verändernde bilddaten nochmal übertragen, jedoch nur vom letzten frame. der atvisican codec speichert diese informationen anscheinend vom ganzen film, bestimmte objekte werden daher nur 1mal übertragen, während des ganzes films. man könnte nun das raster für die suche von objekten beliebig klein machen, dann könnten viel mehr kleine objekte gefunden werden. wenn man jetzt anhand von geschwindigkeit und richtung von z.b. sich bewegenden objekten das neue bild im vorraus berechnen kann, dann kann somit nochmal datenübertragung gespart werden.

so in etwa dürfte das ganze funktionieren. quasi wie mpeg, nur anders ;)

Muh-sagt-die-Kuh

2005-02-07, 01:22:05

also das prinzip dürfte in etwa so sein

im grunde funktioniert es wie mpeg, nur das der speicher für die bildinformationen größer ist. bei mpeg werden nur sich verändernde bilddaten nochmal übertragen, jedoch nur vom letzten frame.MPEG ist nicht auf das vorangehende Bild limitiert.der atvisican codec speichert diese informationen anscheinend vom ganzen film, bestimmte objekte werden daher nur 1mal übertragen, während des ganzes films.Es existiert im Moment kein Algorithmus der automatisch und effzient Objekte jeglicher Art in jeder erdenklichen Umgebung erkennen kann. man könnte nun das raster für die suche von objekten beliebig klein machen, dann könnten viel mehr kleine objekte gefunden werden.Es existiert eine astronomisch hohe Anzahl an Objekten in einem Film....das ist heute einfach nicht machbar.wenn man jetzt anhand von geschwindigkeit und richtung von z.b. sich bewegenden objekten das neue bild im vorraus berechnen kann, dann kann somit nochmal datenübertragung gespart werden.Genau das macht Motion Estimation bei MPEG.....auf Makroblockebene.so in etwa dürfte das ganze funktionieren. quasi wie mpeg, nur anders ;)Ich bleibe dabei....die Firma hat außer heißer Luft nichts zu bieten.

Crazy_Bon

2005-02-07, 03:50:55

@Muh-sagt-die-Kuh
Also wenn Mpeg das alles schon könne, wieso haben die dann so eine beschissene Kompression bzw eine niedrige Effizienz?

tombman

2005-02-07, 05:09:58

Außerdem is es eine VEKTOR basierte KOmpression, nicht Pixel...

Deswegen sagt er ja auch er kann stufenlos zoomen ohne fette Megapixel .... is also gänzlich anders als MPEG.

MaiKi

2005-02-07, 07:23:24

naja dann hat man irgendwann ein video das auf nem hochleistungsrechner läuft... aber solange die codecs dann nicht auf dvd playern standart werden sind sie finde ich nicht sooo interresant!

wenn es jemand schaffen würde die qualität dvd player tauglich (mit den normalen geräten) zu machen DANN würde ich es erst als "revolution" bezeichnen :)

Muh-sagt-die-Kuh

2005-02-07, 09:27:19

@Muh-sagt-die-Kuh
Also wenn Mpeg das alles schon könne, wieso haben die dann so eine beschissene Kompression bzw eine niedrige Effizienz?Weil es stur mit 16x16 Makroblöcken (Luma) bzw 8x8 Makroblöcken (Chroma) arbeitet. Eine Motion Estimation arbeitet nun aber mit kleineren Blockgrößen in einigen Bildbereichen deutlich effizienter. Hier liegt auch der Hauptunterschied zwischen MPEG-2 und MPEG4: Letzteres erlaubt es schon im Simple Profile, einen 16x16 Block in 4 8x8 Blöcke zu unterteilen wenn es die Situation erfordert, dazu kommen dann noch solche Dinge wie die Vorhersage von Makroblöcken aus umliegenden Makroblöcken.

Muh-sagt-die-Kuh

2005-02-07, 09:34:35

Außerdem is es eine VEKTOR basierte KOmpression, nicht Pixel...

Deswegen sagt er ja auch er kann stufenlos zoomen ohne fette Megapixel .... is also gänzlich anders als MPEG.Gänzlich anders? Nein, auch bei Vektorgrafik basiertem Video sollte man die Objekte mittels Bewegungsvektoren zwischen den Bildern verschieben. Das nennt sich auch "Animation" ;)

Mal abgesehen davon ist Vektorgrafik für Video absolut ungeeignet.....viel Spass beim Versuch einen Baum mit vielen Blättern per Vektorgrafik und ohne die Verwendung von Texturen nachzubauen.

Xmas

2005-02-07, 18:02:28

Wir gingen natürlich sehr skeptisch an die Sache heran und brachten einen Pampers Spot mit. Uwe produzierte wie versprochen eine sehr kleine Datei. Dann spielte er die Datei ab. Und die Datei lief wunderbar. Doch was hier interessant ist, war nicht nur die beeindruckend geringe Größe der Datei. Uwe hat es geschafft, die kodierte Datei, die wir ihm gaben, die auch noch weniger als die volle Bildschirmauflösung hatte, besser zu machen. Der Clip hatte eine bessere Auflösung. Die Graphiken, die vorher ein wenig weich waren, wurden plötzlich scharf. Und einige Aspekte des Bildes waren deutlich besser. Und da wusste ich sofort, dass wir es mit einer völlig neuen Methode der Komprimierung zu tun hatten. Eine ganz neue Herangehensweise.
Bildverfälschung scheint also eine Stärke des Codecs zu sein, wenn man diese Passage von einem etwas anderen Standpunkt interpretiert. Begeistert mich nicht, aber es gibt sicher Anwendungen dafür.

GloomY

2005-02-07, 18:36:45

Momo

2005-02-07, 18:52:59

Mal abgesehen davon ist Vektorgrafik für Video absolut ungeeignet.....viel Spass beim Versuch einen Baum mit vielen Blättern per Vektorgrafik und ohne die Verwendung von Texturen nachzubauen.
das meinte ich ja auch... das verfahren mag gut sein um sehr kleine videos mit akzeptabler qualität zu produzieren, in denen es mehr auf scharfe umrisse als viele kleine details ankommt; für richtig gute bildqualität is es aber wohl ungeeignet.

Crazy_Bon

2005-02-07, 19:03:58

Wie kann man etwas "besser" machen als das Original? Die Information ist weg, da kann man nichts dran ändern. Wenn der Autor mit "besser" wirklich informationsreicher meint, dann ist das garantiert eine Ente. Andernfalls soll er sich doch bitte präziser ausdrücken... :|
Ich will ja nicht sagen, dass eine solche Technologie angewendet wird, aber wie in einem vorherigen von Post mir, erinnert das stark an folgendes. Aus einer verpixelten Vorlage ist ein schärferes Bild möglich.
http://www.hiend3d.com/hq4x.html
Das lässt sich sogar auch auf Texturen von 3D-Objekten anwenden. http://www.hiend3d.com/smartflt.html

Wieso sollte man das nicht in ähnlicherweise auch mit Videos anwenden?

Klar kann hier und da mal ungewollt kleinere Artefakte enstehen, dass einge Dinge zu scharf gezeichnet oder leicht rundlich wirkt, aber allemal besser als Blur- oder bilineares Filtering-Flickwerk.

Xmas

2005-02-07, 21:45:09

Ich will ja nicht sagen, dass eine solche Technologie angewendet wird, aber wie in einem vorherigen von Post mir, erinnert das stark an folgendes. Aus einer verpixelten Vorlage ist ein schärferes Bild möglich.
http://www.hiend3d.com/hq4x.html
Schärfer? Was ist daran schärfer als beim Zoom mit Point-Sampling? Und woran machst du fest welches dann näher am "Original" ist? Das kannst du nur wenn du bereitsdas Wissen bzw. eine Erwartung hast, wie die Vergrößerung aussehen soll.

Das lässt sich sogar auch auf Texturen von 3D-Objekten anwenden. http://www.hiend3d.com/smartflt.html
Mit Aliasing. Wie es sich mit Mipmapping verträgt, wird nicht gezeigt. Außerdem muss das im Content vorgesehen sein. Im vorliegenden Fall sieht es brauchbar aus, für Fototexturen ist es das sicher nicht.

Wieso sollte man das nicht in ähnlicherweise auch mit Videos anwenden?
Für Comics vielleicht. Für Realbilder kaum brauchbar.

Klar kann hier und da mal ungewollt kleinere Artefakte enstehen, dass einge Dinge zu scharf gezeichnet oder leicht rundlich wirkt, aber allemal besser als Blur- oder bilineares Filtering-Flickwerk.
In einem eingegrenzten Verwendungsbereich, ja. Generell eher nicht.

Crazy_Bon

2005-02-07, 22:38:20

Es ging mir darum die Aussage, dass verlorene Information für immer weg sind, zu widerlegen. Klar stimmt das, aber wenn sich bewegende Objekte schon im vorraus berechnet werden, wieso dann nicht auch Teile wieder rekonstruiert werden?

Coda

2005-02-07, 23:20:11

Gassst

2005-02-08, 01:35:40

Habe den Artikel gelesen, und folgendes ist mir aufgefallen.
Lorenz Hahnewinkel:
Ganz sicher. Ja, ja. Dass der erst mal erkannt hat, dass man diese neuronalen Netze jetzt hier für diesen speziellen Zweck einsetzen kann. Denn Datenkompression, da grübeln viele dran, und keiner ist auf die Idee gekommen, da neuronale Netze einzusetzen, und das ist ein ganz großer Fortschritt.
Einsatz von neuronalen Netzen.
Mmmmh. In welcher Form und in welchem Algorithmus?
Das die Erforschung von neuronalen Netzen am Anfang und vieles nicht schlüssig ist, ist die Frage, was es noch bringen kann?
Lassen wir uns überraschen.

Eine weitere Quelle ist dieser:
http://www.drefa.de/aktuell/pdf/newsletter_04_06.pdf
Seite 12:
Kurznachrichten
Seite 12
Nummer 30 Juni 2004 monatlich
DREFA Media Service
GmbH bei der Hausmesse
der Lintec AG 17.-19. Juni Dresden 2004

Anlässlich der Präsentation der „neuen“ Lintec AG lud das
Unternehmen alle seine Partner zu einem gemeinsamen Stelldichein.
Die DREFA Media Service GmbH als der Partner im Bereich „Home-
E n t e r t a i n m e n t “ m i t d e m
„Allcanview“ war mit einem eigenen Stand präsent. Gemeinsam mit zwei
der autorisierten Allcanview-Händlern, der Avisystems aus
Chemnitz und der TVC GmbH aus Leipzig und Halle, begeisterte man
mehr Kunden als erwartet. Die BoldMedia GmbH aus Leipzig
unterstützte die Veranstaltung mit professioneller Technik. Präsentiert
wurde der „allcanview acv-1SE“ vom technischen Leiter Alexander
Kölling und Burkhard Liebmann.
„Wir konnten viele interessante Kontakte knüpfen, die auf weitere
gute Zusammenarbeit hoffen lassen.“, so die beiden.
www.drefa-msg.de
Dort ist auch ein Bild von der Präsentation.

Laut 3-Sat-Neues wurde ein 30 Sekunden Werbespot in fast voller Auflösung auf 1,5 MB komprimiert.
1,5 MB / 30 Sekunden = 1572864 Bytes / 30 Sekunden = 52428,8 Bytes/Sekunden = 419430,4 Bit/Sekunden
Für die Audio-Kodierung ziehe ich mal 64 kBit/s ab.
Dann bleiben rund 355430 Bit/Sekunde, also 355 kBit/s, übrig.
Mit xvid bekommt man in dieser Bitrate auch in guter Auflösung ein gutes Video hin, wenn man lange herumrechnen lässt.

Umgekehrt:
45 Minuten wären dann rund 135 MB. Paar MB mehr und auch bei xvid sieht es besser als VCD aus.

Wenn es in hoher Auflösung (DVD bis HDTV 1080p) in der niedrigen Bitrate ist, dann wäre es nicht schlecht.

Gassst

2005-02-08, 02:34:45

Auf 2 Messen kann man es bewundern:

Messe: HIGH END 2005
Datum: 05. - 08. Mai 2005
Land: Deutschland
Stadt: München (MOC)

Messe: IFA Berlin
Datum: 02. - 08. September 2005
Land: Deutschland
Stadt: Berlin

Wenn es so toll sein soll, dann werden wir es frühenstens bei der High End und spätestens auf der IFA mitbekommen.

GloomY

2005-02-08, 14:46:55

CrazyBon,

Coda hat es auf den Punkt gebracht:Verlorene Informationen sind verloren, da kannst du nix rekonstruieren. Du kannst nur schätzen wie es vielleicht mal ausgesehen hat [...]Das ist der Punkt. Das Interpolieren ist ja nur eine "Schätzung" der Zwischenwerte. Dass es da sicher mehr oder weniger gute Approximationsalgorithmen für diese Zwischenwerte gibt (nearest Neigbour, bilinear, bicubisch...) ist eine ganz andere Frage.

Plasmafusion

2005-02-08, 16:14:35

grade eben auf 3sat gesehn:
http://www.3sat.de/3sat.php?http://www.3sat.de/neues/sendungen/spezial/75626/index.html

also die technik hört sich her gut an, auch das es schon nen prototyp gibt.
irgendwie freu ich mich auf die zukunft ;)

Jo, mitlerweile kannst Du jede Datei jeder Größe und Art auf 0 Bytes komprimieren und wieder fehlerfrei entpacken.
Ist nur etwas aufwendig und das Ergebnis einer 1MB Ausgangs-Datei auf 0 Bytes behinaltet zahlose Zwischendateien, kann locker 1GByte Gesamtdaten zusammenbringen wobei die letzte eben nur 0 Bytes hat nach tausenden Kompressions-Schritten. Ist aber eine sehr interessante Technologie.

ollix

2005-02-08, 17:01:40

Vielleicht sieht das Bild "besser aus", ist aber falscher als das mpeg Bild verfälscht ist. Es ist sicherlich beeindruckend, wenn man keine Pixel sieht und beliebig skalieren kann, allerdings sind die Artefakte dieser Technik dann einfach anderer Natur und fallen wohl spontan nicht so ins Auge, wenn man auf der Suche nach Pixelmoskitos ist. Auf die typischen Artefakte aktueller Makroblock basierter Videokompression reagieren die meisten Menschen relativ empfindlich (wenn sie sie denn sehen) - anders artige Artefakte sind da evtl. "natürlicher".

Habe den Beitrag gesehen und war (und bin) die ganze Zeit über sehr skeptisch - vorallem weil der geniale Erfinder scheinbar auch Zeit auf der Sonnenbank verbringt :); er soll ja vor vielen Jahren irgendein Patent für Digitalverstärker nach Japan verkauft haben. Aber vom Grundsätzlichen her halte ich erstmal alles für möglich und jederzeit bestehendes für "revidabel". Was ich auch von den zahlreichen Aussagen unabhängiger Leute gehört habe, halte ich es aktuell für ein durchaus interessantes Verfahren, was aber natürlich Schwächen hat und auch nicht pauschal alles besser macht, gepart mit einer entwas übertriebenen und sehr undifferenzierten Berichterstattung (TV eben).

Und das "besser machen" schien mir auch für die TV Sendung wichtig zu sein - wobei es neben der wohl besseren Skalierungsmöglichkeit dieser Videos das "besser machen" sich wohl im Rahmen bewegt, was ich auch mit ffdshow und post-processing Filtern erreiche (was bei schlechtem Material tw. sogar eine ganze Menge ist).

Ich mußte bei dem Beitrag aber auch erst an den Aprilscherz der c't denken...

Momo

2005-02-08, 19:06:14

Tigerchen

2005-02-08, 19:39:58

Verlorene Informationen sind verloren, da kannst du nix rekonstruieren. Du kannst nur schätzen wie es vielleicht mal ausgesehen hat, das funktioniert aber durch einen dummen Computer eher schlecht als recht.

Dein Auge "berechnet auch immer nur einen winzigen Bildausschnitt. Trotzdem ist das Gesamtergebnis doch recht überzeugend. Um das hinzukriegen brauchst natürlich ein neuronales Netz, auch Gehirn genannt. Und genau so ein neuronales Netz nutzt auch der Erfinder.
Meinst du ein ganzer Pulk von Texas-Instruments Leuten fliegt wegen jedem Mumpitz nach Essen?

Coda

2005-02-08, 19:41:43

So ein neuronales Netz müsste aber recht groß sein und würde beachtliche Rechenleistung bei der Simulation verbrauchen. Ohne diskreten Chip geht da gar nix.

Außerdem würde ich bei künstlichen neuronalen Netzen noch lange nicht von echter Intelligenz reden.

Dein Auge "berechnet auch immer nur einen winzigen Bildausschnitt. Trotzdem ist das Gesamtergebnis doch recht überzeugend.Den Zusammenhang must du mir jetzt erklären.

Plasmafusion

2005-02-08, 20:12:24

das halt ich ja jetz für eher unmöglich...

Wenn Dich das Thema ernsthaft interessiert, dann beschäftige dich mal mit dem BARF compressor. Erstmal selber Infos sammeln bevor man etwas als möglicherweise unmöglich abschreibt :|

Coda

2005-02-08, 20:24:51

BARF speichert die "komprimierten" Daten im Dateinamen, das ist ein Witz ;)

Erstmal selber Infos sammeln...Oh ja, das trift auch auf dich zu...

Plasmafusion

2005-02-08, 21:10:57

Sehe keinen Grund meine Aussagen inhaltlich zu revidieren. :P

Momo

2005-02-08, 21:23:10

wenn mir jemand erzählt er kann mehrere megabyte auf 0 byte komprimieren, muss ich mich nich erst informieren, um sagen zu können das das schwachsinn is ;)

littlejam

2005-02-08, 22:26:19

Verlorene Informationen sind verloren, da kannst du nix rekonstruieren. Du kannst nur schätzen wie es vielleicht mal ausgesehen hat, das funktioniert aber durch einen dummen Computer eher schlecht als recht.

Das mag so für Einzelbilder stimmen. Allerdings kann man aus einer Bildsequenz ein Bild formen, was mehr Details aufweist, als ein Einzelbild.

Davon abgesehen, halte ich dieses neue Verfahren für Blödsinn. Ein Video in Vektoren zu zerlegen ist "tollkühn".

Gruß

Coda

2005-02-08, 22:49:53

Das mag so für Einzelbilder stimmen. Allerdings kann man aus einer Bildsequenz ein Bild formen, was mehr Details aufweist, als ein Einzelbild.Ähm, dann hat man ja wieder mehr Informationen zur Verfügung :rolleyes:

Plasmafusion

2005-02-08, 23:53:58

wenn mir jemand erzählt er kann mehrere megabyte auf 0 byte komprimieren, muss ich mich nich erst informieren, um sagen zu können das das schwachsinn is ;)

Dann tust Du mir mit deiner Ignoranz echt leid.

Senior Sanchez

2005-02-09, 00:08:05

Dann tust Du mir mit deiner Ignoranz echt leid.

Er hat aber recht. Denn der Dateiname ist auch Information und demzufolge mehr als 0 Byte, auch wenn das dein Windows so anzeigen möge, es braucht trotzdem Speicherplatz auf der Festplatte.

Ist aber ne witzige Idee ;)

mfg Senior Sanchez

Coda

2005-02-09, 00:45:39

Dann tust Du mir mit deiner Ignoranz echt leid.Aaaaauuuuuaaaaaaaaaaaaaaaaaaaaa :biggrin:

aths

2005-02-09, 01:55:18

Jo, mitlerweile kannst Du jede Datei jeder Größe und Art auf 0 Bytes komprimieren und wieder fehlerfrei entpacken.
Ist nur etwas aufwendig und das Ergebnis einer 1MB Ausgangs-Datei auf 0 Bytes behinaltet zahlose Zwischendateien, kann locker 1GByte Gesamtdaten zusammenbringen wobei die letzte eben nur 0 Bytes hat nach tausenden Kompressions-Schritten. Ist aber eine sehr interessante Technologie.Das geht prinzipiell nicht. Stichwort Entropie. Da gibts feine Dinge wie BWT oder arithmetische Komprimierung, die besser sind als der pure Huffmann, was man auch kombiniert mit Wörterbuch-basierter Komprimierung á la LZW einsetzen kann. Aber eine 1 MB große Datei mit beliebigem Inhalt kriegt man nicht so klein. Enhält die Datei nur weißes Rauschen, kann man sie gar nicht komprimieren.

Ist ja auch einsichtig: Mit einem Byte kann man exakt 256 unterschiedliche Zustände kodieren. Man kann also nach dem Komprimieren auf 1 Byte bei einer Dateigröße von 1 MB nur 256 unterschiedliche Möglichkeiten abspeichern, wie die 1-MB-Datei aufgebaut ist. Mit einem MB sind aber 2^8000000 unterschiedliche Zustände darstellbar. Eine Komprimierung, davon nur 2^8 Möglichkeiten speichern kann, und bei den restlichen Varianten versagt, taugt nicht viel.

Komprimierung funktioniert nur, wenn es innerhalb der Information sich wiederholende Muster gibt. Je besser der Komprimierungsalgo, desto raffinierter findet er auch versteckte Wiederholungsfolgen. Aber es gibt auch Bitmuster, die keine verwertbaren Wiederholungen beinhalten.

aths

2005-02-09, 02:08:54

CrazyBon,

Coda hat es auf den Punkt gebracht:Das ist der Punkt. Das Interpolieren ist ja nur eine "Schätzung" der Zwischenwerte. Dass es da sicher mehr oder weniger gute Approximationsalgorithmen für diese Zwischenwerte gibt (nearest Neigbour, bilinear, bicubisch...) ist eine ganz andere Frage.Ja, man kann eine Menge tun, um aus wenig Daten "angenehme" Bilder zu erzeugen. So kann man schwachkontrastige Abstufungen glattziehen, und scharfkonstrastige wieder zu richtigen scharfen Kanten machen. Treibt man es weiter, könnte man z. B. Gesichtserkennende Verfahren einbauen, und nach gewissen Regeln speziell in Gesichter Details rekonstruieren, die im Datenmaterial nur angedeutet sind. Das fertige Bild mag als besser empfunden werden, ist darum aber nicht zwangsläufig näher am Original. Gegen schlechte Bildqualität hilft mehr Datenrate. Die Zeit in der ein 19200-er Modem noch Ultrahighspeed war, sind lange vorbei.

Ich zweifle z. B., dass bikubische Filter per se besser sind, als bilineare. Hat eher "philosophische" Gründe, imo wird damit das vorhandene Datenmaterial überinterpretiert.

Vektorisierung von TV-Bildern ist imo keine schlechte Idee. Irgendwann muss auch dieser Ansatz mal gründlich untersucht werden. Zwar glaube ich, dass Wavelet-basierte MPEG-ähnliche Verfahren mehr Qualität pro Datenrate liefern, aber das ist nur so eine Vermutung.

anorakker

2005-02-09, 11:45:04

man muss wohl unterscheiden, inwiefern hier reine "daten" komprimiert werden, d.h. ein decoder rekonstruiert die ursprünglichen daten rein aus den komprimierten, oder aber der decoder besitzt selber schon jede menge informationen bzw. muster, um die daten mit hilfe weniger "bytes" vollständig wiederherzustellen. als beispiel seien da mal die spieledemorecordings ala hl genannt : aus wenigen kb werden da auf dem rechner komplette minutenlange "videos" draus. das ist natürlich nur möglich, weil dem rechner sehr wenige daten ausreichen (z.b. mausbewegungen) um daraus ein komplexes (ich nenne das jetzt mal) video zu machen...vektorprogramme ala coreldraw arbeiten ähnlich..

der aprilscherz der c´t hat diesen ansatz natürlich(nicht realisierbar) auf die spitze getrieben :)

Gast

2005-09-08, 17:20:03

Ich habe diesen ganzen Ansatz mit meinen eigenen Augen gesehen und er stellt alles in den schatten was bis jetzt verfuegbar ist. Komprimierung auf o byte hin oder her- den konsumenten interessiert letztendlich nur das Bild was das Auge sieht . Und dies ist wirklich sehr beeindruckend

aths

2005-09-08, 19:02:38

Gast

2005-09-08, 21:06:05

Gibt es irgendwo einen aktuellen Artikel von dieser IFA darüber?

Gast

2005-09-08, 21:37:34

Auf der Suche habe ich hier genauere Infos gefunden:
http://www.avguide.ch/index.cfm/show/page.view/uuid/2267DC3E-0907-ECD5-C966E54C7C2F1C52

Basis:
Intel Pentium 4 / 2.66 GHz
400 GB Festplatte
2 x DVB-S HDTV (opt. DVB-T/DVB-C)
TV-Genie / tvtv
6 x USB 2.0
3 x Firewire
1x VGA und 1x DVI-I (Dual), Composite (max. 2048x1536 Pixel -200 Hz)
1 x Ethernet 100

Es wird ein neuronales Netz benutzt, um zu komprimieren.
Was ich in dem Bericht vermisse, ist die Videogröße. Da wird kaum was erwähnt.
Vor allem, wenn von DVB-S aufgenommen wird. Da kann man den Live-Stream und dem "Wunder"-Codec vergleichen. :|
Was erwähnt wird:
Dank dem hohen Komprimierungsfaktor kann über eine ISDN-Leitung ruckelfrei und in nahezu PAL-Bildqualität eine Videokonferenz geführt werden.

Das habe ich auch gefunden:
Beschuldigung von einem Vermittler zwischen Atvisican und Vestel:
http://forum.golem.de/read.php?1884,362035,412380#msg-412380
Antwort von einem Mitarbeiter von Atvisican:
http://forum.golem.de/read.php?1884,362035,425797#msg-425797

Von dort:
Es riecht übel:
http://www.tagesanzeiger.ch/dyn/digital/hintergrund/489361.html
Gravierende Vorwürfe
«In meiner ganzen Zeit bei Atvisican sah ich den neuartigen Codec kein einziges Mal» erzählt ein ehemaliger Mitarbeiter. Bis 2004 war er dabei. Er beschuldigt das Unternehmen: «Keiner der Allcanviews, die zu meiner Zeit verkauft wurden, war fürs Internet mit einer Firewall geschützt oder hatte einen Virenscanner». Prochnow verwahrt sich gegen diese Anwürfe: «Das entspricht absolut nicht den Tatsachen. Wir hatten ZoneAlarm installiert und als Virenscanner AntiVir.» Das sind Gratisprogramme.
Mitte 2004 verliessen alle Techniker gleichzeitig das Unternehmen Atvisican. Mit ihnen ging nahezu die ganze Belegschaft. Übrig blieben Putzkraft und Telefonempfang.

Aus der Traum?
http://www.tagesanzeiger.ch/dyn/digital/hintergrund/503581.html

Aktueller Bericht Juli/August 2005:
http://www.wirtschaftsmagazin-ruhr.de/Bilder/magazin/0503/wmr0305.pdf
Seite 54+55:
Was mir neu ist:
Es gibt einen 64-bit Chip. Was könnte dieser sein?

aths

2005-09-08, 23:54:18

Es wird ein neuronales Netz benutzt, um zu komprimieren.Sagt wer? Was sagt das "neuronale Netz" aus?

Was ich in dem Bericht vermisse, ist die Videogröße. Da wird kaum was erwähnt.Ich weiß nicht, was er da gemacht haben will, aber 20x besser als MPEG ist nicht drin. Auch wenn MPEG noch nicht das Ende der Fahnenstange ist – an MPEG arbeiteten (und arbeiten) viele sehr kluge Leute. Dass jemand praktisch im Alleingang einen supertollen Codec zusammenbastelt, halte ich für unglaubwürdig.

Gast

2005-09-09, 00:02:29

Sagt wer? Was sagt das "neuronale Netz" aus?

Ich weiß nicht, was er da gemacht haben will, aber 20x besser als MPEG ist nicht drin. Auch wenn MPEG noch nicht das Ende der Fahnenstange ist – an MPEG arbeiteten (und arbeiten) viele sehr kluge Leute. Dass jemand praktisch im Alleingang einen supertollen Codec zusammenbastelt, halte ich für unglaubwürdig.
z.B. hier: http://www.forum-3dcenter.de/vbulletin/showpost.php?p=2718932&postcount=34
Originalquelle: http://www.3sat.de/3sat.php?http://www.3sat.de/neues/sendungen/spezial/75635/index.html

Besser als MPEG 1 sind heute viele Codecs.

aths

2005-09-09, 01:45:12

z.B. hier: http://www.forum-3dcenter.de/vbulletin/showpost.php?p=2718932&postcount=34
Originalquelle: http://www.3sat.de/3sat.php?http://www.3sat.de/neues/sendungen/spezial/75635/index.html

Besser als MPEG 1 sind heute viele Codecs.Wie viel mal kleiner schaffen sie es denn?

Coda

2005-09-09, 01:55:08

Also die Idee mit den neuronalen Netzen ist schon interessant, aber 20x kleiner ist auf jedenfall übertrieben oder nur in Spezialfällen möglich.

HajottV

2005-09-09, 09:35:52

Ich weiß nicht, was er da gemacht haben will, aber 20x besser als MPEG ist nicht drin. Auch wenn MPEG noch nicht das Ende der Fahnenstange ist – an MPEG arbeiteten (und arbeiten) viele sehr kluge Leute. Dass jemand praktisch im Alleingang einen supertollen Codec zusammenbastelt, halte ich für unglaubwürdig.

Hi,

MPEG = MPEG-1 nehme ich mal an.

MPEG-1 ist ein ziemlich simples Dekompressionsverfahren (*) für Videos. MPEG-2 ist nur im Detail verbessert und auch nicht sonderlich gut. Es ist keine große Kunst bei gleicher Qualität, besser als MPEG-1/2 zu sein, auch nicht um den Faktor 3-4. Faktor 2 schafft jeder, der sich auch nur einigermaßen eingehend mit Videokompression beschäftigt.

Schon bei den Vorschlägen zu MPEG-1 gab es deutlich bessere Verfahren, was die Kompressionsrate angeht... allerdings sollte das Verfahren einfach in Hardware zu implementieren sein und muß viele Kompromisse erfüllen. Daher hatte man sich für dieses Verfahren entschieden.

In der Forschung macht man inzwischen extrem abgefahrene Sachen, die auch deutlich über das hinausgehen, was MPEG-4 oder H.264 (**) machen. Da werden Szenen wirklich als 3d-Objekte + Texturen beschrieben... der Rechenaufwand ist allerdings gigantisch.

Aber selbst diese Verfahren erreichen keinen Faktor 20 (bei gleicher Qualität). Ich denke auch, daß das unglaubwürdig ist.

Gruß

Jörg

(*) MPEG 1/2 beschreibt lediglich, wie ein MPEG-Strom dekomprimiert wird, es schreibt nicht vor, wie die Ausgangsdaten in das Format kommen.
(**) Wer sich den Standard mal durchliest, wird ziemlich enttäuscht sein... noch immer eine Form der DCT, noch immer Blöcke... nicht viel neues im Westen. (= Kompromisse, Kompromisse, Kompromisse)

Gast

2005-09-09, 11:07:21

Hi,

MPEG = MPEG-1 nehme ich mal an.

MPEG-1 ist ein ziemlich simples Dekompressionsverfahren (*) für Videos. MPEG-2 ist nur im Detail verbessert und auch nicht sonderlich gut. Es ist keine große Kunst bei gleicher Qualität, besser als MPEG-1/2 zu sein, auch nicht um den Faktor 3-4. Faktor 2 schafft jeder, der sich auch nur einigermaßen eingehend mit Videokompression beschäftigt.
Nicht ganz: http://www.cybersite.de/german/service/Tutorial/mpeg/
Schon bei den Vorschlägen zu MPEG-1 gab es deutlich bessere Verfahren, was die Kompressionsrate angeht... allerdings sollte das Verfahren einfach in Hardware zu implementieren sein und muß viele Kompromisse erfüllen. Daher hatte man sich für dieses Verfahren entschieden.
Die waren eher propriotär. Man wollte mit MPEG-1 eine gemeinsame Basis schaffen. Da es damals zu neu war, war es nicht besser umgesetzt.
Heute kann man mit MPEG-1 und variabler Bitrate und weiteren Schnickschnak des Encoders sehr gut encodieren.
In der Forschung macht man inzwischen extrem abgefahrene Sachen, die auch deutlich über das hinausgehen, was MPEG-4 oder H.264 (**) machen. Da werden Szenen wirklich als 3d-Objekte + Texturen beschrieben... der Rechenaufwand ist allerdings gigantisch.
In der Forschung macht man fast immer abgefahrene Sachen, deswegen heißt es ja auch Forschung.
Aber hast recht, so groß sind die Unterschiede zwischen Mpeg-1 und H-264 eigentlich nicht, nur die Algorithmen sind komplexer.
Aber selbst diese Verfahren erreichen keinen Faktor 20 (bei gleicher Qualität). Ich denke auch, daß das unglaubwürdig ist.
Man kann solche Sachen immer zurechtrücken.
Man nehme einen DVD-Stream, komprimiere es mit MPEG1 und konstanter(!) Bitrate von 10 MBit/s und das gleiche Video mit xvid und 1 Mbit/s. Nun hat man eine deutliche Verbesserung der Komprimierung. ;)

Gruß

Jörg

(*) MPEG 1/2 beschreibt lediglich, wie ein MPEG-Strom dekomprimiert wird, es schreibt nicht vor, wie die Ausgangsdaten in das Format kommen.
(**) Wer sich den Standard mal durchliest, wird ziemlich enttäuscht sein... noch immer eine Form der DCT, noch immer Blöcke... nicht viel neues im Westen. (= Kompromisse, Kompromisse, Kompromisse)
Sondern nur den Aufbau. Wie es dazu kommt ist egal. Um es dekodieren zu können muss man wissen, wie es encodiert wurde. Dieser Vorgang ist nicht fest vorgeschrieben.
Die Kompromisse ergeben sich von der Umsetzung in die billige Hardware (DivX - DVD-Player usw.)
Grüße
gast

Coda

2005-09-09, 11:16:27

In der Forschung macht man inzwischen extrem abgefahrene Sachen, die auch deutlich über das hinausgehen, was MPEG-4 oder H.264 (**) machen. Da werden Szenen wirklich als 3d-Objekte + Texturen beschrieben... der Rechenaufwand ist allerdings gigantisch.Uhm nein. MPEG 4 ist immer ein reines 2D-Verfahren. 3D Objekte aus Filmen rauszufiltern ist praktisch unmöglich.

Gast

2005-09-09, 11:43:34

Uhm nein. MPEG 4 ist immer ein reines 2D-Verfahren. 3D Objekte aus Filmen rauszufiltern ist praktisch unmöglich.
Das bezogt sich eher auf h.264. 3D ist es auch nicht ganz, aber man versucht Objekte zu erkennen.

HajottV

2005-09-09, 12:51:57

Nicht ganz: http://www.cybersite.de/german/service/Tutorial/mpeg/

Die waren eher propriotär. Man wollte mit MPEG-1 eine gemeinsame Basis schaffen. Da es damals zu neu war, war es nicht besser umgesetzt.
Heute kann man mit MPEG-1 und variabler Bitrate und weiteren Schnickschnak des Encoders sehr gut encodieren.

[QUOTE=Gast]Nicht ganz: http://www.cybersite.de/german/service/Tutorial/mpeg/

Öhh, das ist ein langer Text... was genau da drin widerspricht dem, was ich gesagt habe?

Heute kann man mit MPEG-1 und variabler Bitrate und weiteren Schnickschnak des Encoders sehr gut encodieren.

Nuja... wenn Du mit MPEG-1 die Qualität von Xvid & Co.erzielen möchtest, brauchst Du aber mehr als nur die doppelte Bitrate. Bei durchschnittlich 2 Mbit kann man mit DivX/XVid schon ganz passabel höhere Auflösungen kodieren, das geht mit MPEG-1 nicht.

Man kann solche Sachen immer zurechtrücken.

Man nehme einen DVD-Stream, komprimiere es mit MPEG1 und konstanter(!) Bitrate von 10 MBit/s und das gleiche Video mit xvid und 1 Mbit/s. Nun hat man eine deutliche Verbesserung der Komprimierung. ;)

Aber nicht bei gleicher Qualität. Zahlen schönen kann man allerdings immer, klar.

Uhm nein. MPEG 4 ist immer ein reines 2D-Verfahren. 3D Objekte aus Filmen rauszufiltern ist praktisch unmöglich.

Oh, hatte ich mißverständlich formuliert. Das "da" bezog sich auf die Forschung, nicht auf MPEG-4.

Gruß

Jörg

Shink

2005-09-09, 13:37:01

Uhm nein. MPEG 4 ist immer ein reines 2D-Verfahren.
Uhm nein, eigentlich nicht: MPEG 4 ist nur ein Containerformat beinhaltet z.B. auch VRML und ähnliches. Theoretisch könnte man ja aus einem Video eine VRML-Szene machen. Das wär zwar dann nicht mehr MPEG 4 Video (und vermutlich auch nicht sinnvoll) aber MPEG 4 wär es immer.
Zu h.264: Wenn ich mich recht erinnere, war das sogar einer der schlechtesten (ineffizientesten) Vorschläge für den neuen MPEG 4 Video-Codec. Aber eben auch der einzige, der noch blockbasiert arbeitet. Wavelet-Verfahren sind im Allgemeinen effizienter und schneller.

Gast

2005-09-09, 14:18:25

Öhh, das ist ein langer Text... was genau da drin widerspricht dem, was ich gesagt habe?
Deine Aussage bezog sich nur auf das Dekodieren. Um Dekodieren zu können muss man wissen, wie encodiert worden war. Da ist bei MPEG nicht festgelegt.
Nuja... wenn Du mit MPEG-1 die Qualität von Xvid & Co.erzielen möchtest, brauchst Du aber mehr als nur die doppelte Bitrate. Bei durchschnittlich 2 Mbit kann man mit DivX/XVid schon ganz passabel höhere Auflösungen kodieren, das geht mit MPEG-1 nicht.
Mit einem anständigen Encoder, passender Q-Matrix und 2-fachem Durchlauf kann man mit durchschittlichen 1,5-2 MBit und Mpeg1/2 auch in guter Qualität in DVD-Auflösung encodieren. Schaue mal auf entsprechende Seiten nach, z.B. doom9.
Aber nicht bei gleicher Qualität. Zahlen schönen kann man allerdings immer, klar.
Dies bezog sich auf gleiche Qualität.
An MPEG-1 kann man viel variieren. Ich experimentiere in letzter Zeit (~2 Jahre) an Mpeg1/2 herum. Man kann damit mehr machen, als man auf dem ersten Blick meint.
Oh, hatte ich mißverständlich formuliert. Das "da" bezog sich auf die Forschung, nicht auf MPEG-4.

Gruß

Jörg
Mir war es klar. Nur weiss ich nicht, wie weit die sind, da alles noch "geheim" ist.
Uhm nein, eigentlich nicht: MPEG 4 ist nur ein Containerformat beinhaltet z.B. auch VRML und ähnliches. Theoretisch könnte man ja aus einem Video eine VRML-Szene machen. Das wär zwar dann nicht mehr MPEG 4 Video (und vermutlich auch nicht sinnvoll) aber MPEG 4 wär es immer.
Zu h.264: Wenn ich mich recht erinnere, war das sogar einer der schlechtesten (ineffizientesten) Vorschläge für den neuen MPEG 4 Video-Codec. Aber eben auch der einzige, der noch blockbasiert arbeitet. Wavelet-Verfahren sind im Allgemeinen effizienter und schneller.
MP4 ist das offizielles Container-format nicht MPEG-4. Das blöde bei den neuen nicht-blockorientierten Verfahren: die brauchen viel Leistung. Am besten 4 bis 8-fach DC-Prozessoren.

Gast

2005-09-09, 17:03:07

Gast

2005-09-09, 17:27:41

Sucht mal im Inet nach dem Typen. Das ganze ist eine große Verarschung um Risiko Kapital zu bekommen. Hier mal ein Artikel den ich gefunden habe

http://www.tagesanzeiger.ch/dyn/digital/hintergrund/503581.html

Ich denke man brauch sich darüber keine Gedanken mehr machen.
Diese Meldung vom 30.05.2005 ist bekannt, siehe hier:
http://www.forum-3dcenter.de/vbulletin/showpost.php?p=3464260&postcount=57

Gast

2005-09-09, 17:55:25

Wieder was neues Altes:
http://digitalsushi.kaywa.ch/gadget/post-2.html
Von dort Artikel von Home Electronic 05/2005:
http://www.allcanview.de/de/downloadsFree/HOMEelectronic_0505.zip

Gast

2005-09-09, 23:20:09

Ich habe mir die Sache mit dem Allcanview angeschaut und über die vorhandenen Informationen nachgedacht. Kann es sein, dass der Codec die Objekte nicht anhand der Form erkennt sondern die Frames im voraus anschaut und dann die Objekte im "Vordergrund" bestimmt?
Z.B. fällt mir das anhand dieser beiden Bilder, die ständig wiederholt werden, auf:
http://www.avguide.ch/bilder/testbericht/vektorkomprimierung_250.jpg
http://www.avguide.ch/bilder/testbericht/pioritaeten_250.jpg
So deute ich das spärliche Bildmaterial vom Wundercodec.

Shink

2005-09-10, 07:46:42

Muh-sagt-die-Kuh

2005-09-10, 11:21:59

Zu h.264: Wenn ich mich recht erinnere, war das sogar einer der schlechtesten (ineffizientesten) Vorschläge für den neuen MPEG 4 Video-Codec. Aber eben auch der einzige, der noch blockbasiert arbeitet. Wavelet-Verfahren sind im Allgemeinen effizienter und schneller.H.264 ist eine evolutionäre Lösung, das ist korrekt....aber prinzipiell keine schlechte: Der Rechenaufwand hält sich in Grenzen, die Effizienz wurde gesteigert. Klar, Subpartitionierung von Makroblöcken, mehrere Referenzframes für P- und B-Frames, Intra-Frame Prediction, In-Loop Deblocking oder auch CAVLC sind nicht wirklich revolutionär, tun aber ihren Job.

In einer der letzten c'ts wurde drei freie Videocodecs vorgestellt, von denen zwei Wavelet-Transformationen zur Codierung von I-Frames verwenden....aber auch hier wird für P- und B-Frames immer noch blockbasierte Motion-Compensation verwendet. Ein Codec, der 3D-Wavelets zur Inter-Prediction verwedet, ist mir zumindest nicht bekannt. Zudem sind auch Wavelets kein Allheilmittel....sie neigen oft dazu, Bildmaterial weichzuzeichnen.

aths

2005-09-10, 15:24:03

Zudem sind auch Wavelets kein Allheilmittel....sie neigen oft dazu, Bildmaterial weichzuzeichnen.Das hängt davon ab, welche Anteile man weglässt. Bei sehr hohen Komprimierungsraten liefert JPEG2000 natürlich bessere Ergebnisse als JPEG, aber irgendwoher muss die geringere Datenrate dann ja auch kommen.

Wenigstens ist in diesem Thread nicht wieder von "fraktaler" Komprimierung die Rede :)

Gast

2005-09-10, 17:07:16

Wenigstens ist in diesem Thread nicht wieder von "fraktaler" Komprimierung die Rede :)
Da du es jetzt mal ansprichst. :D
Fangen wir mal an: bla blabla ...

Quatsch. ;)
h.264 ist von der heutigen Performance und Machbarbeit gut umzusetzen. Andere Codecs, die deutlich besser sind brauchen auch mehr Leistung. In paar Jahren, wenn Multicore-CPUs Standard werden, haben sie eine reelle Chance.

S3NS3

2005-09-11, 10:53:26

Shink

2005-09-12, 14:21:03

:ugly:
Er meinte vermutlich sowas wie LenPEG:
http://www.dangermouse.net/esoteric/lenpeg.html

Zum Weichzeichnen bei Wavelets: Naja, irgendwie muss sich das Wegwerfen von Informationen ja auswirken. Weichzeichnen ist immer noch besser als Blockbildung.

3D-Wavelets bringens soviel ich weiß nicht so wirklich: Erstens ist die Idee viel zu einfach, um effizient zu sein ;) und zweitens führt das zu Timing-Artefakten.

S3NS3

2005-09-13, 09:13:26

Egal was, egal wie, egal wie vereinfacht: Zeig mir was das ein auch nur paar Bit´s an Infos in 0 (NULL) Bytes packt und wieder entpackt :)

Null ist null, nichts :)

Irgendwo ist eine Grenze. Und null überschreitet diese ums unendliche :)

Deshalb kam der :ugly: daher ;)

Wolfram

2005-09-13, 10:08:46

S3NS3

2005-09-13, 12:15:23

ShadowXX

2005-09-13, 13:10:20

Und es gibt halt auch viele die echt ABSOLUT keine Ahnung haben.
Mein Kollege hier auch. Wegen DVD und Mpeg4, komprimierung allgemein, mal gelabert.

Der SIEHT ES NICHT EIN warum man eine Komprimierung brauch. Sieht es nicht ein warum die Mpegs Verlustbehaftet sind und kann es nicht verstehen warum aus 320x200 Mpeg1 konvertiert in 1920x1080 h264 KEIN besseres Bild rauskommt. Er ist der meinung das MUSS dann möglich sein das es wieder Glasklar ist. Mit Filter usw.
Und wenn noch so Argumentierst das halt ein Gesicht im Hintergrund ja GARNICHT da war, die Information ja nie im 320ér drinne war ausser nen 3-4Pixelklumpen, ne, auf hoher Res muss das aber sichtbar sein...

Boh, bekomm ich Kopfschmerzen von ;)

Das kommt durch Hollywood & Co., wo ein ziemlich grobkörniges und schlechtes S/W-Pic ausreicht um mit Hilfe des Computers und irgendwelcher Wundersoftware ein 3x3 Pixel großen Ausschnitt, von dem man mit viel phantasie erahnen kann das das eine Zeitung sein soll, glasklar Lesebar macht (und zwar jeden Artikel incl. Photos und am besten noch die Fingerabdrücke desjenigen, der die Zeitung hält).

Das bekommst du nicht aus den Köpfen von Leuten raus, die sich mit der Materie nicht auskennen.

Gast

2005-09-13, 14:42:52

Wolfram

2005-09-13, 15:04:54

Die Zeiten des Tüftlers sind noch nicht vorbei. Es gibt ja noch autodidaktische Erfinder, die noch Leistungen vollbringen können. Nur ist das Hobby teurer geworden.

Der Autor mag es nicht ganz verstanden haben, aber die Wahrheit über den Codec ist versteckt.
Wenn schon der Journalist, dessen Aufgabe es in diesem Fall ist, das Fachwissen allgemeinverständlich zu vermitteln, die Sache nicht verstanden hat, wie soll ich als Leser sie dann verstehen oder gar ihren Wahrheitsgehalt beurteilen können?

Wie gesagt: Ich kann das inhaltlich gar nicht beurteilen. Aber bei Geschichten über wundersame Erfindungen wäre ich lieber ein bißchen skeptisch.

Und wenn ich dann noch lese, daß der Erfinder früher mal in einem Strukturvertrieb (für Nahrungsergänzungsmittel?!?) gearbeitet habe soll... nicht gerade etwas, was ich mit Computerfricklern oder seriösen Geschäftspraktiken in Verbindung bringen würde.

Gast

2005-09-13, 16:00:38

Wenn schon der Journalist, dessen Aufgabe es in diesem Fall ist, das Fachwissen allgemeinverständlich zu vermitteln, die Sache nicht verstanden hat, wie soll ich als Leser sie dann verstehen oder gar ihren Wahrheitsgehalt beurteilen können?

Wie gesagt: Ich kann das inhaltlich gar nicht beurteilen. Aber bei Geschichten über wundersame Erfindungen wäre ich lieber ein bißchen skeptisch.

Und wenn ich dann noch lese, daß der Erfinder früher mal in einem Strukturvertrieb (für Nahrungsergänzungsmittel?!?) gearbeitet habe soll... nicht gerade etwas, was ich mit Computerfricklern oder seriösen Geschäftspraktiken in Verbindung bringen würde.
Einstein hat wo gearbeitet und was erarbeitet? Dann hat er als Frickler sehr weit gebracht, :D

Gast

2005-09-13, 16:08:12

Und es gibt halt auch viele die echt ABSOLUT keine Ahnung haben.
Mein Kollege hier auch. Wegen DVD und Mpeg4, komprimierung allgemein, mal gelabert.

Der SIEHT ES NICHT EIN warum man eine Komprimierung brauch. Sieht es nicht ein warum die Mpegs Verlustbehaftet sind und kann es nicht verstehen warum aus 320x200 Mpeg1 konvertiert in 1920x1080 h264 KEIN besseres Bild rauskommt. Er ist der meinung das MUSS dann möglich sein das es wieder Glasklar ist. Mit Filter usw.
Und wenn noch so Argumentierst das halt ein Gesicht im Hintergrund ja GARNICHT da war, die Information ja nie im 320ér drinne war ausser nen 3-4Pixelklumpen, ne, auf hoher Res muss das aber sichtbar sein...

Boh, bekomm ich Kopfschmerzen von ;)
Was habt ihr geredet? Es scheint mir, ihr habt vorbeigeredet.
Ein Originalvideo, das in HDTV vorliegt ist, hat ein besseres Bild als VCD. Aber ein VCD in HDTV konvertieren? Gelöschte Informationen kann man nicht wiederherstellen, auch nicht mit Wunder-Filtern/-Algorithmen.
Das Komprimieren von Videos und Bildern basiert da drauf, dass Informationen verloren gehen. Je unwichtiger die sind, umso besser.

aths

2005-09-13, 16:46:39

Das ist der Punkt. Ich hab ja von der Technik keine Ahnung, aber die Zeiten des Tüftlers, der im stillen Kämmerlein das perpetuum mobile ausbrütet, sind doch wohl vorbei (wenn sie denn jemals da waren :D).

Es gibt den Effekt, daß, je unglaubwürdiger eine Meldung ist, um so mehr Leute darauf hereinfallen. Weil alle glauben, daß man mit so einer dreisten Lüge doch wohl nicht aufwarten kann.

Und wenn Ihr das Skript zu dem Fernsehbeitrag lest: Klingt das so, als hätte der Autor die Sache wirklich verstanden?Daran dachte ich auch. Die Schreiberlinge reden alle von der Eloquenz des Uwe Prochnow, aber machen nicht den Eindruck als würden sie die technischen Details verstehen. Zufällig interessiere ich mich seit meiner Kindheit für Videokomprimierung und habe viel, viel, viel darüber nachgedacht. Ohne mir dabei professionelles Wissen anzueignen, da bin ich Amateur. Dennoch wage ich zu behaupten, dass ein Video-Codec, der normale Filme komprimieren soll, bei vergleichbarer Qualität nicht 20x besser als MPEG sein kann. Selbst wenn man mit MPEG-1 vergleicht.

Man kann mit gesteigerter Rechenleistung sicher noch was machen. Das Problem ist allerdings die Streamfähigkeit: Es kommt darauf an, auf eine bestimmte Bitrate zu optimieren, die nicht allzu sehr schwanken sollte. Das heißt, für hochwertige Qualität muss die Bitrate auf schwierige Passagen ausgelegt sein (das ist bei der DVD ja nicht unbedingt der Fall.) Gerade in solchen Passagen kann man aber nicht besonders stark komprimieren. Geht einfach nicht (Stichwort Informationsgehalt, Entropie.) Da kann man lediglich mit wahrnehmungspsychologischen Ansätzen "nebensächliches" weglassen. Solche Modelle entwickelt keine Einzelperson, wenn sie gut sein sollen, dafür sind umfangreiche Testreihen erforderlich.

Coda

2005-09-13, 16:57:10

Außerdem stößt man bei Kompressionen immer an eine Grenze ab der sich der Aufwand fast nicht mehr lohnt um höhere Kompressionsraten zu bekommen.

Man muss sich nur mal anschauen wie wenig sich bei den generischen Kompressionsverfahren wie ZIP, RAR und Co. in den letzen Jahren getan hat. Irgendwann hat das zu komprimierende Material nunmal zu viel Entropie...

aths

2005-09-13, 18:19:03

Bei der verlustfreien Komprimierung ist für meine Begriffe erstaunliches drin gewesen. LHA, lange mein Standard-Tool, wurde von RAR spielend übertroffen, während bei soliden Archiven neuerdings 7z besonder zupackend scheint. Ich weiß nicht, ob diese Programme bereits arithmetische Komprimierung nutzen. Das Verfahren ist nicht frei, aber besser als Huffman. (Allerdings gibt es auf Huffman basierende Methoden, die ebenfalls besser sind als der pure Huffman.)

Natürlich nimmt der Aufwand gewaltig zu, um nur noch ein kleines Stück näher ans Optimum zu gelangen.

Coda

2005-09-13, 18:25:30

Ja schon, aber es gibt dort keine Quantensprünge mehr. Es sind max. 20% zwischen ZIP und 7z.

aths

2005-09-13, 18:36:18

Coda

2005-09-13, 18:39:06

Der Quantensprung ist der kleinste Sprung, den es in der Physik gibtWeiß ich selber, trotzdem ist das eine Redensart die du wohl verstehst.

zeckensack

2005-09-13, 19:01:13

Ja schon, aber es gibt dort keine Quantensprünge mehr. Es sind max. 20% zwischen ZIP und 7z.Der Autor sieht das anders. Schaust du auf der Hauptseite (http://www.7-zip.org/) ganz unten, findest du das:Archiver Compressed size Ratio
7-Zip (7z format) 5445402 100%
WinRAR 3.10 6004155 110%
WinAce 2.3 6242424 115%
CABARC 1.0 6455327 119%
7-Zip (zip format) 9461621 174%
PKZIP 2.50 9842800 181%Aber dass es nicht mehr viel besser werden wird, denke ich auch.

aths

2005-09-13, 21:10:21

Weiß ich selber, trotzdem ist das eine Redensart die du wohl verstehst.Bevor man bekannte Phrasen nutzt, kann eine Reflektion über ihren Sinn nicht schaden.

Der Autor sieht das anders. Schaust du auf der Hauptseite (http://www.7-zip.org/) ganz unten, findest du das:Archiver Compressed size Ratio
7-Zip (7z format) 5445402 100%
WinRAR 3.10 6004155 110%
WinAce 2.3 6242424 115%
CABARC 1.0 6455327 119%
7-Zip (zip format) 9461621 174%
PKZIP 2.50 9842800 181%Aber dass es nicht mehr viel besser werden wird, denke ich auch.Ein ähnliches Problem hat man bei verlustbehafteter Komprimierung mit fester Bitrate: Je nach Komprimierung hat das Ergebnis mehr oder weniger Qualität. Die DXT1-Komprimierungstools von ATI und Nvidia liefern geringfügig unterschiedliche Ergebnisse, aber in jedem Fall brauchbare – im Gegensatz zu meinem Ansatz. Wobei ich eine bestimmte Idee da noch nicht getestet habe. (Der aber auch nur ein wenig besser wäre als meine erste Idee und bei weitem nicht an die ausgereiften Algorithmen heranreichen würde.)

S3NS3

2005-09-15, 09:18:01

Was habt ihr geredet? Es scheint mir, ihr habt vorbeigeredet.
Ein Originalvideo, das in HDTV vorliegt ist, hat ein besseres Bild als VCD. Aber ein VCD in HDTV konvertieren? Gelöschte Informationen kann man nicht wiederherstellen, auch nicht mit Wunder-Filtern/-Algorithmen.
Das Komprimieren von Videos und Bildern basiert da drauf, dass Informationen verloren gehen. Je unwichtiger die sind, umso besser.

ja, genau, kann er sich nicht Vorstellen.

S3NS3

2005-09-15, 09:20:18

Der Quantensprung ist der kleinste Sprung, den es in der Physik gibt :)

In bestimmten Fällen kann der Truecolor-Algorithmus von RAR für deutliche Unterschiede in der Komprimierungrate sorgen, und deutlich mehr als weitere 20% rausholen. Klar ist, dass die noch so ausgetüftelten Algorithmen alle eine Grenze haben, und wir können wohl davon ausgehen, dass sich im großen und ganzen nicht mehr sehr viel tun wird.

Mit der herkömmlichen Technik vieleicht nicht so. Nur falls mal irgendwann vieleicht einer ne ganz andere Revolutionäre Idee haben sollte... bestimmt mal.
Rechenleistung wird auch immer höher. Wenn CPU´s 100x so schnell wären wäre noch mehr machbar.

Gast

2005-09-15, 13:22:24

Rechenleistung wird auch immer höher. Wenn CPU´s 100x so schnell wären wäre noch mehr machbar.
z,B. fraktale Komprimierung (@aths :D); Scherz beiseite.
Ich könnte mir dann eher Echtzeit Objekt-Erkennung vorstellen.
Das es nicht nur auf Leistung ankommt, sieht man z.B. zu Zeiten des C64s und Amiga. Da wurden mit "einfachen" Tricks Effekte und Dinge gezaubert, die erst PC jahre später mit deutlich mehr Leistung machen konnten.
Muss mal danach suchen, aber bevor es Direct-X gab und GDI zu langsam waren, wurden meist in Assembler DOS und Windows Programme geschrieben, die tolle Effekte machen konnten. Heute braucht man dafür DX7-9.

Shink

2005-09-15, 14:41:57

z,B. fraktale Komprimierung (@aths :D); Scherz beiseite.
Ich könnte mir dann eher Echtzeit Objekt-Erkennung vorstellen.
Das es nicht nur auf Leistung ankommt, sieht man z.B. zu Zeiten des C64s und Amiga. Da wurden mit "einfachen" Tricks Effekte und Dinge gezaubert, die erst PC jahre später mit deutlich mehr Leistung machen konnten.
Muss mal danach suchen, aber bevor es Direct-X gab und GDI zu langsam waren, wurden meist in Assembler DOS und Windows Programme geschrieben, die tolle Effekte machen konnten. Heute braucht man dafür DX7-9.
Seltsame Aussage:
- Was man mit Assembler machen kann, kann man meistens auch mit C
- Hardwarenahe Windows-Libraries gabs schon vor DirectX und somit vor Windows 95 (WinG etc.), mit denen läßt sich ähnliches machen.
- Hat mit Videokompression wohl nicht sehr viel zu tun...

Aber natürlich stimmt es, dass effizientere Algorithmen immer wichtiger sind als schnellere Hardware. Hab mal vor einiger Zeit mit einem freien H264-Codec gespielt, der brauchte zur Komprimierung von 1 Sekunde Filmmatrial 14 Minuten @ 2 GHz.
Und wenn jemand mal selbst MPEG1 nachprogrammieren will: Ist zwar nicht schwer, wenn man nicht standardkonform sein muss, aber das Zeug wird halt ziemlich lahm...

Coda

2005-09-15, 15:09:44

Was man mit Assembler machen kann, kann man meistens auch mit CWas heißt hier "meistens"? Solange man keinen hardwarenahen (und dabei meine ich maschinenspezifische Sachen, nicht DirectX) Code programmiert geht in C alles.

Shink

2005-09-15, 15:14:11

Was heißt hier "meistens"? Solange man keinen hardwarenahen (und dabei meine ich maschinenspezifische Sachen, nicht DirectX) Code programmiert geht in C alles.
Ich denke, du hast dir die Antwort selbst gegeben und weißt, was ich meine, oder?

][immy

2005-09-15, 16:11:23

Ich denke, du hast dir die Antwort selbst gegeben und weißt, was ich meine, oder?

nö nicht wirklich

C-Code ist inzwischen genauso schnell wie assembler-code da die compiler inzwischen auch ziemlich gut geworden sind.

zudem, programmiere mal ein großes projekt in assembler-code, dann in c-code und dann in einer objekt-orientierten sprache.
den assembler-code kannst nur nur auf dieser maschine nutzen und zudem wirst du wohl nie fertig werden
den c-code bekommste wohl auch noch fertig und sollte schnell laufen
den objekt-orientierten code bekommste wahrscheinlich noch schneller hin ist aber langsamer

den code der programmiersprachen kannst du aber auch auf jeden anderem system nutzen (zumindest wenn es einen compiler für das jeweilige system gibt)

@Topic
Ist der Artikel nicht schon einige Jahre alt? ich kann mich noch daran erinnern, aber das ist ne ewigkeit her

Coda

2005-09-15, 16:33:30

den objekt-orientierten code bekommste wahrscheinlich noch schneller hin ist aber langsamerDas ist Unfug, OOP erzeugt nicht zwangsläufig langsameren Code.

Shink

2005-09-15, 17:06:38

[immy']nö nicht wirklich

C-Code ist inzwischen genauso schnell wie assembler-code da die compiler inzwischen auch ziemlich gut geworden sind.

Alle Optimierungsmöglichkeiten kann ein Compiler nicht erkennen. Alle Möglichkeiten, auf Hardware zuzugreifen, kann man mit reinem C nicht nutzen.

[immy']
zudem, programmiere mal ein großes projekt in assembler-code, dann in c-code und dann in einer objekt-orientierten sprache.
den assembler-code kannst nur nur auf dieser maschine nutzen und zudem wirst du wohl nie fertig werden
den c-code bekommste wohl auch noch fertig und sollte schnell laufen
den objekt-orientierten code bekommste wahrscheinlich noch schneller hin ist aber langsamer

Man sollte nicht glauben, wie schnell manche Leute in Assembler programmieren können. Das ist dann eher eine Frage der verwendeten Libraries als der Programmiersprache.

[immy']
den code der programmiersprachen kannst du aber auch auf jeden anderem system nutzen (zumindest wenn es einen compiler für das jeweilige system gibt)

Wenn man HW-nah programmiert vermutlich nicht, ausser man verwendet Libraries, die es für beide Systeme gibt.
Wenn man "will", kann man aber auch trivialen C/C++ - Code generieren, der bestimmt auf keinem anderen System oder auch nur anderen Compiler läuft.

Das ist Unfug, OOP erzeugt nicht zwangsläufig langsameren Code.

Das kommt drauf an... Ein Zugriff auf eine nicht ererbte Methode kostet mich bei Mehrfachvererbung sicher den einen oder anderen Speicherzugriff im Vergleich zu einem Assembler-Jump-Befehl oder einer Inline-Methode.

PS: Ja, ich weiß: Ich bin lästig, das habt ihr alles selbst gewusst. Bin eben noch immer gekränkt wegen euren neuen Forumsregeln...

Coda

2005-09-15, 17:09:16

Das kommt drauf an... Ein Zugriff auf eine nicht ererbte Methode kostet mich bei Mehrfachvererbung sicher den einen oder anderen Speicherzugriff im Vergleich zu einem Assembler-Jump-Befehl oder einer Inline-Methode.Das einzige was langsamer ist, ist ein Aufruf einer virtuellen Memberfunktion. Das ist eine Indirektion mehr.

Ansonsten gibt es keinen Overhead, außer dass der this-pointer übergeben wird.

Neomi

2005-09-15, 22:07:58

Alle Optimierungsmöglichkeiten kann ein Compiler nicht erkennen. Alle Möglichkeiten, auf Hardware zuzugreifen, kann man mit reinem C nicht nutzen.

Die Sache mit der Optimierung ist leicht anders. Inzwischen sind die guten Compiler längst so effektiv, daß sie Optimierungen anwenden, über die sich auch der genialste Programmierer nur noch den Kopf zerbricht.

Sachen wie z.B. Inline-Funktionen mit Rekursion sind nur noch von einem Compiler effektiv zu handhaben.

Wenn man "will", kann man aber auch trivialen C/C++ - Code generieren, der bestimmt auf keinem anderen System oder auch nur anderen Compiler läuft.

Beispiel? Ich behaupte da eher, daß es dann kein C/C++ mehr ist. Wer MS-spezifische Erweiterungen nutzt, kann seinen Code natürlich nicht mehr auf anderen Compilern compilieren, aber der entspricht dann eben auch nicht mehr dem Standard.

Das kommt drauf an... Ein Zugriff auf eine nicht ererbte Methode kostet mich bei Mehrfachvererbung sicher den einen oder anderen Speicherzugriff im Vergleich zu einem Assembler-Jump-Befehl oder einer Inline-Methode.

Auch nur ein Gerücht. Um die gleiche Flexibilität zu erreichen, muß man in nicht objektorientierten Sprachen schon einige Verrenkungen machen, aber mit Funktionspointern geht das natürlich auch alles. Das compilierte Ergebnis ist dann gleich, nur eben mit deutlich mehr Aufwand bei der Programmierung. Setzt man eine Sache in der einen Sprache auf die eine Art um, in der anderen Sprache aber auf eine andere Art, dann gibt es natürlich Unterschiede im resultierenden Code. Das hat aber nichts mit der Sprache zu tun. Beispielsweise ist ein in Visual Basic implementierter HeapSort logischerweise (bei nicht allzu kleinen Arrays) deutlich schneller als ein in C implementierter BubbleSort.

HajottV

2005-09-16, 11:39:59

[immy']
C-Code ist inzwischen genauso schnell wie assembler-code da die compiler inzwischen auch ziemlich gut geworden sind.

Nein... es gibt nix Schnelleres als von jemandem, der sein Handwerk versteht, optimierter Assemblercode.

Gruß

Jörg

aths

2005-09-16, 17:14:27

Nein... es gibt nix Schnelleres als von jemandem, der sein Handwerk versteht, optimierter Assemblercode.Dieser Assemblercode läuft nicht auf allen Maschinen. Portabilität ist aus meiner Sicht viel wichtiger, als irgendwo noch 5% an Geschwindigkeit rauszukitzeln. Größere Projekten sind direkt in ASM nur mit erheblichem Aufwand umsetzbar, mit C oder C++ kann man solche Software deutlich schneller und damit günstiger herstellen. Das bei der Software gesparte Geld könnte man in die Hardware stecken, und ist so dann doch wieder schneller.

Coda

2005-09-16, 17:22:34

Nein... es gibt nix Schnelleres als von jemandem, der sein Handwerk versteht, optimierter Assemblercode.Theoretisch ist das richtig, aber praktisch wird wohl bei einem größeren FPU-Code-Block kein Mensch mehr das Scheduling komplett durchblicken auf modernen Out-Of-Order-CPUs und der Compiler macht dich gnadenlos platt. Selbst schon erlebt...

(del)

2005-09-16, 19:19:22

Theoretisch ist das richtig, aber praktisch wird wohl bei einem größeren FPU-Code-Block kein Mensch mehr das Scheduling komplett durchblicken auf modernen Out-Of-Order-CPUs und der Compiler macht dich gnadenlos platt. Selbst schon erlebt...
Jou, aber irgendwie sind beide Aussagen (HajottV und ][immy) nicht so wirklich das Dogma. Es kommt IN ERSTER Linie immernoch drauf an wie die Leute programmieren und welche Algos und Routinen sie ausklügeln.

Der Source frei, es kann also jemand den ZIP mit GCC4 kompiliert nach ASM zu konvertieren und es allen beweisen, ob wenigstens die 5% drin sind :rolleyes:

Gast

2006-01-03, 10:46:25

Was ist daraus geworden?

http://www.tilo-schuster.de/3D/home3d.htm
Auf der Grundlage einer neuronalen Netztechnologie aus der russischen Militärforschung werden Bildinformation (Personen, Gegenstände, Gebäude, etc.) direkt separiert und vektorisiert. Im Ergebnis konnte ein MPEG2-Spot von 25 MB auf 1.5 MB reduziert werden, wobei sich sogar die Schärfe verbesserte.
Dann ist der Extra-Chip russische Militättechnologie. :|
Was hat er dann entwickelt? Eine Schnittstelle?

Zwei weitere Firmen, deren Technologien darauf basierte, Objekte zu erkennen und zu komprimieren, und nun verschwunden sind:
- Arctic Systems Inc
Deren Präsentation auf dem THIC (Siehe http://www.thic.org )
http://www.thic.org/pdf/Jan01/arctic.pvega.010113.pdf

- Pulsent
http://web.archive.org/web/20030417003239/http://www.pulsent.com/index.html

Gast

2006-01-03, 13:36:17

Auf der Grundlage einer neuronalen Netztechnologie aus der russischen Militärforschung werden Bildinformation (Personen, Gegenstände, Gebäude, etc.) direkt separiert und vektorisiert. Im Ergebnis konnte ein MPEG2-Spot von 25 MB auf 1.5 MB reduziert werden, wobei sich sogar die Schärfe verbesserte.

schon alleine da stellt es mir die ohren auf.

ein videocodec kann und soll die schärfe nicht verbessern. die aufgabe der kompression ist es so nah wie möglich am original zu bleiben und nicht jenes zu verbessern.

aths

2006-01-03, 17:47:23

Ja und nein. Wenn man ein MPEG-Video zoomt, wird es immer unscharf. Ein vektorisiertes Video kann man zoomen, ohne dass es unscharf wird. (Natürlich kommen trotzdem keine neuen echten Details hinzu.)

Gast

2009-03-27, 21:51:34

Über 2 Jahre ist es her und nichts Neues gehört vom Wundercodec.

Die Homepage scheint vom Stand 2005 hängenbeblieben zu sein.

Weiss einer mehr?

Gast

2009-03-28, 10:21:01

Da gibts nichts zu wissen, der Codec war von Anfang an ein Fake und hat nie existiert. Einziger Sinn der Sache lag darin, dass man so an Investorengelder kommt...

PHuV

2009-03-28, 12:57:17

Da gibts nichts zu wissen, der Codec war von Anfang an ein Fake und hat nie existiert.

Woher weißt Du das? Gibt es dazu Quellen?

aths

2009-03-28, 15:54:40

Die Existenz von etwas muss belegt werden. Der Nachweis dass es einen supertollen Codec von Uwe Prochnow geben soll, steht aus.

Lokadamus

2009-03-29, 09:51:53

mmm...

Das Teil kann man hier kaufen.
http://www.atvisican.de/de/adviver/index2.php

http://www.google.de/search?q=Allcanview

pest

2009-03-29, 10:23:26

Quark^10

Gast

2009-04-06, 03:30:05

Also googled mal nach "object based video compression" bzw. "onject based video coding" ("obvc")

Z.B. kommt so etwas raus:

http://www.library.unsw.edu.au/~thesis/adt-ADFA/uploads/approved/adt-ADFA20051110.115419/public/07chapter6.pdf
hier: ab S210 Vergleich Object-based codec gegen h.264 bei niedrigen Bitraten in Bildern + Ausschnitte aus Frames
Da ist h.264 deutlich unterlegen

S201-S207: Funktionsweise (Objecterkennung, Sprite-/Texture-Generierung...)
S207: Bitratenverbrauch für Texturen, Bewegung

Oder hier:
http://www.eurasip.org/Proceedings/Ext/PCS2007/defevent/papers/cr1202.pdf
Letzte Seite: Vergleichsbilder-> mehr details sichtbar im Vergleich zu h.264

http://www.springerlink.com/content/t324837h1x2g3682/

http://www.irisa.fr/temics/publis/2003/ICIP-2003-CHAUMONT-CAMMAS-PATEUX.pdf

Einige interessante Artikel sind leider nicht zugreifbar.

Dabei werden, je nach Quelle/Forschung/Veröffentlichungs-Datum, Wavelets, Sprites in mehreren Bild-Layern, Fraktale Compression und weitere teils einfachere Verfahren genutzt.

Das ganze ist noch weltweit in der Entwicklung, da jeder in eine andere Richtung forscht.

Jetzt wüsste ich nur:
WO bekommt man die Test-Codecs her ??? (nur zum Experimentieren :D)

PS: Mpeg4 bzw. h.264 werden auch zu den Object-Based Video Coding "gezählt" bzw. beinhalten Objekte, nur werden sie noch nicht genutzt (wie denn) :|

Gast

2009-04-08, 12:18:09

Also googled mal nach "object based video compression" bzw. "onject based video coding" ("obvc")
Sorry, es muss "object based video coding" heißen.

http://www.eurasip.org/Proceedings/Ext/PCS2007/defevent/papers/cr1202.pdf
Letzte Seite: Vergleichsbilder-> mehr details sichtbar im Vergleich zu h.264
Hier gibt es vom Symposion weitere Links:
http://www.eurasip.org/Proceedings/Ext/PCS2007/defevent/main/topidx.pdf
Meistens zu mathematisch. ;)

http://www.springerlink.com/content/t324837h1x2g3682/
Von der Uni kann ich drauf zugreifen, aber außerhalb des Netzwerkes ist es leider nicht möglich.

@pest
Quark^10
Wenn die mit der Entwicklung so weiter machen, dann in der Zukunft nicht mehr. ;D

Nun zum "Wundercodec":
1. Woher hat der Prochnow den Codec bzw. das funktionierende System her, da die meisten noch in Entwicklung sind? Es heißt irgendwo im Thread "russ. Militärtechnologie". Ich denke, so einfach dürften die Russen nicht so gerne in ihr Kämmerlein reinschauen.
2. Die meisten OBV-Codecs liegen noch tief im alpha-Status der Entwicklung. Beta dürfte es frühestens in paar Jahren geben. (vielleicht auch schneller)

PS: Es erinnert mich irgendwie an die Anfangszeit, als zwei "Hacker" (Jérôme Rota(fr) und Max Morice(dt)) den Mpeg4-Codec von MS gehackt haben (-> divx 3.x) und daraus die bekannten Codecs divx bzw. xvid entwickelt worden sind.
War damals auch ein größerer Umbruch. (->DivX (http://de.wikipedia.org/wiki/DivX) bzw. DivX(eng) (http://en.wikipedia.org/wiki/DivX))

pest

2009-04-08, 12:21:28

Wenn die mit der Entwicklung so weiter machen, dann in der Zukunft nicht mehr. ;D

das hoffe ich doch. Gegen Objekt Basierende Kompression ist nichts einzuwenden.

Ich kann (als Gedankenkonstrukt) auch den perfekten Videocodec fabrizieren,
nur leider scheitert es dann eben an den Details und die verschweigt der Prochnow wissentlich, denke ich. Da sind einfach viel zu viele Fragen offen.

PS: Es erinnert mich irgendwie an die Anfangszeit, als zwei "Hacker" (Jérôme Rota(fr) und Max Morice(dt)) den Mpeg4-Codec von MS gehackt haben (-> divx 3.x) und daraus die bekannten Codecs divx bzw. xvid entwickelt worden sind.
War damals auch ein größerer Umbruch. (->DivX (http://de.wikipedia.org/wiki/DivX) bzw. DivX(eng) (http://en.wikipedia.org/wiki/DivX))

es ist etwas anderes einen codec zu hacken um die kontrolle darüber zu erlangen, als einen codec selbst zu schreiben ;)
ich erinnere mich ungern an den "noshit"-Parameter :D

Gast

2009-04-08, 12:44:36

es ist etwas anderes einen codec zu hacken um die kontrolle darüber zu erlangen, als einen codec selbst zu schreiben ;)
Ich schätze mal, Prochnow hat auch kaum was entwickelt.
Es wird in der Summe von einem russ. Chip gesprochen, der über ein neuronales Netz Objekte erkennt.
Nun fehlt noch so eine Art Container/Stream, in der die ganzes Texturen usw. abgespeichert werden.

ich erinnere mich ungern an den "noshit"-Parameter :D
:) muss es nicht heißen "shit=0" ? :D
(PS: Wundercodec != "shit" != 0 ;D)

Coda

2009-04-08, 14:40:30

Neuronale Netze... ohje...

Gast

2009-04-08, 15:07:56

Neuronale Netze... ohje...
Marvin !? ;) :D (Per Anhalter....)
Sollen dazu dienen, Objekte zu erkennen... vermute ich mal

Coda

2009-04-08, 15:12:36

Ich weiß was ein neuronales Netz ist. Nur ist mir das Zeug immer viel zu undeterministisch.

pest

2009-04-09, 08:12:19

Sobald das Wort "Neuronales Netz" fällt gibts doch immer "aaaah" und "ooooh" :D
Der Praktische Anwednungsbereich ist trotzdem sehr beschränkt imo

Gast

2009-04-13, 18:11:26

es gab mal Hype um Fuzzy Logik und Neuronale Netze
nur hat es die erwartungen nicht erfüllt

hier bei doom9 artikel zu svm - scalable video coding
http://forum.doom9.org/showthread.php?t=101344

wie gesagt, noch alles in entwicklung

Actionhank

2009-04-13, 18:24:12

v.a. kacken neuronale netze und der gleichen bei erkennung und klassifikation eigentlich regelmäßig gegen statistische verfahren ab.

Coda

2009-04-13, 18:48:44

Neuronale Netze sind im Prinzip auch nur eine Ausrede, wenn man das was zwischen Eingabe und Ausgabe passieren sollte nicht kapieren möchte ;)

Gast

2009-04-13, 21:01:26

Neuronale Netze sind im Prinzip auch nur eine Ausrede, wenn man das was zwischen Eingabe und Ausgabe passieren sollte nicht kapieren möchte ;)
:) oder ein Verfahren fehlt bzw. noch nicht entwickelt worden ist bzw. wird ;)

Die einzigen in Deutschland, die sich mit neueren Multimedia-Standards u.a. auch Objekt-Erkennung beschäftigt sind, sind die vom RWTH Aachen:
http://www.ient.rwth-aachen.de/cms/software/
http://www.ient.rwth-aachen.de/cms/software/intermedia/ -> Objekt-Erkennung

Dort ist auch ein MPEG7 Audio Encoder.
Habe es nicht ausprobiert.

PHuV

2013-01-28, 01:37:54

Atvisican: Wie die MPEG-Hochstapelei endete (http://blog.buetikofer.net/2010/07/13/atvisican-wie-die-mpeg-hochstapelei-endete/)

Sieh an, doch nur große Verarsche.

MartinB

2013-01-28, 01:51:56

Nightspider

2013-01-28, 01:57:38

Mich würde ebenfalls interessieren ob H.265 mehr Rechenleistung benötigt oder woher die bessere Komprimierungsrate kommt.

Ich wäre dafür das wir das in einen neuen H.265-Thread ausgliedern.

aths

2013-01-28, 12:48:56

Ich frage mich ob nun H.265 etwas ähnliches macht. Zeitliche Prädiktion ist ja ein alter Hut und dank neuer Algorithmen wäre eine Mustererkennung zur starken Kompression durchaus denkbar. Anstatt das Muster "pixelweise" zu übertragen, braucht man dann nur noch die Musterparameter.

Ähnlich wie es bei Audiocodecs bereits schon lange eingesetzt wird.
Verlustbehaftete Audio- und Videocodecs setzen in erster Linie darauf, dass man bei lauten Passagen oder bei hartkontrastigen Bildstellen kleine absolute Abweichungen nicht bemerkt, weil unsere Wahrnehmung auf Vergleiche, also auf relative Abweichung setzt. Man quantisiert das Signal gröber, je nach dem, "wie viel los ist". Dann kann man weitere Dinge nutzen. Beim Audiosignal lassen sich bestimmte Details ganz weglassen, weil sie in unserer Wahrnehmung von einem lauteren Signal maskiert, also übertönt werden. Bei Bildern kann man die Farbe in geringerer Bildauflösung speichern und braucht nur den Monochromwert in voller Auflösung speichern. Weil es für einen Computer dann leichter ist, unwichtige Details zu erkennen, wandelt man das Signal vorher mit der Fourieranalyse um. Hier lässt sich die anfangs erwähnte gröbere Quantisierung leichter bewerkstelligen.

Anders gesagt: Die Komprimierung beruht in erster Linie auf geschicktem Weglassen. Erst am Ende kommt eine Entropiekodierung zum Tragen, also Mustererkennung. Entropie ist das Stichwort bei Musterparametern: Wenn du X unterschiedliche Muster darstellen können willst, brauchst du log2 X Bits.

"Nur noch" die Musterparameter zu brauchen ist keine Komprimierung per se.

MartinB

2013-01-28, 13:55:38

Um die Quantisierung und die Wahrnehmungsmodelle ging es mir aber nicht.

Mir ging es um die erweiterte Musteranalyse. Schon im Audiobereich wird dies bei HVXC und SBR in gewisser Weise durchgeführt. Man überträgt nurnoch unmittelbar wichtige Teile und berechnet sich den Rest neu.

Als Beispiel für die Videokompression könnte man einen rauschenden Wasserfall nehmen. Bei starker Kompression und kleiner Auflösung, könnte man anstatt jedes "Pixel" zu koodieren, nurnoch das Rauschen an sich übertragen, indem man nur noch Kennparameter für die Rauschfunktion kodiert.

aths

2013-01-28, 14:42:50

Das ist wie gesagt per se keine Komprimierung. Um alle Bildinhalte zu kodieren, brauchst du eine große Auswahl an Funktionen und eine längere Liste an mit hoher Genauigkeit gespeicherten Parametern.

MartinB

2013-01-28, 16:04:50

RLZ

2013-01-28, 16:18:01

Das ist mir schon klar, dennoch ist es ein interessantes Feature und es würde mich interessieren ob bzw. wie H.265 davon Gebrauch macht.
Im Grunde ist H.265 von den Techniken her recht unspektakulär.
*Wiki* (http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding)

MartinB

2013-01-28, 16:46:56

So auf den ersten Blick scheinen die größten Änderungen die Blockgröße und die neuen Richtungs-Modi zu sein. Wenn man überall ein wenig optimiert bekommt man sicherlich bessere Kompressionsraten, aber kommt man so auf die angestrebten 50% über H.264?

aths

2013-01-28, 17:10:24

Das ist mir schon klar, dennoch ist es ein interessantes Feature und es würde mich interessieren ob bzw. wie H.265 davon Gebrauch macht.

Ich spreche ja nicht davon alle Bildinhalte so zu kodieren, sondern eben nur dort wo es auch passt.
Das ergibt aber keinen Sinn.

Erst recht nicht bei deinem Beispiel einer Rauschfunktion. Man müsste nicht nur Rausch-"Korngröße" speichern, sondern den Bildinhalt, da der Encoder nicht weiß, ob die Bildstelle mit "irgenein Rauchen passt schon, sofern einige Parameter stimmen" ausreichend gut kodiert ist, oder ob es nicht gerade dort auf bestimmte Dinge ankommt. Selbst wenn der Encoder das wüsste, läge die Komprimierung nicht in deinem Ansatz einer speziellen Mustererkennung, sondern im gezielten Weglassen von Informationen.

MartinB

2013-01-28, 17:33:30

Limit

2013-01-28, 20:00:47

Verlustbehaftete Audio- und Videocodecs setzen in erster Linie darauf, dass man bei lauten Passagen oder bei hartkontrastigen Bildstellen kleine absolute Abweichungen nicht bemerkt, weil unsere Wahrnehmung auf Vergleiche, also auf relative Abweichung setzt. Man quantisiert das Signal gröber, je nach dem, "wie viel los ist".

Klar benutzen moderne Video-Codecs das, aber das "in erster Linie" würde ich streichen. x264 z.B. komprimiert auch bei abgeschalteter AQ (gröbere Quantisierung in sehr hellen/dunklen Bereichen) ganz ordentlich. Den Kern moderner Video-Codecs würde ich in der Differenzbildspeicherung in Verbindung mit der Bewegungskompensation sehen.

Weil es für einen Computer dann leichter ist, unwichtige Details zu erkennen, wandelt man das Signal vorher mit der Fourieranalyse um.

Du meinst Fouriertransformation? Das würde zwar prinzipiell gehen, aber meist nimmt man eine DCT (Discrete Cosinus Transformation), weil sie weniger Rechenleistung braucht.

Das ist mir schon klar, dennoch ist es ein interessantes Feature und es würde mich interessieren ob bzw. wie H.265 davon Gebrauch macht.

Afaik nicht, aber ich bezweifle, dass es viel bringen würde, da ein "Muster" durch die Differenzbildspeicherung sowieso schon berücksichtigt würde, zumindest innerhalb einer GOP.

Bei HVXC reichen soweit ich weiß 2 kBit/s aus um Sprache halbwegs aktzeptable zu übertragen.

Die Frage ist dann, ob es da nicht schon fast sinnvoller ist Text-to-Speech zu benutzen?

Ob man jetzt niedriger Quantisiert und Zwischenstufen weglässt, ganze 8x8 Pixelblöcke nurnoch durch Muster beschreibt, oder eben Bildinhalte analyisiert und diese garnicht mehr überträgt sondern deren Kenngrößen, ist doch letztendlich egal.

Das ist schon richtig. Ich befürchte nur, dass man einfach viel zu viele Muster bräuchte. Vor allem wenn man wirklich in Größenordnungen von Blöcke denkt. Wenn man sehr große Muster nehmen will, geht das schon sehr in Richtung Objekterkennung.

Coda

2013-01-28, 20:21:37

https://www.xiph.org/daala/

Das Zeug mal anschauen. Gibt einen guten Überblick über moderne Video-Kompression.

MartinB

2013-01-28, 20:48:54

Die Frage ist dann, ob es da nicht schon fast sinnvoller ist Text-to-Speech zu benutzen?TTS ist absolut keine brauchbare Lösung wenn es um Radio geht. AAC+SBR wird bei Datenraten von 10 bis 40 kBit/s bei DRM (Digital Radio Mondiale, also u.A. auch Musik) eingesetzt.

Das ist schon richtig. Ich befürchte nur, dass man einfach viel zu viele Muster bräuchte. Vor allem wenn man wirklich in Größenordnungen von Blöcke denkt. Wenn man sehr große Muster nehmen will, geht das schon sehr in Richtung Objekterkennung.

Deswegen stellte ich die Frage auch in diesem Thread hier. Der "Wunder-Codec" sollte nämlich genau dies tun. Das dies prinzipiell möglich ist, steht ja außer Frage. Ich wollte eben nur wissen ob H.265 dies evtl benutzt.

Man könnte ja z.B. Rauschmuster in Blöcken erkennen und anstatt eines dieser 33 neuen "Verlaufsmuster" zu wählen, eben das Rauschen rekonstruiren.

Limit

2013-01-28, 22:37:06

Deswegen stellte ich die Frage auch in diesem Thread hier. Der "Wunder-Codec" sollte nämlich genau dies tun. Das dies prinzipiell möglich ist, steht ja außer Frage. Ich wollte eben nur wissen ob H.265 dies evtl benutzt.

Was soll er tun? Muster oder Objekterkennung? Die Bewegungskompensation kann man, wenn man großzügig ist als eine Art von Mustererkennung betrachten. Das ist aber keinesfalls neu. Dabei wird geschaut ob es für einen gegebenen Block im selben Bild oder in einem benachbarten einen hinreichend ähnlichen Block gibt. Falls ja, speichert man einfach eine Referenz auf diesen und ein "Differenzbild" zwischen den beiden Blöcken. Was bei H.265 in dem Bereich geändert wurde, ist einerseits die max. Blockgröße zu erhöhen und andererseits die Flexibilität bei der Wahl der Blockgröße zu erhöhen.

Objekterkennung und ein darauf beruhender Videocodec (Da könnte man sogar darüber streiten, ob die Bezeichnung dann überhaupt noch passend ist) ist wohl noch sehr sehr weit entfernt, falls es überhaupt jemals einen solchen geben wird.

Man könnte ja z.B. Rauschmuster in Blöcken erkennen und anstatt eines dieser 33 neuen "Verlaufsmuster" zu wählen, eben das Rauschen rekonstruiren.

Das ist im Prinzip das, was ich oben bei der Bewegungskompensation beschrieben habe. Unterschied ist halt, dass man keine globalen Muster hat, sondern diese zeitlich und örtlich lokal sucht.

Zum Thema Rauschmuster: Afaik ist echtes Rauschen per Definition vollkommen zufällig und daher bräuchtest du genau so viele Muster wie es verschiedene Blöcke geben kann. Natürlich könntest du ähnliche Muster zusammenfassen, aber genau das macht ja sowieso schon die Quantisierung, ergo kann man sich das sparen.
Etwas anderes sind Bildartefakte, also Störungen die durchaus Muster erzeugen. Meistens möchte man diese aber nicht erhalten, sondern eher entfernen.

Coda

2013-01-28, 23:38:53

Milchkanne

2013-01-29, 00:14:07

Tatsächlich wurde das sogar schon für h264 spezifiziert und nennt sich Film Grain Modelling, es war aber in keinem Profil enthalten und kein En- und Decoder unterstützt das.
Andererseits enthalten die Psy Optimierungen von x264 etwas ähnliches, das hat auch unter dem namen Film Grain Optimization angefangen (und hat mit FGM nichts zu tun). Die Idee ist grob gesagt, die Energie eines Blocks konstant zu halten. Also wenn normalerweise die hohen Frequenzen wegquantisiert würden, werden einige Koeffizienten hinzugefügt, die sich billiger komprimieren lassen als die ursprünglichen, damit auch hohe Frequenzanteile und somit immerhin irgendein Rauschen im Bild bleibt.

aths

2013-01-29, 13:20:51

Das mit dem Rauschen ist aber ein guter Punkt. Man könnte Rauschen erkennen und einfach beim Decoding wieder zufälliges Rauschen hinzufügen um die subjektive Qualität zu erhöhen.
Wie soll das vom Content her funktionieren? Du willst doch kein zufälliges Rauschen, wenn du schon Rauschen im Content hast.

Tatsächlich wurde das sogar schon für h264 spezifiziert und nennt sich Film Grain Modelling, es war aber in keinem Profil enthalten und kein En- und Decoder unterstützt das.Bildrauschen wäre aber nicht das, was MartinB angesprochen hatte.

aths

2013-01-29, 13:27:59

Klar benutzen moderne Video-Codecs das, aber das "in erster Linie" würde ich streichen. x264 z.B. komprimiert auch bei abgeschalteter AQ (gröbere Quantisierung in sehr hellen/dunklen Bereichen) ganz ordentlich. Den Kern moderner Video-Codecs würde ich in der Differenzbildspeicherung in Verbindung mit der Bewegungskompensation sehen.
Ja, seit Mpeg der Bringer.

Du meinst Fouriertransformation? Das würde zwar prinzipiell gehen, aber meist nimmt man eine DCT (Discrete Cosinus Transformation), weil sie weniger Rechenleistung braucht.Ja, das ist aber ein technisches Detail.

aths

2013-01-29, 13:30:16

Bei extrem geringen Datenraten macht das durchaus Sinn. Bei SBR werden im Audiobereich ja ganze Frequenzbänder weggelassen und nur durch die Hüllkurve beschrieben. Da werden u.A. auch Rauschparameter mitübertragen. Der Encoder stellt dann diese Frequenzbänder anhand der Zusatzinformationen wieder (so gut es geht) her.

Das lässt sich bei Video doch genauso gut einsetzen. Bei 320*240 Pixel merkt keiner den Unterschied zwischen einem generierten Wasserfall und einem Echten (der bei üblicher Kompression sowieso nur Pixelmatsch wäre). Wie gesagt, sowas lohnt sich nur bei minimaler Datenrate. Bei HVXC reichen soweit ich weiß 2 kBit/s aus um Sprache halbwegs aktzeptable zu übertragen.

Und natürlich beinhaltet verlustbehaftete Kompression immer ein Weglassen von Informationen, deswegen ist es ja verluftbehaftet. Ob man jetzt niedriger Quantisiert und Zwischenstufen weglässt, ganze 8x8 Pixelblöcke nurnoch durch Muster beschreibt, oder eben Bildinhalte analyisiert und diese garnicht mehr überträgt sondern deren Kenngrößen, ist doch letztendlich egal.
Gerade bei 320x240 benötigt man gute Bildschärfe, um überhaupt noch was zu erkennen. Nach wie vielen Mustern soll der Encoder denn suchen und wie groß müsste die Decoder-Muster-Bibliothek sein? Was man macht, ist, eine Blockinhaltsbeschreibungsmethode zu nutzen, die zuerst Dinge weglässt, wie wenig auffallen. Das funkioniert überall und ist bereits, wenn man mal sehr großzügig ist, eine Art Mustererkennung.

Machen wir es einfach und gehen weg von Videokomprimierung zu Texturkomprimierung. Gängige Texturkomprimierung benötigt für einen Block von 4x4 Texeln 64 Bit. Mit 64 Bit lassen sich nur 2^64 unterschiedliche Inhalte abspeichern. Ausgehen von einem Bild mit 16 Bit Farbe (RGB 5-6-5) hätte man aber 2^256 unterschiedliche mögliche Blöcke. Wenn wir uns alle 2^256 unterschiedlichen Blöcke in einem Raum vorstellen, sorgt die Methode der Texturkomprimierung dafür, dass 2^64 eher sinnvolle Möglichkeiten aus dem Gesamtraum ausgewählt werden die sich abspeichern lassen. Oder anders gesagt: Zwischen recht ähnlich aussehenden Blöcke wird kein Unterschied mehr gemacht, aber wesentlich intelligenter als einfach die Farbquantisierung von 16 Bit auf 4 Bit zu senken. (Man speichert zwei Farbwerte die für den gesamten Block gelten. Jedes Texel wird als Gewichtung zwischen den beiden Farben gespeichert, entweder 100% eine Farbe oder 100% die andere, oder 1/3 die eine und 2/3 die andere oder 2/3 die eine und 1/3 die andere. Zwei gute Referenzfarben pro Block zu suchen ist das Geheimnis eines guten S3TC-Encoders.)

Was ist mit Rauschen? Starkes Rauschen wird mit gängiger Texturkomprimierung räumlich recht genau erfasst, es leidet lediglich die Information zur Helligkeit, die vom Original in absoluten Werten abweichen kann. Doch das fällt kaum auf, weil eben 'so viel los ist'. Es geht wild durcheinander, das wird erfasst ohne spezielle Mustererkennung. Was ist mit einem sanften Farbverlauf? Der wird ebenfalls ordentlich erfasst. Zwar erlangt man keine echte Truecolor-Qualität von RGB 8-8-8, aber die mögliche Qualität ist für viele Texturen gut genug.

Bei Jpeg ist die Komprimierung deutlich aufwändiger. Nach der Umwandlung in den Frequenzraum ordnet man die Koeffizienten in einem bestimmten Muster an, interpretiert sie als Ganzzahlen und dividiert sie durch einen Faktor. Kleine Koeffizienten werden damit Null. Eine Reihe am Ende die nur noch aus Nullen besteht, wird nicht mit abgespeichert (der Divisionsfaktor muss natürlich abgespeichert werden.) Durch die Anordnung der Koeffizienten werden horizontal und vertikal liegende Änderungen weniger stark wegkomprimiert als welche im anderen Winkel. Wir sprechen besonders auf diese rechtwinklingen Muster an.

Solche Ansätze funktionieren für fast alle Bildinhalte gut. Zwar liegt die Idee nahe, Blöcke mit unterschiedlichen Verfahren zu komprimieren und dann den Block zu nehmen, der auf die kleinste Bitmenge komprimiert wurde, doch damit kann man Blockanschlussartefakte bekommen, wenn Beispielsweise die eine Methode noch sanfte Farbverläufe recht gut erfasst und die andere nicht und zwei solche Blöcke nebeneinanderliegen.

Anstatt mit spezieller Mustererkennung die Komprimierungsrate zu steigern, senkt man lieber die Bitrate bei einem guten Allround-Verfahren und verbessert das Allround-Verfahren.

MartinB

2013-01-29, 14:56:45

aths, du verstehst nicht worauf ich hinaus will. Ich kenne mich mit Videokompression aus (das habe ich u.A. studiert, inklusive dem ganzen Gedöns bzgl. Zick-Zack-Abtastung, Makroblöcke, der DCT, usw), Du brauchst mir das nicht von Anfang an zu erklären.

Mir geht es um die Erweiterung bestehender Verfahren um die von mir beschriebene Funktionalität um noch mehr zu komprimieren, bei gleicher subjektiver Qualität. Du betonst immer wieder dass es unnötig ist, weil die etablierte Kompression ja bereits gut funktioniert. Das will ich ja garnicht abstreiten, aber hier in dem Thread geht es ja um zukünftige Verfahren und da finde ich da kann man eine solche Idee ruhig mal ansprechen.

aths

2013-01-29, 15:25:16

Solche Ideen hatten andere auch schon, oder meinst du nicht? Ich glaube nicht, dass einer von uns Ideen hat, die a) funktionieren und b) auf die noch keiner in der Motion Picture Expert Group oder einer anderen renommierten Videokomprimierungsverfahren-Entwicklertruppe gekommen ist. Was man machen kann, ist, Blockgröße oder den Suchbereich für sich wiederholende Blöcke zu erweitern und etwas Detailarbeit was zum Beispiel Überblendungsparametern von Blöcken angeht (ist aber in H.264 schon drin) und anderen Dingen.

MartinB

2013-01-29, 15:37:36

Wo behaupte ich denn das ich der erste wäre mit dieser Idee? Ich wollte nur wissen ob H.265 diese implementiert.
Wenn es nach dir gehen würde, dürfte man also nirgends über Ideen reden die noch nicht existieren?

Der einzig hilfreiche Beitrag in dieser Richtung kam von "Milchkanne".
Tatsächlich wurde das sogar schon für h264 spezifiziert und nennt sich Film Grain Modelling, es war aber in keinem Profil enthalten und kein En- und Decoder unterstützt das.

aths

2013-01-29, 15:40:27

Film Grain ist kein Wasserfall. Du hast über was anderes gesprochen als Milchkanne.

MartinB

2013-01-29, 15:47:30

Ich weiß worüber ich gesprochen habe, danke :rolleyes:. Ich habe ja auch nicht geschrieben das Milchkanne mir nun alle Fragen der Menschheit beantwortet hat. Dennoch war die Antwort hilfreicher als dein "das ist Unsinn, weil die altbewährte Komprimierung funktioniert".

Warum sollte es nicht machbar sein einen Wasserfall, bzw dessen Rauschen zu erkennen und eben nicht mehr zu übertragen, sondern im Encoder wieder rekonstruiren? Anzahl der benötigten Funktionen, oder Parameter? Das ist eine Hardwarelimiterung. Vor 20 Jahren war auch kein H.264 denkbar bei der geringen Hardwarepower. Heutzutage nimmt jedes billige Smartphone in FullHD und H.264 auf. Parameteranzahl? Solange es weniger Paramater sind als die Datenmenge eines "standard"-komprimierten Videos, lohnt sich es.

Oder mal ein übertriebenes Beispiel: der Decoder erkennt in dem Videobild eine Blumenwiese und überträgt nurnoch die Informationen der Parameter, also z.B. "Sonnenblumen, 3 Blumen / 10Pixel, Durchschnittsfarbe, Durchschnittshelligkeit. Die Wiese ist im Frame nur 100x100Pixel groß, irgendwo im Hintergrund in einer Ecke. Der Encoder stellt nun irgendeine Wiese wieder her. Fällt einem das auf? Und selbst wenn, in diesem Szenerio hätte man wohl nur ein einziges Byte gebraucht um die Wiese zu übertragen. Oder eben auch der Wasserfall. Da könnte man ja weiterhin die grobe Form "altbewährt" übertragen, aber eben alle Feinheiten komplett weglassen und nachträglich wieder genrieren. Wenn 90% aller Leute nicht auffallen würde, dass der Wasserfall computergeneriert wurde, dann wäre das schon ein enormer Gewinn. In Fällen wo man für ein Video nur extremst geringe Datenraten zur Verfügung hat, wäre soetwas durchaus denkbar. Internet Streams zum Beispiel. Man erkennt den Rasen, oder die Zuschauer-Tribünen. Der Rasen wird einfach nicht übertragen und der Decoder bekommt die Singalisierung für "Fußballrasen". Bei heutigen Internetstreams erkennt man teilweise ja nichtmal den Ball, so gering ist die verfügbare Datenrate.

Es ist schön dass H.265 nun größere Blöcke und mehr Funktionen zur Bewegungseinschätzung unterstützt, aber darf man deswegen nicht mehr über andere Möglichkeit reden?

aths

2013-01-29, 16:14:28

Sagt dir der Begriff "Entropie" was? Mit X Bits lassen sich nur 2^X Zustände kodieren. Um auf einer Wiese die Sonnenblumen da zu platzieren wo sie im Original sind, mit richtiger Ausrichtung, mit dem Wiegen im Wind, der richtigen Anzahl der Blätter, benötigst du eine Menge Bits. Der Trick ist zudem, dass du das Objekt referenzieren musst. Unterschiedest du nur zwischen "Wasserfall", "Fußballrasen" und "Wiese mit Sonnenblumen" oder "normal kodierter Bildinhalt", reichten dazu zwei Bits. Aber bei der kleinen Liste würde es nicht bleiben.

Deshalb ergibt es mehr Sinn, die Wiese ein mal regulär zu komprimieren und daraus zu referenzieren, falls dieselbe Wiese öfter vorkommt. Anstatt ein Objekt aus einer Liste heraus parametrisch zu beschreiben, kodiert man es lieber ein mal herkömmlich und bezieht dich dann darauf. Man könnte es auch rotiert oder gezoomt verwenden, das machen heutige Encoder glaube ich noch nicht.

Anstatt "Fußballrasen" zu kodieren, reichte bei geringer Aufllösung eine recht eintönige grüne Fläche, gegebenenfalls mit Streifenmuster. Da braucht man keinen prozeduralen Fußballrasenerzeuger um das platzsparend zu speichern.

MartinB

2013-01-29, 16:20:27

Rumbah

2013-01-29, 16:21:51

Wenn ich mich richtig an Berichte über das Film Grain Modelling in H264 erinnere, dann hatte das Verfahren 2 Nachteile, die wahrscheinlich auch auf andere derartige Methoden zutreffen (Erkennung von Bildinhalten und ersetzen durch etwas Parametrisiertes):

1. Das erkannte Rauschen zu entfernen ist nicht so trivial und geht zwangsweise mit Verlust der Bildschärfe einher (die zugefügtes Rauschen nur bedingt ausgleichen kann)

2. Das beim Dekodieren zugefügte parametrisierte Rauschen sah wohl vor allem in Bewegung recht künstlich aus.

So, und ich glaube, was aths mit dem Problem mit der Anzahl der Funktionen/Muster sagen wollte ist, dass das ja nicht beliebig skaliert. Allein wenn du 256 verschiedene Muster anbietest, brauchst du schon für die Kodierung, welches Muster du benutzen willst, 8 Bit. Geschweige denn von den Parametern, wie das Muster zu benutzen ist. Da kann es nützlicher sein, die Bits gleich in die "alte" Kodierung zu stecken.

Breegalad

2013-01-29, 16:29:17

Es gab doch mal (zu Modem-Zeiten) Fraktale Kompression. War damals beeindruckend, incl. Zoom.
Ich finde dazu nix mehr.
Wäre diese Methode heutzutage interessant?

MartinB

2013-01-29, 16:31:12

Das kann der Encoder doch sehr gerne tun. Wenn er erkennt dass durch die Übertragung der Musterinformationen keine Einsparnis gegenüber der Übertragung der Originalpixel entsteht, dann überträgt er eben die Originalpixel. Dies geschieht doch bereits jetzt in mehreren Ebenen im Codec, sei es nun die Entscheidung welcher Frame nun ein I, B oder P Bild ist oder welche Blockgröße benutzt werden soll, etc. Mir ist schon klar dass sich kein komplettes Bild auf diese Weise effizient übertragen lässt, glücklicherweise Arbeiten ja heute alle Encoder halbwegs schlau und entscheiden eben selbst wo es Sinn macht und wo nicht.

aths

2013-01-29, 16:35:22

Die Ausrichtung, der Wind, die Blätteranzahl ist doch vollkommen egal. Bei extremster Komprimierung darf sich das Bild vom Quellmaterial doch unterscheiden. Es geht hier schließlich um verlustbehaftete Komprimierung. Wenn ich das Quellmaterial nicht verändern will, dann darf ich sowieso nur lossless Komprimieren, und dann bräuchten wir sowieso nicht über Quantisierung oder irgendwelche (nicht-integer) Transformationen reden.

Ich verstehe nicht was dein Problem ist zu akzeptieren dass dies eine weitere Möglichkeit zur Kompression darstellt. Das Ganze wird ja schließlich auch im Audiobereich bereits von einigen Codecs für Spezialfälle angewendet.
Das ist "vollkommen" egal? Erzähl das mal einem Regisseur.

Bei "extremster" Komprimierung nimmt man geringe Auflösung. Da fallen automatisch Details weg die einzelne Blätter.

Dein Verfahren wie gesagt ist zudem keine echte Komprimierung. Du legst vorgefertigten Content (Anweisungen, wie für ein Muster die Parameter ausgewertet werden) in eine Bibliothek die vom Decoder benutzt wird. Solchen Content kann man aber per se nicht intelligenter beschreiben als man das direkt in der Videodatei selbst tun könnte.

Es ergibt auch rein technisch keinen Sinn. Was ist, wenn der Film gar keine Sonnenblumenwiese enthält? Dann schleppt der Decoder trotztem die Bibliothek mit sich rum.

aths

2013-01-29, 16:37:38

Es gab doch mal (zu Modem-Zeiten) Fraktale Kompression. War damals beeindruckend, incl. Zoom.
Ich finde dazu nix mehr.
Wäre diese Methode heutzutage interessant?
Nein. Um Bildinhalt hinreichend exakt zu beschreiben, musst du Parameter mit sehr hoher Genauigkeit speichern. Das kostet zu viele Bits.

MartinB

2013-01-29, 16:51:22

Das ist "vollkommen" egal? Erzähl das mal einem Regisseur.
Der Regisseur entscheidet nicht wie komprimiert wird. Die Sendeanstalten sind es. Schau dir mal DVB-T an, kein Regisseur der Welt hätte mit diesen Blockartefakten leben können. Was ich damit ausdrücken will: wenn es den Endkunden nicht stört, dann ist es vollkommen egal was nun übertragen wird. Wenn man sich die heutige Medienlandschaft mal anschaut, dann wird man feststellen dass dies leider viel zu oft zutrifft.

Bei "extremster" Komprimierung nimmt man geringe Auflösung. Da fallen automatisch Details weg die einzelne Blätter.
Das dies nicht immer ausreicht kannst Du dir also nicht vorstellen? Guck dir mal DRM und deren Bitraten an. Das hättest Du mit stärkerer Quantisierung und Frequenzunterabtastung (denn nichts anderes ist die Auflösung eigentlich) nie im Leben hinbekommen.

Dein Verfahren wie gesagt ist zudem keine echte Komprimierung. Natürlich ist es das. Das Weglassen von Informationen und das übertragen der nach den Wahrnehmungsmodellen wichtigen Informationen ist immer eine Komprimierung. Allein schon in dem Moment in welchem Du dich entscheidest nur noch die halbe Farbauflösung zu nehmen (was alle Videocodecs im Main Profile machen) lässt Du Sachen weg die Du nie wieder herstellen sondern nur halbwegs gut erraten kannst.

Du legst vorgefertigten Content (Anweisungen, wie für ein Muster die Parameter ausgewertet werden) in eine Bibliothek die vom Decoder benutzt wird. Solchen Content kann man aber per se nicht intelligenter beschreiben als man das direkt in der Videodatei selbst tun könnte.
Nicht intelligenter, aber aber eben mit weniger Bits bei subjektiver gleicher Qualität.
Den "vorgertigten Content" hast Du aber auch bei H.264. Es gibt 9 Verlaufsmuster der 8x8 Blöcke, du nimmst nur eben den der am besten zum Originalblock passt. Und diese Verläufe liegen im Decoder in einer Bibliothek vor.

Es ergibt auch rein technisch keinen Sinn. Was ist, wenn der Film gar keine Sonnenblumenwiese enthält? Dann schleppt der Decoder trotztem die Bibliothek mit sich rum.
Na und? Was ist wenn der Film nur I-Frames enthält? Der Decoder hat dann seine ganze tolle Bewegungseinschätzung umsonst eingebaut.

Übrigens arbeitet Zip auch mit Bibliotheken. Was ist wenn ddas gepackte File garnicht alle Codewörter enthält die es in der Bibliothek gibt?

Milchkanne

2013-01-29, 17:06:23

Ich muss aber auch sagen, dass ich bezweifel, dass relevante und nützliche Codecs in den nächsten 10 Jahren mit Mustererkennung arbeiten werden. Das ist einfach zu kompliziert und die Anzahl der möglichen Muster zu groß und die Bandbreiten nehmen ja ohnehin eher zu als ab. Und ich glaube nicht, dass jemand in jedem Film die gleiche Wiese sehen will. Und wenn man auch noch Parameter für den Wiesengenerator speichern muss, dann reduziert das die Kompression auch wieder und sieht immernoch kacke aus. Dann lieber einmal das Bild speichern und ab dann den Rest in Bewegungsvektoren.

aths

2013-01-29, 17:10:38

Der Regisseur entscheidet nicht wie komprimiert wird. Die Sendeanstalten sind es. Schau dir mal DVB-T an, kein Regisseur der Welt hätte mit diesen Blockartefakten leben können. Was ich damit ausdrücken will: wenn es den Endkunden nicht stört, dann ist es vollkommen egal was nun übertragen wird. Wenn man sich die heutige Medienlandschaft mal anschaut, dann wird man feststellen dass dies leider viel zu oft zutrifft.
Der Encoder hat keine Möglichkeit, festzustellen, ob ein bestimmter Platz der Sonnenblume nicht doch noch für die Handlung wichtig ist. Was ist, wenn der Autor offenlassen möchte, ob eine Sonnenblume für die Handlung wichtig ist, also den Zuschauer bewusst im Unklaren lassen, ob sie zufällig dort steht oder irgendwie den Mörder des Krimis verrät?

Das dies nicht immer ausreicht kannst Du dir also nicht vorstellen? Guck dir mal DRM und deren Bitraten an. Das hättest Du mit stärkerer Quantisierung und Frequenzunterabtastung (denn nichts anderes ist die Auflösung eigentlich) nie im Leben hinbekommen.
Natürlich ist es das. Das Weglassen von Informationen und das übertragen der nach den Wahrnehmungsmodellen wichtigen Informationen ist immer eine Komprimierung. Allein schon in dem Moment in welchem Du dich entscheidest nur noch die halbe Farbauflösung zu nehmen (was alle Videocodecs im Main Profile machen) lässt Du Sachen weg die Du nie wieder herstellen sondern nur halbwegs gut erraten kannst.
Das Weglassen von Information ist verlustbehaftete Komprimierung, nicht dein Vorschlag der Objekt/Mustererkennung. Um ein Muster hinreichend genau zu beschreiben, benötigst du wieder entsprechend viele Bits.

Wenn du jedoch auf Content im Decoder angewiesen bist ("zeichne von hier bis da Fußballwiese Nummer drei aus der Decoder-Bibliothek) ist das keine Komprimierung, nur eine Verlangerung von Daten. Aber eine höchst ineffziente, da der Decoder die volle Bibliothek braucht.

DRM ist für Audiosignale, die sich anders komprimieren lassen. Eine Audiospur ist nur eindimensional, so dass weniger Parameter zur Beschreibung ausreichen.

Nicht intelligenter, aber aber eben mit weniger Bits bei subjektiver gleicher Qualität.
Den "vorgertigten Content" hast Du aber auch bei H.264. Es gibt 9 Verlaufsmuster der 8x8 Blöcke, du nimmst nur eben den der am besten zum Originalblock passt. Und diese Verläufe liegen im Decoder in einer Bibliothek vor.

Na und? Was ist wenn der Film nur I-Frames enthält? Der Decoder hat dann seine ganze tolle Bewegungseinschätzung umsonst eingebaut.

Übrigens arbeitet Zip auch mit Bibliotheken. Was ist wenn ddas gepackte File garnicht alle Codewörter enthält die es in der Bibliothek gibt?Ein paar Verlaufsmuster als vorgegebener Content ist nicht das, was du vorschlägst. Du willst eine Vielzahl an Mustern parametrisch beschreiben und du willst Objekte darin auch zufällig platzieren können wie die Sonnenblumen. Das hat nichts mit festverdrahteten (bzw. fest vorliegenden) Verläufen zu tun.

Jeder normale Film hat nicht nur I-Frames. Wenn doch, enthielte er extrem chaotischen Content, der als Film keinen Sinn ergibt. Dafür braucht man auch keinen Encoder. Außerdem ist die B- und P-Frame-Mechanik in einigen tausenden oder Zigtausenden Byte Programmcode untergebracht. Das spielt lange nicht in der Größenordnung, wie sie für deinen Ansatz notwendig wäre. Bei deinem Ansatz würde der Decoder für jeden Videoclip eine Menge Musterbeschreibungen herumtragen, die in vielen Filmen nicht gebraucht werden.

MartinB

2013-01-29, 17:46:23

Der Encoder hat keine Möglichkeit, festzustellen, ob ein bestimmter Platz der Sonnenblume nicht doch noch für die Handlung wichtig ist. Was ist, wenn der Autor offenlassen möchte, ob eine Sonnenblume für die Handlung wichtig ist, also den Zuschauer bewusst im Unklaren lassen, ob sie zufällig dort steht oder irgendwie den Mörder des Krimis verrät?

Die Sonnenblume wäre bei starker "traditioneller" Kompression garnicht zu sehen. Das findet der regisseur sicher besonders toll.

Das Weglassen von Information ist verlustbehaftete Komprimierung, nicht dein Vorschlag der Objekt/Mustererkennung. Um ein Muster hinreichend genau zu beschreiben, benötigst du wieder entsprechend viele Bits.

Wenn du jedoch auf Content im Decoder angewiesen bist ("zeichne von hier bis da Fußballwiese Nummer drei aus der Decoder-Bibliothek) ist das keine Komprimierung, nur eine Verlangerung von Daten. Aber eine höchst ineffziente, da der Decoder die volle Bibliothek braucht.

Nein. Die Muster werden durch Algorithmen beschrieben. Das ist ein gängiger Ansatz und Zip unterstützt z.B. mehrere Hundert Megabyte große Bibliotheken wenn man es darauf anlegt. Zip ist demnach also auch keine Komprimierung?

DRM ist für Audiosignale, die sich anders komprimieren lassen. Eine Audiospur ist nur eindimensional, so dass weniger Parameter zur Beschreibung ausreichen.

Das Grundprinzip ist sehr ähnlich. Ersetze etwas vorhandenes durch etwas künstlich generiertes das annähernd passt.

Ein paar Verlaufsmuster als vorgegebener Content ist nicht das, was du vorschlägst. Du willst eine Vielzahl an Mustern parametrisch beschreiben und du willst Objekte darin auch zufällig platzieren können wie die Sonnenblumen. Das hat nichts mit festverdrahteten (bzw. fest vorliegenden) Verläufen zu tun.

Die Verlaufsmuster sind genau das was Du an dem Mustererkennungsansatz auszusetzen hast: sie Verlagern einen Teil des Contents in den Decoder.

Jeder normale Film hat nicht nur I-Frames. Wenn doch, enthielte er extrem chaotischen Content, der als Film keinen Sinn ergibt. Dafür braucht man auch keinen Encoder. Außerdem ist die B- und P-Frame-Mechanik in einigen tausenden oder Zigtausenden Byte Programmcode untergebracht. Das spielt lange nicht in der Größenordnung, wie sie für deinen Ansatz notwendig wäre. Bei deinem Ansatz würde der Decoder für jeden Videoclip eine Menge Musterbeschreibungen herumtragen, die in vielen Filmen nicht gebraucht werden.

Das ist doch völlig belanglos wenn es um die Kompression geht. Dann benötigt die Decoderdatenbank eben mehrere Hundert MB. Wenn sich dadurch im Schnitt die Datenrate halbieren lässt, ist der Vorteil enorm. Man könnte diese Datenbank sogar dynamisch aufbauen und am Anfang des Films mitschicken lassen oder auch dynamisch Aufbauen, genau wie es bei ZIP getan wird.

Milchkanne

2013-01-29, 18:32:34

Also dein Vorschlag ist ja wohl schon ein riesiger Unterschied zum Zip Wörterbuch. Und was du in deinem letzten Absatz sagst, die "Datenbank sogar dynamisch aufbauen", das ist ja in etwa das, was gemacht wird. Ein Muster wird gespeichert und dann in vielen Frames referenziert. Wenn du prozedural generierte Muster für jeden Film generieren willst, ich bezweifel dass das je klappen wird.
Tatsächlich könnte ich mir einen Fußballspiel zu Fifa Socker replay Konverter noch ganz gut vorstellen, da sind die Parameter extrem eingeschränkt und viel gleichbleibender Kontent lässt sich prima in der Engine speichern, aber für allgemeine Filme halte ich das für eine untaugliche Idee.

Limit

2013-01-29, 18:47:01

Wie soll das vom Content her funktionieren? Du willst doch kein zufälliges Rauschen, wenn du schon Rauschen im Content hast.

Der Punkt ist der, dass du das Rauschen aus der Quellmaterial entfernt (Rauschfilter gibt es wie Sand am Meer), wodurch die Komprimierbarkeit mit der üblichen Quantisierung deutlich zunimmt. Da Rauschen selbst keine Bildinformationen trägt, sondern zufällig ist, kann man es dann zum abspielen einfach wieder zufällig hinzufügen. Um dem Original-Bildeindruck möglichst nahe zu kommen, kann man einige Grundmerkmale des Rauschens, z.B. Intensität und Körnung (hier lässt Martins Vorschlag grüßen), speichern und zur Abspielzeit einfach entsprechend zufällig generieren.

Bildrauschen wäre aber nicht das, was MartinB angesprochen hatte.

Nein, war es nicht, aber an der Stelle wäre es brauchbar.

Das will ich ja garnicht abstreiten, aber hier in dem Thread geht es ja um zukünftige Verfahren und da finde ich da kann man eine solche Idee ruhig mal ansprechen.

Sicher kann man darüber reden. Meiner Meinung nach würde es aber keinen zusätzlichen Nutzen bringen. Die Haken sind einerseits die große Muster-Bibliothek, die du mit rumschleppen müsstest. Auch um das entsprechende Muster zu referenzieren bräuchtest du sehr lange Codewörter. Andererseits entspricht die Bewegungskompensation bereits einer einfachen Art Mustererkennung auf Blockebene, eben nur zeitlich und räumlich lokal begrenzt. Eine Mustererkennung im größeren Maßstab würde die Sache wegen viel zu großem Overhead vermutlich eher verschlechtern als verbessern.

Warum sollte es nicht machbar sein einen Wasserfall, bzw dessen Rauschen zu erkennen und eben nicht mehr zu übertragen, sondern im Encoder wieder rekonstruiren?

Meinst du hier mit Rauschen das Bildrauschen oder das echtes Wasserrauschen? Ersteres wird wie bereits gesagt wurde in den H.264 Spezifikationen zumindest vorgesehen, wenn auch nie umgesetzt. Zweiteres hingegen ist nicht so einfach, weil Wasserrauschen kein zufälliger Prozess ist. Natürlich könnte man so etwas halbwegs physikalisch korrekt generieren, aber das würde für eine auch nur halbwegs korrekte Wiedergabe des Originals eine exorbitant große Menge von Parametern brauchen.

Anzahl der benötigten Funktionen, oder Parameter? Das ist eine Hardwarelimiterung.

Das hast du vermutlich falsch verstanden. Er meint wohl damit, dass du für eine halbwegs korrekte Wiederherstellung des Originals soviele Parameter bräuchtest, dass du dafür mehr Speicher verbrauchst als man für die Komprimierung des Bildausschnitts mit der altbewährten Technik bräuchte.

Solange es weniger Paramater sind als die Datenmenge eines "standard"-komprimierten Videos, lohnt sich es.

Das ist der Knackpunkt — vermutlich würdest du mit der Datenmenge wie bei der herkömlichen Technik mit deiner Methode nicht mal ansatzweise so nah ans Original herankommen. Das einzige was deine Method da retten könnte wäre es, wenn man sagt, es soll irgendein Wasserfall (mit bestimmten Randbedingungen) im Bild platziert werden, der aber nicht dem im Original entsprechen muss. Aber diese Entscheidung kann auf keinen Fall der Codec treffen, sondern das müsste der Regiseur, Produzent oder sonst wer entscheiden.

Oder mal ein übertriebenes Beispiel: der Decoder erkennt in dem Videobild eine Blumenwiese und überträgt nurnoch die Informationen der Parameter, also z.B. "Sonnenblumen, 3 Blumen / 10Pixel, Durchschnittsfarbe, Durchschnittshelligkeit. Die Wiese ist im Frame nur 100x100Pixel groß, irgendwo im Hintergrund in einer Ecke. Der Encoder stellt nun irgendeine Wiese wieder her.

Die Entscheidung könnte wie o.g. nicht der Codec treffen. Vielleicht gibt es in der Wiese ja einen verborgenes Muster. Das weiß der Drehbuchschreiber, aber sicher nicht der Codec.

Ich verstehe nicht was dein Problem ist zu akzeptieren dass dies eine weitere Möglichkeit zur Kompression darstellt. Das Ganze wird ja schließlich auch im Audiobereich bereits von einigen Codecs für Spezialfälle angewendet.

Das was du mit deiner Blumenwiese oder dem Wasserfall beschreibst ist eindeutig Objekterkennung und darauf beruhende Verfahren. Der Film wäre dann im Idealfall im Prinzip nur noch ein ultra-genaues Drehbuch und alles würde computergeneriert. Damit wären theoretisch Datenrate möglich, die viel kleiner sind als mit den herkömlichen Codecs möglich. Daran wird auch schon lange geforscht, aber es wird auch noch sehr sehr lange dauern bis daraus ein praktikabler Codec wird wenn es überhaupt mal soweit kommt.

Mustererkennung im Sinne von Texturerkennung wird wie gesagt in Form von Bewegungskompensation bereits gemacht und da 95% (nagelt mich nicht auf die genaue Prozentzahl fest) der Textur-Wiederholungen in enger zeitlicher und räumlicher Nähe vorkommen, würde eine globale Mustererkennung außer einem riesigen Overhead nichts bringen.

aths

2013-01-31, 00:42:34

Die Sonnenblume wäre bei starker "traditioneller" Kompression garnicht zu sehen. Das findet der regisseur sicher besonders toll.
Hast du eine Beispielrechnung für die Datenrate?

Nein. Die Muster werden durch Algorithmen beschrieben. Das ist ein gängiger Ansatz und Zip unterstützt z.B. mehrere Hundert Megabyte große Bibliotheken wenn man es darauf anlegt. Zip ist demnach also auch keine Komprimierung?

Das Grundprinzip ist sehr ähnlich. Ersetze etwas vorhandenes durch etwas künstlich generiertes das annähernd passt.

Die Verlaufsmuster sind genau das was Du an dem Mustererkennungsansatz auszusetzen hast: sie Verlagern einen Teil des Contents in den Decoder.
Weiter vorne schreibst du, dass du sowas im Studium gehabt hättest und man nicht alles erklären müsste. Hier müsste ich aber eine Reihe erklären. Zwar ist das was du schreibst nicht an sich falsch, aber passt nicht zum Kontext. Es stützt auch nicht deinen Vorschlag, wie du Muster erkennen willst und wie du damit die Bitrate senken willst.

Die Zip-Methode basiert auf dem Wörterbuchverfahren, welches oft durch Entropiekodierung noch optimiert wird. Entropiekodierung ist auch in vielen Videokomprimierungsverfahren zumindest optional vorgesehen. Die Wörterbuchmethode von Zip hat nichts mit der Objekterkennung zu tun wie sie dir für Videos vorschwebt.

Das Beispiel mit der Audiokomprimierung hat ebenfalls nichts mit der Objekterkennung zu tun. Man kann Rausch-Typen mit wenigen Parametern beschreiben (Spektrum, Hüllkurve) was jedoch auf einen Wasserfall oder eine Wiese mit Sonnenblumen nicht zutrifft. Die sind wesentlich komplexer.

Einige Verlaufsmuster, wie sie übrigens auch in DX11-Texturkomprimierung BC7 zum Tragen kommt (die Muster heißen dort "partition table") sind ebenfalls qualitativ nicht mit Wasserfällen oder Sonnenblumen zu vergleichen.

Das ist doch völlig belanglos wenn es um die Kompression geht. Dann benötigt die Decoderdatenbank eben mehrere Hundert MB. Wenn sich dadurch im Schnitt die Datenrate halbieren lässt, ist der Vorteil enorm. Man könnte diese Datenbank sogar dynamisch aufbauen und am Anfang des Films mitschicken lassen oder auch dynamisch Aufbauen, genau wie es bei ZIP getan wird.Eine Datenbank mitzuschicken wird doch bei traditioneller Komprimierung bereits gemacht. Bei Zip ist es das Wörterbuch, bei üblicher Videokomprimierung sind es I-Frames (oder Teile eines I-Frames.)