I was sitting in the kitchen thinking through a few things that would make life slightly easier on my vomp thingy. I don't know how realistic these could be, but I wondered if they could be considered and I thought someone might also agree. Firstly though.. Thank you, thank you, thank you for audio support. It has made my life so much better as I can leave VDR to auto update.
1. To have bouquets.
I have things like:
:->sky ita - general
:->uk tv
Scattered throughout my channels.conf which I can skip to using a right arrow in VDR itself.
I use skip fwd and skip bkwd to go up and down a page already, but another couple of keys to skip to the next marker (which could be visable in the channel list) would be really cool. Also would be good in the epg page.
Maybe even:
1. Watch TV.
Second option (List of Bouquets):
1. sky ita
2. uk tv
3. etc
Third Option
1 Rai 1
2 Rai 2
3 etc
or
1 BBC 1
2 BBC 2
3 ITV
or even
123 BBC 1
124 BBC 2
If we can't reorder channel numbers.
I think this will really help when we have 1000's of channels.
2. To be able to scroll epg description if it's too big for the box. (I use the Radio Times listings, and they can go on a bit.)
3. Quick screen resolution change. (for changing between widescreen and not)
There are three issues with a widescreen TV.
1. 4:3 looks stretched.. An option for side black borders could be nice.
2. widescreen broadcast by braindead European operators like Sky who put a black border top and bottom. (A way to display full width but chop top and bottom)
3. 16:9 looks good on 16:9 settings.
(On a 4:3 tv the normal options are ok)
4. Having an icon on the programme banner at the bottom saying the original source would be nice. (ie, 16:9 or 4:3) - maybe a way to know which DVB card you're watching too, as the signal is better on one than the other on a couple of channels, but I never know which I am on.
4. Weather forcast?
(Yeh I know it's fluff, but we used it a lot on the dreambox).
5. A way of editing the channels.conf file?
(I guess this would be a major project, but if we could have a fairly quick and easy Move, delete it would be good).
6. Childprotection Pin. (To lock off all those channels you don't want your 10 year old finding, instead of hiding them up around channel 7000 and hoping they don't notice) (Deleting them is not an option as VDR just adds them again and if they go up instead of down they get to the other end of the channel list). This could be found in a quick lookup file. A way to add a channel to this list would be good too.
7. A way to execute commands on the server..
(ie, just display and execute whatever is in commands.conf)
8. Button change for the audio language change.
We're using green for both epg info (if we click ok first) and audio. Why not have green for calling up epg info regardless of whether OK is pushed and yellow for audio change?
As always, thanks guys, this is really good and usable. We're watching it in three rooms constantly.
I guess there's as many wishlists as there is users :)
For me no 1 wish is subtitles (DVB & teletext)
Other wishes in previous posting are good too, but subtitles is defenately #1.
Here are my (old) thoughts on new features/wishlist:
http://www.loggytronic.com/forum/index.php?topic=49.0
http://www.loggytronic.com/forum/index.php?topic=126.0
Today my wishlist-priorities would be:
1. Teletext/Videotext
2. Timeshifting/Pausing/Resuming in LiveTV
3. Advanced Set/Edit Timers (we would need a typing-function for making new folders etc.)
4. Renaming Recordings (also needs that input-typing-function from No. 3)
5. Scrolling long epg-descriptions
6. Advanced Mediaplayer (esp. Video-Transcoding)
7. Direct Channel-selection while onscreen-display is shown (#keys while now/next-box is shown)
8. Skin-Engine for advanced/alternate screen-surfaces
9. Prettier Channel-Selection (e.g. with channel-icons?)
10. Channel-Bouquets/Tabs ( i habe in mind categories like public channels, private channels, news, sport etc., selectable viiews in tabs/registers)
11. editing channels.conf
When reading my old lists, i just realized what fantastic progresses VOMP has made during the last two years. A very loud THANK YOU to Chris and all other contributing developers!
Yours
Schnurps
Quote from: rdoac on November 10, 2007, 16:32:39
2. To be able to scroll epg description if it's too big for the box. (I use the Radio Times listings, and they can go on a bit.)
Quote from: Schnurps on November 11, 2007, 13:19:57
5. Scrolling long epg-descriptions
Before doing double work, I would like to tell that I have a nearly finished implementation done yesterday. Cleanup and polishing still open.
Please expect this or latest next week the patch for review.
Philipp
Does anyone know if subtitles support is huge or gigantic work? :)
I tried to read dongle code, but didn't understand a bit. I do programming with other languages.
Scrolling long EPG data is great too.
Great job everyone contributing efforts for vomp (server & dongle)!
I'd really appreciate to have full cutting marks support...
Lutz
Quote from: Lutz on November 13, 2007, 12:09:52
I'd really appreciate to have full cutting marks support...
Lutz
This would be great too.
Wonder if this is possible though.
If SVDRP is used, it is not. http://www.linuxtv.org/vdrwiki/index.php/Svdrp
Quote from: svalavuo on November 13, 2007, 09:45:22
Does anyone know if subtitles support is huge or gigantic work? :)
I'm not sure that subtitling is working correctly in VDR yet. There are discussions on the VDR mailing list about problems with the new subtitle code.
I can use VOMP with VDR 1.5.11 to view live TV or watch existing recordings, but if I make a new recording using 1.5.11 of a programme which has subtitles, playback freezes after a few seconds. VOMP hasn't crashed; the remote control still works, and I can view the recording on the server using mplayer. Hopefully thisis a VDR issue.
Once VDR is stable it presumably wouldn't be too difficult to use similar code in VOMP to extract the text. I don't know what would be involved in displaying text on-screen.
Quote from: svalavuo on November 13, 2007, 12:39:43
If SVDRP is used, it is not. http://www.linuxtv.org/vdrwiki/index.php/Svdrp
AFAIK: Vomp doesn't use SVDRP at all. It's directly linked to the vdr-libs as a plugin.
Quote from: davep on November 13, 2007, 17:02:53
I'm not sure that subtitling is working correctly in VDR yet. There are discussions on the VDR mailing list about problems with the new subtitle code.
I can use VOMP with VDR 1.5.11 to view live TV or watch existing recordings, but if I make a new recording using 1.5.11 of a programme which has subtitles, playback freezes after a few seconds. VOMP hasn't crashed; the remote control still works, and I can view the recording on the server using mplayer. Hopefully thisis a VDR issue.
Once VDR is stable it presumably wouldn't be too difficult to use similar code in VOMP to extract the text. I don't know what would be involved in displaying text on-screen.
Yes, I forgot that they "broke" subtitles in 1.5.10 -> :P
Subtitles worked fine in previous versions using plugin, but new subtitles -system isn't the same code because if you record show with subtitles using 1.5.(10/11) and try to watch it with previous versions, subtitles doesn't work. Other way it works.
Keeping that in mind, it would be better to implement subtitles in vomp dongle (and vomp server?) when they work in 1.5.x.
Does vompserver forward all data from stream to dongle (including teletext and subtitles and...) or does is strip data?
Quote from: muellerph on November 13, 2007, 17:06:52
AFAIK: Vomp doesn't use SVDRP at all. It's directly linked to the vdr-libs as a plugin.
OK. I didn't know this. Some plugins are using SVDRP though.
Does vompserver forward all data from stream to dongle (including teletext and subtitles and...) or does is strip data?
All data is forwarded. Be careful subtiles is a tough task, because you have to the synchronisation with audio video...
Quote from: MartenR on November 14, 2007, 07:32:15
Be careful subtiles is a tough task, because you have to the synchronisation with audio video...
As I mentioned previously, I can't code anything with c :)
I wish someone can though.
We will see what Santa Claus is bringing. ;)
Walter
Firstly I will say that subtitles is on my wishlist too, though it does look like a chunk of work, though I haven't fully investigated yet.
"Santa Claus" is bringing something (check CVS for how broken it is atm!) but it won't be subtitles. Well, not from me anyway.
Chris:
It's so great news, that someone from the core development team is interested of subtitles.
I would go to teletext subtitles first (more common) and after that DVB subtitles (not used in meny countries (afaik)).
When I would like to see another issue solved is a support like the Avards-Plugin (http://www.vdr-portal.de/board/thread.php?threadid=71314).
This thread is in german, so I translate the topic:
The Avards-Plugin is use for the automatic recognition and surpression of the black borders when widescreen material is broadcasted in a 4:3 mode (letterbox format). This is done in a way so that the TV gets via the WSS signal a zoom factor.
Some stations are still broadcasting everything in 4:3. Now that I have 2 16:9 TVs this is very ugly. I need to switch on the TV all the time the zoom factor and then I don't see the OSD anymore. So in order to see the OSD I need to toggle the TV setting again.
Also I have the impression, that when we send the compressed signal through the SCART cable and zoom at the TC we get a lower qualtiy then if we already send a zoomed picture through SCART and don't need to do anything on TV.
That sounds quite good. Quite a lot of UK TV is already 16:9, so we have a widescreen TV. However, Italian TV is 4:3, and when they go for 16:9 they broadcast it with top and bottom borders and a channel logo at the top. Xineliboutput does a fairly good job of scaling it (on the fly) and chops the logo (which is ok by me).
However, having a button on the Vomp menu, say zoom, which scales up the source could work? Or is there a cleverer way to do it?
Hi,
Anyone doing anything for subtitles -support?
Chris mentioned, that subtitles -support isn't in Santa's bag, but where does it place in roadmap?
Actualy subtitles is the property in MVP for me at the moment.
My colleague is in same situation and I assume that every user in Finland with MVP wishes subtitles -support appear asap.
I don't intend this as complaint, I'm happy user of great product!
Thank you everyone participating development of this great project!
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...
davep: great news! :)
Can it be something to do with the style (or mean, or way, or something) of saving subtitles with the stream?
I don't know what is the reason that vdr > 1.5.9 subtitles aren't compatible with vdr < 1.5.10.
Earlier versions used plugin for subtitles and now it's builtin, but why they changed the way that I don't know.
I noticed that recordings made with vdr > 1.5.9 don't play correctly with vdr < 1.5.10 (subtitles doesn't work). Probably same reason they don't play through vomp with MVP.
Quote from: davep on December 17, 2007, 16:40:31
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 :)
So does this mean that subtitles -support is no longer on "short-term roadmap"?
I can't do any C programming (or C++ either), but is there anything I could do to help to get subtitles (teletext & DVB) to work with MVP?
It is quite important to at least to us in Finland.
Quote from: MarkC on December 19, 2007, 00:01:21
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 :)
I spent ages looking at that code and convinced myself it was OK :-\
Yes that now works with recordings from vdr > 1.5.9. Many thanks.
Quote from: davep on December 19, 2007, 16:14:36
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.
Quote from: svalavuo
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.
It would be great!
I don't intend to greed, but how about teletext -subtitles? ;D
In 1.5.12 there is only DVB -subtitles builtin, but teletext subtitles are more common (at least in Finland). :)
Quote from: svalavuo on December 21, 2007, 08:20:44
I don't intend to greed, but how about teletext -subtitles? ;D
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 :)
Sounds great!
As I mentioned earlier, we have DVB -subtitles in national channels (YLE & some MTV3 -channels) so DVB -subtitles support will be great.
Teletext -subtitles is used by pay/movie -channels (Canal+, Viasat, ...).
QuoteOnce 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.
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.
Marten
Quote from: MartenR on December 23, 2007, 17:12:44
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.
Quotebut 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 am just wondering, if Video::getCurrentTimeStamp() is accurate enough on all platforms.
I do not, if accuracy is so important for subtiteling...
Anyway a way with Video::getCurrentTimeStamp(), if it works, it will be fine on all platforms.
I do not remember, if the windows implementation will work also for live tv, but this will be correctable.
I have also thought about a separate subtitling device, which will care for the right presentation time -on windows, this can be more accurate, but may be the Video::getCurrentTimeStamp() is accurate enough.
QuoteIn 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.
Well, I think, that we have to generalize the output device stuff, in the long time run, if more hardware should be supported, because in the moment it is relatively mvp dependent.
For the long time run, if HDTV is becoming more important a linux based streaming box like mediamvp will be a nice target, but actually there is no such box outside.
Marten