I just downloaded osdtest and will have a look.
But i may take some time as I'm on vacation
jojo61
I just downloaded osdtest and will have a look.
But i may take some time as I'm on vacation
jojo61
It seems that osdtest does not call VideoOSDInit bevor changing the size of the Images. . But it changes the Area above the currend OSD Size.
set osd 1920 x 1080... debug in VideoOSDInit
==> Construct OsdImage...
start readOsdUpdate
Image size 100x100
OsdImage readOsdUpdate, get scale context
OsdImage readOsdUpdate, scale image
==> OsdImage Show()
==> Display
Area size set to 0:0 - 3839:2159 <------------- Area ist set above osd size. That will crash of course.
Hi,
it did not solve the issue but changing the initialization order may make sense in softhdcuvid
https://github.com/pesintta/vd…231787538e98635403c891059
with the patch I get
==> Construct OsdImage...
start readOsdUpdate
hbbtv: Got illegal OSD size 0x0==> OsdImage Show()
==> Display
Area size set to 0:0 - 4095:2159
OsdImage SetOsdSize()
OsdImage SetOsdSize, Get new OSD size
OsdImage SetOsdSize, Create pixmap 1920x1080
OsdImage SetOsdSize, Clear Pixmap
start readOsdUpdate
Image size 1920x1080
OsdImage readOsdUpdate, get scale context
OsdImage readOsdUpdate, scale image
OsdImage readOsdUpdate, draw image lock
OsdImage readOsdUpdate, draw image unlock
OsdImage readOsdUpdate, flush osd
Old Size: 0x0, New Size. 1920x1080
MainThreadHook => Display()==> Display
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...
Aborted (core dumped)
CU
9000h
//posd = (unsigned char *)calloc((OsdWidth + 1) * (OsdHeight + 1) * 4, 1);
posd = (unsigned char *)calloc((4096 + 1) * (2160 + 1) * 4, 1);
If you change the calloc to the maximum size then osdtest runs ok. But the Images are wrongly scaled because the Images are in the wrong size.
So the Images need to be within the OSD size,
Hi,
hmm strange, with the change from jojo61 it did not crash and displayed correct.
==> Construct OsdImage...
start readOsdUpdate
hbbtv: Got illegal OSD size 0x0==> OsdImage Show()
==> Display
Area size set to 0:0 - 4095:2159
OsdImage SetOsdSize()
OsdImage SetOsdSize, Get new OSD size
OsdImage SetOsdSize, Create pixmap 1920x1080
OsdImage SetOsdSize, Clear Pixmap
start readOsdUpdate
Image size 1920x1080
OsdImage readOsdUpdate, get scale context
OsdImage readOsdUpdate, scale image
OsdImage readOsdUpdate, draw image lock
OsdImage readOsdUpdate, draw image unlock
OsdImage readOsdUpdate, flush osd
Old Size: 0x0, New Size. 1920x1080
MainThreadHook => Display()==> Display
Area size set to 0:0 - 4095:2159
OsdImage SetOsdSize()
OsdImage SetOsdSize, Get new OSD size
OsdImage SetOsdSize, Create pixmap 1920x1080
OsdImage SetOsdSize, Clear Pixmap
start readOsdUpdate
Image size 1920x1080
OsdImage readOsdUpdate, get scale context
OsdImage readOsdUpdate, scale image
OsdImage readOsdUpdate, draw image lock
OsdImage readOsdUpdate, draw image unlock
OsdImage readOsdUpdate, flush osd
Destroy OsdImage...
CU
9000h
I have changed both osdtest and main plugin and introduced the define SET_AREA_VERY_EARLY in osdimage.c and cefhbbtvpage.c.
If it is defined, the area will be set to the (hopefully) maximum value, but if undefined, the call of SetArea happens after determination of the OSD size and SetArea uses the real OSD size.
Softhdcuvid crashes directly after a window resize - if SET_AREA_VERY_EARLY is not defined. With the already mentioned segfault while doing cOglFont::Cleanup.
Softhddevice (with my patches and known flaws) works nearly as desired without any crash.
I now remember why i set the area size very early. But because at least one plugin works i think i will changed it again to set the area after knowing the real OSD size.
Zabrimus
Try my patch and it should work also with softhdcuvid.
Hi,
i have tested both changing the posd calloc
> grep "posd = " video.c
// posd = (unsigned char *)calloc((OsdWidth + 1) * (OsdHeight + 1) * 4, 1);
posd = (unsigned char *)calloc((4096 + 1) * (2160 + 1) * 4, 1);
and moving VideoOsdInit(); as mentioned by 9000h (#23).
And the result is the same. Directly resizing the VDR window (while channel information or main menu is visible) leads to a stopped VDR.
The exactly same result i got with softhddevice.
The only plugins started are softhdcuvid and satip. No other skin or other plugins.
Because i'm probably the only one with this problem, it can be either, i'm the only one who resizes the window very early or my installation is somehow different to all other ones.
I started the debugger in Clion and try to show the details:
Stacktrace is:
FT_Done_Library 0x00007fe78ff32be4
FT_Done_FreeType 0x00007fe78ff26fce
cOglFont::Cleanup openglosd.cpp:400
cOglThread::Cleanup openglosd.cpp:1879
cOglThread::Action openglosd.cpp:1763
cThread::StartThread thread.c:293
start_thread 0x00007fe79003bfa3
clone 0x00007fe78fb304cf
Let's go through the stacktrace:
1. cThread::StartThread thread.c:293
2. cOglThread::Action openglosd.cpp:1763
void cOglThread::Action(void)
{
...
while (Running()) {
...
}
dsyslog("[softhddev]Cleaning up OpenGL stuff");
Cleanup(); // Line 1763
dsyslog("[softhddev]OpenGL Worker Thread Ended");
}
Alles anzeigen
3. cOglThread::Cleanup openglosd.cpp:1879
4. cOglFont::Cleanup openglosd.cpp:400
void cOglFont::Cleanup(void)
{
...
if (FT_Done_FreeType(ftLib)) // Line 400
esyslog("failed to deinitialize FreeType library!");
...
}
I assume that Running() in 2. return false and then the thread starts and immediately tries to cleanup itself. I've added an additional output statement to verify my assumption. And yes, Running() returns false.
May 15 14:08:06 xxx vdr: video: crop to +0+0 1280x720
May 15 14:08:06 xxx vdr: video: normal aspect output 1331x749+109+0
May 15 14:08:07 xxx vdr: [17383] OSD size changed to 1550x749 @ 0,859068
May 15 14:08:07 xxx vdr: [17383] [softhddev]CreateOsd: left 124, top 60, level 0, using OpenGL OSD support
May 15 14:08:07 xxx vdr: [17383] [softhddev]Trying to start OpenGL Worker Thread
May 15 14:08:07 xxx vdr: [17451] oglThread thread started (pid=17383, tid=17451, prio=high)
May 15 14:08:07 xxx vdr: [17451] [softhddev]OpenGL using display :0
May 15 14:08:07 xxx vdr: [17429] [softhddev]stopping OpenGL Worker Thread
May 15 14:08:07 xxx vdr: [17451] [softhddev]OpenGL Context initialized
May 15 14:08:07 xxx vdr: [17451] [softhddev]Shaders initialized
May 15 14:08:07 xxx vdr: [17451] [softhddev]vdpau interop initialized
May 15 14:08:07 xxx vdr: [17451] [softhddev]Vertex buffers initialized
May 15 14:08:07 xxx vdr: [17451] [softhddev]Maximum Pixmap size: 32768x32768px
May 15 14:08:07 xxx vdr: [17451] [softhddev]Running returns false
May 15 14:08:07 xxx vdr: [17451] [softhddev]Cleaning up OpenGL stuff
May 15 14:08:07 xxx vdr: [17451] [softhddev]OglThread cleanup
May 15 14:08:07 xxx kernel: [3198001.469796] traps: oglThread[17451] general protection ip:7fbe89e54be4 sp:7fbdffffeda0 error:0 in libfreetype.so.6.16.1[7fbe89e48000+7d000]
And one additional observation from the above syslog:
May 15 14:08:07 xxx vdr: [17451] oglThread thread started (pid=17383, tid=17451, prio=high)
May 15 14:08:07 xxx vdr: [17429] [softhddev]stopping OpenGL Worker Thread
May 15 14:08:07 xxx vdr: [17451] [softhddev]OpenGL Context initialized
The thread 17429 is beginning to stop itself after the other thread 17451 has been started. And i assume some global or static variables will be overwritten.
Zabrimus
ps: Sorry for the long post. I will try to stop myself writing too much nonsense.
I wonder why it is crashing in FT_Done_Freetype. HOw did you test this ? Can I test this with osdtest or do I need to install your hbbtv plugin ?
And why do you need to resize the OSD after all ? To my understanding, the OSD needs only be resized when I change the windows size.
So in fullscreenmode (as it usually is) there is no need to resize the OSD at all.
This is a special use case and happens often while developing. There I often change the VDR window either to fullscreen or i resize the window to see other more important windows. If i don't change the window size at all, then everything works as desired. Especially the switching to fullscreen happens so often unintentionally because it is only a click into the VDR window. If then VDR crash, although i wanted to do something else, it's a little bit annoying.
It can easily reproduced by opening any VDR menu (e.g. main menu, channel list, program, ... it doesn't matter) and then while resizing the VDR window, the error occurs. The problem does not depends on any plugin at all. The plugin osdtest is more useful to test if resizing the OSD to the same size as the VDR window, works.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!