On Sun, Nov 03, 2013 at 10:01:54PM +0200, Marko Mäkelä wrote:

On Fri, Nov 01, 2013 at 11:19:48PM +0200, Marko Mäkelä wrote:

...

If I change the assignment to isTrueColor=false, the square goes away and I will get the familiar gray rectangles on the screen (from the "else" block that I omitted above).

I did some further studying. The truecolor OSD was implemented early 2011. As far as I understand, the softdevice plugin is converting palette-based bitmaps into an ARGB layer. There is a comment at the end of the definition of class cOsd in osd.h that shows how the conversion should be done.

It looks like I should simply follow this example, possibly implementing some kind of threshold mapping on the Alpha channel in case the Matrox does not implement 8-bit translucency but just a 1-bit transparency flag. So, I will try to remove the palette mapping from SoftOsd.c and replace the GetBitmap() call with the RenderPixmaps() loop.

I figured this out for the most part. The pixmap gets first converted to an ARGB buffer cSoftOsd::OSD_Bitmap in FlushPixmaps() and DrawConvertPixmap(). From OSD_Bitmap it gets converted to the screen memory. I did not change the latter conversion.

Maybe I did something wrong regarding DirtyDrawPort and DirtyViewport, because I got occasional crashes when activating the OSD. When using a full-screen OSD (filling the entire 1280×1024 panel) the bottom 4 or so lines were never erased.

I did not get to see DVB subtitles yet, either due to them not being present in the live sendings at the moment I tested, or due to misconfiguration. I guess that VDR 2.0 would allow the subtitles to be alpha-blended with the OSD layer.

My patch against softdevice-cvs is attached. I compiled it with the following:

vdr 2.0.4 ffmpeg 0.5.13 DirectFB 1.0.1 DFB++ 1.0.0

Best regards,

Marko

On Sun, Nov 03, 2013 at 05:25:36PM -0800, VDR User wrote:

Have you tried softhddevice for output? http://projects.vdr-developer.org/git/vdr-plugin-softhddevice.git/

It looks like this is based on the X server. I see no reference to DirectFB in the README.txt or the Makefile.

The Matrox MGA450 is a very old graphics card. Also the computer is 11 or 12 years old, featuring a 900 MHz Celeron and 256 MB RAM. DirectFB meets these requirements. I do not have plans to replace my Hauppauge Nova-T PCI 90002 tuner(s) with DVB-T2 either, so I do not even care about HDTV for now.

Thanks for the hint anyway! I could at least compare how the OSD is implemented there.

Best regards,

Marko

On Mon, Nov 04, 2013 at 10:30:14PM +1000, Torgeir Veimo wrote:

Softdevice had transparency 'dithering' for when there's only 1-bit transparency, did you look at that option?

Thanks, but I guess I will be fine with the transparency key. The screen output would not be so much for watching videos, but mainly for setting up timers and cutting recordings. For watching, the plan is to stream the videos to the Samsung SmartTV in the living room.

I will try to put back the dirty_lines[] optimization that I removed in my initial attempt (trying to make it as simple as possible). The system felt slow without that.

You are one of the Softdevice authors, right? Is the CVS tree at berlios.de still open for patches? AFAICT, recent years the mailing list archive are corrupted, and the latest commit was a couple of years ago.

Best regards,

Marko

I did some more hacking and got softdevice to a useable state on VDR 2.0.4. My patch against softdevice cvs is attached.

The TL;DR version is that I suspect 2 bugs in VDR 2.0.4:

(1) The bottom 1% lines of the OSD are not being cleared when the OSD extends that low. (I can choose up to 99% height and 0% vertical offset.)

(2) Changes in DVB subtitles will flash the OSD layer (make it empty for a very short time) if an OSD is active. I suppose that DVB subtitles should not be displayed at all when OSD layer is active.

On Mon, Nov 04, 2013 at 10:30:14PM +1000, Torgeir Veimo wrote:

Softdevice had transparency 'dithering' for when there's only 1-bit transparency, did you look at that option?

I am a bit unsure if it really is using 1-bit transparency. The background inside the LCARS main menu is darker (but still translucent) than the area outside the menu borders. Everything else in the OSD layer is opaque.

