ORF-Kurzbeiträge fehlerhaft?

[DaDirnbocher]

Bei sehr kurzen ORF-Beiträgen (vielleicht auch SRF - keine Ahnung) kommt es vor, dass die Downloads als fehlerhaft gekennzeichnet werden, wobei (für mich) unklar ist, ob sie wirklich fehlerhaft sind.

Beispiel Wetter Wien vom 5.1.2021 19;20, Dauer lt. Filmliste 00:00:59.

Vor Beginn des Downloads liefert ffmpeg (ebenfalls) eine Duration von 00:00:59.00:

Am Ende des Dowloads meldet ffmpeg eine time von 00:00:58.66

Wenn man die beiden Werte in Relation setzt ist das 99,4237%, was MV auch im LOG protokolliert:

. Download fehlgeschlagen: 99,5% wurden nicht erreicht

Was ich nicht beurteilen kann, ob der Download wirklich fehlerhaft war (und 0,34 sek tatsächlich fehlen, abspielbar ist das mp4 jedenfalls) oder ob MV einen Scheinfehler wegen einer mögliche Rundungsgeschichte anzeigt (Duration lt ffmpeg bzw. Dauer lt. Filmliste ist vielleicht auf ganze Sekunden aufgerundet).

Im letzteren Fall wäre es vielleicht sinvoll für den Vergelcih die "Endlänge" auf ganze Sekunden aufzurunden.

Wenns um ein (Auf-)Rundungsthema geht, betriffts damit max. Sendungen mit einer Länge kleiner oder gleich 3 min 20 sek.

Weitere Beispiele/Diskussionen/INfos gibts im Forum.

[styroll]

Ergänzung zum obigen Post zwecks besserer Grundlage zur Fehleranalyse:

@DaDirnbocher sagte: Bei sehr kurzen ORF-Beiträgen (vielleicht auch SRF - keine Ahnung) kommt es vor, dass die Downloads als fehlerhaft gekennzeichnet werden

Bei SRF-Sendungen (Clips), die ähnlich kurz sind (also < 3 min) gibt es das Problem nicht, was zeigt, dass es am ORF-Video-Material liegt. Und woran habe ich dargelegt.

@DaDirnbocher sagte: Weitere Beispiele/Diskussionen/INfos gibts im Forum.

Und dort ist klar ersichtlich, dass es kein Problem von FFmpeg ist, welches ja nur meldet, was Sache ist, sondern wie MV 13.7 auf die Meldungen von FFmpeg reagiert (und zwar anders als MV 13.6 und ältere Versionen – aus welchen Gründen auch immer):

@styroll sagte: Fakt ist, dass man z.B. die besagte Sendung “Wetter Wien 30.12.20” mit MV 13.6.0 ohne Fehlermeldung vonseiten MV herunterladen kann. Auch kriegt man keine Fehlermeldung vonseiten MV, wenn man MV 13.0.6 (ja eine alte Version) und die mit MV 13.7 gepackte FFmpeg-Version verwendet.

[DaDirnbocher]

Bei SRF-Sendungen (Clips), die ähnlich kurz sind (also < 3 min) gibt es das Problem nicht,

Das hängt halt davon ab, was man als "das Problem" ansieht.

Ich sehe das Problem darin, dass es 2 Längenangaben gibt - eine vor dem Download, eine nach dem Download, die - wie die Beispiele zeigen - halt unterschiedlich sein können.

Und diesem Umstand gibt es sehr wohl bei SRF auch, z.B.

was auch ffmpeg meldet:

Nach dem Download ist die Sendung aber sogar fast 4 Sekunden länger:

MV prüft halt auf Zeit2 < 99,5% von Zeit1 und damit werden Sendungen die länger als erwartet sind, nicht als fehlerhaft gekennzeichnet.

Vielleicht ist die Angabe nach dem Download bei SRF immer größer als vorm Download und fällt deshalb bei der Prüfung durch MV nicht auf. Mag sein, kann ich nicht beurteilen, weil ich weder Zeit noch Lust habe alle SRF-Sendungen durchzuprobieren.

Aber im Grunde ist es auch egal ...

Ich sehe das Problem darin,

... wie ich das sehe. @derreisende77 wird sich das anschauen und eine Lösung dafür finden.

[styroll]

@DaDirnbocher sagte: Das hängt halt davon ab, was man als "das Problem" ansieht.

Ja, natürlich, ich bezog mich auf deine Überschrift und deine Aussage in deinem ersten Satz, also auf genau das, was ich zitiert habe. Genau dafür gibt's ja die Zitierfunktion, die leider (v.a. im Forum) viel zu wenig von den Usern benützt wird…

@DaDirnbocher sagte: weil ich weder Zeit noch Lust habe alle SRF-Sendungen durchzuprobieren.

Das ist einerseits ja nicht nötig, und andererseits wird der Entwickler diese Lust auch nicht haben, aber er ist sicher immer froh, wenn ihm einiges an genauer Fehlerbeschreibung bzw. Problemanalyse abgenommen wurde. Und in diesem Kontext ist dein SRF-Beispiel hilfreich, auch wenn dort MV nicht "fehlerhaft" meldet.

[derreisende77]

Das Problem sind frame drops die manchmal vorkommen und die Berechnung stören. Ich habe einen Workaround eingebaut um abwärtskompatibel mit anderen externen Programmen zu bleiben der bei erfolgreichem Beenden von ffmpeg prüft ob der Wert >99% war. Dann ist es erfolgreich (da es auch ffmpeg zuvor bestätigt hat). <99% bleiben sie weiterhin fehlerhaft da zuviele drops dabei waren.