Beiträge von Murry

jsffm schrieb:

Ja, ich, mit dem an 3.4.4 angepasstem patch von seahawk1986

siehe auch hier

Der Patch war für ffmpeg 4.0, deshalb wollte ich noch eine Bestätigung von jemanden der die aktuelle Version einsetzt.

Hallo!

Hat jemand mit FFmpeg 4.0 und dem patch von ffmpeg auch das Problem mit de SD-Sendern?

softhddevice with hevc and UHD

Gruß

Murry

Mit dem ffmpeg Paket von seahawk bekomme ich diese Fehlermeldungen beim Umschalten einen nicht HD Sender:

Die RTL HD Sender laufen einwandfrei.

Gruß

Murry

iNOB schrieb:

Wo ist das Problem? Die Änderungen sind in ffmpeg 3.4.4 in "libavcodec/cuvid.c" statt in "libavcodec/cuviddec.c" zu machen.

Bei mir wird 30min lang compiliert und dann, kurz vorm Paketbau, bei der Generierung der man pages mit fehlenden Schreibrechten abgebrochen.

jojo61 schrieb:

Das Problem ist das der ffmpeg cuda decoder bei deinterlacing und drop secondfield = false nicht mehr prüft ob das second field noch in den Buffer passt bevor er es dort hineinschreibt. Deswegen initialisiert der Patch den Buffer mit 2 Buffer mehr von denen der Treiber aber nix weiss. Deswegen ist dann immer noch ein Buffer vorhanden. Der Test auf Buffer voll ist falsch da müsste eigentlich auf Buffer max - 1 getestet werden.

Zitat

Das ist genau was der Patch behebt.

Ohne meinen Patch sehe ich das flackern auch. Original ist das einfach ein off-by-one Fehler. Der check in cuvid_is_buffer_full sollte >= sein, nicht >.

Mit meinem Patch ist er jetzt in jedem Fall korrekt, und zumindest in meinem Test mit der ffmpeg cli flackert nichts mehr (Ohne den Patch kann ich das Flackern nachstellen).

Sicher, dass korrekt getestet wurde?

Werde den Patch auf jeden Fall gleich pushen und soweit möglich backporten. Zu 3.4 wird er wahrscheinlich nicht mehr passen, aber 4.0 sollte ihn bekommen.

Alles anzeigen

Für mein Ubuntu habe ich nur 3.4.4 und schaffe es nicht mit FFmpeg 4.0 zu testen.

Hallo Jojo61,

der FFmpeg Programierer (Timo Rothenpieler) hat geantwortet:

Zitat

Das erscheint mir nicht richtig, der buffer wird beim flush auf genau die selbe Größe initialisiert wie vorher, da sollte also wenn vorher schon etwas nicht funktionieren.

nb_buffers ist außerdem ein Parameter, der frei konfiguriert werden kann. Und eigentlich ist der default von 25 Frames absolut ausreichend.

Was genau ist denn überhaupt das Problem? Ich kann die verlinkte Seite nicht aufrufen.

Try this:

https://github.com/BtbN/FFmpeg…26e5a761aa8e5eb37bc.patch

Alles anzeigen

Aufnahme RTL HD flackert nach spulen oder springen.

Mit dem neuen commit läuft UHD bei mir ruckelfrei

Vielen Dank

Es gibt anscheinend Karten die nur 4x verwenden:

https://de.msi.com/Graphics-ca…0-2GH-LP-OC/Specification

Meine GT1030 läuft nur mit 4x obwohl die Karte im x16 Slot sitzt (blau):

Ich habe gerade etwas mit nvidia-smi gespielt

Weiß jemand was sm ist? Das ist jedenfalls bei UHD bei 100%

jojo61 schrieb:

seahawk1986 Mich wundert das etwas mit dem deinterlacer weil ich das gar nicht auswerte. Es wird immer der adaptive Deinterlacer genutzt. Aber evtl. gibt es noch eine andere Stelle wo das ausgewertet wird, das schaue ich mir an.

