softhddevice mit OSD (va-api-glx) und 720p - kein Bild

wtor · Nov 1st 2022

Quote from lnj

I tested a software decoder very little, there was no such error, I will test more.

Cause i'm blocked here Is there anything i can do like debug outputs or other to support you to find the reason for these 'TS packet(s) not accepted in Transfer Mode' errors? Or there any alternatives with OSD in the meantime? xinelibout seems to work but with high cpu load...

Thanks

Torsten

lnj · Nov 2nd 2022

In Makefile uncomment

#CONFIG += -DDEBUG

#CONFIG += -DOSD_DEBUG

recompile and post log

Also you tried softhdvaapi or softhddrm?

wtor · Nov 2nd 2022

i've recompiled with debug. Attached the log of the transfer error.

softhdvaapi doesn't work at all, log is full of these messages:

Code

VAAPI-ERROR: video/vaapi: vaSyncSurface failed: operation failed

For softhddrm it's not clear for me how to use, with or without X11?

cinfo · Nov 2nd 2022

Quote

For softhddrm it's not clear for me how to use, with or without X11?

ja wird ohne X11 genutzt.

lnj · Nov 2nd 2022

softhddrm works without X11.

Make a log from normal softhddevice work to first buffer overflow please.

wtor · Nov 2nd 2022

Quote from lnj

Make a log from normal softhddevice work to first buffer overflow please.

But va-api-glx is not working there. I can only try without OSD (-v va-api -f -D -w no-hw-decoder).

For softhddrm i have no clue. I startet vdr (without X11) with "softhddrm -f -D -w no-hw-decoder -a hw:0,7 -p hw:0,7" but i get no picture at all. Are there any additional configuration required for drm? i attached the start log for drm.

lnj · Nov 2nd 2022

No, you did not understand.

Make log -v cpu-egl, from normal works to buffer overflow. You posted the log when the buffer overflow had already started, but I need the log before that.

wtor · Nov 2nd 2022

Ye, missunderstanding... here the full log.

But maybe its the log of "-v va-api-egl -w no-hw-decoder" instead of "-v cpu-egl". Is this a problem? But options are behave identically.

kamel5 · Nov 3rd 2022

Quote from wtor

xinelibout is also possible without vaapi but only without the skindesigner plugin as vdr crashes with them.

I've reproduced the problem now.

skindesigner and other skins use "True Color OSD". For this reason, TrueColor must first be set in xineliboutput "Setup->OSD->Color depth".

Other entries do not work in this case.

The log then shows the following:

Code

