En/na Luca Olivetti ha escrit:

En/na Reinhard Nissl ha escrit:

...

Hi,

I'm pleased to announce the long awaited release 0.8.0, which integrates the vdr-xine-network patch. You can find it on my homepage:

I finally upgraded to this version (from 0.7.6 + network patches, I think I tried some other version but with similar problems as this one), but using it from the network (I cannot try it locally, so I don't know if it applies), live tv stutters (i.e. plays smooth for around a second, stops or slows down for a moment, plays for a second, stops, and so on). Recordings are not affected by this problem (or so it seems). The same version of xine (20070829224000, downloaded from your page, with the patches in vd-xine) on the client against streamdev-server plays smoothly.

Mmmh, I usually use wifi, now I tried with a wired connection and it seems to work fine. 0.7.6 worked fine with wifi though (even with marginal reception, with at least 5Mbps available as reported by kwifimonitor), and where I usually need it there's no wired connection available. Is it possible that newer version generate more traffic/are more sensible to network latencies?

Bye

En/na Reinhard Nissl ha escrit:

Hi,

Luca Olivetti schrieb:

...

Is it possible that newer version generate more traffic/are more sensible to network latencies?

Yes, at least in the buffer monitoring phase, which was introduced with 0.7.7. Try to set it to 0 in vdr-xine's setup menu.

That was it! Thank you. Incidentally, that was the only parameter I didn't touch ;-)

Bye

"mike lewis" lachlanlewis@gmail.com writes:

Hi,

I've used vdr-xine, and I've used xinelibout for vdr. I've just ogt a general question, as they both seem to have similar functionality (or at least they both satisfy my need for a software client head to vdr. What's the driver for vdr-xine? I've heard people say xinelibout is "better" because it is more stable. But, whats the reality?

If you've used both you should be able to compare them, shouldn't you ?

I've also used both. Now i'm only using xineliboutput because (just facts, no attack !) - it has support for network without patching for longer - it doesn't require me to recompile libxine - network features are more advanced - i can have more that one frontend watching/sharing the same channel. - now i just aptitude install libxine1-xvdr to install the client side.

Obviously the two plugins are both great plugins. And, Reinhard you do a really good job providing patches for vdr & xine ! Thanks a lot.

I guess the hidden question was "have you ever considered to merge the two projects ?", wasn't it ? :)

My question would be: "one vdr, one xineliboutput plugin, 2 dvb cards, 2 independant frontends displaying different channels(+osd and stuff) without streamdev, has it been considered ?" :)

On Tuesday 13 November 2007 13:50:42 mike lewis wrote:

On Nov 13, 2007 7:12 PM, syrius.ml@no-log.org wrote:

...

"mike lewis" lachlanlewis@gmail.com writes:

Hi,

...

I've used vdr-xine, and I've used xinelibout for vdr. I've just ogt a general question, as they both seem to have similar functionality (or at least they both satisfy my need for a software client head to vdr. What's the driver for vdr-xine? I've heard people say xinelibout is "better" because it is more stable. But, whats the reality?

If you've used both you should be able to compare them, shouldn't you ?

Well no, as I used them in the past and my media box died; and my memory isn't all that good.. so now I'm re-assessing my new solution based on running linux on a ps3; and I can't compare them until I've installed them both... Which is basically what I want to avoid ;-).

...

I've also used both. Now i'm only using xineliboutput because (just facts, no attack !)

• it has support for network without patching for longer
• it doesn't require me to recompile libxine
• network features are more advanced
• i can have more that one frontend watching/sharing the same channel.
• now i just aptitude install libxine1-xvdr to install the client side.

Yes, the "support" for users like me on something like ubuntu is one reason why i'm likely to go down the path xinelibout.

...

Obviously the two plugins are both great plugins. And, Reinhard you do a really good job providing patches for vdr & xine ! Thanks a lot.

I guess the hidden question was "have you ever considered to merge the two projects ?", wasn't it ? :)

Well no, my question probably should have been: whats the difference between the two plugins; if I'm using either simply as a software headend (similar to softdevice, but not permanently on) is their any feature which would drive the selection of xinelibout over vdr-xine?

...

My question would be: "one vdr, one xineliboutput plugin, 2 dvb cards, 2 independant frontends displaying different channels(+osd and stuff) without streamdev, has it been considered ?" :)

I think the answer there is to use one vdr per head-end.

Thanks for jumping on board the Q&A session! hehe.'

Mick

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Hi,

Using my PS3 as a vdr client is also my target. But I experienced bad (de-)interlacing when watching SD TV using SD output (even with right resolution). I am now waiting the new HV xorg driver to have more control on the video than the already available fb blit mechanism. I did rewrite the fb driver of xinelib to enhace it with ps3 blit functionality and virtual fb but it did not improve the output quality. By the way, the PS3 have a colorspace issue to display the OSD with proper color palette under the fb. (X is not affected by this)

Actually I am using streamdev and xineliboutput together. Xineliboutput is good to pilot the server side from any linux based system. Streamdev + FF card + vdr is the best deal for client device (I am using this solution over wifi and it works like a charm) Streamdev + m3u patch is ideal to use VLC with playlist and allow Win OS to access the TV programs.

If you want to start developping good SD support for the PS3 I would be pleased to provide some help.

Cheers,

Alex

En/na Graziano Pavone ha escrit:

I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..)

Note that 0.8.0 has network support built-in. A nice feature that vdr-xine has over xineliboutput, is that it automatically sets itself as the primary device when a connection comes, and when the connection is closed it restores the previous primary device. This way I can either watch locally with the dxr3-plugin or remotely with vdr-xine.

Bye

Hi,

Graziano Pavone schrieb:

2007/11/13, Luca Olivetti <luca@ventoso.org mailto:luca@ventoso.org>:

Note that 0.8.0 has network support built-in.

I know but you still have to patch and recompile xine-lib... Are there any problems in submitting the needed patch to the mainstream xine-lib distribution?

The problem is that small parts of the patch would break binary compatibility in xine-lib-1.1.x. This is no problem if a distribution decides to include the patch and recompiles all applications which use xine-lib-1.1.x.

I still do provide those patches as not all people are willing to switch to xine-lib-1.2 (hg) which is still in development, contains the patches and therefore works out of the box.

A nice feature that vdr-xine has over xineliboutput, is that it
automatically sets itself as the primary device when a connection
comes,
and when the connection is closed it restores the previous primary
device.
This way I can either watch locally with the dxr3-plugin or remotely
with vdr-xine.

I only have Skystar2/Airstai2 budget cards, so it's not an issue for me. A feature that allows to watch different channels on clients at the same time (without using multiple vdr installations and streamdev) would definetely make me switch back to vdr-xine :)

And you wouldn't mind applying a huge patch on VDR to achieve this goal?

Bye.

