Sehr schön 👍
Ich wäre dafür auch sehr dankbarZitat von Guenni
Sehr schön 👍
Ich wäre dafür auch sehr dankbar
@guenni:
Ich nehme die Änderungen natürlich auch gern und mit bestem Dank entgegen
Ich habe otrverwaltung3p auf meinem Raspberry Pi 4 (mit Buster) installiert. Es funktioniert zwar nur teilweise, aber das Schneiden funktioniert. Ich werde da meine Änderungen einbauen und das ganze testen. Dann kann ich den geänderten Sourcecode zur Verfügung stellen, bzw. das wichtigste Modul. Einige kleine Änderungen müßtet Ihr dann vielleicht noch manuell vornehmen. Die werde ich in einer separaten Textdatei dokumentieren.
Ich verwende zwar in rpiotrtool nur noch x264, aber ffmpeg ist noch drin und ich werde vielleicht auch noch versuchen, das ebenfalls anzupassen.
Ich habe nicht einfach nur die Encodierungsparameter geändert, sondern spezielle Parameter für das neue HD-Format hinzugefügt. Eine spezielle neue Analysefunktion unterscheidet das alte vom neuen Format und liefert die entsprechenden Parameter. Damit ist sichergestellt, daß sowohl das alte HD-Format wie auch das neue geschnitten werden können.
Die Schnittmethode von rpiotrtool habe ich ja aus otrverwaltung++ übernommen. Da bin ich natürlich froh, mal was zurückgeben zu können.
Mal gerade der neue Raspberry Pi 4 hat Hardware decoding für h265 und die Umstellung der Schnittsoftware ist auch noch ein Problem.
Nutze z.B. keinen Rechner/Notebook mehr für Videos, sicher ist das bei den meisten so, da fast jedes Kleingerät h264 kann.
Es wurde so lange an dem veralteten xvid festgehalten, obwohl alle einigermaßen aktuellen Geräte h264 bereits konnten, selbst der alte PI1 ...
Aktuell wäre ein Wechsel zu h265 (leider) noch zu früh.
@guenni: Ja, ich bin gcurse
Die Unterscheidung der HD/HD.test-Dateien habe ich schon implementiert. Mir fehlen nur noch die Encoding-Parameter. Das Umsetzen auf ffmpeg sollte kein Problem sein und falls doch, kann ich auch x264 benutzen. Die Infrastruktur dafür ist ja seit otrv++ vorhanden.
Zum Dekodieren: Du musst in 'Einstellungen -> OTR-Einstellungen' den Pfad zum nativen Dekoder angeben.
Das Dekodieren mal zuerst: den Pfad habe ich natürlich eingegeben, aber der RPi-Dekoder ist eine abgespeckte Version und funktioniert nicht mit der otrverwaltung. Auch der manuelle Schnitteditor ist praktisch nicht verwendbar.@guenni: Ja, ich bin gcurse
Die Unterscheidung der HD/HD.test-Dateien habe ich schon implementiert. Mir fehlen nur noch die Encoding-Parameter. Das Umsetzen auf ffmpeg sollte kein Problem sein und falls doch, kann ich auch x264 benutzen. Die Infrastruktur dafür ist ja seit otrv++ vorhanden.
Zum Dekodieren: Du musst in 'Einstellungen -> OTR-Einstellungen' den Pfad zum nativen Dekoder angeben.
Zu den Enkodereinstellungen. Ich habe einen neuen Parameter in Config.smartmkvmerge eingeführt. Der sieht derzeit so aus:
"x264_newhd_string": "--tune film --pic-struct --preset veryfast --sps-id 1 --stitchable"
Entscheidend ist "--sps-id 1 ". Es würde vermutlich auch mit anderen Encodingparametern funktionieren. Ich habe den preset veryfast als Ausgangsbasis genommen, weil er einige Ähnlichkeiten zum OTR-Format aufweist. "--stitchable" ist evtl. in älteren x264-Versionen noch nicht vorhanden. Es funktioniert aber auch ohne.
Zur dauerhaften Unterscheidung des Unterschiedes zwischen den Formaten teste ich übrigens in mediainfo auf Profile "Main@L3.2".
Geändert von Guenni (09.04.2020 um 12:09 Uhr)
Hallo,
ich verwende seit fünf Jahren das Programm "Pegasys TMPGEnc MPEG Smart Renderer 4 bzw. 5".
Die neuen experimentellen HD-Dateien lassen sich damit nicht schneiden.
Fehlermeldung:
This file cannot be smart rendered due to the following reason:
Number of DPB Frames (Not Supported), Maximum Re-order Frames (Not Supported).
Hier ein Screenshot dazu.
Number of DPB Frames hat im neuen Format einen Wert von 8, mit dem Werten 6 bzw. 4 würde es funkionieren.
Max Re-order Frames hat im neuen Format einen Wert von 7, mit dem Wert 2 würde es funktionieren.
Vielleicht könnt Ihr das noch berücksichtigen.
Bitte die Datei nicht noch größer machen. Das braucht auch Serverkapazitäten. Eine verschlechterung der Qualität hat bei HD keinen Sinn, dann kann man gleich HQ nehmen. Also ab Besten das bisherige Format nutzen.
Ich glaube, du hast das zugrunde liegende Problem nicht verstanden. Um mehr HD-Aufzeichnungen anbieten zu können, muß OTR die Transkodiergeschwindigkeit erhöhen. Dazu wurde beim neuen Test-Format die Enkodier-Einheit von Nvidia-Grafikkarten eingesetzt. Es handelt sich also nun um eine Hardware-Enkodierung statt eine Software-Enkodierung.
Hardware-Enkoder brauchen in der Regel bei gleicher Qualität eine höhere Datenrate als Software-Enkoder.
Ich habe mal einige bisherige HD-Aufzeichnungen von OTR überprüft. Die Bitrate (stark schwankend abhängig vom Inhalt) lag da zwischen 1.4 und 1.7 Mbit. Zum Vergleich: Die Originalausstrahlung (ich habe einige dieser Sendungen auch selbst von Satellit aufgenommen) lag bei 14.3 Mbit.
Das neue per Hardware transkodierte Format hat eine Bitrate von 2 bis 2.1 Mbit. Das ist schon sehr niedrig für einen Hardware-Enkoder. Ich habe selbst hardware-basierte Echtzeit Transkodier-Software für TV-Streams geschrieben (für den Raspberry Pi). Bei 720p50-Sendungen der öffentlich-rechtlichen Sender mußte ich (ohne Format-Verkleinerung) 3 MBit verwenden, wenn ich keine deutlich sichtbare Qualitätsminderung haben wollte. Da liegt die Nvidia-Einheit mit 2-2.1 Mbit sehr gut im Rennen.
Das neue HD-Format wird also 30-50% mehr Datenvolumen für den Video-Bitstream brauchen. Ist es uns das nicht wert, wenn wir dafür viel mehr HD-Aufzeichnungen bekommen? Und das ist auch noch deutlich weniger als bei den Mediatheken.
Geändert von Guenni (10.04.2020 um 10:18 Uhr)
Ich bisher auch nicht.
Insofern danke, Guenni, für diese Darlegung des Hintergrundes der Einführung/des Tests eines neuen HD-Formats.
Ich hatte mich nur nicht getraut nachzufragen, weil ich den Thread nicht unnötig voll machen wollte mit Anfängerfragen.
Berechtigungen
Zitieren