With "perf top" I noticed that Softdevice was spending a lot of time, scaling the OSD layer down from 1920×1080 to 720×576 that is my video output resolution. So, I hardcoded the OSD size back to 720×576. OSD updates became snappy (fewer pixels to copy to the cSoftOsd::OSD_Bitmap[], and from there it would be a straight memcpy to the video memory). The following problem was unaffected by this fix.

If I set the OSD size to 100% height, then VDR will never clear the very bottom lines at the screen. If I set it to 99% height, everything will be erased properly when I leave the main menu, or the program info at the bottom of the screen is cleared. If I set it to 99% height and 1% vertical offset, the garbage will appear again. My current understanding is that it is VDR 2.0.4 that fails to post a proper draw request to clear the bottom of the screen.

The next problem was related to my patch. It turned out that cSoftOsd::Flush() has to check cOsd::IsTrueColor() and render pixmaps or bitmaps accordingly. This would also explain why I previously never saw any output from the Classic VDR OSD (it is the only non-TrueColor built-in theme).

The garbage-at-bottom problem also affects DVB subtitles. If I move the "Setup.DVB$Subtitle offset" too low, the pixels from the last 4 or so of the 576 lines will never be cleared (only drawn when there is some "y" or "p" or "q" character that extends to to the "garbage area").

A small (old) problem with the Softdevice OSD/subtitles remains. When the OSD is active while the current stream is showing DVB subtitles, the OSD layer will be cleared, but no subtitles will be displayed. Eventually, parts of the OSD will be repainted. It turns out that this problem was emphasized by the cSoftOsd::dirty_lines[] array. If I commit out the dirty_lines[] checks, the OSD will be properly repainted, but the entire OSD layer will be cleared for a few frames whenever the subtitles are about to display. (No subtitles will be actually displayed, because the OSD layer is active.) How to avoid this short OSD flash? I tried commenting out all cSoftOsd::Clear() calls, but that did not help (other than leaving DVB subtitles garbage on the screen when the OSD layer was not active).

Note: I understand that the non-truecolor DVB subtitles are not being alpha-blended to the truecolor OSD layer. It is OK for me not to see subtitles when the OSD is active. But it is not OK that the active OSD layer gets cleared whenever subtitles are attempting to display or clear themselves.

Best regards,

Marko

On Sat, Nov 09, 2013 at 11:36:55AM +0100, Klaus Schmidinger wrote:

I just tried this on my VDR with a TT S2-6400 and there was no such problem. I assume that this is related to the softdevice OSD implementation and not the core VDR.

Thank you for testing, Klaus!

Were you able to test the other problem (the OSD menu becomes fully transparent and then normal again when subtitles would want to update the OSD)? I can provide a short recording if needed. I guess that these bitmap-based subtitles are not too widespread functionality. Even here in Finland, only the state-owned YLE is using them; the commercial broadcasters are burning the subtitles into the video layer.

In any case, these are very minor problems now; I have an acceptable workaround for both. I just thought that I would go the last mile and polish a bit more, to prepare for a proper release of softdevice.

While I now understand the VDR and softdevice OSD implementation a little better, I still do not fully understand it. Currently, it is a bit of a mystery for me what happens when the OSD is closed and the screen is cleared. In osd.c I understood that there could be a transparent "background pixmap" whose relevant part would be invalidated when upper-layer pixmaps or bitmaps get removed. But, will this also happen when the whole OSD is closed, or only for closing individual "windows"?

Based on the SoftOsd.c debug output and some gdb sessions, it seems to me that the cSoftOsd object gets created and destroyed repeatedly, maybe every time something is displayed and then hidden again. Is this the correct object life cycle? Is there some wiki page or other documentation than the source code?

Best regards and thank you for the great work,

Marko

Hi Klaus,

I have no such problem here. If I open the menu of the channel/progress display while subtitles are active, no subtitles are displayed while the menu is open and they continue to be displayed once the menu has been closed again.

