Re: [vdr] [ANNOUNCE] VDR successfully ported to Windows
On Sat, May 19, 2012 at 12:30:43AM +0300, WinVDR wrote: To solve that problem we need to modify these functions and avoid using file descriptors: int cDevice::OpenFilter(u_short Pid, u_char Tid, u_char Mask); void cDevice::CloseFilter(int Handle); Does any body have suggestions about the best way to implement this. We had the same problem with NetCeiver-plugin (full DVB-device emulation over network). Everything is vdr is nicely abtracted and then there are suddenly file handles instead of get-functions :-( We've solved this issue by using pipes (Unix-sockets). This probably works also on Windows... You can have a look in filter.c of https://svn.baycom.de/repos/vdr-mcli-plugin/ -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb devices on demand patch
On Sun, Dec 05, 2010 at 01:58:42AM +0100, Steffen Barszus wrote: To make it short I see use cases for it - i just can not manage to do it myself - so i thought i share my thoughts, by chance someone interested is reading it. Have a look at the mcli-plugin and the few patches for vdr it needs. It is already doing everything you are describing, as we needed that for the NetCeiver-streaming for multiple clients. Namely: a) Providing virtual tuners to allow arbitrary hotplugging (tuner types and sat positions) and even changing tuner properties on-demand. b) Disabling unused tuners, however this is hard in general as there's no hard information on the PID usage type available. But be warned, hotplugging has some pitfalls ;) So the resource allocation checks for a point of time in the future (like timer collisions) are no longer useful. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Thu, Oct 14, 2010 at 02:48:51PM +0300, Vesa wrote: The root cause is still there, somehow eHD delivers around 50 too low STC for recording play. For live shows STC value is correct.. I'll need to have a closer look, but it sounds possible, that the pts is the pts of the last packet put into the video decoder queue and not the latest value of the currently shown frame... That would explain the time lag, the ES queue of the decoder is about 3MB or so. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB (usb) device hotswapping?
On Sun, Apr 04, 2010 at 10:54:02AM +0200, Udo Richter wrote: How did you solve the case that a device disappears while being used? If this happens for a recording, then VDR would terminate with a VDSB, or? Do you silently switch the device to another resource? As long as the device is used by vdr with a successful Provides() at the beginning, it cannot disappear, even if the real device behind it is gone. However, the vdr-device will get a no-lock after 10s and femon sees no longer a type and description after one minute. That also triggers the VDSB message, but recording goes on if the resource re-appears, as the vdr-device is not shutdown. Since the tuner behind it is already virtualized, it will be immediately attached again to the dangling dvbdevice if something matching appears, e.g. when the network gets reconnected. This is due to the fact that the tuning parameters are included in the MLDv2-messages the mcli-plugin will resend every few seconds for an open device. The streaming starts again when an appropriate server gets these messages. In principle it is possible to switch to another resource, but the current firmware supports no distributed sources (=satellite positions) over different NetCeivers, they need to be exclusive. We have already a peer-to-peer-like firmware that supports distributed resources and would allow redundant NetCeivers, but it still needs some CPU optimizations for the slow CPU on the NetCeiver... However, internally in one NetCeiver an expensive resource (like a rotor or a S2-tuner that were used because no other tuners were free at that time) is automatically switched back to a cheaper resource if possible. This is almost invisible from the outside... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB (usb) device hotswapping?
On Sun, Apr 04, 2010 at 12:35:04AM +0200, Udo Richter wrote: Am 03.04.2010 21:17, schrieb Teemu Rantanen: now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported? VDR is far from being able to hot-swap. This is true, but there is a workaround for that. It involves one indirection in the device handling by a plugin. During the development of the mcli-plugin for the NetCeiver the same issue appeared. The networked tuners are already virtualized, they get visible a few seconds after the plugin start and may also disappear or change their type. So hotplugging support was a must. It is now solved by the mcli plugin by allocating all (16) devices at startup. When the various Provides*-methods are called for tuning, the plugin searches in its internal resource database for an appropriate tuner and assigns it to the vdr-device. If there is no appropriate tuner for the request the Provides-methods return simply false, so the device is skipped. That is virtualizing of already virtual tuners :-O This means also that every tuner has initially no type like DVB-S/C/T. The type is allocated on demand during tuning and reset when the device has no active PIDs (for short, actually it's a bit more complicated since there is no reliable resource usage tracking in vdr...). -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new support
On Fri, Jan 22, 2010 at 09:25:07AM -0500, abbe normal wrote: hello guys lars that looks like a nice setup that real media has didnt even know that was around... There's a more detailed description of the system here: http://www.baycom.de/~acher/netceiver/netceiver_white_paper.pdf -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No Dolby Digital+ with VDR
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. Can you run dvbsnoop on that channel? -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Tue, Jun 09, 2009 at 11:44:29AM +0200, Mattia Rossi wrote: Hi Georg, sorry if that came out as 'they are hiding something', I was really thinking more in terms of 'there are so many variables that the best combination is probably achieved in an environment where the user has much less control as we have in a custom vdr compiled environment, without even taking into account the endless combinations of display devices that people will want to connect to the eHd' That said, I really really would like a different option than 'don't use the scaler on the eHd-HDMI output, it's crap', is there a way to change the scaling algorithm it uses ? Is there any other setting we can work on regarding the eHd outputs, even if they are not listed in the reelbox-3 setup ? Not really. You can either use upscaling without deinterlacing (and get tearing for real interlaced moving signals) or use the chips deinterlacer. That is effectively independent scaling of both fields, so the field order is correct, but fine details show horizontal ghost lines as the interpolation doesn't know anything about the full context. It depends a bit on the display how visible these lines can be seen, some displays seem to have their own filtering and hide them better. There is a third possibility that is currently not settable: Blending. That mixes both fields together. So still pictures are sharp and movements are only blurred and not teared. I can enable it in a experimental linux.bin. BTW: We chose the DeCypher despite a real deinterlacer was missing at the time, because we were told that it will be enabled later. The rest is history... For example, I am using the coax digital output on the eHd mini-din, instead of the pass through HDMI (the HDMI cable goes straight to the VPR, the coax cable goes to my main amp), I had to change a couple of lines in the reelbox-3 plugin in order to allow for AC3 to pass through the digital output. The option was there, it just wasn't compiled in because of REELBOXLITE ifdefs That was because the MiniPCI-Card for the Lite used a DeCypher-revision with a dead SPDIF-port. So we need to feed the AC3 SPDIF output over the main sound card. The AVG-card has a working SPDIF, so the mainboard sound is used only for PCM (if enabled). What I would like to achieve is decent quality (either scaled or unscaled) SD MPEG-2 output, and by decent I mean at least at the same quality of the MPEG-2 output of a FF card without having to use a 2Keuro deinterlacer. Please note that I'm talking about MPEG processing quality, not still image quality You can output 576i over HDMI and let the display do the deinterlacing. But there is a dependency with the analog output that allows only 576p when the analog port should emit 576i (CVBS etc.). For 576i over HDMI you need to switch the analog port completely off. I understand that this is not easy to fine tune because of all the different variables and because of all the 'not straightforward' test environments every single vdr user will have set up. At the moment my vdr 1.7.x install is really basic (vdr, extensions patch, reelbox3 filebrowser xinemediaplayer and menuorg plugins) and I am completely satisfied by the stability (both of vdr and of the eHd) , I even don't notice the problems with the recordings handling (the single frame forward in a recording isn't really working, it looks like it is skipping from i-frame to i-frame (doesnt'do that when going backwards, it is the opposite behaviour as with the ff card, where forward skipping works, while backward skipping goes from i_frame to i-frame ..) I guess the vdr 1.7 has it's own intelligence about frame-precise playback for TS that doesn't match the requirements of the plugin... It took us quite a while to make it work almost as responsive as on the FF, maybe there are some dependencies with our old 1.4. But up to now, I had no time to try 1.7... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Mon, Jun 08, 2009 at 09:40:04PM +0200, Mattia Rossi wrote: The need for time in such a discovery process, at least on my part, is fully understood, I only wish that sometimes the guys from Reel would provide a little more documentation (in english) about how they do some things in the avantgarde, but this is probably what is actually giving the avantgarde the edge over a normal vdr install, so I won't complain. Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Mon, Jun 08, 2009 at 09:09:06PM +0100, Morfsta wrote: On Mon, Jun 8, 2009 at 8:54 PM, Georg Acherac...@in.tum.de wrote: Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest... Great! Georg, can you let us know why FF/FR and pause/play handling within VDR with reelbox-3 is so laggy? It makes jumping, searching and seeking within VDR almost unusable. Ouch, I expected more technical questions ;-) At least for the reelvdr-base, I don't see any special handling for these cases. All the dirty stuff is done in the plugin and and on the DeCypher-side... Is there anything we can do to fix this? Send me a full patched vdr-package that shows this behavior... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Fri, Jun 05, 2009 at 11:40:44PM +0300, Vesa wrote: But with suitable devices I can feed 576i HDMI to it and it works. Normal BD player and eHD refuses to send 576i to it and end result is 576P even that source is in 576i mode by ui. You need to disable the analog output to get 576i over HDMI. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 06:28:36PM +1000, Torgeir Veimo wrote: http://www.reel-multimedia.com/en/shop_netclient.php describes a new product by reel that allows streaming of HD content over the network. It includes a hw decoder that supports mpeg2/4 and is to be used with the reelbox avantgarde as server. I'd assume reel has implemented something a bit more sophisticated than streamdev for this, but given the open source nature of their products, I'm wondering if someone has tried looking into using this client with pure VDR? The thing is not yet available, so the current SVN doesn't contain most of the new code. But in general it uses the same reelvdr-base as the Avantgarde (just with a different output plugin for the SoC). The live TV streaming is not done by the vdr on the Avantgarde, but directly via IPv6-multicast by the NetCeiver-hardware. This is the same way the Avantgarde gets its data, so the NetCeiver traffic is just bridged into the LAN for other clients. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 11:54:14PM +1000, Torgeir Veimo wrote: So it does not allow viewing of channels received as DVB-C/S/T on the avantgarde, or such recordings, only IPTV transmissions? The NetCeiver IS a DVB-S/C/T headend to IPTV. So the tuners the Avantgarde-vdr uses are already sourced by that way, a new client makes no difference. The PC mainboard and the NetCeiver in the AVG just happen to be in the same casing and share the same power supply. Beyond that they are totally seperated devices. The tuner data is delivered by a loop back ethernet cable on the backside. It's similar to a USB tuner, but with all advantages of ethernet, especially more than one client ;-) Of course the NetClient can also access recordings over NFS etc. There's also a multiroom-setup that transfers timers to the AVG. So there is a full vdr running on the client, just the tuners are external. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote: I have no netceiver to play with and didn't look at the sources. But it's nice to see a real world use for IPv6 in consumer hardware (if you can call the reel boxes consumer hardware, it's probably only for a limited, but sophisticated market. The client and the also available standalone NetCeiver should bring it more to the masses as the price will be comparable to typical HDTV receivers. Does it just use a fixed multicast-address to receive the stream and if yes, how is the communication to the tuner realized? Is this something reel-specific or could this be used to start a unified streaming-concept for vdr based on standards (and using IPv6 to avoid all that ugly IPv4 stuff...) It is a proprietory protocol in the sense as it is no standard. When there are so many IPTV standards to choose from, why make not a new one? ;-) At the time we started, DVB-IPTV was not even named and still I think it is so bloated that it cannot be efficiently used to use cheap hardware as a server. However, our protocol uses standard protocols like MLDv2 just with a different interpretation to make it light-weight and use hardware supported streaming. In the end, one NetCeiver can stream up to 6 full S2-transponders (~40MByte/s), only the zapping time increases a bit... Do that with a PC :p The protocol translates (almost) all DVB specifics to ethernet, so it was no problem to wrap it back to DVB-API. The multicast address is not static but contains all relevant reception parameters. The basic communication only exchanges a few MLDv2-messages (no XML), so it can be processed very fast and also gains from MLDv2-aware switches. Only tuner capabilities and tuning states (SNR, lock, ...) are transmitted regularly in a side band via XML on a specific multicast address. That also allows zero configuration for the client. We will write a white paper about the protocol, currently we just don't have enough time... For the client side, the sources will be published as GPL. Currently we use a closed source daemon with a dvb loopback driver in the kernel, but that makes it hard to fully use the tuner virtualization and costs some overhead for small CPUs. Since we already have a native vdr plugin for that, the network code will be then forced to be GPL anyway ;-) -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 05:46:14PM +0100, Andrew Herron wrote: But does the Reel Smart-Client box run vdr? Yes, but like on the Avantgarde it's the Reel-variant (based on 1.4.x with our own HDTV extensions). -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 08:48:44PM +0100, Andrew Herron wrote: What is the hardware platform then? What CPU GPU is used? Are you running closed or open graphics drivers etc? It's a typical System-on-Chip for STBs. Details will be announced later. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD and how subtitle timing start work
On Sun, Feb 01, 2009 at 10:41:32AM +0100, Klaus Schmidinger wrote: Efforts should go into making the devices provide the actual PTS of the most recently presented frame - anything else is just trying to cure symptoms and not a real solution. The DeCypher delivers an STC over shared memory, there's also the GetSTC-method implemented. Currently I just don't know why it works only when the mainboard sound is enabled... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Wed, Dec 10, 2008 at 10:07:35AM +, Morfsta wrote: Are you selling single eHD cards solely for implementation within Reel devices? If so, I believe you should make this clear as I wasn't aware of this and other users won't be. Some of the problems I have when running eHD with VDR 1.7.0 are: - Well, they are sold for hackers. As there is no official HDTV-capable vdr, RMM cannot provide support for any possible patch variant. AFAIK it is mentioned on the website that it works best with the reelvdr. 1) Upgrading the latest testing version SVN often causes problems with compilation and you have to try and track down patches from other sites, or for bleeding edge SVN there simply aren't any available resulting in it not being possible to compile it. Would it be possible for Reel to host patches that will apply to vanilla VDR to make this operate, or have I missed this already? I don't think that RMM can make patches for vanilla vdr, because there is no standard how to handle DVB-S2/HDTV. You have multiproto systems, you have S2API. Neither one is used in the reelvdr. Currently there is the inofficial PES-solution for h264, but as Klaus wants to move to TS, it is already deprecated. In the end, it would be a reelvdr ported to 1.7 just because there is an 1.7. That makes no sense when there is already a maintained 1.4-1.7 chimera from RMM which works out of the box. You can download the reelvdr source and compile it on your own. There are maybe a few compiler/make issues, but most of them are easy to fix. 2) Seeking forward/backward/play/pause/fast forward/fast rewind in recordings does not work very well and there is a bad delay and lag when using these functions. This is frustrating and irritates my wife! Hm, what means bad delay? The reelvdr IMO has not such issues. The trickmodes are a bit slower in their reaction than on the latest FF card firmware, but for me it's Ok when looking at all the buffering stages that need to be notified and flushed... 3) You cannot play MKV files with the xine mediaplayer (although I think this also applies to Reel products) We know. Something is wrong in the AVC-parser that affects some (not all) MKVs. 4) Some channels don't work, e.g. BBC HD (very important for us Brits), SVT HD and others. Apparently BBC HD has been fixed in the Reel products but it doesn't work for vanilla VDR This is maybe an issue due to the PES remuxing as you need to differentiate between AC3 and MPEG during remuxing. As it seems BBC HD makes some strange things here. The reelvdr doesn't remux HDTV and records dumb TS, so we just had to fix it in the player detection. 5) If the stream is interrupted (i.e. weak signal) on HD channels / recordings then the picture does not recover until a channel change. This is a serious issue which needs to be addressed. There are some watchdogs implemented (eg. to large timestamp jumps, internal buffer overflow, apparent decoder stalls etc.). But the overall handling is quite fragile, some decoder problems cannot detected. Can you reproduce these hangs reliably? -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote: I hope you don't buy an eHD card since I don't believe it's the way to go and it would drive VDR in the wrong direction. I'm sitting here with a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu 97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask me. And now that hdmi audio finally works with nvidia it's just awesome. I REALLY hope the xine guys will get this running soon. Btw, thanks to Klaus and the rest for all the work you put into this. /Magnus H Why all this eHD-bashing? Just because a *commercial* company already made a complete HDTV-vdr-solution more than 18 months ago that the vdr-community hasn't achieved until now? Of course the eHD won't live forever, probably not half as long as the FF-card, but it solved an imminent issue at that time and it allowed to run vdr and HDTV on it. I also favour decoding in the graphics card instead of dedicated HW, but please make a reality check: For Linux, this option is now available for 4 weeks or so... BTW: The HDTV/h264-capability is in no way related to the eHD, so it simply cannot drive vdr in the wrong direction. If you look at the stuff that the reelvdr already has in its core for TS/HDTV/h264-handling you will see that there is ZERO dependency on the eHD. The eHD-reelvant code is just an output-plugin similar to the softdevice-plugin. The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made? -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Tue, Dec 09, 2008 at 12:46:21PM -0800, VDR User wrote: On Tue, Dec 9, 2008 at 11:48 AM, Georg Acher [EMAIL PROTECTED] wrote: The reelvdr code base is tested by a really large number of users (many thousands and not many geeks ;-) ). Is there any specific reason why you don't want to profit from the experiences RMM already made? There are many thousands of reelvdr users? That's news to me but ok. I don't know the exact numbers, but the Reelbox Lite was about 4-5k. Only one batch of PCBs was produced because later the prices for the used chips increased dramatically. So RMM was without a product for nearly 18 months... The Avantgarde is definitely already way beyond these figures. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel overview based upon Bouquet
On Fri, Nov 28, 2008 at 10:34:40PM +0100, Niels Wagenaar wrote: I was testing a patch which would allow the Reel-VDR sources to be compiled against multiproto. But during the test of Reel-VDR, I found out that the Channel Overview was only showing the channels in the chosen Bouquet. I do really like this option and I thought it was a option in the setup.conf. However, I'm not able to find that option. Can somebody enlighten me if this option exists or if I can re-create it with a plugin? UseBouquetList = (1 for bouquet, 2 for bouquet list). I use 0, I hate the bouquet sorting in any variant ;-) In the Reel-vdr, the menu is in OSD settings (expert mode). -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Syncearly + subtitles problem
On Wed, Oct 08, 2008 at 06:10:55PM +0200, Klaus Schmidinger wrote: Does this mean that the eHD will actually deliver an STC, or that some workaround will be implemented? The STC is already written into the shm area in regular intervals (after each received packet). It is used to emulate a somewhat synchronous STC on the PC for the AV-sync via mainboard audio. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 + reelbox plugin problem
On Sat, Sep 20, 2008 at 03:41:23PM +0300, Josce wrote: I have also noted that sometimes when I boot my pc the eHD card gets an IRQ 255. [EMAIL PROTECTED] tv]#lcpci -v 03:0f.0 Multimedia controller: Micronas USA, Inc. Unknown device 8100 Subsystem: Micronas USA, Inc. Unknown device 8100 Flags: medium devsel, IRQ 255 Memory at dfc0 (32-bit, non-prefetchable) [disabled] [size=4K] Memory at 2000 (32-bit, non-prefetchable) [disabled] [size=128M] Capabilities: [40] Power Management version 2 When this happens I can't start the card: [EMAIL PROTECTED] tv]# modprobe hdshm [EMAIL PROTECTED] tv]# /usr/local/src/eHD/hdboot -i /usr/local/src/eHD/linux.bin Decypher PCI BAR1: 2000 Warm Reset Timeout: U-Boot not ready for PCI boot [EMAIL PROTECTED] tv]# Could my card be defect? There is a reset circuit on the that controls the complicated power sequencing. It is possible that your BIOS is too fast and configures the PCI space during this powerup sequence. At that time, the HDE is not properly accessible. It is possible to shorten this sequence a bit, but for that you need to exchange a SMD capacitor on the HDE board. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 + reelbox plugin preoblem
On Sat, Sep 20, 2008 at 11:44:34AM +, Josce wrote: Could you define mosaic? Would you be able to post a picture of some kind? To be honost, I haven't updated the hdplayer3 stuff for some while now. So it could be related to a new update in the svn in the reelbox plugin/hdplayer3. I guess the correct term would be artifacts? I can see the video but here and there across the screen are small boxes. I also get in my log file: video vdr: [2037] buffer usage: 100% (tid=2036) video vdr: [2037] ERROR: 1181 ring buffer overflows (222017 bytes dropped) The harddisk has DMA on. To me it seems that the eHD can't get the stream quickly enough. What is the CPU load during that time? The host CPU transfers the data into the shared memory on the card, so anything below 80-90% load indicates another problem. When I run lspci -b I get 3 devices sharing with IRQ 5: The card does not use the IRQ, so that is not relevant. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 + reelbox plugin problem
On Sat, Sep 20, 2008 at 06:46:14PM +0300, Josce wrote: Noticed some other thing. When I playback a recording that worked well with vdr 1.6.0 the subtitles come 6-7 seconds before they should. The audio and video are in sync. Have a look at the hdtsplay-demo in the hdshm3-folder. It is a simple demo that plays back TS files over the DeCypher. If that works, your basic driver setup (+ the HW) is OK, and something in the vdr (or the patches) itself is wrong. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote: FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Which one? SCNR :-) I also don't think that a vdr-repository would help in the development speed. Either the whole development procedure needs to be changed (more maintainer with KLS's approval) or it has no advantage compared to the .tgz-distribution. But I think the repository stuff is only marginal. The design itself matters. When looking at the experiences at Reel, there are some things to be considered in the (far) future of vdr 2.0: - vdr has grown/evolved since 2000, but is still based in its design on the FF card and its capabilities. There are now different signal source setups (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the NetCeiver, and not forgetting the IPTV variants), various output types and devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a PC-based STB should be able to do (playback of other media, home automatisation, etc.). - It allows no real server/client distinction. It is quite common to have a real file server somewhere in the house, but it's hard to get a vdr running on it and viewing on other clients. Even the recordings sharing of two vdrs is not that easy (touch update here and there...). One of the main advantages of Unix was resource sharing and distribution in heterogenous networks (like X over network), but vdr is currently focused only on its platform. - The current plugin concept allows only a very limited access or modfications in the core behaviour. At least without core patches... - Based on the long evolution history, vdr IMO also has some design problems. Every object interacts with each other, I'm personally lost in the inheritance-graph of dozens of identically named Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is a bit fat ;-) This makes it hard for newcomers and potential contributors. I guess that there are only very few people that actually know what is going on in the device/devbdevice/remux/libsi-core. I still favour vdr over mythTV or MCE, because their neglect the TV side. But we have to face it: Radio is dying already. Old fashioned TV over antenna is also getting more and more unimportant and is merged with other data sources (IPTV, internet radio, podcasts, ...). Full convergence is no if, it's a when. So, the main discussion topic should be: What is needed for a future-proof design? It is not about XML or SQL or other hype buzzwords, it's about the overall design and how individual modules/plugins interact with each other. Just my EUR0.01... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 07, 2008 at 07:21:04PM +0200, Halim Sahin wrote: * help to add dvb-s2 support into main kernel!! Which one? I don't know. :-) I guess nobody does... But I have forgotten another important point: Help to develope an fullfeatured, h264 capable card, or hw accelerated Been there, done that already :-) The HDE from Reel decodes h264, I wrote a lot of the driver stuff for it. So there is (at least one) h264-decoder card, and btw, vdr is the main platform for the HDE. video driver for radeon/nvidia/intel cards. There are rumours that Ati is planning such drivers... In the long term special decoder cards will vanish, but I think it will still take some time. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fw: about eHD from Reelmultimedia (was - VDR Development)
On Mon, Sep 08, 2008 at 12:09:11AM +0400, Goga777 wrote: Yes right that might be an option for short time. Micronas stopped the support of the used chips I think. Support!=availability How many boards can be equipped with the available chips AFAIK we have received no last order date yet. I don't know of any sourcing problems. How many boards are available for vdr users? Enough... ;) -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD, VDR and multimedia files
On Thu, Jul 24, 2008 at 05:30:46PM +0400, Goga777 wrote: may be you know - does Pentium 4 3 GHz will be enough ? Even 300MHz are enough. The CPU load is not a load that depends on CPU speed. It depends mainly on the current state of the driver which transfers the video data from the CPU over PCI without using bursts. Autonomous DMA should be possible, but is not yet finished. do you mean the transfer of compressed (h264 or mpeg2) video data from dvb card to eHD ? Yes, only the TS (or ES) is transfered. Since the Decypher aborts PCI bursts (I'm not sure if it is just a config setting to circumvent some PCI erratas in the first chip version or really a HW block to fix them...), you end up with about 12-15MByte/s transfer rate at most. So a typical 20Mbit/s stream produces about 16% load almost independent on the CPU speed. There are DMA blocks in the chip, but the documentation is a bit ...er... weak -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD, VDR and multimedia files
On Thu, Jul 24, 2008 at 05:43:55PM +0400, Goga777 wrote: what about post-processing, scaling quality ? is it good ? Depends on who you ask... does only easiest bob deinterlace method support ? There is simple scaling for 576i-1080i, ie. you see ghost lines, but there are no other artifacts. There's also Bob for interlace-progressive and (in the near future) blending for all modes. There is no motion compensation, although it was inofficially mentioned at the early stages of the chip... what about support the different h264 profiles - PAFF + spatial direct mode, MBAFF (bottleneck of ffmpeg), CABAC, CAVLC Is supported, there were never problems on BBC HD or so. For CABAC, the (official) input rate is about 25Mb/s, for CAVLC 50. does eHD support those profiles well ? which h264 level does support eHD ? H.264 Main Profile and High Profile at Level 4. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD, VDR and multimedia files
On Wed, Jul 23, 2008 at 11:55:04PM +1000, Torgeir Veimo wrote: - does the card support changing output framerate between 50 and 60Hz without restarting VDR? Yes, you can change the output mode (resolution, frequency, ...) in a settings menu on-the-fly. - how is changing between video / s-video output and HDMI achieved? Can they be enabled simultaneously, or change automatically based on whether something is connected on the HDMI port? Analog SDTV output (576i/480i) works only when HDMI outputs 576p/480p. For all other modes, the analog port (usually in YUV) works in parallel with HDMI. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD, VDR and multimedia files
On Wed, Jul 23, 2008 at 10:52:04PM +0400, Goga777 wrote: may be you know - does Pentium 4 3 GHz will be enough ? Even 300MHz are enough. The CPU load is not a load that depends on CPU speed. It depends mainly on the current state of the driver which transfers the video data from the CPU over PCI without using bursts. Autonomous DMA should be possible, but is not yet finished. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] error decompressing frame for Astra HD+
On Sun, May 04, 2008 at 11:13:37PM +0400, Igor wrote: I think it's ffmpeg's problem, but I don't know how can I solve it. It seems to me, nobody from ffmpeg-devel list doesn't want to fix it. Has somebody experience with this problem ? The Astra HD stream has errors always on the same positions in the loop. They show up also with the Reel HDE and the Humax HD1000. When they were simulcasting AstraHD on the Pro7HD and PremiereHD-transponder, only the stream on the PremiereHD-transponder was OK. Now they apparently have moved the faulty stream also to PremiereHD... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
On Sun, Mar 16, 2008 at 01:50:41PM +0300, Igor wrote: The card is not a standalone product, but the video output for the Reelbox Avantgarde. As long as this box is being manufactured, the card is also produced. And the Avantgarde is sold quite successfully... Is it means that this Extension HD PCI card a VDR-users couldn't buy in the RMM-internet shop (or other shops) for upgrading existing VDR with Celeron/Sempron or other slow CPU ? The main usage is in the Avantgarde. You can buy it as a standalone card in the shop, but this is only a side effect being a regular PCI card. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
On Sat, Mar 15, 2008 at 10:45:06PM +0400, Manu Abraham wrote: Is this card still being manufactured, considering that Micronas USA closed down and the Decypher has been EOL'd ? There are enough chips available... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
On Sat, Mar 15, 2008 at 11:52:43PM +0400, Manu Abraham wrote: Georg Acher wrote: On Sat, Mar 15, 2008 at 10:45:06PM +0400, Manu Abraham wrote: Is this card still being manufactured, considering that Micronas USA closed down and the Decypher has been EOL'd ? There are enough chips available... What about support from Micronas for the chip, with regards to firmware fixes etc ? No support anymore. But most of the issues have been resolved for us. Also the RMM card uses/needs only a small portion of the chip features. The PCI communication is based on my shared memory driver with almost no kernel dependencies, so we have no problems with future kernels. The people who designed a complete STB with a standalone DeCypher have much more trouble now... What i heard was that they took everything back from the Linux driver developer for shredding after announcing closure. Yet Micronas was forwarding support requests to him after taking back all sources/info. A pity that so much efforts put in and one fine day it has just vaporized. Damagers... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI card from ReelMultimedia - what's new ?
On Sat, Mar 15, 2008 at 01:12:28PM -0700, VDR User wrote: On Sat, Mar 15, 2008 at 12:36 PM, Georg Acher [EMAIL PROTECTED] wrote: On Sat, Mar 15, 2008 at 10:45:06PM +0400, Manu Abraham wrote: Is this card still being manufactured, considering that Micronas USA closed down and the Decypher has been EOL'd ? There are enough chips available... Yes but available chips doesn't mean they have been purchased and the card is still being produced so the question still remains. The card is not a standalone product, but the video output for the Reelbox Avantgarde. As long as this box is being manufactured, the card is also produced. And the Avantgarde is sold quite successfully... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] H.264 VPID's
On Wed, Jan 16, 2008 at 08:19:53PM +0100, Reinhard Nissl wrote: I'm thinking about auto detecting H.264 in cRemux (i. e. cVideoRepacker), but it may yield wrong results. That's why I haven't started coding yet. Such a simple detection is implemented in ScanVideoPacket() of the remuxer-rewrite of the Reelbox. I haven't seen a problem with that code for almost a year now... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] current status of Extension HD PCI card from ReelMultimedia
On Wed, Dec 26, 2007 at 09:43:20AM +1000, Torgeir Veimo wrote: Is the card able to switch between 480i s-video output and 720p HDMI output easily, ie. is it possible to just start up my projector and re- route the signal from my plain old TV into the projectors HDMI input without restarting VDR with different parameters? Dual output signals is something I'm looking for so this might be a deal maker for me. Yes, you can switch the output mode via a shell utility or the vdr-GUI. Independent outputs (1080i on HDMI and 576i on SCART/YUV/S-Video) seem to be possible, but are not implemented yet. Currently HDMI and analog ouput have the same timining. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] current status of Extension HD PCI card fromReelMultimedia
On Wed, Dec 26, 2007 at 09:40:31AM +0300, Igor wrote: are the hardware deinterlacing working with this card ? There's a Bob deinterlacer for upscaling SDTV to 576p/720p/1080i. I don't know if there is a plan for a more sophisticated algorithm. is there any postprocessing inside the card ? Except the usual filtering for the arbitrary up/downscaling, I'm not aware of any additional processing. does the 1080p mode and upscaling from 720i till 1080i work properly ? The 1080p mode currently crashes the display controller, but that seems to be a firmware problem. I don't know a 720i-mode, but upscaling 1280x720 AVIs to 1080i works. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On Sun, Nov 18, 2007 at 11:29:29AM +0100, Klaus Schmidinger wrote: From what I can see in this thread http://vdr-portal.de/board/thread.php?threadid=51286 (sorry, it's in German) this card is being discussed rather controversial... From the pictures and description I also don't see any optical SPDIF output to which I could connect my Dolby-Digital decoder. AFAIK the HDMI connector also provids the digital audio, but that would go to the tv set - how would it go to the DD decoder? Electrical SPDIF is along with the component signals on the 9-pin MINI-Din-connector. It's also with I2S and I2C for audio DA-converter and some GPIOs on a flex cable slot on the backside of the PCB. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On Sun, Nov 18, 2007 at 02:30:36PM +0100, Reinhard Nissl wrote: It would be nice if you could provide a list with pin assignments for the 9-pin Mini-DIN connector. I do have a pigtail from an nVidia graphics card and I'd like to know where to find for example S-Video. 8 7 6 5 9 4 3 21 3/5: GND 1: SPDIF-out 6: Y (Y in YC-mode) 8: U (C) 9: V (CVBS) If you remove the plastic pin of a 4-pin-S-Video plug, it fits nicely (without any violence...) in the 9-pin socket and has the right pin assignment. A very strange coincidence ;-) -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ 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.10
On Wed, Oct 17, 2007 at 08:16:54PM +0200, Reinhard Nissl wrote: Hi, attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9. I still don't understand why you want to record h.264 in PES... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI from ReelMultimedia in August ?
On Fri, Aug 10, 2007 at 02:12:22PM +0200, Steffen Barszus wrote: from my understanding of happened discussions: 1080p: HDMI supported, YUV Not supported (the decoderchip should be able to handle it , the Focus(? - Chip for analog output) can not handle it according to spec. *unofficially only from my understanding Correct. Easiest would be , if there would be a framebuffer you just could use for it, shouldn't it ? There is a memory mapped framebuffer visible over PCI, we just have to write a driver for it. Then also X should be possible (@800*600, 32bit RGBA), but until then, consider this as a maybe and not a promised feature. The vdr-osd is currently done by message passing to a drawing daemon on the card itself. But for playing back unsupported formats, recoding to MPEG1 should be do-able, I haven't tried it. Also note that some unsupported or not mentioned formats may actually be supported by the chip and we just currently have no SW support for that (container parsing, etc.). There are people working on the universal media player part. But that's not my area, I can't comment on other supported formats than h.264 and MPEG2 (SD/HD) for now. Yes the same i think - looks like NG FF card ;) - so who is starting to buy one ? ;) For the full it's missing the tuner. But given the TV programming nowadays, it's not a real drawback ;-) -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI from ReelMultimedia in August ?
On Mon, Aug 06, 2007 at 08:44:49PM +0200, Lars Bläser wrote: For the moment, we have only a plugin for vdr and some demo programs to transfer TS/ES data. There's no plan for a DVB adapter-like integration, but there's no obstacle in writing one... only a plugin for vdr? does that mean a output plugin like the one for the dxr3? Haven't seen that yet, but I guess it's similar. It has methods for playing ES and TS (see below) and uses the transfer mode. does it work with other plugins like the dvd-plugin? Yes. It also provides the OSD-stuff. what about the h.264, vdr does not support that (yet)? Our vdr does already. Due to performance constraints with the Geode, remux.c was replaced in the RMM-vdr with a more optimized one from the beginning (but it's still API compatible). That allows some really nasty extensions... Now there's a simple h264 detection added. It's maybe not formally correct (I'm sure that I've missed some obscure packing scenarios), but it works with the few h264 channels on air... After the h264 detection, the remux output is no longer PES, but raw TS. So the CPU load SDTV vs. HDTV is about the same, no complex repacking is done for h264. The TS recordings have a synthetic PMT now and then, so they are correctly detected by mplayer/vlc. The frame index is also stored, ie. go-to and jumps work. The playback section detects the TS format and forwards it directly via the TS-play-methods to the card, as the TS demux runs on the DeCypher (load sharing, quite important with a 300MHz turtle ;-) ). The current scheme works quite fine, also it requires only a small DVB-independent kernel driver for establishing the shared memory communication. BTW, when reading the DVB-ML, I don't get the impression that the DVB subsystem is in a good shape for the near future :-( anything better to offer? No (enough other things to do...), but the idea of putting the tuner parts into user space is IMO the future. the problem is that this is the only solution for linux with vdr The old API itself is OK for most aplications. But I don't want to write a device driver now. I've lost track during all the PLL refactoring and the totally new API for S2 support is IMO a bit oversized and too preliminary to rely on for a product. The RMM S2 stuff on the RB Lite uses the old 2.6.11 and packs the few additional S2 parameters in the upper FEC bits. It is a hack, no question, but it's compatible and an easy patch on proven kernels. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 11:34:14AM +0200, Steffen Barszus wrote: Another thing: Will it have a proper framebuffer ? I mean the main problem of the current FF cards is that you can't do a lot of things because of the very limited OSD. ScumVM etc pp would be a really nice thing. The OSD framebuffer (RGBA) is accessible over PCI, but I don't know if acceleration functions will work outside the embedded system. We are planing to write a small fb-driver (shouldn't be that hard, as a direct mmap() already works). -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 12:33:39PM +0200, Clemens Kirchgatterer wrote: because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better. So what? Wasn't it idea of free Software to get it without paying for it? no. and i'm a little bit shocked to read this from you. i hope this is just an unlucky wording. No, it's not. Free is free, you can't make differences between hardware vendors using Linux as a basis for their HW and SW vendors using Linux as an OS for their SW. And that's exactly the intention of your wording (zero cost). Or is there a newly inserted paragraph about hardware vendors to pay something if they use free SW? sarcasm does not help here either. Oh, it helps a lot to tolerate opinions from people who don't know what's behind selling hardware with chips from others. There are things you can't change, eg. NDAs. free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements. Until now, there's AFAIK no legal decision that you are not allowed to include binary only modules in the kernel. If it gets that far, we will put in user space. No real gain, but if it helps... The usual practical anti-binary arguments for a PC platform (new mainboard requires new kernel) don't count here, it's an embedded system. You can't simply switch the kernel anyway, as it has many additions for the V4L-stuff. what if i wan't to put additional faetures into the card? what if i want to fix a bug in the firmware? benefit from performance improvments in later kernel releases? IMO a theoretical question. This is not file server. It's a video decoding card. Most of the important stuff is done in the (closed) co-processors anyway. If you want it to be a file server, you don't need the HDMI output. it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real. Don't buy it and wait for a card with better Linux support. I'm beginning to understand why big consumer hardware vendors won't do Linux support at all, if they get always this friendly reception... [..] many people don't care about their freedom as users. either because they don't have the knowledege to fiddle with the software themselfs or they rather have binary drivers for their expensive / high performance video card than free drivers for a cheep one. fine. but at least vendors MUST respect the will of the countless developers who release their work under the license of their choice for a reason. Apropos developers: How much do YOU already have developed for the Linux kernel, DVB-API or vdr? I've made the experience that the loudest people in this GPL issue have the least contributions... But it's getting tedious. Take it or leave it, that's all I can say. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote: That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device). To make it clear: This whole argument is *ONLY* about the HDMI chip driver, which is the only closed source part in the kernel. This part is *not* a modification of some existing code. You can build the whole image without it (or maybe with a dummy module) from source, and all the video decoding and analog output will still work, but you lose and HDMI/DVI output. Maybe there will be a better solution later, but for the moment that's it. There are enough real challenges in the project than thinking about how that module can be put into user space... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 03:55:04PM +0100, Darren Salt wrote: I demand that Georg Acher may or may not have written... On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote: That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device). To make it clear: This whole argument is *ONLY* about the HDMI chip driver, which is the only closed source part in the kernel. This part is *not* a modification of some existing code. That part may not be, but you can't simply switch the kernel anyway, as it has many additions for the V4L-stuff. That (to me) says 'modified kernel source'... But that's included as source and released by Micronas as GPL. What I meant with you can't simply was that you need to do the all the diff'ing and porting the additions to a newer kernel version, which will not be actively supported. You can do it but I doubt the gain and RMM will stick to the official kernel version provided by Micronas anyway. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote: If only the hardware vendors where as united as the movie-industry. HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and HDMI. As long as they can sell chips and licenses, they don't care about the consumer, looks quite united to me ;-) In principle, HDMI is not that bad (ok, the mechanical part is ugly...). In contrast to DVI, it allows to encapsulate audio and additional information, which makes it much more universal. Unfortunately it is quite expensive to get into the club (and buy chips) and the legal stuff is -er- demanding... And quite frankly, the dumb consumer doesn't care about HDCP and its implications. Compared to DRM on music, HDCP is invisible to him, he has no visible disadvantage. So all the boycott stuff is for freaks only. The consumer buys a display with HDMI and it just works (with or without HDCP). BTW: HDMI doesn't mean you have to enable HDCP. But you can't tell the consumer sorry, we think that HDMI is bad/crap/useless anyway, so we have only analog output. He will look for another product with a plug in the right form factor. And nobody spends a few hundred thousand $ on HW development just for a freak product... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
On Sat, Jun 30, 2007 at 01:29:23PM +0200, Clemens Kirchgatterer wrote: Anssi Hannula [EMAIL PROTECTED] wrote: If I understood correctly, you only need proprietary parts for the kernel that runs *in* the card. The kernel running on your actual system does not need proprietary parts, leaving you free to use a different kernel. yes, but as there is linux also running on the card the GPL applies there as well. what if i want to change that? Then you are loosing the HDMI output capability... I'm also unhappy with that issue and I don't understand why it has to be a kernel module at all. But for now it's built that way. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
On Sat, Jun 30, 2007 at 01:05:18PM +0200, Stefan Lucke wrote: Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel Damm, that's the nvidia way. They decide on which kernel it runs. If I need for some other device a different kernel which they don't / won't support, I'm left alone. It does not affect the kernel of the host system, so don't overreact... To my opinion that is a nogo way. Your opinion... From the outside it's easy to say that everything must be open source... As a small hardware manufacturer you have three possibilities: 1) Don't use a HDMI transmitter and ignore the market demand. 2) Use a HDMI transmitter, care about the NDA and deliver binary modules for controlling it. 3) Use a HDMI transmitter, publish the controlling code and pay a contract penalty of a few million $. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
On Fri, Jun 29, 2007 at 10:47:58AM +0100, Torgeir Veimo wrote: There is other hardware that does mpeg2/4/h.264 decoding, the lacking piece is always proper open source drivers. Will this hardware have open source drivers / open specifications? With a few exceptions (eg the driver for the HDMI chip) it will be open source. Actually, there's a Linux running on the card... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
On Fri, Jun 29, 2007 at 12:13:53PM +0100, Torgeir Veimo wrote: Is this the card in question? http://www.directupload.net/images/070503/CjsyApL2.jpg It is. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reelbox HD kit - vendor?
On Wed, Mar 28, 2007 at 03:33:51PM +0100, Torgeir Veimo wrote: Ok. I guess they could sell a lot of PCI versions of that card if they made one.. Not everyone wants a ready made reelbox. Well, maybe there will be one later... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote: I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Due to the limited power of the Geode with 300MHz of the Reelbox, I've analyzed the TS-path in the vdr with gprof/oprofile and re-wrote the repacker from scratch and changed some of the related TS code in device/dvbdevice. It has a lot of optimizations: - The ringbuffer works with packet granularity (no single bytes), no extra sync checks are needed. Multiple memcpy of the same data is avoided as much as possible, especially for the video part. - The MPEG-sequence code search (ScanVideoPacket) is optimized for simple CPUs where the raw number of memory accesses and instructions is important (no memchr, that's slower on the Geode) - The video packer detects if the PES-flag in the TS header actually starts a new PES packet with I, P and B-frames at the TS beginning. After this detection, the search for start-of-picture is no longer done and the PES-flag only determines the separation. Since a lot of broadcasters are using the flag this way (especially the hingh bandwidth ones like ARD and ZDF in Germany) this saves a lot of CPU time. Services which don't allow this usually have low bandwidth anyway and are IMO not that important anyway (CNBC, Gods Channel, etc ;-) )... - There's one ringbuffer (and thus one data copying) eliminated in the way from the DVB-device to the TS receivers. Multiple ringbuffers in a row only give the illusion of better buffering... - The TS-dispatcher in cDevice::Action looks for bursts of TS-packets with the same PID and only does one Lock() and one Receive()-call for this burst instead for each single packet. Video data usually comes in bursts, so this saves a lot of unnecessary overhead. As the receiver function allows multiple packets (length parameter) this is perfectly legal. Unfortunately, some plugins don't respect the length parameter (older femon comes to mind, I don't know about the latest version). But that is easily fixed... The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Sun, Mar 18, 2007 at 05:25:00PM +0100, Halim Sahin wrote: Hi, Is there a patch available with your modifications? That's a bit difficult, since our vdr has no exact mainline equivalent. It may contain parts from different vdr versions. But as I've heard, it should work also on a full featured card without any modifications. Maybe you need to tweak the makefile... The remuxer itself should be API compatible, so exchanging the file and using tools.c/h from the svn should also work. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
