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
[softhddevice] MPEG Artefakte nach Umschalten mit ffmpeg 2.6.x (Und täglich grüßt das Murmeltier)
-
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 -
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)
Code
Alles anzeigenvdr01_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 ~ #ffmpeg:
Codevdr01_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:
Codevdr01_64 softhddevice-git # git log |head -n6 commit f0d31ad33cf08d39186e08914bbcfa7853126c4c Author: Johns <johns98@gmx.net> Date: Wed Apr 22 12:35:42 2015 +0200 Fixed typing error. vdr01_64 softhddevice-git # -
An das CAM habe ich jetzt garnicht gedacht...
Hier mal ein paar Beispiele mit SD FTA:
Code
Alles anzeigenvdr01_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 ~ #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"?
-
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?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!