Messages

You are probably correct about page_time_out. I didn't implement this, because when I was testing with UK subtitles, they were always cleared explicitly with an empty page composition. I believe this is the way subtitles are supposed to be transmitted, and that page_time_out is only there in case the decoder misses some of the subtitle data.

I've been lucky to have got away with this for so long! I'll make a mental note that this needs to be looked at, but I can't promise anything soon!

UTF-8 and extended font support is in progress (see thread below from General forum). Getting close now, just trying to tidy up the code because the text drawing functions are a bit disorganised.

http://forum.loggytronic.com/index.php?topic=428.0

Is a memcpy really necessary, can you try:

*((ULONG*)(buffer+bufUsed))=htonl(ul);
instead.

Marten

I think this code is identical to the original by definition.

p[x] is defined as *(p+x), and I'm pretty sure &*p == p, at least in this case where p is an unsigned char*.

Even if I'm wrong and your code does work on ARM, I still think memcpy is the correct method, otherwise we're just guessing about portability. Pointer casting can be a nightmare: for example, what about a platform where unsigned long pointers have to be aligned?

[Edit: indeed, alignment is what AndersF suggests is the problem here]

It shouldn't really make a difference to the end product [on x86]: I expect that all modern compilers, on an optimised build, will replace the memcpy with a direct assignment if possible.

When I was talking about this in finnish HTPC -forum (in IRC), there was this comment that VDR has cIconv -class that can be used to convert strings (with error checking).
I can't do coding with C so I don't know if that helps...

But anyway, I guess it would help quite a few people to have UTF support in vomp. Looking forward to be able to test it

- Samuli

Thanks for letting me know about that. It might be useful to convert strings on the server, so the MVP can just assume everything is in UTF-8. But I've already done the work to perform checking on the client, so I'll probably just leave it as it is.

Interesting that you should ask this just now. In the recent bdftobogl thread, I mentioned that I did some work on Unicode and extended font support a long time ago. I hope get it properly finished and in CVS over the Christmas holidays.

The new code supports both UTF-8 and Latin-1. Each string is checked to see whether it is valid UTF-8. If not, it is treated as Latin-1. This way, there should be no problems based on whether people are running UTF-8 or Latin-1 on their servers, and the old Latin-1 language files will continue to work.

Actually it would not be on the mvp (maybe windows). I am working for vomp on something with respect to hdtv, but at the moment I do not know if it leads to something usuable, anyway it will automatically have support for ttf, which may be a good idea for high resolution osd.

Ah, I see. When you said "accelerated", it sounded promising for the MVP

I can see how it makes good sense to provide support for them on Windows.

@Mark

If you implement such a mechanism, it would be nice, if you include also support for other font formats like ttf. Since I am working on something, where ttf fonts are availiable and accelerated.

Marten

Most of the code for the BDF fonts is already done, so if I do find the time to work on this again, I should be able to finish it fairly quickly.

If you're working on a way to support TTF / OTF fonts on the MVP, then I'll just stay with the BDF code for now. We should be able to merge your TTF code with it.

The structure in VOMP came from some very old bdf/bogl code. My guess is that it was taken from the mvpmc project. However, I had to change the structure slightly and re-code some of the characters by hand to work around a bug in the original. The top two lines of characters like Ä Ö Ü were wrapped to the bottom, and there wasn't enough vertical spacing to display them properly at the top.

Almost two years ago  I did some work to enable basic Unicode support and the ability to load fonts directly from BDF files on the VDR server. I really ought to revisit this now and get it into CVS. It is then really easy to use a program like fontforge to convert and edit fonts for use with VOMP.

In the meantime, there unfortunately isn't any software that can produce the exact form of code currently used in VOMP. The bdf2bogl code must still be around somewhere though, which you can use to create almost the right format. Chances are I can dig it out later, or Chris might have it to hand.

