Beiträge von Brother John

Die offiziellen Szenerules für eigene Encodings herzunehmen ist ja nicht illegal. Es ist auch keine besonders gute Idee, aber das ist ein anderes Problem.

Zitat von Chetwood

Ich hab meine alten CDs mit ~256 kbit VBR gerippt und werde das nicht wiederholen, da für mich Transparenz erreicht ist. Mit neuen encodes würde ich nur unwesentlich mehr Platz sparen

Genau mit der Transparenz hat Xvid arge Probleme. Und ein paar Skripte & Co. aufzuheben, kostet ja nix. Vielleicht schließe ich auch nur mal wieder von mir auf andere. Bei Serien schneide ich z.B. immer das »Was bisher geschah« am Folgenanfang raus. Das nervt dermaßen, wenn man mehrere Folgen hintereinander schaut. D.h. ich habe eine ganze Liste an Schnittmarken und ähnlichem manuell zusammengefieseltem Geraffel. Das irgendwann nochmal zu machen, wäre unnötig aufwändig.

Imo klingt das gerade ein Stück schlimmer als es wirklich ist. Ich hab damals viel CQ 2 mit der Matrix EQM VR3HR (oder Heinis Mod davon) gemacht. QPel hilft außerdem, zumindest den Eindruck von Detailreichtum zu erzeugen. Klar: Grob 2,5–3 GB pro Film muss man ansetzen, das ist sicher nicht die Ausgeburt an Effizienz und insgesamt immer eine Größenordnung schlechter als x264. Aber so kriegt man schon recht ordentliche Ergebnisse.

Wie standalone-kompatibel das ist, kann ich nicht beurteilen. Gerade bei den älteren Geräten ist ja jeder Player irgendwie anders kastriert.

Chetwood, ein Tipp noch, den ich schmerzlich erfahren habe: Wenn du jetzt Serien mit Xvid baust, heb dir AviSynth-Skripte, Frontend-Projekte und ähnliches Drumherum auf. Falls du’s später mit einem modernen Encoder nochmal baust, erleichtert es die Sache ungemein, wenn du das ganze Vorab-Gefiesel nicht machen musst.

Da die »Szene« keinerlei technische Autorität in Sachen Encoding hat (auf Deutsch: denn sie wissen (oft) nicht, was sie tun), willst nicht wirklich vergleichbare Qualität haben. Kurze Antwort: Nimm x264. Längere Antwort: zu meinen alten Empfehlungen aus dem Encodingwissen stehe ich weiterhin. Allerdings nur, solange es wirklich unbedingt absolut MPEG-4 ASP sein muss und was anderes nicht funktioniert. Ansonsten siehe kurze Antwort.

Würde mich wundern, wenn es in absehbarer Zeit StaxRip in anderen Sprachen geben würde. Das ist ja nicht ganz unaufwändig. Es braucht die technische Unterstüzung durch die Programmierumgebung (weil selbst will man nicht wirklich ein Framework für die Lokalisierung schreiben) und fähige Übersetzer, die kontinuierlich aktualisieren. Sieht man an vielen Open-Source-Projekten, wo die Übersetzung qualitativ vielleicht gerade mal Hobbyistenansprüchen genügt und ein wilder Sprachmischmasch entsteht, weil die Übersetzung nur sporadisch wenn überhaupt aktualisiert wird.

Das Problem mit übersetzten Fachbegriffen ist nochmal ne ganz eigene Baustelle. Gerade bei Spezialanwendungen wie StaxRip ist da Englisch + deutsche Doku oft der bessere Weg.

Oder nimm die 32bit r1995. Auf Anhieb wüsste ich nichts, was da Probleme machen sollte.

StaxRip beschwert sich immer, wenn er nicht exakt die erwartete Versionsnummer findet. Das muss nicht zwingend heißen, dass nichts mehr funktioniert. Schon probiert?

Für 64bit x264 brauchst du aber auch ein 64bit-AviSynth incl. aller verwendet Plugins in 64bit. Das dürfte die größere Schwierigkeit sein

Ich glaube, hier können wir dann zumachen...

