Messages

What is the status for subtitles?
I volunteer to betatest dongle with subtitle -support (either one). 

Here you go then, but it's more alpha than beta:

http://www.zen50618.zen.co.uk/vomp/vomp-dongle-cvs20081123-subtitles-a1

You asked just at the right time! I spent most of the weekend on this.

Some notes:

1. It only works with recordings at the moment. So the recordings have to be made with vdr 1.6 (or 1.5.something). svalavuo, I see you're running 1.6, so that's not a problem for you.
Live TV shouldn't be hard to do; I just haven't bothered with it yet.

2. This dongle will always show subtitles. You can't switch them off.

3. Skipping / fast foward / fast backward aren't handled properly yet. The client shouldn't crash, but subtitles might not work properly if you skip around.

4. If the recording contains more than one subtitle service, this dongle will only show the first one it sees.

I'm particularly interested in the last point. If anyone has any recordings of programmes with more than one subtitle service (for example, more than one language), I'd like to get a sample to see how VDR deals with it.

Sorry it's taken so long! Please report any successes, crashes, comments, etc...

Just out of interest, do you mean you have got the binary running in a gnome environment? Albeit with all the KDE stuff installed?

Chris, IIRC you told me that the phonon stuff doesn't work if you're not running the full KDE. On Debian / Ubuntu, at least.

The bug below has just been fixed in Debian. Not sure if it's relevant, but people have commented in it about phonon not working if you've never started a KDE4 session.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498573

Lutz, are you using the 0.2.7 release or the latest code from CVS? If you're using 0.2.7 I can't see how this can happen because all the translations are compiled into VOMP: the set-up of VDR shouldn't make any difference.

If you're using the CVS code, with language files loaded from the VDR server, have you edited the German l10n file (main-de) and perhaps saved it as Unicode by mistake? You could try downloading the original file again from the sticky thread "New I18n system in CVS".

Yes, I'm still interested in doing subtitles. Last night I tested to see whether a simple method of timing the subtitles is good enough, and the results were pretty good.

Marten, if you're following the thread, I know you were concerned about this from the WIndows side, but if you can get your Video object to report the master clock value during both live TV and recordings, at least as accurately as the MVP, then things are looking good.

I hope to start work on adopting the DVB subtitle code from VDR this weekend, and I need to discuss with Chris the best way of passing subtitles to the display system.

Teletext subtitles will have to wait until later, and then it'll either have to be written and tested by someone with access to a Teletext subtitle service, or I'll need a sample recording.

We're getting there, slowly!

Hi morfsta! Welcome to the forum.

There is a bug in VOMP that stops recordings made with the newer VDR 1.5 versions from playing back, due to the subtitles that are now included in the recording.

The bug is fixed in CVS, so yes, it should work... once you can get it to boot! Someone with an H3 might be able to help you there.
Have you built your own CVS dongle or have you got one from the Web?

For this dynamic OSD stuff it would be nice, if we can discuss the way it will be implemented in advance, so that it can be easily ported to windows.
Especially I'm unsure if the timing stuff should be in the device dependent objects or in os dependent framework.

Yep, don't worry, I always try to keep the Windows port in mind. In fact I try to think in more general terms of an unspecified output device, as in future there will probably be other OS's or hardware boxes requiring support.

I'm not going to start anything until I've talked to Chris, and I expect he'll be exchanging emails with you. I haven't thought about it properly yet, and this may be too simplistic, but I expect the existing device-dependent Video::getCurrentTimeStamp() to supply all we need for timing. A good solution (provided it exists) will "just work" on both platforms.

I don't intend to greed, but how about teletext -subtitles? 
In 1.5.12 there is only DVB -subtitles builtin, but teletext subtitles are more common (at least in Finland).

Well it will definitely be DVB subtitles first, so that we can test the system locally in the UK with live data.

Once that's done, we would hopefully have a fairly general system for displaying dynamic OSD over the video, so a back end for teletext could follow, either written by us or someone else.

Sounds good in theory anyway

I spent ages looking at that code and convinced myself it was OK 

Yeah, it did look OK. Probably a bad design decision on my part, that the function has to "pretend" it has processed the data instead of just ignoring the packet.

So does this mean that subtitles -support is no longer on "short-term roadmap"?

Well, I can't promise anything yet, but fixing that bug and installing vdr 1.5.12 got me interested, and I now have the vdr subtitles code and can fiddle with it.
I hope we can use a lot of that VDR code as it stands, leaving the hard bit Marten mentioned: synchronising with the video/audio streams.
I'll be seeing Chris before the new year so we might find time to discuss it and think about what's involved.

Hopefully over the break I'll work out why VOMP won't play recordings made with vdr > 1.5.9 (ie versions with subtitling support). Maybe one small step on the road to subtitles...

