Schwieriges Thema. Eine gewisse "Vorbildung" ist leider unbedingt von Nöten:
Display Aspect Ratio und Pixel Aspect Ration (--sar entspricht PAR) sind zwei verschiedene Dinge.
Bei Unklarheiten gern nochmals fragen.
Das Videobild habe ich gelesen bevor ich gepostet habe, finde es auch kompliziert 
Wenn ich --sar 16:11 nicht benutze, behalte ich doch das
originale Bild bei oder?
Mein Quellmaterial war ja 16:9 mit schwarzen Balken, wenn es 16:9 ohne schwarze Balken sein soll geht das doch nur mit Qualitätsverlust oder Verzerrungen oder?
Leider fehlt mir die Möglichkeit für wirklich aussagekräftige Tests, so ein Röhrenfernseher verzeiht einem fast alles denke ich
Welchen Nachteil geht man ein wenn man --sar 16:11 weglässt?
Welchen Vorteil hat man wenn man es benutzt?
Gruß
Parti
--sar und Balken haben nichts miteinander zu tun. Hast du ein Resizing drin und wenn ja, auf welche Auflösung? Ist die Quelle eine DVD?
wenn cropping aber kein resizing, dann --sar 16:11 für anamporphes PAL-Material...
Das, was kurt sagt. In dem Fall macht --sar nicht nur Sinn, sondern ist sogar absolut notwendig für die richtige Wiedergabe.
Ja danke,
hatte jetzt auch zufällig die Möglichkeit das Ganze auf einem Beamer zu testen,
--sar 16:11 muss sein, sonst sieht alles lang und schmal aus 
Gruß
Parti
Ob du einen sar-Wer schon in der x264-CL angibst oder nicht ist aber eigentlich egal, wenns das danach in einen MKV-Container wandert. Wirds vorher gesetzt, dann steht das Flag im Bitstream, mkvmerge erkennt das, setzt das Flag im Bitstream zurück und schreibt das dann im Container wieder rein. Also kannste "sar" im Grunde auch weglassen und die korrigierte Auflösung später in mkvmerge angeben. Kommt aufs gleiche raus.
greets
LTJ
Ob du einen sar-Wer schon in der x264-CL angibst oder nicht ist aber eigentlich egal, wenns das danach in einen MKV-Container wandert. Wirds vorher gesetzt, dann steht das Flag im Bitstream, mkvmerge erkennt das, setzt das Flag im Bitstream zurück und schreibt das dann im Container wieder rein. Also kannste "sar" im Grunde auch weglassen und die korrigierte Auflösung später in mkvmerge angeben. Kommt aufs gleiche raus.
greets
LTJ
Nein, eigentlich nicht. Soviel ich weiß, wird das PAR (bzw. SAR) direkt im RAW-Stream gespeichert, ist also relativ unveränderlich sobald einmal encodiert wurde.
Mkv kann nur einen Containerflag setzen.
Belegen kann ich das dadurch, als dass ich mit dem Zoomplayer beide Werte auslesen kann. So hab ich für diverse alte Encodes 2 Seitenverhältnisse, weil ich damals noch nicht mit dem PAR gearbeitet habe.
Nein, eigentlich nicht. Soviel ich weiß, wird das PAR (bzw. SAR) direkt im RAW-Stream gespeichert, ist also relativ unveränderlich sobald einmal encodiert wurde.
Unveränderlich ist garnichts 
Mosu schreibt das auch selbst (Klick) oder hat sich das mittlerweile wieder geändert?
Mkv kann nur einen Containerflag setzen.
Und das ist das einzige was nach dem muxen gesetzt ist.
Belegen kann ich das dadurch, als dass ich mit dem Zoomplayer beide Werte auslesen kann. So hab ich für diverse alte Encodes 2 Seitenverhältnisse, weil ich damals noch nicht mit dem PAR gearbeitet habe.
Wäre ja ein Indiz für eine Änderung in mmg.
Edit//
Du kannst ja mal folgendes testen:
Dein MKV in dem beide Flags gesetzt sind extrahieren (beim demuxen wird der Bitstream nicht verändert)
h264_parse über den RAW-Stream laufen lassen und in der SPS-NAL den Eintrag: aspect_ratio_info_present_flag suchen.
Steht der auf 1 war vorher tatsächlich beides gesetzt.
Dann die Quell-mkv einfach mal remuxen und das Spielchen wiederholen.
Steht das Flag dann auf 0 dann wirds halt beim muxen entfernt.
Vielleicht war das in den älteren Versionen von mmg ja noch nicht so, oder du hast vielleicht auch immer mit "--engage keep_bitstream_ar_info" gemuxt (?)
greets
LTJ
Unveränderlich ist garnichts
Mosu schreibt das auch selbst (Klick) oder hat sich das mittlerweile wieder geändert?
Äh, who the fuck is Mosu? :cool:
Entwickler oder wie, ich hab den Namen noch nie gehört.
Wäre ja ein Indiz für eine Änderung in mmg.
Hm, nein. Eigentlich ist das ein Indiz dafür, dass mmg eben den .mkv Containerflag setzt, aber den h264-Internen nicht abändert. Sonst hätte ich nicht 2 Seitenverhältnisse
Aber ich werden das...
Edit//
Du kannst ja mal folgendes testen:
Dein MKV in dem beide Flags gesetzt sind extrahieren (beim demuxen wird der Bitstream nicht verändert)
h264_parse über den RAW-Stream laufen lassen und in der SPS-NAL den Eintrag: aspect_ratio_info_present_flag suchen.
Steht der auf 1 war vorher tatsächlich beides gesetzt.
Dann die Quell-mkv einfach mal remuxen und das Spielchen wiederholen.
Steht das Flag dann auf 0 dann wirds halt beim muxen entfernt.Vielleicht war das in den älteren Versionen von mmg ja noch nicht so, oder du hast vielleicht auch immer mit --engage "--keep_bitstream_ar_info" gemuxt (?)
greets
LTJ
...mal probieren, wenn ich wieder Zeit hab.
Mosu oder Moritz Bunkus ist der Entwickler von mkvtoolnix.
Hm, nein. Eigentlich ist das ein Indiz dafür, dass mmg eben den .mkv Containerflag setzt, aber den h264-Internen nicht abändert. Sonst hätte ich nicht 2 Seitenverhältnisse
Es wäre ein Indiz dafür das es wieder rückgängig gemacht wurde.
greets
LTJ
Ob wieder entfernt oder nicht, sinnvoller ist es trotzdem, --sar zu verwenden, denn dabei muss man nur den passenden PAR-Wert einsetzen. Die Auflösung dagegen muss man ausrechnen, dafür braucht man auch das PAR, muss Cropping berücksichtigen – viel zu viel Aufwand und potenzielle Fehlerquellen.
Ich würde übrigens den Schalter setzen, dass das Stream-Flag nicht entfernt wird, da imo das AR ein wichtiger Bestandteil des Videostreams ist. Und da sollte er auch gespeichert sein.
Mosu oder Moritz Bunkus ist der Entwickler von mkvtoolnix.
Es wäre ein Indiz dafür das es wieder rückgängig gemacht wurde.
greets
LTJ
Du hast recht. Allerdings nicht mit den Schlüssen, die du aus den Indizien ziehst :p
Ich kann bei Zoomplayer sowohl den Aspect Ratio:Source als auch die Aspect Ratio:Derived auswählen.
Source richtet sich dabei aber anscheinend nach der Auflösung, Derived nach dem Containerflag. Aber auch das scheint etwas willkürlich zu sein, abhängig von der verwendeten mmg-Version und x264-Version.
Und tatsächlich habe ich diverse Encodes auf der Platte, bei denen mit der Option Source das SAR von x264 ausgelesen wird, mit Derived ein willkürlicher Wert, den ich bei mmg einstellen kann.
Aber im Grunde genommen ist das total egal, sofern am Ende das richtige bei rauskommt.
Ob wieder entfernt oder nicht, sinnvoller ist es trotzdem, --sar zu verwenden, denn dabei muss man nur den passenden PAR-Wert einsetzen. Die Auflösung dagegen muss man ausrechnen, dafür braucht man auch das PAR, muss Cropping berücksichtigen – viel zu viel Aufwand und potenzielle Fehlerquellen.
Naja so wahnsinnig aufwändig ist das ja nun auch nicht, aber bequemer alle male.
Ich würde übrigens den Schalter setzen, dass das Stream-Flag nicht entfernt wird, da imo das AR ein wichtiger Bestandteil des Videostreams ist. Und da sollte er auch gespeichert sein.
Hatte dir die Antwort von mosu damals als Begründung nicht gereicht, "--engage keep_bitstream_ar_info" nicht zu benutzen?(Klick #49/#50)
Ich frage nur aus reiner Neugier. Was für Gründe gibts denn das Flag im Stream stehen zu lassen? Den RAW-Stream später irgendwann mal weiterverarbeiten zu wollen, wäre der einzige Grund der mir einleuchtet und selbst wenn das Flag nicht im Bitstream steht, kanns jederzeit aus den Container-Informationen ausgelesen werden, wenn es benötigt würde.
Für mich persönlich gehört zu einem Video auch Audio und ggf. Untertitel - oder geht der Trend mittlerweile woanders hin?:zunge: - und das geht für vollen Genuß nur zusammen in nem Container, da ist es mir ehrlich gesagt recht egal ob meine DVB-Encodes nen Flag im Bitstream haben oder nicht, solange der Decoder damit zurechtkommt. Einige Decoder/Demuxer (ich habs selber allerdings noch nicht erlebt) scheinen aber damit Probleme zu haben, daher lass ich das Flag sicherheitshalber nur im Container setzen.
greets
LTJ
Wie ist es denn nun richtig?
Richtig gibt es da nicht. Zur ordentlichen Wiedergabe kommt es halt darauf an, was der Player&Co beachtet, ob er sich an die Flags im Container oder im Stream hält.
Wenn man Container&Stream Flags unterschiedlich einstellt kann man je nach Player eine andere Darstellung haben.
Cu Selur
Ps.: Brother John hat da mal ein paar Tests gemacht gehabt soweit ich mich entsinne,...
Kann es sein, dass ich --sar so einmal direkt im Bitstream und dann ein 2tes mal in den Container schreibe??
Nochmal ganz knapp zusammengefasst:
Gründe das Flag nur im Container setzen zu lassen
Gründe das Flag in Container und Bitstream setzen zu lassen
greets
LTJ
Hier: http://brother-john.net/ar-vergleich.html
Was nun »richtig« ist, das ist Ansichtssache. Ich bin der Meinung, die AR-Info ist ein essentieller Bestandteil des Videos, weil sie für eine korrekte Wiedergabe zwingend notwendig ist. Deswegen sollte die Info so eng mit dem eigentlichen Videostream verknüpft sein, wie möglich. Also Prioriät fürs Streamflag. Mosu sagt, Streamflag ist lästiger zu verändern, deswegen Priorität fürs Containerflag.
Für das, was ich mit Video anstelle, zieht Mosus Argument nicht. Ich verarbeite nicht weiter, Matroska ist das Ende der Kette. Wer sich nicht entscheiden kann, sollte sich fragen: In welchen Situationen könnte ich das AR-Flag ändern mögen (das Flag, wohlgemerkt, nicht das Bild selbst), ohne dass sowieso ein komplette Re-Encoding notwendig ist.
Ich nutze übrigens immer beide Flags.
Bumsfalara
Hattest du vielleicht als Quellstreams fürs Muxing weder RAW AVC noch MP4 AVC? Nur in den beiden Fällen tastet MKVMerge das Stream-AR an.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
