Re: [vdr] [path] vdr-1.6 better spu on ff card
matthieu castet a écrit : Hi, this patch try to handle case where the osd is limited (for example on ff card). For that it try to split area, count the really needed bpp (all transparent index can be merged together and will with my previous patch in osd.c). Also it fix a bug in the current version : removing all the transparent baground area is ok only if it is recomputed at each draw. Otherwise a highlight request can happen outside the computed area. With this patch I can navigate in dvd menu that produce oeOutOfMemory before. Matthieu I forgot the patch... --- vdr-1.6.0/dvbspu.c 2007-02-03 11:13:18.0 +0100 +++ vdr-1.6.0p/dvbspu.c 2009-11-21 21:48:54.0 +0100 @@ -335,6 +335,35 @@ return size; } +int cDvbSpuBitmap::getMinBpp(const aDvbSpuPalDescr paldescr) +{ +int col = 1; +for (int i = 0; i < 4; i++) { +if (paldescr[i].trans != 0) { +col++; +} +} +return col > 2 ? 2 : 1; +} + +int cDvbSpuDecoder::CalcAreaBpp(cBitmap *fgbmp, cBitmap *bgbmp) +{ +int fgbpp = 0; +int bgbpp = 0; +int ret; +if (fgbmp) { +fgbpp = spubmp->getMinBpp(hlpDescr); +} +if (bgbmp) { +bgbpp = spubmp->getMinBpp(palDescr); +} +ret = fgbpp + bgbpp; +if (ret > 2) +ret = 4; +return ret; +} + + void cDvbSpuDecoder::Draw(void) { cMutexLock MutexLock(&mutex); @@ -342,43 +371,89 @@ Hide(); return; } - +sDvbSpuRect bgsize; cBitmap *fg = NULL; cBitmap *bg = NULL; -sDvbSpuRect bgsize; -sDvbSpuRect hlsize; - -hlsize.x1 = hlpsize.x1; -hlsize.y1 = hlpsize.y1; -hlsize.x2 = hlpsize.x2; -hlsize.y2 = hlpsize.y2; if (highlight) -fg = spubmp->getBitmap(hlpDescr, palette, hlsize); +fg = spubmp->getBitmap(hlpDescr, palette, hlpsize); if (spubmp->getMinSize(palDescr, bgsize)) bg = spubmp->getBitmap(palDescr, palette, bgsize); -sDvbSpuRect areaSize = CalcAreaSize(hlsize, fg, bgsize, bg); +if (osd == NULL) { +restricted_osd = false; +osd = cOsdProvider::NewOsd(0, 0); + +tArea Area = { size.x1, size.y1, size.x2, size.y2, 4}; +if (osd->CanHandleAreas(&Area, 1) != oeOk) +restricted_osd = true; +else +osd->SetAreas(&Area, 1); +} +if (restricted_osd) { +sDvbSpuRect hlsize; +bool setarea = false; +/* reduce fg area (only valid if there is no bg below) */ +if (fg) { +spubmp->getMinSize(hlpDescr,hlsize); +/* clip to the highligh area */ +setMax(hlsize.x1, hlpsize.x1); +setMax(hlsize.y1, hlpsize.y1); +setMin(hlsize.x2, hlpsize.x2); +setMin(hlsize.y2, hlpsize.y2); +if (hlsize.x1 > hlsize.x2 || hlsize.y1 > hlsize.y2) { +hlsize.x1 = hlsize.x2 = hlsize.y1 = hlsize.y2 = 0; +} +} +sDvbSpuRect areaSize = CalcAreaSize((fg && bg) ? hlpsize : hlsize, fg, bgsize, bg); -if (!fg || !bg || !osd) { - Hide(); - } +#define DIV(a, b) (a/b)?:1 +for (int d = 1; !setarea && d <= 2; d++) { -if (bg || fg) { -if (osd == NULL) { - osd = cOsdProvider::NewOsd(0, 0); - if ((areaSize.width() & 3) != 0) - areaSize.x2 += 4 - (areaSize.width() & 3); - tArea Area = { areaSize.x1, areaSize.y1, areaSize.x2, areaSize.y2, (fg && bg) ? 4 : 2 }; - if (osd->SetAreas(&Area, 1) != oeOk) +/* first try old behaviour */ +tArea Area = { areaSize.x1, areaSize.y1, areaSize.x2, areaSize.y2, DIV(CalcAreaBpp(fg, bg), d) }; + +if ((Area.Width() & 7) != 0) +Area.x2 += 8 - (Area.Width() & 7); + +if (osd->CanHandleAreas(&Area, 1) == oeOk && +osd->SetAreas(&Area, 1) == oeOk) +setarea = true; + +/* second try to split area if there is both area */ +if (!setarea && fg && bg) { +tArea Area_Both [2] = { +{bgsize.x1, bgsize.y1, bgsize.x2, bgsize.y2, DIV(CalcAreaBpp(0, bg), d)}, +{hlpsize.x1, hlpsize.y1, hlpsize.x2, hlpsize.y2, DIV(CalcAreaBpp(fg, 0), d)} +}; +if (!Area_Both[0].Intersects(Area_Both[1])) { +/* there is no intersection. We can reduce hl */ +Area_Both[1].x1 =
[vdr] [path] vdr-1.6 better spu on ff card
Hi, this patch try to handle case where the osd is limited (for example on ff card). For that it try to split area, count the really needed bpp (all transparent index can be merged together and will with my previous patch in osd.c). Also it fix a bug in the current version : removing all the transparent baground area is ok only if it is recomputed at each draw. Otherwise a highlight request can happen outside the computed area. With this patch I can navigate in dvd menu that produce oeOutOfMemory before. Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [patch] vdr-1.6 merge transparent color
Hi, this patch merge all color that are transparent (alpha = 0) in ClosestColor. This allow to save precious color Index on ff cards. Matthieu --- vdr-1.6.0/osd.c 2007-10-12 14:38:36.0 +0200 +++ vdr-1.6.0p/osd.c 2009-11-21 21:33:09.0 +0100 @@ -141,6 +141,8 @@ int B1 = (Color & 0x00FF); for (int i = 0; i < numColors; i++) { int A2 = (color[i] & 0xFF00) >> 24; + if (A2 == 0 && A1 == 0) + diff = 0; int R2 = (color[i] & 0x00FF) >> 16; int G2 = (color[i] & 0xFF00) >> 8; int B2 = (color[i] & 0x00FF); @@ -149,6 +151,8 @@ d = diff; n = i; } + if (d == 0) + break; } return d <= MaxDiff ? n : -1; } ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No Dolby Digital+ with VDR
Georg Acher wrote: > On Wed, Jun 10, 2009 at 08:48:37PM +0200, ECLiPSE wrote: >> Hi everyone, >> >> since 1st june 2009, the HD Channels broadcasted on DVB-T in France use >> Dolby Digital+ (E-AC-3) instead of classic Dolby Digital (AC-3). >> So now, i can' t have anymore sound on theses channels with the eHD Reel >> card. >> >> I don't know if the problem comes from the hardware part of the eHD or the >> reelbox plugin or VDR. >> I use the VDR 1.7.6 and a quite recent build of the reelbox plugin >> >> Can someone help me with that? >> Thanks in advance > > Since DD+ is supposed to be compatible with DD, it is maybe just a different > audio format type in the PMT. > No sure, but for software decoding with ffmpeg you need a patch to decode DD+ with Spectral extension. Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] rotor and vdr
Goga777 wrote: > Hi > > is there any working solution for moving of rotor with vdr ? > Yes Matthieu PS : I let you search it (hint search in vdr plugin page). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new project - xine-vdpau
Magnus Hörlin wrote: > VDR User wrote: > I'm not sure what deinterlacing is available with vdpau though. But my > suggestion to people looking for new hardware is: buy a mobo with nvidia > 8/9-series IPG and a cheap CPU and start testing. Let's hope Intel start > allowing HDMI on Atom boards soon, that would be ideal. > Or wait for atom Atom boards with ion nvidia chipset [1] Matthieu [1] http://www.anandtech.com/video/showdoc.aspx?i=3478 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
Hi, Seppo Ingalsuo wrote: > Clemens Kirchgatterer wrote: >> vdr in a massive client server configuration is a giant hack with many >> pieces each with its own little problems summing up. >> > > Not giant system, but some experiences: I have one server running three > instances of vdr. Vdr #2 and #3 are connected by streamdev to vdr #1 > that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1. > Three client PCs run just vdr-sxfe as explained in xinelibout's README file. My experience with a vdr#1 on a box with a dvb-s FF and a dvb-t card. And a vdr#2 connected via streamdev. It works, but it's really an hack/mess and lack lot's of features : - on my configuration the recording only work on vdr#1. on vdr#2 svdrp should be used to control recording and ftp to read them (with a video player) - on my configuration some dvb-s and dvb-t channels are the same. If vdr#1 is watching a channel on dvb-s (that is also on dvb-t), but vdr#2 want to use another transponder on dvb-s, the switch should be done by hand. - I have got issue for some channels that are encrypted at some hours and free at other hours - IRRC nothing that stop the master (vdr#1) to powerdown (even if vdr#2 is in use). Nothing that allow vdr#2 to powerdown vdr#1 if nobody watch TV. - no channel sync I wanted to give a try to mythtv (or freevo) but neither of them doesn't seem to support output on FF card. Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.18 subtitles issue
Klaus Schmidinger wrote: > On 09/05/08 16:36, sundararaj reel wrote: >> On Wed, Mar 26, 2008 at 9:55 PM, matthieu castet >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> Next osd behaviour is weird : as soon as subtitle is started, when it >> will refresh it will mess up with other osd. For example if I start >> subtitle and then go to the menu, the menu will be clear by subtitle >> refresh, but I am still in menu mode. >> >> >> Hi all, >> >> Is there a fix for this problem ? I tested with vdr-1.6.0 + softdevice >> plugin. I have the same problem. > > I don't have such problems here on a FF DVB card. > Could it be that the softdevice plugin doesn't handle the OSD levels > correctly? These were introduced in VDR version 1.5.9. > Yes it seems to be a softdevice problem : there a post on the softdevice ML, the developper try something, but it didn't solve the problem. See http://thread.gmane.org/gmane.comp.video.vdr.softdevice/689 Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] lcdproc, utf-8 & VDR
Ville Aakko wrote: > Hi! > > Also, in your opinion, which one in the chain > VDR-lcdproc-LCDd-/dev/lcd0 should be responsible of the conversion of > the character set? I'm asking so I know which programs author should I > point my whine to =) Well it depends of API and what support the hardware. In my opinion doing charset conversion in kernel is not a good thing. Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5.18 subtitles issue
Hi, I tried subtitle features and I saw some problems (I am using vdr-1.5.18 with softdevice and streamdev). First auto channel update is need : there no way to save subtitle pid in channel.conf. I haven't info about this on the manual and it takes me some time how to make it works. Next osd behaviour is weird : as soon as subtitle is started, when it will refresh it will mess up with other osd. For example if I start subtitle and then go to the menu, the menu will be clear by subtitle refresh, but I am still in menu mode. Next, why like audio aren't there an entry in main menu for showing current subtitle tracks ? The only way to know that is to use keymacro with Subtiles key, but that could be hard to map it with remote with few keys. Finally I have the impression that the subtitles synchronisation isn't good. Thanks, Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup On LAN
Bernd Juraschek wrote: Hello, What I've done: - BIOS: Wakeup controlled by BIOS and WOL enabled - Gentoo: echo -n PCI0 > /proc/acpi/wakeup ; halt - Router: wol -h PC-IP-Addr PC-MAC-Addr I use etherwake to send wol packet (it sends ethernet packets, not udp one that doesn't work with my lan card). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Hi, Timothy D. Lenz wrote: The way I understand it, the shows are sent as mpeg2, VDR decodes to raw data and stores as xxx.vdr files Now vdr file are raw data sent by the card : ie mpeg2. Have you an idea of the size of uncompressed video ? Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr