ffmpeg m3u8_hold_counters und seg_max_retry parameter hinzufügen

[lukastribus]

Hallo,

wie im Forum beschrieben:

https://forum.mediathekview.de/topic/4864/srf-ton-ab-filmmitte-asynchron/31

lösen die ffmpeg Argumente:

-m3u8_hold_counters 1 -seg_max_retry 1

das Problem dass Streams mit fehlendem HLS Segmenten heruntergeladen werden, die Fehler ignoriert werden und der User dann eine korrupte Video Datei mit Sync Problemen usw hat.

Mit diesen Argumenten bricht ffmpeg ab, und Mediathekview zeigt den Fehler auf.

Kann das in die Codebase übertragen werden damit alle User davon profitieren?

Achtung: -seg_max_retry scheint erst ab ffmpeg 6 verfügbar zu sein.

Danke!

[ghost]

Das Übertragen in die Codebase halte ich für keine gute Idee, Krücken gehören nicht dahinein.

Niemand hindert dich daran, für solche Fälle ein entsprechendes SET zu erstellen, in dem du die Parameter für ffmpge hinzufügst.
Außerdem ist überhaupt nicht gewährleistet, dass die fehlenden Teile in den Segmenten auch tatsächlich integriert werden.
Und dass der Sender für solche Tricks Verständnis hat und auf Dauer toleriert, wage ich mal zu bezweifeln.

[DaDirnbocher]

Außerdem ist überhaupt nicht gewährleistet, dass die fehlenden Teile in den Segmenten auch tatsächlich integriert werden.

Das ist ja auch gar nicht der Sinn der Änderung. Ganz im Gegenteil: aktuell wird dem User in gewissen Fällen signalisiert, dass "alles ok war" obwohl es das genau nicht war. Die Änderung soll erreichen, dass für diese Fälle, MV einen Fehler anzeigt.

Besser wäre natürlich, wenn solche eigentlich depublizierten Sendeungen in der Filmliste gar nicht mehr vorkommen, aber als Plan B scheint mir das Ticket doch sinnvoll.

Was spricht dagegen, neben den aktuellen Set-Vorlagen, die man jetzt schon mportieren kann, auch eine Vorlage mit diesen Schaltern anzubieten?

[vitusson]

Außerdem ist überhaupt nicht gewährleistet, dass die fehlenden Teile in den Segmenten auch tatsächlich integriert werden.
Und dass der Sender für solche Tricks Verständnis hat und auf Dauer toleriert, wage ich mal zu bezweifeln.

Glückwunsch, nicht verstanden um was es überhaupt geht aber Hauptsache mal mitgeredet.

[ghost]

Das ist ja auch gar nicht der Sinn der Änderung. Ganz im Gegenteil: aktuell wird dem User in gewissen Fällen signalisiert, dass "alles ok war" obwohl es das genau nicht war. Die Änderung soll erreichen, dass für diese Fälle, MV einen Fehler anzeigt.

Wenn das im Programm integriert wird, ist der Ersteller des Programms verantwortlich. Was der User selbst einfügt, ist seine Sache und im Fall der Fälle wird ER auch zur Verantwortung gezogen. Der Sender depubliziert einen Beitrag ja nicht, um Anwender zu verärgern, sondern mit hoher Wahrscheinlichkeit aus rechtlichen Gründen. Ansonsten wäre der Beitrag ja wohl auch in der Mediathek des Senders noch verfügbar.

@vitusson: Herr, lass Hirn regnen, möglichst viel und vor allem schnell !

Haut euch, stänkert, ich bin hier raus.

[lukastribus]

Der Sender depubliziert einen Beitrag ja nicht, um Anwender zu verärgern, sondern mit hoher Wahrscheinlichkeit aus rechtlichen Gründen. Ansonsten wäre der Beitrag ja wohl auch in der Mediathek des Senders noch verfügbar.

Zur Zeit ignoriert MV diese Intention des Senders und downloaded alle verfügbaren Segmente runter, die dann zu einer korrupten Datei zusammengefügt werden.

Die vorgeschlagene Änderung sorgt dafür dass der Download so schnell wie möglich abbricht und als fehlerhaft gekennzeichnet wird, also ganz im Sinne des Senders.

Es handelt sich nicht um eine Krücke sondern um die korrekte Konfiguration von ffmpeg, damit bei einem Fehler auch abgebrochen wird.

[MuenchenSued]

Ich sehe bei meinen Skript basierten ffmpeg Downloads ab und zu, dass der Zugriff auf einige wenige Segmente nicht auf Anhieb klappt sondern mehrere Versuche braucht. Würde hier bereits nach dem ersten Fehler abgebrochen, so würde es bei mir oft kaputte Ergebnisse geben. Ich habe noch nicht verstanden, was diese zwei neuen Parameter bewirken und welche Auswirkungen sie bei kurzzeitigen Verbindungsproblemen hätten, die ffmpeg normalerweise gut abfängt. Daher würde ich es momentan auch in der Verantwortung der Anwender belassen, sich ein entsprechendes Set für den SRF anzulegen.

[styroll]

@drandreaskrueger sagte in diesem Thread: Das eingefügte -m3u8_hold_counters 1 -seg_max_retry 1 hat sonst keine Nebenwirkungen, man kann es also einfach immer drin lassen?

Ich hatte das mal einige Monate drin, bis bei einer ORF-Sendung der Download von MV als "fehlerhaft" ausgegeben wurde und das Entfernen dieser Schaltereinstellung in einem einwandfreien Download resultierte.

Ich habe jedoch einen speziellen Use case: Für den Eigenbedarf lade ich regelmässig SRF-Sendungen runter (2–3 Videos pro Woche), aber immer zeitnah, so dass ich die zusätzliche Schaltereinstellung eigentlich gar nicht brauche. Allerdings lade ich auch regelmässig zu Testzwecken zum Lösen von Forumsproblemen anderer User ORF-Sendungen runter. Und dazu bin ich dann besser mit den Default-ORF-Schalter-Einstellungen unterwegs…