Hi,
so far I have tested and looked different solutions for VDR video output and it seems that there is no working solutions just now. Only good solution seems to stay on SD video with vdr 1.6.0 and use old FF card as analog output.
List of non-working solutions:
Xine and it's variants: problems with stability, problems with FF/FR.
Softdevice: huge need of CPU for HD
XBMC: not ready for anything
Reelbox EHD: hw works, AV signal quality is ok, but dvb susbtile timing not. Also issues with replaying recordings, FF/FR and jump works with loooooooooooooooooooon delay
Summary: current VDR seems to be quit unusable for anything due lack of working HD video/audio output.
Working video/audio output means these items:
-Video is played with original resolution or scaled with good quality -No drobbed/dublicated frames, frame to frame played as it is -Video in digital format (HDMI or DVI) -Audio played as it is and in _sync_ with video. No delays, no lipsync issues etc. -Audio in digital format (SPDIF or HDMI) -AC3 plays also with out issues like lipsync missed by 10 frames -FF/FR works as it should on recordings -It do not crash
Any plans on anyone to reach this reasonable reguest level of quality?
Regards, Vesa
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc.
VDR User schrieb:
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc.
I agree with VDR User, I use it for months now without problems.
Gerald
Gerald Dachs a écrit :
VDR User schrieb:
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc.
I agree with VDR User, I use it for months now without problems.
Could you please both detail a bit the DVB sources, software versions, plugins, patches, etc. related to HD, that you actually use now ? (DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine plugin, xinelib patches...)
Maybe there is an english howto somewhere ?
Nicolas Huillard schrieb:
Gerald Dachs a écrit :
VDR User schrieb:
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc.
I agree with VDR User, I use it for months now without problems.
Could you please both detail a bit the DVB sources, software versions, plugins, patches, etc. related to HD, that you actually use now ? (DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine plugin, xinelib patches...)
DVB-C, stock Jaunty kernel, vdr 1.6.0 + extension patch v72 + h264 patch, nvidia-driver 180.60, xine-lib 1.2 + vdpau patch r262 + crop patch v5, xineliboutput 1.0.4 + crop patch v5, vdr-sxfe
Maybe there is an english howto somewhere ?
Here it is: install jaunty and add the packages from my repository https://launchpad.net/~gda-dachsweb/+archive/vdr, but there is no support from me. I have not enough time.
Gerald
Pertti Kosunen schrieb:
Gerald Dachs wrote:
DVB-C, stock Jaunty kernel, vdr 1.6.0 + extension patch v72 + h264 patch, nvidia-driver 180.60, xine-lib 1.2 + vdpau patch r262 + crop patch v5, xineliboutput 1.0.4 + crop patch v5, vdr-sxfe
What is crop patch and where do i find it?
It cuts the black borders from the letterbox format: http://vdr-portal.de/board/thread.php?threadid=86804
Gerald
On Fri, 5 Jun 2009 10:06:20 +0200 (CEST) "Gerald Dachs" vdr@dachsweb.de wrote:
Here it is: install jaunty and add the packages from my repository https://launchpad.net/~gda-dachsweb/+archive/vdr, but there is no support from me. I have not enough time.
They look useful, but are the deb source files available so Debian users can build similar packages?
Tony Houghton schrieb:
On Fri, 5 Jun 2009 10:06:20 +0200 (CEST) "Gerald Dachs" vdr@dachsweb.de wrote:
Here it is: install jaunty and add the packages from my repository https://launchpad.net/~gda-dachsweb/+archive/vdr, but there is no support from me. I have not enough time.
They look useful, but are the deb source files available so Debian users can build similar packages?
yes
Gerald
On Fri, 5 Jun 2009 15:06:47 +0200 (CEST) "Gerald Dachs" vdr@dachsweb.de wrote:
Tony Houghton schrieb:
On Fri, 5 Jun 2009 10:06:20 +0200 (CEST) "Gerald Dachs" vdr@dachsweb.de wrote:
Here it is: install jaunty and add the packages from my repository https://launchpad.net/~gda-dachsweb/+archive/vdr, but there is no support from me. I have not enough time.
They look useful, but are the deb source files available so Debian users can build similar packages?
yes
Ah yes, I didn't see the deb-src line before.
On Fri, 05 Jun 2009 09:35:19 +0200 Nicolas Huillard nicolas@huillard.net wrote:
Gerald Dachs a écrit :
VDR User schrieb:
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc.
I agree with VDR User, I use it for months now without problems.
Could you please both detail a bit the DVB sources, software versions, plugins, patches, etc. related to HD, that you actually use now ? (DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine plugin, xinelib patches...)
I think it would also help if we could reach an agreement over the terms "stable" and "good quality" and "everything is working" because they are highly subjective.
For me a "stable" configuration of vdr is one where (I have a dual ff card setup at the moment): - I can record two streams from two different transponders and watch a third one (either from one of the two transponders, a recorded one, or with mplayer) without pixelation, without skips and with no audio/video desyncing - The osd is fast and clear - Zapping from one channel to another takes less then .5 seconds - everything is controlled from the remote
"good quality" in an SD environment means that I am used to the video quality of the s-video output of the FF card to a Mitsubishi VPR with a 100" screen (it isn't blue-ray I know, but except for the resolution, the output quality is really exceptional)
"everything is working" means that I have a computer that I use as an stb (no keyboard, no mouse, no video) and that I can power up with my remote, that is completely controlled via my remote, where vdr is able to autostart and record on its own, where I can burn shows either to DVD or Xvid files, where I can play every media file mplayer can, with PCM or AC3 audio depending on the media, with subtitles in mplayer media, and the occasional streaming to a vlc client around the house
I do have an eHd card I'm playing with, together with an s2-3200 card on a separate machine, I haven't played with xine-vdpau yet, and until I can find a video card that will be able to run vdpau with < 10W consumption I don't think I will be tempted to try it ... we'll see
At the moment I have a running system with one s2-3200, vdr1.7.5, extensions patch, reelbox3, filebrowser,xinemediaplayer (took me about a weekend of fiddling with patches, drivers, small corrections to the reel code, lurking the german boards and swearing, lots of swearing) and some other plugins, hd output on the eHd is really nice, I am not so happy with the quality of SD output either at native resolution or scaled to 1080i .... the non scaled quality is in my opinion much worse than what I have on my FF card, and the scaled quality depends on the media, but it is generally bad, in my opinion.
From what I have understood lurking on the German folders (I'm italian so German is a no-no for me) low sd quality on the ehd is a common complaint from eHd users, and one that won't probably be tackled from Reel since apparently it is a hardware/firmware limitation of the chip used on the eHd and production and support for the this chip has been terminated from the original manufacturer Also, it doesn't look like there will be an 'Oliver Endriss' that takes the situation in hand like it happened with the FF cards firmware and releases updates even if the original chip developer has ceased support. (on the other hand, since I can understand about one word in ten of german and usually use google translator to understand the meaning of the posts, it may be that sd quality output can be fine-tuned to FF quality and I simply don't know how)
This means that if the situation doesn't change (reel multimedia gets the source code for the embedded chip in the eHd and tries to improve on it) the next version of the eHd won't use the same chip/there won't be and eHd anymore, and sd quality won't improve, unless Reel finds a way to improve it using other methods.
Since here in Italy the selection of HD channels not related to football is non-existent (and I'm not interested in football), there has been no incentive for me (so far) to move from a "stable", "good quality" and "working" sd solution to an equivalent hd one with lower quality sd.
Also, I am not using file sharing programs to download hd content and I am not ready to tackle blu-ray yet .
Maybe there is an english howto somewhere ?
Hmm, not that I'm aware of, the most reliable howto is on the german VDR wiki: http://www.vdr-wiki.de/wiki/index.php/OpenSUSE_VDR_DVB-S2_-_Teil2.1:_eHD#Vor...
this covers the ehd and vdr basic install, while for the xinemediaplayer (that requires you to compile a custom version of xine-lib and the xine-hde plugin) I had to delve into the german board and improvise and do some manual changes in order for all the plugins to compile/run correctly on my setup (ubuntu 9.04 32bit) .... from what I understand depending on the host system and the architecture and gcc version and a couple other factors the plugins should compile with minimal adjustments/force you to manually correct compilation errors (that was my case)
It would be great if someone that has a "stable, good quality and working" eHd setup that also outputs "good quality" sd video could step up and point us non german speakers to some documentation/thread (even german would do) and/or patches and/or suggestions about how to obtain good results with the eHd
Regards
Mattia
---MR.---
I think it would also help if we could reach an agreement over the terms "stable" and "good quality" and "everything is working" because they are highly subjective.
For me I'd add a class; "Set-top-box quality"
It would mean that no judder and studder on HD-quality. With VDPAU the problem still might be "50Hz vs 50.02Hz" -thing so you cannot get frame accurate display. With every 5 seconds you might have duplicated display of frame or dropped frame. This is not acceptable by my standards. Typically "Set-top-boxes" can display frame accurate.
You can easily look your own modeline and dump it to a timings analyzator. http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html
From MythTV wiki:
# Modeline "1920x1080@50" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
This gives exact 50Hz 1080p mode. But does your VGA-cards internal clock generator allow exactly 148.500MHz. If VGA can only generate f.ex 148.460MHz clock then you have 49.99Hz output signal. Also is pulse width divisable by 8 etc.
- Jori
jori.hamalainen@teliasonera.com schrieb:
I think it would also help if we could reach an agreement over the terms "stable" and "good quality" and "everything is working" because they are highly subjective.
For me I'd add a class; "Set-top-box quality"
For me there exists another class: "Good enough"
Gerald
On Fri, 5 Jun 2009 11:17:54 +0200 jori.hamalainen@teliasonera.com wrote:
I think it would also help if we could reach an agreement over the terms "stable" and "good quality" and "everything is working" because they are highly subjective.
For me I'd add a class; "Set-top-box quality"
It would mean that no judder and studder on HD-quality. With VDPAU the problem still might be "50Hz vs 50.02Hz" -thing so you cannot get frame accurate display. With every 5 seconds you might have duplicated display of frame or dropped frame. This is not acceptable by my standards. Typically "Set-top-boxes" can display frame accurate.
I've always found [1] that playing TV straight from DVB reception with xine the frame rate is reasonably smooth, but while playing back a recording there are definitely more dropped frames. I would have expected things to be the other way round, but it's occurred to me that with "live" TV xine may be using the source as its clock reference, whereas with recordings it uses the system clock, and there could be a worse discrepancy with the VGA clock in the latter case. Live TV playback could probably only be improved by using the frame rate control patches, but recording playback could be improved by basing all the timings on keeping in sync with the VGA interrupts. All this is made more complicated because were' not using a RTOS.
[1] Both with dfbmga output and Xv with NVidia HDMI.
On Fri, Jun 05, 2009 at 11:17:54AM +0200, jori.hamalainen@teliasonera.com wrote:
It would mean that no judder and studder on HD-quality. With VDPAU the problem still might be "50Hz vs 50.02Hz" -thing so you cannot get frame accurate display. With every 5 seconds you might have duplicated display of frame or dropped frame. This is not acceptable by my
I fully agree. The *only* way to overcome this is by synchronizing VGA video timing to DVB-stream clock.
I realized this for some ATI-Radeon and Intel-GMA hardware. Even the brandnew Intel D945GSEJT now is fully supported with VGA/SCART/DVI/HDMI output.
For further details see:
http://lowbyte.de/vga-sync-fields/ http://vga2scart.gw90.de/ http://www.easy-vdr.de/git?p=frc.git/.git;a=summary git clone git://www.easy-vdr.de/git/frc
This gives exact 50Hz 1080p mode. But does your VGA-cards internal clock generator allow exactly 148.500MHz. If VGA can only generate f.ex 148.460MHz clock then you
with vga-sync-fields patch you always have *exactly* 50Hz since video clock frequency is dynamically controlled and corrected.
have 49.99Hz output signal. Also is pulse width divisable by 8 etc.
this restriction is no longer true for Intel 945Gxx hardware.
cheers Thomas
Am Freitag, den 05.06.2009, 15:42 +0200 schrieb Thomas Hilber:
On Fri, Jun 05, 2009 at 11:17:54AM +0200, jori.hamalainen@teliasonera.com wrote:
It would mean that no judder and studder on HD-quality. With VDPAU the problem still might be "50Hz vs 50.02Hz" -thing so you cannot get frame accurate display. With every 5 seconds you might have duplicated display of frame or dropped frame. This is not acceptable by my
I fully agree. The *only* way to overcome this is by synchronizing VGA video timing to DVB-stream clock.
I realized this for some ATI-Radeon and Intel-GMA hardware. Even the brandnew Intel D945GSEJT now is fully supported with VGA/SCART/DVI/HDMI output.
Could you test your boards with HD-material, for example some movie trailers? Could you please share your results, what resolutions are possible to play and how much the system usage is doing so?
I found the following on VDR-Portal. Your mpstat results for playing SD material [2] and x.264 encoded material [3] from [8]. [4] has a row »HDTV Video Wiedergabe« which says non-fluent playback. [5] claims to be playing 1080p HD material on an ASUS EeePC 901. Specifications for the GMA 950 from Intel state »HDTV 480i/p, 576i/p, 720i/p and 1080i/p display resolution support« [7]. [6] says something similar.
So is the following summary correct? The hardware is capable to play certain HDTV resolutions, but the xf86-video-intel driver does not support it yet.
Thanks,
Paul
[1] http://www.vdr-portal.de/board/thread.php?postid=816759#post816759 [2] http://www.vdr-portal.de/board/thread.php?postid=816443#post816443 [3] http://www.vdr-portal.de/board/attachment.php?attachmentid=22074 [4] http://www.minitechnet.de/asus-n10_5.html [5] http://www.youtube.com/watch?v=JVf3PtNF-j0 [6] http://www.intel.com/design/intarch/applnots/DSS_Appnote_r5.pdf [7] http://www.intel.com/products/chipsets/gma950/index.htm [8] http://www.vdr-portal.de/board/thread.php?postid=816831#post816831
On Thu, Jul 02, 2009 at 10:34:09AM +0200, Paul Menzel wrote:
Could you test your boards with HD-material, for example some movie trailers? Could you please share your results, what resolutions are
no way to play HD-material with this board
So is the following summary correct? The hardware is capable to play certain HDTV resolutions, but the xf86-video-intel driver does not
the hardware is capable to play most HDTV resolutions (over VGA or DVI) and xf86-video-intel does support this. But the hardware is not capable of decoding H.264. At least not today with current linux drivers.
- Thomas
Thomas Hilber wrote:
On Fri, Jun 05, 2009 at 11:17:54AM +0200, jori.hamalainen@teliasonera.com wrote:
It would mean that no judder and studder on HD-quality. With VDPAU the problem still might be "50Hz vs 50.02Hz" -thing so you cannot get frame accurate display. With every 5 seconds you might have duplicated display of frame or dropped frame. This is not acceptable by my
I fully agree. The *only* way to overcome this is by synchronizing VGA video timing to DVB-stream clock.
I realized this for some ATI-Radeon and Intel-GMA hardware. Even the brandnew Intel D945GSEJT now is fully supported with VGA/SCART/DVI/HDMI output.
Need to ask. Nvidia vdpau is not listed so with it there are duplicated or dropped frame in every 5 secs?
-----Original Message----- Behalf Of Mattia Rossi Subject: Re: [vdr] Any really working HD video output systems for VDR?
At the moment I have a running system with one s2-3200, vdr1.7.5, extensions patch, reelbox3, filebrowser,xinemediaplayer (took me about a weekend of fiddling with patches, drivers, small corrections to the reel code, lurking the german boards and swearing, lots of swearing) and some other plugins, hd output on the eHd is really nice, I am not so happy with the quality of SD output either at native resolution or scaled to 1080i .... the non scaled quality is in my opinion much worse than what I have on my FF card, and the scaled quality depends on the media, but it is generally bad, in my opinion.
Reelbox eHD DA is poor, so there is no any reason to use analog output. HDMI output is ok, but there is couple items to remember: chipset have only one scaler/video processor. So if analog output is active, video is for it. HDMI gets same -> video is not pixel to pixel, it is always scaled! To get right quality out of HDMI, turn off analog output completely.
Second issue is caused by HDMI itself, there is very few displays with 576i/480i support. With HDMI eHD reads display capabilities and end result is most of cases 576P/480P even that ui tels 576i/480i. eHD internal processing for i->P is poor, so SD looks quit bad.
When you get combination where eHD outputs pixel to pixel 576i (or what native resolution of video is) signal over HDMI/DVI and TV scales it properly, quality is perfect. Much beter than FF card with RGB, it is clear with comparison how DA-AD process lost one bit of every color channels.
If reelbox-3 plugins would work better (working FF/FR, no delays on replay commands) it is the best video output currently. It outputs original video/audio as it is with out micro stuttering.
Here is proper settings for eHD, when you have HDMI/DVI display and it support all resolutions (576i, 720p and 1080i in Europe)
Output: HDMI Analog Output: off Display Type: 16:9 Aspect Rations: Fill to Aspect Resolution: 1080 Refresh Rate: 50Hz Deinsterlacer for SDTV: Off Resolution change: Media resolution OSD scaling: Fill to screen
With proper display, digital video is now 1:1 on pixel/frame level.
On Fri, 2009-06-05 at 13:19 +0300, Vesa wrote:
-----Original Message----- Behalf Of Mattia Rossi Subject: Re: [vdr] Any really working HD video output systems for VDR?
At the moment I have a running system with one s2-3200, vdr1.7.5, extensions patch, reelbox3, filebrowser,xinemediaplayer (took me about a weekend of fiddling with patches, drivers, small corrections to the reel code, lurking the german boards and swearing, lots of swearing) and some other plugins, hd output on the eHd is really nice, I am not so happy with the quality of SD output either at native resolution or scaled to 1080i .... the non scaled quality is in my opinion much worse than what I have on my FF card, and the scaled quality depends on the media, but it is generally bad, in my opinion.
Reelbox eHD DA is poor, so there is no any reason to use analog output. HDMI output is ok, but there is couple items to remember: chipset have only one scaler/video processor. So if analog output is active, video is for it. HDMI gets same -> video is not pixel to pixel, it is always scaled! To get right quality out of HDMI, turn off analog output completely.
Second issue is caused by HDMI itself, there is very few displays with 576i/480i support. With HDMI eHD reads display capabilities and end result is most of cases 576P/480P even that ui tels 576i/480i. eHD internal processing for i->P is poor, so SD looks quit bad.
When you get combination where eHD outputs pixel to pixel 576i (or what native resolution of video is) signal over HDMI/DVI and TV scales it properly, quality is perfect. Much beter than FF card with RGB, it is clear with comparison how DA-AD process lost one bit of every color channels.
If reelbox-3 plugins would work better (working FF/FR, no delays on replay commands) it is the best video output currently. It outputs original video/audio as it is with out micro stuttering.
First of all, thanks for the explanation, I believe it is the first time I manage to understand why these settings are needed, the automatic translation from google is borderline between funny and completely useless.
Here is proper settings for eHD, when you have HDMI/DVI display and it support all resolutions (576i, 720p and 1080i in Europe)
Output: HDMI Analog Output: off Display Type: 16:9 Aspect Rations: Fill to Aspect Resolution: 1080 Refresh Rate: 50Hz Deinsterlacer for SDTV: Off Resolution change: Media resolution OSD scaling: Fill to screen
With proper display, digital video is now 1:1 on pixel/frame level.
Well, I have to say that I already used this setup since after trying almost all the combinations this was giving me best results. I have a mitsubishi HC-4900 VPR that has no problems displaying 576i/480i through the HDMI connection.
That said, while I agree that for still images and for videos with very small amounts of panning the eHd image is much better (color definition, sharpness) in all other cases , and much more evident with low bitrate streams (that alas are almost the norm with Sky Italy), the mpeg rendering of the FF card is much more smooth than the eHd, the eHD also has problems with the rendering of white lines and/or characters (jagged lines, blurry borders) .
So, either something's still not working with my setup (no pixel to pixel output from the eHd, is there any way I can check ?) or I stand with my s_subjective_ opinion that the FF output, in terms of MPEG rendering is much more polished than the eHd output for SD content
I sincerely hope that I'm wrong, and that I still have to find the correct setup for the eHd that will allow it to output an unprocessed/uninterlaced image
Regards
Mattia
-----Original Message-----
That said, while I agree that for still images and for videos with very small amounts of panning the eHd image is much better (color definition, sharpness) in all other cases , and much more evident with low bitrate streams (that alas are almost the norm with Sky Italy), the mpeg rendering of the FF card is much more smooth than the eHd, the eHD also has problems with the rendering of white lines and/or characters (jagged lines, blurry borders) .
I have not seen those kinds issues with eHD card. But I use on my setup separate video processor (DVDO VP30 with abt102) for deinterlacing and scaling to 1080P.
I can get jagged lines when I use eHD own deinterlacer, it seems to miss even/odd field detection sometimes. Also TV:s own deinterlacer seems to lost half of resolution when video is 576i when comparing to DVDO.
Are you absolutely sure that signal is 576i on HDMI? What TV tells about video? It can be that also Mitsubishi sends 576P signal. True 576i/486i support is rare on HDMI devices, specification recommend always to use at least 576P, sd resolutions are possible but not recommended.. This is same also on my own tv, it do not support officially 576i. But with suitable devices I can feed 576i HDMI to it and it works. Normal BD player and eHD refuses to send 576i to it and end result is 576P even that source is in 576i mode by ui.
On Fri, Jun 05, 2009 at 11:40:44PM +0300, Vesa wrote:
But with suitable devices I can feed 576i HDMI to it and it works. Normal BD player and eHD refuses to send 576i to it and end result is 576P even that source is in 576i mode by ui.
You need to disable the analog output to get 576i over HDMI.
On Fri, 2009-06-05 at 23:40 +0300, Vesa wrote:
-----Original Message----- I have not seen those kinds issues with eHD card. But I use on my setup separate video processor (DVDO VP30 with abt102) for deinterlacing and scaling to 1080P.
Well, your setup is a little different than what I have.
I can get jagged lines when I use eHD own deinterlacer, it seems to miss even/odd field detection sometimes. Also TV:s own deinterlacer seems to lost half of resolution when video is 576i when comparing to DVDO.
Are you absolutely sure that signal is 576i on HDMI? What TV tells about video? It can be that also Mitsubishi sends 576P signal. True 576i/486i support is rare on HDMI devices, specification recommend always to use at least 576P, sd resolutions are possible but not recommended..
I am reasonably sure since it is a supported resolution in the VPR manual, and it is the listed resolution on the VPR on screen display.
At this point there can be three different explanations:
1 - the internal scaler of my VPR behaves differently when it receives 576i from the s-video port and the HDMI port
2 - I'm doing something wrong with the eHd output 3 - The ehd output - in my conditions - is really worse than the ff card
Will experiment further, and will let you know when/if I come to any conclusion
Thanks and regards
Mattia
On Fri, Jun 5, 2009 at 12:35 AM, Nicolas Huillardnicolas@huillard.net wrote:
Could you please both detail a bit the DVB sources, software versions, plugins, patches, etc. related to HD, that you actually use now ? (DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine plugin, xinelib patches...)
I use DVB-S sources on VDR-1.7.7 with just basic plugins and xine-vdpau (r260). No special patches are needed for/to anything although I do use vdr-1.7.3-ntsc-fps.diff which changes the default framespersecond to 30.0 (NTSC) instead of 25.0 (PAL), although I've heard this is not necessary now that VDR uses mpeg-ts. It's really straight forward.
Maybe there is an english howto somewhere ?
There are english forums at:
http://dvbn.happysat.org (they have a linux specific forum there which is very active) http://www.hoochvdr.info (good howtos but not actively kept up anymore _I think_)
vdrportal looks like a good forum but as already pointed out, it's in German and thus practically useless for all of us english-speaking users.
On a side note I just want to say that I see some posts here about peoples expectations.. "I want to record X, and Y, while playing Z with no dropped frames, etc etc". I hope you guys understand that things like that are not only related to software. Your hardware is a factor and if your hardware can't do it then it can't do it and doesn't automatically mean there's a problem with your software. Your signal matters too.
great English howto
HTPC DVB-S2 VDR 1.7.7 Howto http://ubuntuforums.org/showthread.php?t=1126258
Could you please both detail a bit the DVB sources, software versions, plugins, patches, etc. related to HD, that you actually use now ? (DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine plugin, xinelib patches...)
I use DVB-S sources on VDR-1.7.7 with just basic plugins and xine-vdpau (r260). No special patches are needed for/to anything although I do use vdr-1.7.3-ntsc-fps.diff which changes the default framespersecond to 30.0 (NTSC) instead of 25.0 (PAL), although I've heard this is not necessary now that VDR uses mpeg-ts. It's really straight forward.
Maybe there is an english howto somewhere ?
There are english forums at:
http://dvbn.happysat.org (they have a linux specific forum there which is very active) http://www.hoochvdr.info (good howtos but not actively kept up anymore _I think_)
vdrportal looks like a good forum but as already pointed out, it's in German and thus practically useless for all of us english-speaking users.
On Fri, 5 Jun 2009 08:49:02 -0700 VDR User user.vdr@gmail.com wrote:
--- snip -----
On a side note I just want to say that I see some posts here about peoples expectations.. "I want to record X, and Y, while playing Z with no dropped frames, etc etc". I hope you guys understand that things like that are not only related to software. Your hardware is a factor and if your hardware can't do it then it can't do it and doesn't automatically mean there's a problem with your software. Your signal matters too.
I can't speak for the other participants of this thread, but I consider myself an 'old hand' of vdr having started fiddling with this great piece of software since version 1.0 (2002) and I am used to what for users of a full featured dvb-s card is normal: rock solid stability, excellent video quality, no dropped frames whatsoever, up to the bandwidth limit of the card (about 20Mbit/s), great zapping time, time shifting as the norm, multiple card installations without conflicts and so on.
The only thing the FF card won't do is play/replay HD content and while this is still not so important at the moment (at least in Italy) since we're used to such a great level of quality it will be hard to obtain the same results with a new generation solution.
The need for time in such a discovery process, at least on my part, is fully understood, I only wish that sometimes the guys from Reel would provide a little more documentation (in english) about how they do some things in the avantgarde, but this is probably what is actually giving the avantgarde the edge over a normal vdr install, so I won't complain.
Regards
Mattia
---MR.---
On Mon, Jun 08, 2009 at 09:40:04PM +0200, Mattia Rossi wrote:
The need for time in such a discovery process, at least on my part, is fully understood, I only wish that sometimes the guys from Reel would provide a little more documentation (in english) about how they do some things in the avantgarde, but this is probably what is actually giving the avantgarde the edge over a normal vdr install, so I won't complain.
Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest...
On Mon, Jun 8, 2009 at 8:54 PM, Georg Acheracher@in.tum.de wrote:
Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest...
Great! Georg, can you let us know why FF/FR and pause/play handling within VDR with reelbox-3 is so laggy? It makes jumping, searching and seeking within VDR almost unusable.
Is there anything we can do to fix this?
On Mon, Jun 08, 2009 at 09:09:06PM +0100, Morfsta wrote:
On Mon, Jun 8, 2009 at 8:54 PM, Georg Acheracher@in.tum.de wrote:
Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest...
Great! Georg, can you let us know why FF/FR and pause/play handling within VDR with reelbox-3 is so laggy? It makes jumping, searching and seeking within VDR almost unusable.
Ouch, I expected more technical questions ;-) At least for the reelvdr-base, I don't see any special handling for these cases. All the dirty stuff is done in the plugin and and on the DeCypher-side...
Is there anything we can do to fix this?
Send me a full "patched" vdr-package that shows this behavior...
On Mon, 2009-06-08 at 21:54 +0200, Georg Acher wrote:
On Mon, Jun 08, 2009 at 09:40:04PM +0200, Mattia Rossi wrote:
The need for time in such a discovery process, at least on my part, is fully understood, I only wish that sometimes the guys from Reel would provide a little more documentation (in english) about how they do some things in the avantgarde, but this is probably what is actually giving the avantgarde the edge over a normal vdr install, so I won't complain.
Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest...
Hi Georg, sorry if that came out as 'they are hiding something', I was really thinking more in terms of 'there are so many variables that the best combination is probably achieved in an environment where the user has much less control as we have in a custom vdr compiled environment, without even taking into account the endless combinations of display devices that people will want to connect to the eHd'
That said, I really really would like a different option than 'don't use the scaler on the eHd-HDMI output, it's crap', is there a way to change the scaling algorithm it uses ?
Is there any other setting we can work on regarding the eHd outputs, even if they are not listed in the reelbox-3 setup ?
For example, I am using the coax digital output on the eHd mini-din, instead of the pass through HDMI (the HDMI cable goes straight to the VPR, the coax cable goes to my main amp), I had to change a couple of lines in the reelbox-3 plugin in order to allow for AC3 to pass through the digital output. The option was there, it just wasn't compiled in because of REELBOXLITE ifdefs
What I would like to achieve is decent quality (either scaled or unscaled) SD MPEG-2 output, and by decent I mean at least at the same quality of the MPEG-2 output of a FF card without having to use a 2Keuro deinterlacer. Please note that I'm talking about MPEG processing quality, not still image quality
I understand that this is not easy to fine tune because of all the different variables and because of all the 'not straightforward' test environments every single vdr user will have set up.
At the moment my vdr 1.7.x install is really basic (vdr, extensions patch, reelbox3 filebrowser xinemediaplayer and menuorg plugins) and I am completely satisfied by the stability (both of vdr and of the eHd) , I even don't notice the problems with the recordings handling (the single frame forward in a recording isn't really working, it looks like it is skipping from i-frame to i-frame (doesnt'do that when going backwards, it is the opposite behaviour as with the ff card, where forward skipping works, while backward skipping goes from i_frame to i-frame ..)
If this is still not technical enough I'll go back to my test machine, experiment some more, and come back with more detailed questions ...
Thanks
Mattia
On Tue, Jun 09, 2009 at 11:44:29AM +0200, Mattia Rossi wrote:
Hi Georg, sorry if that came out as 'they are hiding something', I was really thinking more in terms of 'there are so many variables that the best combination is probably achieved in an environment where the user has much less control as we have in a custom vdr compiled environment, without even taking into account the endless combinations of display devices that people will want to connect to the eHd'
That said, I really really would like a different option than 'don't use the scaler on the eHd-HDMI output, it's crap', is there a way to change the scaling algorithm it uses ?
Is there any other setting we can work on regarding the eHd outputs, even if they are not listed in the reelbox-3 setup ?
Not really. You can either use upscaling without deinterlacing (and get tearing for real interlaced moving signals) or use the chips "deinterlacer". That is effectively independent scaling of both fields, so the field order is correct, but fine details show horizontal ghost lines as the interpolation doesn't know anything about the full context. It depends a bit on the display how visible these lines can be seen, some displays seem to have their own filtering and hide them better.
There is a third possibility that is currently not settable: Blending. That mixes both fields together. So still pictures are sharp and movements are "only" blurred and not teared. I can enable it in a "experimental" linux.bin.
BTW: We chose the DeCypher despite "a real" deinterlacer was missing at the time, because we were told that it will be enabled later. The rest is history...
For example, I am using the coax digital output on the eHd mini-din, instead of the pass through HDMI (the HDMI cable goes straight to the VPR, the coax cable goes to my main amp), I had to change a couple of lines in the reelbox-3 plugin in order to allow for AC3 to pass through the digital output. The option was there, it just wasn't compiled in because of REELBOXLITE ifdefs
That was because the MiniPCI-Card for the Lite used a DeCypher-revision with a dead SPDIF-port. So we need to feed the AC3 SPDIF output over the main sound card. The AVG-card has a working SPDIF, so the mainboard sound is used only for PCM (if enabled).
What I would like to achieve is decent quality (either scaled or unscaled) SD MPEG-2 output, and by decent I mean at least at the same quality of the MPEG-2 output of a FF card without having to use a 2Keuro deinterlacer. Please note that I'm talking about MPEG processing quality, not still image quality
You can output 576i over HDMI and let the display do the deinterlacing. But there is a dependency with the analog output that allows only 576p when the analog port should emit 576i (CVBS etc.). For 576i over HDMI you need to switch the analog port completely off.
I understand that this is not easy to fine tune because of all the different variables and because of all the 'not straightforward' test environments every single vdr user will have set up.
At the moment my vdr 1.7.x install is really basic (vdr, extensions patch, reelbox3 filebrowser xinemediaplayer and menuorg plugins) and I am completely satisfied by the stability (both of vdr and of the eHd) , I even don't notice the problems with the recordings handling (the single frame forward in a recording isn't really working, it looks like it is skipping from i-frame to i-frame (doesnt'do that when going backwards, it is the opposite behaviour as with the ff card, where forward skipping works, while backward skipping goes from i_frame to i-frame ..)
I guess the vdr 1.7 has it's own intelligence about frame-precise playback for TS that doesn't match the requirements of the plugin... It took us quite a while to make it work almost as responsive as on the FF, maybe there are some dependencies with our "old" 1.4. But up to now, I had no time to try 1.7...
On Wed, 2009-06-10 at 00:50 +0200, Georg Acher wrote:
On Tue, Jun 09, 2009 at 11:44:29AM +0200, Mattia Rossi wrote:
Is there any other setting we can work on regarding the eHd outputs, even if they are not listed in the reelbox-3 setup ?
Not really. You can either use upscaling without deinterlacing (and get tearing for real interlaced moving signals) or use the chips "deinterlacer". That is effectively independent scaling of both fields, so the field order is correct, but fine details show horizontal ghost lines as the interpolation doesn't know anything about the full context. It depends a bit on the display how visible these lines can be seen, some displays seem to have their own filtering and hide them better.
Ok, will try to improve a little bit on the display side (i.e. bring my test machine to a couple of friend's houses and test with different VPRs, plasmas). I haven't found much documentation for my particular hardware, but it looks like scaling from 480i and 576i isn't really what it is best at ....
There is a third possibility that is currently not settable: Blending. That mixes both fields together. So still pictures are sharp and movements are "only" blurred and not teared. I can enable it in a "experimental" linux.bin.
That would be great, and if you manage to get a test build I would be willing to experiment
BTW: We chose the DeCypher despite "a real" deinterlacer was missing at the time, because we were told that it will be enabled later. The rest is history...
Alas, that happens too often with manufacturers
You can output 576i over HDMI and let the display do the deinterlacing. But there is a dependency with the analog output that allows only 576p when the analog port should emit 576i (CVBS etc.). For 576i over HDMI you need to switch the analog port completely off.
Understood.
I guess the vdr 1.7 has it's own intelligence about frame-precise playback for TS that doesn't match the requirements of the plugin... It took us quite a while to make it work almost as responsive as on the FF, maybe there are some dependencies with our "old" 1.4. But up to now, I had no time to try 1.7...
Well, while this looks like a show stopper for other users, it really isn't for me (and my users) since we mainly use the skip fwd and skip backward functions when replaying
Thanks and regards
Mattia
One "problem" with vdr is that it is not obvious from this list when people are just happy and thing are just working fine.
Maybe such success stories are posted to the VDR portal/forum. But that is mostly in German, so not obvious to us English speakers. (Lack of German is failing on our part, I am sure, but so things are).
People only post to this list when things are wrong, so things like software decoding, vdpau etc etc seems difficult and next to impossible.
On Thu, 2009-06-04 at 21:42 -0700, VDR User wrote:
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Georg Acher -
Gerald Dachs -
Goga777 -
jori.hamalainen＠teliasonera.com -
Malcolm Caldwell -
Mattia Rossi -
Morfsta -
Nicolas Huillard -
Paul Menzel -
Pertti Kosunen -
Thomas Hilber -
Tommi Lundell -
Tony Houghton -
VDR User -
Vesa