Das gepatchte ffmpeg aus seahawks ppa hat bei mir geholfen. Die RTL HD-Gruppe ist nun ruckelfrei.

Nur die UHD-Kanäle wollen noch nicht so recht (downscale).

Vielen Dank,

Jojo61 und seahawk1986

seahawk1986 schrieb:

Das wird vermutlich von dpms ausgelöst werden. Versuch mal in der /var/lib/vdr/.config/openbox/autostart dpms abzuschalten, indem du diesen Befehl am Ende einträgst:

xset s off -dpms

sieht gut aus

seahawk1986 schrieb:

Klappt bei dir der wechsel zu KODI und zurück ohne Crashes des VDR?

Mit Kodi 18 beta geht es

jojo61 schrieb:

Murry Mit welchem NVIDIA Treiber hast du denn getestet. Mir scheint es das dir die Frames nicht schnell genug verarbeitet werden. hast du den Screen auf 50 Hz oder 60Hz ? Irgendwas ist da zu langsam ? Das würde auch das ruckelm bei RTL erklären (siehe meinen Post weiter oben weg deinterlacing).

Ist die Karte in eine PCIE16 Slot ?

nvidia 390

TV zeigt 50hz an

Ard HD, ZDF HD, ServusTV HD laufen einwandfrei.

PCIE16: ja

Ist deinterlace: Bob richtig?

Hallo jojo61,

bei mir funktionieren die öffentlichen in HD und die privaten in SD sehr gut (DVB-S2, seahawks ppa). Jedoch HD+ (1080i) und UHD1 (downscale) ruckeln sehr stark. Getestet habe ich ohne den ffmpeg patch. Bei UHD1 kommt die Prozessorlast nicht über 15%, daran kann es diesmal nicht liegen.

HD+

Sep 30 17:19:31 ubuntu18 vdr: video: normal aspect output 1919x1080+0+0 Video 1920x1080

Sep 30 17:19:31 ubuntu18 vdr: no CUVID Init ok 1920x1080

Sep 30 17:19:31 ubuntu18 vdr: video: normal aspect output 1919x1080+0+0 Video 1920x1080

Sep 30 17:19:33 ubuntu18 vdr: video/cuvid: synced after 57 frames

Sep 30 17:19:34 ubuntu18 vdr: [7844] animator thread thread ended (pid=6347, tid=7844)

UHD1

Sep 30 17:22:39 ubuntu18 vdr: video: normal aspect output 1919x1080+0+0 Video 1920x1080

Sep 30 17:22:39 ubuntu18 vdr: no CUVID Init ok 3840x2160

Sep 30 17:22:39 ubuntu18 vdr: video: normal aspect output 1919x1080+0+0 Video 1920x1080

Sep 30 17:22:42 ubuntu18 vdr: [1925] animator thread thread ended (pid=1192, tid=1925)

Sep 30 17:22:44 ubuntu18 vdr: video/cuvid: synced after 210 frames

Des weiteren bekomme ich bei HD+ sehr schnell einen schwarzen Bildschirm.

Soll ich mal mit debug testen oder ist erstmal der ffmpeg patch notwendig?

Vielen Dank für die mühen.

Gruß

Murry

Hallo Christian,

ich habe ein ähnliches Problem:

Boot mit eingeschalteten Fernseher: output.hdmi-stereo

Boot mit ausgeschalteten Fernseher:output.hdmi-stereo-extra1

Das Problem scheint bei pulseaudio zu liegen, hast du es schon mal mit alsa versucht? --> Sorry ich hatte nur den zweiten Beitrag gesehen.

Gruß

Murry

jojo61 schrieb:

Leider muss man mal wieder FFMPEG patchen da dort noch ein Fehler beim deinterlacen von cuda frames verborgen ist.

Der Patch ist nur für AMD, oder?

Gruß

Murry

Aber wie komme ich an die gewünschte Zeile der Timer Tabelle?

Einen hätte ich noch:

ls -l /etc/udev/rules.d/