Moin,
Es gab mal wieder eine neue stabile ffmpeg Version.
Beim Umschalten von SDTV Kanälen sieht man nun mehr Artefakte.
ffmpeg gibt nun fehlerhafte Frames zurück. Im Schnitt um die 14.
Die Frage ist nun: Will man diese sehen?
Johns
Moin,
Es gab mal wieder eine neue stabile ffmpeg Version.
Beim Umschalten von SDTV Kanälen sieht man nun mehr Artefakte.
ffmpeg gibt nun fehlerhafte Frames zurück. Im Schnitt um die 14.
Die Frage ist nun: Will man diese sehen?
Johns
Das ist mir auch schon aufgefallen. Kann es sein, dass dadurch das Umschalten gefühlt schneller vonstatten geht, da man eben schon die halb-kaputten P-Frames sieht und ffmpeg nicht auf ein neues I-Frame wartet?
Abgesehen davon, dass ich kaum noch SD schaue, stört mich das neuerlich Verhalten nicht wirklich. Ich finde es möglicherweise gar vorteilhaft, wegen des gefühlt schnelleren Umschaltens.
Mir wäre ein Umschalten ohne Artefakte lieber.
Wie das bei solchen Fragen eigentlich immer ist: vermutlich sollte es konfigurierbar sein (wenn es geht).
Lars.
Leider bietet gentoo 2.5.4 nicht mehr an. Zum Glück hab ich mir den ebuild davon lokal gesichert
Das ist mir auch schon aufgefallen. Kann es sein, dass dadurch das Umschalten gefühlt schneller vonstatten geht, da man eben schon die halb-kaputten P-Frames sieht und ffmpeg nicht auf ein neues I-Frame wartet?
Abgesehen davon, dass ich kaum noch SD schaue, stört mich das neuerlich Verhalten nicht wirklich. Ich finde es möglicherweise gar vorteilhaft, wegen des gefühlt schnelleren Umschaltens.
Ich meine auch, daß das Umschalten schneller geht, so bin ich auf die Ursache gestossen.
Bin aber noch am Suchen ob nicht irgendwo ein Fehler ist und so mehr kaputte Frames entstehen.
Zitat
Wie das bei solchen Fragen eigentlich immer ist: vermutlich sollte es konfigurierbar sein (wenn es geht).
Ein Patch zum Verhindern ist schon fertig. Konfigurierbar machen ist, ist Arbeit.
Johns
Moin,
also ich habe die Artefakte auf meinem Dev Rechner mit aktuellem Gentoo auch...und ich bin mir sicher, die will wirklich keiner sehen. Die sind ganz schön hässlich
Ciao Louis
Ich habe seit ca. 2 Wochen bei mir 2.6.2 und muss sagen das mir das bis jetzt noch nicht aufgefallen ist, werde das aber mal beobachten.
Vorher war ich noch bei 1.2.X glaub ich. Und ich bin mit der neuen Version auch zufrieden, bin auch der Meinung das es gefühlt schneller geht.
Grüße
Martin
GIT enthält nun einen Workaround.
Aus irgendeinen Grund ändern die Volld* von Gentoo die Version von libavcodec.
Aber die Änderungen sollten keine Auswirkung mit älteren ffmpeg Versionen haben.
libav ist nicht getestet.
Mit der Kommanzeilen Option "-w use-possible-defect-frames" kann man den Workaround ausschalten.
Wer schnelleres Umschalten mit Defekten will, kann es auch deaktivieren (-w verwenden).
Sollte dieses Problem in ffmpeg bestehen bleiben, dann kann ich es immer noch ins Setup verschieben.
Mich würde aber immer noch intressieren ist Umschaltgeschwindigkeit gleich geblieben?
Johns
Also unter "Umschaltgeschwindigkeit" verstehe ich die Zeit, zwischen dem Tastendruck (z.B. <ch+>) auf der Fernbedienung, bis zum stabilen Bild und Ton und das hat sich seit min. einem Jahr nicht verändert.
Wenn Artefakte, oder ein Blacksreen beim Umschalten kommt, dann kommt es einem halt so vor, als ob das Umschalten länger dauen würde.
Wenn das genau messen wollte, müsste man wohl im Ausgabedevice eine "Stoppuhr" einbauen, die den "Umschaltbefehl" erkennt und dann misst, wie lange es dauert, bis keine "missed frames" mehr kommen.
Macht es einen Unterschied, wenn die Option zum Clearen des decoder buffers aktiviert ist, evtl. In Verbindung mit Schwarzbild beim Umschalten?
Beim klassischen Umschaltverhalten, wo das alte Bild noch einen Moment nachläuft, ehe das neue Bild kommt, habe ich mich eigentlich immer schon gewundert, wieso das ohne Artefakte ging.
Wenn das genau messen wollte, müsste man wohl im Ausgabedevice eine "Stoppuhr" einbauen, die den "Umschaltbefehl" erkennt und dann misst, wie lange es dauert, bis keine "missed frames" mehr kommen.
Ist drin. Mit -DDEBUG kommt die Meldung "video/vdpau: synced after xxx frames yyy ms".
Ohne Debug lkommt "video/vdpau: synced after yyy frames".
Das misst wann Bild und Ton im Sync sind.
Johns
Macht es einen Unterschied, wenn die Option zum Clearen des decoder buffers aktiviert ist, evtl. In Verbindung mit Schwarzbild beim Umschalten?
Das macht nur gefühlte Unterschiede. Wenn du mit der Stopuhr misst, sollte zum gleichen Zeitpunkt alles im Sync sein.
Zitat
Beim klassischen Umschaltverhalten, wo das alte Bild noch einen Moment nachläuft, ehe das neue Bild kommt, habe ich mich eigentlich immer schon gewundert, wieso das ohne Artefakte ging.
Früher hat ffmpeg diese kaputten Frames nicht zurückgeben. Ich habe versucht mit Fehlerflags usw. zuspielen, aber die machten keinen Unterschied. Ich habe schon immer was ich bekommen habe ausgeben.
Johns
[...] Mich würde aber immer noch intressieren ist Umschaltgeschwindigkeit gleich geblieben?
Johns
Hier mal ein paar Umschaltzeiten: (SD --> SD)
vdr01_64 ~ # log |egrep "synced after|switching"
Apr 23 21:56:50 [vdr] [24155] switching to channel 106 (MGM)
Apr 23 21:56:54 [vdr] video/vdpau: synced after 97 frames 3824ms_
Apr 23 21:57:04 [vdr] [24155] switching to channel 107 (Kinowelt TV)
Apr 23 21:57:05 [vdr] [24155] switching to channel 107 (Kinowelt TV)
Apr 23 21:57:11 [vdr] [24155] switching to channel 96 (Sky Cinema)
Apr 23 21:57:16 [vdr] video/vdpau: synced after 106 frames 4248ms_
Apr 23 21:57:19 [vdr] [24155] switching to channel 97 (Sky Cinema+1)
Apr 23 21:57:23 [vdr] video/vdpau: synced after 113 frames 3772ms_
Apr 23 21:57:29 [vdr] [24155] switching to channel 98 (Sky Cinema+24)
Apr 23 21:57:32 [vdr] video/vdpau: synced after 94 frames 3341ms_
Apr 23 21:57:36 [vdr] [24155] switching to channel 99 (Sky Action)
Apr 23 21:57:42 [vdr] video/vdpau: synced after 193 frames 6466ms_
Apr 23 21:57:48 [vdr] [24155] switching to channel 100 (Sky Thrones)
Apr 23 21:57:51 [vdr] video/vdpau: synced after 102 frames 3837ms_
Apr 23 21:57:56 [vdr] [24155] switching to channel 101 (Sky Nostalgie)
Apr 23 21:58:00 [vdr] video/vdpau: synced after 90 frames 3287ms_
Apr 23 21:58:04 [vdr] [24155] switching to channel 102 (Sky Emotion)
Apr 23 21:58:08 [vdr] video/vdpau: synced after 94 frames 4343ms_
Apr 23 21:58:10 [vdr] [24155] switching to channel 103 (13th Street)
Apr 23 21:58:14 [vdr] video/vdpau: synced after 95 frames 3908ms_
^C
vdr01_64 ~ #
Alles anzeigen
ffmpeg:
vdr01_64 ~ # eix -cI media-video/ffmpeg
[I] media-video/ffmpeg (2.6.2@18.04.2015): Complete solution to record, convert and stream audio and video. Includes libavcodec
vdr01_64 ~ #
Softhddevice:
Die sind aber extrem lang. Ich denke es liegt am CAM.
Ich habe hier 1/2 - 1s (30 bis 60).
Und wie war es mit ffmpeg 2.5.x ?
Johns
An das CAM habe ich jetzt garnicht gedacht...
Hier mal ein paar Beispiele mit SD FTA:
vdr01_64 ~ # log |egrep "synced after|switching"
Apr 23 22:12:36 [vdr] [24155] switching to channel 430 (Bayerisches FS Nord)
Apr 23 22:12:39 [vdr] video/vdpau: synced after 88 frames 2850ms_
Apr 23 22:12:44 [vdr] [24155] switching to channel 431 (Bayerisches FS Süd)
Apr 23 22:12:46 [vdr] video/vdpau: synced after 96 frames 2763ms_
Apr 23 22:12:51 [vdr] [24155] switching to channel 432 (Das Erste)
Apr 23 22:12:53 [vdr] video/vdpau: synced after 92 frames 2702ms_
Apr 23 22:12:58 [vdr] [24155] switching to channel 433 (EinsPlus)
Apr 23 22:13:01 [vdr] video/vdpau: synced after 99 frames 3003ms_
Apr 23 22:13:05 [vdr] [24155] switching to channel 434 (Einsfestival)
Apr 23 22:13:07 [vdr] video/vdpau: synced after 94 frames 2578ms_
Apr 23 22:13:14 [vdr] [24155] switching to channel 435 (MDR S-Anhalt)
Apr 23 22:13:17 [vdr] video/vdpau: synced after 90 frames 3001ms_
Apr 23 22:13:22 [vdr] [24155] switching to channel 436 (MDR Sachsen)
Apr 23 22:13:25 [vdr] video/vdpau: synced after 88 frames 2854ms_
Apr 23 22:13:26 [vdr] [24155] switching to channel 437 (MDR Thüringen)
Apr 23 22:13:29 [vdr] video/vdpau: synced after 93 frames 2854ms_
Apr 23 22:13:33 [vdr] [24155] switching to channel 438 (NDR FS HH)
Apr 23 22:13:36 [vdr] video/vdpau: synced after 81 frames 2851ms_
Apr 23 22:13:41 [vdr] [24155] switching to channel 439 (NDR FS MV)
Apr 23 22:13:43 [vdr] video/vdpau: synced after 75 frames 2410ms_
^C
vdr01_64 ~ #
Alles anzeigen
Wie es mit ffmpeg 2.5.x war, kann ich gar nicht mehr sagen, da ich extrem selten SD schaue und meistens auch kein FTA.
@ Johns,
könnte man denn nicht diese Ausgabe, "synced after 90 frames 3001ms_" standardmäsi8g so ausgeben, also auch ohne "-DDEBUG"?
Ich gebe ja die synced aus. Die Zeit des Umschaltens wird nur mit Debug erfasst und zieht sich über ein paar Stellen.
Im Prinzip ist mit "Clear on channel switch" der Wert gleichbedeutend.
Also soltte Frames * 20ms = Zeit sein.
Reicht das nicht?
Johns
Nun ja, es wird halt so oft nach den "Umschaltzeiten" gefragt und da wäre es halt schön, bzw. einfach, wenn es gleich im Klartext angezeigt würde.
Ich möchte mich jetzt nicht allzu weit aus dem Fenster lehnen, aber ich gehe mal davon aus, dass die Meisten hier mit Millisekunden eher etwas anfangen können, als mit Frames.
Ich wollte gerade einmal testen, ob ich das Gefühl empirisch bestätigen kann. Allerdings gibt es jetzt bei mir mit ffmpeg 2.6.3 keine Artifakte mehr - also sowohl mit, als auch ohne Workaround. In der Zwischenzeit wurde bei Arch aber auch an den config flags gedreht, wobei das laut commit message nur die Vorgabewerte betraf: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ffmpeg&id=09be7451cd235d0e7e8ef22f6d745eeeae4414cf.
Kann jemand das Verhalten mit ffmpeg>2.6.2 bestätigen?
Leider keine Zeit zum Testen. Aber man kann ja das schnelle Umschalten im Setup einschalten.
Johns
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!