SRF - Ton ab Filmmitte asynchron

[vitusson]

@brainstuff *plonk* wg OT-Geschwafel

[lukastribus]

Hallo,

könnte man hier zur Verbesserung der User Experience bei fehlenden TS Segmenten den Download mit einer Fehlermeldung abbrechen, anstatt diese dann falsch zusammenzumuxen und Erfolg zu suggerieren?

Dass es ein Sync Problem gibt kommt man in vielen Situationen erst nach einigen Minuten - oft auf bereits auf der Couch - drauf, “fail early” wäre hier glaube ich hilfreich.

Danke

[styroll]

@lukastribus sagte: könnte man hier zur Verbesserung der User Experience bei fehlenden TS Segmenten den Download mit einer Fehlermeldung abbrechen

Sinnvoller wäre es, solche depublizierte Sendungen aus der Liste entfernen zu lassen (was eine Zusatzprüfung, die erst zu finden wäre, bedingen würde, da leider die Playlist-URL immer noch gültig ist).

EDIT:

Eine Prüfung die jeder selber vornehmen kann: Die URL zur Sendung (unten links, “Link zur Website”) anklicken

Da hat einer wieder etwas nicht verstanden und zitiert meine eigenen Aussagen weiter zurück in diesem Thread…

[mac-christian]

@styroll Eine Prüfung die jeder selber vornehmen kann: Die URL zur Sendung (unten links, “Link zur Website”) anklicken, dann sieht er/sie, ob die Sendung noch verfügbar ist oder nicht. Wenn nicht, einfach nicht versuchen, runterzuladen…

[Georg-J]

@lukastribus sagte in SRF - Ton ab Filmmitte asynchron:

Hallo,

könnte man hier zur Verbesserung der User Experience bei fehlenden TS Segmenten den Download mit einer Fehlermeldung abbrechen, anstatt diese dann falsch zusammenzumuxen und Erfolg zu suggerieren?

Dazu müsste MV den Download der einzelnen Chunks selbst durchführen oder ffmpeg müsste für diesen Fehlerfall erweitert werden.

[lukastribus]

@mac-christian sagte in SRF - Ton ab Filmmitte asynchron:

Eine Prüfung die jeder selber vornehmen kann: Die URL zur Sendung (unten links, “Link zur Website”) anklicken, dann sieht er/sie, ob die Sendung noch verfügbar ist oder nicht. Wenn nicht, einfach nicht versuchen, runterzuladen…

Natürlich gibt es immer Workarounds, mit guter User Experience hat das aber nichts zu tun.

Der Sinn wäre dass man das Problem frühzeitig erkennt bevor man diesen Forum Thread liest und mit dieser Problematik sehr vertraut ist.

@Georg-J sagte in SRF - Ton ab Filmmitte asynchron:

Dazu müsste MV den Download der einzelnen Chunks selbst durchführen oder ffmpeg müsste für diesen Fehlerfall erweitert werden.

Danke. Gibt es irgendwo (auch im Source code) Hinweise darüber, mit welchen Parametern ffmpeg von MV aufgerufen wird?

Wenn ich solch eine m3u URL direkt an ffmpeg übergebe, dann kriege ich einen endlosen 404 Not Found Fehlersturm heraus. Deswegen wäre es wichtig zu verstehen wie ffmpeg aufgerufen wird, wenn wir hier Verbesserungen bei ffmpeg erreichen möchten.

Vielen Dank

[vitusson]

@lukastribus sagte in SRF - Ton ab Filmmitte asynchron:

Danke. Gibt es irgendwo (auch im Source code) Hinweise darüber, mit welchen Parametern ffmpeg von MV aufgerufen wird?

Die stehen in den Einstellungen in deinem Set zum Herunterladen. Und im Log, dafür brauchst du keinen Source-Code.
Und in den Set-Einstellungen kannst du sie auch ändern.

Aber frag mich nicht welche der hunderte von Schaltern helfen könnte.
Vom schnell drüberschauen könnte sich “-m3u8_hold_counters” anbieten

       m3u8_hold_counters
           The maximum number of times to load m3u8 when it refreshes without new segments.  Default value is 1000.