"Graziano Pavone" graziano.pavone@gmail.com writes:

[...]

And you wouldn't mind applying a huge patch on VDR to achieve this goal?

This feature is so interesting that I certainly wouldn't mind, even if it would a very good feature to be included in the 1.5 vdr release... :)

imho that's a feature that must be in 1.5 ! as with the smart channel management.

utf8 and subtitles are great achievements, what's next ? :-)

On Nov 14, 2007 4:23 AM, Gregoire Favre gregoire.favre@gmail.com wrote:

I would love to have VDR support H.264 recording on DVB-S.

I know a lot of people, including myself, who agree!

On 11/14/07 17:24, Lauri Tischler wrote:

syrius.ml@no-log.org wrote:

...

"Graziano Pavone" graziano.pavone@gmail.com writes:

[...]

...

And you wouldn't mind applying a huge patch on VDR to achieve this goal?

This feature is so interesting that I certainly wouldn't mind, even if it would a very good feature to be included in the 1.5 vdr release... :)

imho that's a feature that must be in 1.5 ! as with the smart channel management.

utf8 and subtitles are great achievements, what's next ? :-)

You have to ask Santa-Klaus ;)

H.264 will only become interesting (to me) once there are hardware devices that can replay it (aka "Full Featured DVB cards"). I am not interested in software players that might not even run on my 450 MHz VDR.

Until then, normal MPEG2/DVB-S does just fine for me.

Klaus

On 11/14/07 17:57, VDR User wrote:

On Nov 14, 2007 8:36 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:

...

H.264 will only become interesting (to me) once there are hardware devices that can replay it (aka "Full Featured DVB cards"). I am not interested in software players that might not even run on my 450 MHz VDR.

Until then, normal MPEG2/DVB-S does just fine for me.

Ouch!

Well, maybe we should all chip in a couple dollars and buy Klaus a new pc that can handle h264. Can build one for just a couple hundred bucks.

My VDR is just fine ;-)

Klaus

Hi,

Klaus Schmidinger schrieb:

H.264 will only become interesting (to me) once there are hardware devices that can replay it (aka "Full Featured DVB cards"). I am not interested in software players that might not even run on my 450 MHz VDR.

Until then, normal MPEG2/DVB-S does just fine for me.

I don't think that the ability to replay HD content is required to take over the patches. It would simply be nice to have a vanilla VDR 1.5.x which is able to handle H.264 content.

Did you ever record or replay MPEG2 HD content? Have you ever seen or used a FF card for MPEG2 HD content? Though, VDR has the ability to handle MPEG2 HD content.

And I don't think that we will see a FF card which can handle H.264. Gfx cards take over that business and once the VA API is released and supported, those functionality will even be available on Linux.

So whenever you like, feel free to contact me regarding integration of H.264 support. Till then, I'll try to provide updated patches, so there is no need to hurry.

Bye.

You're right, the wait for FF-HD dvb cards is pointless as the vendors have no interest in it due to no viable market and that information comes direct. We could discuss all the reasons why you will not see a FF-HD card but it still won't change anything.

Many users are moving away from FF cards and into the realm of h264 and HDTV, which is why VDR has lost a lot of users to that other software I won't mention. ;( And not just that but also moving from single card/tv/client/etc. setups to multiple cards/tvs/clients/etc.

Klaus has made it very clear that he only cares how VDR works in his environment and if you want that support then you should use different software. I'm sure a large number of users don't like hearing that but it is what it is. Klaus has the right to include or neglect anything he wishes in VDR, and users do have the option to use something else instead.

I've been using VDR for many years now and am very loyal to it and I must say I don't like seeing users leaving because VDR is being left in the dust when it comes to support for current & future things like h264 and HDTV. You can hope that Klaus will change his mind on some of these things but honestly, based on everything I've read I wouldn't hold my breath. It's better to hope that people will (continue) to make patches or get acquainted with that other software I won't mention.

Some of us aren't ready to switch just yet but there's no ignoring the shift in peoples interests. All I can say is when it comes time that I can't ignore those requirements anymore, I can only hope that VDR has envolved with the times and I won't be forced to use something else.

Klaus Schmidinger wrote:

Some comments in this thread (and others) sound as if there is an imminent need to switch to HDTV/H.264, because otherwise we won't be able to watch tv any more within a few months. I don't see any real incentive in taking all the extra efforts to do HDTV. The programmes I usually watch are all broadcast in normal MPEG2, SDTV. Even if I had the ability to receive HDTV, I would have to pay extra to actually see anyting - so what's the point?

I completely agree with Klaus on that point. All the HD hype right now is just the industries way of pushing a new technology and selling new hardware (decoders, TV sets, ...) to the consumers that didn't really ask for it. Seems a bit like some years ago when 16:9 TV sets was a *must have*. But there were actually almost no anamorph 16:9 transmissions and most people with their brand new sets were happily watching the news speaker or their favourite soap opera stars with squashed heads. That has somehow changed and even the news are in 16:9 anamorph format on German TV now. But how long did it take?

How many channels are available now which transmit quality HD content (apart from demo channels)? I don't think it's a significant number to make VDR useless because you can't watch them with it. Of course there are alternatives for the "early adaptors" so that's fine. I am sure VDR will also support HD some time in the future. It just doesn't seem necessary right now.

Ondrej ...

On Thu, Nov 15, 2007 at 07:48:25PM +0200, Petri Helin wrote:

VDR User wrote:

...

Many users are moving away from FF cards and into the realm of h264 and HDTV, which is why VDR has lost a lot of users to that other software I won't mention. ;( ... I've been using VDR for many years now and am very loyal to it and I must say I don't like seeing users leaving because VDR is being left in the dust when it comes to support for current & future things like h264 and HDTV.

But VDR does support h.264 broadcasts already, although with patching, but still. So there is no need for anyone to stop using VDR because of a lack of h.264 support.

Btw afaik some countries are broadcasting SD content H.264 encoded.. norway for example?

-- Pasi

"VDR User" user.vdr@gmail.com writes:

Some of us aren't ready to switch just yet but there's no ignoring the shift in peoples interests. All I can say is when it comes time that I can't ignore those requirements anymore, I can only hope that VDR has envolved with the times and I won't be forced to use something else.

Agreed, but in the end I'm pretty sure I will be forced to use something else. (I've been thinking that for a long time and I'm still using it :)) I'm not even sure vdr is modular enough to allow my "requirements" without changing everything, is it ? (When Reinhard says it would be a big patch I guess BIG is meant.) Anyway, there's no public TODO, no public cvs/svn, etc... I'm surprised there's no fork yet.

note: this message is not meant to be nasty, disrespectful or provocative in any way.

VDR User wrote:

Also, I talk with many dvb users on pretty much a daily basis and I've never once heard someone say they've left VDR for that other software because of eye-candy/UI. Most people seem to be concerned with capability & functionality, not pretty graphics.