Thanks for the patches. The lack of data locking in the player is certainly a problem. I guess Chris will want to look at this, so I won't apply any changes yet.

I don't understand what the problem is with the demuxer. Can you explain what you mean by "copying all the data twice"? I've had a look at your patch and I think your main concern is with the store[TS_SIZE] array. However, most of the data is written directly from the input buffer ("buf" in the put method) to the PES packets. store[] is used for packets that are split between two calls to put, and yes, these packets are copied twice. But that's just 188 bytes per put, and TV data is received in 50K chunks, so only 0.4% of the data passes through store[].

Maybe I've misunderstood your patch, or maybe the demuxer isn't working as I intended it to. It could also be that your rewrite has removed a bug that was previously causing artefacts.

DVB Subtitles are now supported on Live TV. Code is in CVS, and there is a dongle here:

http://www.zen50618.zen.co.uk/vomp/vomp-dongle-cvs20081206

The "record" button is still used for switching subtitles on or off.

Marten, I agree with putting Teletext and DVB subtitles in the same menu, as you suggested. If possible, I think we will combine it all with audio selection, on the green button.

I have committed the DVB subtitles code to CVS. A dongle is also available at
http://www.zen50618.zen.co.uk/vomp/vomp-dongle-cvs20081129

Use the Record button to switch subtitles on and off. Of course this makes no sense and will be changed once we've decided which button to use!

Here are some things that still need to be done or considered:

• Live TV is not yet supported (recordings only)
• There is no indicator to say whether subtitles are available in the current recording.
• The user gets no feedback when subtitles are switched on or off.
• Subtitles do not stay on from one recording to the next. Playback always begins with them switched off.
  
• There is no support yet for multiple subtitle streams (e.g. languages).
• Subtitles can interfere with the progress bar at the bottom of the screen.

If you see any problems or have any ideas that aren't on this list, please post a message.

@Marten: I've made an initial attempt at the Windows code myself, but I can't compile it so it'll need checking. There isn't much: just mutex code and a new surface function for drawing bitmaps instead of plotting one pixel at a time. I'll send you a mail or a PM via the forum covering all the new Windows code when I commit to CVS.

Yes, I have seen your teletext patch... looks good. I think using a new view for teletext (as you have done) is the right way to go, rather than using my OSD interface, because it's the easiest way to accept page number input from the user, and it just seems to make more sense when you're showing a full screen of text. By the way, I think the patch Chris sent to me was missing the teletext font definition files: could you send those across?

Excellent news! Before I do live TV I want to get everything working properly with recordings, so I can get the code into CVS. Apart from multiple language selection... that can come later.

Recordings made with VDR before 1.6 don't actually contain any subtitle data, so there's nothing VOMP can do about those.

Sorry, I'm an idiot. I uploaded my test dongle, where the client doesn't start automatically.

I've replaced the dongle, so please try the download again. Or you can telnet to the MVP and run /vompclient

Thanks, Marten. So in the case where there are multiple TS PIDs for subtitles, I guess VDR renumbers the substreams 0x20, 0x21, etc... because in the TS source they should all be 0x20. As you say, it will be very similar to the audio selection.

But it is also possible to carry several languages in a single TS PID, by using more than one subtitle page ID. I need to read again about where in the TS stream the page information is transmitted, but it doesn't look like VDR stores it anywhere, not in recordings at least.

It might be that broadcasters don't use this feature anyway, and prefer to use separate PIDs, which is much easier. Both methods are mentioned in the DVB subtitles standard.

For synching, the demuxer adds each subtitle to a list, with its PTS value, and signals a separate subtitle display thread. This thread checks the work list, uses Video::getCurrentTimeStamp() to calculate how long to wait for, and then sends the graphics to the display (via a new OSD interface implemented by VVideoRec). If there is no work to do, it just waits for another signal from the demuxer.

I can probably commit all this to CVS as soon as I've implemented some way of switching subtitles on and off.