Re: [vdr] Q: Fanless VDR streaming client ?
On 6 Jan 2008, at 21:12, Harald Milz wrote: - what else? The VIA S3 Chrome S27 looks interesting. If the unichrome / openchrome / viaexp can be used to do HW assisted H.264 decoding with this (pci-e) board, see http://www.mythtv.org/wiki/index.php/XvMC#Unichrome , it could be interesting as an easy upgrade similar to the reelbox H. 264 capable card. I think this card already accelerates mpeg2 decoding with the current drivers. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] How To use DeviceStillPicture ?
I have seen that plugins use this in a different way. For example in this order: DevicePlay DeviceStillPicture DeviceFreeze So the next action to display a new Stillimage would start with DevicePlay Others call neither Freeze nor Play. The dvd-Plugin calls DeviceClear and DevicePlay before DeviceStillPicture. I remember that Klaus once stated that DeviceStillPicture could be seen as a trickmode, so that always a Play has to follow to resume from trickmode. But is it necessary to Freeze the Stillpicture before? And I wonder: How should a device plugin handle the StillPicture function? Is it necessary that StillPicture also calls a Clear() to clear the internal decoder buffers? It looks like that vdr is not doing this in dvbdevice.c, although I am not sure if the av7110 ioctl VIDEO_STILLPICTURE does internally clear the buffers. I noticed problems when both plugins (that one that uses DeviceStillPicture and the device plugin) do a Clear() at the same time. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.1 plugin
This doesn't directly concern xine plugin, but maybe anybody can help me. Trying to update xine plugin and got xine-ui compile problem like this: gcc -I/usr/local/include -I/usr/include/readline -I../../src/xitk/xine-toolkit -Wall -D_FILE_OFFSET_BITS=64 -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -I/usr/local/include -DNDEBUG -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute -Wstrict-aliasing=2 -o xine-remote xine_remote-network.o -lnsl -lpthread -lreadline ../../src/common/libcommon.a /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `PC' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetflag' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetent' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `UP' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tputs' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgoto' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetnum' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `BC' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetstr' collect2: ld returned 1 exit status make[4]: *** [xine-remote] Error 1 make[4]: Leaving directory `/usr/local/src/xine-ui/src/xitk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/xine-ui/src/xitk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/xine-ui/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/xine-ui' make: *** [all] Error 2 Please any hint to solve this. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How To use DeviceStillPicture ?
On 01/06/08 14:13, Martin Dauskardt wrote: I have seen that plugins use this in a different way. For example in this order: DevicePlay DeviceStillPicture DeviceFreeze So the next action to display a new Stillimage would start with DevicePlay Others call neither Freeze nor Play. The dvd-Plugin calls DeviceClear and DevicePlay before DeviceStillPicture. I remember that Klaus once stated that DeviceStillPicture could be seen as a trickmode, so that always a Play has to follow to resume from trickmode. But is it necessary to Freeze the Stillpicture before? And I wonder: How should a device plugin handle the StillPicture function? Is it necessary that StillPicture also calls a Clear() to clear the internal decoder buffers? It looks like that vdr is not doing this in dvbdevice.c, although I am not sure if the av7110 ioctl VIDEO_STILLPICTURE does internally clear the buffers. Incidentally I'm currently writing a simple picture viewer plugin, and there I just call DeviceStillPicture() without anything else. In order to make the FF-DVB cards display both frames of a still picture (thus avoiding jagged lines) you may want to apply the following patch to the driver: --- av7110_av.c 2007-12-30 12:59:44.0 +0100 +++ av7110_av.c 2007-12-31 11:19:41.0 +0100 @@ -1125,6 +1125,8 @@ dvb_ringbuffer_flush_spinlock_wakeup(av7110-avout); ret = play_iframe(av7110, pic-iFrame, pic-size, file-f_flags O_NONBLOCK); + if (!ret) + ret = vidcom(av7110, AV_VIDEO_CMD_FREEZE, 1); break; } Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
On Sat, Jan 05, 2008 at 06:53:48PM +0100, Reinhard Nissl wrote:
Hello,
with the last patch, VDR refuse to tune to any DVB-S2 channels.
I guess that VDR thinks all my card are only DVB-S ones.
I get Channel not available! on all DVB-S2 channels.
Any maybe not directly interesting, but with this patch, graphlcd
make vdr segault at start.
Thanks,
The attached version implements this behavior now. You may want
to experiment a bit with the decision logic as explained below.
The decision is based on the number of modulation systems a card
provides. For example, my NOVA-S provides one (DVB-S) and my
SkyStar HD provides three (DVB-S, DVB-DSS, DVB-S2).
The decision logic is implemented in cDevice::GetDevice(), so
have a look into device.c. After applying the patch, you'll find
two lines in that function marked with comments like /*1*/ and
/*2*/, and the latter one was disabled by a line comment.
In my scenario with just the above cards and vdr-xine as software
device, watching a channel requires VDR to operate in transfer
mode. Therefore it selects a device which provides for example a
DVB-S channel. The patched version will choose the NOVA-S with
either implementation /*1*/ or /*2*/.
Let's then start a DVB-S recording on a different transponder.
When implementation /*2*/ would be active, VDR would choose the
SkyStar HD, as the NOVA-S is claimed by transfer mode. Then, try
to switch to a DVB-S2 channel. It wouldn't work, as the SkyStar
HD would be claimed by a DVB-S recording.
That's why I've chosen implementation /*1*/ as default. For the
above scenario, starting a DVB-S recording on a different
transponder will choose the NOVA-S and kick off transfer mode.
Then VDR will look for a card to set up transfer mode again and
it will choose the only remaining card, the SkyStar HD. If you
then try to switch to a DVB-S2 channel, it will work as the
SkyStar HD is not claimed by a recording.
The patch is incremental to the original dvbs2 patch from
yesterday, i. e. you can simply apply it to your already patched VDR.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.12-dvbs2-other/device.c2008-01-01 22:55:18.0
+0100
+++ device.c 2008-01-05 18:06:15.0 +0100
@@ -359,6 +359,21 @@ cDevice *cDevice::GetDevice(int Index)
return (0 = Index Index numDevices) ? device[Index] : NULL;
}
+inline int GetClippedModulationSystemCount(int AvailableBits, cDevice
*Device)
+{
+ int ModulationSystemCount = Device-ModulationSystemCount();
+ int MaxModulationSystemCount = 1 AvailableBits;
+ if (ModulationSystemCount MaxModulationSystemCount) {
+ esyslog(ERROR: device %d supports %d modulation systems but
cDevice::GetDevice() currently only supports %d modulation systems which
should be fixed, Device-CardIndex() + 1, ModulationSystemCount,
MaxModulationSystemCount);
+ ModulationSystemCount = MaxModulationSystemCount;
+ }
+ else if (ModulationSystemCount = 0) {
+ esyslog(ERROR: device %d reported an invalid number (%d) of supported
modulation systems. The device should be fixed to return at least 1,
Device-CardIndex() + 1, ModulationSystemCount);
+ ModulationSystemCount = 1;
+ }
+ return ModulationSystemCount;
+}
+
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool
LiveView)
{
// Collect the current priorities of all CAM slots that can decrypt the
channel:
@@ -408,11 +423,13 @@ cDevice *cDevice::GetDevice(const cChann
imp = 1; imp |= LiveView ? !device[i]-IsPrimaryDevice() ||
ndr : 0; // prefer the primary device for
live viewing if we don't need to detach existing receivers
imp = 1; imp |= !device[i]-Receiving() (device[i] !=
cTransferControl::ReceiverDevice() || device[i]-IsPrimaryDevice()) || ndr;
// use receiving devices if we don't need to detach existing receivers, but
avoid primary device in local transfer mode
imp = 1; imp |= device[i]-Receiving();
// avoid devices that are receiving
+/*1*/imp = 2; imp |= GetClippedModulationSystemCount(2, device[i])
- 1;// avoid cards which support multiple
modulation systems
imp = 1; imp |= device[i] ==
cTransferControl::ReceiverDevice(); //
avoid the Transfer Mode receiver device
imp = 8; imp |= min(max(device[i]-Priority() + MAXPRIORITY,
0), 0xFF); // use the device with the lowest
priority (+MAXPRIORITY to assure that values -99..99 can be used)
imp = 8; imp |= min(max((NumUsableSlots ? SlotPriority[j] :
0) + MAXPRIORITY, 0), 0xFF); // use the CAM slot with the lowest
priority (+MAXPRIORITY to assure that values -99..99 can be used)
imp
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Hi, Gregoire Favre schrieb: with the last patch, VDR refuse to tune to any DVB-S2 channels. I guess that VDR thinks all my card are only DVB-S ones. I get Channel not available! on all DVB-S2 channels. Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems. Any maybe not directly interesting, but with this patch, graphlcd make vdr segault at start. Did you recompile all plugins as a virtual function had been added? Please provide a backtrace otherwise. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
Hi,
Reinhard Nissl schrieb:
The patches now include my recently released speedup patches as
well as an unreleased speedup patch for cAudioRepacker and
cVideoRepacker, because at least the latter one would have been
hard to extract separately.
cAudioRepacker speedup patch contains a typo. Please apply the
attached fix.
The optimized DrawRectangle() will crash when called with
incorrect coordinates, i. e. x1 x2 or y1 y2.
More generally such issues should be handled in Intersects() and
Covers(). The attached patch adds sanity checks to them.
Thanks to Claus Meder for reporting this issue.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.12-dvbs2-other/osd.c 2008-01-01 22:55:18.0 +0100
+++ osd.c 2008-01-06 22:39:33.0 +0100
@@ -217,6 +217,8 @@ bool cBitmap::Contains(int x, int y) con
bool cBitmap::Covers(int x1, int y1, int x2, int y2) const
{
+ if (x1 x2 || y1 y2) // sanity check
+ return false;
x1 -= x0;
y1 -= y0;
x2 -= x0;
@@ -226,6 +228,8 @@ bool cBitmap::Covers(int x1, int y1, int
bool cBitmap::Intersects(int x1, int y1, int x2, int y2) const
{
+ if (x1 x2 || y1 y2) // sanity check
+ return false;
x1 -= x0;
y1 -= y0;
x2 -= x0;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
On Sun, Jan 06, 2008 at 09:34:32PM +0100, Reinhard Nissl wrote: Hi, Hello :-) Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems. I'll do tomorrow ;-) Any maybe not directly interesting, but with this patch, graphlcd make vdr segault at start. Did you recompile all plugins as a virtual function had been added? Please provide a backtrace otherwise. The two fix solve it :-) (not the non tunable DVB-S2). Thanks, -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ERROR: can't set PID xxxx on device y
Hi, since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log: Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9 PID 2027 is for a finnish subtitles stream. I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him. Here is a longer snippet of the log around that time: Jan 6 23:00:36 vdr vdr: [7319] subtitleConverter thread started (pid=4506, tid=7319) Jan 6 23:02:31 vdr vdr: [4513] channel 1 (TV1) event Su 06.01.2008 23:05-23:28 'Ponille kyytiä' status 4 Jan 6 23:02:47 vdr vdr: [4513] changing pids of channel 2 from 513+513:660=fin:2027=fin,2028=dut:2321 to 513+513:660=fin:2027=fin:2321 Jan 6 23:02:47 vdr vdr: [4506] retuning due to modification of channel 2 Jan 6 23:02:47 vdr vdr: [4506] switching to channel 2 Jan 6 23:02:47 vdr vdr: [7257] transfer thread ended (pid=4506, tid=7257) Jan 6 23:02:47 vdr vdr: [7319] subtitleConverter thread ended (pid=4506, tid=7319) Jan 6 23:02:47 vdr vdr: [4506] buffer stats: 110920 (5%) used Jan 6 23:02:48 vdr vdr: [4506] buffer stats: 0 (0%) used Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9 Jan 6 23:02:48 vdr vdr: [7340] transfer thread started (pid=4506, tid=7340) Jan 6 23:02:49 vdr vdr: [4506] buffer stats: 0 (0%) used -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: can't set PID xxxx on device y
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting
this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just
thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like
SetCurrentSubtitleTrack() calls AttachReceiver() on the
PrimaryDevice() which is cXineDevice in my case.
(gdb) bt
#0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther)
at device.c:612
#1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8,
Receiver=0xb44e2078) at device.c:1502
#2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8,
Type=ttSubtitle, Manual=false) at device.c:1052
#3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at
device.c:1104
#4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8,
Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 deu, Description=0x0)
at device.c:984
#5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8,
LiveView=true) at device.c:845
#6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8,
LiveView=true) at device.c:735
#7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at
channels.c:1201
#8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a
cLiveSubtitle instance is created although none is needed in
transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone !Replaying()
!Transferring()) {
1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack);
1050 if (TrackId TrackId-id) {
1051liveSubtitle = new cLiveSubtitle(TrackId-id);
1052AttachReceiver(liveSubtitle);
1053}
1054 }
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Q: Fanless VDR streaming client ?
What fanless solution are you using? I have an EPIA SP-13000G motherboard in a Serener GA-L01, all fanless and no moving parts apart from a 120G 2.5 laptop drive. The thing runs too hot though - even with the 5% cpu mp3-plugin, the cooling fins get quite hot. I have a TT-2300-C with CAM/CI. Picture quality is good (MPEG2 only though) - Original Message - From: Harald Milz [EMAIL PROTECTED] To: VDR Mailing List vdr@linuxtv.org Sent: Monday, January 07, 2008 12:12 AM Subject: [vdr] Q: Fanless VDR streaming client ? Hi, my current VDR works fine with 3 Sat cards and a fanless case so far - but the case is quite bulky, and since I'm going to move to a new home shortly, I am looking for a nice fanless streaming solution. Xine-plugin works fine so far, and I can use Reinhard's patched xine player on my laptop nicely. The best part of this solution is that you get a completely remote box including OSD and recording playback (albeit without burning DVDs or something on the client but so be it). My new solution should be able to handle to following requirements: - decode 1080p / H.264 (just in case this becomes widely available in the future...). - DVI or HDMI out up to 1080p - S/PDIF out incl. AC3 passthrough. - display the VDR server's OSD as if it were local - control the VDR server with an IR remote (via LIRC or whatever). (aside: a 100 mbit network should be able to handle a HDTV stream - right?) I see several options so far: - re-use my old AMD64 3200+ (2 GHz single core S939), Asus A8V (full size ATX w/ AGP) and a fanless Nvidia card in a new HTPC case with a heatpipe cooler. Nice for the moment but unlikely to be able to handle HDTV decoding. Or is it? (such cases aren't exactly cheap ...). Since ffmpeg isn't multithreading capable yet (last time I looked), a dual-core CPU makes little sense. Needs a full size case anyway due to the AGP card (low-profile passive cooled AGP card anyone?). Bulky. - build a new streaming client with a Via Epia EX board (CX700M2 w/ MPEG4 decoding support). At the moment the viaexp driver is required (unichrome and openchrome don't seem to cut it), and one needs the Via patched xine that AFAIK does not support netvdr:/ MRLs. Has anyone tried to patch the Via xine to do that? Is it stable? Is the fanless 1 GHz CPU sufficient for HD decoding, or is the fan-cooled 1.5 GHz CPU required? - same board running Windows XP (yuck) and a Windows player. Which windows player will handle the OSD correctly (or rather: which VDR plugin does it talk to that sends the OSD correctly, like xine-plugin) and use the MPEG4 hardware decoder? Vlc? - µATX board like Abit AN-M2 w/ AMD64 BE-2350 CPU (as for dual-core see above but these CPUs are quite efficient) and a µATX heatpipe case (which one)? Little MPEG4 hardware support. - standalone HDTV multimedia player. There are several players built around a Sigma EM8620/21/22 chip but which one will handle a http or vtp stream? Streamdev-server or ffnetdev or xine-plugin or xineliboutput? - what else? what are you using? -- Nihilism should commence with oneself. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
