Jetzt hast du doch schon den 3. Thread zu diesem Thema erstellt und so eine halbe Odyssee durch? Du hattest doch Probleme mit dem unteren Rand bei Auflösung 720x576? Hast du das behoben bekommen? Wenn du noch den Aplic (oder verwechsel ich das jetzt?) verwendest, den originalen Treiber hast du genommen?
https://archive.org/details/usb-grabber
Es wurde doch schon einiges gesagt. Es ist sinnvoll mit OBS erstmal in einem verlustfrei komprimierten Codec wie FFV1 oder Huffyuv, FFVhuff aufzunehmen und die Aufnahme später in ein passendes Endformat zu bringen. Dabei kannst du auch besser Einstellungen wie Bitrate, Codec, Cropping, Deinterlacing, Resize etc. testen. Empfehlen würde ich dafür Staxrip.
Zur Sache mit x264/265 - nicht nur die Bitrate ist entscheidend, sondern auch das Preset. Presets wie super und ultrafast brauchen im Vergleich zu medium, slow, slower etc. eine weit höhere Bitrate um eine ähnliche Qualität zu erreichen. Wenn man eine schwache CPU hat ist die Aufnahme in x264/265 nicht immer ratsam, weil die Leistung nicht aussreicht und es zu verworfenen FPS kommt. Dazu bei OBS auf Ansicht und Statistiken kontrollieren. GPU-Encoder sind weit schneller, liefern aber in der Regel eine schlechtere Qualität.
Bei OBS Einstellungen unter Video:
Basis Auflösung 720x576; Skalierte Auflösung 720x576; Ganzzahl FPS-Wert 25
Unter Erweitert:
Farbformat NV12 oder I420; Farbraum Rec. 601; Farbbereich begrenzt
Unter Ausgabe:
erweiterte Ausgabe (ffmpeg), Container Matroska; Kodierer FFV1 oder HuffYUV
Audio: AC3 44kbps oder PCM/WAV 16bit
Dann muss der Grabber noch richtig konfiguriert werden. Dass die Ausgangsqualität besser ist ist erwartbar aber das Ergebnis sollte eigentlich nicht schlechter sein als das was der Cinch/HDMI Converter liefert.
Final würde ich die Aufnahme dann in x264 konvertieren. x265 hat bei SD nicht wirklich Vorteile und ist, wenn allgemein betrachte, zwar der besser, aber langsamere und kompliziertere Codec.
Hier ist mindesten Preset slow zu empfehlen.
Außerdem musst du dich entscheiden, ob du das Ganze wieder interlaced encodest und das Deinterlacing dem TV oder Player überlässt (dafür den Parameter --tff / top field first) setzen oder ein Software-Deinterlacing durchführst.
Software-Deinterlacing führt immer zu einem Qualitätsverlust und es gibt allerlei unterschiedliche Varianten, die alle unterschiedlich gut arbeiten. Deinterlacing ist allerdings für manche Bearbeitungen notwendig, man kann kein Interlaced-Video resizen beispielsweise.
QTGMC wird oft als bester Software-Deinterlacer genannt. QTGMC kann man in die Kategorie "Smarte Deinterlacer" stecken, hier wird jedes Halbbild zu einem Vollbild erweitert. Daraus ergibt sich eine doppelte Framerate, also bei PAL 50 FPS. Vorteil ist, dass wir wirklich die vollen Bewegungsinformationen erhalten und das Video vollkommen flüssig spielt. Deweiteren kann man mit QTGMC recht gutes Denoising durchführen, was natürlich besser für die Komprimierbarkeit des Videos ist. Nachteil: QTGMC ist langsam.
Hier kann man mit Preset fast starten, wer mehr Denoising möchte kann auf höhere Presets zurückgreifen.
x264 hat auch einen eingebauten Parameter für eine interne Noise Reduction (--nr). Damit kann man auch einiges an Bitrate sparen ohne das Bild zu verschlimmbessern, wenn man es nicht übertreibt. Ich glaube selbst ein Wert von 100 liefert nur sehr leichtes Denoising, kann also auch sinnvoll sein höhere Werte zu nehmen.
Achja außerdem sollte noch die korrekte Sample Aspect Ratio (--sar 16:15) gesetzt werden, damit das Video beim Abspielen von 720x576 auf 768x576 gestreckt wird und wir ein korrektes Seiterverhältnis haben.
Und hier haben wir schon den nächsten Fall, wo wir abwägen müssen ob wir das Video interlaced belassen oder deinterlacen. Wenn wir die schwarzen Ränder bei einen anamorphen interlaced Video beliebig croppen, kann es sein dass diverse Player Probleme damit haben, es bei Abspielen wieder mit der richtigen Aspect Ratio darzustellen. Deinterlacen wir das Video, können wir Resizen und somit das Anamorphing entfernen.
Auch gut: mache Smart-TVs können so eingestellt werden, dass sie die wenigen schwarzen Pixel vom, ich nenne es mal Overcan-Bereich, gar nicht mit darstellen. (Just Scan Funktion)
So viel dazu und das waren noch nichtmal die Details.
Vindoriel schrieb:
Die ITU (weltweit maßgeblich für Telekommunikation, (Rund-)Funk und Fernsehen) sagt da eher was Anderes. Da sind (bei modernen Videocodecs, MPEG-1/2 lasse ich mal weg) H.264 (AVC, meist für HD) und H.265 (HEVC, meist für UHD / "4K") das Maß der Dinge...
Korrekt. Ich finde besonders "daneben", dass HEVC in 3840x2160p ein Rund-Funk-Standard ist aber HEVC in 1920x1080p nicht. Jedenfalls nicht bei der SAT-Übertragung.
)
