x264 Kompatiblität mit Standalone Playern

Zitat von Selur

Quelle: http://lassaadjemai.unblog.fr/files/2010/05/h264transform1.pdf

Hab kurz reingeschaut ... obwohl ich das meiste nicht verstehe, ist der ganze encoding prozess ja eigentlich nur ein packen und abrunden und durch die ganzen "tricks drumherum" werden die Verluste dann durch ergänzen von "bitrate-sparenderen" Psychotricks wieder ausgeglichen ... grins ... aber anders geht halt nicht, wenn man nicht für jeden Film eine neue Festplatte kaufen will

Apropos Psychotricks ... ich hätte da mal eine Frage an die leuz mit den großen HD-Fernsehern ... bis vor ein paar Tagen hatte ich noch gedacht, das dieses Graining in HD-Filmen einfach nur eine Nachlässigkeit der Postproduction wäre. Bis ich dann hier mehrmals gelesen habe, das dies ein gängiges Stilmittel ist.
Wenn ich sowas herausfiltere, wirkt der Film auf den HD-Teilen dann unnatürlich?

Zitat von LigH

Wenn man von den klassischen Begriffen der Shannonschen Informationstheorie ausgeht, dann wäre die verlustlose Komprimierbarkeit ein Resultat der Entropie. Aber ob die sich auch auf psychologisch optimierte verlustbehaftete Verfahren erweitern lässt, da bin ich überfragt, das soll ein theoretischer Informatiker klären.

Viel Interessanter als ein velustbehafteter Codec wäre einer bei dem man durch Objekttrennung, Objekterkennung, das speichern des Kamerapfades und diversen "modifiern" ein komplettes Video in seine Bestandteile zerlegt, die fehlenden Bereiche extrapoliert und am ende einen begehbaren Film "kompiliert" ... das wird irgendwann kommen ... Holodeck ick hör dir trapsen

Zitat von Goldwingfahrer

...links...

Danke für die Artikel ... ich hab das Zeugs nämlich bisher immer rausgefiltert ... kostet Bitrate

Allerdings ... kann man das wohl nicht so generell sagen ... wenn ich überlege, würde "300" ohne die Matschepampe wahrscheinlich zu steril wirken ... mhmmm ... tut das in den Augen weh, wenn man vor einem großen HD-TV sitzt und ein bischen graining (wie z.B. in Troja) zu sehen ist?

Bei aufgezeichneten 3D-Filmen ist das ja langweilig ... die Herausforderung aus 2D-Material einen echten 3D-Film zu berechnen ist viel Interessanter

Achso ... kleiner Zwischenstand ... ist schon merkwürdig, wie sich x264 verhält ... bei meinem capture hab ich folgende presets gefunden, die nahezu identische Ergebnisse wie die Referenz (CRF18) ergeben:

1080p bei crf24 slower
720p bei crf21 slower
PAL bei crf21 slower ist schlechter
PAL bei crf20 slower ist besser

Die beiden Ergebnisse bei PAL finde ich merkwürdig ... ich hatte erwartet, das bei PAL die 720er Settings oder sogar noch höhere verwendet werden können.
Ich muss das nochmal mit normalem Filmmaterial vergleichen. Vielleicht ist das eine Besonderheit bei Gamecaptures.

Meine Parameterliste macht übrigens leicht bessere Ergebnisse, als crf18 medium ... grübel ... an welchem/n Parameter(n) das wohl liegt ... ich denke, ich werde auch mal ein oder mehrere Parameter mit den slower-varianten kombinieren und testen.

Du hast nicht genug Fantasie. Hast du mal überlegt, wie du TV guckst? Und hast du dich schonmal gefragt, warum Kinder erst ab einem bestimmten Alter TV gucken "können"? Das muss das Gehirn nämlich erstmal lernen.

Es gibt übrigens schon länger solche Ansätze, die nichts mit Schwachsinn zutun haben. Ich rede hier auch nicht von Echtzeit-Transcoding, was ich beim Autofahren ja bräuchte.
Achso ... da du es angesprochen hast ... frag mal einen Einäugigen, wie der Auto fährt ... meinst du, der würde Entfernungen nicht abschätzen, oder Objekte auf der Straße von denen am Straßenrand, oder sicht bewegende Objekte von stehenden Objekten (die sich MIT dem Straßenrand auf ihn zu bewegen) unterscheiden können?

Aber bleibt ruhig bei deiner "Das kann ich mir nicht vorstellen, also geht das nicht" Einstellung.

Hier mal was für den Horizont:

http://kantaratv.de/bluenote/flow.php?id=322

http://www.tvbeurope.com/main-content/f…sed-video-codec

Gruß
Thom

Zitat von Selur

nette Idee wie man sieht ist es mit der Umsetzung seit 2005 nicht geklappt

