Von ÖR 720p50 nach PAL-DVD

  • Hallo!

    Ich muss doch manchmal einen ÖR-HD-Stream (*.ts) in 720p50 in einen DVD-kompatiblen Stream konvertieren. Ich kann das ganze mit TMPGEnc Video Mastering Works 5 relativ einfach machen, habe aber den Eindruck, dass das Ergebnis nicht optimal ist. Z.B. ruckeln die so erstellten DVDs und Laufschriften erscheinen horizontal zerrissen. Ich habe deshalb ein wenig gegoogled und andere Lösungen auf Basis von Avisynth und ffmpeg gefunden. Ich experimentiere mit folgendem Script:

    LoadPlugin("C:\meGUI\MeGUI_2153_x86\tools\dgavcindex\DGAVCDecode.dll")
    AVCSource("D:\HDTV\xy.dga")
    Lanczos4Resize(720, 576)
    Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave()

    Ich verstehe, dass Avisynth zuerst die Auflösung von 1280*720 auf 720*576 verkleinert und dann das Ganze irgendwie interlaced. Genau verstehe ich die Zeile mit Assumetff()... aber nicht und weiß deshalb auch nicht, ob das interlacing so richtig ist. Wer kann mir die Zeile genauer erklären?

    Das Script verfüttere ich dann an ffmpeg und zwar so:

    ffmpeg -i xy.dga -aspect 16:9 -target pal-dvd dvd.mpg

    Das ganze funktioniert im Prinzip auch - auch mit der Qualität wäre ich zufrieden, allerdings ist das Ergebnis am Ende progessive und nicht interlaced und - was viel schlimmer ist - ffmpeg scheint die Option -aspect zu ignorieren, denn das Seitenverhältnis ist verkehrt (Eierköpfe) und MediaInfo zeigt als Display aspect ratio 5:4 an. Wie komme ich zu einem interlaced Video im richtigen Seitenverhältnis von 16:9?

    Vielen Dank!
    Indy

  • Genau verstehe ich die Zeile mit Assumetff()... aber nicht und weiß deshalb auch nicht, ob das interlacing so richtig ist. Wer kann mir die Zeile genauer erklären?

    Die AviSynth-Dokumentation, die beim Installieren mit auf deiner Festplatte gelandet ist.

    In Kürze:

    AssumeTFF() # Halbbildreihenfolge "oberes Halbbild zuerst" wird angenommen
    SeparateFields() # Clip mit 50 Vollbildern pro Sekunde wird in 100 Halbbilder pro Sekunde aufgeteilt
    SelectEvery(4, 0, 3) # immer je aller 4 Halbbilder werden nur das Halbbild Nr. 0 und das Halbbild Nr. 3 ausgewählt, also das aktuelle obere mit dem nächsten unteren
    Weave() # beide werden zu einem neuen Vollbild gemischt, wieder halbe Framerate, jetzt mit Interlaced-Inhalt
    AssumeFPS(25, 1) # zur Sicherheit; leider bin ich mir nicht sicher, ob SelectEvery auch die Halbbildrate halbiert hätte


    Das Script verfüttere ich dann an ffmpeg und zwar so:

    ffmpeg -i xy.dga -aspect 16:9 -target pal-dvd dvd.mpg

    Wieso xy.dga? Sollen AviSynth-Skripte nicht die Endung *.avs haben? Die Endung *.dga gehört zu DGAVCDec-Indexdateien, nicht zu AviSynth-Skripten.

    Ansonsten weiß ich nicht, wie man ffmpeg zuverlässig mit Parametern steuert, dafür ist mir der Dschungel aus Parameters unterschiedlichster Kategorie einfach zu dicht. Den HC-Encoder kann ich dagegen leicht bedienen, und ich bin mir auch bei dem ganz sicher, dass er qualitativ zu den besten MPEG2-Encodern gehört.

  • Hallo!

    Vielen Dank für Deine Antwort!


    AssumeTFF() # Halbbildreihenfolge "oberes Halbbild zuerst" wird angenommen


    Warum muss ich diese Annahme überhaupt machen, wo das Quellmaterial doch progessiv ist und also jedes Frame nur aus einem Vollbild besteht? Oder hat diese Annahme einen Einfluss auf SeperateFields, das...

    Zitat


    SeparateFields() # Clip mit 50 Vollbildern pro Sekunde wird in 100 Halbbilder pro Sekunde aufgeteilt


    ...durch AssumeTFF() aus jedem progressiven Frame zuerst ein oberes und dann ein unteres Halbbild erzeugt und nicht umgekehrt? Aber was wäre der Unterschied zu AssumeBFF()? Die erzeugten Halbbilder bestehen nur aus jeder zweiten Bildzeile des jeweiligen Frames und haben die halbe vertikale Auflösung, ist das richtig?

    Zitat


    SelectEvery(4, 0, 3) # immer je aller 4 Halbbilder werden nur das Halbbild Nr. 0 und das Halbbild Nr. 3 ausgewählt, also das aktuelle obere mit dem
    nächsten unteren
    Weave() # beide werden zu einem neuen Vollbild gemischt, wieder halbe Framerate, jetzt mit Interlaced-Inhalt


    Ja, das verstehe ich sogar. Aus jedem ursprünglichen progessiven Frame wird jeweils nur ein erzeugtes Field ausgewählt, entweder das obere (0) oder untere (3). Dadurch hat Stream anschließend 50 Fields also 25 frames pro Sekunde.

    Zitat


    AssumeFPS(25, 1) # zur Sicherheit; leider bin ich mir nicht sicher, ob SelectEvery auch die Halbbildrate halbiert hätte


    Zumindest gibt MediaInfo 25 als frame rate aus. Dann wäre AssumeFPS(25, 1) nicht nötig?

    Zitat


    Wieso xy.dga?


    Kopierfehler, sorry.

    Zitat


    Den HC-Encoder kann ich dagegen leicht bedienen, und ich bin mir auch bei dem ganz sicher, dass er qualitativ zu den besten MPEG2-Encodern gehört.

    Ok, den kannte ich noch gar nicht und werde ihn mal ausprobieren!

    Vielen Dank,
    Indy

  • Warum muss ich diese Annahme überhaupt machen, wo das Quellmaterial doch progessiv ist und also jedes Frame nur aus einem Vollbild besteht? Oder hat diese Annahme einen Einfluss auf SeperateFields, das...

    ...durch AssumeTFF() aus jedem progressiven Frame zuerst ein oberes und dann ein unteres Halbbild erzeugt und nicht umgekehrt?

    RÜÜÜCHTÜÜÜCH!

    Aber was wäre der Unterschied zu AssumeBFF()?

    Da wird zuerst das untere Halbbild aus dem ersten Frame herausgeholt, dann das obere aus dem ersten Frame, dann wieder das untere aus dem zweiten Frame... So was ist typisch für DV-Magnetband-Kameras, aber beim Digitalisieren von Fernsehsignalen mit analogen Capturekarten oder beim Verarbeiten von DVD-Material wird eher die TFF-Reihenfolge verwendet. Dem Röhrenfernseher ist das relativ egal, da kommt ein Halbbild nach dem anderen zur Anzeige. Relevant ist das nur, wenn zwei Halbbilder in einem Frame abgespeichert werden, dann muss man wissen, welches von beiden zu früherer Zeit dargestellt werden muss.

    Die erzeugten Halbbilder bestehen nur aus jeder zweiten Bildzeile des jeweiligen Frames und haben die halbe vertikale Auflösung, ist das richtig?

    Ja, und außerdem immer abwechselnd die anderen Zeilen, von ihrer "Höhenlage" her.

    Ja, das verstehe ich sogar. Aus jedem ursprünglichen progessiven Frame wird jeweils nur ein erzeugtes Field ausgewählt, entweder das obere (0) oder untere (3). Dadurch hat Stream anschließend 50 Fields also 25 frames pro Sekunde.

    Genau. Und da zwischen den Halbbildern (0 und 1) sowie (2 und 3) jeweils die Zeit 1/50 Sekunde voranschreitet, mischen sich im neuen Frame zwei Halbbilder "oben von jetzt" und "unten von 1/50 s später". In dieser Reihenfolge wegen AssumeTFF() und SelectEvery(4, 0, 3).

    Zumindest gibt MediaInfo 25 als frame rate aus. Dann wäre AssumeFPS(25, 1) nicht nötig?

    Allerdings. Dann hat wohl SelectEvery berechnet, dass 2 aus 4 Halbbildern die halbe Halbbildrate zum Ergebnis haben (100/2 => 50/2), wodurch Weave bereits die richtige Framerate erzeugt (50/2 => 25).

  • Bei 720p50 sollte zunächst geprüft werden, ob es sich tatsächlich um 50fps handelt, oder - wie z.B. bei Spielfilmen - jedes Bild zweimal gesendet wird. In diesem Fall sollte durch SelectEven() ein 720p25 erzeugt werden. Anschließend prüfen, ob man besser progressiv oder interlace kodieren soll.

  • Hallo!

    Bei 720p50 sollte zunächst geprüft werden, ob es sich tatsächlich um 50fps handelt, oder - wie z.B. bei Spielfilmen - jedes Bild zweimal gesendet wird.

    Genau das wäre dann auch meine nächste Frage gewesen. Das zu prüfen scheint mir aber schon einigermaßen kompliziert zu sein. Was wäre denn das Ergebnis wenn man SelectEvery(4, 0, 3) auf eine Quelle anwendet bei der die Frames nur verdoppelt wurden?

    EDIT: Naja, klar ist, dass dann die beiden ausgewählten Halbbilder gar nicht von unterschiedlichen Zeitpunkten stammen würden. Aber was würde man dann sehen?

    Zitat

    In diesem Fall sollte durch SelectEven() ein 720p25 erzeugt werden.

    Das leuchtet dann ein!

    Zitat

    Anschließend prüfen, ob man besser progressiv oder interlace kodieren soll.

    Wie kann man soetwas entscheiden?

    Vielen Dank,
    Indy


  • Wie kann man soetwas entscheiden?


    Den Film in den VLC-Player einlesen, Ansicht auf Erweiterte Steuerung einstellen und auf Frame nach Frame klicken. Wenn grundsätzlich nur nach jedem 2. Bild Bewegung feststellbar ist, ist das Video als 720p25 anzusehen.

  • Den Film in den VLC-Player einlesen, Ansicht auf Erweiterte Steuerung einstellen und auf Frame nach Frame klicken. Wenn grundsätzlich nur nach jedem 2. Bild Bewegung feststellbar ist, ist das Video als 720p25 anzusehen.

    Ja, ok. Auch das leuchtet mir ein! VLC-Player habe ich eh installiert und AvsPmod gucke ich mir auch mal an. Es ging mir jetzt aber um Deine Aussage, dass man entscheiden müsste, ob man nach der Umwandlung in 720p25 durch SelectEven() progressiv oder interlaced kodiert. Wie kann man das entscheiden? DVD-Video unterstützt ja auch 576p25. Warum sollte man in einem solchen Fall interlaced kodieren? Zumal bei 720p50, das durch Verdoppelung der Frames erzeugt wurde, ja eh keine höhere zeitliche Auflösung vorhanden ist. Interlaced zu kodieren würde dann nur Sinn machen, um die höhere zeitliche Auflösung eines "echten" 720p50 auf eine DVD zu retten, dann aber zum Preis einer geringeren vetikalen Auflösung.

    Gruß,
    Indy

  • Den Film in den VLC-Player einlesen, Ansicht auf Erweiterte Steuerung einstellen und auf Frame nach Frame klicken. Wenn grundsätzlich nur nach jedem 2. Bild Bewegung feststellbar ist, ist das Video als 720p25 anzusehen.

    Ja, ok. Auch das leuchtet mir ein! VLC-Player habe ich eh installiert und AvsPmod gucke ich mir auch mal an. Es ging mir jetzt aber um Deine Aussage, dass man entscheiden müsste, ob man nach der Umwandlung in 720p25 durch SelectEven() progressiv oder interlaced kodiert. Wie kann man das entscheiden? DVD-Video unterstützt ja auch 576p25. Warum sollte man in einem solchen Fall interlaced kodieren? Zumal bei 720p50, das durch Verdoppelung der Frames erzeugt wurde, ja eh keine höhere zeitliche Auflösung vorhanden ist. Interlaced zu kodieren würde dann nur Sinn machen, um die höhere zeitliche Auflösung eines "echten" 720p50 auf eine DVD zu retten, dann aber zum Preis einer geringeren vetikalen Auflösung.

    Gruß,
    Indy

  • Es ging mir jetzt aber um Deine Aussage, dass man entscheiden müsste, ob man nach der Umwandlung in 720p25 durch SelectEven() progressiv oder interlaced kodiert. Wie kann man das entscheiden? DVD-Video unterstützt ja auch 576p25. Warum sollte man in einem solchen Fall interlaced kodieren


    Genau, deshalb empfiehlt sich, nicht zu deinterlacen und progressiv zu codieren. SelectEven() muß dann in jedem Fall gesetzt werden.
    Zusammengefaßt: erfährt nur jedes 2. Bild eine Veränderung, progressiv codieren, ist es echtes 720p50, bringt die Interlace-Codierung möglicherweise einen besseren Bewegungsfluß.

  • Oder anders:

    Wenn der Inhalt wirklich 50 fps hat, webt man sich aus Halbbildern interlaced PAL mit 50 Fields pro Sekunde.

    Wenn der Inhalt nur verdoppelte 25 fps ist, halbiert man sie zu progressiv PAL mit 25 Frames pro Sekunde. Und um die leichten Differenzen zwischen den verdoppelten Frames auszugleichen (man weiß ja nie, ob SelectEven() oder SelectOdd() bessere Qualität gehabt hätte), könnte man auch den Mittelwert bilden: Merge(SelectOdd(),SelectEven())

  • Und um die leichten Differenzen zwischen den verdoppelten Frames auszugleichen (man weiß ja nie, ob SelectEven() oder SelectOdd() bessere Qualität gehabt hätte), könnte man auch den Mittelwert bilden: Merge(SelectOdd(),SelectEven())

    Wobei ich mich hier Frage, ob diese nicht eh durch einen Hard-Pull-Down 100% identisch sind. Weiß nicht, wie die ÖR das handhaben, aber feine Unterschiede zwischen den eigentlich identischen Frames würden ja eine extreme Bitratenverschwendung/Bildverschlechterung bedeuten.

  • Aber selbst der billigste Encoder müßte den zweiten Frame als P-Frame zu quasi 0 kodieren - Problem wäre hier dann nur ein durch das Keyframe-Intervall erzwungener I-Frame. Keine Ahnung, welches Muster die ÖR da anwenden bzw. ob das bedacht wird. Hat zufällig jemand ein etwas längeres Sample? Vielleicht wäre in diesem Fall auch das Auswählen des jeweils zweiten Frames von Vorteil? Schlimmstenfalls ist er zu 100% identisch zum vorherigen und ansonsten ein I-Frame mit potenziell mehr Bits.

  • Ich glaube, Selur hatte da mal was getestet, mit dem Ergebnis, dass die doppelte Anzahl Frames eben doch noch zu deutlich höherer Größe führt, selbst wenn eigentlich bei identischen Frames eines der beiden ein minimales B-Frame (eher nicht P) werden müsste.

    Ich glaube.

    Genau erinnern kann ich mich aber nicht, und suchen wäre mangels perfekter Schlüsselworte schwierig.

  • Ich glaube, Selur hatte da mal was getestet, mit dem Ergebnis, dass die doppelte Anzahl Frames eben doch noch zu deutlich höherer Größe führt, selbst wenn eigentlich bei identischen Frames eines der beiden ein minimales B-Frame (eher nicht P) werden müsste.

    Ich vermute mal mit x264 und CRF? Das hat dann hier mit eher nicht viel zu tun. Letztendlich müßte man aber bei Verdopplung der Frames auch einige andere Größen Verdoppeln, Keyframeinterval, maximale Anzahl an B-Frames und refs und solche Dinge. Außerdem arbeitet x264 CRF's frameratenabhängig, d.h. bei Veränderung von --fps ändert sich auch die Bitrate.

  • Danke für die Links. Ist allerdings ein etwas anders gelagerter Fall, weil es hier um 25 -> 50 progressiv und nicht um Deinterlacing geht. Außerdem wollen wir hauptsächlich wissen, was besser ist:
    1.) ersten Frame wählen
    2.) zweiten Frame wählen
    3.) Durchschnitt beider Frames

    Habe leider keinen Beispielstream, mit dem man das mal nachschauen könnte. Grundsätzlich hat LigH aber schon Recht, daß es auf das Muster der Frametypen ankommen könnte.

    Gesendet wird HD in Deutschland meines Wissen ausschließlich in AVC. (Oder war das mit MPEG-2 ein Vertipper?)

Jetzt mitmachen!

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