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 ??
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 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.
Motion search mode finds and follows motion vectors for accurate interpolation. This is the TomsMoComp deinterlacer from DScaler. ---
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.
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.
On Tue, Jul 15, 2008 at 9:54 AM, Goga777 goga777@bk.ru 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.....?
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
2008/7/15 Jukka Vaisanen Jukka.Vaisanen@exomi.com:
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.
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: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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 Jukka.Vaisanen@exomi.com:
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.
2008/7/15 Jukka Vaisanen Jukka.Vaisanen@exomi.com:
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
I'd try to make a modeline:
$ gtf 720 576 50
# 720x576 @ 50.00 Hz (GTF) hsync: 29.65 kHz; pclk: 26.57 MHz Modeline "720x576_50.00" 26.57 720 736 808 896 576 577 580 593 -HSync +Vsync
$ gtf 720 576 100
# 720x576 @ 100.00 Hz (GTF) hsync: 61.10 kHz; pclk: 58.66 MHz Modeline "720x576_100.00" 58.66 720 760 840 960 576 577 580 611 -HSync +Vsync
(if these blow up your 50'' fullHD plasma, you're on your own - try them at your own risk!)
I'd suspect VDR+xinelibout would not support this out of the box. You probably need to make a script or something to change resolutions when needed. Also, xinelibout might not like resolution switches on the fly. But if this is the case, it could probably be worked around by making xinelibout / X part a frontend (I believe this is possible and a very common setup anyways), and restarting it when needed.
OTOH, I don't see much gain in doing the above compared to the deinterlacing in software and then scaling, apart from saving some CPU cycles. I'd doubt any external display could do a better job, though then again, I haven't had any experience with those modern (post-4:3 CRT era TV) displays =)
- Ville
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=947830&page=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 have often wondered how vdr-xine or xineliboutput would implement dynamic resolution switching. It would be easy to upscale everything to a higher resolution like 1080p. But what if your tv can handle only 1080i at best. It would be better to switch resolution when broadcasts change between 1080i and 720p on a program-to-program basis.
Stuart
--- Ville Aakko ville.aakko@gmail.com wrote:
2008/7/15 Jukka Vaisanen Jukka.Vaisanen@exomi.com:
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
I'd try to make a modeline:
$ gtf 720 576 50
# 720x576 @ 50.00 Hz (GTF) hsync: 29.65 kHz; pclk: 26.57 MHz Modeline "720x576_50.00" 26.57 720 736 808 896 576 577 580 593 -HSync +Vsync
$ gtf 720 576 100
# 720x576 @ 100.00 Hz (GTF) hsync: 61.10 kHz; pclk: 58.66 MHz Modeline "720x576_100.00" 58.66 720 760 840 960 576 577 580 611 -HSync +Vsync
(if these blow up your 50'' fullHD plasma, you're on your own - try them at your own risk!)
I'd suspect VDR+xinelibout would not support this out of the box. You probably need to make a script or something to change resolutions when needed. Also, xinelibout might not like resolution switches on the fly. But if this is the case, it could probably be worked around by making xinelibout / X part a frontend (I believe this is possible and a very common setup anyways), and restarting it when needed.
OTOH, I don't see much gain in doing the above compared to the deinterlacing in software and then scaling, apart from saving some CPU cycles. I'd doubt any external display could do a better job, though then again, I haven't had any experience with those modern (post-4:3 CRT era TV) displays =)
- Ville
--
Ville Aakko - ville.aakko@gmail.com
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
__________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
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=947830&page=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
-
Goga777 -
Jukka Vaisanen -
Lauri Tischler -
Morfsta -
Pasi Kärkkäinen -
Petri Hintukainen -
Stuart Morris -
Ville Aakko