Ok, dann weiss ich wodran es liegt. Da ich aber auf dem System nicht wild eigene ffmpeg Versionen kompilieren mag, warte ich mal bis es eine funktionierende Version in die yavdr Repos oder zugehörige PPAs geschafft haben.
Danke für die Arbeit!
Ok, dann weiss ich wodran es liegt. Da ich aber auf dem System nicht wild eigene ffmpeg Versionen kompilieren mag, warte ich mal bis es eine funktionierende Version in die yavdr Repos oder zugehörige PPAs geschafft haben.
Danke für die Arbeit!
seahawk1986 so nochmal am OSD und DETA gebastelt und versucht die GLX Contexte besser zu verstehen. Bei mir klappt nun alles.
D.h. beim starten mit -D kommt das OSD sofort als overlay mit Bild und umschalten auf anderen Screen mit DETA und ATTA geht auch.
Habe es bestimmt 30mal zwischen 2 Monitoren hin und her geschaltet ohne crash
jojo61
ffmpeg 3.4.4 bringt keine Verbesserung
seahawk1986 so nochmal am OSD und DETA gebastelt und versucht die GLX Contexte besser zu verstehen. Bei mir klappt nun alles.
Es wird besser - nach dem erneuten Attachen habe ich jetzt Bild und OSD. Aber das Plugin hängt immer noch reproduzierbar beim detachen, falls da gerade das OSD offen ist.
Es wird besser - nach dem erneuten Attachen habe ich jetzt Bild und OSD. Aber das Plugin hängt immer noch reproduzierbar beim detachen, falls da gerade das OSD offen ist.
Upps mit offenem OSD hatte ich es noch gar nicht probiert. Kann es reproduzieren und schaue es mir an.
jsffm an den ffmpeg sachen habe ich nichts mehr gemacht, Insofern wundert es mich nicht das sich da nix bessert. Hast du immer noch einen crash beim detachen ?
jojo61
so gefixt
Hast du immer noch einen crash beim detachen ?
Nein, beim Attachen
so gefixt
Die Hänger sind weg, aber ich habe mit dem skindesigner noch sporadische Crashes wie crash_0.6.1rc1+git20180929-29-a998e6a-0yavdr0~bionic.txt beobachten können, wenn man das Plugin für den Bildschirmwechsel detached und wieder attached. Mit LCARS als Skin scheint das nicht zu passieren.
Die Menü-Darstellung mit dem skindesigner sieht jetzt sauberer aus (der Hintergrund wird korrekt gezeichnet) und das Scrollen funktioniert ohne Flackern.
Ich hab mich mal an nem Backtrace vom detach versucht:
#0 0x00007ffff61373c8 in raise () from /lib64/libc.so.6
#1 0x00007ffff613901c in abort () from /lib64/libc.so.6
#2 0x00007ffff617dd7e in ?? () from /lib64/libc.so.6
#3 0x00007ffff61859e8 in ?? () from /lib64/libc.so.6
#4 0x00007ffff6186d68 in ?? () from /lib64/libc.so.6
#5 0x00005555556b60aa in cListBase::Clear (
this=this@entry=0x55555592f660 <DvbDeviceProbes>) at tools.c:2233
#6 0x00005555556b6197 in cListBase::~cListBase (
this=0x55555592f660 <DvbDeviceProbes>, __in_chrg=<optimized out>)
at tools.c:2140
#7 0x00007ffff613a748 in ?? () from /lib64/libc.so.6
#8 0x00007ffff613a7ca in exit () from /lib64/libc.so.6
#9 0x00007ffff012a5d7 in _XDefaultError () from /usr/lib64/libX11.so.6
#10 0x00007ffff012a71d in _XError () from /usr/lib64/libX11.so.6
#11 0x00007ffff01274af in ?? () from /usr/lib64/libX11.so.6
#12 0x00007ffff0127565 in ?? () from /usr/lib64/libX11.so.6
#13 0x00007ffff01284f0 in _XReply () from /usr/lib64/libX11.so.6
#14 0x00007ffff0123d0d in XSync () from /usr/lib64/libX11.so.6
#15 0x00007fffbecc0178 in ?? () from /usr/lib64/libGLX_nvidia.so.0
#16 0x00007fffbecb2961 in glXCreateContext ()
from /usr/lib64/libGLX_nvidia.so.0
#17 0x00007fffefa88570 in glXCreateContext ()
from /usr/lib64/opengl/nvidia/lib/libGLX.so.0
#18 0x00007ffff3070000 in GlxInit () at video.c:1206
#19 CuvidGlxInit (display_name=<optimized out>) at video.c:2006
#20 0x00007ffff30748c6 in VideoInit (display_name=0x555555a82d18 ":0.0")
at video.c:5545
#21 0x00007ffff3069015 in StartVideo () at softhddev.c:2014
#22 0x00007ffff306cda5 in Resume () at softhddev.c:3379
#23 0x00007ffff30645e7 in cPluginSoftHdDevice::SVDRPCommand (
this=<optimized out>, command=<optimized out>, option=<optimized out>,
reply_code=<optimized out>) at softhdcuvid.cpp:3713
#24 0x00005555556a89f7 in cSVDRPServer::CmdPLUG (this=0x555555d738d0,
Option=<optimized out>) at svdrp.c:2339
#25 0x00005555556ab165 in cSVDRPServer::Process (this=0x555555d738d0)
at svdrp.c:2617
#26 0x00005555556ab38e in cSVDRPServerHandler::ProcessConnections (
this=this@entry=0x555566838750) at svdrp.c:2722
#27 0x00005555556ab585 in cSVDRPServerHandler::Action (this=0x555566838750)
at svdrp.c:2745
#28 0x00005555556ad9d9 in cThread::StartThread (Thread=0x555566838750)
at thread.c:293
#29 0x00007ffff7953afa in start_thread () from /lib64/libpthread.so.0
#30 0x00007ffff62042df in clone () from /lib64/libc.so.6
Da ich aber auf dem System nicht wild eigene ffmpeg Versionen kompilieren mag, warte ich mal bis es eine funktionierende Version in die yavdr Repos oder zugehörige PPAs geschafft haben.
Bei ffmpeg 3.4.4 gibt es zwei Stellen in der libavcodec/cuviddec.c, in denen die im README angesprochene Stelle vorkommt:
~/src/experimental/ffmpeg-3.4.4/libavcodec$ grep -n 'ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces' cuvid.c
844: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
1041: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
Bei der cuviddec.c aus ffmpeg 4.0.2 sind die Treffer in Zeile 856 und 1059, was ziemlich weit weg von den in der README angegebenen Zeile 360 ist:
Unfortunatly FFMEG has a bug with deinterlacing cuda frames. So you have to patch the file in libavcodec/cuviddec.c
Somewhere near line 360 depending on your release: old: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
new: ctx->frame_queue = av_fifo_alloc((ctx->nb_surfaces + 2 ) * sizeof(CuvidParsedFrame));
jojo61 hast du eventuell einen Patch für die von dir genutzte ffmpeg-Version, mit dem man den Zusammenhang besser sehen kann?
seahawk1986 Habe gerade gesehen das ich einen Tippfehler im Readme hatte. Die Zeile bei meiner FFMPEG 4.0 ist 863 und nicht 360.
Die zweite Stelle im Sourcefile wo das vorkommt ist nicht nötig zu patchen, aber es schadet auch nichts.
Hintergund ist folgender:
Beim deinterlacen erzeugt der decoder ein zweites Vollbild (frame) . Wenn nun die Framequeue schon voll ist dann ist kein Platz mehr für dieses weitere Frame und die Queue löuft über. Deswegen habe ich die Frameque einfach um ein weiteres (genauer 2 sicherheitshalber) beim alloc erweitert. Dann ist immer noch Platz weil der "voll" test nicht bis zum Ende der Queue auffüllt.
Im Prinzip sollte die Queue nie voll laufen weil die Frames ja abgeholt und angezeigt werden. Am Anfang habe ich die Frames erst abholt nachdem die Decoderqueue (av_codec_send_packet) voll war. So habe ich den Fehler entdeckt. Dann habe ich das abholen der Frames aber umgestellt und hole immer sofort alle fertigen Frames ab.Damit sollte es eigentlich auch ohne den FFMPEG patch gehen. Aber wie es aussieht tritt das Problem doch noch manchmal auf und dann wird der patch gebraucht. Ein Fehler ist es auf jeden Fall.
Ich weiss leider nicht wie ich das den Jungs von FFMPEG melden soll damit es dort eingepflegt wird.
mfg
jojo61
PS: das Detachen mit dem skindesigner schaue ich mir noch an
jsffm dein BT ist interessant. Ich schaue das noch genauer an.
PS: das Detachen mit dem skindesigner schaue ich mir noch an
Danke, er scheint sporadisch auch ohne skindesigner mit LCARS als Skin zu crashen das sieht dann z.B. so aus: crash_0.6.1rc1+git20180929-29-a998e6a-1yavdr0~bionic.txt
Ich weiss leider nicht wie ich das den Jungs von FFMPEG melden soll damit es dort eingepflegt wird.
Man könnte es über die ML (libav-user) oder den IRC probieren: https://ffmpeg.org/contact.html
Danke, er scheint sporadisch auch ohne skindesigner mit LCARS als Skin zu crashen das sieht dann z.B. so aus: crash_0.6.1rc1+git20180929-29-a998e6a-1yavdr0~bionic.txt
Der crash mit LCARS lag daran das er noch versucht hat ein Bild anzuzeigen als die Buffer schon gelöscht waren. Das habe ich nun hoffentlich verriegelt.
jsffm dein Fehler beim ATTA ist sonderbar. Er crasht beim versuch den GKXcontext zu löschen. Da ist die libX11 und die libGLX von nividia beteiligt. Welche libX11 hast du denn ? Bei mir ist es die 1.6.3
seahawk1986 beim DETA mit skindesigner scheint der skindesigner das detachen nicht mitzubekommen. Beim nächsten ATTA ist das OSD dann kaputt. Das scheint mir am skindesigner zu liegen. Oder jemand sagt mir wie ich dem skindesigner das DETA mitteilen kann
jojo61
x11-libs/libX11-1.6.6
es könnte sein, das beim BT noch ne ältere Version aktiv war, der BT hatte sich aber nicht verändert.
Beim nächsten ATTA ist das OSD dann kaputt. Das scheint mir am skindesigner zu liegen. Oder jemand sagt mir wie ich dem skindesigner das DETA mitteilen kann
Ich habe gerade noch mal in meine Notizen geschaut: Der skindesigner hätte gerne, dass man ihm ein svdrpsend plug skindesigner DLIC schickt, wenn man das Frontend detached (softhddevice mit High Level OSD) - an anderer Stelle hat louis geschrieben, dass man den Befehl vor dem Detachen bei geschlossenem OSD absetzen soll (Skindesigner 0.8.8).
Bei yaVDR 0.6 hatte ich das so gelöst, dass das Frontend-Skript mit aller Gewalt versucht das OSD zu schließen (also die Taste MENU gefolgt von BACK BACK BACK, kleine Pause und noch mal BACK BACK sendet), dann wird DLIC an den Skindesigner gesendet und zum Schluss geht das DETA an softhddevice(-openglosd). Bei yavdr-ansible hatte ich das vereinfacht (erst DETA an softhddevice/-cuvid, dann DLIC an den skindesigner) - das hat mit den älten softhddevice-Forks bei meinem Versuchen gut geklappt, aber falls nötig baue ich den Workaround wieder ein.
Mit dem Commit aus dem Git 3f15f79 sieht es schon mal besser aus, ich konnte mit dem Skindesigner gerade bei mehrfachem deta->atta mit einem Bildschirmwechsel oder Start von KODI dazwischen keinen Crash auslösen.
seahawk1986 na das sind doch mal gute Nachrichten. Ist denn nun noch etwas offen ?
jsffm ich habe noch eine Version eingecheckt die an der Stelle wo es bei dir crasht etwas mehr debuggt. Kannst du das mal mit debug compilieren und dann das log dazu einstellen. Danke
jojo61
grab grab grab ?
Aber schon mal vielen Dank bis hierher, werde nachher mal testen.
Christian
Ist denn nun noch etwas offen ?
Die Implementierung von GRAB fehlt noch.
Leider unterstützt der nvidia-396 die GT630 und GT730 Karten laut https://www.nvidia.com/Downloa…Results.aspx/137211/en-us nicht - ich werde noch ein PPA mit dem nvidia-Treiber und dem gepatchten ffmpeg anlegen, damit die yavdr-ansible Nutzer mit neueren NVIDIA-Karten den aktuellen Stand leichter ausprobieren können.
Don’t have an account yet? Register yourself now and be a part of our community!