My personal opinion is that, because I'm biased in favor of VDR, it's disappointing to see so many users abandon it simply because of the lack of support for things that are becoming more common & in-demand every day.

[...]

A lot of these guys aren't coders, aren't used to compiling things, and aren't even used to using a console for that matter.

They often use ready packages, and if those packages don´t contain the necessary patches, they will never get it to work.

The more the interest shifts, the more people will leave VDR in its current state behind for something more suitable. Klaus very honestly said he's perfectly ok with that and sees no incentive to support this stuff so the story pretty much ends there.

I fully agree with you (with [nearly?] all points) . I think you can see the interest in HD in the high number of hits e.g. in the DVB-S2 section at vdrportal.de. The people here and at vdrportal are very technically interested, so I think that there are a lot of early adopters that do not want to wait until 2010. And speaking for other PVR hard- and software solutions too, scrambling is no real problem for people who want to get certain content - and this is no secret as you can see in the vdr-wiki entry. HDCP output is no problem as the Dreambox 8000 is also said not to support this flag. Or do you think that Dream Multimedia will get sued as soon as the Dreambox 8000 is out because of this missing "feature"?

With kind regards

Jörg

On Nov 16, 2007 2:52 AM, Petri Helin phelin@googlemail.com wrote:

That should be no problem. If a patch exists, a package developer could easily make use of and include it in the release. So there is no need for Klaus to add it in to the core VDR.

It's generally not a good idea to base your conclusions on 'should' or 'could'. Also, you can easily & effectively argue that such basic & common functionality should be added into the core being that it's such basic & common functionality... Not much different then the recent support of subtitles.

Also, Ondrej, HDTV is not hype, it's real & it's here. Everyone I know who has invested in HDTV equipment did so because of the obvious increase in quality.. Not because they are mindless idiots who fell victim to illusions of content that doesn't really exist, or because of spoonfed hype.. Have you ever even watched HD content on a HD display? Maybe the provider -you use- doesn't offer much HD content but there are plenty of other providers that do. I don't know how it is where you live but here every major network and most of their affiliates, most of the pay movie channels, sports, ppv, etc. are all offered in HDTV, with a lot more coming soon. You can't ignore the obvious truth that a lot of people are leaving VDR behind because of its lack of support for h264 and HDTV. Maybe -you- don't use it but clearly a lot of other people do. I respect your opinions but they don't seem to be based on an accurate reflection of reality. You can resist HDTV and h264 all you want but it's here to stay.

Besides, what's so bad about being with the curve or ahead of it for once, instead of always trailing behind?

On 11/16/07 17:32, Gregoire Favre wrote:

On Fri, Nov 16, 2007 at 08:20:38AM -0800, VDR User wrote:

I didn't try vdr-1.5.11 because there is no H.264 patch for it.

I really don't understand why they are not investigated to be intregrated into vdr at this time as more and more TV are going to go to H.264 (not all in HDTV).

The answer is very simple: I'm currently working on other things.

And as long as there isn't at least a (graphics) card that supports decoding the "good old" MPEG2 in a quality that is at least as good as that of the FF DVB cards, as well as decoding H.264/HDTV in *hardware*, this whole area has next to no priority for me. I am not interested in software decoding this stuff - I don't want to have an extra heater in my living room ;-)

Klaus

And as long as there isn't at least a (graphics) card that supports decoding the "good old" MPEG2 in a quality that is at least as good as that of the FF DVB cards, as well as decoding H.264/HDTV in *hardware*, this whole area has next to no priority for me. I am not interested in software decoding this stuff - I don't want to have an extra heater in my living room ;-)

That is interesting thread to read, thanks to Morfsta that said that many others wanted to say already long time ago :)

I think that Morfsta's main point isn't any specific feature of VDR like HD support. The point is VDR's development model itself. It is closed now. Patches are not the answer to this problem. Developers have to be very motivated to maintain patches from version till version. As you see, MUCH patches are already died, not because nobody wants them, because it's hard to maintain them for years.

Klaus, you are doing the great job! But I think VDR now is much more than your own hobby/job/lack of software for your personal needs and hardware. Big part of VDR's community also want to "own" it. By ownership I mean here decision making and commiting to CVS/SVN/HG. Current development model looks like dictatorship model :) If you allow to commit improvements to VDR by other authorized devs, such things as UTF8 support were in VDR since 1.3.* I think :) I belive VDR and VDR's community will gain a lot from this.

Imagine if Linus Torvalds were the only man, who were decision maker in kernel's development. I belive linux never become so popular because of being always 2 steps backward of current community's needs.

If I were really the "dictator" as which you were "kind" enough to entitle me, I sure wouldn't have spent all the recent work in cleanly integratiting subtitle support into VDR. The original patch/plugin was way too complex for my taste.

Please, nothing personal :))) I really admired by the product and work you have done. But it is very difficult to see it's future with such development model.

I don't want to work on a VDR where people can check in monster changes into a CVS or whatever, and the next time I sit down to do something, I first have to (meaning: am *forced* to) deal with what others have modified, so that I understand the source again. I rather take one topic at a time, look at whatever patches etc. are available, and consider how things really fit into the big picture. That can mean that the patch will be integrated just "as is", because it is the right solution, or it can mean that I come up with a solution of my own, that (I believe) fits better into the VDR structure.

You see, that what I'm talking about. If VDR is one-man-project or it is targeted to community. It's your choice, you have all rights to decide what approach is the best for your child.

...

Imagine if Linus Torvalds were the only man, who were decision maker in kernel's development. I belive linux never become so popular because of being always 2 steps backward of current community's needs.

Don't compare me to Linus - I don't deserve that honor ;-)

Why not? :) And see how Linus become superstar, not just doing a good product, but more by enlarging the audience interested in it's future ;)

On 11/18/07 15:38, Magnus Hörlin wrote:

... Hi Klaus. I'm a big fan of you, VDR and Eagle since many years. I always agree with your postings and read them with great interest, but this is the first time I have to disagree. My VDR livingroom client consumes 30-35W from AC mains when running sw mpeg2 SD decode, deinterlace and scaling. Using Reinhards patches to play h.264 720p it increases to 40-45W, while my LCD runs at about 125W. So using modern pc hardware, software decoding doesn't really create a heater in my opinion. I'm sure an old 450MHz K6 uses more than that.

My setup: AMD BE-2300: €70 Abit AN-M2HD: €80 1GB no-name DDR2: €20 Mini-box picoPSU-80: €50 total: €220

Maybe it actually is about time for me to build a new VDR. I'll probably take a look at the Reel Extension HD PCI. But that means I'll also need a new motherboard with at least five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD). On my desktop PC I'm using a passively cooled Pentium M with 1.86GHz, which works really good, so maybe that's also a viable choice for a new VDR. I guess it goes without saying that modern motherboards have a gigabit Ethernet port and graphics on board. Does anybody have a recommendation for such a board?

