StaxRip Encoding-Frontend (Diskussion)

Hallo Leute,

ich habe eine Frage zur Berechnung der Zielauflösung.

Bei einer DVD-Recorder-Aufnahme in PAL 4:3 / 704x576 schlägt StaxRip eine in die Breite gezogene Zielauflösung von 640x464 Pixel vor. Laut Brother Johns Encodingwissen sollte aber ziemlich genau eine 4:3 Auflösung herauskommen.

Habe ich irgend eine Einstellung übersehen? Oder Fehler im System?

Gordian Knot kommt im etwa auf die gewünschte Zielauflösung von 640x480.

MeGui schlägt allerdings auch die krumme Auflösung von 640x464 vor. Wird hier vielleicht die nach der gleichen Formel gerechnet?

Gruß

Exakt gerechnet nach ITU-R BT.601 und unter der Voraussetzung kein Cropping. (MPEG-4-PAR 12/11 führt zum gleichen Endergebnis.)

PAL 4:3 704×576 hat ein PAR von 128/117, d.h.:
704 * 128/117 = 770,189
und damit eine »quadratische« Auflösung von 770,189×576.

Auf 640er Breite skaliert ergibt sich vertikal:
(640/(704*128/117)) * 576 = 478,63
und damit 640×478,63

Beachtet man mod16, ist die nächste passende Zielauflösung 640×480. Das gleiche mit generischem PAR (16/15) durchexerziert ergibt 640×490,90 und incl. mod16 640×496.

Ist bei dir in den StaxRip-Projektoptionen "Use ITU-R" aktiviert? Das brauchst du, um auf 640×480 zu kommen. Aber auch wenn das nicht der Fall ist, rechnen sowohl StaxRip als auch MeGUI falsch.

Ein bisschen weiterspekuliert dürfte der Fehler daher kommen, dass die modernen Encoding-Frontends versuchen, das Seitenverhältnis des Quellmaterials immer automatisch zu bestimmen und dafür gerne das DAR nehmen. Man sieht das in MeGUIs Fall, das eine Quell-DAR von 1,36 annimmt. Das stimmt zwar für 720×576, aber nicht mehr für 704×576 – obwohl beide Auflösungen das gleiche PAR haben. Der Fall ist imo ein gutes Beispiel dafür, warum man sich aufs PAR verlassen und nur im absoluten Notfall das DAR nehmen sollte.

Zitat von Brother John

Ist bei dir in den StaxRip-Projektoptionen "Use ITU-R" aktiviert? Das brauchst du, um auf 640×480 zu kommen. Aber auch wenn das nicht der Fall ist, rechnen sowohl StaxRip als auch MeGUI falsch.

Die Option ist aktiviert.

Ist nur ein bißchen dumm, wenn man sich nicht auf die Ergebnisse verlassen kann. Ich bin da auch nur durch Zufall drauf gestoßen, weil ich zufällig nicht gecropt hatte.

Zitat von Brother John

Ein bisschen weiterspekuliert dürfte der Fehler daher kommen, dass die modernen Encoding-Frontends versuchen, das Seitenverhältnis des Quellmaterials immer automatisch zu bestimmen und dafür gerne das DAR nehmen.

Vielleicht sollte das ürsprünglich bei den krummen DVB-Auflösungen, wie 352x576, 480x576, 528x576 und 544x576 helfen :hm:

Wobei bei der 544er Auflösung ja noch ein zusätzlicher Fehler entsteht:
544 * 4/3 = 725

Gruß

Jetzt hats geklappt musste nur den yuv12 filter laden.
Danke für die Hilfe.

Jetzt noch was anderes, wenn ich das File mit Staxrip öffnen zeigt er in Preview falsche Farben an, die natürlich auch beim umwandeln übernommen.

Hier mal die Bilder

Original
[Blockierte Grafik: http://www.bilder-hochladen.net/files/6rpm-k.jpg]

Staxrip
[Blockierte Grafik: http://www.bilder-hochladen.net/files/6rpm-l.jpg]

Weiß jemand wie das weggeht.
Ich weiß net mal wie man den Fehler beschreiben soll.

mfg

josch

spontan sieht es nach einer Farblayerverschiebung aus,... -> eventuell auf eine Auflösung gecroppt die nicht glatt durch 4 teilbar ist? Oder bei einem Filter der einen gewissen Teiler braucht diesen nicht eingehalten?

@stax0711

ich hab immer diesen batch auftrag für alle Files geplant und da ist keine Fehlermeldung gekommen.

Nachdem ich aber die Files mal einfach geladen habe, hat mit Staxrip angegeben dass es einen YUV12 Filter benötigt, den habe ich hinzugefügt und es hat funktioniert.

Selur
danke werde ich mal gucken.

Zitat von stax0711

Teste bitte mal eine neue beta, hoffe dass jetzt alles 100% korrekt funktioniert.

Ja, super. Jetzt funktioniert es richtig. Das sind ja richtig fixe Bug Fixes

Gruß

Mit Convert to RGB hats nicht hingehauen.

Nachh vielem Probieren und fluchen:D:D hab mich mal DirectShowSource genommen.

Tada.

Hamma Tool, fehlt nur noch mein Quadcore

mfg

Josch

Welcher Codec ist eigentlich besser für animierte Serien geeignet? Der aktuelle DivX-Codec (h.263 opt + masking) oder XVid (h263 + Cartoon Mode) ?

Tut sich nicht wirklich was, würde wenn eher zu x264 greifen,...

Für 264 habe ich eine Hardware, divx+xvid kann ich mit DVD-Player und alter XBOX wiedergeben.
Deswegen nun meine Frage, welcher Codec besser damit umgeht. Es soll auch keine Glaubensfrage werden (ich habe eine Lizenz für DivX), sondern einzig und allein ein Vergleich ...

Zitat von MacLeod

Welcher Codec ist eigentlich besser für animierte Serien geeignet? Der aktuelle DivX-Codec (h.263 opt + masking) oder XVid (h263 + Cartoon Mode) ?

Meinst also "Animes"? Der Cartoon Mode ist nich wirklich für Animes geeignet, vielleicht für ältere Cartoons, aber so material hab ich auch nie encoded. Und sonst durch VAQ bei Xvid und den einstellungsmöglichkeiten gefällt mir persönlich Xvid mehr und ich erziehl auch bei geringen Datenraten gute Ergebnisse. Die Ger/Eng Fansub Encoder verwenden z.B. meistens nur Xvid/x264 für ihre Encodes.

Aber die Japanischen Ripper in ihrem Lande verwenden z.B. nur DivX oder ebend x264.

Also kommts drauf an für was du encoden willst, x264 ist der relativ neuste Videocodec, der auch ständig weiterentwickelt wird, damit sollteste auch die besten ergebnisse erziehlen können bei kleinerer Datengröße. Wenn du allerdings für DVD/XBOX encoden willst, sollteste dich mit Xvid/DivX auseinander setzen.

Wie gesagt: Ist egal, je nach Szene wird mal der eine mal der andere etwas schöner aussehen; bei gleicher Größe. Da Du für DVD-Player encoden willst würde ich eher DivX wegen der vorhandenen und funktionierenden vbv-Unterstützung nehmen.

Die im Programm integrierte Downloadmöglichkeit für die "External Applications" funktioniert mit der Version 1.1.0.1 nicht bei "DivX" und "AviSynth". Als Meldung erscheint "Download failed".

Ich habe mir vor zwei Tagen die 1.1.0.1 gezogen und installiert.
Ich finde es schon, dass man beim Resize-Regler keine größere Auflösung als die max Source-Width einstellen. Bei den alten 1.0.x ging das noch ...