I think I've just solved this one. There was a bug in the AC3 audio code: if the demuxer came across a private stream packet that was not an AC3 packet (like a subtitle packet) then it just hung on it forever.

Fixed in CVS. I can't test AC3 but I've tried my best not to break it in the process

Hi Harry,

No, this only covers texts displayed by the VOMP client.

"VOMP client(s) connected" is the only text in the server code that asks to be translated. At some point we'll have to decide whether to bother setting up gettext / RegisterI18n for it, or just take out the call to tr() and leave it in English.

[For users running CVS code:]

The CVS code now uses a new system for internationalisation. The translations are no longer compiled into the client, but loaded from vompserver at runtime. I hope it will make the job of translation a lot easier. This obviously has an impact on translators, developers and users running CVS code.

For users running CVS code:
As Chris mentioned in a recent post, we now use the directory plugins/vompserver/ for the config files. The attached zip file should be extracted here, to produce the following directory tree:
plugins/vompserver/l10n/<translation files>
These files will be added to CVS, and we'll distribute them properly with the next release.

The client language settings will not be carried over from the old system. The first time a new CVS client runs, it will choose a language from the ones it finds on the server, with a preference for English.
If you want all your clients to use the same language automatically, for example German, the easiest solution is to install only the main-de and missing-de files into the l10n directory.

For translators:
The format of the new files should be fairly obvious. The format-definition in the zip file explains things in detail.
The encoding is still Latin-1. My next step is to convert to UTF-8 and extend (or replace) the font system.

For each language, there is a missing-* file, which lists the texts that have not yet been translated. It would be great if somebody who speaks one of these languages well could go through and fill in the missing texts. Please don't mix new translations into the main-* files; just leave them in a separate file and they will work. That way you can send us the file (or attach it here) containing only your new translations. I have some simple tools that can merge the files together with the texts in the correct order.

To test a new translation, either reboot the client or simply switch languages in the options screen.

The master-keys file is a complete list of all the texts that require translation.

For developers:
If you're writing code with text that should be localised, stop adding stuff to the language-data.h file and start patching the master-keys file (or simply send a list of new texts), along with translations into whatever languages you know, of course.

I have left the language-data.h file in CVS for now, in case anyone needs to diff a modified version against it.

Is there available source for 2.7 client around, I can compile that with the language file to test?

As well as the pull-by-date method Fourty2 mentioned, you can pull a specific release:

cvs update -r r0-2-7

The -D and -r tags are 'sticky'; to clear them and revert to the mainline, you can use

cvs update -A

If you browse CVS on sourceforge.net, there is a drop-down box showing all the available tags for the -r option.

How is the channel requested from VDR?  Is it by pids like you can do with streamdev?

VDR sends all the audio channels to VOMP: it just transmits the raw TS stream. The TS demuxer filters out packets from the selected video/audio PIDs. Currently, it always uses the first PID in the list obtained by VDR::getChannelPids. This process starts in VVideoLive::play and the first PID is passed to Player::play and from there to DemuxerTS::setAID.

I'm not sure how you're sorting the channel list in channelFromNumber; that would appear to involve modifying a standard VDR channel object. If I were doing this on the server side, I'd probably try changing the processGetChannelPids function to loop over the channel->Apid() list in a different order, when building the network packet to send to VOMP.

2) Faulty channel conf, the vdr has not recorded video data. Do you have an headless vdr or a full vdr? Can you check if the recordings are fine?
3) Bug in vomp, what is your vdr version? If you have an old vdr version, maybe vomp misdetects the recordings as radio .

I don't think it can be either of these, because the PTS JUMP message only occurs when the demuxer is analysing a video packet. It could be that the video packets exist but are corrupted.
But the same problem occurs with live TV, so it's very unlikely that there is a bug specific to recordings.

goldfisch: if possible could you provide an example of a recording... the index.vdr and the first 10 or 20 MB of the 001.vdr should be enough. (Either put it on the Web somewhere or I'll see if I can open ftp for you. Email as a last resort ) Then we can see if the problem is only with your MVP.

These messages:

21:03:23.067913 [debug]  TS Demuxer - Packet overflow, pid 101

are nothing to worry about. I think Chris has taken that debug message out of the CVS code now.

But these:

21:20:51.137629 [debug]  Demuxer - +* PTS JUMP *+ 1385315296 456

might be a problem. Possibly the demuxer can't synchronise the video and audio (IIRC the audio starts playing first and the video waits until it's in sync).

I don't know why this would be, unless the MVP is expecting an NTSC frame rate. (I don't really believe this, but it would explain why the demuxer thinks the time stamps are wrong.) Maybe the answers to Marten's questions will give us a clue.

One more question: do the "PTS JUMP" messages keep happening as long as the audio is playing, or do they stop?