btw Klaus: I'm an everyday Cadsoft Eagle user since five years and I still haven't had a single crash or even found a bug in it. Having used all the high-end E-CAD system there is I can say that this is unheard of in the industry. I guess you have something to do with that, or what is your position at Cadsoft?

Yes, I'm one of the developers (and also co-owner) ;-)

Klaus

On Sunday 18 of November 2007, Klaus Schmidinger wrote:

Does anybody have a recommendation for such a board?

I've found one with four PCI slots, see http://www.asus.com/products.aspx?l1=3&l2=11&l3=307&l4=0&mod....

Ales

On Nov 19, 2007 1:31 AM, Magnus Hörlin magnus@alefors.se wrote:

Klaus Schmidinger wrote:

...

Maybe it actually is about time for me to build a new VDR. I'll probably take a look at the Reel Extension HD PCI. But that means I'll also need a new motherboard with at least five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD). On my desktop PC I'm using a passively cooled Pentium M with 1.86GHz, which works really good, so maybe that's also a viable choice for a new VDR. I guess it goes without saying that modern motherboards have a gigabit Ethernet port and graphics on board. Does anybody have a recommendation for such a board?

Can't you just buy a 2nd hand Pentium 4 board and another P4 mobile? Save the environment and your wallet! No gigabit ethernet, but stick a Matrox in the AGP slot and get component PAL output.. matrox G450 costs 10 euros...

On Nov 19, 2007 2:08 AM, Halim Sahin halim.sahin@t-online.de wrote:

Hmm HDTV with a matrox card????????

What I mean is H264 video gets decoded by the extra horsepower of the P4, matrox is used with software output device in vdr.

Are you planning on buying an HD television set Klaus? Then ignore what I had to say and throw out one your dvb-s cards.

On Nov 18, 2007 9:54 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:

On 11/18/07 19:16, Alasdair Campbell wrote:

...

On Nov 19, 2007 2:08 AM, Halim Sahin halim.sahin@t-online.de wrote:

...

Hmm HDTV with a matrox card????????

What I mean is H264 video gets decoded by the extra horsepower of the P4, matrox is used with software output device in vdr.

Are you planning on buying an HD television set Klaus? Then ignore

I already have one ;-)

...

what I had to say and throw out one your dvb-s cards.

I don't want to lose the ability to record 3 DVB-S transponders in parallel, and I also need the DVB-T card.

It seems like you have two totally different options, depending on whether you go for hardware or software decoding of HD content. If the Reel HD card turns out to be a winner, then I'd suggest you buy a board with the Intel 865PE chipset, lots of second hand options out there. If you go for one with gigabit ethernet, you'll likely be buying a top line board, well looked after and with sata ports, DDR400 support, good bios options for undervolting/clocking. 5 PCI slots and an AGP slot to stick in a suitable card for installing an OS. Doubt many will come with on board video.

Of course if you go for software decoding you're in a different boat: new RAM required; USB tuners or PCIe->PCI adaptor; new PSU?; most good boards wouldn't have onboard video, so a need to buy a cheap PCIe graphics card to install in gui mode.

I know what I'd go for...it's just a shame that hardware HD decoding hasn't grown enough for there to be some competition and innovation.

I don't agree, if we start upgrading the hardware, the software will become relaxed and would require everybody to upgrade to always be at the latest and greatest level of hardware. Then maybe later on we will see more byte-code orientated languages creeping in. Just take a look at windows.

Klaus enforced strict control over the software and obviously had to work on low end hardware (optimized, so that it doesn't turn into another heater), which meant that it would run even better on the new hardware.

Intel claim to run at 11 watt idle, but the rest of the main board requires ~90 watt. I my self currently am using a desktop 24/7 and running vdr on the same machine. But I have to set every desktop application's nice level to 19 so that it doesn't interfere with vdr's output. Of course I'm running low end desktops like xfce or fluxbox.

I am still convinced that an external multimedia device would help in different ways:

- steering vdr into multiple networking client setups, - h.264 decode will happen on the client's hardware. still require vdr to accept h.264 in its core. - still low end hardware on server/clients, requiring efficient code, no heaters. - doesn't require you to upgrade your existing hardware. Just another add-on to your setup.

My 2 cents.

Theunis

On 19/11/2007, VDR User user.vdr@gmail.com wrote:

On Nov 18, 2007 4:20 PM, Alasdair Campbell ragawu@gmail.com wrote:

...

I know what I'd go for...it's just a shame that hardware HD decoding hasn't grown enough for there to be some competition and innovation.

I think the cost of producing such hardware HD cards doesn't make sense when you can build a new pc that can handle software HD decoding for cheap anyways. Also, as I understand, the chips which can do it contain many other functions that are just a total waste when you put the chip on a card to be only a HD decoder. Besides, I don't think that many users are still using some ancient pc with a slow cpu like Klaus has. Why would you bother when you can buy something way better & faster for cheap these days?

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

On Nov 19, 2007 2:40 AM, Jan Exner exner@gmx.net wrote:

...

Why would you bother when you can buy something way better & faster for cheap these days?

Why would you bother updating when it works just fine? And even the cheapest system I could buy today is still more expensive than keeping what I have now.

Well obviously when your ancient pc can't handle new things such as h264 decoding and HDTV, and no manufacturer is willing to waste their money making a hardware decoder card, I would say it's not working just fine as you claim. Sorry, a small handful of people using ancient pc's for dvb is not even vaguely enough for manufacturers to create h264 hardware decoder cards. And even if they did actually bring one to market, meaning you can BUY it and not just look at it on a website, the cost would be too much.

If there's such a market for hardware decoding, where are all the cards? How come manufacturers aren't jumping at the chance to capture the profits from people like you with old slow pc's in need of such cards?

I'm sure somebody somewhere still drives a Ford Model-T car, 'because it still works'.

On Nov 19, 2007 9:37 AM, Jan Exner exner@gmx.net wrote:

...

How come manufacturers aren't jumping at the chance to capture the profits from people like you with old slow pc's in need of such cards?

I'm not saying my way is the best way.

But there are more people like Klaus who are quite happy with hardware decoding, and I am grateful he works the way he does.

Yeah, but it's usually not a benefit to the software when the work is based primary on the needs of a small minority. In my opinion, the more people interested in VDR, the better because the bigger the VDR community gets, the more contributors you'll get as well. Which of course can be great for the development to the software. I do agree that it would be nice if code/patch submissions were evaluated by more then just one person (no offense Klaus!) to give a better & more well-rounded opinion. And also a bug/request/ticket system would be nice as well. Yes, technically you could use the mailing list for that but mailing lists aren't well-organized for that.

I think the advantages of change are pretty obvious so hopefully Klaus will take them into serious consideration. Also, change does -not- mean losing control!! In this case it just means improving organization, workflow, development, and in the end VDR! :)

