Message ID | ae19db840803060952u9aeb44q7f6464b34e6d9931@mail.gmail.com |
---|---|
State | New |
Headers |
Received: from gv-out-0910.google.com ([216.239.58.187]) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from <ville.aakko@gmail.com>) id 1JXKH5-0004aO-QV for vdr@linuxtv.org; Thu, 06 Mar 2008 18:53:05 +0100 Received: by gv-out-0910.google.com with SMTP id o2so1790725gve.16 for <vdr@linuxtv.org>; Thu, 06 Mar 2008 09:52:52 -0800 (PST) Received: by 10.142.216.9 with SMTP id o9mr46669wfg.172.1204825969996; Thu, 06 Mar 2008 09:52:49 -0800 (PST) Received: by 10.143.164.14 with HTTP; Thu, 6 Mar 2008 09:52:49 -0800 (PST) Message-ID: <ae19db840803060952u9aeb44q7f6464b34e6d9931@mail.gmail.com> Date: Thu, 6 Mar 2008 19:52:49 +0200 From: "Ville Aakko" <ville.aakko@gmail.com> To: "VDR Mailing List" <vdr@linuxtv.org> In-Reply-To: <47CFADDF.3070204@ventoso.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_30724_15193213.1204825969990" References: <20080304205553.GA29585@srotta.homeip.net> <20080305120231.GA32268@srotta.homeip.net> <20080305164745.GA923@srotta.homeip.net> <47CECF7B.5090709@cadsoft.de> <20080305173822.GA1219@srotta.homeip.net> <47CF0CCB.70309@ventoso.org> <20080305223554.GA1916@srotta.homeip.net> <20080305235759.GB1916@srotta.homeip.net> <47CFACB0.8080604@ventoso.org> <47CFADDF.3070204@ventoso.org> X-LSpam-Score: 0.0 (/) Subject: Re: [vdr] DXR3 and subtitles in 1.5.x X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Thu, 06 Mar 2008 17:53:05 -0000 Status: O X-Status: X-Keywords: X-UID: 15994 |
Commit Message
Ville Aakko
March 6, 2008, 5:52 p.m. UTC
Hi Luca! 2008/3/6, Luca Olivetti <luca@ventoso.org>: > En/na Luca Olivetti ha escrit: > > > >> ... and this went away when I changed the cDxr3SubpictureOsd constructor > >> to call the cOsd with proper level. Unless I'm missing something - and I > >> bet I am - the system seems to be working smoothly now. > > > > Mmh, it should be already doing it, look at line 39 > > > > http://dxr3plugin.cvs.sourceforge.net/dxr3plugin/dxr3/dxr3osd_subpicture.c?revision=1.1.2.18&view=markup&pathrev=vdr-dxr3-0-2 > > > (slaps on head), ok, that's calling it with 0, in my local copy I'm > calling it with Level (probably the problem was introduced when I made > the patch for the cvs version supporting older vdr releases). > Sorry for all the trouble. > > Ville, are you listening? ;-) If you meant me then yes I am =) I made the change locally here too and now it works correctly! Has been bugging me a long time but I've lived with it ;) Sami, I believe you already have it almost in order. I've been using the development VDR all the time, and the only problem has been that the OSD hijacked the OSD (and is now gone thanks to the osdlevel patch). Though, if you get the problem that the OSD doesn't clear between subtitles, then see the 2. patch I'm attaching for vdr-dxr3 plugin (though it could be in the CVS now, I'm using a tarball of the CVS that is somewhat aged now). For reference I'm attaching here all the patches I need to apply to VDR (1.5.15 but probably works with older ones too) and dxr3-vdr plugin on my setup to get it working properly. Are the Gentoo overlay guys listening? These could go into the overlay (but the VDR patch should of course only activate if the dxr3 use flag is set). - Ville
Comments
El Thu, 6 Mar 2008 19:52:49 +0200 > > Ville, are you listening? ;-) > > If you meant me then yes I am =) No, I meant Ville Skyttä, the plugin maintainer, there are many Ville here :-) [...] >Though, if you get the problem that the OSD doesn't clear > between subtitles, then see the 2. patch I'm attaching for vdr-dxr3 > plugin (though it could be in the CVS now, I'm using a tarball of the > CVS that is somewhat aged now). Yes, it should be in cvs, the only thing missing is calling the cOsd constructor with Level instead of 0 Bye
On Thursday 06 March 2008, Luca Olivetti wrote: > Yes, it should be in cvs, the only thing missing is calling the cOsd > constructor with Level instead of 0 That's right - all patches posted for the DXR3 plugin are now in CVS, thanks again to everyone involved. However, Luca and Ville A, you seem to be using different patches to VDR's dvbsubtitle.c - looks like Luca's contains all the changes in Ville A's, but comments those out and uses something else instead. Unless a better fix emerges, I'm quite interested in including one of these in the upcoming VDR 1.6.x package for Fedora and also ship it in the DXR3 plugin tarball (possibly modified so that it's only enabled if the primary device is a DXR3 if possible), but I don't quite follow which would be the preferred one. Could you compare and comment (off-list is fine, this may be getting a bit off topic for the general VDR public)? http://article.gmane.org/gmane.linux.vdr/35860 http://article.gmane.org/gmane.linux.vdr/35881
Ville Skyttä wrote: > On Thursday 06 March 2008, Luca Olivetti wrote: > >> Yes, it should be in cvs, the only thing missing is calling the cOsd >> constructor with Level instead of 0 > > That's right - all patches posted for the DXR3 plugin are now in CVS, thanks > again to everyone involved. > > However, Luca and Ville A, you seem to be using different patches to VDR's > dvbsubtitle.c - looks like Luca's contains all the changes in Ville A's, but > comments those out and uses something else instead. > > Unless a better fix emerges, I'm quite interested in including one of these in > the upcoming VDR 1.6.x package for Fedora and also ship it in the DXR3 plugin > tarball (possibly modified so that it's only enabled if the primary device is > a DXR3 if possible), but I don't quite follow which would be the preferred > one. > > Could you compare and comment (off-list is fine, this may be getting a bit off > topic for the general VDR public)? Preferably on-list, as I'm planning a similar conditional patch for Mandriva VDR 1.6.x packages. That is, unless something better emerges. > http://article.gmane.org/gmane.linux.vdr/35860 > http://article.gmane.org/gmane.linux.vdr/35881
En/na Anssi Hannula ha escrit: > Preferably on-list, as I'm planning a similar conditional patch for > Mandriva VDR 1.6.x packages. That is, unless something better emerges. Keep in mind that the patch could be detrimental if you have something other than a dxr3 with a better osd (though I'm using it with either the dxr3 or a xine frontend and in both cases I can read the subtitles just fine, in fact with xine I cannot tell the difference with or without the patch). Bye
On Thu, Mar 06, 2008 at 08:42:30PM +0200, Ville Skyttä wrote: > Unless a better fix emerges, I'm quite interested in including one of > these in the upcoming VDR 1.6.x package for Fedora and also ship it in > the DXR3 plugin tarball (possibly modified so that it's only enabled > if the primary device is a DXR3 if possible), but I don't quite follow > which would be the preferred one. Both amount to same thing - setting bpp for each area to 2 - but Luca's patch does it in cleaner way, so that's what I would use.
On Thu, Mar 06, 2008 at 07:52:49PM +0200, Ville Aakko wrote: > Sami, I believe you already have it almost in order. I've been using > the development VDR all the time, and the only problem has been that > the OSD hijacked the OSD (and is now gone thanks to the osdlevel > patch). Though, if you get the problem that the OSD doesn't clear > between subtitles, then see the 2. patch I'm attaching for vdr-dxr3 > plugin (though it could be in the CVS now, I'm using a tarball of the > CVS that is somewhat aged now). Yep, I seem to have the second patch, so it's looking good now, thanks. I'm having some stability problems, though - every once in a while changing the channel or doing some fast moves with OSD freezes the screen. Don't know what the problem is, yet. Possibly related to this is that the subtitles have gone missing a couple of times. I haven't been able to pinpoint what exactly happens here, but my guess is it's got something to do with DXR3 :P
2008/3/9, Sami Sundell <sami.sundell@kotikone.fi>: > > I'm having some stability problems, though - every once in a while > changing the channel or doing some fast moves with OSD freezes the > screen. Don't know what the problem is, yet. Possibly related to this is > that the subtitles have gone missing a couple of times. I haven't been > able to pinpoint what exactly happens here, but my guess is it's got > something to do with DXR3 :P What skin are you using? I've noticed that the only skins that are usable (i.e. stable enough to use them) are those of text2skin plugin - more specifically, I use enElchi. Some other were stable, too. Anything else (including skinsoppalusikka, which is identical in appearance to enElchi but standalone) and I just can't use my VDR without losing my nerves. I still get OSD freezes, but only very rarely (i.e. maybe once in every 12 hours of active use; i.e. watching recordings and such). - Ville
On Sun, 9 Mar 2008, Ville Aakko wrote: > What skin are you using? I've noticed that the only skins that are > usable (i.e. stable enough to use them) are those of text2skin plugin > - more specifically, I use enElchi. Some other were stable, too. > Anything else (including skinsoppalusikka, which is identical in > appearance to enElchi but standalone) and I just can't use my VDR > without losing my nerves. You could try the latest soppalusikka as there were some osd update tweaks. At least with xineliboutput the cpu load was reduced ~20% on a core2duo+nvidia setup, so the skin is nowadays less demanding for the hardware... BR, -- rofa
En/na Rolf Ahrenberg ha escrit: > On Sun, 9 Mar 2008, Ville Aakko wrote: > >> What skin are you using? I've noticed that the only skins that are >> usable (i.e. stable enough to use them) are those of text2skin plugin >> - more specifically, I use enElchi. Some other were stable, too. >> Anything else (including skinsoppalusikka, which is identical in >> appearance to enElchi but standalone) and I just can't use my VDR >> without losing my nerves. > > You could try the latest soppalusikka as there were some osd update > tweaks. At least with xineliboutput the cpu load was reduced ~20% on a > core2duo+nvidia setup, so the skin is nowadays less demanding for the > hardware... I'm still using 1.0.4 (and, yes, from time to time I have osd problems with the dxr3), but a performance improvement could be actually a bad thing for the dxr3 (if it translates to more osd updates). In fact I think that text2skin works well enough for Ville because it is slow (at least it was last time I used it). Bye
On Sun, 9 Mar 2008, Luca Olivetti wrote: > I'm still using 1.0.4 (and, yes, from time to time I have osd problems > with the dxr3), but a performance improvement could be actually a bad > thing for the dxr3 (if it translates to more osd updates). Well, in this case the performance improvement means less work for the osd provider as I've eliminated unnecessary osd accesses. Hence the lower CPU load on the xineliboutput setup. I didn't mention about those tweaks in HISTORY, but they should be included in version 1.1.5 and a few more in the next release. BR, -- rofa
2008/3/10, Rolf Ahrenberg <rahrenbe@cc.hut.fi>: > On Sun, 9 Mar 2008, Luca Olivetti wrote: > > > I'm still using 1.0.4 (and, yes, from time to time I have osd problems > > with the dxr3), but a performance improvement could be actually a bad > > thing for the dxr3 (if it translates to more osd updates). > > > Well, in this case the performance improvement means less work for the > osd provider as I've eliminated unnecessary osd accesses. Hence the > lower CPU load on the xineliboutput setup. I didn't mention about those > tweaks in HISTORY, but they should be included in version 1.1.5 and a > few more in the next release. I tried skinsoppalusikka. It is a bit more stable, but not enough. Channel surfing and menus seem to be generally more stable. Editing, (putting marks and moving them), and most notably, jumping to a certain position via the red button is still PITA with skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit different when it starts being buggy; the "flickering" I get is different and it doesn't hang as often as it used to. So you can feel something has changed =). I still get more random crashes with skinsoppalusikka, than with text2skin. Also, skinsoppalusikka doesn't update the palette of channel logos, if the OSD isn't closed in between channel changes (this is notable only when channel surfing, but if you wait a while, let the OSD close itself, and then change channel, the logo is shown in right colors). Just for your information (it probably isn't worth the trouble to get skinsoppalusikka working properly on DXR3, unless you have some ideas what to try), and also for DXR3 users who are looking for a stable OSD. - Ville
On Sun, 30 Mar 2008, Ville Aakko wrote: > Channel surfing and menus seem to be generally more stable. Editing, > (putting marks and moving them), and most notably, jumping to a > certain position via the red button is still PITA with > skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit Did you test it with the latest skinsoppalusikka-1.6.0? I added similar osd performance tweaks for replay mode into that particular version. > Also, skinsoppalusikka doesn't update the palette of channel logos, if Well, IMO the skin isn't responsible of palette updates, but the real problem might be in the osd implemantation of DXR3 plugin. BR, -- rofa
En/na Rolf Ahrenberg ha escrit: >> Also, skinsoppalusikka doesn't update the palette of channel logos, if > > Well, IMO the skin isn't responsible of palette updates, but the real > problem might be in the osd implemantation of DXR3 plugin. channel logo *must* be disabled for the dxr3. Bye
En/na Rolf Ahrenberg ha escrit: >> Also, skinsoppalusikka doesn't update the palette of channel logos, if > > Well, IMO the skin isn't responsible of palette updates, but the real > problem might be in the osd implemantation of DXR3 plugin. channel logo *must* be disabled for the dxr3. Bye
2008/3/30, Rolf Ahrenberg <rahrenbe@cc.hut.fi>: > On Sun, 30 Mar 2008, Ville Aakko wrote: > > > Channel surfing and menus seem to be generally more stable. Editing, > > (putting marks and moving them), and most notably, jumping to a > > certain position via the red button is still PITA with > > skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit > > > Did you test it with the latest skinsoppalusikka-1.6.0? I added > similar osd performance tweaks for replay mode into that particular > version. No, sorry! I thoiught I was using the latesta, but I wasn't. But after some quick testing, it still seems unstable in the editing mode, > > Also, skinsoppalusikka doesn't update the palette of channel logos, if > > > Well, IMO the skin isn't responsible of palette updates, but the real > problem might be in the osd implemantation of DXR3 plugin. Yes, that is most probably true. I was merely stating what I'm experiencing with skinsoppaluskka and the logos =) - Ville
2008/3/31, Luca Olivetti <luca@ventoso.org>: > > channel logo *must* be disabled for the dxr3. But they look neat =) But, seriously, they work very nicely with text2skin here, and used to work in and older VDR / skinsoppalusikka, too (providing you use logos with decreased number of colours, but I really couldn't tell the difference when I opened both versions of some of the logos in an editor on my computer). So it IS a small regression (triggered in the plugin by changes in skinsoppalusikka). But the real problem here was the stability, into which the logos have no effect. Well, honestly, I didn't try the 1.6.0 without logos, but I assume this, because 1) disabling the channel logos didn't have any effect in a previous skinsoppalusikka, and 2) the instablility occurs in editing mode and when going trough the menus, i.e. NOT when any logos are shown on the screen. The "palette of the logos not updating" is, on the other hand, a very minor and purely cosmetic problem. - Ville
Seems that my brain stopped working in the middle of a sentence here : 2008/4/2, Ville Aakko <ville.aakko@gmail.com>: > > No, sorry! I thoiught I was using the latesta, but I wasn't. But after > some quick testing, it still seems unstable in the editing mode, ... , but I need to do some more testing, before I can say if the 1.6.0 is more stable than 1.1.5. - Ville
On Wed, 2 Apr 2008, Ville Aakko wrote: >> No, sorry! I thoiught I was using the latesta, but I wasn't. But after >> some quick testing, it still seems unstable in the editing mode, > ... , but I need to do some more testing, before I can say if the > 1.6.0 is more stable than 1.1.5. Increasing the "Osd Flush Rate" value in DXR3 plugin setup might make things a bit more stable... BR, -- rofa
On Wed, 2 Apr 2008, Ville Aakko wrote: > But, seriously, they work very nicely with text2skin here, and used to > work in and older VDR / skinsoppalusikka, too (providing you use logos > with decreased number of colours, but I really couldn't tell the You don't happen to remember when things went broken? An exact version number would help a lot... BR, -- rofa
diff -Naur vdr-1.5.10/dvbsubtitle.c vdr-1.5.10-new/dvbsubtitle.c --- vdr-1.5.10/dvbsubtitle.c 2007-10-14 17:02:35.000000000 +0300 +++ vdr-1.5.10-new/dvbsubtitle.c 2007-11-04 13:17:19.000000000 +0200 @@ -982,13 +982,13 @@ return; tArea *Areas = Page->GetAreas(); int NumAreas = Page->regions.Count(); - int Bpp = 8; + int Bpp = 4; bool Reduced = false; - while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) { +// while (osd->CanHandleAreas(Areas, NumAreas) != oeOk) { int HalfBpp = Bpp / 2; if (HalfBpp >= 2) { for (int i = 0; i < NumAreas; i++) { - if (Areas[i].bpp >= Bpp) { + while (Areas[i].bpp >= Bpp) { Areas[i].bpp = HalfBpp; Reduced = true; } @@ -997,7 +997,7 @@ } else return; // unable to draw bitmaps - } +// } if (Reduced) { for (int i = 0; i < NumAreas; i++) { cSubtitleRegion *sr = Page->regions.Get(i);