Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video & audio, etc.
Hi, On Mon, 2010-08-16 at 19:05 +0300, Seppo Ingalsuo wrote: > Asus Bravo 220 silent seems to be a passive model. Do you know if these > non-motherboard integrated cards support 7.1ch PCM audio over HDMI? Yes, as VDR User said, the latest generation VP4/VDPAU feature set C cards (GeForce 210, GT 220, ...) have an integrated audio controller. The ALSA driver should support 7.1 channel PCM too. Some older cards have an S/PDIF input header but they don't support multichannel PCM, obviously. > I got as PM one tip that pointed to this page > > http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs > > I wonder if some smaller number cheaper model with similar VP4/C skills > would do? E.g. Asus EN210 Silent? It could also produce less heat? The > text in Wikipedia is not perfectly in line with the table so I wonder if > GT2xx is needed for best VDPAU support. IMO the only reason to go for a separate card over ION would be higher quality 1080i deinterlacing. You'll need GT 220 for that since GeForce 210 is only slightly faster than ION. They have the same video processor and therefore the same video decoding capabilities, but post-processing is done on the graphics cores. > It seems that the IONs are VP3/B so your prosal is certainly better (if > there is HDMI audio support). ION2 has VP4/C, I think. If you don't need advanced 1080i deinterlacing, Asus AT5IONT-I is a very good option right now. It has ION2, latest dualcore Atom and USB3, and it's passively cooled. -- Niko ___ 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.
Hi Paul, On Tue, 2010-08-17 at 17:13 +0200, Paul Menzel wrote: > is there really no recommendation for a board not using Nvidia graphics > components? It would really be great to not depend on proprietary > drivers. Hardware decoding through VA-API is working on some Intel chipsets and CPUs, but I haven't seen any usable GPU deinterlacing implementations besides those in Nvidia's VDPAU. AMD's XvBA is closed and still too buggy to be used in practice. I haven't heard much about S3/VIA. Broadcom CrystalHD has open-source drivers, but it also doesn't deinterlace anything. This page list all VA-API compatible hardware solutions: http://freedesktop.org/wiki/Software/vaapi So, basically it's either Intel or Broadcom CrystalHD with open-source drivers or Nvidia with closed ones. Only Nvidia and CrystalHD hardware decoding is usable on Atom-based motherboards. For the Intel way, you'd need to step up to something based on GM45 or Core i3 and forget about fancy 1080i deinterlacing and other postprocessing. -- Niko ___ 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 Tue, 2010-08-17 kello 19:36 +0300, Seppo Ingalsuo wrote: > On Tue, 2010-08-17 at 13:39 +0300, Niko Mikkilä wrote: > > IMO the only reason to go for a separate card over ION would be higher > > quality 1080i deinterlacing. You'll need GT 220 for that since GeForce > > 210 is only slightly faster than ION. They have the same video processor > > and therefore the same video decoding capabilities, but post-processing > > is done on the graphics cores. > > Good point. I think 1080i is rare content for me. If ION is as good as a > GT220 with 576i, 720p and 1080p then it could be very suitable for my > needs. ION 2 should be about as good as GT220 for those formats. Older ION works too since you probably don't need all the new features in VDPAU feature set C. > > If you don't need advanced 1080i deinterlacing, Asus AT5IONT-I is a very > > good option right now. It has ION2, latest dualcore Atom and USB3, and > > it's passively cooled. > > It's an interesting new board but I wonder if there's some risk for > problems. I tried to search but I could not find reports about success > with Ubuntu or Linux generally. Yep, that's always the question with new hardware. I'd expect any showstopping issues to be fixed pretty quickly though, at least on Nvidia's side. Their Linux support has been quite outstanding in my opinion. > Do Nvidia's binary graphics drivers > support ION2? It should. The README lists it as "Second Generation ION". See: http://us.download.nvidia.com/XFree86/Linux-x86/256.44/README/supportedchips.html -- Niko ___ 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.
Hi, ke, 2010-08-18 kello 10:13 +0200, jori.hamalai...@teliasonera.com kirjoitti: > I also would like to remind the framerate issues. Naturally you decide what > is enough precision and quality for you. > > 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. If the difference is only few percents or less, this is not a problem for playing back recordings. You can simply sync the video playback to screen refresh and resample audio or drop/duplicate audio samples. That way there is no video judder and only a very slight reduction in audio quality. Heck, even most of the movies broadcast on PAL TV have been converted from 23.976 fps or 24 fps to 25 fps in a similar fashion; by speeding up and resampling audio. > With this bridge we come to VGA-hardware which might have 50.01Hz closest to > 50Hz signal. So every 100 frames we get a jump in picture synch. You mean every 100 seconds. > Ever seen jumping camera panning while watching a film and got annoyed by it? That's usually due to a much larger framerate mismatch or failure to configure the video player so that it doesn't drop/duplicate video frames to keep A/V sync. > For ATI cards there is a dynamic framerate fix, unfortunately there is not > one > for Nvidia cards. Nvidia has good HW acceleration but potentially bad > output. > With ATI vice versa. > > This ATI fix fixes 50.01 by dynamically reprogramming VGA timers so real > output > is 50.000Hz. (General description, the author can describe more if needed). The actual problem is that normally neither the video nor the audio outputs in a PC can be synchronized to _live_ broadcast. When the stream is live, one can't replay it faster. Slower playback would be possible with a buffer, but I don't know if anyone has implemented that. The vga-sync-fields (http://frc.easy-vdr.de/) patch collection provides support for synchronizing the video output exactly to a live transport stream. However, it only works on old pre-Avivo Radeons and Intel i9xx. I'm guessing that most general-purpose network media players such as Popcorn Hour and PS3 have the same problem with live playback? The only advantage they may have compared to standard PC hardware is that they can have a single clock source for both video and audio, which means that recordings can be played back in sync without dropping or duplicating audio frames. -- Niko ___ 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.
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. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] nvidia-vdr closed driver or open source?
Fri, 2010-08-20 at 10:30 +0300, Mikko Tuumanen wrote: > I've just tried to use a tnt2 card with the nvidia legacy drivers > because a couple of capacitors blew up on my newer card. It didn't work, > undefined symbol. Same thing with ati cards. The Nvidia legacy drivers are kept up to date with kernel and X.org changes. Plus the interface between the binary blob and the rest of the system is open source, so in most cases anyone could patch it. 71.86.14 was released just a while ago with "Improved compatibility with recent Linux kernels": http://www.nvidia.com/object/linux-display-amd64-71.86.14-driver.html > For example my work computer had an ati card and fglrx support for it > went away before warranty of the computer expired. ATI has chosen a strategy of supporting open-source driver development so that they don't need to sacrifice as much resources on supporting legacy hardware. > Open source drivers are needed so that old cards can be put to use even > after the manufacturer doesn't care to support them anymore. I totally agree. It's good to have alternative projects such as Nouveau when the manufacturer doesn't want to release proper open source drivers. -- Niko ___ 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.
Fri, 2010-08-20 at 10:08 +0200, jori.hamalai...@teliasonera.com wrote: > > 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. > > If you can find a modeline what your output is currently using you can use > online services > to check framerates it provides. "xvidtune -show" prints the current modeline, but the refresh rate calculated from it will not be the same as the actual rate. The clock chrystals have deviations in order of 0.01 % and the only way to fix that is by adjusting the timing slightly at frequent intervals as vga-sync-fields does. Having a more accurate time source might not help either because the broadcast may not be accurately timed. > It does not help using direct Toslink-output from VDR which mostly prohibits > resampling of audio. Audio can be resampled with any PCM output. The idea is to adjust the playback speed slightly by resampling for example 48 kHz audio to 48.01 kHz and then playing the result back at 48 kHz. This is more difficult if you'd like to play multi-channel AC-3 with S/PDIF passthrough; then the audio would need to be decoded, resampled and re-encoded. An easier alternative is to drop/duplicate AC-3 packets, but that may be more noticeable on playback. Both Xine and XBMC support resampling audio. XBMC also supports dropping/duplicating audio packets. > And why would you like to have audio decompressed, speeded up 1% > and then > recompressed. > > Just to avoid your output software to duplicate or drop frames. Synch > perfectly.. Yep, that's the best way to get fluid video playback with synchronized audio on current PC hardware. Re-encoding is unnecessary with stereo streams or HDMI1.3 and analog multichannel outputs. High-quality resampling is totally unnoticeable. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 dvb-t channel mismatch
Hi, Sat, 2010-08-21 at 22:06 +0200, Stefan Lucke wrote: > reststarting my vdr activities I went into trouble with dvb-t > channels.conf for Berlin. Just took the channels from: > http://www.vdr-wiki.de/wiki/index.php/Channels.conf_DVBT-De-Berlin-Brandenburg > > There is the following entry for ARTE: > > arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:0:0 The zero TID is due to an old bug in the dvb-apps scan tool. Buggy versions seemed to always return that for channels in the first scanned mux and perhaps in some other cases too. The problem has been fixed in January, but most distributions carry older versions. See: http://linuxtv.org/hg/dvb-apps/rev/673a3b451936 -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] speeding up vdr+xine on an old Pentium4
Sun, 2010-08-22 at 11:51 +0200, marti...@embl.de wrote: > You are absolutely right, the P4 has indeed 2.4GHz (and 512MB of RAM) > Which makes it the more surprising that on SD channels I am getting cpu > utilization in the region of 80% to 95% > It should be a lot less? What kind of deinterlacing settings are you using with Xine? Full-rate Greedy2Frame (which I'd recommend) will probably cause a load of 50% to 100% on that CPU, depending on how good your graphics card drivers are. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Converting all recordings to TS?
Wed, 2010-08-25 at 19:30 +0200, C.Scheeder wrote: > I guess ProjectX will do the trick, it is scriptable. > At least vdrconvert uses it this way to generate DVD-streams > from VDR-recordings. > the only downside is, it needs an X-server to run. > (a real one or a fake one. vdrconvert uses a fake server...) No need for an X server if you put AWT to headless mode: java -Djava.awt.headless=true -jar ProjectX.jar ... -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Compressing VDR recordings without losing quality.
coder. Deblocking should be coupled with the decoder so that information on macroblock quantizers is available. Otherwise it will smooth out actual detail in the video. Oversmoothing is an issue with the good filters too. Tradeoffs As Lars Bläser pointed out earlier, all this processing and encoding comes at a high price in CPU time and energy consumption. Whether it's worth it depends on your purposes, so make your own calculations. If you only want a bitrate reduction for storage reasons, CPU time alone may cost more than the required disk space -- unless it gets cold outside and you are heating with electricity... Efficient encoding still requires lots of manual work because there are no reliable automatic detection schemes for recognizing different types of sources: interlaced, telecined, field-blended and phase-shifted. Personally I'd like a scheme where the encoder frontend would adapt to source type changes on the fly and encode the video with a variable framerate, but this is not always desirable. Scripts I wrote a bash script for downloading and installing AviSynth plus some of the essential filters on Linux. I could upload it somewhere if people are interested? There's also a simple command-line based template system that makes using AviSynth slightly easier, but it needs more work to be useful. Cheers, Niko Mikkilä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib and vaapi support
On 2010-11-08 at 12:54 +0200, Theunis Potgieter wrote: > On 6 November 2010 14:14, Udo Richter wrote: > > AMD also supports vaapi, but progress is very slow, and its still very > > buggy. Also, its limited to closed source drivers. > > Sounds similar to what nvidia went through. AMD's progress has been snail-paced. I think they have actually gone backwards for at least a year now. Most (All?) of the XvBA interfacing work has been done by Gwenole Beauchesne, who is working for a third party. Nvidia's VDPAU is at least supported and it works rather well compared to every other similar attempt on Linux so far. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VGA2SCART and Broadcom Crystal HD
On 2010-11-29 at 18:58 +0100, Damien Bally wrote: > Hello > > I plan to buy an D945GSEJT to build my new VDR box and I would give a > try to the VGA2SCART (FRC) output. My TV-set is still a good old CRT. > > 1) Is the quality comparable to a dxr3 card which I am satisfied with ? If you get FRC working, it's about as good as RGB SCART can possibly be, which is much better than the SVideo output of a normal Dxr3. I haven't seen how an RGB-modified Dxr3 compares. > 2) Can it be used with a BCM70015 card in order to play HD channels ? That should work in principle, but I'm not sure what would be the best way to use it with VDR. Proper 1080i->576i downconversion may also be a bit tricky to achive with current solutions. 720p and progressively coded 1080i broadcasts are easier. --Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On 2011-01-02 at 18:56 -0800, VDR User wrote: > On Sun, Jan 2, 2011 at 3:52 PM, Adrian C. wrote: > > Also with VDPAU, but more importantly in the absence of it would any of > > these CPU be up to the task of processing: Athlon2 X3 450 3.2GHz and > > Pentium E6500 or E6700 3.0GHz. Those CPUs are fast enough for H.264 decoding, but in the absence of VDPAU, realtime 1080i deinterlacing will be difficult. You'd probably have to use a simple bobber. > The only > exception would be VC-1 material, which I don't have much of, but > again I think other users can chime in there. VC-1 decoding gets fully offloaded on feature set B (VP3) and C (VP4) cards such as GT 220 and 240, so it should work fine. On feature set A cards it's decoded partially by libavcodec that doesn't support interlaced VC-1 streams. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On 2011-01-15 22:36 +, Tony Houghton wrote: > I wonder whether it might be possible to use a more eonomical card which > is only powerful enough to decode 1080i without deinterlacing it and > take advantage of the abundant CPU power most people have nowadays to > perform software deinterlacing. It may not be possible to have something > as sophisticated as NVidia's temporal + spatial, but some of the > existing software filters should scale up to HD without overloading the > CPU seeing as it wouldn't be doing the decoding too. It's possible, but realtime GPU deinterlacing is more energy-efficient: - For CPU deinterlacing, you'd need something like Greedy2Frame or TomsMoComp. They should give about the same quality as Nvidia's temporal deinterlacer, but the code would need to be threaded to support lower-frequency multicore CPUs. Yadif almost matches temporal+spatial in quality, but it will also be about 50% slower than Greedy2Frame. - Hardware-decoded video is already in the GPU memory and moving 1920x1080-pixel frames around is not free. - Simple motion-adaptive, edge-interpolating deinterlacing can be easily parallelized for GPU architectures, so it will be more efficient than on a serial processor. For example, GT 220 can do 1080i deinterlacing at more than 150 fps (output). Normal 50 fps deinterlacing only causes partial load and power consumption. GT 430 is currently worse because of an unoptimized filter implementation: http://nvnews.net/vbulletin/showthread.php?p=2377750#post2377750 Still, only the latest CPU generation can reach that kind of performance with a highly optimized software deinterlacer. > > Alternatively, use software decoding, and hardware deinterlacing. GPU video decoding is very efficient thanks to dedicated hardware. I'd guess that current chips only use about 3 Watts for high-bitrate 1080i25. Also, decoding and filtering aren't executed on the same parts of the GPU chip. They are almost perfectly parallel processes, so combined throughput will be that of the slower process. > Somewhere on linuxtv.org there's an article about using fairly simple > OpenGL to mimic what happens to interlaced video on a CRT, but I don't > know how good the results would look. Sounds like normal bobbing with interpolation. Even if it simulates a phosphor delay, it probably won't look much better than MPlayer's -vf tfields or the bobber in VDPAU. Sharp interlaced (and progressive) video is quite flickery on a CRT too. > BTW, speaking of temporal and spatial deinterlacing: AFAICT one means > combining fields to provide maximum resolution with half the frame rate > of the interlaced fields, and the other maximises the frame rate while > discarding resolution; but which is which? And does NVidia's temporal + > spatial try to give the best of both worlds through some sort of > interpolation? Temporal = motion adaptive deinterlacing at either half or full field rate. Some programs refer to the latter by "2x". "Motion adaptive" means that the filter detects interlaced parts of each frame and adjusts deinterlacing accordingly. This gives better quality at stationary parts. Temporal-spatial = Temporal with edge-directed interpolation to smooth jagged edges of moving objects. Both methods give about the same spatial and temporal resolution but temporal-spatial will look nicer. --Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On 2011-01-18 14:49 +, Tony Houghton wrote: > I still can't translate that explanation into simple mechanics. Is > temporal like weave and spatial like bob or the other way round? Or > something a little more sophisticated, interpolating parts of the > picture belonging to the "wrong" field from previous and/or next frames? "Temporal 1x" weaves the parts of the frame that aren't combed (stationary objects) and interpolates one of the fields to fill the combed parts. I don't think it uses temporal information from other fields while interpolating. That would result in blurry video without motion compensation, which is too heavy at least for low-end GPUs. The output rate for 50 Hz interlaced video is 25 fps. "Temporal 2x" does the same but outputs one frame for each input field, keeping full temporal and spatial resolution. Output rate is 50 fps. "Temporal spatial 1x" does the same as "temporal 1x" but it smoothes the rough diagonal edges in interpolated parts of the frame. Output rate is 25 fps. "Temporal spatial 2x" does the same as "temporal 2x" but it smoothes the edges. Output rate is 50 fps. So the "temporal" part refers to motion-adaptiveness, or some kind of combing detection in a weaved frame. I haven't written a deinterlacer myself, so can't say what the used methods are exactly. If you want to know more about the "spatial" part of these filters, search for Edge-Directed Interpolation (EDI). Yadif uses a similar technique. --Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
ke, 2011-01-19 kello 10:18 +, Stuart Morris kirjoitti: > My experience with an nVidia GT220 has been less than perfect. It can > perform temporal+spatial+inverse_telecine on HD video fast enough, but > my PC gets hot and it truly sucks at 2:2 pulldown detection. The > result of this is when viewing progressive video encoded as interlaced > field pairs (2:2 pulldown), deinterlacing keeps cutting in and out > every second or so, ruining the picture quality. I think VDPAU's inverse telecine is only meant for non-even cadences like 3:2. Motion-adaptive deinterlacing handles 2:2 pullup perfectly well, so try without IVTC. > IMHO the best way to go for a low power HTPC is to decode in hardware > e.g. VDPAU, VAAPI, but output interlaced video to your TV and let the > TV sort out deinterlacing and inverse telecine. Well, flat panel TVs have similar deinterlacing algorithms as what VDPAU provides, but it would certainly be a nice alternative. > These are the key requirements to achieve interlaced output: > > Get the right modelines for your video card and TV. Draw interlaced > fields to your frame buffer at field rate and in the correct order > (top field first or bottom field first). When drawing the field to the > frame buffer, do not overwrite the previous field still in the frame > buffer. Maintain 1:1 vertical scaling (no vertical scaling), so you > will need to switch video output to match the source video height > (480i, 576i or 1080i). Display the frame buffer at field rate and > synchronised to the graphics card vertical sync. Finally, there is NO > requirement to synchronise fields, fields are always displayed in the > same order they are written to the frame buffer, even if occasionally > fields are dropped. Interesting. Could you perhaps write full instructions to some suitable wiki and post the code that you used to do this? I'm sure others would like to try it too. --Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
Replying to myself... ke, 2011-01-19 kello 12:48 +0200, Niko Mikkilä kirjoitti: > ke, 2011-01-19 kello 10:18 +, Stuart Morris kirjoitti: > > My experience with an nVidia GT220 has been less than perfect. It can > > perform temporal+spatial+inverse_telecine on HD video fast enough, but > > my PC gets hot and it truly sucks at 2:2 pulldown detection. The > > result of this is when viewing progressive video encoded as interlaced > > field pairs (2:2 pulldown), deinterlacing keeps cutting in and out > > every second or so, ruining the picture quality. > > I think VDPAU's inverse telecine is only meant for non-even cadences > like 3:2. Motion-adaptive deinterlacing handles 2:2 pullup perfectly > well, so try without IVTC. Not perfectly well apparenty; there will be slight artifacting at sharp horizontal edges, so the trigger to deinterlace is pretty low. Probably to avoid any visible combing in interlaced video. Pullup seems to work fine for me though, but I only have VP2/"VDPAU feature set A" hardware. --Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
On 2011-01-22 08:16 +0100, Thomas Hilber wrote: > On Wed, Jan 19, 2011 at 12:42:40PM +, Stuart Morris wrote: > > conversion and then draw the first field to the frame buffer. At the next > > vertical sync the shader would convert the second field and draw that to > > the frame buffer. With VDPAU is there a new OpenGL interop function that > > that's not the whole story. You still have to consider synchronicity between > incoming data rate (TV-stream) and outgoing data rate (VGA/Video timing). Yep. As Stuart said, framedrops/duplicates will happen, but with his drawing technique they don't cause the player to lose field sync. I think that's already quite acceptable, since at least recordings can be played without any video judder if audio is resampled. --Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe open hug OSD
On 2011-02-01 19:48 +0100, Oliver Schinagl wrote: > And the reason why I hadn't tried those: > > vdr-sxfe: option '--hud' doesn't allow an argument > vdr-sxfe: unrecognized option '--opengl' Then you have an old version of Xineliboutput. What does vdr-sxfe -h say about the options? For example, I'm using the yaVDR-packaged version, which is probably two or three weeks older than rofa's CVS build, and it has these switches: -D, --hudHead Up Display OSD mode using compositing -Q, --opengl-always Always use OpenGL for video and Head Up Display OSD -O, --opengl-hud Head Up Display OSD mode using OpenGL Since SourceForge's CVS servers are still down, it may be a bit tricky to get the latest and greatest version. -- Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