Hi!

...

But there are more people like Klaus who are quite happy with hardware decoding, and I am grateful he works the way he does.

Hear, hear... Thankfully no need for totally bloated X-stuff or framebuffers or such.. Just plain minimal text/consolebased system. VDR _is_ just a Set-Top-Box

I too like the hardware based solution over one using software only, at least it was always easier to install and maintain ....

It turns out that I have to upgrade my VDR System now as my FF DVB Card has a burned video-out (too much red) and the plain-homebrew-1:1-j2-scart-adapter do no longer work with my new LCD-TV: http://l3x.net/~im/pics/IMG_4250.JPG http://l3x.net/~im/pics/IMG_4251.JPG http://l3x.net/~im/pics/IMG_4252.JPG

Not really good pictures, but notice the black pixel-errors ....

The question is now, what do do next: a) Buy the AVBoard and hope that its circuits allow better pictures again (~60 €) b) Upgrade the VDR System to DVB-S2 (~500€ at least for Motherboard, CPU, Memory, DVB-S2 with CI and a graphic-card with DVI/HDMI) c) Buy a Kathrein UFS-910 (~350€ with CAM) The next firmware should allow recording to external USB HDD too.

As it is currently it seems setting up a VDR System for DVB-S2 is not that easy as it was with a DVB-S FF system. Yesterday I tried to use xineliboutput (SD, not HD for sure) to workaround my bad picture problem, but the plain xine is to slow on my old VIA EPIA (cle266) system and I really think compiling the enhanced VIA version will become a pain ... not even sure if any of the xine plugins are compatible to it.

Well, I am definitely unsure ... thus whining here, sorry. I wanted to fell this decision not before approx 6 month .... Thus, a seems odd as it is a lot of money too ... and I can't reuse it then.

Any suggestions what to do now?

BTW: Congrats to Klaus! Great work! VDR was/IS always a pleasure. What about porting VDR to the Kathrein :-)

Ciao, Mario

Hi!

I am using the xine-xxmc plugin and cle266 hw decoder for some years now; video running smoothly and cpu usage is low. vdr is running with vdr-xine, but I don't see why you could not use xxmc also with xineliboutput...

Interesting.

Do you use the TV-Out or VGA? The quality should be better with VGA, but: What resolution did you setup to get full-screen tv output in the right aspect ratio? What about deinterlacing? I now own a 100Hz LCD-TV (Sony KDL-32D3000), but it looks like the tricks used in there won't work with PC input as then you'll see the typical "kamm-effekt" (comb-effect ;-) !?) again. It looks like the PC has to do the work then. What about the various video formats? If we can't send the streams in their native format we no longer can use all the aspect settings of the TV, no? All the resizing will be done by xine now. Or is there a way that xine changes the output format on the fly?

Ciao, Mario

On Tue, Nov 20, 2007 at 12:14:59PM +0000, Torgeir Veimo wrote:

Do you sometime find the mpeg2 decoding with cle266 gives you colour banding with low bitrate transmissions?

I didn't see such an effect on any of the DVB-T channels I have here in Berlin. What bitrate do you consider as "low"?

The question is now, what do do next: a) Buy the AVBoard and hope that its circuits allow better pictures again (~60 ─) b) Upgrade the VDR System to DVB-S2 (~500─ at least for Motherboard, CPU, Memory, DVB-S2 with CI and a graphic-card with DVI/HDMI)

you can save your money if I will look at the cheaper motheboard with hdmi output MCI K9AGM2-FIH (about 60 Euro)

Igor

VDR User schrieb:

On Nov 19, 2007 2:40 AM, Jan Exner exner@gmx.net wrote:

...

...

Why would you bother when you can buy something way better & faster for cheap these days?

Why would you bother updating when it works just fine? And even the cheapest system I could buy today is still more expensive than keeping what I have now.

Well obviously when your ancient pc can't handle new things such as h264 decoding and HDTV, and no manufacturer is willing to waste their money making a hardware decoder card, I would say it's not working just fine as you claim. Sorry, a small handful of people using ancient pc's for dvb is not even vaguely enough for manufacturers to create h264 hardware decoder cards. And even if they did actually bring one to market, meaning you can BUY it and not just look at it on a website, the cost would be too much.

I'm sure it seems strange to you that people are using decoder hardware if the CPU can easily do it.

BUT

All people having an FF card or dxr3 or em84xx are using exactly something like this. Count users using such a setup and count people using softdevice etc pp setup, i'm sure the people with soft decoding are the minority (or at least lesser then the first group).

If there's such a market for hardware decoding, where are all the cards? How come manufacturers aren't jumping at the chance to capture the profits from people like you with old slow pc's in need of such cards?

marketing doesn't allways recognize market demands, but tries to create demand for their ideas ...

As i said it's obvious that this idea sounds strange to you - but that doesn't mean that its a bad idea. I don't have exactly an ancient setup (Turion ML30+500MB RAM) but why i should burn CPU cycles all the time for wathcing TV if a hardware card can do it far more effecient ? And the power left over can sure be used for streaming, converting and so on.

What about a simple multimedia networking device like the Mvix www.mvixusa.com

They appear to have a live community in open source development for the device. Would have been nice if the device had the sigma EM8623L and not the EM8621L, the 21L doesn't support H.264 decoding :(

This would make nice VDR client (add-on) without having to upgrade your current hardware. I would recommend a device _like_ this to Klaus for development purposes. The TVix appears to have the EM8623L chip, but I can't find any references to open source development community.

Theunis

Klaus Schmidinger wrote:

On 11/18/07 18:31, Magnus Hörlin wrote:

...

Klaus Schmidinger wrote:

...

Maybe it actually is about time for me to build a new VDR. I'll probably take a look at the Reel Extension HD PCI. But that means I'll also need a new motherboard with at least five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD). On my desktop PC I'm using a passively cooled Pentium M with 1.86GHz, which works really good, so maybe that's also a viable choice for a new VDR. I guess it goes without saying that modern motherboards have a gigabit Ethernet port and graphics on board. Does anybody have a recommendation for such a board?

Well, of the 643 modern mainboards for sale in Sweden (by modern I mean S775 and AM2), none combine five PCI slots with integrated graphics. Do you need a GPU if the Reel card works?

Well, I guess you'll need some sort of console when installing the system, so some basic graphics would be nice. Don't know if the HD-E acts as a graphics card.

Klaus

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

I simply stick an old PCI grapics card I bought for one euro on e-bay in my server if I need to do something that requires a local display, but integrated graphics is better of course. The closest modern match would be Gigabyte GA-M61P-S3. You'll get four PCI, GbEthernet and graphics on board. Then you could buy a low-power 33-Euro CPU like the LE-1100, but you would have to live with a USB DVB-T card. The Nova-T Stick works well for me with latest drivers.