Muss auch. Matroska kennt nämlich aus technischer Sicht gar keine Seitenverhältnisse. Es gibt nur Einträge für »display width« und »display height«, womit laut Spec sogar tatsächlich die ideale Abspielauflösung gemeint ist. In der Praxis nutzt jeder die beiden Felder, um das DAR anzugeben.

Zitat von Selur

zu b.: (hab was im Hinterkopf:) war es nicht so, dass mkvmerge beim Muxen den PAR Wert aus dem Stream entfernt und ihm beim Extrahieren wieder einfügt?

Das war mal einige Zeit so, ist aber jetzt auch schon länger wieder anders. Aktuelle MKVMerge lassen das Stream-PAR wie es ist.

Die Zeit ist genau das Problem. Technisch ist’s ja nicht besonders aufwändig. Camtasia habe ich da. Eine Uraltversion, die es mal als Aktion kostenlos gab. Aber funktioniert einwandfrei. Dazu eine Titel- und Creditsseite drangepappt und fertig. Aber Inhalt und das Drehbuch dazu, das ist so viel aufwändiger als ein normales Texttutorial. Und ich will’s dann natürlich wie immer besonders perfekt haben.

Es ist ja nun doch ein Stück her, dass sich am Encodingwissen was getan hat. Und die PDF war sowieso noch viel staubiger. Ich glaube, ein kleines bisschen Leichengeruch hat sich schon breit gemacht. Sowas ist natürlich kein Zustand!

Update vom 26.11.2010

• Die PDF ist wieder aktuell! Außerdem hat sie ein weiterentwickeltes Layout mit freien Schriften (DejaVu und Computer Modern Unicode) erhalten.
• Umstrukturierung: Der Praxisteil ist endlich klar und deutlich in einen Abschnitt Encoding in Handarbeit und einen Abschnitt Encoding mit StaxRip aufgeteilt. Dabei ist auch ein kurzes Kapitel zum AviSynth-Skripting mit AvsP abgefallen. Den Spezialteil habe ich aufgelöst und die Kapitel in den Praxis- und Hintergrundteil integriert.

War ein ganz schönes Mammutprojekt, die PDF rundzuerneuern. Und OpenOffice 3.2 ist offensichtlich mal wieder eine der verbuggteren Versionen. Aber die Technik darf natürlich nicht gewinnen.

Zukunftspläne? Hab ich. Auf jeden Fall braucht das StaxRip-Kapitel einen Abgleich mit der aktuellen StaxRip-Version. Und dann treibt mich die Idee mit den Videotutorials um. Könnte ein AviSynth-für-Einsteiger-Video werden, evtl. auch mehrere. Das Projekt steckt aber noch in frühen Kinderschuhen, und das Fotografie-Hobby stiehlt den bewegten Bildern ganz schön Zeit. Wahnsinnsgeschwindigkeit wird das Encodingwissen also sicher nicht aufnehmen. Aber von tot kann auch keine Rede sein.

Laut Log passt die decodierte WAV noch: 24min und mono. Beim Encoding mit BeSweet scheint es dann schief zu gehen. BeSweet ist halt einfach nicht für Mono gemacht. Du kannst:

a) Die WAV manuell mit dem Neroencoder encodieren, BeSweet komplett umgehen und die fertige Spur dann so wie sie ist in StaxRip einbinden.

b) Bei Stereo bleiben. Die Quelle ist Mono, die Stereodatei, die daraus entsteht, hat also zwei identische Kanäle. D.h. beim Encoding brauchst du für »Stereo« kaum mehr Bitrate als für Mono.

BeSweet und Mono ist schon immer so eine Sache. Das geht eher schlecht als recht. StaxRip erzeugt eine LOG-Datei, die müsstest du im Ordner mit dem Video finden. Poste die doch mal und dazu den BeSweet-Befehl, mit den es funktioniert.

Praktisch und halbwegs universell verwendbar gilt weiterhin: Menüs nur mit Video-DVD bzw. -BluRay. Matroska und MP4 haben Menüs zwar in den Specs, aber keine funktionierende Implementierung.

LigH
VOB2MKV kann auch Menüs mitnehmen? *skeptisch* Das wäre ja ein echter Fortschritt. Ist dann nur die Frage: Womit das Zeug abspielen?

