[vdr] UK users - multiple BBC One/Two/News in channels list
Hi, Been a while since I've used VDR. Have it setup after scanning using the scan program, however something is strange. There are multiple versions of some channels, such as BBC One/Two/News, Channel 4 etc. Some of these either have video and no EPG, have video and EPG, or have EPG and no video... Obviously what I'm looking for is the video the EPG - this works for BBC One, but when I tune to the BBC Two which has the EPG visible, I receive no signal found message. If any UK users have a cluestick on how to fix this, please let me know. It seems like VDR is updating the channels.conf but not merging the information, because a fresh scan using dvbutils does not show multiple versions for the same channel. Any help appreciated.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK users - multiple BBC One/Two/News in channels list
On 3 November 2010 20:48, Luca Olivetti l...@ventoso.org wrote: Al 03/11/10 21:31, En/na Alasdair Campbell ha escrit: There are multiple versions of some channels, such as BBC One/Two/News, Channel 4 etc. Some of these either have video and no EPG, have video and EPG, or have EPG and no video... Obviously what I'm looking for is the video the EPG - this works for BBC One, but when I tune to the BBC Two which has the EPG visible, I receive no signal found message. Terrestrial or satellite? Sorry forgot to say - it's Terrestrial. I'm not really sure, but the issue should be the same in both cases: the service id should be sufficient to identify a channel, regardless of the transponder, but since some broadcasters reuse the same id in more than one transponder, vdr uses both the transponder and the service id to differentiate channels. The result is that when a channel changes transponder (like the uk channels recently did), vdr would probably find a new channel instead of replacing the tuning data of the existing one. Ah so, the initial tuning file I'm using from dvbutils is out of date, and VDR finds the new transponders instantly? Well, I think there should be a better way, but the only current option is to let vdr update all channels and manually delete the old, non working ones. I've left VDR set at Add New Transponders which presumably is the most promiscuous mode, and will see what it comes up with over the next hour or so. Thanks for the reply! Bye -- Luca ___ 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] UK users - multiple BBC One/Two/News in channels list
On 3 November 2010 23:18, Torgeir Veimo torg...@netenviron.com wrote: From memory, I think the frequencies in channels.conf ends up being 166khz off the actual frequency. I remember having to tweak the channels.conf file manually, then turn off automatic updates. Can you post your file here? After leaving it for a few hours this is what I have, note BBC ONE at the very bottom, the EPG is available here but no video stream, same with BBC TWO elsewhere. channels.conf attached (hope attachments are allowed on this list!) channels.conf Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
Lauri Tischler wrote: Füley István wrote: Oops, that's really not so good... one can't comment about HDTV with a resolution which is not full HDTV : 1920x1080... Ok, this means that my setup is a low-end instead of being average as I stated before, therefore my considerations about HDTV was totally wrong. But to buy a 1000+ Euro TV set? That's another reason for me to stay SD. Not really, FullHD also means large, minimum 42, it is quite senseless to to watch good picture on a postcard, so you start at €1500 You forgot to add the €20,000 building an extension to your house, if you don't want your living room to be dominated by a 42 diagonal piece of plastic. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
Lauri Tischler wrote: Alasdair Campbell wrote: Lauri Tischler wrote: Not really, FullHD also means large, minimum 42, it is quite senseless to to watch good picture on a postcard, so you start at €1500 You forgot to add the €20,000 building an extension to your house, if you don't want your living room to be dominated by a 42 diagonal piece of plastic. Thats peanuts, considering you spend the same amount for cables alone http://www.pearcable.com/sub_products_anjou_sc.htm 'Made in the U.S.A. for superior quality' - Don't matter where you make it, it better be good quality at $500 a foot. Highly recommended - Dave Clark In extended listening sessions, I found the cables' greatest strength to be its PRAT. Simply put these are very danceable cables. Music playing through them results in the proverbial foot-tapping scene with the need or desire to get up and move. - Dave Clark What the fudd is he talking about? PRAT? Danceable? Ain't that the musician's responsibility? I wonder what sort of cable the engineer was using when he mixed the album. Someone explain to me how these cables are more 'honest' than the rest. Okay so the Anjous are rather pricey at $2750 for a meter pair, but they are impeccably built, sound quite nice, and should keep you happy for a quite a while. Sound quite nice AND well built? Where's my credit card..? Will I ever be happy with my speaker cables? Do I want to be happy?!? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
VDR User wrote: On Nov 22, 2007 7:30 AM, Füley István [EMAIL PROTECTED] wrote: To be clear: I did not say, that we don't need HD at all. I just said, that normal TV stations should stay in SD, and only a couple of premium (PPV, etc) channels should go HD. But the situation is more clear: not me is gonna be who decide the future of television but the market :) If HD is no better or not real increase in quality then why switch from SD at all? If it's not any better then how have these providers, hardware makers, etc. all tricked s many people into believing HD -IS- better quality? Maybe it's simply because it is and all the user needs as proof is his own two eyes. Like it or not HDTV is here to stay, and it's taking over. H264 is here to stay. Change is nothing to be scared of, especially when it's for the better. The only thing scary about it is being left behind and wishing you would have done something about it sooner. Btw, do you still prefer music on cassette tape? ;) (just kidding) I certainly prefer listening to music on dmm 180g vinyl to a poorly mastered compact disc, and I've never seen a cheap CRT look anywhere near as bad as some LCDs I've seen over the years.. Shops in Britain kept the CRT and LCD displays apart, so shoppers with a limited short term memory failed to notice the washed-out colour and lack of black in the BULK of lcd TVs sold in the last 5 years. Now there's fortunatly no CRTs to compare with. (I understand the contrast on the latest FullHD tvs can be superb). I do believe HD for films, concerts wildlife docs must be amazing to watch, but as it is terrestrial HD in the UK is still two years away, and will require DVB-T2 receivers. At the point when my cards stop receiving a signal I might start worrying about being 'left behind'. UK Terrestrial HD plans: http://www.ukfree.tv/fullstory.php?storyid=1107051325 SD bitrates to be reduced, 3 HD channels for 9 hours a day, more people without a proper signal. Progress! and a few billion pounds in OFCOM's coffers. (To be paid off by people replacing their IDTVs and set top boxes on redundancy..) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
Beside all that, I do believe VDR needs to integrate H264 HD recording, along with support built-in for multiple frontends. Hopefully I can lend a hand with the coding (in about 6 years). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On Nov 18, 2007 9:54 PM, Klaus Schmidinger [EMAIL PROTECTED] wrote: On 11/18/07 19:16, Alasdair Campbell wrote: On Nov 19, 2007 2:08 AM, Halim Sahin [EMAIL PROTECTED] 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] File play problem..
On 21/08/07, JJussi [EMAIL PROTECTED] wrote: And how you do that with Gentoo... If I change something, gentoo compile process will notice that.. Suspend the emerge just after the source has been unpacked and any patches applied. Might take you a couple of times to get it just before it starts compiling, but at least this is a way to try out changes before you confirm it all works and write your own ebuild. The file to edit should be here: /var/tmp/portage/media-plugins/vdr-xineliboutput-1.*.*/wor k/xineliboutput-1.*.*/Makefile ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Configuring vdr-sxfe to use a single vdr backend for recordings/dvb cards
On 18/06/07, Alasdair Campbell [EMAIL PROTECTED] wrote: On 16/06/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote: Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc? Yes. Then you don't need the -D option. The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server. This is more complicated :) I think you need to set every timer manually to the system where it is supposed to be recorded. Timersync won't work as it disables all recording at client(s). Using timersync and enabling recording at the client won't work if you use streamdev: both systems will see the same channels and would record the same timers in paraller. Maybe something like this might work: VDR1: (2x DVB-?): streamdev-server, streamdev-client connected to VDR2 VDR2: (1x DVB-S): streamdev-server, streamdev-client connected to VDR1 VDR3: (no DVB): 2 instances of streamdev-client: one connected to VDR1 and another to VDR2. Note that circular streamdev setup doesn't work without patching ( http://www.vdr-developer.org/mantisbt/view.php?id=198 ) If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible... No, but transferring the device interface (/dev/dvb/...) over network is possible with something like nbd (network block device). I think I saw similar redirector for DVB devices few years ago: http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html But it seems quite old and unmaintained. I remember reading about this years ago, if it could work then it would be ideal for my situation - maybe for others too. Vadim Epmak's address is bouncing so I'll ask on the DVB mailing list and see if anyone else ever got it up and running. I'm keen on trying it out myself, and have started reading about porting drivers to 2.6 kernels. Could be an interesting way to learn more C ;-) In hindsight, I believe learning C on my own by porting a driver to the 2.6 kernel was a tad optimistic.. Sill won't compile, and I haven't got to grips with the changes in the dvb api from when this was written. No response yet on the linuxtv list. I'll keep working at the code - it could be a fun way to learn, and the principle seems quite straight-forward. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Configuring vdr-sxfe to use a single vdr backend for recordings/dvb cards
On 09/06/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Sat, 2007-06-09 at 18:15 +0100, Andrew Herron wrote: I have several networked vdr machines that i want to use to connect back to the 'server' vdr machine. The networked vdr machines will have no dvb cards (they will all be located at the vdr server). How do i configure my vdr client machines to connect back to the server vdr machine and use its dvb cards/recording storage etc? Can anyone give some guidance on this type of setup or point me at a url where I can find out about such a config? If you don't watch different recordings / channels at the same time you can just run vdr-sxfe at each client and connect to the single VDR server. You'll get same video + OSD mirrored to all locations. But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server: - less maintenance, only one installation of VDR and plugins required - allows using diskless clients (and with less memory) - Faster cutting / DVD burning / ... as there is no network between VDR and disks - no need to export/mount /video to every client - ... Here's how I do it: master VDR: DVB cards, recordings, server for client 1: vdr -c /etc/vdr \ -Pxineliboutput --local=none --remote=37890 \ -Pstreamdev-server server for client 2: vdr -c /etc/vdr2 \ -D 10 \ -Pxineliboutput --local=none --remote=37892 \ -Pstreamdev-client server for client 3: vdr -c /etc/vdr3 \ -D 10 \ -Pxineliboutput --local=none --remote=37894 \ -Pstreamdev-client + other options / plugins you normally use. Using -D 10 option for client VDR instances forces all DVB cards for master VDR. Streamdev plugin is used to provide live view for client VDR's, it is not required to just watch recordings. You must use separate configuration directory for each VDR (-c option). Without it you'll most likely break all recordings (all VDRs record all timers in paraller to same recording directory). And at clients: Client 1: vdr-sxfe Client 2: vdr-sxfe xvdr://server ip:37892 Client 3: vdr-sxfe xvdr://server ip:37894 If you use RTP between vdr and vdr-sxfe, using separate RTP address or port for each xineliboutput server instance might be good idea. Also it might be good idea to disable recording at all but the master vdr. Recording the same timer on two VDR instances will most likely corrupt whole recording. Besides that, doing all recordings directly from DVB card (no streamdev in middle) makes things simpler and less error prone. It is probably even impossible to do several recordings from different transponders using single streamdev instance. I use timersync plugin to disables recording on client VDRs. All timers are still visible at each client and you can create/modify timers at any client just as before. Plugin synchronizes all modifications to timers between VDR instances and takes care that all recordings are made only by master vdr. Still, if you have some kind of autotimer plugins etc. that generate timers automatically it might be better to run those only at server vdr... This system is just what I'm looking to create, however I have one or two questions. (As usual..) Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc? The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server. If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible... There is currently no way for me to have all 3 DVB cards in the same box. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with two DVBS cards
On 13/06/07, Andrey Vlassov [EMAIL PROTECTED] wrote: Hi, could somebody point me in right direction? lots of useful info here: http://www.linuxtv.org/vdrwiki/index.php/Main_Page I am looking into configuring a second DVBS card to use with vdr. Configuration: Athlon 1.2GHz MB: ABIT Memory: 512MB OS: Mandriva 2006 vdr: 1.4.5 DVBS1: Nexus-S DVBS2: Twinhan 1025a At this time I use Nexus-S and it works fine. What modification/patches will require to make both cards work with vdr? Is there any documentation for this case? As far as I know, once you've confirmed both cards are being recognized and working independently of VDR - your first step - then VDR will require no changes other than 'number of DVB cards ' in the Setup menu. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with two DVBS cards
On 13/06/07, Klaus Schmidinger [EMAIL PROTECTED] wrote: There is no such option in VDR's Setup menu. Sorry, I was thinking of Primary DVB interface - something totally different.. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 25/05/07, Petri Hintukainen [EMAIL PROTECTED] wrote: Yes, patch against xine-lib 1.1.6 is available from http://phivdr.dyndns.org/xine-lib/directfb/ Thanks so much for that! I'll be able to try it over the weekend and I'll let you know how I get on. many thanks -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB unscalded OSD (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). I tried to give xine-lib1.1.2-r3 a go today but after rebuilding xineliboutput against xine-libs., I still receive the message [12674] [input_vdr] WARNING: Video output driver reports it does not support unscaled overlays ! - so maybe I need an older version of xine-lib?? Unfortunatly that version is as far back as I can go with gentoo, perhaps somebody with better skills could test an older version still. Theres a chance I made a mess of trying out the older xine-lib as now I have no video just sound :-) good thing my girlfriend is out for the day...! -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Markus Schuster [EMAIL PROTECTED] wrote: Well, this changes are more than 7 month old, maybe there have been some changes to DirectFB to make it work in the meanwhile... As far as I saw it's only a two line patch, so I could try to manually revert it and compile xine-lib again... Worth a go? :) I'd volunteer but I don't trust myself.. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Tony Houghton [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Alasdair Campbell wrote: Because I'm using a 550Mhz P3, my only option is to use the xineliboutput until I figure out what is causing the big CPU load variations. As I've never had softdevice successfully running on this television, I can't really say anything about it's quality, though I know there's been lots of work in respect to the matrox cards. Another alternative is to use the other vdr xine plugin with df_xine, which gives very good results with my Matrox (G450). About the only problem is that it sometimes doesn't scale the OSD correctly, chopping off the right hand side. Something to do with 16:9 vs 4:3 I'm sure. And I'm seeing something similar to that with More4 other less popular channels on UK DVB-T. The lower resolution or incorrect imprinted aspect ratio causes the OSD to zoom to the left two thirds, with the right third off screen. As this only happens on one or two channels that I watch, It's not bothering me too much. xineliboutput is exactly what I need at the moment, with my headless recording server and one streaming client - I wanted to control the server osd directly for now. I don't know whether it can handle letterboxing an interlaced 16:9 picture for a 4:3 TV. I heard that softdevice gets, or used to get that wrong, as if it treated the two fields as one frame and scaled them together, rather than scaling each field separately. Maybe the hardware doesn't support the latter, in which case it would have to use slow software scaling. When I was using softdevice I had a 4:3 TV, but wanted to view 16:9 content in full (so with black horizontal bars above and below video). With this setup, interlaced video would show artifacts. I believe that's been fixed by the kind softdevice guys. My experience with softdevice was that the A/V sync was a bit off for live TV and way off for recordings. df_xine is spot on. If you want to be able to stop/start df_xine and/or watch other videos all with one remote control you can use boxstar as a front-end. I had issues with audio sync with softdevice too, can't really say how it deals now, as I'm underpowered. So boxstar will give me direct control over VDR similar to xineliboutput? I hadn't realised that. At the moment I'm not looking to change my setup, just tweak what I have :-) (Sorry if the formatting on this email is all wrong, I'm writing this with lynx on the console, as my laptop is without X at the moment...) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB unscalded OSD (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 20/04/07, Markus Schuster [EMAIL PROTECTED] wrote:
Am Donnerstag, 19. April 2007 15:06:54 schrieb Alasdair Campbell:
config_xineliboutput
# field parity
# { none top bottom }, default: 0
#video.device.directfb_field_parity:none
That's funny, my config_xineliboutput doesn't have this config option per
default...
But I can insert it and when set to 'top' video quality is quite awesome, but
there are still some small hickups and stutters here and there (even with
vsync set to 1). Maybe some other settings are still missing, that softdevice
sets...
I've noticed problems with a couple of music video channels where
there's an effect similar to a stuck CD, surely related to field sync
but probably down to poorly transmitted content. I'm not experiencing
any problems with my favourite channels.
With Bloomberg (German news/stock channel) I see a very odd behavior: To have
to video itself fullscreen, I have to enable local frontend scaling but then
the OSD is renderd much too big. So I have to enable OSD resizing/downscaling
which results in a very unnice OSD (fonts look a bit ugly and the complete
OSD is not the nicest view.).
And channels broadcasting a 16:9 signal are always scaled up to my 4:3 CRT TV,
so I have the typical 'long faces' (I think that's only a configuration
setting, but I haven't been able to locate it...)
My experiences with a 16:9 TV are different but theres some issues
with scaling OSD that I would like to fix..
I don't want 4:3 content to stretch to my widescreen tv, so I set
Video Crop letterbox 4:3 to 16:9 - NO
OSD Everything here is set to NO or OFF
This isn't a bad setup, with 4:3 content, the OSD area shrinks
horizontally to 4:3 ratio, but the text stays nice and clear - I
noticed that any scaling of the OSD results in quite poor text.
However :-), I would prefer it if the OSD stayed at 16:9 resolution
all the time, with just the video layer beneath changing per content
aspect ratio. I'm not sure how I could cause this, or even it it's
possible with the framebuffer.
I'm currently not in a productive environment (that runs with a FF and VDR
1.26 :)) with software decoding, but from what I can say so long, using
DirectFB and the Matrox G450s TV-Out, softdevice is my personal favorite! I
think xineliboutput doesn't earn it's high version number in this 'special'
configuration.
BUT I have to admit that xineliboutput uses only half of the CPU power of
softdevice, so it's video decoder has to be more efficient...
Because I'm using a 550Mhz P3, my only option is to use the
xineliboutput until I figure out what is causing the big CPU load
variations. As I've never had softdevice successfully running on this
television, I can't really say anything about it's quality, though I
know there's been lots of work in respect to the matrox cards.
all the best,
--
A l a s d a i r C a m p b e l l
r a g a w u @ g m a i l . c o m
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 19/04/07, Torgeir Veimo [EMAIL PROTECTED] wrote: On 19 Apr 2007, at 09:41, Alasdair Campbell wrote: In the original post I was just wondering if xineliboutput has been written with the matrox specific instructions that softdevice's -vo dfb:mgatv uses. As I don't understand the difference between -vo dfb: -vo dfb:mgatv I can't really say what difference this would make. I belive this is entirely dependent on what xine instance you're using with xinelib. Are you using df_xine? I think it should handle field parity correctly. I'm firing up df_xine now to see if there's any similarity. OK, playing a copy of some interlaced video with scrolling text (BBC News 24). Using df_xine -a 5:4 -l 0 -s -f top 001.vdr I get perfect output! This is what Markus and I are seeing for a few seconds before the field sync gets screwed With df_xine -a 5:4 -l 0 -s -f bottom 001.vdr The output is constantly like the stuttering video we're seeing most of the time. So somehow xineliboutput is losing field sync, should be a simple fix then... :-) Needless to say I have no audio, buts it just a configuration problem at my end. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Sorry for replying to myself, but in the meantime, while waiting for xineliboutput to work again, anyone reading know if I can use df_xine for the video display, while retaining xineliboutput as the lirc transport to my headless server running vdr-xineliboutput. ** I know there has been a tremendous amount of work from everyone in respect to Matrox TV-Out already, sorry to keep bugging you all ;-) ** -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
ignore that, I was being an idiot, set to 'top' now. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Can vdr-xineliboutput utilize the excellent interlaced output of a Matrox G450 with VGASCART cable? I'm seeing what I can only describe as video stutters/shakes with interlaced video and quick movements, long camera pans. Using latest vdr-xineliboutput, DirectFB-1.0.0 xine-lib-1.1.5 using Gentoo ebuilds. Otherwise xineliboutput is working fantastically! (well without any sound but that's another issue for another day :-) ) -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
