Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
On 24 Nov 2008, at 19:37, Nicolas Huillard wrote: Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB- card(s)) use power? No use of PCI in the client. Do you put the DVB cards in the server? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Converting H264 vdr 1.7.0 recordings to xvid (or x264) inavi container
I've got the same error than getting it from streamdev in ts format (with wget) and trying to read it with mplayer, the fps is not found but not a problem at all Playing bbc.ts. TS file format detected. VIDEO H264(pid=256) NO AUDIO! NO SUBS (yet)! PROGRAM N. 1 FPS not specified in the header or invalid, use the -fps option. No stream found. This has been addresses on another thread with playback to Popcorn Hour 'set-top box' device. Patches are already developed and tested. For quick fix please see: http://www.vdr-developer.org/mantisbt/view.php?id=496 and apply patch #5. As TS stream gets more standardized and some other minor changes happened, the stream is also more compatible with Mplayer. Now mplayer recognizes the stream better. Best regards, Jori smime.p7s Description: S/MIME cryptographic signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? Asrock A780FullDisplay without DisplayPort card AMD Athlon X4 3850e 2GB DDR2-800 DVD/RW 300W 80+ Green 1x Momentus 7200.3 250GB 2,5 3x WD Caviar Green 1TB 3,5 Terratec Diversity (Dual Tuner) USB DVB-T 2x extra Fans While recording two DVB-T channels ~ 60W (UPS tells it). The WD drives build up a RAID5. The A780 chipset is nice for low-power needs. Yes, I have AMD 780G also in my vdr server and in clients I am currently using the vdr-xineliboutput. What I have now tried to search for is a fast booting client for my old P700, that could boot automatically to X with dummy user and then launch the vdr-xineliboutput. The ideal would be that once bios checks have been done, rest of the boot would for getting X and vdr client running would take less than 30 seconds from the bios checking, but currently I am very far from that and I am not sure what would be the best option for the client. 1) local harddisk for booting and launching X and vdr-sxfe 2) nfs mount from server for booting and launching X and vdr-sxfe 3) local harddisk booting X and connecting to server with XDMCP. (would video and audio work over XDMCP from server?) 4) lpts5 where some apps would be run from server, while multimedia like vdr-sxfe would be run from client harddisk What kind of solutions what boottimes you have for the clients? Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Windows remote client
If you want to play H264 and/or HD content, this is not a good solution and you cannot consider use a light client to do that There is a good solution but it needs work. Popcorn Hour (and compatible) networked media tanks can replay SD/HD content, on there has been work ongoing to fix vdr-streamdev to provide proper TS-stream. PCH is light client, some people has measured 12W power on HDD spun up and playing stream. PCH is a Linux based settop-box where you can get access to shell level and even crosscompile programs with toolchains. Box is about 27x13x3cm. HDD is optional but you should install it for best benefit. (http://www.popcornhour.com/onlinestore/index.php?pluginoption=catalogtask= infoitem_id=6main_id=0) What is needed is Vomp-like or VDRadmin-am-like user interface for streams and files. It would make PCH as a top alternative of todays front-end for VDR, and in general a front end to all media you have. For GB-PVR there is already some work done. http://gbpvr.com/pmwiki/pmwiki.php/Hardware/NMT With this device you can discard HTPC's at once unless you do web browsing with your TV-set. smime.p7s Description: S/MIME cryptographic signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Converting H264 vdr 1.7.0 recordings to xvid (or x264) inavi container
Hi I have just applied patch #5, some reject so I have to enter manually lines No major change on mplayer, still have to enter the -fps to let play it but on popcorn it is night and day, now I can stream to popcorn all my HD channels and all is working nice, some desentrelacing problem on SD channels but was not the first goal Very good job by the way for the author ;o) have a nice day Selon [EMAIL PROTECTED]: I've got the same error than getting it from streamdev in ts format (with wget) and trying to read it with mplayer, the fps is not found but not a problem at all Playing bbc.ts. TS file format detected. VIDEO H264(pid=256) NO AUDIO! NO SUBS (yet)! PROGRAM N. 1 FPS not specified in the header or invalid, use the -fps option. No stream found. This has been addresses on another thread with playback to Popcorn Hour 'set-top box' device. Patches are already developed and tested. For quick fix please see: http://www.vdr-developer.org/mantisbt/view.php?id=496 and apply patch #5. As TS stream gets more standardized and some other minor changes happened, the stream is also more compatible with Mplayer. Now mplayer recognizes the stream better. Best regards, Jori ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput crashes when closing the xineliboutput/videomenu
I demand that Nicolas Huillard may or may not have written... [snip] vdr 1.6.0 xineliboutput 1.0.3 xine 1.1.2 Maybe you should upgrade to 1.1.15. :-) all Debian etch + e-tobi repository [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Lobby friends, family, business, government.WE'RE KILLING THE PLANET. I fear explanations explanatory of things explained. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
Torgeir Veimo a écrit : On 24 Nov 2008, at 19:37, Nicolas Huillard wrote: Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB- card(s)) use power? No use of PCI in the client. Do you put the DVB cards in the server? The temporary current setup is weird : * server only handles NFS root FS and NFS /video share * 1 client have a PCI DVB-S card, and an USB DVB-T card, with streamdev-server * another client have a PCI DVB-T card, with streamdev-server * the most recent client have no DVB device Every DVB device will move to the server, requiring a bit of antennae rewiring. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
On Mon, 24 Nov 2008 11:58:22 +0100 Holger Rusch [EMAIL PROTECTED] wrote: The A780 chipset is nice for low-power needs. That's not what I found. I tried to install an Asus MA738EMH last week and had to give up in the end and replace it with a similar board with NVidia 8200 graphics (that choice based on the VDPAU announcement), MN738VM. Xorg's radeonhd driver (I used their latest release version, which is in debian experimental) didn't enable even basic Xv acceleration for the 3200 graphics, so the Athlon X2 4850e CPU I used could barely manage 720p. Fglrx was OK with MPlayer but Xv didn't work at all with xine and with OpenGL it caused unrecoverable screen garbling when switching from full-screen to windowed mode. The whole system would regularly crash when not doing anything too, and I think that even happened once or twice with the radeonhd driver. The new board has worked flawlessly from day one and I expect VDPAU will be nice and stable and well supported by the time I really need it (for 1080p), whereas it's hard to imagine the ATI ever getting usable acceleration even for H.264. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
Mika Laitio a écrit : What I have now tried to search for is a fast booting client for my old P700, that could boot automatically to X with dummy user and then launch the vdr-xineliboutput. The ideal would be that once bios checks have been done, rest of the boot would for getting X and vdr client running would take less than 30 seconds from the bios checking, but currently I am very far from that and I am not sure what would be the best option for the client. 1) local harddisk for booting and launching X and vdr-sxfe 2) nfs mount from server for booting and launching X and vdr-sxfe 3) local harddisk booting X and connecting to server with XDMCP. (would video and audio work over XDMCP from server?) 4) lpts5 where some apps would be run from server, while multimedia like vdr-sxfe would be run from client harddisk What kind of solutions what boottimes you have for the clients? From kernel first log line in the syslog server (I guess timestamps are when rcS.d/ scripts start to run, ie. does not include kernel load time + initrd), to LIRC accepting the VDR client (including a 5s sleep I had to add): * 31s on the ML6000 * 16s on a Athlon 2200+ * 18s on the M10k That's with a single NFS root filesystem and network boot (no local storage). It does not include kernel + initrd load time over the network, BIOS time, etc. It also does not include specific imrpovement, except not install unneeded things. The best timing would be from power-on to live-TV on the display. BIOS + PXE (network boot) are ugly in this regard... Initrd is also time-consuming. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput crashes when closing the xineliboutput/videomenu
Darren Salt a écrit : I demand that Nicolas Huillard may or may not have written... [snip] vdr 1.6.0 xineliboutput 1.0.3 xine 1.1.2 Maybe you should upgrade to 1.1.15. :-) all Debian etch + e-tobi repository Well... I think I'll have a step at 1.1.14, when e-tobi.net is ready for lenny, then ;-) Maybe xserver-xorg-video-openchrome will also solve issues left in xserver-xorg-video-via too... Do you (Darren) still maintain an up-to-date repository with Xorg and VDR, Xine, etc? I remember using it when playing with CLE266 hardware acceleration, a long time ago. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.1 video stream format
On Mon, 24 Nov 2008 14:41:44 +0100, Stefan Lucke wrote
- dumping the data I got via PlayVideo() to a file neither ffplay nor
mplayer can identify stream info from dumped data.
Unless I've overlooked some section repacker somewhere, there's a bug in
cPatPmtGenerator. I've already sent the attached patch to Klaus, but he didn't
have time to look at it yet.
Frank
--- remux.c.orig 2008-11-13 13:39:48.0 +0100
+++ remux.c 2008-11-13 16:32:57.0 +0100
@@ -2298,6 +2298,7 @@
p[i++] = 0x40; // flags (3), pid hi (5)
p[i++] = 0x00; // pid lo
p[i++] = 0x10; // flags (4), continuity counter (4)
+ p[i++] = 0x00; // pointer field (payload unit start indicator is set)
int PayloadStart = i;
p[i++] = 0x00; // table id
p[i++] = 0xB0; // section syntax indicator (1), dummy (3), section length hi (4)
@@ -2367,13 +2368,18 @@
MakeCRC(buf + i, buf, i);
// split the PMT section into several TS packets:
uchar *q = buf;
+ bool pusi = true;
while (i 0) {
uchar *p = pmt[numPmtPackets++];
int j = 0;
p[j++] = 0x47; // TS indicator
- p[j++] = 0x40 | (P_PNR 8); // flags (3), pid hi (5)
+ p[j++] = (pusi ? 0x40 : 0) | (P_PNR 8); // flags (3), pid hi (5)
p[j++] = P_PNR 0xFF; // pid lo
p[j++] = 0x10; // flags (4), continuity counter (4)
+ if (pusi) {
+ p[j++] = 0x00; // pointer field (payload unit start indicator is set)
+ pusi = false;
+ }
int l = TS_SIZE - j;
memcpy(p + j, q, l);
q += l;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Video Decode and Presentation API from NVidia
On Mon, Nov 24, 2008 at 4:53 AM, Nicolas Huillard [EMAIL PROTECTED] wrote: It seems that things are really moving, and VDR-HD may finally work with cheap hardware by the time HD material is commonplace. You must live under a rock if HD content isn't already common where you live/from your provider! Here is NA there's tons of HD channels, with many more coming soon. Also, building a HD-capable pc is already cheap. You don't need some expensive cpu with GB's of ram and so on. My test box (which uses the on-board gpu) does HD and was only cpu-$40 + ram-$25 + mainboard-$65. cpu is amd x2 4400, corsair 2x1GB stick ram kit, mainboard is msi k9n6sgm-v. $130 USD and I had a new dvb test box that does HDTV. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.1 video stream format
On Monday 24 November 2008, Frank Schmirler wrote: On Mon, 24 Nov 2008 14:41:44 +0100, Stefan Lucke wrote - dumping the data I got via PlayVideo() to a file neither ffplay nor mplayer can identify stream info from dumped data. Unless I've overlooked some section repacker somewhere, there's a bug in cPatPmtGenerator. I've already sent the attached patch to Klaus, but he didn't have time to look at it yet. Thanks, but things went worse with that on my system: audio disappeared and nothing more to dump in PlayVideo() :-( . -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Video Decode and Presentation API from NVidia
On Mon, Nov 24, 2008 at 8:05 AM, Niels Wagenaar [EMAIL PROTECTED] wrote: Only, in the US most of the HDTV transports don't use H264. At least, I heard from several people that it's HDTV through MPEG2. Over here (Europe) it's mostly HDTV through H264 (only a very small number of MPEG2 HDTV channels over here). You've been given bad information. There are _some_ HDTV channels broadcast in mpeg2 but most are h264. Currently I need to use a Core 2 Quad (Q6600 @ 2.40GHz) to get decent and stutter-free H264 decoding using software (FFMpeg SVN, Xine-lib 1.2, Xine-UI and vdr-xine plugin). With my Core 2 Duo (E7300 @ 2.53Ghz) I didn't had enough juice (stuttering, framedrops, etc). You absolutely do not need a quad-core CPU and your Core 2 Duo should easily handle h264 decoding. I'd say something was misconfigured or so. Btw, I use CoreAVC here and the cpu usage doesn't go above about 87% on that x2 4400. The h264 implimentation in ffmpeg was very unstable when I tried it although I heard it's gotten much better. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Video Decode and Presentation API from NVidia
Hi, On Mon, Nov 24, 2008 at 08:43:14AM -0800, VDR User wrote: On Mon, Nov 24, 2008 at 8:05 AM, Niels Wagenaar [EMAIL PROTECTED] wrote: Only, in the US most of the HDTV transports don't use H264. At least, I heard from several people that it's HDTV through MPEG2. Over here (Europe) it's mostly HDTV through H264 (only a very small number of MPEG2 HDTV channels over here). You've been given bad information. There are _some_ HDTV channels broadcast in mpeg2 but most are h264. Currently I need to use a Core 2 Quad (Q6600 @ 2.40GHz) to get decent and stutter-free H264 decoding using software (FFMpeg SVN, Xine-lib 1.2, Xine-UI and vdr-xine plugin). With my Core 2 Duo (E7300 @ 2.53Ghz) I didn't had enough juice (stuttering, framedrops, etc). You absolutely do not need a quad-core CPU and your Core 2 Duo should easily handle h264 decoding. I'd say something was misconfigured or so. Btw, I use CoreAVC here and the cpu usage doesn't go above about 87% on that x2 4400. The h264 implimentation in ffmpeg was very unstable when I tried it although I heard it's gotten much better. And what resolution? 720p ? I have no problems in decoding 720p, but 1080i is a bit more difficult to decode. I have also tried out CoreAVC, but ffmpeg worked better for me. Regards, Artem ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where is the H.264 patch?
On Fri, 21 Nov 2008 11:49:23 +0100 jlacvdr [EMAIL PROTECTED] wrote: to vdr-1.7.0, in attach file of this message : http://www.linuxtv.org/pipermail/vdr/2008-April/016513.html Is there a patch that will work with 1.6.0? It'll make things rather easier if I can just patch the debian packages instead of completely replacing them. If I do have to use 1.7.x does this patch still work with 1.7.1 ie it's safe to ignore the failed hunk in transfer.c which has apparently changed radically? -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
Alex Betis a écrit : On Mon, Nov 24, 2008 at 3:24 PM, Nicolas Huillard [EMAIL PROTECTED]wrote: From kernel first log line in the syslog server (I guess timestamps are when rcS.d/ scripts start to run, ie. does not include kernel load time + initrd), to LIRC accepting the VDR client (including a 5s sleep I had to add): * 31s on the ML6000 * 16s on a Athlon 2200+ * 18s on the M10k Guys, How about putting the system in suspend mode instead of powering it off and on again? Should take few seconds. Some of you were talking about UPS, so its even safer than I can have... VDR can resume from suspend to record programs. I'll try that ;-) Suspend to RAM as always been a pain in my various trials, but this is a much simpler goal than a complete laptop. Virtually no device to take down/bring up on a pure streamdev client. NFS handles must just survive the long delay, but it should be OK. This also works around an annoying bug in the (non-upgraded) EPIA BIOS: the PXE LAN boot does not always initialize the network interface after a shutdown. One have to unplug power to boot correctly next time... -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where is the H.264 patch?
On Mon, Nov 24, 2008 at 9:44 PM, Tony Houghton [EMAIL PROTECTED] wrote: On Fri, 21 Nov 2008 11:49:23 +0100 jlacvdr [EMAIL PROTECTED] wrote: to vdr-1.7.0, in attach file of this message : http://www.linuxtv.org/pipermail/vdr/2008-April/016513.html Is there a patch that will work with 1.6.0? It'll make things rather easier if I can just patch the debian packages instead of completely replacing them. http://www.linuxtv.org/pipermail/vdr/2008-March/016227.html -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
