Re: [vdr] xine tvtime parameters explained
Lauri Tischler wrote: Trying to google for manual, info or article where all parameters for xine tvtime command are explained, what they do, why, etc. No luck yet, any pointers ?? Here's the help text from plugin: --- Advanced tvtime/deinterlacer plugin with pulldown detection This plugin aims to provide deinterlacing mechanisms comparable to high quality progressive DVD players and so called line-doublers, for use with computer monitors, projectors and other progressive display devices. Parameters Method: Select deinterlacing method/algorithm to use, see below for explanation of each method. Enabled: Enable/disable the plugin. Pulldown: Choose the 2-3 pulldown detection algorithm. 24 FPS films that have being converted to NTSC can be detected and intelligently reconstructed to their original (non-interlaced) frames. Framerate_mode: Selecting 'full' will deinterlace every field to an unique frame for television quality and beyond. This feature will effetively double the frame rate, improving smoothness. Note, however, that full 59.94 FPS is not possible with plain 2.4 Linux kernel (that use a timer interrupt frequency of 100Hz). Newer RedHat and 2.6 kernels use higher HZ settings (512 and 1000, respectively) and should work fine. Judder_correction: Once 2-3 pulldown is enabled and a film material is detected, it is possible to reduce the frame rate to original rate used (24 FPS). This will make the frames evenly spaced in time, matching the speed they were shot and eliminating the judder effect. Use_progressive_frame_flag: Well mastered MPEG2 streams uses a flag to indicate progressive material. This setting control whether we trust this flag or not (some rare and buggy mpeg2 streams set it wrong). Chroma_filter: DVD/MPEG2 use an interlaced image format that has a very poor vertical chroma resolution. Upsampling the chroma for purposes of deinterlacing may cause some artifacts to occur (eg. colour stripes). Use this option to blur the chroma vertically after deinterlacing to remove the artifacts. Warning: cpu intensive. Cheap_mode: This will skip the expensive YV12-YUY2 image conversion, tricking tvtime/dscaler routines like if they were still handling YUY2 images. Of course, this is not correct, not all pixels will be evaluated by the algorithms to decide the regions to deinterlace and chroma will be processed separately. Nevertheless, it allows people with not so fast systems to try deinterlace algorithms, in a tradeoff between quality and cpu usage. * Uses several algorithms from tvtime and dscaler projects. Deinterlacing methods: (Not all methods are available for all plataforms) [Linear] Linear Interpolation: Expands each field independently without blurring or copying in time. Use this if you want TV-quality with low CPU, and you have configured your monitor to run at the refresh rate of the video signal. Full resolution mode expands each field to full size for high quality fullscreen use. --- [LinearBlend] Linear Blend (mplayer): Avoids flicker by blurring consecutive frames of input. Use this if you want to run your monitor at an arbitrary refresh rate and not use much CPU, and are willing to sacrifice detail. Temporal mode evenly blurs content for least flicker, but with visible trails on fast motion. From the linear blend deinterlacer in mplayer. --- [Greedy] Greedy - Low motion (DScaler): Uses heuristics to detect motion in the input frames and reconstruct image detail where possible. Use this for high quality output even on monitors set to an arbitrary refresh rate. Simple detection uses linear interpolation where motion is detected, using a two-field buffer. This is the Greedy: Low Motion deinterlacer from DScaler. --- [Greedy2Frame] Greedy 2-frame (DScaler): --- [Weave] Weave Last Field: Only updates the most recent field. --- [LineDoubler] Line Doubler: --- [Vertical] Vertical Blend (ffmpeg): Avoids flicker by blurring consecutive frames of input. Use this if you want to run your monitor at an arbitrary refresh rate and not use much CPU, and are willing to sacrifice detail. Vertical mode blurs favouring the most recent field for less visible trails. From the deinterlacer filter in ffmpeg. --- [ScalerBob] Scaler Bob: Expands each field independently without blurring or copying in time. Use this if you want TV-quality with low CPU, and you have configured your monitor to run at the refresh rate of the video signal. Half resolution is poor quality but low CPU requirements for watching in a small window. --- [GreedyH] Greedy - High Motion (DScaler): Uses heuristics to detect motion in the input frames and reconstruct image detail where possible. Use this for high quality output even on monitors set to an arbitrary refresh rate. Advanced detection uses linear interpolation where motion is detected, using a four-field buffer. This is the Greedy: High Motion deinterlacer from DScaler. --- [TomsMoComp] Tom's Motion Compensated (DScaler): Uses
Re: [vdr] xine tvtime parameters explained
is it good for 1080i/720p channels ? @Petri do you know that coreavc for linux 150 + xine-lib doesn't work with xineliboutput ? have you time to solve this issue ? Goga Lauri Tischler wrote: Trying to google for manual, info or article where all parameters for xine tvtime command are explained, what they do, why, etc. No luck yet, any pointers ?? Here's the help text from plugin: --- Advanced tvtime/deinterlacer plugin with pulldown detection This plugin aims to provide deinterlacing mechanisms comparable to high quality progressive DVD players and so called line-doublers, for use with computer monitors, projectors and other progressive display devices. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine tvtime parameters explained
Goga777 wrote: is it good for 1080i/720p channels ? Well, it works, I can't say, yet, how good it is. Local provider, YLE, is broadcasting HD (1280x720) on VHF-channel 8. My VDR shows the picture fine. It is only testpicture, colorbars, eventually they will broadcast Bejing Olympics there. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine tvtime parameters explained
On Tue, Jul 15, 2008 at 9:54 AM, Goga777 [EMAIL PROTECTED] wrote: is it good for 1080i/720p channels ? Not on my athlon dual core 3Ghz. Too many dropped frames using greedy2frame or tomsmocomp. That is why in my patch for xine-lib-1.2 and coreavc I disabled the interlacer by default as I use CoreAVC's interlacer (bob) which is not as good particularly for interlaced source material such as sport. With the current set-up you can use greedy2frame for SD material and CoreAVC's interlacer for HD material. If anyone has found a way to better deinterlace HD broadcasts then please let me know, or is it simply a case of too much cpu power required to process both HD material and use a high quality deinterlacer.? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 576i output on DVI-HDMI?
With all the recent talk about deinterlacing, I was wondering if it's now possible to get 576i output over DVI-HDMI from xine-based output devices for VDR? I was a dxr3 user for a long time and the deinterlacing offered by A/V hardware never gave me any issues.. Now I have an A/V receiver with a HQV Realta inside so it should nicely deinterlace and upscale my image. My understanding is that 576i in HDMI is actually done as a 100Hz displaymode where each frame is sent twice. This is because the HDMI spec doesn't allow speeds as low as required by true 576i.. I am using xineliboutput currently as the software output device. Of course I would prefer it to use 576i for only the interlaced SD channels / recordings and change to 1080p for media player with HD content ;) - Vaizki ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe, radeon x1200 and xv out
Hi, I can't use xineliboutput for my new vdr box using fglrx driver and xv-out. It is unstable and often crashs after switching channels etc. My graphicsadapter is an onboard rs690 based radeon x1200. Softdevice works stable but I want to use xineliboutput and its mediaplayer features. Thanks Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] directFB with 1080i (was - Vdr-xine OSD question)
Goga777 wrote: This sounds very good for HDTV setups which apparently all imply xorg, but what about DirectFB, does this HUD implementation also work there? have you good experience with HD video 1080i video from satellites and DirectFB ? is it better than X- Window solution ? Sorry, my only HDTV capable hardware a.t.m. would be the Lenovo L220x monitor, (no TV, no DVB-S2 card, I can only try to receive what's still broadcasted on DVB-S, which again is already h264 - even my desktop PC is to weak for this), so I can't tell. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr-xine OSD question
Antti Seppälä wrote: [...] Unfortunately HUD is very dependent on xorg and will not work with DirectFB. I'm not even sure whether DirectFB contains support for similar operations without resorting to CPU intensive software blending of the OSD. AFAIK, it does, at least for certain graphics cards (also depending on the configuration), there are so-called layers and the device capabilities can be queried in the API. Even if there is no good enough support for separate layers to do this, DirectFB further supports surfaces whithin a layer, AFAIK that's how softdevice implements the OSD, and it's not at all CPU-intense, in fact I guess those operations are also accelerated, and the OSD shows up all the time at the same, correct, native display resolution, regardless of the video resolution (i.e. it also uses the black top/bottom bars when the video is 16:9 letterboxed on my 4:3 TV, or it is drawn still at 720x576 even when the broadcast is only 544x764). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 576i output on DVI-HDMI?
Well the 100Hz is just a kludge to fit 576i on the HDMI signaling. My understanding is that the following happens: PC sends 1-1-2-2-3-3-4-4.. but the a/v receiver just ignores every other frame because it knows about the 576i kludge also.. so it is just seeing 1+2-3+4 going into the deinterlacer + scaler. The 100Hz thing is just a workaround to get enough data on the link so that the HDMI handshake will happen :P - Vaizki -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ville Aakko Sent: 15. heinäkuuta 2008 16:53 To: VDR Mailing List Subject: Re: [vdr] 576i output on DVI-HDMI? 2008/7/15 Jukka Vaisanen [EMAIL PROTECTED]: My understanding is that 576i in HDMI is actually done as a 100Hz displaymode where each frame is sent twice. This is because the HDMI spec doesn't allow speeds as low as required by true 576i.. I'm not actually answering your question (I couldn't since I don't have any experience with these modern TVs), but, AFAIK, you wouldn't get very good results by doing what you describe. If every frame of 50Hz interlaced moving picture is shown twice, you'll get annoying blurriness and / or jerky movement. Anyhow, the movement won't be smooth as you might expect (because the frames are shown like this: 1-2-1-2-3-4-3-4-5-6-5-6-7-8-7-8 instead of 1-2-3-4-5-6-7-8). You'll get much better results by doing true deintercaling, and showing every full frame just once (i.e. 1+2-3+4-5+6-7+8 and so on). So what you want would be quite useless, IMHO, though I could be wrong. Someone correct me if you know better =). If you really want to show interlaced material as they are supposed to - i.e. you are a Hifi-lover - then the only real solution is to get a display that can (truly) show 50Hz interlaced - perhaps via a DXR3 card, as you used to =). I am using xineliboutput currently as the software output device. Of course I would prefer it to use 576i for only the interlaced SD channels / recordings and change to 1080p for media player with HD content ;) I'd just deinterlace via software (or hardware), and then upscale x2 (576 * 2 = 1052). Or, maybe forget the upscaling and send 576p (n * 50Hz) trough the HDMI/DVI. -- -- Ville Aakko - [EMAIL PROTECTED] ___ 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] vdr-sxfe, radeon x1200 and xv out
Hi, On Di, Jul 15, 2008 at 05:52:44 +0100, Darren Salt wrote: I demand that Halim Sahin may or may not have written... I can't use xineliboutput for my new vdr box using fglrx driver and xv-out. It is unstable and often crashs after switching channels etc. My graphicsadapter is an onboard rs690 based radeon x1200. xf86-video-ati 6.9.0 should be fine with that hardware (apparently); 3D may also work, though I expect that you'll need drm mesa git. Yes this can be the right solution but unfortunately the driver does not support tv-out!! This is the reason why I am trying to use fglrx. Is there a chance to get this work with fglrx? Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe, radeon x1200 and xv out
2008/7/15 Halim Sahin [EMAIL PROTECTED]: This is the reason why I am trying to use fglrx. Is there a chance to get this work with fglrx? If you didn't already try this - try disabling first AGPFastWrites (if the integrated is a PCIe divece inherently, it won't have any effect), and setting BusType PCI in xorg.conf. It won't give you good performance but just might make it more stable. -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe, radeon x1200 and xv out
I demand that Halim Sahin may or may not have written... Hi, On Di, Jul 15, 2008 at 05:52:44 +0100, Darren Salt wrote: I demand that Halim Sahin may or may not have written... I can't use xineliboutput for my new vdr box using fglrx driver and xv-out. It is unstable and often crashs after switching channels etc. My graphicsadapter is an onboard rs690 based radeon x1200. xf86-video-ati 6.9.0 should be fine with that hardware (apparently); 3D may also work, though I expect that you'll need drm mesa git. Yes this can be the right solution but unfortunately the driver does not support tv-out!! You could experiment with 6.9.0 (or a git snapshot) by disabling a small piece of code which causes the TV output to be skipped, I suppose (see src/radeon_atombios.c). No idea whether it'll work, though. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Windows 95. Shrug and Pray. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
