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 Tue, 18 Jan 2011 15:06:50 +0200 Niko Mikkilä wrote: > On 2011-01-15 22:36 +, Tony Houghton wrote: > > > 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. 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? ___ 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] vdr segfaults with glibc 2.12.2
Thanks a lot. I used: --enable-kernel=2.6.36 and it works fine now. -- Scott On 12/01/2011 00:11, David Spicer wrote: It turns out that the problem was known already. The fix is to rebuild Arch's x86_64 glibc 2.12.2 package with the --enable-kernel configure option set to one of the "Good" kernel versions listed in the post at http://www.cygwin.com/ml/libc-help/2010-12/msg00017.html. On 06/01/11 21:25, gimli wrote: I'm on Archlinux 32bit and there it works fine. Am 06.01.2011 um 22:19 schrieb sc...@waye.co.uk: Funny, I tried to change my system to Archlinux last weekend and had the same problem. I gave up in the end and will try Opensuse 11.3 now. I also tried recompiling glibc from source but it gave the same error. Would be to have a test suite for pthread. Could be a 64bit problem... if I was going to pursue it I would create a test program that made the same call as vdr to submit to the Archlinux guys. Sent from my HTC - Reply message - From: "David Spicer" Date: Thu, Jan 6, 2011 20:53 Subject: [vdr] vdr segfaults with glibc 2.12.2 To: Hi, I'm not a programmer and I'm not sure where to go with this but I thought that I'd try here first. I'm running vdr 1.6.0-2 on Arch Linux x86_64. The Arch glibc package was upgraded from 2.12.1 to 2.12.2 recently, with associated toolchain package updates. After the upgrade, vdr started segfaulting when it was run so I recompiled it with debugging symbols and got the following backtrace from gdb: (gdb) bt #0 0x0001 in ?? () #1 0x004f2d06 in ?? () #2 0x7fff1bb0269f in ?? () #3 0x004c2775 in cRwLock::Lock (this=0x72bb40, Write=true, TimeoutMs=) at thread.c:163 #4 0x0047d382 in cSchedulesLock::cSchedulesLock (this=0x7fff1bb0269f, WriteLock=, TimeoutMs=) at epg.c:911 #5 0x0047dd06 in cSchedules::Read (f=0x0) at epg.c:1014 #6 0x004cc304 in main (argc=, argv=) at vdr.c:604 If I've done this properly then problem seems to be with the glibc, specifically pthread, functions that vdr uses to lock the epg data file for reading and writing but I have no idea whether the problem is with the vdr code or with glibc. The only workaround I have at the moment is to downgrade to glibc 2.12.1, after which vdr works again. Can anybody help please? TIA, David Spicer ___ 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 ___ 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
