Archiv verlassen und diese Seite im Standarddesign anzeigen : experimentelles HD bei Arte
Hallo,
seit letzter Woche werden ja alle Arte-Aufnahmen in HD kodiert (siehe News dazu).
Feedback dazu bitte hier drunter, wenn alles soweit ok ist, können wir das als Standard-HD-Kodierung nehmen und nach und nach auf weitere Sender ausweiten.
Und um die Frage von Fabio (Thread wurde wohl verschoben) zu beantworten ("[...] ist aber größer als das bisherige HD. Wo ist der Unterschied?"):
Der wichtigste Unterschied für uns besteht in der Kodiermethode, die erheblich schneller ist als die bisherige. Allein dadurch ist die durchgehende Kodierung aller Aufnahmen in HD mit vertretbarem Aufwand möglich (laut Umfrage wurde ja mehr HD gewünscht). Daher wohl auch die größeren Dateien, ob da noch viel Feintuning möglich ist, muß ich noch prüfen, aber ohne Qualitätsverluste sicher nicht (schneller, evtl. etwas schlechter und ein wenig größer wäre zumindest kein großes Problem ;) ). Außer wir steigen um auf h265 und mp4/mkv-Container.
otr.th
Erst mal Danke für den neuen Service!
Ein paar Fragen und Anmerkungen dazu:
1) Müssen die Schnittprogramme angepaßt werden? Werden also andere Schnittparameter gebraucht? Das könnte für ziemliche Probleme sorgen, da ja viele Programme nicht mehr weiterentwickelt werden.
Als Autor von rpiotrtool müsste ich das unbedingt wissen und könnte dann vielleicht auch schnell darauf reagieren. Ich werde mal ein oder ein paar aktuelle Sendungen herunterladen und damit herumexperimentieren.
2) Bitte kein H265. Das wird noch von zu wenig Endgeräten unterstützt. Und kein aktuelles Schnittprogramm käme damit klar. Es dürfte auch in der Enkodierung wesentlich aufwändiger sein. H264 ist gut genug (lieber ein wenig größere Dateien).
Ich habe mal eine Datei von gestern runtergeladen und mit rpiotrtool geschnitten. Funktioniert problemlos! Das sollte dann auch zumindest für otrverwaltung3p gelten, wenn man dort Smartmkvmerge mit x264 verwendet (dann sind es die gleichen Schnittverfahren).
Ich habe die große Hoffnung, daß das dann auch für Windows- und Mac-Programme gilt, aber die kann ich selbst nicht ausprobieren.
mrturbo1
24.03.2020, 14:30
Hallo zusammen,
meine Rückmeldung als "alter" PS3 Nutzer zum Abspielen..... Sie unterstützt nur 2 GB große Dateien. Schon heute stoßen da viele Sendungen mit langer Sendezeit an diese Grenze. Oder werden die Dateien kleiner?
Hallo zusammen,
meine Rückmeldung als "alter" PS3 Nutzer zum Abspielen..... Sie unterstützt nur 2 GB große Dateien. Schon heute stoßen da viele Sendungen mit langer Sendezeit an diese Grenze. Oder werden die Dateien kleiner?
Du könntest in diesen Fällen eines der üblichen Schnittprogramme nutzen um derart große Dateien in zwei passende Teile aufzuspalten.
Aber so groß sind die Dateien wirklich selten. Z. B. Walk The Line, 2 Stunden 8 Minuten (geschnitten) ca. 1.3 GB.
Hallo,
1) Müssen die Schnittprogramme angepaßt werden? Werden also andere Schnittparameter gebraucht? Das könnte für ziemliche Probleme sorgen, da ja viele Programme nicht mehr weiterentwickelt werden.
Tja, keine Ahnung, sorry. Daher auch der Thread hier. Vermutung: Ich denke, das müsste klappen, es ist ja Standard-h264.
2) Bitte kein H265. Das wird noch von zu wenig Endgeräten unterstützt. Und kein aktuelles Schnittprogramm käme damit klar. Es dürfte auch in der Enkodierung wesentlich aufwändiger sein. H264 ist gut genug (lieber ein wenig größere Dateien).
Wie das mit den Schnittprogrammen aussieht, weiß ich auch hier nicht, wenn man h265/hevc als Encoder wählen kann, könnte es eigentlich klappen.
Bzgl. Endgeräte: Kann nur für PCs sprechen, da ist sowas ja kein Problem. Das dann einige "Kleingeräte" rausfallen, ist auch wahrscheinlich. En- und Dekodierung ist von der Rechenleistung her aufwendiger, ja.
Dekodierung: Neuere GPUs (auch interne neuere Intel-GPUs) sollten da den Prozessor entlasten; falls es nur auf dem Prozessor dekodiert wird, kommt es halt auf den an. Aber solange der nicht älter als 10 Jahre ist, sollte es klappen (IMHO).
Bzgl. der Enkodierung (also eher für uns, nicht für die User interessant): Ja, das dauert nicht ganz doppelt so lange mit der neuen Methode.
Aber gut, das dürfte nicht geplant sein. Zumindest nicht in absehbarer Zukunft. Reden wir wieder drüber, wenn 4K Standard ist ;)
otr.th
Hallo,
meine Rückmeldung als "alter" PS3 Nutzer zum Abspielen..... Sie unterstützt nur 2 GB große Dateien. Schon heute stoßen da viele Sendungen mit langer Sendezeit an diese Grenze. Oder werden die Dateien kleiner?
eher größer (laut Fabio). Müsste man ja mittlerweile vergleichen können, wo es beide Varianten gibt?
otr.th
HD als Standardformat finde ich aktuell noch nicht praktikabel. Allein die jeweiligen Dateigrößen sprengen den Rahmen.
Ich selbst bin ein "Sammler" gerade von älteren Serien/Filmen, da stößt man schnell an Kapazitätsgrenzen der Speicher.
Zumal man sich noch eine Sicherung anlegt. Festplatten halten nicht ewig.
Gerne können mehr Filme/Dokus in HD aufgezeichnet werden, aber für die ganzen Dokusoaps/Telenovelas (auch ÖR-TV) usw. reicht HQ vollkommen aus.
Diese "Test-HD" sind zur Zeit aber nur über OTR verfügbar, oder?
Ich muß mich korrigieren. Ich wußte nicht, daß man das neue HD-Format nur über OTR als Test-Format bekommt.
Da habe ich nun mal eine Datei heruntergeladen und leider klappt das Schneiden überhaupt nicht. Jetzt geht die Sucherei los ... Da muß definitiv was an der Software geändert werden.
Zumindest ortverwaltung3p müsste die gleichen Probleme haben.
Ich muß mich korrigieren. Ich wußte nicht, daß man das neue HD-Format nur über OTR als Test-Format bekommt.
Ich nehme das an, da ich bei den Mirrors nur HD-Dateien (Arte) vor dem 24. März gefunden habe.
@OTR.TH
Könntet Ihr uns die Encoding Parameter verraten? Das würde die Programmierung des SmartRendering (Neu-Enkodierung an den Schnittpunkten) stark vereinfachen. Die Daten, die mir mediainfo liefert sind dafür doch ein bißchen dünn.
Tja, keine Ahnung, sorry. Daher auch der Thread hier. Vermutung: Ich denke, das müsste klappen, es ist ja Standard-h264.
Streng genommen gibt es kein "Standard-h264".
Innerhalb des Codecs gibt es div. Einstellungsmöglichkeiten.
Ein Versuch mit Cutana ergab, dass der Schitt misslang, da die h264-Einstellungen nicht kompatibel seien.
Werde jetzt erst mal versuchen das Video ungeschnitten abzuspielen ... dann sehe ich mal bezüglich "Schnitt" weiter.
buffalo-as
25.03.2020, 23:27
Es wäre bestimmt sinnvoll, wenn die die hier testen auch die dabei verwendeten Aufnahmen benennen.
Ich kann z.B. Der_Blob_Schleimiger_Superorganismus_20.03.21_21-50_arte_55_TVOON_DE.mpg.HD.test.avi unter Win7 mit CA 0.19.4.23, VirtualDub 1.7.8 und x264vfw 2200bm problemlos schneiden.
Falls OTR natürlich aktuell noch an den Encoding-Einstellungen rumschraubt, könnte sich das vermutlich von Tag zu Tag ändern.
Werde ich machen, wenn ich mit meinem "Rumspielen" fertig bin.
Ich will nur wegen einer Cutana-Fehlermeldung keinen Sturm im Wasserglas auslösen.
Dennoch wäre es schön, die h264-Einstellungen zu kennen.
Ich will hier mal über meine weiteren Versuche berichten. Ich habe zunächst eine Routine geschrieben, die die beiden HD-Formate unterscheiden kann und unterschiedlich behandelt. Danach konnte ich dann mit dem neuen Format herumexperimentieren.
Es gibt leider immer noch Probleme an den Schnittstellen. Manchmal sind sie kaum (oder gar nicht) zu bemerken ( wie z. B. bei Der_Blob_Schleimiger_Superorganismus_20.03.21_21-50_arte_55_TVOON_DE.mpg.HD.test.avi ), manchmal führen sie zu sekundenlangem Bildsalat. Und die Effekte sind auch noch unterschiedlich, je nach Player, den man für die geschnittene Datei nutzt.
Deshalb nochmals die Bitte an OTR: Verratet uns die Schnittparameter, die ihr verwendet. Es gibt bestimmt so an die einhundert verschiedene Parameter, die man einstellen kann. Ich bin schon nahe dran, aber es fehlt immer noch etwas, und bei sovielen Parametern kann man endlos herumexperimentieren.
Noch ein Nachtrag. Beim alten Format erhielt man mit mediainfo (aus dem Header) folgende Information (HD Aufzeichnung):
Encoding settings : cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / fade_compensate=0.10 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=23.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Bei dem neuen Format fehlen diese Angaben leider im Header.
Hallo,
bzgl. der Parameter, außer "-preset slow" keine weiteren Einstellungen. Der Codec ist h264_nvenc, also Hardware-Encoding mit Nvidia-Grafikkarten. Feintuning war (falls nötig) für später geplant ;)
Hoffe das hilft weiter... wie genau da die Detaileinstellungen bei diesem Preset sind, weiß ich nicht :-|
Voyager Fan
31.03.2020, 13:40
Hallo,
Es wäre bestimmt sinnvoll, wenn die die hier testen auch die dabei verwendeten Aufnahmen benennen.
Ich kann z.B. Der_Blob_Schleimiger_Superorganismus_20.03.21_21-50_arte_55_TVOON_DE.mpg.HD.test.avi unter Win7 mit CA 0.19.4.23, VirtualDub 1.7.8 und x264vfw 2200bm problemlos schneiden.
Falls OTR natürlich aktuell noch an den Encoding-Einstellungen rumschraubt, könnte sich das vermutlich von Tag zu Tag ändern.
Da ich gerne mittesten würde - ich arbeite mit ColdCut - habe ich mal nach im Zitat genannter Datei gesucht. Sie befindet sich auch auf den Mirrors, ABER ohne das "test" in der Dateiendung.
Warum ist das so? Sind das unterschiedliche Dateien auf OTR mit "test" und dagegen auf den Mirrors ohne "test"?
buffalo-as
31.03.2020, 14:12
@Voyager Fan:
Siehe News: "Ausbau der HD-Kapazitäten: Seit gestern gibt es bei Arte-Aufnahmen für jede Sendung eine HD-Kodierung, zu finden auf der Downloadseite unter Experimentelle Formate."
Das auf den Mirrors ist das normale HD.
Voyager Fan
31.03.2020, 15:57
@buffalo-as:
Ok danke. Ich wußte nicht, dass es verschiedene HD-Aufnahmen gibt.
Zum eigentlichen Thema:
Ich konnte Wunderwelt_Erde_20.03.31_11-00_arte_45_TVOON_DE.mpg.HD.test.avi mit ColdCut problemlos schneiden.
Ich hoffe, das ist hilfreich. Wenn nicht, dann bitte bescheid geben.
loretotr
31.03.2020, 19:28
@Voyager Fan:
Wenn Du *.HD.test.avi Dateien zum Testen schneidest, solltest Du darauf achten NICHT an Keyframes zu schneiden, da dies immer funktioniert. Bitte im Text auch darauf hinweisen.
Und natürlich ist jeder Test willkommen. :)
@Voyager Fan:
Wenn Du *.HD.test.avi Dateien zum Testen schneidest, solltest Du darauf achten NICHT an Keyframes zu schneiden, da dies immer funktioniert. Bitte im Text auch darauf hinweisen.
Und natürlich ist jeder Test willkommen. :)
Im Grunde müßten wir mit den gleichen Cutlists in verschiedenen Programmen schneiden. Außerdem liegt ja bei Arte kein Grund vor, innere Schnitte hinzuzufügen, weil ja keine Werbung drin ist. Das habe ich dann aber mal absichtlich gemacht und das Ergebnis war Bildsalat an den Schnittstellen.
Manchmal sieh eine Datei so aus, als wäre sie richtig geschnitten. Vor allem der Anfang sieht fast immer gut aus. Springt man dann aber rückwärts an den Anfang zurück, merkt man, daß da auch etwas nicht stimmt (Bildstörung). Und außerdem ist das noch unterschiedlich in verschiedenen Playern, z. B. auf ffmpeg basierenden Playern (Mplayer) oder VLC.
Voyager Fan
31.03.2020, 19:51
@loretotr:
Danke für Deinen Zuspruch :)
...aber auch für den technischen Hinweis bzgl. der Keyframes.
Jetzt habe ich leider eine blöde Gegenfrage: Wie erkenne ich in ColdCut, ob ich an einem Keyframe schneide oder nicht?
Es gibt in ColdCut hauptsächlich Buttons zum Springen:
- 30 sek vor/zurück
- 10 Frames vor/zurück
- 1 Frame vor/zurück
Aber es gibt nicht "Springe zu nächstem/vorigem Keyframe", wie in avidemux.
loretotr
01.04.2020, 10:39
@Voyager Fan:
Die Keyframes liegen beim Test-Format bei 0, 250, 500, 750 usw. Frames. In Sekunden: 0, 5, 10, 15 usw. Sekunden
Wie Guenni bereits anmerkte macht es zu Testzwecken Sinn zufällige Schnitte zu platzieren, auch wenn keine Werbung enthalten ist.
Ich habe einmal eine Test-Cutlist für Wunderwelt_Erde_20.03.31_11-00_arte_45_TVOON_DE.mpg.HD.test.avi erstellt und hochgeladen.
EDIT: Ok, die Cutlist war Mist. Habe eine neue Version hochgeladen. Schnitte jetzt auf Szenenwechseln.
EDIT2: Ich habe jetzt einmal Coldcut installiert und die Datei mit der Test-Cutlist2 geschnitten. Ergebnis: Perfekter Schnitt. Da sage ich: Hut ab! :)
Für Interessierte:
Mediainfo zur geschnittenen Datei (https://raw.githubusercontent.com/gCurse/support/master/Wunderwelt_Erde_20.03.31_11-00_arte_45_TVOON_DE.mpg.HD.test.mediainfo.txt)
Voyager Fan
01.04.2020, 14:52
@Voyager Fan:
Die Keyframes liegen beim Test-Format bei 0, 250, 500, 750 usw. Frames. In Sekunden: 0, 5, 10, 15 usw. Sekunden
Wie Guenni bereits anmerkte macht es zu Testzwecken Sinn zufällige Schnitte zu platzieren, auch wenn keine Werbung enthalten ist.
Danke erneut - für diese beiden Infos/Hinweise!
EDIT2: Ich habe jetzt einmal Coldcut installiert und die Datei mit der Test-Cutlist2 geschnitten. Ergebnis: Perfekter Schnitt. Da sage ich: Hut ab! :)
Bravo! Gut gemacht. :)
Da warst Du schneller mit dem Test in ColdCut. ;-)
loretotr
01.04.2020, 18:43
@Voyager Fan:
Was mir noch einfiel: Hast Du auch eine NVIDIA GraKa? Falls ja, bräuchten wir noch einen Test von jemandem, der keine NVIDIA hat. (Für den Fall, dass ffdshow 'klammheimlich' die Hardware nutzt und es nur deshalb funktioniert?)
Ich habe mir die Mediainfo-Datei zu der Sendung mal runtergeladen und versucht, auszuwerten.
Was mir zunächst auffiel: ColdCut verwendet eine x264-Version die mehr als zehn Jahre alt ist! Einige Parameter haben sich inzwischen geändert (Namen) oder sind erweitert worden.
Aucht OTR hat bislang recht alte Softwareversionen verwendet, die sich aber alle mit aktuellen x264 Versionen schneiden lassen.
Mein Versuch, mit den (bzw. ähnlichen) Einstellungen aus der Mediainfo-Datei x264 zu konfigurieren und zu schneiden (mit der bekannten 2. Fassung der Schnittliste) bringt derzeit nur ziemlich katastrophale Ergebnisse.
Das Hauptproblem besteht wohl darin, daß Nvidia nirgendwo dokumentiert hat, welche Einstellungsparameter mit "-preset slow" gesetzt werden. Bei X264 ist das anders. Da sind alle Presets sauber dokumentiert.
Voyager Fan
01.04.2020, 19:59
@Voyager Fan:
Was mir noch einfiel: Hast Du auch eine NVIDIA GraKa? Falls ja, bräuchten wir noch einen Test von jemandem, der keine NVIDIA hat. (Für den Fall, dass ffdshow 'klammheimlich' die Hardware nutzt und es nur deshalb funktioniert?)
Meine GraKa ist eine "AMD Radeon R7".
Ich habe zur Sicherheit noch Deine Test-Cutlist für Wunderwelt_Erde_20.03.31_11-00_arte_45_TVOON_DE.mpg.HD.test.avi probiert -> Resultat: alles ok
loretotr
04.04.2020, 23:03
@Voyager Fan: Sehr schön. Also keine Hardware-Nutzung (Meine Idee war ohnehin Nonsens, wenn man das Alter der ffdshow-Version bedenkt).
Mein "Hut ab" gilt damit VirtualDub und ffdshow.
Das Schneiden der HD.test-Dateien gelingt auch otr-verwaltung3p unter Zuhilfenahme von VirtualDub und ffdshow mit wine. Und das ohne die Einstellungen zu verändern!
@Voyager Fan: Sehr schön. Also keine Hardware-Nutzung (Meine Idee war ohnehin Nonsens, wenn man das Alter der ffdshow-Version bedenkt).
Mein "Hut ab" gilt damit VirtualDub und ffdshow.
Das Schneiden der HD.test-Dateien gelingt auch otr-verwaltung3p unter Zuhilfenahme von VirtualDub und ffdshow mit wine. Und das ohne die Einstellungen zu verändern!
Ja, das habe ich heute auch getestet (meine alte otrverwaltung++ mit vdub). Auch hier wir eine sehr alte x264 library verwendet.
Mit der aktuellen x264-Version (mit der ich alles andere schneiden kann) und SmartMKVmerge kriege ich es aber einfach nicht hin. Die einzelnen Schnipsel sind OK, aber nach dem Zusammenfügen ergibt sich an den Schnittstellen Bildsalat (je nach Einstellungen unterschiedlich). Dabei habe ich auch die Einstellungen probiert, die VDUB in der Datei hinterlassen hat. Aber die sind eigentlich unlogisch, weil sie nicht komplett zum Main@3.2 Profil passen.
loretotr
08.04.2020, 20:38
@guenni
Mit dem Encoding komme ich auch nicht weit.
Aber: Wenn die zusammenzufügenden Teile nicht als mkv, sondern als raw-video (*.h264) vorliegen und man solche Teile mit mkvmerge zusammenfügt, kann man das Ergebnis fehlerfrei abspielen.
Gleiches gilt auch für ffmpeg's concat (https://trac.ffmpeg.org/wiki/Concatenate). (Ist aber extrem langsam).
EDIT: Ah, ich sehe gerade, dass Du das Encoding "geknackt" hast :)
Heureka! Es hat endlich geklappt. Ich habe heute eine Möglichkeit gefunden, das neue HD-Format mit SmartMKVMerge ohne Fehler zu schneiden.
@loreotr: Es funktioniert auch ohne das raw stream Format, also direkt mit MKV-Dateien. Ich könnte dir die nötigen Änderungen zur Verfügung stellen. Allerdings verwende ich ausschließlich x264. Für ffmpeg müßtest du es selbst anpassen.
Jetzt sollten endlich alle Windows-Programme mal getestet werden, damit wir OTR das OK geben können. Prinzipiell sollte es ja mit allen Programmen laufen, die VirtualDub zum Schneiden verwenden. Aber das muß halt getestet werden.
Sehr schön 👍
… Ich könnte dir die nötigen Änderungen zur Verfügung stellen. …
Ich wäre dafür auch sehr dankbar :)
loretotr
09.04.2020, 09:55
@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.
0daredevil0
09.04.2020, 10:57
Außer wir steigen um auf h265 und mp4/mkv-Container.
Hallo,
Bzgl. Endgeräte: Kann nur für PCs sprechen, da ist sowas ja kein Problem. Das dann einige "Kleingeräte" rausfallen, ist auch wahrscheinlich. En- und Dekodierung ist von der Rechenleistung her aufwendiger, ja.
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.
loretotr
09.04.2020, 11:24
@guenni: Ja, ich bin gcurse :) Und ich bin der aktive Developer von otrv3p.
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.
@guenni: Ja, ich bin gcurse :) Und ich bin der aktive Developer von otrv3p.
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.
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".
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.
https://up.picr.de/38248511wr.jpg
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
09.04.2020, 22:47
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.
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
10.04.2020, 11:35
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
10.04.2020, 11:50
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
10.04.2020, 12:38
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.
@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.
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.
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.
Solange HQ das Standardformat bleibt, nichts dagegen.
Ansonsten gibt es "Speicherplatznöte" für Sammler wie meiner einer.
HDD's sind zwar viel günstiger als früher, aber 8TB Platten kosten auch noch über 200 € das Stück.
Mit einer ist es dann nicht getan.
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.
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
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
Soweit ich das sehe, gibt es keine Probleme mehr. Alle auf VirtualDub basierenden Programme scheinen problemlos zu funktionieren. Otrverwaltung3p und rpiotrtool wurden angepasst. Von mir aus kann es losgehen.
soweit ich das rausgelesen habe, sind die Schnittprobleme soweit gelöst, sodass wir auf das neue Format umstellen können?
Für mich spricht nichts dagegen.
Ich habe zwar das Cutana-Problem noch nicht gelöst.
Aber bei Windows gibt es mit dem CutAssistenten und ColdCut keine Probleme.
Kurz: Hau rein!
ok, Arte ist ab jetzt mal umgestellt, also keine HD.test-Dateien mehr, alles als "reguläre" HD.avi-Dateien (mit neuer Kodierung).
Ab morgen voraussichtlich mindestens ein weiterer Sender, danach nach und nach mehr.
Werden die in HD umgestellten Sender auch weiterhin in 100% HQ angeboten?
TlatoSMD
15.06.2020, 00:49
HD als Standardformat finde ich aktuell noch nicht praktikabel. Allein die jeweiligen Dateigrößen sprengen den Rahmen.
Ich selbst bin ein "Sammler" gerade von älteren Serien/Filmen, da stößt man schnell an Kapazitätsgrenzen der Speicher.
Zumal man sich noch eine Sicherung anlegt. Festplatten halten nicht ewig.
Gerne können mehr Filme/Dokus in HD aufgezeichnet werden, aber für die ganzen Dokusoaps/Telenovelas (auch ÖR-TV) usw. reicht HQ vollkommen aus.
Diese "Test-HD" sind zur Zeit aber nur über OTR verfügbar, oder?
Ich dachte, es geht hier darum, daß die Dateien von OTR selber als HD aufgenommen werden, und dann rechnet OTR die HDs zu HQs und mp4s runter, um dann alle drei Möglichkeiten gleichzeitig anzubieten (oder auch nur die HQs und mp4s)? Es wäre von daher schonmal ein Vorteil, weil dann hoffentlich auch die HQs wenigstens wieder ansatzweise so gut wie analoges SD-Kabelfernsehen oder professionelle DVDs aussehen. Seitdem vor Jahren ja die Datenrate von HQ reduziert wurde, war kaum noch ein Unterschied mehr zwischen HQ und digitalen SD-TV-Streams zu erkennen, die wegen viel zu niedriger Datenrate wiederum wie MPEG-1-Dateien mit der Auflösung 320 * 240 Pixel auf VCDs wie aus den frühen 90ern aussehen.
Wenn OTR jetzt stattdessen wenigstens die ÖRs standardmäßig in HD aufnimmt, um dann auf HQ usw. runterzurechnen, verbessert sich hoffentlich die Qualität wieder.
TlatoSMD
15.06.2020, 00:56
Streng genommen gibt es kein "Standard-h264".
Innerhalb des Codecs gibt es div. Einstellungsmöglichkeiten.
Ein Versuch mit Cutana ergab, dass der Schitt misslang, da die h264-Einstellungen nicht kompatibel seien.
Ich will hier mal über meine weiteren Versuche berichten. Ich habe zunächst eine Routine geschrieben, die die beiden HD-Formate unterscheiden kann und unterschiedlich behandelt. Danach konnte ich dann mit dem neuen Format herumexperimentieren.
Es gibt leider immer noch Probleme an den Schnittstellen. [...]
Deshalb nochmals die Bitte an OTR: Verratet uns die Schnittparameter, die ihr verwendet. Es gibt bestimmt so an die einhundert verschiedene Parameter, die man einstellen kann. Ich bin schon nahe dran, aber es fehlt immer noch etwas, und bei sovielen Parametern kann man endlos herumexperimentieren.
Ich denke, euer Problem besteht einfach grundsätzlich darin, daß ihr Cutter ständig neu komprimiert und damit ohnehin die Qualität nur noch weiter ruiniert, egal ob: "Bildsalat" an den Schnittkanten oder nicht. Und das bloß, weil ihr unbedingt framegenau schneiden wollt, obwohl wir's hier grundätzlich mit Interframe-Videos zu tun haben.
Ihr könntet auch ganz einfach ohne Neukomprimierung per Direct Stream Copy schneiden. Dann müßt ihr auch rein garnichts einstellen. Freilich braucht ihr dafür 1.) ein Programm wie VDub, daß die Keyframes findet (um: "Bildsalat" zu vermeiden), und 2.) müßt ihr in Kauf nehmen, daß dann an den Schnittkanten immer ca. 1-2 Sekunden mehr übrigbleibt (aber eben nicht als Salat). Eben wie früher, wenn man per Hand mit dem Videorekorder aufgenommen und die Werbung von Hand selber rausgeschnitten hat.
Ich denke, euer Problem besteht einfach grundsätzlich darin, daß ihr Cutter ständig neu komprimiert und damit ohnehin die Qualität nur noch weiter ruiniert, egal ob: "Bildsalat" an den Schnittkanten oder nicht. Und das bloß, weil ihr unbedingt framegenau schneiden wollt, obwohl wir's hier grundätzlich mit Interframe-Videos zu tun haben.
Ihr könntet auch ganz einfach ohne Neukomprimierung per Direct Stream Copy schneiden. Dann müßt ihr auch rein garnichts einstellen. Freilich braucht ihr dafür 1.) ein Programm wie VDub, daß die Keyframes findet (um: "Bildsalat" zu vermeiden), und 2.) müßt ihr in Kauf nehmen, daß dann an den Schnittkanten immer ca. 1-2 Sekunden mehr übrigbleibt (aber eben nicht als Salat). Eben wie früher, wenn man per Hand mit dem Videorekorder aufgenommen und die Werbung von Hand selber rausgeschnitten hat.
Die Keyframes liegen bei OTR-Aufnahmen zwischen 3 und 10 Sekunden auseinander (variabel, beim neuen HD-Format exakt 5 Sekunden). Wenn du mit so einem Schnitt-Müll zufrieden bist, ist das deine Sache. Ich jedenfalls nicht.
Ich schneide jedenfalls seit 14 Jahren alles framegenau. Mit der richtigen Software und Cutlist (natürlich auch mal selber machen und teilen) ist das kein Problem. Auch beim neuen HD-Format nicht. Das haben wir Softwareentwickler weitgehend in den Griff gekriegt.
Ich denke, euer Problem besteht einfach grundsätzlich darin, daß ihr Cutter ständig neu komprimiert und damit ohnehin die Qualität nur noch weiter ruiniert
Dann denkst Du falsch. Komplett falsch.
Da Du von falschen Voraussetzungen ausgehst spare ich mir den Rest.
Dann denkst Du falsch. Komplett falsch.
Da Du von falschen Voraussetzungen ausgehst spare ich mir den Rest.
Da das ja vielleicht auch noch andere interessiert, will ich doch noch etwas hinzufügen:
Wir verwenden ja "SmartRendering". Das bedeutet, daß nur winzige Bereiche des Videos (rund um die Schnittpunkte) neu enkodiert werden. 99.x% des Videos werden einfach kopiert (also auch kein Qualitätsverlust).
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.