Hab auch nie behauptet, das sowas in 5 oder 10 Jahren Marktreif ist.

Ich würde das auch noch viel weiter treiben ... aber der Ansatz, so ein Bild in Meshes und Texturen zu zerlegen ist schonmal nicht übel.

Mann könnte zur Finanzierung des gesamten Projektes auch recht lukrative Zwischenprodukte auf den Markt schmeissen. Leider reicht für sowas die Freizeit nicht aus, aber wenn ich morgen im Lotto gewinnen würde, dann würde ich mich mit ein paar guten Informatikern und Mathematikern an sowas heranwagen.

Zitat von LigH

...nur einen Blickwinkel hat ...

Ja, deshalb hab ich auch "lernen" gesagt ... ich würde es generell in Bibliotheken/Datenbanken ablegen und "wiederfinden" lassen.
Außerdem könnte man es auch später manuell "selektieren" und/oder ergänzen.

Oh mann ... wie die Zeit vergeht ... die sind da schon seit längerem dran ... sowas hier hab ich mir 2003 mal ansatzweise ausgedacht ... naja ... vielleicht nicht ganz so detailliert

https://localhost/www.medien.ifi…MPEG-7_Form.pdf

heul ... und ich dachte, ich wäre der einzige verrückte.

Ohje ... ich hab meinen Kompass für Qualitätsempfinden scheinbar durch das ganze rumgefummel mit HD-Material neu kalibriert ... ich seh bei SD-DVDs nur noch rauschen und Makroblöcke ... heul ... sind die alle so schmutzig oder gibts da auch irgendwas "klares" mit viel Bewegung und komplexeren Strukturen?

Hab mein bisheriges SD-Ref-Video (Lost in Space) jetzt mal durchexorziert ... ich werde mit --preset slower ohne weiteren Parameter-Schnickschnack arbeiten.
Tune Film und Grain hab ich mit dem Video getestet ... führt beides zu schlechteren Ergebnissen ... hauptsächlich entstehen Makroblöcke und die hasse ich am meisten.

Außerdem hab ich bei meinen frühren tests mit dem Ding die typischen Anfängerfehler gemacht ... keine Ahnung warum ... z.B. hab ich:

a) Source ist anamorph ... hatte ich via DGSource() resized ... der macht das scheinbar über biliniear ... schlechtes Ergebnis
b) Resize und Cropping hatte ich "übern Daumen" via "sichtvergleich" ermittelt ... war zwar ohne Treppen, aber das Bild mit den exakten Werten ist unschlagbar
c) Deblock() hatt ich nie in Erwägung gezogen, weil ich garnicht auf die Idee gekommen wäre das im Source schon (z.B. heftige) Makroblöcke kodiert sind

nachdem ich das jetzt folgendermaßen angepasst habe:

LoadPlugin("C:\Tools\Windows\DGDecNV\DGDecodeNV.dll")
LoadPlugin("C:\Program Files\AviSynth\plugins.manual\deblock.dll")
DGSource("d:\Storage\Work\Lost in Space.dgi")
Crop(0,70,-0,-74)
Deblock()
Lanczos4Resize(1024,430)

... und wie erwähnt mit --preset slower und --crf 18 kodiere, erhalte ich ein um längen besseres Ergebnis als vorher, ohne das die Datei wesentlich größer wird.
Einzig die Encoding-Zeit ist auf das 3fache angestiegen ... aber damit kann ich gut leben.

Fazit bisher:

IHR HATTET RECHT!

So ... jetzt hab ichs gesagt

Und ich hab mir die Zeit genommen, die Sets von medium, slow und slower miteinander zu vergleichen ... und schonwieder muss ich sagen:

STIMMT, DIE X264-ENTWICKLER WISSEN WAS SIE TUN!

Schraub ich nur geringfügig an den Einzelwerten, dann geht entweder die Quali runter oder die Bitrate hoch.

Der Sinn von tune Film/Grain erschließt sich mir momentan nicht ... wenn ich Film nehme, bekomme ich mehr Artefakte und wenn ich Grain nehme, siehts künstlich aus.

Ich muss jetzt erstmal meine Platten aufräumen, sonst weiß ich garnicht, wo ich den Troja hinkopieren soll

Danach gehts weiter mit den CRF-Tests ... wollt ihr wissen, wie's ausgeht, oder langweile ich euch schon?

Gruß
Thom

Autsch ... Troja encoded mit 1.49fps ... das dauert dann über 55 Stunden ... ich bau jetzt erstmal nen neuen Server

CRF15 dürfte bei 1080p eine verdammt große Datei auspucken ... mhmmm ...

Da hätt ich gleich die nächste Frage. Lohnt sich das, mit 1080p zu encoden oder ist der Unterschied zu 720p auf großen TVs wirklich so gravierend?

Auf meinem 17" Notebook sieht das nämlich nicht "soo" viel besser aus.