Nov 03 11:32:31 vdr[98852]: [98852] info: Primäres Interface wird umgeschaltet...
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: osd size changed
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: old osd size: top 38 left 22 size 1840 * 1037
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: new osd size: top 14 left 12 size 688 * 553
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: initializing skin estuary4vdr
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: using decimal point ,
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: using channel logo path /etc/vdr/plugins/skindesigner/logos/
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: using icon path /etc/vdr/plugins/skindesigner/skins/estuary4vdr/themes/applegreen/
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: using skinparts path /etc/vdr/plugins/skindesigner/skins/estuary4vdr/themes/applegreen/skinparts/
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: using svgtemplate path /etc/vdr/plugins/skindesigner/skins/estuary4vdr/svgtemplates/
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: using language de_DE
Nov 03 11:32:31 vdr[98852]: [98852] skindesigner: templates successfully validated and parsed
Nov 03 11:32:33 vdr[98852]: [98852] skindesigner: templates and images cached
Nov 03 11:32:33 vdr[98852]: [98852] skindesigner: cached 75 icons - size internal mem 0,21MB, high level mem 0,24MB
Nov 03 11:32:33 vdr[98852]: [98852] skindesigner: cached 200 logos - size 1841,25MB internal mem
Nov 03 11:32:33 vdr[98852]: [98852] skindesigner: cached 8 skinparts - size internal mem 0,00MB, high level mem 3,50MB
Nov 03 11:32:33 vdr[98852]: [98852] skindesigner: templates loaded and caches created - needed 1599 ms
Nov 03 11:32:33 vdr[98852]: [99992] animator thread thread started (pid=98852, tid=99992, prio=high)
Nov 03 11:32:33 vdr[98852]: [98852] [input_osd] ARGB overlay not supported by video driver
Nov 03 11:32:36 vdr[98852]: [99992] animator thread thread ended (pid=98852, tid=99992)
Nov 03 11:32:36 vdr[98852]: [98852] [input_osd] OSD_Close(0): non-existing OSD !
Nov 03 11:32:37 vdr[98852]: [98852] max. latency time 6 seconds
Nov 03 11:32:37 vdr[98852]: [98964] [demux_vdr] PMT changed, resetting demuxer
Nov 03 11:32:37 vdr[98852]: [98964] [demux_vdr] ts2es: reset, dropping buffer
Nov 03 11:32:37 vdr[98852]: [98964] [demux_vdr] ts2es: reset, dropping buffer
Nov 03 11:32:37 vdr[98852]: [98964] [demux_vdr] ts2es: reset, dropping buffer
Nov 03 11:32:37 vdr[98852]: [98964] [demux_vdr] ts2es: reset, dropping buffer
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264: Found NAL SPS at offset 6/524
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: profile_idc 100
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: pic_width:  80 mbs
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: pic_height: 45 mbs
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: frame only flag: 1
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: aspect_ratio_idc 1
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: -> aspect ratio 1 / 1
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] H.264 SPS: -> video size 1280x720, aspect 1:1
Nov 03 11:32:37 vdr[98852]: [99921] [xine..put] Detected video size 1280x720
Nov 03 11:32:37 vdr[98852]: [99921] [input_vdr] WARNING: xine-engine setting "engine.buffers.video_num_frames":15 is too small for some HD channels

Display More

No Segfault at all, but no OSD either. Everything else is functional.

I think this is the real problem in this case: "[input_osd] ARGB overlay not supported by video driver".

I don't know if there is a configuration parameter to enable ARGB.

So, that problem cant be fixed in the skins.

PS: for skin lcars you have to use "Automatic" in "Setup->OSD->Color depth"

Grüße

kamel5

lnj · Nov 20th 2022

You can try test branch of softhddevice, 720p must works now. With va-api-egl.

wtor · Nov 20th 2022

I have done some short tests and it's also working here. I will have a look next days, to see if there are any problems left.

Thanks for your work!

Torsten

wtor · Nov 20th 2022

Very short Test i got the same problem like said some posts before with -w no-hw-decoder, but here i tested with HW decoder (va-api-egl). Means randomly the picture hangs about a minute with these log entries:

Code

Nov 20 17:40:12 vdr vdr: [7115] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Nov 20 17:40:17 vdr vdr: [7118] i/o throttle activated, count = 1 (tid=7118)
Nov 20 17:40:23 vdr vdr: [7118] buffer usage: 100% (tid=7115)
Nov 20 17:40:24 vdr vdr: [7118] ERROR: driver buffer overflow on device 1

I will recompile with debug enabled. Any ideas about that problem?

wtor · Nov 20th 2022

I retested with debug enabled. VDR was started at Nov 20 17:48, and it hangs at 21:36 for about a minute. Here the start and the end of the problem in short:

Code

Nov 20 21:36:03 vdr vdr: [22173] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Nov 20 21:36:09 vdr vdr: [22175] i/o throttle activated, count = 1 (tid=22175)
Nov 20 21:36:17 vdr vdr: [22175] ERROR: driver buffer overflow on device 1
Nov 20 21:36:54 vdr vdr: [22175] i/o throttle released, count = 0 (tid=22175)

So, the vdr runs fine without problems for about 4 hours, then the problem occured. This happens in different time ranges (today afternoon it happend about 20 minutes after vdr start). I attached the full log for further analyzing.

softhddevice mit OSD (va-api-glx) und 720p - kein Bild

Participate now!

Share

Users Viewing This Thread