experimentelles HD bei Arte

[MenneSi]

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.

[Firebird]

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.

[Guenni]

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.

[Voyager Fan]

Ich glaube, du hast das zugrunde liegende Problem nicht verstanden.

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.

[buffalo-as]

Ich habe nochmal mit Habemus_Papam_20.04.06_20-15_arte_100_TVOON_DE.mpg.HD.test.avi (Cutlist mit ein paar Pausen an bekannter Stelle zur Verfügung gestellt) getestet.
Schneiden mit Cut Assistant (0.19.4.23 und 0.9.12.2) und Cutana 0.9.2.2 (mit Win7, VirtualDub 1.7.8 und x264vfw 2200bm) hat problemlos geklappt, und die Schnittstellen waren auch auf 2 Hardwareplayern ohne Störungen abspielbar.

[buffalo-as]

Bitte die Datei nicht noch größer machen.

Bei meinem Beispiel Habemus_Papam_20.04.06_20-15_arte_100_TVOON_DE.mpg.HD
hat das alte Format eine Größe von 1819002734 Bytes (Videobitrate: 1882874 bps)
und das neue 1985078650 Bytes (Videobitrate: 2074862 bps), also 10% größer.
Wenn das ungefähr in diesem Rahmen bleibt, dürfte das kein Problem sein.

[Guenni]

@buffalo_as

1) Danke für die weiteren Tests. Offensichtlich können alle auf VirtualDub basierenden Windows-Schnittprogramme das neue Format schneiden, ebenso natürlich otrverwaltung3p mit VDub. Aber auch für das von Windows unabhängige SmartMKVMerge-Verfahren (otrverwaltung3p und rpiotrtool) sind nun Lösungen gefunden. Ich habe keine Ahnung wie das auf dem Mac aussieht und was es da überhaupt an Schnittmöglichkeiten gibt.

2) Beim alten HD-Format variiert die Videobitrate viel stärker je nach Inhalt. Beim neuen Verfahren ist sie annähernd konstant. Der Mehrbedarf kann also deutlich höher sein, bis etwa 50%. Das soll aber kein Argument gegen das neue Format sein, wenn uns dafür mehr HD-Inhalte angeboten werden.

[sv00010]

2) Beim alten HD-Format variiert die Videobitrate viel stärker je nach Inhalt. Beim neuen Verfahren ist sie annähernd konstant. Der Mehrbedarf kann also deutlich höher sein, bis etwa 50%. Das soll aber kein Argument gegen das neue Format sein, wenn uns dafür mehr HD-Inhalte angeboten werden.

Ich vermute mal, dass dies so sein muss, weil eine Kodierung mit variabler Bitrate eine Überprüfung des Inhalts mit mehreren Kodierungsdurchläufe braucht,
was dazu führt, dass sich die Aufnahmen auf OTR stapeln, weil die Zeit nicht reicht.

[Guenni]

Ich vermute mal, dass dies so sein muss, weil eine Kodierung mit variabler Bitrate eine Überprüfung des Inhalts mit mehreren Kodierungsdurchläufe braucht,
was dazu führt, dass sich die Aufnahmen auf OTR stapeln, weil die Zeit nicht reicht.

Das stimmt so nicht. Alle bisherigen Formate werden in einem 1-Pass-Verfahren erzeugt. Das neue HD-Format verwendet ein 2-Pass-Verfahren, ist aber trotzdem viel schneller, weil alles wichtige mit spezieller Hardware auf der Grafikkarte abläuft.

[OTR.TH]

Hallo,

soweit ich das rausgelesen habe, sind die Schnittprobleme soweit gelöst, sodass wir auf das neue Format umstellen können?
Das alte HD-Format würde dann vom neuen ersetzt werden; ggf. nach und nach, Sender für Sender, erstmal Arte, ARD, ZDF, danach gehe ich die Liste nach Anzahl Dekodierungen und Verfügbarkeit (HD-Aufnahme und HD-Hardware-Kodiereinheit am Aufnahmestandort) durch. Das "test" im Dateinamen würde ich dann rausnehmen.

otr.th