1000 scheint mir doch sehr großzügig. Siehe auch https://trac.ffmpeg.org/ticket/8434
Nützlich wäre es mal eine konkrete URL zum testen zu haben.

[lukastribus]

@vitusson

Beispiel Sendung:
Sender:SRF
Titel: Der Schwarm (Staffel 1, Folge 1)
Datum: 22.02.2023

Beispiel URL:

https://srf-vod-amd.akamaized.net/world/hls/derschwarm/2023/02/derschwarm_20230222_151728_17738342_v_webcast_h264_,q40,q10,q20,q30,q50,q60,.mp4.csmil/index-f6-v1-a1.m3u8

ffmpeg argumente wie:

-m3u8_hold_counters 1
-seg_max_retry 1
-max_reload 1
-xerror

scheinen alle nichts zu nützen.

[MenchenSued]

@lukastribus
Ich habe den Link mal mit yt-dlp herunter geladen und dabei stellt man fest, dass 10 von 270 Segmenten nicht gefunden und übersprungen werden. Wenn ich den Link mit geringer Auflösung (index-f5) verwende, bekomme ich nur die ersten 2 von 270 Segmenten. MV stellt bei der Prüfung vermutlich fest, dass die Datei noch existiert, prüft aber nicht den Inhalt auf Konsistenz.

[styroll]

@MenchenSued sagte: Ich habe den Link mal mit yt-dlp herunter geladen und dabei stellt man fest, dass 10 von 270 Segmenten nicht gefunden und übersprungen werden.

Und was hat das mit Anliegen von @lukastribus zu tun? Er weiss ja, dass die fehlenden Segmente Ursache für die AV-Sync-Probleme sind, was ja gerade in diesem Thread auch erklärt wurde…

@MenchenSued sagte: MV stellt bei der Prüfung vermutlich fest, dass die Datei noch existiert, prüft aber nicht den Inhalt auf Konsistenz.

Welche Datei? Die Playlist-Datei ist noch da und deren Inhalt ist natürlich auch konsistent, aber verweist teilweise auf Segmente, die nicht mehr existieren, wo sich die Frage der Konsistenz somit gar nicht erst stellt. Aber auch das steht schon sinngemäss in diesem Thread…

[lukastribus]

@vitusson m3u8_hold_counters war ein gutes Stichwort.

Die Lösung des Problems wird erreicht durch die Kombination der beiden Argumente:

-m3u8_hold_counters 1 -seg_max_retry 1

Im Setz Speichern hinzufügen:

Nur noch vollständige Downloads scheinen als “Fertig” auf, die fehlerhaften Downloads brechen ab, dann hat die Datei lediglich ein paar Minuten Laufzeit (anstatt volle Länge mit desync und fehlenden Segmenten) und der Download wird in Mediathekview korrekterweise als fehlerhaft bezeichnet:

[vitusson]

@lukastribus sagte in SRF - Ton ab Filmmitte asynchron:

@vitusson m3u8_hold_counters war ein gutes Stichwort.

Die Lösung des Problems wird erreicht durch die Kombination der beiden Argumente:

-m3u8_hold_counters 1 -seg_max_retry 1

Das klingt doch gut.

[styroll]

@lukastribus sagte: Die Lösung des Problems wird erreicht durch die Kombination der beiden Argumente:
-m3u8_hold_counters 1 -seg_max_retry 1

Sehr schön, da werden wohl einige Benutzer dankbar sein, diesen Schalter verwenden zu können.
Ich hab das auch gleich erfolgreich verifizieren können (auch wenn ich die Prüfung selbst nicht benötige, da ich weiss, dass internationale Produktionen beim SRF grundsätzlich nach einer Woche depubliziert werden).

Das zweite Mal Aufführen von “-m3u8_hold_counters” nach der URL (Parameter %f) – wie das dein Screenshot zeigt – dürfte nicht nötig sein, oder?
Ich zumindest kriegte ohne “-m3u8_hold_counters 10” bei deinen zwei Beispielfilmen das gleiche (gewünschte) Resultat.