Mit AviSynth MT basteln ist schon die richtige Methode, weil AviSynth eben eigentlich nicht multithreaded ist. Deswegen kann v.a. MTMode() auch gerne mal abstürzen. Du kannst dann noch gezielter mit MT() rumspielen und immer hoffen, dass sich nichts verheddert und abstürzt. Zuverlässiger geht AviSynth mit mehreren Kernen leider nicht.

Oft hilft es auch schon, mit MTMode(2,<Anzahl threads>) die Threadanzahl zu senken. Die steht iirc standardmäßig auf Anzahl der CPU-Kerne. Ist oft gar nicht nötig für volle Auslastung, aber je mehr Threads desto wahrscheinlicher Probleme.

Puh, naja, bei der Quelle darfst du einfach nicht mehr allzu viel erwarten. Schau dir das Quellbild mal genau an, das ist vollständig kaputt, besteht v.a. im Hintergrund praktisch ausschließlich aus Blockartefakten. Die Idee mit dem Deblocking in AviSynth halte ich für am sinnvollsten. Und dann ein normales Standardencoding à la --preset slow --tune film -- crf 19-20 o.ä.

Ich mag ja Didées Deblock_QED(). Aber bei solchen schweren Fällen musst du einfach ein bisschen rumtesten und durchaus mit aggressiven Einstellungen anfangen. Ein bisschen sanft streicheln bringt in dem Fall eher nix. Und aufpassen: Deblocking immer ganz am Anfang vor Cropping und Resizing anwenden.
(Das alles natürlich soweit man den Film an einem Einzelbild überhaupt beurteilen kann.)

Zitat von Salviro

Also weiß mein Mediaplayer selber nicht ob es sich um ITU-R BT.601 handelt und stellt einfach mal alles in 1024x576 dar?Wie kann denn ein DVD Player den richtigen Standard erkennen

Gar nicht. Es steht nirgendwo auf der DVD und ist leider auch nicht ausdrücklich genormt. Deswegen hast du:

Zitat von Salviro

Also weiß mein Mediaplayer selber nicht ob es sich um ITU-R BT.601 handelt und stellt einfach mal alles in 1024x576 dar?

ganz richtig erkannt.

Es ist auf der DVD eben leider nirgendwo vermerkt, welche PAR-Variante in der Produktion verwendet wurde. Deswegen kannst du nur auf gut Glück raten, welchen PAR du beim Konvertieren brauchst. Manchmal wirst du falsch liegen und manchmal richtig. Zum Glück ist der Unterschied nicht besonders der Rede wert. Ich denke nicht, dass es sich lohnt, deswegen alle Filme neu zu muxen.

Zitat

Das macht ja Staxrip schon automatisch, wenn ich das richtig verstanden habe

PAR eintragen ja. Aber den Resizer musst du selbst abschalten.

Zitat

Mit welchen Einschränkungen hätte ich zu rechnen? [...] Ich halte mir da gerne immer alles offen^^

Immer alles geht nicht, schon gar nicht in die Zukunft gedacht. HQ-Archiv und mobil fürs Handy kriegst du sowieso nicht auf einen Nenner. Als Kompromiss könnten BluRay-kompatible Einstellungen evtl. ganz brauchbar sein. Aber ich beschäftige mich (auch aus dem Grund) nicht mit Hardware-Wiedergabe …

Zitat

Mich würde trotzdem noch interessieren ob das Heranzoomen schlechter wäre als eine kleinere Auflösung?

Tendenziell ist vergrößern unkritischer als verkleinern – aber Resizing ist nie verlustlos. Bei deinen Größenordnungen ist es wahrscheinlich egal.

Möglichkeit 1:
Mod16 ist für x264 unnötig. AviSynth erzwingt mod4×mod2, mehr muss auch nicht sein. Mal von den diversen Einschränkungen bei der Hardware-Wiedergabe abgesehen.

Möglichkeit 2 (qualitativ besser):
Nur croppen, aufs Resizing komplett verzichten und einfach den passenden PAR sestzen (mit der --sar-Option). Tabelle mit den nötigen Werten: http://encodingwissen.de/video/anamorph-quelle.html#par

Edit:
Ich bin jetzt einfach mal frech von x264 ausgegangen …?