/Magnus

On 11/18/07 19:47, Darren Salt wrote:

I demand that Klaus Schmidinger may or may not have written...

[snip]

...

Maybe it actually is about time for me to build a new VDR. I'll probably take a look at the Reel Extension HD PCI. But that means I'll also need a new motherboard with at least five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD).

ECS nForce3-A and -A939? Not exactly current, but they both have 5 PCI slots and an AGP slot (anything up to x8).

But AFAICS unfortunately no gigabit Ethernet (which I'd like have in order to record to my server).

Klaus

On Sun, Nov 18, 2007 at 11:32:47PM +0100, Segers,Jan J.K.T. wrote:

how about the ASUS P5GC ?

hi

i bought the p5gc recently; it is the only board with 6x PCI, but without onboard graphics.

the only problem so far is the onboard realtek 8169 NIC -> works not with the ubuntu 7.10 default kernel! (the latest git kernel should work -> not tested yet)

but to something differnt:

i think it is crucial to buy something with a amd/ati r500/r600 as graphic chip; i expect that amd releases soon the docs to decode h.264 on the GPU! (avivo) and with this, it should be very cheap option for a dvb-s2/hdtv vdr!

mfg hermann

On 11/19/2007 11:01 AM, Hermann Gausterer wrote:

On Sun, Nov 18, 2007 at 11:32:47PM +0100, Segers,Jan J.K.T. wrote:

...

how about the ASUS P5GC ?

hi

i bought the p5gc recently; it is the only board with 6x PCI, but without onboard graphics.

Well, I can plug a graphics card into that extra PCI slot.

the only problem so far is the onboard realtek 8169 NIC -> works not with the ubuntu 7.10 default kernel! (the latest git kernel should work -> not tested yet)

That's a real pitty. I wonder if it will work with the default SUSE 10.3 kernel...

Klaus

On 11/19/07 11:35, Ales Jurik wrote:

On Monday 19 of November 2007, Klaus Schmidinger wrote:

...

...

i bought the p5gc recently; it is the only board with 6x PCI, but without onboard graphics.

Well, I can plug a graphics card into that extra PCI slot.

There is also one extra PCIEx16 slot.

...

...

the only problem so far is the onboard realtek 8169 NIC -> works not with the ubuntu 7.10 default kernel! (the latest git kernel should work -> not tested yet)

That's a real pitty. I wonder if it will work with the default SUSE 10.3 kernel...

On Asus web there are drivers for linux (LAN, Audio) which are tested for kernel 2.6.21 and 2.6.22 - the need is kernel source and gcc.

The default SUSE 10.3 kernel comes with an r8169.ko module, so I would guess it should work.

Klaus

On 11/19/07 21:57, Michael Möhle wrote:

...

The default SUSE 10.3 kernel comes with an r8169.ko module, so I would guess it should work.

This is correct, with a small Bug: http://en.opensuse.org/SDB:Realtek_8169_driver_problem

Ok, that's not a real problem (at least for me) ;-)

Klaus

On 11/18/07 23:32, Segers,Jan J.K.T. wrote:

...

But AFAICS unfortunately no gigabit Ethernet (which I'd like have in order to record to my server).

how about the ASUS P5GC ?

Well, looks like the ASUS P5GC is going to be the board for my new-to-build VDR:

http://de.asus.com/products.aspx?l1=3&l2=11&l3=498&l4=0&mode...

So the next question is: which CPU to use?

http://support.asus.com/cpusupport/cpusupport.aspx?SLanguage=de-de&model...

lists all the CPUs this board supports, and since they are probably all way faster than I'll actually need, it's probably best to use the one with the lowest power consumption. Does anybody know which of these has the lowest power requirements? Or can point me to a source where I can find that information?

Klaus

So the next question is: which CPU to use?

http://support.asus.com/cpusupport/cpusupport.aspx?SLanguage=de-de&model...

GC

lists all the CPUs this board supports, and since they are probably all way faster than I'll actually need, it's probably best to use the one with the lowest power consumption. Does anybody know which of these has the lowest power requirements? Or can point me to a source where I can find that information?

Klaus

Hi,

From what I have read over the last few months I would recommend either the

Core 2 Duo E4300 (1.8GHz,800FSB,L2:2MB,65W,rev.L2) or the Pentium Dual Core E2140(1.6GHz, 800FSB, L2 1MB, rev.L2)

Daniel

It should be noted that Core Duo and Core 2 Duo are not the same. Core 2 Duo uses the new architecture while Core Duo does not. Unless the price difference is drastic between your considerations, I would absolutely go with the Core 2 Duo.

The Pentium Duo I referred to is not a Core Duo but a Pentium Dual Core[1] "These closely resembled the Core 2 Duo E4300 processor with the exception of having 1 MB L2 cache instead of 2 MB"

We are talking here about a 55€ E2140 vs. 100€ E4300. So yes I would say the price difference is considerable while the difference in performance will likely be negligible in a vdr environment.

[1] http://en.wikipedia.org/wiki/Pentium_E

Daniel

Daniel Heuwinkel wrote:

Pentium Dual Core E2140(1.6GHz, 800FSB, L2 1MB, rev.L2)

These have quite advanced thermal protection, so it should work well with passive cooling.

http://www.tomshardware.com/2007/09/27/what_if_your_cpu_cooler_fails/

On Wednesday 21 of November 2007, Klaus Schmidinger wrote:

lists all the CPUs this board supports, and since they are probably all way faster than I'll actually need, it's probably best to use the one with the lowest power consumption. Does anybody know which of these has the lowest power requirements? Or can point me to a source where I can find that information?

Klaus

Hi Klaus,

see for ex. http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors

Rgds,

Ales

On 18.11.2007 17:01, Klaus Schmidinger wrote:

Maybe it actually is about time for me to build a new VDR. I'll probably take a look at the Reel Extension HD PCI. But that means I'll also need a new motherboard with at least five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD). On my desktop PC I'm using a passively cooled Pentium M with 1.86GHz, which works really good, so maybe that's also a viable choice for a new VDR. I guess it goes without saying that modern motherboards have a gigabit Ethernet port and graphics on board. Does anybody have a recommendation for such a board?

There exist PCIe -> PCI converters, the one my local dealer offers converts one PCIe to 4xPCI. (Price-point is about 150 EUR IIRC)

AFAIK there are no specific limitations to which PCI-card can be used in that thing.

So it shouldn't be a problem to get enough PCI-Slots even with recent mainboard that mainly have 3/3 PCIe/PCI and last but not last 1 PEG.

Bis denn

PCI-Express has nothing to do with PCI, they're different slots. I'm selling hardware, and as I said before, current motherboards does not have 5 PCI slots. The last boards with 5 PCI slots were these: Asus P5P800, with AGP port, socket 775 on board 10/100 LAN, DDR 1 support. I have couple of these on stock, we're using them for servers where we need a lot of Ethernet ports. You will not find on any PCI-Express board 5 PCI ports, unless it is a server dedicated, expensive board.

István

Füley István wrote:

PCI-Express has nothing to do with PCI, they're different slots. I'm selling hardware, and as I said before, current motherboards does not have 5 PCI slots. The last boards with 5 PCI slots were these: Asus P5P800, with AGP port, socket 775 on board 10/100 LAN, DDR 1 support.

Similar is Asrock AM2NF3-VSTA, 5 PCI, 1 AGP Socket AM2, lan 10/100

The point is that Klaus has very strict demands on code quality, and many patches never get up to that quality level. Thanks to that strictness, the VDR sources are relatively clean and straight implemented, and we're pleased with frequent rock-solid so-called 'developer' releases.

That is very good point for end user to know that he compiled ideal source. There is some lack of very useful features, but the source is ideal. Sorry for sarcasm :))