OK. The only difference that I am seeing (after disabling the dirty_lines[] optimization) that the OSD menu will disappear for less than half a second when the subtitles would want to do something. The menu would reappear again, and no subtitles are displayed until I close the OSD menu. As soon as I close the OSD menu, the subtitles (if any are active at that time) would be displayed immediately.

"burning the subtitles into the video layer" is probably the worst idea ever.

I fully agree. I guess that the commercial broadcasters try to avoid "leaking" too much metadata. Or they are just lazy, such as never showing the episode number of name of a series in the EPG data. If they sent proper subtitles and VPS signals and what not, then commercial breaks could be detected easier, without having to decompress and interpret the video stream. (Well, I guess there are VDR plugins for this; another reason to use VDR instead of some proprietary product.)

Also the state-owned broadcaster YLE is bending the rules a little. There usually is a "Dutch" language audio track that contains the original audio mixed with a speech synthesizer that is reading the Finnish subtitles. More recently, they have started to introduce "Dutch" language subtitles that actually are Finnish transcript of the Finnish audio track for the hearing impaired.

In any case, this is good service: The same video broadcast can serve all audiences. For example, a program that has original audio in N languages can be sent with N+M audio tracks and N+M sets of subtitles. In the times of the analog TV, the program could be sent in 2 channels, once in Swedish and once in Finnish, and that is it.

When the whole OSD is closed, ther is nothing that gets displayed.

OK, I think I will have to check what is happening around cOsd::~cOsd(). It could be that Softdevice is simply clearing the OSD layer at wrong points of the object lifecycle, in a way that happens to work for everything else than subtitles.

Best regards,

Marko

On Sun, Nov 10, 2013 at 04:44:44PM +0200, Sami Ketola wrote:

This is not entirely true. All broadcasters in Finland are using DVB subtitles except "Nelonen Media" on all their channels and MTV Media on "Sub" channel. Yes even MTV3 seems to be DVB subtitled now.

I must admit that I do not watch TV that much, except now when debugging softdevice. :) I was not aware of these very welcome news.

However, I am still seeing "burned" subtitles on the commercial DVB-T channels, for example in the currently active MTV3 program "Selviytyjät".

Marko

On Sat, Nov 09, 2013 at 01:57:37AM +0200, Marko Mäkelä wrote:

(1) The bottom 1% lines of the OSD are not being cleared when the OSD extends that low. (I can choose up to 99% height and 0% vertical offset.)

This looks like a bug in DirectFB or the way how softdevice is using it. There is a comment related to Matrox in video-dfb.c, AFAIU related to the video layer, not the OSD layer.

I did a short test recording of a 4:3 program. Depending on the softdevice crop mode, the garbage area at the bottom shrinks (from about 3 lines to 1 or even 0).

(2) Changes in DVB subtitles will flash the OSD layer (make it empty for a very short time) if an OSD is active. I suppose that DVB subtitles should not be displayed at all when OSD layer is active.

This is a bug in SoftOsd.c or in video-dfb.c. The OpenOSD call in the cSoftOsd constructor was clearing the OSD layer on the physical screen, even when !cOsd::Active(). To fix this, I made cDFBVideoOut::OpenOSD() a no-op, or renamed it to cDFBVideoOut::ClearOSD(), which is where this clearing should have been done.

I also moved some of the initialization to cSoftOsd::Action(), which seems to be a more appropriate place. cSoftOsd derives from both cOsd and cThread, to do the intensive work in a background thread.

Now I have some trouble with VDR crashing every now and then when I press Recordings or Menu. I fixed most Valgrind warnings in Softdevice, so that it is silent when I press buttons to hide or show the OSD. There are some warnings left in cRect::Intersects() or similar, seemingly not related to softdevice code. I will investigate further.

Also, on VDR 2.0.4 startup, cRecordings::ScanVideoDir() is calling cRecording::cRecording(), which according to Valgrind is reading past some strdup() buffer. I do have libc6-dbg installed, so I hope it is not a false alarm. I only had 2 short test recordings in my video directory, so this should be easy to debug, once I rebuild vdr in debug mode. I only had debug symbols for softdevice in my session, and I did not yet try vgdb-server, which is better for multi-threaded programs.

Best regards,

Marko