Re: [vdr] Replay Problems with Extension HD
From: Hannu Tirkkonen
Subject: Re: [vdr] Replay Problems with Extension HD
On 14.10.2010 19.17, Vesa wrote:
From: Rolf Ahrenberg
Would it help to modify the plugin's GetSTC() method only when
replaying?
+ if (Replaying())
+STC -= 50L; // or configurable: 900L *
ReelSetup.STCDelayMs;
Yes, that works. Complete fix for ReelBoxDevice.c around line 996:
- return (stc == 0) ? -1LL : stc;
+ if (Replaying())
+ stc -= 52L;
+ return (stc == 0) ? -1LL : (stc 0x);
With this change Reelbox delivers stc in correct format and timing is
correct for live show. For recordings 52 is suitable mid range
offset on
Yle SD feed. I assume that eHD buffer is for mpeg/h264 and delay is
based on
bit/s.
OMG :) It's really working.
Unfortunately it is not working.. The Working Fix is this:
- return (stc == 0) ? -1LL : stc;
+ if (Transferring()){
+ stc -= 9L;
+ }
+ else {
+ stc -= 52L;
+ }
+ return (stc == 0) ? -1LL : (stc 0x);
Replaying returns always true, Transferring returns true only for live. eHD
seems to need small delay also for live.
With this patch eHD looks usable device. I have to do long time testing for
stability, but so far it is more stable than xine/vdpau based solutions. I'm
using reelbox testing tree version 15208 for reelbox-3 and eHD device
driver.
--
Vesa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
From: Hannu Tirkkonen Sent: Friday, 15 October, 2010 11:18 To: VDR Mailing List Subject: Re: [vdr] Replay Problems with Extension HD Is it still required to modify also the dvbsubtitle.c? No. btw; Your previous patch reelbox-svn15208-vdr.bin for reelbox svn 15208 didn't apply clean to VideoPlayerHd.c. The line 313 in svn 15208 (VideoPlayerHd.c) start with: const UInt repeat = 6; and your patch expect it to start with const UInt repeat = 4; It's easy to fix, but I thought I let you know... Correct patch in the attachment, original was broken (wrong version) as you found. This do not include yet that STC fix. -- Vesa reelbox-svn15208b-vdr.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
From: Rolf Ahrenberg Would it help to modify the plugin's GetSTC() method only when replaying? + if (Replaying()) +STC -= 50L; // or configurable: 900L * ReelSetup.STCDelayMs; Yes, that works. Complete fix for ReelBoxDevice.c around line 996: - return (stc == 0) ? -1LL : stc; + if (Replaying()) + stc -= 52L; + return (stc == 0) ? -1LL : (stc 0x); With this change Reelbox delivers stc in correct format and timing is correct for live show. For recordings 52 is suitable mid range offset on Yle SD feed. I assume that eHD buffer is for mpeg/h264 and delay is based on bit/s. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Replay Problems with Extension HD
Al 12/10/10 18:13, Hannu Tirkkonen: Hi! This is really annoying problem and basically all of the recordings containing dvb subtitles are pretty much useless. The problem exists also on recordings having teletext subtitling, but the teletext plugin have an option for delaying the subtitling. Similar delay as on ttxsubtitles would be nice addition to VDR. Separate and additional delay for live and record play modes. Suitable range would be 0 - 10s. This would fix also other issue than non working output. Sometimes broadcaster do mistake and subtitles timing is wrong. Last time this happened last week with LawOrder, subtitle timing has 4s offset. With DVB subtitle delay settings show would be ok. Now I have only one option, turn subtitles completely off. My opinion is that there is several reason to add DVB subtitle delay setting to VDR menu. To fix non working output devices and to fix temporally miss aligned subtitles. This feature is similar as Lipsync set on all modern AV devices. Audio should be in sync with video, but sometimes it is not. It is good to have lipsync on menu for fixing this temporal but totally annoying issue. For Reelbox plugins: I fixed patch for reelbox-3 svn 15208. Patch on attachment. With this reelbox-3 and with latest hdplayer pause seems to work.. -- Vesa reelbox-svn15208-vdr.bin Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
From: Klaus Schmidinger Sent: Thursday, 14 October, 2010 00:43 If there's something actually wrong with VDR's DVB subtitle code, it should be fixed in VDR. I don't see why we would need a plugin interface here. An output device needs to provide a proper STC in order to sync subtitles. I guess I need to change the description of cDevice::GetSTC() to make this a requirement... Reelbox delivers STC values. Only issue with Reelbox is that STC value seems to be somehow wrong during recording play. STC is correct during live DVB broadcast. The issue is that timing works, but there is 5s offset during recording play. Reelbox do not separate live broadcast and recording play. VDR separate these. One opinion is that VDR recording playback is broken.. Is there any easy place to add delay for subtitling on VDR recording playback code? I would do that hack to my system just to get finally eHD card to use. I assume that I should add some value to STC. Any documentation available about this STC and how it works on VDR? -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Replay Problems with Extension HD
eHD card has now days working plugin for vdr, more info about that here: http://www.vdr-portal.de/board/thread.php?threadid=98019 eHD is stable with latest card firmwares, also for ts playback. Only issue is still that somehow VDR is not compatible with eHD on replay mode. With live tv DVB subtile timing is correct. During replay subtitles still comes 6-7s too early here in Finland. Last real discussion about this bug is from Sat Sep 5 15:09:30 CEST 2009. And still no any real solutions. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
-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. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
-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. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Any really working HD video output systems for VDR?
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 ln 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] eHD and how subtitle timing start work
There has been several discussion about eHD dvb subtitle timing. Vdr works correctly on this area and time subtitles as they should be. Reelbox-plugin do not deliver timing info (STC) with default settings. The catch is soundcard support. For audio delay adjustment reelbox-plugin deliver STC. So just turn Analog audio to Soundcard and STC is delivered to VDR and subtitles are in time. Only issue after this is with replaying recording, it will took some time to get STC to correct value. For this it would be nice to get min and max value for subtitle delay. If delay is out of those limits, vdr would use middle setting. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