...

Big part of VDR's community also want to "own" it. By ownership I mean here decision making and commiting to CVS/SVN/HG.

I've never seen an open source project where everyone is allowed write access to software repositories. There's always a very small group of people with write access, and any changes go through a strict review process before they're accepted.

I've also told about this, about the group of authorized developers.

But my point was not only authorized developers. My point was make more than one decision maker. I was really disappointed reading Klaus's decision not to do anything in H264 field only because he don't needed it (at least now). And this was not the only one feature that what denied or delayed because of this reason (remember how much time takes migration to 2.6.* kernels ;)

In the end, what we could really need, are some developers that are persistent enough to develop their patches to a point where Klaus agrees to take over the patch as it is, without the need to do it any better.

How developer should be motivated to do his job, if there will be "exam of his skills" at the end by only one man with his own vision of quality of code and what is needed for project and what not? ;)

As I see there are people in this group who wants to participate in this development. But the rules of this process should be more clear and open. IMHO.

And the only thing that I think that could help in VDR development is a public bug tracking system, where bugs and feature requests could be developed to quality patches.

Exactly. And also voting system, what features are more needed for community, what less.

But o.t.o.h. what stops us from doing this in the mailing list?

IMHO this will not work good, because of much reasons like you have to track mailing list and so on, it will be easier to to check such bugtracking/voting system from time to time.

P.S. Again, nothing personal. I'm only talking about the process.

On 11/17/07 23:07, Pasi Kärkkäinen wrote:

On Fri, Nov 16, 2007 at 06:29:55PM +0100, Klaus Schmidinger wrote:

...

On 11/16/07 17:32, Gregoire Favre wrote:

...

On Fri, Nov 16, 2007 at 08:20:38AM -0800, VDR User wrote:

I didn't try vdr-1.5.11 because there is no H.264 patch for it.

I really don't understand why they are not investigated to be intregrated into vdr at this time as more and more TV are going to go to H.264 (not all in HDTV).

The answer is very simple: I'm currently working on other things.

And as long as there isn't at least a (graphics) card that supports decoding the "good old" MPEG2 in a quality that is at least as good as that of the FF DVB cards, as well as decoding H.264/HDTV in *hardware*, this whole area has next to no priority for me. I am not interested in software decoding this stuff - I don't want to have an extra heater in my living room ;-)

http://www.reel-multimedia.de/shop/product_info.php?products_id=223 http://www.reel-multimedia.com/rmm-english/pdf/produkt-flyer/extension_hd.pd...

I don't know if that card is actually available or not, but worth checking out anyway..

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?

Klaus

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.

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 2 1

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 ;-)

On 11:29:29 Nov 18, Klaus Schmidinger wrote:

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?

Sorry if I am hijacking this thread.

I was wondering what sort of driver support will be necessary for providing optical audio out and HDMI video output.

I understand that HDMI also support audio output but I am mainly interested in knowing if there will be some support necessary at the driver level.

Any reference documentation or specifications will help a lot.

Thanks in advance.

Best, Girish

support within VDR. More and more channels will start using it (not necessarily HD channels either, H264 increases the bandwidth of the satellite platform) and there is already plenty of fine content out there. E.g. the Premiere HD channels, Sky UK HD channels and the bouquet of HD channels on Thor (Canal Digital). The Polish HD channels are already improving and there will be HD channels as part of Digitalb in December. It has now gone behind demonstration loops and if you check out Kingofsat's website you will see there is now an abundance of channels from different providers.

please, don't forget about Russian :) http://lyngsat.com/europe.html

22 open h.264 channels with standard definition from Express 40E + 25 irdeto h.264 channels from Rikor with SD on Intelsat 904 at 60.0°E + 4 hdtv via-channels from Eutelsat Sesat & W4 at 36.0°E

I hope the VDR will have good hdtv-future

Igor

Hi,

Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck?

Regards,

Y.

Luca Olivetti schrieb:

En/na Graziano Pavone ha escrit:

...

I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..)

A nice feature that vdr-xine has over xineliboutput, is that it automatically sets itself as the primary device when a connection comes, and when the connection is closed it restores the previous primary device. This way I can either watch locally with the dxr3-plugin or remotely with vdr-xine.

I experienced the same with xineliboutput.

A very interesing feature of xinelibout is the ability to control deinterlacing, color settings etc. from within the VDR OSD in the plug-in´s settings. Furthermore, xineliboutput has a function that cuts and scales letterboxed 16:3 to anamorph 16:9, there is an audio equalizer and much more...

With kind regards

Jörg Knitter

Reinhard Nissl wrote:

Hi,

Jörg Knitter schrieb:

...

...

...

I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..)

A nice feature that vdr-xine has over xineliboutput, is that it automatically sets itself as the primary device when a connection comes, and when the connection is closed it restores the previous primary device. This way I can either watch locally with the dxr3-plugin or remotely with vdr-xine.

I experienced the same with xineliboutput.

A very interesing feature of xinelibout is the ability to control deinterlacing, color settings etc. from within the VDR OSD in the plug-in´s settings. Furthermore, xineliboutput has a function that cuts and scales letterboxed 16:3 to anamorph 16:9, there is an audio equalizer and much more...

Well, that's the cleaner approach of suppling an own frontend. I didn't want to write an own frontend. But my xine plugin has to act like a frontend within any other frontend and therefore requires some xine-lib patches to prevent deadlocks.

I may have misunderstood what you meant with frontends, but xineliboutput *can* be used with other xine frontends, such as xine-ui, without patching xine-lib.

Sure,

Standard FC 7 (I will soon upgrade it to FC 8) modified version of iwconfig to allow wpa-psk(2) to work Xine-lib cvs (v1.1.6) vdr-sxfe or vdr-fbfe as needed

