Verhältnistreue Kodierung yuy2 (DV-PAL 59:54) in mpeg-2 und x264 (SAR, PAR, DAR)

  • Hallo zusammen,

    ich habe aus digitalisierten Aufnahmen im Format 720x576 (576i) mittels ffmpeg mpg (mpeg2video) und x264 (xlib264) Dateien erstellt.
    Ich habe mich bei x264 an den Bluray-Standard gehalten, mit SAR 12:11 und DAR 15:11 für ein 720x576 interlaced video.
    Dies führt auf dem PC (VLC, ffplay) zu unverzerrten Wiedergaben (runder Teller).

    Wenn ich sie auf einem Mediaplayer (Vu+ Duo2) abspiele, dann funktioniert im Prinzip, aber verzerrt bzw. abgeschnitten.
    Gegenüber 4:3 ist das Bild etwas breiter, aber korrekt, wird aber abgeschnitten (zirka 10 Zeilen oben und unten, zirka 8 rechts und links).
    Außerdem wird beim Abspielen 704x576 angezeigt.

    Wenn Mediaplayer Probleme haben mit SAR 12:11 und DAR 15:11, sind denn dann diese Einstellungen in der Praxis (außer für Blurays) zu empfehlern?
    Welche Alternativen gibt es?

    Gruß
    Highwayman.
    Highwayman.

    2 Mal editiert, zuletzt von Highwayman (2. Januar 2018 um 18:33)

  • Entweder oder.

    Entweder du gibst mit dem SAR an, um welchen Faktor das Video entzerrt werden soll, oder mit dem DAR, auf welches Seitenverhältnis. Speicherst du beide, kann es passieren, dass unterschiedliche Ergebnisse herauskommen, je nach dem ob der Player das Flag im Videostream oder das Flag im Container für wichtiger hält.

    Außerdem sind mündliche Beschreibungen nicht ganz so eindeutig wie z.B. die MediaInfo-Analyse. Schließlich haben unterschiedliche Content- und Container-Formate auch unterschiedliche Möglichkeiten, solche Flags zu speichern.

  • Nun, ich gebe nur den SAR 12:11 an:

    "...\ffmpeg.exe" -i "...\Teller.avi" -map 0:v:0 -map 0:a:0 -frames:v 300 -c:v libx264 -bluray-compat 1 -profile:v high -pix_fmt yuv420p -level 4.1 -preset veryslow -tune film -crf 17 -flags +ilme+ildct+cgop -top 1 -sar 12:11 -slices 4 -r 25 -g 25 -maxrate 40000k -bufsize 30000k -b:a 448000 -ar 48000 -codec:a ac3 -color_primaries "bt470bg" -color_trc gamma28 -colorspace bt470bg "...\TellerSAR_12_11.mp4"

    b1.PNGb2.PNG

    Meiner Meinung nach sind in der Videodatei SAR und DAR richtig gesetzt. Beide werden gebraucht, um das Bild korrekt darzustellen.
    ffplay und VLC machen das auch richtig auf dem PC.

    Im Container habe ich noch keine Angaben gefunden.
    Weder bei mp4 noch bei mkv.

    Mit welchem Tool kann ich das (noch) überprüfen?

    Highwayman.

    5 Mal editiert, zuletzt von Highwayman (2. Januar 2018 um 18:34)

  • Das Quellmaterial liegt als avi (YUY2) im Format DV-PAL 59:54 vor.
    Zu x264 kann ich es verhältnistreu konvertieren (mit genannten Problemen), zu mpeg2video gar nicht.

  • Quelle: 720x576 mit PAR 59:54 nach MP4 PAL 4:3 (12/11)
    59:54 = 1,0925925925925925925925925925926 -> 720*59/54 = 786,66666666666666666666666666667
    12:11 = 1,0909090909090909090909090909091 -> 720*12/11 = 785,45454545454545454545454545454
    wenn man in YUV2 und damit auf mod2 bleiben will würde man zur Fehler Reduktion beide auf 786 entzerren
    Da wir hier anamorph bleiben wollen würde man nicht Resizen sondern einfach den PAR ändern. :)
    Und wenn man mir nicht glauben will einfach PARanoia verwenden.

    Wenn es nach MPEG-2 PAL 4:3 (16/15) geht würde man auf 720x562 resizen (und den PAR ändern).

    Cu Selur

  • Ich habe bisher nur festgestellt, dass ich bei MPEG-2 links und rechts insgesamt 14 Spalten wegcroppen und dann wieder auf 720x576 resizen muss, um mein Bild unter DAR 4:3 verhältnistreu angezeigt zu bekommen. Das wäre dann doch DVD-kompatibel, oder?

  • Vielleicht habe ich etwas falsch dargestellt.
    Meine Quelldatei hat ein Pixelverhältnis von 1 und Bildseitenverhältnis von 5:4.

    Wenn ich es in Virtualdub lade, ist es bei Aspect Ratio = 4:3 verzerrt, bei 59:54 (DV-PAL) in Ordnung
    Wenn ich daraus eine MPEG-2-Datei erzeuge (mit aspect ratio = 4:3) ist diese ebenfalls verzerrt, und aspect ratio 59:54 funktioniert nicht.

    Es scheint tatsächlich so, als ob ich das Quellmaterial entzerren muss.

    Mein Avisynth-Script schneidet an allen Seiten etwas ab, unter Erhaltung des Verhältnisse 720:576. Und auf 720:576 resize ich dann.
    Offenbar muss das Verhältnis des gecroppten Clips anders sein, z.B. 706:576 oder kleiner im gleichen Verhältnis.

    Und dann muss ich mir noch die crop/resize MOD-Regeln ansehen.

  • Vielleicht habe ich etwas falsch dargestellt.
    Meine Quelldatei hat ein Pixelverhältnis von 1 und Bildseitenverhältnis von 5:4.

    Bist du dir da sicher? In DV-AVI wird wahrscheinlich kein SAR explizit gespeichert, sondern von Standardwerten ausgegangen, insofern kann man einer Header-Analyse da nicht vertrauen.

    Vielleicht könnten wir mal einen Ausschnitt begutachten. Auch fehlen vielleicht noch ein paar Details, mit welcher Technik hier digitalisiert wurde, woraus man vielleicht schließen kann, ob ein Croppen auf 704 Pixel Breite von vorn herein vielleicht vernünftig wäre.

    Ein Skalieren von 704 (oder wie viel genau auch immer) auf die sehr nahe liegende Breite von 720 Pixeln halte ich jedenfalls nicht für vernünftig, da dir hier erst vor der Wiedergabe Details verlorengehen, und nach der Wiedergabe mit Entzerrung auf 576 * 4:3 = 768 noch ein zweites Mal. Wahrscheinlich wird es besser sein, das Material bei 704 Pixeln Breite zu belassen. Aber das wird klarer, wenn man einen kurzen Clip anschauen kann.

  • Ich muss an allen 4 Seiten etwas wegschneiden, auch oben und unten.
    Natürlich könnte man das auch schwarz abdecken, um Resizen zu vermeiden. Aber das muss ich ja, glaube ich zumindest, sowieso, wenn ich den Teller rund haben will.
    Capturen nach 704x576 hätte die gleiche Verzerrung gebracht, nur bereits abgeschnitten (ich glaube, mich daran zu erinnern, dies getestet zu haben).

    Mein Versuch war, links, rechts und unten 20 Pixel, oben 12 Pixel abzuschneiden (liegt im Overscan-Bereich ?), um wieder auf das gleiche Seitenverhältnis zu kommen (680x544).
    Dies ist aber wieder 5:4 und immer noch verzerrt bei 4:3.


    Nachtrag:

    Wenn ich auf 704 beschneide, dann ist das Bild in VDub unter 59:54 und 4:3 nahezu identisch, bzw. das Bild ist unter 4:3 OK.
    Nachteile: Eigentlich wollte ich auf 720x576 (576i) gehen. Außerdem habe ich den Overscan-Bereich dabei, insbesondere die Störungen am oberen und unteren Rand (siehe die beiden "Lauffische" unten im Frame).

    Einmal editiert, zuletzt von Highwayman (3. Januar 2018 um 15:42)

  • Probleme im Overscan- oder Sync-Bereich werden am einfachsten mit "Letterbox" überdeckt, anstatt mit "Crop" zu einer beliebigen Auflösung jenseits aller Standards abgeschnitten. Kanten in stabilem Schwarz können moderne Codecs relativ effizient codieren, selbst wenn deren Breite nicht durch 8 oder gar 16 teilbar ist. Verluste durch das erneute Hochskalieren könnten da durchaus stärker ins Gewicht fallen (entweder "zu weiches" Bild, oder durch Aliasing laufende Kanten bei der Wahl eines "zu scharfen" Kernels). Und ganz schlimm wird es erst, wenn man vertikal skaliert, ohne eventuelles Interlacing zu beachten.

  • crop + addborders ist doch äquivalent zu letterbox, oder?
    Wenn ich den ermittelten Overscan-Bereich (L 30, R 30, O 12, U 27) komplett abdecke, dann sieht das sehr unschön aus mit den dicken schwarzen Balken.
    Und nur mit 704 wird die Sache bei 4:3 "rund".

    Derzeitiger Stand ist:

    Crop (16, 2, -16, -12)
    separatefields()
    Lanczos4Resize (720, 288)
    weave()

    Ergebnis sieht erst einmal nicht schlecht aus. Aber ich arbeite weiter daran.

  • Theoretisch ist Crop + AddBorders äquivalent zu Letterbox; praktisch muss aber nach dem Crop ein Clip entstehen, der zu den Nebenbedingungen seines Farbraums passt.

    Beispiel: Mit Letterbox kann man auch in YUY2 und YV12 einen Rand mit ungeradzahliger Breite überdecken, aber mit Crop keinen Zwischenclip mit ungeradzahliger Breite erzeugen.

  • Ja, stimmt, Crop meldet einen Fehler (bei left und -right). Letterbox aber auch.

    Die 704er - Variante ohne Resize wäre wohl folgende:

    crop( 6, 0, -10, 0)
    letterbox(12, 12, 4 ,4)

    Die 12 korrespondieren mit meinem Overscan von TV oder Mediabox. Ich weiß nicht, ob der Overscan aktueller Standard ist und wo der herkommt. Am PC sind die Ränder sichtbar. Die 4er-Balken links und rechts vergrößern die TV-Letterbox ein wenig.

  • Quelle: 720x576 mit PAR 59:54 nach MP4 PAL 4:3 (12/11)
    59:54 = 1,0925925925925925925925925925926 -> 720*59/54 = 786,66666666666666666666666666667
    12:11 = 1,0909090909090909090909090909091 -> 720*12/11 = 785,45454545454545454545454545454
    wenn man in YUV2 und damit auf mod2 bleiben will würde man zur Fehler Reduktion beide auf 786 entzerren
    Da wir hier anamorph bleiben wollen würde man nicht Resizen sondern einfach den PAR ändern. :)
    Und wenn man mir nicht glauben will einfach PARanoia verwenden.

    Wenn es nach MPEG-2 PAL 4:3 (16/15) geht würde man auf 720x562 resizen (und den PAR ändern).

    Cu Selur

    Dazu noch gefunden von mrg:
    AW: Zeitgemäßes hochwertiges analoges Capturing per USB oder HDMI
    [INDENT] Genau wie LigH es beschreibt ist es. Das bedeutet, dass beim Capturing mit 704x576 UND 720x576 nur jeweils 702 Pixel in der Breite den Inhalt des PAL 4:3 Bildes beinhalten. Bei 704x576 sind also 2 und bei 720x576 18 zusätzliche Pixel vorhanden, die nicht zum PAL 4:3 Format gehören. Um beide Formate in quadratische Pixel umzuwandeln, muss jedes digitalisierte Pixel jeweils um den Faktor 1,094 bei PAL 4:3 oder 1,459 bei PAL 16:9 in der Breite gestreckt werden und somit erhält man folgende praktische Werte:
    704px -> [4:3]: 768px (genau: 770px) / [16:9]: 1024px (genau: 1027px)
    720px -> [4:3]: 784px (genau: 788px) / [16:9]: 1056px (genau: 1050px)
    Beim Encoding des 720er Formates darf DAR 4:3 oder 16:9 nicht im Encoder gesetzt werden! Es muss dafür PAR auf 1:1 gesetzt sein, damit es bei der Wiedergabe korrekt angezeigt wird. Beim 704er Format ist es egal ob der Encoder auf PAR 1:1 oder DAR 4:3 / 16:9 gesetzt ist.
    [/INDENT]

    [INDENT] Geändert von mrg (28. June 2016 um 15:09 Uhr)
    [/INDENT]


    Heißt das, dass ich mit Avisynth eine Clip im Format 704x786 erstellen muss (links und rechts 8 croppen, dann horizontal resizen (strecken).
    Bzw. im Format 720x786.
    Und dabei dann auf quadratische Pixel gehen (wie denn, in Avisynth?).
    Und beim Encoden mit ffmpeg wird dann daraus wieder 720x576?

    Highwayman.

    2 Mal editiert, zuletzt von Highwayman (3. März 2018 um 13:11)

  • Weniger sorgen.

    Wenn du MPEG-2 für DVD Video erzeugst, hast du nur zwei kompatible Möglichkeiten: entweder das MPEG-2-Video wird mit Seitenverhältnis-Flag "DAR 4:3" encodiert, oder das MPEG-2-Video wird mit Seitenverhältnis-Flag "DAR 16:9" encodiert. Egal ob das encodierte Video 720 oder 704 (oder gar 352) Pixel breit ist: Der Player hat dafür zu sorgen, dass es entweder mit Seitenverhältnis 4:3 oder mit Seitenverhältnis 16:9 dargestellt wird.

    Wenn du MPEG-4 AVC für modernere Player erzeugst, hast du mehr Möglichkeiten zur Auswahl. Aber so oft wie ich bisher versucht habe zu antworten, so oft vergesse ich auch immer wieder, was am Ende eigentlich herauskommen soll...

  • Hallo,

    durch die "aspect ratio = 15:11" - Angabe bei ffmpeg wird bei der MPEG-4-Encodierung das richtige Seitenverhältnis erreicht.
    Das gilt sowohl bei Encodierung des Originalclips in 720x576 als auch bei Encodierung eines in 720x786 "gestreckten" Clips (Resize).
    Somit kann man sich das Resizing ersparen.

    Aber welcher Weg ist richtig? Was passiert genau bei der Encodierung mit ffmpeg?
    Wir hier nur ein SAR-Wert richtig gesetzt oder werden die Pixel bearbeitet? (Beim Umweg über 786 sicher, aber auch bei 576?)

    Ein Blick auf die Dateigrößen:
    Bei den avi-Dateien ist die 786er Datei um den Faktor 1,36 größer, das entspricht dem Verhältnis der Pixelanzahlen.

    Bei den mp4-Dateien (bei ansonsten gleicher ffmpeg-Einstellungen) dreht sich das aber:
    Hier ist die aus der 786er avi-Datei entstandene mp4 nur 0,65 - fach so groß wie die 576er. ???.
    Woran liegt das?

    Egal, was ist der richtige Weg. Ich nehme an, der über den Originalclip.

    Highwayman.

    2 Mal editiert, zuletzt von Highwayman (1. April 2018 um 16:39)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!