Re: [vdr] Questions about good hardware to view VDR 4K
Hi, On Wed, May 08, 2019 at 09:20:30PM +0200, Frantisek Rysanek wrote: > Dear Karim, > > thanks for raising that point... > > At first I thought that the i3 "T" edition was somehow limited in the > graphics output, to make people buy the i7 - but no, if I look at > some mainstream i7 CoffeeLake CPU, the set of outputs is the exact > same spec: the CPU can produce 4k at 24 Hz only on the HDMI output > (TMDS framing), but can produce 4k at 60 Hz in the DisplayPort > format. To me this is slightly funny, because the "universal digital > display" outputs can do either DP or TMDS on the same port (the > format is configurable in software). > You need Intel "Icelake" CPU for 4K@60 support.. because that capability is only in the Intel Gen11 graphics, which will debut in Icelake CPUs. And Icelake is not out yet.. (and yes, Cannonlake/Icelake CPUs are some 4 years (or so) late at this point.. so the newer gfx capabilities were supposed to be launched already ages ago, but got delayed due to Intel "10nm process problems"..) -- Pasi ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR on Centos/RHEL6
On Wed, Jun 27, 2012 at 06:12:29PM +0200, Michael Schumacher wrote: make with this version resulted in a lot of errors. ---8--- Package freetype2 was not found in the pkg-config search path. Perhaps you should add the directory containing `freetype2.pc' to the PKG_CONFIG_PATH environment variable No package 'freetype2' found Package fontconfig was not found in the pkg-config search path. Perhaps you should add the directory containing `fontconfig.pc' to the PKG_CONFIG_PATH environment variable No package 'fontconfig' found font.c:19:10: error: #include expects FILENAME or FILENAME make: *** Deleting file `.dependencies' Package freetype2 was not found in the pkg-config search path. Perhaps you should add the directory containing `freetype2.pc' to the PKG_CONFIG_PATH environment variable No package 'freetype2' found Package fontconfig was not found in the pkg-config search path. Perhaps you should add the directory containing `fontconfig.pc' to the PKG_CONFIG_PATH environment variable No package 'fontconfig' found ---8--- and many more compiling errors in font.c. The package fontconfig-2.8.0-3.el6.x86_64 is installed, but I cannot find a package freetype2, so I am stuck now. yum search fontconfig yum search freetype So you need to: yum install fontconfig fontconfig-devel freetype freetype-devel -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR on Centos/RHEL6
On Mon, Jun 25, 2012 at 07:55:39PM +0200, Michael Schumacher wrote: Hi everybody, I am trying for some days to get VDR running on my recent home server. This machine is running CENTOS6. There are various compiling errors and I am starting to wonder if somebody went through the installation process successfully? Any feedback would be welcome. Well, paste the errors. First error messages are the most important. You're probably lacking some -devel rpms. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recent breakage of DVB subtitles with dxr3
On Thu, Mar 29, 2012 at 01:47:06PM +0300, Mika Iisakkila wrote: 28.3.2012 22:34, Pasi Kärkkäinen kirjoitti: The default audio mode of the em8300 device support utilities and kernel modules (em8300 and kmod-em8300-* packages) has changed from OSS to ALSA to follow upstream I googled your quote. Apparently it is from some Fedora release note from 2007 and I don't think it will help me a bit with an Ubuntu kernel from 2012, as the driver project has been forked, patched and merged a number of times after that. Yep, it was from Fedora. You could always check the Fedora src.rpm for any extra patches they might have there.. I'll gladly receive a current, relevant reference that will tell me how to use the em8300 drivers on current Ubuntu without recompiling the kernel. It takes 18(!) hours of CPU time on my VDR box. I think your best bet is to post to dxr3-de...@lists.sourceforge.net mailinglist, I think all (most) the em8300 developers are there.. Also, can we try and discuss the subtitling problem as well? Sorry I can't really help with that.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recent breakage of DVB subtitles with dxr3
On Sun, Apr 01, 2012 at 02:15:39PM +0300, Mika Iisakkila wrote: 1.4.2012 13:04, Pasi Kärkkäinen kirjoitti: Yep, it was from Fedora. You could always check the Fedora src.rpm for any extra patches they might have there.. I'll gladly receive a current, relevant reference that will tell me how to use the em8300 drivers on current Ubuntu without recompiling the kernel. It takes 18(!) hours of CPU time on my VDR box. I think your best bet is to post to dxr3-de...@lists.sourceforge.net mailinglist, I think all (most) the em8300 developers are there.. Well, I googled a bit more, and it seems the actual problem is in dxr3-plugin, not the drivers. The plugin is only able to use OSS (as of Dec.2008, anyway). I'm not willing to waste time fighting with semi-functional compatibility layers, so I'll just keep using my own kernel. Next time I'll configure out all the unneeded junk before compiling, though :D I'm pretty sure there is drx3-plugin version with ALSA support aswell! -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recent breakage of DVB subtitles with dxr3
On Sun, Apr 01, 2012 at 07:50:07PM +0300, Pasi Kärkkäinen wrote: On Sun, Apr 01, 2012 at 02:15:39PM +0300, Mika Iisakkila wrote: 1.4.2012 13:04, Pasi Kärkkäinen kirjoitti: Yep, it was from Fedora. You could always check the Fedora src.rpm for any extra patches they might have there.. I'll gladly receive a current, relevant reference that will tell me how to use the em8300 drivers on current Ubuntu without recompiling the kernel. It takes 18(!) hours of CPU time on my VDR box. I think your best bet is to post to dxr3-de...@lists.sourceforge.net mailinglist, I think all (most) the em8300 developers are there.. Well, I googled a bit more, and it seems the actual problem is in dxr3-plugin, not the drivers. The plugin is only able to use OSS (as of Dec.2008, anyway). I'm not willing to waste time fighting with semi-functional compatibility layers, so I'll just keep using my own kernel. Next time I'll configure out all the unneeded junk before compiling, though :D I'm pretty sure there is drx3-plugin version with ALSA support aswell! Yep, see dxr3plugin-users mailinglist archives for more information: [Dxr3plugin-users] [PATCH] Switch to the ALSA audio interface: http://sourceforge.net/mailarchive/message.php?msg_id=21665465 -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recent breakage of DVB subtitles with dxr3
On Mon, Mar 26, 2012 at 09:18:54PM +0300, Mika Iisakkila wrote: Quick data points with Finnish YLE DVB subtitles, using a dxr3: 1.7.22: everything works (never tried versions between here, because I was stuck with a 2.6 kernel back then) 1.7.25: subtitles are almost black and thus illegible 1.7.26: same thing 1.7.27: colours OK, but during live programming, maybe one of every 20 subtitles shows at all, and are about half the correct size. Same thing when viewing recordings made with this version - when I replay old recordings, all subtitles seem to get displayed. vdr-dxr3-plugin version 0.2.13 from here: http://projects.vdr-developer.org/projects/plg-dxr3/files em8300 drivers from here (cloned on March 17th, I think): hg clone http://dxr3.hg.sourceforge.net:8000/hgroot/dxr3/em8300 dxr3 System Ubuntu Oneiric, kernel 3.0.0-17 from Ubuntu sources (but recompiled by myself, because those nice folks at Ubuntu had to turn OSS support off in the kernel, preventing the em8300 drivers from working) I remember using alsa with em8300 already years ago? Was I dreaming? :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
On Fri, Aug 20, 2010 at 01:37:10AM +0300, Niko Mikkilä wrote: Thu, 2010-08-19 at 20:54 +0400, Goga777 wrote: Computer hardware usually cannot provide 50.000Hz, 59.940Hz or 23.976Hz outputs to your TV/Monitor. This will cause some judder on display output as MPEG/AVC input-stream is not synchronized to output framerate. do you mean that all nvidia vdpau cards with existing drivers from Nvidia can't provide exact 50.000Hz, 59.940Hz or 23.976Hz ?? There is no graphics card, BD/DVD player or other standalone device that outputs those rates exactly. I don't know how much they deviate, but I'd guess it's usually something like 0.01 % (50.005 Hz instead of 50 Hz), as Jori said. However, the rate doesn't need to match exactly because the display device is synchronized to the video signal. The rate could be 50.1 Hz or maybe even 51 Hz and the display wouldn't mind. 50 fps video files would play slightly faster, but there would be no need to drop video frames because of that. Things are more problematic when receiving live broadcast. Then the display and the video source (graphics card and software) needs to be synchronized to the broadcast to avoid dropping or duplicating frames. Set-top digital television boxes and FF DVB cards do that, but most graphics cards/drivers can't because they aren't designed to follow an external time source. Audio playback synchronation is another issue, and somewhat difficult to handle properly on a PC where the audio chip's clock is almost always separate from the graphics card's clock. By default, many media players time everything according to the audio clock, and therefore they need to drop/duplicate video frames every now and then. The other alternative is to drop/duplicate audio frames or resample the audio completely. I assume you guys are aware of projects like: http://frc.easy-vdr.de/ It was originally started to get perfectly synced RGB output from a VGA card (to PAL TV), just like from FF DVB card. I haven't really used that myself, but afaik they've been working on making that exact synchronization (variable framerate) possible with new HD/VGA/DVI outputs aswell. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] mini-PCIE with Broadcom Crystal HD Hardware Decoder (BCM970012) for HD playback with free drivers
On Sat, Jan 02, 2010 at 08:22:59PM +0300, Goga777 wrote:
what about of corrected interlace output ? Most of them videocards can't
do it correctly
I can't answer that unfortunately.
let's hope that Crystal HD can do deinterlacing and scaling
Yeah, and hopefully it can do full-fps deinterlacing, aka 50hz
interlaced stream to 50 fps progressive.
-- Pasi
in crystalhd/include/7411d.h there's lines
/* scaling on/off */
/* - eCMD_C011_DEC_CHAN_OUTPUT_FORMAT */
typedef enum
{
eC011_SCALING_OFF = 0x,
eC011_SCALING_ON= 0x0001,
} eC011_SCALING;
/* deinterlacing on/off */
/* - eCMD_C011_DEC_CHAN_OUTPUT_FORMAT */
typedef enum
{
eC011_DEINTERLACING_OFF = 0x,
eC011_DEINTERLACING_ON = 0x0001,
} eC011_DEINTERLACING;
/* deinterlacing on/off */
/* - eCMD_C011_DEC_CHAN_OUTPUT_FORMAT */
typedef enum
{
eC011_DEINTERLACING_OFF = 0x,
eC011_DEINTERLACING_ON = 0x0001,
} eC011_DEINTERLACING;
___
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] mdadm software raid5 arrays?
On Tue, Nov 17, 2009 at 03:34:59PM +, Steve wrote: Alex Betis wrote: I don't record much, so I don't worry about speed. While there's no denying that RAID5 *at best* has a write speed equivalent to about 1.3x a single disk and if you're not careful with stride/block settings can be a lot slower, that's no worse for our purposes that, erm, having a single disk in the first place. And reading is *always* faster... Example. I'm not bothered about write speed (only having 3 tuners) so I didn't get too carried away setting up my 3-active disk 3TB RAID5 array, accepting all the default values. Rough speed test: #dd if=/dev/zero of=/srv/test/delete.me bs=1M count=1024 1073741824 bytes (1.1 GB) copied, 13.6778 s, 78.5 MB/s You should use oflag=direct to make it actually write the file to disk.. #dd if=/srv/test/delete.me of=/dev/null bs=1M count=1024 1073741824 bytes (1.1 GB) copied, 1.65427 s, 649 MB/s And now most probably the file will come from linux kernel cache. Use iflag=direct to read it actually from the disk. -- Pasi Don't know about anyone else's setup, but if I were to record all streams from all tuners, there would still be I/O bandwidth left. Highest DVB-T channel bandwidth possible appears to be 31.668Mb/s, so for my 3 tuners equates to about 95Mb/s - that's less than 12 MB/s. The 78MB/s of my RAID5 doesn't seem to be much of an issue then. Steve ___ 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] Replay Problems with Extension HD
On Tue, Sep 08, 2009 at 09:17:30PM +0300, Pasi Juppo wrote: Petri Helin wrote: On Mon, Sep 7, 2009 at 6:57 PM, VDR Useruser@gmail.com wrote: I'd suggest posting to the mailing list or both as VDR Portal caters 99% to people who speak german and isn't much help for the very large english-speaking-only VDR community. I wouldn't say the english-speaking-only VD community is that large: At least if you look at the registered users: http://www.cadsoft.de/cgi-bin/vdr-counter.pl?action=statist Perhaps you meant the great non-german-speaking community, who communicate in English? ;) -Petri Didn't realize that there was such a database of users available. I'm pretty sure that _many_ of the VDR users are not aware of this thus statistics are probably not very accurate. Klaus should advertise this once in a while ;-) Yeah, I had not noticed this either :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
On Thu, Aug 27, 2009 at 03:04:04AM +0200, Thomas Hilber wrote: On Wed, Aug 26, 2009 at 03:40:25PM +0100, dave cunningham wrote: If I'm reading the patches correctly it seems that the ATI chips can currently do 720x576 only, where the Intel chips can be configured for 1440x576 and 1600x1200 only. for VGA2SCART (without FRC) Intel chips can be setup for 720x576i also. Hmm.. why without? FRC doesn't work on Intel @ 720x576i ? Just confused :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Tue, Aug 18, 2009 at 01:38:09PM +1000, Torgeir Veimo wrote: 2009/8/16 Goga777 goga...@bk.ru: I'm wondering - does the problem with timing and sync also important and for for vdpau nvidia cards ? or that project is important only for intel and ati ? Now that I think about it, I believe this is what I was really asking about.. is it perhaps that good LCD TVs have so much smoothing/deinterlacing processing circuitry that the interlace timing is less of a problem when provided by VGA or HDMI? but to run nvidia geforce 8/9 series cards with 1080i 50Hz mode is not so easy or could you run 1080i mode on vdpau card with good result ? You can't do it with the composite output (using the nvidia supplied breakout cables). You can do it using normal dvi/vga output though, and use a transcoder, or with a tv supporting rgbhv signalling, or just plain vga/dvi/hdmi. .. but you still have the problem of not being able to figure out the field order? See the other mail I sent to this thread.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Sun, Aug 16, 2009 at 05:38:47PM +0100, Gavin Hamill wrote: On Sun, 2009-08-16 at 20:16 +0400, Goga777 wrote: for you.. I believe it should be possible to get 50 fps progressive output from 50i material using vdpau deinterlacing. yes, my PCI Geforce 8400 card on GPU G98 can do 10...@50 but with the simplest bob deinterlacing only. I prefer to use more advanced deinterlacing algorithm - temporal_spatial or temporal. But with them I have jerky video Hm, do you think you were only able to use simple deinterlacing because of limitations in CPU speed, bus bandwidth (only PCI - I've been thinking about one of the 8400 GSs myself so I can play with it in my PCI-only VDR box..), or power within the G98 GPU itself? .. But you might get better results if you outputted 1:1 interlaced material using 1080i50 mode and let the LCD tv do the deinterlacing.. Yes, exactly what I want to try, But I couldn't run properly 10...@50 - even in xorg.log I have the report about validated 10...@50 mode - my LCD TV Philips 9703PFL reported about 1080p source from hdmi :( Native output and letting the TV do the grunt work would be my prefernece, too - in what way doesn't it work? No output at all or very juddery output ? Here are parts of a discussion I had with a Nvidia developer 4 months ago: --- I'm interested in getting 1:1 output of interlaced DVB broadcasts using Nvidia gfx cards. For this you need to be able to vsync to each interlaced field separately.. afaik Nvidia X.org driver does not support this? I just tested VDPAU, and it looks like this is possible, to some degree. Specifically, with 480i output over S-Video, I find that the presentation queue flips at 60Hz, not 30Hz, so it's definitely only syncing to fields not frames. The hard part is that there's no way to specify if you're outputting a top or bottom field, so it'll end up being random if your surface gets displayed as top or bottom, which kinda makes the whole thing pointless. We did acknowledge that this use-case might exist, but were of the opinion that it was extremely rare; most users will simply de-interlace their content and display it one their progressive display. Does your display device not support any progressive modes? --- The hard part is that there's no way to specify if you're outputting a top or bottom field, so it'll end up being random if your surface gets displayed as top or bottom, which kinda makes the whole thing pointless. Yeah the field order you need to be able to specify or figure out.. I did some investigation, and it doesn't look like our HW exposes any status indicating top v.s. bottom field, nor any way to request syncing of display to top v.s. bottom field. Sorry this isn't more useful! I will keep this request around as an RFE (request for enhancement) just in case we can implement it on any future HW. Oh, and it looks like we do support 50Hz output; see the README that comes with the driver, and search for the TVStandard option. Do you know if VDPAU supports full-fps deinterlacing? ie. 50 fps progressive output for 50 hz interlaced video.. Yes, out with an n Hz field rate, you should be able to derive either n Hz frame rate or 2n Hz frame rate. The exact details are explained in the vdpau.h documentation on video mixer usage, with some additional notes in the driver README. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Sat, Aug 15, 2009 at 06:37:36PM +0400, Goga777 wrote: I'm wondering - does the problem with timing and sync also important and for for vdpau nvidia cards ? or that project is important only for intel and ati ? Now that I think about it, I believe this is what I was really asking about.. is it perhaps that good LCD TVs have so much smoothing/deinterlacing processing circuitry that the interlace timing is less of a problem when provided by VGA or HDMI? but to run nvidia geforce 8/9 series cards with 1080i 50Hz mode is not so easy or could you run 1080i mode on vdpau card with good result ? At least you should be able to run 1080p50 and let vdpau do deinterlacing for you.. I believe it should be possible to get 50 fps progressive output from 50i material using vdpau deinterlacing. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patches for VGA timing not matching up with the TV (was: HD output - your current favourites)
On Sun, Aug 16, 2009 at 04:29:38PM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 15, 2009 at 06:37:36PM +0400, Goga777 wrote: I'm wondering - does the problem with timing and sync also important and for for vdpau nvidia cards ? or that project is important only for intel and ati ? Now that I think about it, I believe this is what I was really asking about.. is it perhaps that good LCD TVs have so much smoothing/deinterlacing processing circuitry that the interlace timing is less of a problem when provided by VGA or HDMI? but to run nvidia geforce 8/9 series cards with 1080i 50Hz mode is not so easy or could you run 1080i mode on vdpau card with good result ? At least you should be able to run 1080p50 and let vdpau do deinterlacing for you.. I believe it should be possible to get 50 fps progressive output from 50i material using vdpau deinterlacing. .. But you might get better results if you outputted 1:1 interlaced material using 1080i50 mode and let the LCD tv do the deinterlacing.. Not sure if that's possible with Nvidia hardware/drivers. At least 'vga sync fields' patches are not atm working with nvidia. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD output - your current favourites
On Thu, Aug 13, 2009 at 10:35:11PM +0100, Gavin Hamill wrote: My current vdr-1.4.7 (compiled 2 years ago as of tomorrow!) is still serving me well.. I have a Technotrend FF DVB-C doing all the heavy lifting, but as time moves on and HD content becomes more prevalent, I'm thinking of moving up. Right now I have an EPIA 800MHz quiet PC with the Technotrend giving me lovely SCART RGB out... if I got a nice LCD TV, what setup would be ideal for driving the HDMI input? Most of the content is still SD, and I am a real pedant about smooth video / interlaced output for scrolling text / live sports. Any time that I've played with vdr-xine or xineliboutput over my years with VDR, it's always been a bit juddery due to VGA timing not matching up with the TV.. is that improved any in the world of HD / HDMI? Take a look at these patches: http://lowbyte.de/vga-sync-fields/ I believe they are useful also for HDMI/HD stuff. I haven't tried them yet myself. Original announcement: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html For Intel: http://www.linuxtv.org/pipermail/vdr/2009-January/019330.html -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
On Fri, May 29, 2009 at 05:19:21PM +0300, Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: So you have 576i 50Hz interlaced video playing at 50fps de-interlaced? Yes, the output is 1080p50. Nice. How's the deinterlacing quality? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
On Thu, May 28, 2009 at 08:54:05PM +0300, Seppo Ingalsuo wrote: Luca Olivetti kirjoitti: OTOH with my setup it works poorly (artifacts, banding, freezing, changes in color, etc.) and I'm not the only one, so I'm not sure vdpau support is mature enough for inclusion in xine-lib. Here VDPAU works close to perfectly with two different (Intel E8200, AMD 4850E + GeForce 8400) Ubuntu Jaunty boxes with included restricted Nvidia driver and self compiled VDPAU enabled xine-lib. I had picture tearing that was solved by disabling composite extension. I lost possibility for HUD OSD for now. I needed to force also 50 Hz video mode to HDMI with custom xorg.conf modeline. Somehow probably due to extremely low CPU load VDPAU also solved breaking SPDIF sound that I had on my Asus P5Q motherboard (with similar setup the AMD780G mobo never had sound problems). 576i video scaling and de-interlacing is good quality in VDPAU. So you have 576i 50Hz interlaced video playing at 50fps de-interlaced? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [FRC] Why are patches for framebuffer not needed anymore in release 0.1.0?
On Sun, Mar 29, 2009 at 11:34:30AM +0200, Thomas Hilber wrote: On Sun, Mar 29, 2009 at 12:21:18AM +0100, Paul Menzel wrote: you released version 0.1.0 [1]. Could you please explain to me, why the framebuffer patches (intelfb, radeonfb) are not needed anymore? since version 0.1.0 you will not need DRM from GIT anymore. You just can use DRM as provided by the standard kernel shipped with debian 5.0 (lenny). This should ease the handling of the patch (see [2]). Does Lenny have some extra patches in the kernel, or does it work with all vanilla 2.6.26+ kernels? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Sun, Mar 01, 2009 at 11:06:44PM +0100, Thomas Hilber wrote: On Mon, Mar 02, 2009 at 12:33:48AM +0300, Goga777 wrote: please - could you point out please on proper xorg.conf you'll find one attached. I use it on my Asus Pundit P1_AH2. System is quite old (but stable): debian etch based xserver-xorg 7.1.0-19 NVIDIA-Linux-x86-100.14.19 more recent systems might need some adaptions does that xorg.conf corrected ? http://mymediasystem.net/wp/2009/02/xorg.conf1 it appears it's not a PAL modeline. Instead 1920x1080 is used. Hmm.. so you get 50 Hz interlaced output with this xorg.conf. Are you able to sync to each field separately? -- Pasi - Thomas Section ServerLayout Identifier Default Layout Screen Default Screen 0 0 InputDeviceGeneric Keyboard InputDeviceConfigured Mouse Option BlankTime 0 Option StandbyTime 0 Option SuspendTime 0 Option OffTime 0 EndSection Section Files FontPath/usr/share/fonts/X11/misc EndSection Section Module Load i2c Load bitmap Load ddc Load extmod Load freetype #Load glx Load int10 Load vbe EndSection Section ServerFlags Option AllowMouseOpenFail on EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Monitor Identifier Generic Monitor Option DPMS HorizSync 15-16 Modeline 720x576i 13.875 720 744 808 888 576 580 585 625 -HSync -Vsync interlace EndSection Section Device Option UseEDID FALSE Option UseEvents True Option NoLogo True Identifier Generic Video Card Driver nvidia EndSection Section Screen Identifier Default Screen Device Generic Video Card MonitorGeneric Monitor DefaultDepth 24 SubSection Display Depth 24 Modes 720x576i EndSubSection EndSection ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdpau output to pal tv,
On Mon, Feb 16, 2009 at 01:29:22PM +, Tony Houghton wrote: On Mon, 16 Feb 2009 13:26:18 +1000 Torgeir Veimo torg...@pobox.com wrote: Andy Ritger (nvidia) said in a mail to the xorg mailing list some time ago; If the application doesn't enable de-interlacing, NVIDIA's VDPAU implementation will currently copy the weaved frame to the progressive surface, and whether it will come out correctly will depend whether the window's offset from the start of the screen is odd or even. I take this to imply that field parity should be possible, but the application in use have to detect the field flag from the source material and set the Y offset appropriately to be 0 or 1 accordingly. It also relies on vsyncing correctly. If it syncs to the wrong field you'll get the backward juddering. I don't think VDPAU provides a way for applications to distinguish between odd and even vsyncs, but perhaps it does its own internal syncing. Might be a good idea to ask Andy Ritger about that vsync to correct fields.. Hopefully Nvidia is able to fix/provide that.. VPDAU seems good otherwise.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 06:02:23AM +0100, Thomas Hilber wrote: It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-) I think there's demand for this functionality all over the world :) not just in germany. I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Mon, Jan 19, 2009 at 09:54:18PM +, Scott Waye wrote: I want to replace my UK Sky digital box with VDR (I only want the free to air channels) for watching/recording TV over HDMI on my plasma. So far everything is working OK, I have vdr 1.7.3 and xine running on an ASUS M2N VM-HDMI (nvidia) mobo with the s2-liplianin drivers for my Nova SD2 card. My problem is interlacing. I've googled back through the archives and got a lot of info from there, however I still have one question and one request. If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field? What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong? There's a lot of options for tvtime in xine, TomsMoComp and full framerate seem popular. What settings are others using? Hello. Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html Original patches: http://lowbyte.de/vga-sync-fields/ New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that.. There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
On Tue, Jan 06, 2009 at 01:17:52AM +0200, Jukka Vaisanen wrote: Yes, it's a good idea to get 1:1 pixel mapping on your display. Double scaling (first pc, then display) is not a good idea, ever. But, some problems arise: HDMI uses DVI signalling for the video (and audio is hidden in a vertical blanking time slot believe it or not) so it may seem like just another connector.. however in their finite wisdom the HDMI standardization people decided that HDMI will not support arbitrary resolutions, but instead only the existing (and back then, planned) broadcast resolutions: - 576i/p (pal) and 480i/p (ntsc) - 720p (1280x720) - 1080i and 1080p (1920x1080) The world is full of TVs with 1366x768 and other weird resolutions. There are also plasmas with 1024x768 etc standard computer resolutions. The big surprise to many people is that even though DVI signalling could carry these native resolutions, the displays themselves won't accept / sync to them. And they don't advertise them in the EDID data so you have to force your computer to that resolution / refresh to even try it (and fail). The only true 720p displays I have seen are rear-projection TVs and data/av projectors. They will accept their native resolution of 1280x720 over HDMI, however getting rid of overscan to get 1:1 is another matter.. Then a solution: I used to have a Panasonic plasma with a similar non-standard resolution and I used the VGA port with it to automatically get a 1:1 pixel display as it's intended for PC display use. Yes VGA is not optimal but at that resolution and a 1 meter cable, who cares... Today I have a full HD 1920x1080 panel with an option for exact scan which gives me 1:1 pixels (without overscan) out of the box over HDMI, I just run normal 1920x1...@60hz out of my computers. And finally a question: If someone can tell me how to get 576i over HDMI out from VDR, please do. That way I could use my external HQV Reon video scaler to upscale it.. Of course it would need to allow me to switch modes for 720p and 1080i also based on broadcast resolution ;) Hello. Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html Original patches: http://lowbyte.de/vga-sync-fields/ New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that.. There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Sat, Sep 27, 2008 at 08:35:23AM +0200, Thomas Hilber wrote: a successor of my vga-sync-fields patch (http://lowbyte.de/vga-sync-fields/) now has been released by 'durchflieger' on 'vdr-portal.de' with far more functionality especially for HDTV related things. please see: http://www.vdr-portal.de/board/thread.php?threadid=80567 Too bad the text is not english :( -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Tue, Aug 12, 2008 at 12:11:07AM +0300, Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: Unfortunately I don't have Elisa/Saunalahti ADSL.. :( In DVB-S2 19.2E FTA channel Anixe HD there seems to be some olympics going on. ANIXE HD;BetaDigital:11915:hC910M2O0S1:S19.2E:27500:1535:1539=deu:0:0:132:0:0:0 Too bad I don't have satellite dish atm either.. So, if someone is able to record/dump that stream, please do so :) I just recorded some horse riding to try with various xine lib versions. Send me pm if you'd like to get a clip. My first try on Ubuntu 8.04 produced [h264 @ 0x7faf7a9c7330]PAFF interlacing is not implemented gxine has suffered a fatal internal error. Xine-lib 1.2 from mercurial decodes it now but the playback is very jerky on Intel E8200 CPU. The result is not much better than on my other old AMD Sempron 3100+ based HTPC. Maybe try with recent mplayer (from svn).. and give it -demuxer lavf -lavdopts fast:threads=2 -no-correct-pts or something similar.. you can also try with threads=4 etc.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Aug 12, 2008 at 10:29:53AM +0200, Theunis Potgieter wrote: Does somebody have a URL on how to make one? for d-sub to scart or the new DVI (modern graphic cards) to scart? http://www.sput.nl/hardware/tv-x.html That URL was included in the first mail of this thread.. -- Pasi On 12/08/2008, Thomas Hilber [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 07:40:15PM +0300, Jouni Karvo wrote: with NVIDIA driver 169 and 173 at least, this does not yet work: the patch is not yet ported to nVidia that's true. Independent from that you can configure the nVidia-Xserver to output a PAL/RGB compatible signal. And connect a CRT via a VGA-to-SCART cable. But until the patch is ported to nVidia (if ever) you must use a deinterlacer. I attached my 'xorg.conf' and 'Xorg.0.log' which runs in several configurations here without problems. Maybe you give it a try. BTW: we do not use any of these evil TV encoder things. Just forget about that. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Aug 12, 2008 at 12:08:55PM +0100, Gavin Hamill wrote: On Tue, 2008-08-12 at 14:01 +0300, Pasi Kärkkäinen wrote: On Tue, Aug 12, 2008 at 10:29:53AM +0200, Theunis Potgieter wrote: Does somebody have a URL on how to make one? for d-sub to scart or the new DVI (modern graphic cards) to scart? http://www.sput.nl/hardware/tv-x.html That URL was included in the first mail of this thread.. You can also use this if you have a Radeon and use 'composite' on the modeline instead of '-hsync -vsync' : http://www.idiots.org.uk/vga_rgb_scart/index.html Just please be careful - you can destroy your TV by sending it VGA-spec signals! These two links seem to have a bit different ways of doing the cable.. The first link has more complicated cable.. Can someone try and compare these or explain the differences? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Tue, Aug 12, 2008 at 03:07:57PM +0300, Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: Maybe try with recent mplayer (from svn).. and give it -demuxer lavf -lavdopts fast:threads=2 -no-correct-pts or something similar.. you can also try with threads=4 etc.. mplayer -demuxer lavf -lavdopts fast:threads=4 -nocorrect-pts ... gives steady but slow motion (roughly 50% speed) video. It is weird that the load on CPU1 and CPU2 is less than 40% during playback according to gnome system monitor. Somehow mplayer is not able to max both CPUs close to 100%. With mplayer I noticed that the video is 1080i -- it is silly to broadcast interlaced crap. That probably explains why vdr xinelibout choked due to greedy de-interlacer that is pretty power consuming for 1080i. Other channels such as Arte HD (arte HD;ZDFvision:11362:hC23M5O0S1:S19.2E:22000:6210:6221=deu,6222=fra:6230:0:11120:1:1011:0) work OK. Actually interlaced video kinda makes sense for sports and other live video.. you get 50 fields per second, so the movement is smooth.. If you look at interlaced video on a progressive display, then you need to do pretty heavy deinterlacing, preferrably using full motion methods to get 50 or 100 fps output.. takes a lot of CPU. Check http://www.100fps.com Where did you get that stream from btw? Digita is broadcasting this channel as 720p in DVB-T.. dunno if it's 25 fps or 50 fps.. Hopefully not 25 fps.. In what format is that Arte HD? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Tue, Aug 12, 2008 at 04:03:38PM +0300, Pasi Kärkkäinen wrote: On Tue, Aug 12, 2008 at 03:59:19PM +0300, Lauri Tischler wrote: Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: Maybe try with recent mplayer (from svn).. and give it -demuxer lavf -lavdopts fast:threads=2 -no-correct-pts or something similar.. you can also try with threads=4 etc.. mplayer -demuxer lavf -lavdopts fast:threads=4 -nocorrect-pts ... gives steady but slow motion (roughly 50% speed) video. It is weird that the load on CPU1 and CPU2 is less than 40% during playback according to gnome system monitor. Somehow mplayer is not able to max both CPUs close to 100%. With mplayer I noticed that the video is 1080i -- it is silly to broadcast interlaced crap. That probably explains why vdr xinelibout choked due to greedy de-interlacer that is pretty power consuming for 1080i. Other channels such as Arte HD (arte HD;ZDFvision:11362:hC23M5O0S1:S19.2E:22000:6210:6221=deu,6222=fra:6230:0:11120:1:1011:0) work OK. Hi. What card are you using to get DVB-S2 ? CPU power ? Dual-core ? GHz ? I have now AMD X2 4600 and DVB-T YLE HD is a bit jerky, sometimes, playing recordings from YLE HD is totally jerky. Wondering if getting quad-core 2.6GHz would help any. A friend of mine was able to view DVB-T YLE HD on dual-core Intel core2 3 GHz CPU.. I think it didn't work very well on 2,66 GHz dual-core one. Notice that there was been some optimizations and fixes lately to mplayer/ffmpeg/libavcodec so you should be running latest SVN version.. Or then you could try with CoreAVC H.264 codec.. And just to make it clear, DVB-T YLE HD is 720p.. not 1080i. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Tue, Aug 12, 2008 at 04:18:15PM +0300, Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: Actually interlaced video kinda makes sense for sports and other live video.. you get 50 fields per second, so the movement is smooth.. 720p50 or even 720p60 would give superior motion with in practise better vertical resolution than 1080i. It would better to let the video encoder lose data in a controlled way than rudely alternating between two 540 line fields with interlaced video. Also now when carbon footprint matters it's insane to double every set top box / HDTV power consumption at recipient side for doing magical motion vectors based tricks in trying to restore the 1080 line image. Yep, 720p50 or 720p60 is nice. 25 or 30 fps is not enough.. that's why they do 1080i50 instead of 1080p25. 1080p50 would be excellent though :) Takes a lot of bandwidth also.. I guess too much. If you look at interlaced video on a progressive display, then you need to do pretty heavy deinterlacing, preferrably using full motion methods to get 50 or 100 fps output.. takes a lot of CPU. Check http://www.100fps.com Where did you get that stream from btw? Recorded from Anixe HD yesterday. Digita is broadcasting this channel as 720p in DVB-T.. dunno if it's 25 fps or 50 fps.. Hopefully not 25 fps.. In what format is that Arte HD? At the moment VIDEO: [H264] 1280x720 0bpp 50.000 fps0.0 kbps ( 0.0 kbyte/s) == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000-192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [oss] 48000Hz 2ch s16le (2 bytes per sample) But that was an old B/W film so not real HD content. I just checked a sample of DVB-T YLE HD and it seems to be: VIDEO: [H264] 1280x720 0bpp 50.000 fps0.0 kbps ( 0.0 kbyte/s) Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) AUDIO: 48000 Hz, 2 ch, s16le, 320.0 kbit/20.83% (ratio: 4-192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) So yeah, 720p50 is nice :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Tue, Aug 12, 2008 at 03:07:57PM +0300, Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: Maybe try with recent mplayer (from svn).. and give it -demuxer lavf -lavdopts fast:threads=2 -no-correct-pts or something similar.. you can also try with threads=4 etc.. mplayer -demuxer lavf -lavdopts fast:threads=4 -nocorrect-pts ... gives steady but slow motion (roughly 50% speed) video. It is weird that the load on CPU1 and CPU2 is less than 40% during playback according to gnome system monitor. Somehow mplayer is not able to max both CPUs close to 100%. Just tried a sample of DVB-T YLE HD (720p50) on my computer.. It seems mplayer is not able to use multiple threads, at least on my system.. I just see a single process/thread taking all of the CPU. I guess there's still something to fix for a proper multithreading for h.264 decoding in mplayer/ffmpeg/libavcodec.. I used: mplayer -demuxer lavf -lavdopts fast:threads=4 -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Tue, Aug 12, 2008 at 04:31:30PM +0300, Pasi Kärkkäinen wrote: On Tue, Aug 12, 2008 at 03:07:57PM +0300, Seppo Ingalsuo wrote: Pasi Kärkkäinen wrote: Maybe try with recent mplayer (from svn).. and give it -demuxer lavf -lavdopts fast:threads=2 -no-correct-pts or something similar.. you can also try with threads=4 etc.. mplayer -demuxer lavf -lavdopts fast:threads=4 -nocorrect-pts ... gives steady but slow motion (roughly 50% speed) video. It is weird that the load on CPU1 and CPU2 is less than 40% during playback according to gnome system monitor. Somehow mplayer is not able to max both CPUs close to 100%. Just tried a sample of DVB-T YLE HD (720p50) on my computer.. It seems mplayer is not able to use multiple threads, at least on my system.. I just see a single process/thread taking all of the CPU. I guess there's still something to fix for a proper multithreading for h.264 decoding in mplayer/ffmpeg/libavcodec.. I used: mplayer -demuxer lavf -lavdopts fast:threads=4 And I used SVN version of mplayer/ffmpeg/libavcodec, checked out today.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, Jul 30, 2008 at 07:43:19AM +0200, Thomas Hilber wrote: On Tue, Jul 29, 2008 at 01:40:49PM +0300, Pasi Kärkkäinen wrote: Maybe then I find some time to port the patch to other platforms (like intel based graphics cards). That would rock. maybe this way we could fix current issues with S100. Picture quality dramaticly improves if deinterlacer is switched off. Anyway they made a big step forward these days: http://forum.zenega-user.de/viewtopic.php?f=17t=5440start=15#p43241 btw any chance of getting these patches accepted/integrated upstream? I don't think we get upstream support in the near future. Since TV applications are the only ones that need to synchronize VGA timing to an external signal. Ok.. the other day you sent a mail saying you had reworked the patches, so that made me wonder if it would be possible to make these patches friendly enough to get them accepted upstream :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Finnish Yle HD olympics channel..
On Mon, Aug 11, 2008 at 08:54:32AM +0300, Rolf Ahrenberg wrote: On Sun, 10 Aug 2008, Pasi Kärkkäinen wrote: Hi, I'm not living in an area where Digita transmits this channel via dvb-t, so I was wondering if there are other .fi users who could record/dump some minutes of this channel and upload it somewhere so we others could check the quality etc :) if you're having Elisa/Saunalahti ADSL line, you can use VDR+IPTV plugin to view and record the Yle HD Olympics stream. Unfortunately I don't have Elisa/Saunalahti ADSL.. :( So, if someone is able to record/dump that stream, please do so :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: Finnish Yle HD olympics channel..
Hello! I'm not living in an area where Digita transmits this channel via dvb-t, so I was wondering if there are other .fi users who could record/dump some minutes of this channel and upload it somewhere so we others could check the quality etc :) http://www.digita.fi/digita_dokumentti.asp?path=1840;3793;1973;9850;10653 -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Jul 29, 2008 at 09:34:39AM +0200, Thomas Hilber wrote: On Tue, Jul 22, 2008 at 11:17:26PM +0200, Thomas Hilber wrote: Unfortunately with Radeons we currently have 2 problems unsolved: 1. there appears to be a tiny bug in XV overlay scaling code which sometimes mixes even and odd fields at certain resolutions. A workaround to compensate for this is to scale the opposite way. This is done by xineliboutput option 'Fullscreen mode: no, Window height: 575 px' instead of 'Window height: 575 px' (as noted in my configuration example). Overlay XV uses double buffering eliminating any tearing effects. This works pretty good. 2. the other way to use XV video extension is textured mode. This method shows very good results. No scaling problems at all. But this code is so new (a few weeks), there even does not yet exist proper tearing protection for. the first issue has been fixed yesterday! The second one is void then. Thanks to Roland Scheidegger I now get a perfect picture for all source resolutions testet so far. http://lists.x.org/archives/xorg-driver-ati/2008-July/006143.html http://www.vdr-portal.de/board/thread.php?postid=741778#post741778 Nice progress! There currently is only one known issue left: detection of inital field polarity. I don't think this is a big deal. After this I can start productive use of the patch on my living room VDR. :) Maybe then I find some time to port the patch to other platforms (like intel based graphics cards). That would rock. btw any chance of getting these patches accepted/integrated upstream? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] extending VDR to support external Media software
On Sun, Jul 27, 2008 at 01:09:26PM +0200, Markus Ecker wrote: Hi,I've got a first version of an extension to streamdev for SageTV ready. You can check it out here: http://trac.assembla.com/SageTV-VDR-Integration . I watched some HDTV on the extender with it yesterday and the picture was so fluid, I am still grinning. Cool! When you stop grinning and have some time please upload those network/packet dumps between SageTV server and HD Extender.. :) -- Pasi Markus. 2008/7/19 Pasi Kärkkäinen [EMAIL PROTECTED] On Fri, Jul 18, 2008 at 11:05:09PM +0200, Markus Ecker wrote: I was reading through the streamdev source code today, and allthough I don't understand it a 100% yet,I think I can extend it to support the SageTV recorder plugin protocol. Nice! If anyone wants to write a VDR plugin to support the device directly, I can provide network dumps of the communication between the extender and the server. Ok. Can you put some dumps online? Or if you don't have web/ftp space for that, I think I can fix something.. I could take a look at those dumps.. -- Pasi Markus 2008/7/18 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 09:52:53PM +0200, Markus Ecker wrote: Dear Pasi, Out of the box, it only works together with the SageTV server software. The GUI is rendered on the server, the device acts as a dumb terminal. However, they released some source code, and I just found some more technical details on the MythTV wiki: http://www.mythtv.org/wiki/index.php/SageTV_HD_Extender Yep.. someone with access to hd_extender should do some packet capturing and/or tracing to figure out how the communication between sagetv server and hd_extender is done.. I'm not interested in using SageTV software, but I'd like to use this device with VDR.. if possible. And possibly help developing a vdr plugin :) -- Pasi Markus. 2008/7/16 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 05:20:27PM +0200, Markus Ecker wrote: Torgeir, It's this box: http://sagetv.com/hd_extender.html. Not sure about the hardware, but it runs Linux. From the spec: Video format supported: MPEG1, MPEG2, MPEG4, H.264 up to 1080p, AVI, VOB, WMV9/VC-1 up to 1080p I run it at the moment with a dubious shell script doing the DVB recording, and the picture is very nice and fluid. Hmm.. is there any way to send video streams to this device without running sagetv atm? Looks like a nice device:) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 06:37:05PM +0200, Thomas Hilber wrote: goal develop a budget card based VDR with PAL/RGB output and FF like output quality VGA-to-SCART RGB adapter like this: http://www.sput.nl/hardware/tv-x.html Hi again! One more question.. Is it possible to output WSS signal from a VGA card to switch between 4:3 and 16:9 modes? http://www.intersil.com/data/an/an9716.pdf -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] extending VDR to support external Media software
On Sun, Jul 27, 2008 at 02:58:55PM +0200, Markus Ecker wrote: Pasi,I think on Tuesday I will have some time to capture the network traffic. I have a gut feeling they use a modified vnc protocol for the GUI display, but we will see... Ok, nice :) -- Pasi 2008/7/27 Pasi Kärkkäinen [EMAIL PROTECTED] On Sun, Jul 27, 2008 at 01:09:26PM +0200, Markus Ecker wrote: Hi,I've got a first version of an extension to streamdev for SageTV ready. You can check it out here: http://trac.assembla.com/SageTV-VDR-Integration . I watched some HDTV on the extender with it yesterday and the picture was so fluid, I am still grinning. Cool! When you stop grinning and have some time please upload those network/packet dumps between SageTV server and HD Extender.. :) -- Pasi Markus. 2008/7/19 Pasi Kärkkäinen [EMAIL PROTECTED] On Fri, Jul 18, 2008 at 11:05:09PM +0200, Markus Ecker wrote: I was reading through the streamdev source code today, and allthough I don't understand it a 100% yet,I think I can extend it to support the SageTV recorder plugin protocol. Nice! If anyone wants to write a VDR plugin to support the device directly, I can provide network dumps of the communication between the extender and the server. Ok. Can you put some dumps online? Or if you don't have web/ftp space for that, I think I can fix something.. I could take a look at those dumps.. -- Pasi Markus 2008/7/18 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 09:52:53PM +0200, Markus Ecker wrote: Dear Pasi, Out of the box, it only works together with the SageTV server software. The GUI is rendered on the server, the device acts as a dumb terminal. However, they released some source code, and I just found some more technical details on the MythTV wiki: http://www.mythtv.org/wiki/index.php/SageTV_HD_Extender Yep.. someone with access to hd_extender should do some packet capturing and/or tracing to figure out how the communication between sagetv server and hd_extender is done.. I'm not interested in using SageTV software, but I'd like to use this device with VDR.. if possible. And possibly help developing a vdr plugin :) -- Pasi Markus. 2008/7/16 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 05:20:27PM +0200, Markus Ecker wrote: Torgeir, It's this box: http://sagetv.com/hd_extender.html. Not sure about the hardware, but it runs Linux. From the spec: Video format supported: MPEG1, MPEG2, MPEG4, H.264 up to 1080p, AVI, VOB, WMV9/VC-1 up to 1080p I run it at the moment with a dubious shell script doing the DVB recording, and the picture is very nice and fluid. Hmm.. is there any way to send video streams to this device without running sagetv atm? Looks like a nice device:) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Wed, Jul 23, 2008 at 09:21:01PM +0200, Thomas Hilber wrote: On Wed, Jul 23, 2008 at 05:05:21PM +0300, Pasi Kärkkäinen wrote: I assume RGB NTSC should work as well.. ? basically yes. The devil is in the details:) Just give it a try. When xine-lib calls PutImage() it checks whether to increase/decrease Xservers frame rate. This way after a short adaption phase xine-lib can place it's PutImage() calls right in the middle between 2 adjacent vertical blanking intervals. This provides maximum immunity against jitter. And even better: no more frames/fields are lost due to stream and graphics card frequency drift. Hmm.. can you explain what increase/decrease Xservers frame rate means? you simply adjust the time between two vertical blanking (retrace) intervals to your needs. This is done by lengthening/shortening scan lines that are not visible on the screen. Because they are hidden within the vertical blanking interval. Hmm.. I still don't understand why you need to do this in the first place? I don't really know how xserver or display drivers work nowadays, but back in the days when I was coding graphics stuff in plain assembly (in MSDOS) I always did this to get perfect synchronized output without any tearing: 1. Render frame to a (double) buffer in memory 2. Wait for vertical retrace to begin (beam moving from bottom of the screen to top) 3. Copy the double buffer to display adapter framebuffer 4. Goto 1 that's very similar to the way a Radeon handles this when overlay method is choosen for XV extension: 1. the Xserver writes the incoming frame to one of its 2 buffers. Strictly alternating between the two. 2. the CRT controller sequentially reads the even than the odd (or the other way round dependend on the start condition) field out of the buffer. And then switches to the next buffer. Also strictly alternating between the two. You just have to take care that data is written the right sequence to the double buffers. So it is always read the correct sequence by the CRT controller. Ok. So the video adapter framebuffer was always filled with a full new frame right before it was visible to the monitor.. the same here. Otherwise the CRT controller would reuse already shown data. So I guess the question is can't you do the same nowadays.. lock the PutImage() to vsync? exactly. The patch tries hard to do this:) But to put it in your words: It's only a 'soft' lock. Loading the machine too much can cause problems. Does this mean XV extension (or X itself) does not provide a way to wait for retrace out-of-the-box.. and your patch adds that functionality? Sorry for the stupid questions :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Wed, Jul 23, 2008 at 03:09:29PM +0200, Thomas Hilber wrote: On Tue, Jul 22, 2008 at 11:51:13PM +0300, Pasi Kärkkäinen wrote: A bit off topic.. Does any of the video players for Linux switch to a resolution/modeline with a different refresh rate when watching a movie to get perfect synchronization and no tearing? some time ago I accidentally stumbled across these options in my outdated xineliboutput version: xineliboutput.VideoModeSwitching = 1 xineliboutput.Modeline = maybe these are intended for this purpose? I didn't care yet. Ok. Sounds like it.. although xineliboutput.Modeline sounds a bit like it only wants to change to one specific modeline.. An example.. your desktop might be at 70 hz refresh rate in normal use (ok, maybe it's 60 hz nowadays with LCD displays), and when you start watching PAL TV it would be better to have your display at 50 hz or 100 hz to get perfect output.. and then, when you start seeing a 24 fps movie, it would be best to have your display in 72 hz mode (3*24).. etc. http://en.wikipedia.org/wiki/XRandR is what you are looking for. At least when talking about Xservers with that capability. Don't know how well it's supported by today's VDR output plugins. Thanks. I knew new xservers are able to change resolution/modeline on the fly nowadays.. but didn't remember it was XRandR extension doing it :) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 06:37:05PM +0200, Thomas Hilber wrote: It appeared to be a privilege of so called full featured cards (expensive cards running proprietary firmware) to output true RGB PAL at variable framerate. Thus always providing full stream synchronicity. I assume RGB NTSC should work as well.. ? I live in Europe so PAL is the thing for me, but sometimes you have video in NTSC too.. After some further experimenting I finally found a solution to fine adjust the frame rate of my elderly Radeon type card. This time without any bad side effects on the screen. Just trimming the length of a few scanlines during vertical retrace period does the trick. snip When xine-lib calls PutImage() it checks whether to increase/decrease Xservers frame rate. This way after a short adaption phase xine-lib can place it's PutImage() calls right in the middle between 2 adjacent vertical blanking intervals. This provides maximum immunity against jitter. And even better: no more frames/fields are lost due to stream and graphics card frequency drift. Hmm.. can you explain what increase/decrease Xservers frame rate means? I don't really know how xserver or display drivers work nowadays, but back in the days when I was coding graphics stuff in plain assembly (in MSDOS) I always did this to get perfect synchronized output without any tearing: 1. Render frame to a (double) buffer in memory 2. Wait for vertical retrace to begin (beam moving from bottom of the screen to top) 3. Copy the double buffer to display adapter framebuffer 4. Goto 1 So the video adapter framebuffer was always filled with a full new frame right before it was visible to the monitor.. This way you always got full framerate, smooth video, no tearing.. as long as your rendering took less than duration of a single frame :) So I guess the question is can't you do the same nowadays.. lock the PutImage() to vsync? -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 06:37:05PM +0200, Thomas Hilber wrote: Hi list, the last few days I made some interesting experiences with VGA cards I now want to share with you. goal develop a budget card based VDR with PAL/RGB output and FF like output quality problem --- as we all know current VGA graphics output quality suffers from certain limitations. Graphics cards known so far operate at a fixed frame rate not properly synchronized with the stream. Thus fields or even frames do often not appear the right time at the ouput. Some are doubled others are lost. Finally leading to more or less jerky playback. Hi and thanks for starting this project! I'm a dxr3 user myself, but of course it would be nice to get good output quality without extra hardware! :) It appeared to be a privilege of so called full featured cards (expensive cards running proprietary firmware) to output true RGB PAL at variable framerate. Thus always providing full stream synchronicity. variable framerate.. I tend to watch interlaced PAL streams (50 hz), PAL DVD's and NTSC DVD's.. It would be great to get perfect output for all of these :) A bit off topic.. Does any of the video players for Linux switch to a resolution/modeline with a different refresh rate when watching a movie to get perfect synchronization and no tearing? An example.. your desktop might be at 70 hz refresh rate in normal use (ok, maybe it's 60 hz nowadays with LCD displays), and when you start watching PAL TV it would be better to have your display at 50 hz or 100 hz to get perfect output.. and then, when you start seeing a 24 fps movie, it would be best to have your display in 72 hz mode (3*24).. etc. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] extending VDR to support external Media software
On Fri, Jul 18, 2008 at 11:05:09PM +0200, Markus Ecker wrote: I was reading through the streamdev source code today, and allthough I don't understand it a 100% yet,I think I can extend it to support the SageTV recorder plugin protocol. Nice! If anyone wants to write a VDR plugin to support the device directly, I can provide network dumps of the communication between the extender and the server. Ok. Can you put some dumps online? Or if you don't have web/ftp space for that, I think I can fix something.. I could take a look at those dumps.. -- Pasi Markus 2008/7/18 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 09:52:53PM +0200, Markus Ecker wrote: Dear Pasi, Out of the box, it only works together with the SageTV server software. The GUI is rendered on the server, the device acts as a dumb terminal. However, they released some source code, and I just found some more technical details on the MythTV wiki: http://www.mythtv.org/wiki/index.php/SageTV_HD_Extender Yep.. someone with access to hd_extender should do some packet capturing and/or tracing to figure out how the communication between sagetv server and hd_extender is done.. I'm not interested in using SageTV software, but I'd like to use this device with VDR.. if possible. And possibly help developing a vdr plugin :) -- Pasi Markus. 2008/7/16 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 05:20:27PM +0200, Markus Ecker wrote: Torgeir, It's this box: http://sagetv.com/hd_extender.html. Not sure about the hardware, but it runs Linux. From the spec: Video format supported: MPEG1, MPEG2, MPEG4, H.264 up to 1080p, AVI, VOB, WMV9/VC-1 up to 1080p I run it at the moment with a dubious shell script doing the DVB recording, and the picture is very nice and fluid. Hmm.. is there any way to send video streams to this device without running sagetv atm? Looks like a nice device:) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] extending VDR to support external Media software
On Wed, Jul 16, 2008 at 09:52:53PM +0200, Markus Ecker wrote: Dear Pasi, Out of the box, it only works together with the SageTV server software. The GUI is rendered on the server, the device acts as a dumb terminal. However, they released some source code, and I just found some more technical details on the MythTV wiki: http://www.mythtv.org/wiki/index.php/SageTV_HD_Extender Yep.. someone with access to hd_extender should do some packet capturing and/or tracing to figure out how the communication between sagetv server and hd_extender is done.. I'm not interested in using SageTV software, but I'd like to use this device with VDR.. if possible. And possibly help developing a vdr plugin :) -- Pasi Markus. 2008/7/16 Pasi Kärkkäinen [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 05:20:27PM +0200, Markus Ecker wrote: Torgeir, It's this box: http://sagetv.com/hd_extender.html. Not sure about the hardware, but it runs Linux. From the spec: Video format supported: MPEG1, MPEG2, MPEG4, H.264 up to 1080p, AVI, VOB, WMV9/VC-1 up to 1080p I run it at the moment with a dubious shell script doing the DVB recording, and the picture is very nice and fluid. Hmm.. is there any way to send video streams to this device without running sagetv atm? Looks like a nice device:) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 576i output on DVI-HDMI?
On Wed, Jul 16, 2008 at 10:08:25AM +0100, Stuart Morris wrote: It's my understanding that it is the pixel rate that is doubled to meet the minimum bandwidth requirement of 25Mpixels/sec for hdmi. That is pixels are repeated hence doubling the apparent horizontal resolution. This is always the case for the 480i and 576i modes. The modeline you need should be based on standard EIA/CEA-861B timings like this: # 1440x576i @ 50Hz (EIA/CEA-861B) ModeLine 1440x576 27.000 1440 1464 1590 1728 576 581 587 625 -hsync -vsync Interlace Unfortunately I think there is a special flag that must be set to indicate pixel-repetition is being used and I am not sure how you would get a graphics card to do this. I have not tried using the above modeline so I cannot comment on whether it works. Worth a try though. There is a good list of EIA/CEA-861B modes here: http://www.avsforum.com/avs-vb/showthread.php?t=947830page=3 I do know the 720p modeline works on my tv. GTF timings generally don't work for hdmi. The other issue with interlaced modes is how are the odd/even fields synchronised? Is this the same problem with interlaced output on a good old vga output? I'd like to know this too.. to be able to get 1:1 interlaced output, fields in sync like in the original stream. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] extending VDR to support external Media software
On Wed, Jul 16, 2008 at 05:20:27PM +0200, Markus Ecker wrote: Torgeir, It's this box: http://sagetv.com/hd_extender.html. Not sure about the hardware, but it runs Linux. From the spec: Video format supported: MPEG1, MPEG2, MPEG4, H.264 up to 1080p, AVI, VOB, WMV9/VC-1 up to 1080p I run it at the moment with a dubious shell script doing the DVB recording, and the picture is very nice and fluid. Hmm.. is there any way to send video streams to this device without running sagetv atm? Looks like a nice device:) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new graphics processor from VIA S3 for HD video
On Wed, Apr 23, 2008 at 09:56:23AM +0400, Igor wrote: The question is: Which of them will offer decent open source drivers for HD decoding, and when? I wonder if every vendor pushes his own API for using these decoding accelerators? Or is there some standard (It's surely beyond XvMC)? there's VAAPI - Video Decode Acceleration API Specification http://www.freedesktop.org/wiki/Software/vaapi but seems it hasn't finished yet :( And then there's some XvMC for H.264/AVC work/patches: http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf http://www.x.org/wiki/Events/XDS2007/Notes (link taken from here) -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
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.pdf I don't know if that card is actually available or not, but worth checking out anyway.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI from ReelMultimedia in August ?
On Fri, Aug 10, 2007 at 02:40:57PM +0300, Pasi Kärkkäinen wrote: On Mon, Aug 06, 2007 at 12:24:14AM +0200, Georg Acher wrote: On Sun, Aug 05, 2007 at 10:59:21PM +0100, Torgeir Veimo wrote: Hmm, a bit confusing.. Your saying that it's a component signal, not composite nor s-video? And you can only have output on both if the You can have it all for 576i, for other resolutions it's only YUV. The DAC is a Focus FS453 with 4 analog outputs. Usually 3 of them are YUV and the remaining is composite. But you can switch the YUV to YC. driver is set to output 576p? Or are you saying you can have output on both, but only as 576i if the driver sets a mode for 576p on the HDMI output? There's always output on HDMI and YUV with the same resolution, except 576p. There you can also have 576i on YUV/YC/CVBS. Just to make it absolutely clear and sum it up.. Available outputs: 576i: HDMI, Component (YUV), Svideo, Composite 576p: HDMI, Component (YUV) both 576p/i, Svideo (576i), Composite (576i) 720p: HDMI and Component (YUV) 1080i: HDMI and Component (YUV) 1080p: Not supported? And for 576i/p you can have both component and composite at the same time, or then only svideo from the analog output? What kind of scaling is supported by the card? Also, is MPEG1 decoding supported? I guess that's the easiest format to encode to if wanting to play videos encoded with non-supported codecs.. .. and one more thing in addition to the earlier questions.. Should this card be able to play other types of MPEG4 than h.264? XVID, Divx 3/4/5/6 ? Thanks! -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