I'm using Ubuntu, with wired ethernet. connection So both framebuffer and xorg with xineliboutput are working? Did you compile them yourself, or there are binaries qavailable for Fedora? What about CPU usage. Is the PS3 able to display everything smoothly (with and without the OSD)?

The PS3 is connected to a SD TV set.

As you can see it is not something complicated. Apparently when trying the

same thing with HD (720p/1080p) television gives better result. (talking about picture quality) To enhance the picture quality on a SD TV you can deinterlace in sw before displaying the picture. The drawback is that an interlaced source is de-interlaced then interlaced again to coop with PAL standard.

My PS3 is connected to a 720p display, so this should not be a problem... if it's not a problem for CPU usage...

I did put this project on hold until better fb or xv support is popping up ;-) May be you will also be interested to have a look here:

http://forums.ps2dev.org/viewtopic.php?t=8364&postdays=0&postorder=a...

thanks for all the informations!!

Ciao, Graziano

On Tue, Nov 13, 2007 at 03:41:05PM +0100, alexw wrote:

On Tuesday 13 November 2007 15:16:32 Graziano Pavone wrote:

...

...

Hi,

Using my PS3 as a vdr client is also my target. But I experienced bad (de-)interlacing when watching SD TV using SD output (even with right resolution). I am now waiting the new HV xorg driver to have more control on the video than the already available fb blit mechanism. I did rewrite the fb driver of xinelib to enhace it with ps3 blit functionality and virtual fb but it did not improve the output quality. By the way, the PS3 have a colorspace issue to display the OSD with proper color palette under the fb. (X is not affected by this)

Actually I am using streamdev and xineliboutput together. Xineliboutput is good to pilot the server side from any linux based system. Streamdev + FF card + vdr is the best deal for client device (I am using this solution over wifi and it works like a charm) Streamdev + m3u patch is ideal to use VLC with playlist and allow Win OS to access the TV programs.

Hi, I would like to use my PS3 as vdr client as well. I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..)

Can you give more details of what are you using on your PS3?

Thanks, Graziano

Sure,

Standard FC 7 (I will soon upgrade it to FC 8) modified version of iwconfig to allow wpa-psk(2) to work Xine-lib cvs (v1.1.6) vdr-sxfe or vdr-fbfe as needed The PS3 is connected to a SD TV set.

As you can see it is not something complicated. Apparently when trying the same thing with HD (720p/1080p) television gives better result. (talking about picture quality) To enhance the picture quality on a SD TV you can deinterlace in sw before displaying the picture. The drawback is that an interlaced source is de-interlaced then interlaced again to coop with PAL standard.

If you do that (deinterlace, then interlace again) you lose half of the "framerate" if you're using normal plugins for deinterlacing..

interlaced tv is 50/60 fields/sec, and after deinterlacing you usually end up with 25/30 frames/sec.. half of the "motion/movement information" just disappeared.

end result is that your live video (series,sports,news) starts to look like jerky and shaky..

If you have interlaced output best option would be to display each field as it comes in (1:1).. then you would get "best possible" quality.

If you have progressive display device, then best option is to use "full-fps" deinterlacing, meaning 50 fields/sec ends up 50 frames/sec, or even 100 frames/sec containing all the motion/movement info..

-- Pasi

On Wed, Nov 14, 2007 at 01:52:28PM +0100, alexw wrote:

On Wednesday 14 November 2007 13:19:39 Pasi Kärkkäinen wrote:

...

On Tue, Nov 13, 2007 at 03:41:05PM +0100, alexw wrote:

...

On Tuesday 13 November 2007 15:16:32 Graziano Pavone wrote:

...

...

Hi,

Using my PS3 as a vdr client is also my target. But I experienced bad (de-)interlacing when watching SD TV using SD output (even with right resolution). I am now waiting the new HV xorg driver to have more control on the video than the already available fb blit mechanism. I did rewrite the fb driver of xinelib to enhace it with ps3 blit functionality and virtual fb but it did not improve the output quality. By the way, the PS3 have a colorspace issue to display the OSD with proper color palette under the fb. (X is not affected by this)

Actually I am using streamdev and xineliboutput together. Xineliboutput is good to pilot the server side from any linux based system. Streamdev + FF card + vdr is the best deal for client device (I am using this solution over wifi and it works like a charm) Streamdev + m3u patch is ideal to use VLC with playlist and allow Win OS to access the TV programs.

Hi, I would like to use my PS3 as vdr client as well. I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..)

Can you give more details of what are you using on your PS3?

Thanks, Graziano

Sure,

Standard FC 7 (I will soon upgrade it to FC 8) modified version of iwconfig to allow wpa-psk(2) to work Xine-lib cvs (v1.1.6) vdr-sxfe or vdr-fbfe as needed The PS3 is connected to a SD TV set.

As you can see it is not something complicated. Apparently when trying the same thing with HD (720p/1080p) television gives better result. (talking about picture quality) To enhance the picture quality on a SD TV you can deinterlace in sw before displaying the picture. The drawback is that an interlaced source is de-interlaced then interlaced again to coop with PAL standard.

If you do that (deinterlace, then interlace again) you lose half of the "framerate" if you're using normal plugins for deinterlacing..

interlaced tv is 50/60 fields/sec, and after deinterlacing you usually end up with 25/30 frames/sec.. half of the "motion/movement information" just disappeared.

end result is that your live video (series,sports,news) starts to look like jerky and shaky..

If you have interlaced output best option would be to display each field as it comes in (1:1).. then you would get "best possible" quality.

If you have progressive display device, then best option is to use "full-fps" deinterlacing, meaning 50 fields/sec ends up 50 frames/sec, or even 100 frames/sec containing all the motion/movement info..

-- Pasi

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Hi,

I did test 1:1 output (PAL 720x576 -> 720x576) but due to bad VSYNC the output is shaky. The kernel API provided for the vsync is not working very well with SD content. Unfortunately I do not have a progressive display.

Hmm, how did you try that? with what software/plugins?

Remember that you need to sync each _field_, not frames.. so you need to update your output 50 times a second and your output device needs to support updating/syncing fields separately...

each incoming field needs to go out in the same order.

-- Pasi

Le mardi 13 novembre 2007 à 14:50 +0000, Darren Salt a écrit :

...

• it doesn't require me to recompile libxine

Neither does vdr-xine (if you're using xine-lib-1.2).

affirmative! I am running xine-lib-1.2 and vdr-xine 0.8.0 at last no more messing with patching xine-lib!!!!

My problems:

- something is turning down PCM volume on startup (not xine because when I run xine alone the volume isn't changed) - I have strange xine lockups which I think may be related to the version of the openchrome driver I am running - they are window manager related such as switching from one desktop to another when live TV is running and moving TV windows around

Cheers

Tony