[lukastribus]

@styroll sagte in SRF - Ton ab Filmmitte asynchron:

Das zweite Mal Aufführen von “-m3u8_hold_counters” nach der URL (Parameter %f) – wie das dein Screenshot zeigt – dürfte nicht nötig sein, oder?
Ich zumindest kriegte ohne “-m3u8_hold_counters 10” bei deinen zwei Beispielfilmen das gleiche (gewünschte) Resultat.

Richtig, nicht notwendig, war ein Überbleibsel eines vorherigen Tests. Werde den Screenshot nochmal austauschen damit es klarer ist.

[vitusson]

@vitusson sagte in SRF - Ton ab Filmmitte asynchron:

@lukastribus sagte in SRF - Ton ab Filmmitte asynchron:

@vitusson m3u8_hold_counters war ein gutes Stichwort.

Die Lösung des Problems wird erreicht durch die Kombination der beiden Argumente:

-m3u8_hold_counters 1 -seg_max_retry 1

Das klingt doch gut.

Wobei man anmerken muß daß es “-seg_max_retry” erst ab ffmpeg Version 6 gibt, der abgehangene 5.1 in Debian stable zB tut es nicht und nur mit “-m3u8_hold_counters” lädt der fröhlich weiter den ganzen Kram runter

[lukastribus]

@vitusson Stimmt, ffmpeg 6.0 ist notwendig (in den Debian repositories ab trixie - was zur Zeit debian testing ist).

[vitusson]

@lukastribus sagte in SRF - Ton ab Filmmitte asynchron:

@vitusson Stimmt, ffmpeg 6.0 ist notwendig (in den Debian repositories ab trixie - was zur Zeit debian testing ist).

Alternativ: Das Debian Multimedia Repository von Christian Marillat nutzen, dessen Pakete sind immer weitaus aktueller und dort gibt es auch 6.0 für stable
http://www.deb-multimedia.org/dists/stable/main/binary-amd64/package/ffmpeg

[marqui]

@styroll sagte in SRF - Ton ab Filmmitte asynchron:

Sinnvoller wäre es, solche depublizierte Sendungen aus der Liste entfernen zu lassen

Finde ich ganz und gar nicht. Was soll hier bitteschön sinnvoll sein? Sollte man auf die beste ÖR-Mediatheken-Qualität wegen diesen mickrigen 10 Sekunden verzichten? Die Sendungen werden in den Anstalten eh kreuz und quer nach Belieben geschnitten. Die Kleinigkeit mit Asynchron-Audio lässt sich bekanntlich durch Audiospur-Synchronisation in jedem vernünftigen Player in zwei Sekunden beheben.

[tvRR]

@marqui Der Punkt ist doch, dass die Sendung gar nicht mehr online sein dürfte, weil Lizenzlaufzeit beendet oder eine Rundfunkstaatsvertragsregel einzuhalten ist. Dann zu fordern, sie solle gefälligst dennoch herunterladbar sein, passt da nicht ganz.

[nash 0]

Ich habe das gleiche Problem mit srf. In vlc wird eine Framerate von ca. 21.xx bis 24.xx angezeigt.
Offensichtlich laufen Video und Audio nicht synchron mit 25fps.

Ich benutze ffmpeg um die framerate auf 25fps zu setzen.

Die streams von video+audio extrahieren und dann ein neues File mit korr. fps anlegen.
Kann man sicher noch optimieren, aber ich habe jetzt erstmal keine Lust mehr hier damit rumzufrickeln.
Für mich funktionierts.

ffmpeg -y -i “Film-«EinFilm»mp4” -map 0:v -c:v copy -bsf:v h264_mp4toannexb “bitstream.h264”
ffmpeg -y -i “Film-«EinFilm»mp4” -map 0:a -c:a copy “bitstream.aac”
ffmpeg -y -fflags +genpts -r 25 -i “bitstream.h264” -c:v copy “output_video.mp4”
ffmpeg -i “output_video.mp4” -i “bitstream.aac” -map 0:v -map 1:a -c:v copy -c:a copy “output_video+audio.mkv”