Re: [vdr] setting tv standard in /dev/video0
On 7/1/07, VDR User <[EMAIL PROTECTED]> wrote: Unfortunately I don't have a patch to vdr to handle this but it's better then having to install X and all the other unnecessary packages... You can compile and use v4l2-ctl from the current mercurial v4l drivers located in the v4l-dvb/v4l2-apps/util dir. command is: v4l2-ctl -s ntsc Tested and works. v4l2-ctl is meant to be a standalone app. Thanks for this. I think the Makefile needs another dependency added to it: L../../lib -lqt-mt -lXext -lX11 -lm -lpthread /usr/bin/ld: cannot find -lv4l2 collect2: ld returned 1 exit status Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] setting tv standard in /dev/video0
On 7/1/07, Stone <[EMAIL PROTECTED]> wrote: On 7/1/07, VDR User <[EMAIL PROTECTED]> wrote: > > Unfortunately I don't have a patch to vdr to handle this but it's > better then having to install X and all the other unnecessary > packages... You can compile and use v4l2-ctl from the current > mercurial v4l drivers located in the v4l-dvb/v4l2-apps/util dir. > > command is: v4l2-ctl -s ntsc > > Tested and works. v4l2-ctl is meant to be a standalone app. Thanks for this. I think the Makefile needs another dependency added to it: L../../lib -lqt-mt -lXext -lX11 -lm -lpthread /usr/bin/ld: cannot find -lv4l2 collect2: ld returned 1 exit status Sorry, my bad. I just need to start building one directory higher. Thanks again. ___ 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
Georg Acher schrieb [ ... snip ... ] >Well, you don't have to buy the card if you would wake up in cold sweat >every once in a while because of the small binary-only part in the kernel. > >But IMO you can wait until the end of time for a full open source HDTV card >with HDMI output. If you have the time... ;-) > > > Agreed on all your points. In the end the "firmware" of this card is more open then the one of the Nowadays common FF cards - so what ? I'm caring only for two things at the moment: 1.) That the card comes and can also be bought 2.) That the card fits into my budget (That i can and want to pay it) To my understanding its just about feeding the stream into the card. 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. Just my two cents - Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Strange CPU usage cycling after user inactivity
Brendon Higgins wrote: > Jun 30 21:12:55 phi vdr: [3452] frontend 0 timed out while tuning to channel > 0, tp 536 > > I'm a bit confused that it's > trying to access channel 0, since AFAICT there is *no* channel 0. 'Channel 0' is usually the scan for new channels on currently unused transponders. The timeout means that this transponder probably doesn't transmit any DVB data streams at all at the moment. See Settings -> DVB -> Update channels -> add new transponders. The CPU load problem may be a DVB device driver problem while trying to get a lock on an unused transponder. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] setting tv standard in /dev/video0
Hi, Oliver Endriss wrote: > Are there any FTA NTSC transmissions on Astra 19.2° > or Eutelsat 13°? I'd like to do some tests... Pentagon Channel:11095:hC34:S13.0E:28000:810:800,802,804:0:0:8:6:301:0 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Georg Acher <[EMAIL PROTECTED]> wrote: > From a technical view this is right, but with just a component output > you can't sell a HDTV decoder card nowadays. And HDMI is not only > about encryption but also contains audio encapsulation. And that is > an argument for HDMI vs. DVI... true. > HDCP on a open Linux system is useless anyway. hdcp is useless on any system. it is the same with every single DRM scheme out there, it only limits the legal ownders in what they can do with what they bought. but this is even more off topic. > > 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. > Or is there a newly inserted paragraph about hardware vendors to > pay something if they use free SW? sarcasm does not help here either. free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements. > Overall, all this (IMO useless) discussion is only about the HDMI > driver part which is currently (accidently) implemented in the > kernel. I can't see that it's getting any "better" from an OSS > standpoint when it's a closed-source user space program. Get real... that's your opinion. > 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? it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real. [..] 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. best regards ... clemens ___ 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
I demand that Georg Acher may or may not have written... > On Sun, Jul 01, 2007 at 12:33:39PM +0200, Clemens Kirchgatterer wrote: [snip] > 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... As things stand, ISTM that if you distribute, you'll be in clear licence-violation territory in the view of at least some of the copyright holders. >>> 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. 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). And anyway, I think that the kernel-upgrade and bug-fix points are valid... and it'd probably help if you get as many of your changes upstream as you reasonably can (if you haven't already started on this). For a start, that's likely to make it easier for *you* to switch to a newer kernel :-) > 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. No argument there. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Steer clear of incorrect forms of verbs that have snuck in the language. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Buffer overflow in initializing character table
Marco Schlüßler has sent me the attached patch that fixes a buffer overflow in initializing VDR's character table. Since I'll be away from home for another two weeks and this might be a problem for others, too, I'm posting it here before the next official developer version. Klaus diff -bur vdr-1.5.5_orig/tools.c vdr-1.5.5/tools.c --- vdr-1.5.5_orig/tools.c 2007-06-26 21:03:21.0 +0200 +++ vdr-1.5.5/tools.c 2007-06-26 21:05:18.0 +0200 @@ -756,7 +756,7 @@ char buf[129]; for (int i = 0; i < 128; i++) buf[i] = i + 128; - buf[129] = 0; + buf[128] = 0; cCharSetConv csc(CharacterTable); const char *s = csc.Convert(buf); int i = 0; ___ 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] Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
On Sat, 30 Jun 2007, JJussi wrote: > So, is there "real" solution to this missing subtitles at recorded program > problem? The "vdr-1.5.2-spids" patch? It enables VDR's core to handle subtitling pids internally and remuxes them into recordings as subtitles patch does for backwards compatibility. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.5: red/green/yellow/blue doesn't work anymore
On Saturday 30 June 2007 23:21:29 Torgeir Veimo wrote: > I just upgraded to vdr 1.5.5 and now the colour buttons on the remote > doesn't work anymore when there's no OSD. If I press the menu button > first they work. > > Is there a new setting that can have this effect? Hmm, my keymacros.conf for the color buttons still works: Red Recordings Green Schedule Blue Timers According to Vdr's MANUAL, the color keys have no default function. Maybe your keymacros file is not found? Kind regards, Stefan ___ 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
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'... [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 am Zarniwoop of Borg. I've been waiting 900 years to assimilate you... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.5: red/green/yellow/blue doesn't work anymore
On 1 Jul 2007, at 15:54, Stefan Taferner wrote: On Saturday 30 June 2007 23:21:29 Torgeir Veimo wrote: I just upgraded to vdr 1.5.5 and now the colour buttons on the remote doesn't work anymore when there's no OSD. If I press the menu button first they work. Is there a new setting that can have this effect? Hmm, my keymacros.conf for the color buttons still works: Red Recordings Green Schedule Blue Timers That's it! That file had simply disappeared from my /video directory. Thx! -- Torgeir Veimo [EMAIL PROTECTED] ___ 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] Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Sorry to jump in here... so does the vdr-1.5.2-spids patch mean that the subtitles patch & plugin are no longer needed? On 7/1/07, Rolf Ahrenberg <[EMAIL PROTECTED]> wrote: On Sat, 30 Jun 2007, JJussi wrote: > So, is there "real" solution to this missing subtitles at recorded program > problem? The "vdr-1.5.2-spids" patch? It enables VDR's core to handle subtitling pids internally and remuxes them into recordings as subtitles patch does for backwards compatibility. BR, -- rofa ___ 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
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Georg Acher <[EMAIL PROTECTED]> wrote:
> 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").
strange interpretation of my words. where did i say, that there is any
difference from SW to HW vedors? "zero cost" implied, that some vendors
just try to get a free ride. otherwise there was no need for
http://gpl-violations.org/
> 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.
you can't change the GPL either.
> > 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...
you are nitpicking. if you have read the kernel license and you
understood its intention you can not think binary modules would not
violate it. the GPL was never really challenged in court (at least to my
knownledge), does that mean it's invalid? the FSF itself clearly
stated, that binray only modules violate the GPL, who would know better?
[..]
> > 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...
the usual ranting.
what does linux support have to do with wether you obey a certain
license or not? we are talking about the os "on" a pci card here. you
decided to use free software for your benefit, to make the card cheaper
or better or whatever. cool, no problem. what? you signed a NDA that
does not allow you distribute the os in the first place? your bad.
if it is so easy for you to change the offending software part, why not
from the beginning? your product specs sound really good and the fact
that there is linux running on top of the hardware seems to make it a
nice toy, at least at a first glance. the firmware of the ttpci cards
are a good example of why i would love to have a more open firmware on
it. how long did it take until it was stable? too long. 4MB ram support
could only be added by someone with access to the source code. did it
help anybody to keep the source locked up? did it prevent sc? no.
so i'm all for a DVB/video card that does not have these
limitations. people like to tinker with their harware. even if it's not
me personally who does something unusual with that thing, someone
will. the pure possiblillity of beeing "hackable" adds value to it.
the linux kernel, being monolithic, can be a showstopper if it can not
be changed/upgraded.
> > 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...
regardless of wether this has something to do with the validity of my
arguments or not: i never contributet patches to the linux kernel
directly only some bugreports and patch-tests. i released one small
plugin and once or twice sent patches for vdr, but they got rejected
AFAICR, nevermind. besides from some small libraries and rather useless
tools from my early days i hope that i can convince my employer to
release my main project of the last 3 years under GPL3 [would be
hopefully rather useful for STB vendors or even xbmc]. nevertheless i
doubt i'm one of the loudest who endorses free software either. but i
truly believe that the one and only reason, why GNU/Linux is what it is
because of the GPL. otherwise it would be at best as "untot" as the
BSDs.
> But it's getting tedious. Take it or leave it, that's all I can say.
a decision i will make when time has come depending on the
circumstances.
best regards ...
clemens
___
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 06:47:18PM +0200, Clemens Kirchgatterer wrote: > or better or whatever. cool, no problem. what? you signed a NDA that > does not allow you distribute the os in the first place? your bad. Once again, and now in capitals. IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE WITH IT AS YOU LIKE. You won't find any HDMI chip without NDA for the forseeable future. No NDA, no chips, no HDMI. So there's simply no choice at all and analog inputs are slowly dying. A card without HDMI is already dead in the market. If that security-by-obscurity is reasonable due to possible bus snooping, hacking, whatever: Surely not. Logitech also didn't gave me a datasheet for their Quickcam, so I reverse-engineered in in a few days with an USB analyzer. But this is not the point. If the vendor has the choice to sell cards or pay a multi million penalty, all these theoretical ideas get unimportant and the vendor cares about each single letter in the NDA. -- 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 01.07.2007 19:40, Georg Acher wrote: > On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote: > > > or better or whatever. cool, no problem. what? you signed a NDA that > > does not allow you distribute the os in the first place? your bad. > > Once again, and now in capitals. > > IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE > WITH IT AS YOU LIKE. > > You won't find any HDMI chip without NDA for the forseeable future. No NDA, > no chips, no HDMI. So there's simply no choice at all and analog inputs are > slowly dying. A card without HDMI is already dead in the market. If only the hardware vendors where as "united" as the movie-industry. The result would have been a clear "F*ck You". But with all that backstabing from the left/right/up/down/center, the only looser is the group between their chairs. (The consumer). It's the same with the current PNR and SWIFT data-transfers to the USA. If the EU would be united and say "F*ck You" the USA could happily close their borders. But i'd say the backlash from the economy would open up the borders faster than you can say 'Bad Idea'. According to Wikipedia (sorry german) http://de.wikipedia.org/wiki/Liste_der_L%C3%A4nder_nach_Bruttoinlandsprodukt the EU (in total) has a greater "gross domestic product" than the USA! And the EU has more citizens (about 300M USA, about 492M EU). But in all those cases the unity lacks and the "Power Player" wins. I'd say: Murphy's law proven right again. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ 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] Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
On Sun, 1 Jul 2007, Andrew Herron wrote: > Sorry to jump in here... so does the vdr-1.5.2-spids patch mean that the > subtitles patch & plugin are no longer needed? No, the subtitles patch and plugin are still needed for viewing the subtitles (both recordings and live tv), But I know that there exists a DVB subtitling support integrated into the core VDR without any needs for a plugin, so depending on Klaus priorities we might see that 3rd party functionality sooner or later in official releases too... BR, -- rofa ___ 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
I demand that Georg Acher may or may not have written... [snip] > 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. That's as may be... however, it does seem to be ignoring those of us who happen to want video output in a window (as I do now with vdr & gxine). If there's any taintware involved in that, I for one don't want it. (And I couldn't care less about it right now, at least for my own use - there's no terrestrial HD broadcasting here and there won't be until 2012 at the earliest, that being when analogue transmission is switched off.) > So all the boycott stuff is for freaks only. Right... so consumers are either dumb or freaks... remember that you're one too :-þ [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Travel less. Share transport more. PRODUCE LESS CARBON DIOXIDE. Since you're going to die anyway, can we use you as a shield? ___ 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
Georg Acher wrote: > 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. I cannot let this pass. They don't know they need to care, but they will, down the line after their money has been taken. I own a sony HD projector that is not permitted to display HD content! this will happen to a lot more people and they will care. Especially when the next DRM protocol comes along. Its already happening to both protocols and DRM standards. I noticed that on the xine mailing list there was a request to encode wma content because their phone only supported that. With the rapidly growing green awareness there is the potential for a backlash against manufacturers that force consumers to dump working kit just because the hardware doesn't talk the same protocol. open standards are the only way to prevent that kind of waste and frustration. The problem with all DRM (and to some degree the rapidly changing protocols) is that the problems appear long after the initial purchase. They control the interface between equipment or media and as such it costs significant resources to fix, repair, replace or bypass etc and then only if its legal and purchasable. Simon ___ 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 01.07.2007 21:10, Georg Acher wrote:
> 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 ;-)
That's the "back-stabbing"-part i meant.
You can be certain that there is someone to pick up a knife laying around.
Here is another example of such a "knife" thing from today:
http://hardware.slashdot.org/hardware/07/07/01/0221213.shtml
They invented it because they think that someone will want it (and most
probably someone will), just the same as Intel/Silicon Image.
Another word would be:
"anticipatory obedience" ("vorauseilender Gehorsam" (translated by
dict.leo.org))
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
ok. Thanks for clarifying that. On 7/1/07, Rolf Ahrenberg <[EMAIL PROTECTED]> wrote: On Sun, 1 Jul 2007, Andrew Herron wrote: > Sorry to jump in here... so does the vdr-1.5.2-spids patch mean that the > subtitles patch & plugin are no longer needed? No, the subtitles patch and plugin are still needed for viewing the subtitles (both recordings and live tv), But I know that there exists a DVB subtitling support integrated into the core VDR without any needs for a plugin, so depending on Klaus priorities we might see that 3rd party functionality sooner or later in official releases too... BR, -- rofa ___ 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
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Simon schrieb: >Georg Acher wrote: > > > >>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. >> >> > >I cannot let this pass. > >They don't know they need to care, but they will, down the line after >their money has been taken. > > That may be or they just recognize that this "computerstuff" again just not works as advertized and they will buy it again the next time. The "freaks" trying to fix their stuff as good as possible after having prayed why they should not have bought it in the first place. >I own a sony HD projector that is not permitted to display HD content! >this will happen to a lot more people and they will care. Especially >when the next DRM protocol comes along. Its already happening to both >protocols and DRM standards. I noticed that on the xine mailing >list there was a request to encode wma content because their phone >only supported that. With the rapidly growing green awareness there >is the potential for a backlash against manufacturers that force >consumers to dump working kit just because the hardware doesn't talk >the same protocol. open standards are the only way to prevent that kind >of waste and frustration. The problem with all DRM (and to some degree >the rapidly changing protocols) is that the problems appear long after >the initial purchase. They control the interface between equipment or >media and as such it costs significant resources to fix, repair, replace >or bypass etc and then only if its legal and purchasable. > > And you really think somebody will recognize that ? Its again just that computer stuff that does not work as advertised ... I really hope you are right and people are understanding what open standards and open protocols are good for. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
