Postby eli13 » 28 Aug 2013 17:27
@RSATom: Well, what is well-known? I think there is no bug-report about it, but it is very well known to me:
I started working with VLC around version 2.0.1 - not the plugin, the lib, using it in a C++ application. I've always experienced crashes that come definitely from inside libfreetype.dll with VLC 2.0.1 up to 2.0.6. So no, its not a problem specific to FbVlc.
I did not test VLC > 2.0.6 (but there's nothing about freetype in NEWS).
Sometimes everything is fine and streams run for several days, sometimes it crashes within a few minutes. I think the last call I saw on the stack was a call to 'free' (from libfreetype.dll) but I might be totally wrong (out of my head).
We are simply not using the marquee options: In the standalone app we place a simple label below the video, in the web-plugin we use the fancy windowless mode and place a transparent div on top of it to display the text. Thats nicer anyway, so we can use all the css-things to style the text.
There was always some other confusion about marquee: If you set the text while libVlc is still buffering (but the video is already being displayed) libVlc "forgets" about the marquee that has just been set and you have to set it again.
When 2.0.5 was released there was a note that some crash in freetype has been resolved, but not the one I experience ( * Fix crash in Freetype with embedded fonts ).
Well, maybe I'm just using it the wrong way - but you cannot do much more then call the marquee api things. Sometimes I'm calling them quite often as sometimes I need to update the text often, maybe that is not common? Maybe its also related to the video-format used, the transport-protocol, etc., (here: always rtsp with --rtsp-tcp and h.264) so that it occurs only in a very special environment (?)
Unfortunately I cannot help much to debug things - I'm on Windows with Visual Studio and I would somehow need to get symbols that can be loaded by VS so that I could look at a stacktrace from within libfreetype.dll.