Re: [vdr] PMT in multiple TS packet bug
Hi, I did check the TS stream with dvbsnoop and it is not containing corrupted TS packets. Apparently VDR is able to parse the PMT the first time the data buffer is used. Then, it seems to loose the sync inside the payload. I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem. http://alexw.org.lu/upload/pmt.pid.132.ts Regards, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
> I did check the TS stream with dvbsnoop and it is not containing corrupted TS > packets. > > Apparently VDR is able to parse the PMT the first time the data buffer is > used. Then, it seems to loose the sync inside the payload. > > I have attached a raw TS capture (~10M) containing the PMT pid 132 which is > revealing the problem. > > http://alexw.org.lu/upload/pmt.pid.132.ts Could this patch help with vdr-1.7.3? http://article.gmane.org/gmane.linux.vdr/39097 Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
Hi Mika, I have already applied the mentioned patch ;-) But unfortunately it does not solve the issue. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput + vdpau not ready for prime time
Hi, Gerald Dachs schrieb: >> I read something similar on the MythTV mailinglist. >> >From http://www.gossamer-threads.com/lists/mythtv/users/366684: >>> In the end I believe it was accidental code bugs when he was >>> porting the automatic letterboxing patch over to work with VDPAU >>> that caused him to end up with his OSD ghosted over every image >>> displayed via VDPAU. > > Are you sure that this is the right thread? Someone thinks vdpau > has destroyed his video card. Yeah I thought because of the overlapping pictures this might be related to your problem. It is just a wild guess, so feel free to ignore it. Greetings -Sascha- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote > I have attached a raw TS capture (~10M) containing the PMT pid 132 > which is revealing the problem. Hum - PID 132 is a french dolby track, not a PMT PID... Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On 20.01.2009 16:01, Frank Schmirler wrote: > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote >> I have attached a raw TS capture (~10M) containing the PMT pid 132 >> which is revealing the problem. > > Hum - PID 132 is a french dolby track, not a PMT PID... VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file). Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example. So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Dienstag, 20. Januar 2009, Klaus Schmidinger wrote: > > VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. > This was taken from some patch that implemented PAT/PMT handling > (don't remember which one it was, maybe it was even the code from > reel multimedia - not sure if I've missed mentioning that in the > CONTRIBUTORS file). > > Anyway, I was already wondering if simply using some fixed PMT > pid was such a good idea. What if some other stream uses exactly > that pid? Apparently this is the case in this example. > > So I guess it will be necessary to first collect all pids and then > check whether the default pseudo PMT pid is still free, and if > not, incresase it until a free one is found... > How about just using the original PMT pid? Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537) Thanks for having spotted that. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
Hi Scott! 2009/1/19 Scott Waye : > If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do > any de interlacing in xine, why is this not the same as what my digibox > does? I'm guessing it has something to do with xine outputting a > complete frame when the broadcast sends each field? What you state above is NOT correct. When you use your digiboxx, your TV panel does all interlacing and scaling. To do what your digibox does, you should alwways set the output in the same (interlaced) resolution as the broadast, NOT in the TV's native resolution. And no vertical scaling is allowed before deinterlacing! (but horizontal is allowed) Someone correct me if I'm wrong > What I'd hope > happen (for interlaced material) is that xine receives a field from VDR, > scales it to the X resolution (halfed vertically of course) and sends it > to the the graphics card which just passes it on to the TV which draws > that field. That doesn't seem to happen so where have I gone wrong? In changing the resolution. To achieve what you want, you need to set X to a PAL modeline (720 x 576 interlaced for PAL). However, this is not as straightforward for a VGA card as for full featured DVB cards or set tob boxes. Even after setting the right modeline, a few problems remain: 1) You need to enable sync on vblanck. 2) There is no way to automatically switch the resolution when/if the standard changes 3) The timigns are not exact on VGA (HDMI etc.) outputs The first is not possible on all drivers (i.e. fglrx). For the second problem there are no ready made solutions (but you can of course manually change between modes, and perhaps restart some sowftware when needed). For the third problem, see thread "RGB/PAL over VGA at variable frame rate" for more discussion and patches. Someone correct me if I'm wrong. -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Mon, Jan 19, 2009 at 09:54:18PM +, Scott Waye wrote: > I want to replace my UK Sky digital box with VDR (I only want the free > to air channels) for watching/recording TV over HDMI on my plasma. So > far everything is working OK, I have vdr 1.7.3 and xine running on an > ASUS M2N VM-HDMI (nvidia) mobo with the s2-liplianin drivers for my Nova > SD2 card. My problem is interlacing. I've googled back through the > archives and got a lot of info from there, however I still have one > question and one request. > > If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do > any de interlacing in xine, why is this not the same as what my digibox > does? I'm guessing it has something to do with xine outputting a > complete frame when the broadcast sends each field? What I'd hope > happen (for interlaced material) is that xine receives a field from VDR, > scales it to the X resolution (halfed vertically of course) and sends it > to the the graphics card which just passes it on to the TV which draws > that field. That doesn't seem to happen so where have I gone wrong? > > There's a lot of options for tvtime in xine, TomsMoComp and full > framerate seem popular. What settings are others using? > Hello. Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html Original patches: http://lowbyte.de/vga-sync-fields/ New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that.. There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Tue, 20 Jan 2009 18:19:49 +0200 "Ville Aakko" wrote: > 1) You need to enable sync on vblanck. [Snip] > The first is not possible on all drivers (i.e. fglrx). Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have APIs for waiting for vblank and ISTR seeing a xine option for vblank sync with Xv. Do none of these work with fglrx? Nvidia's settings tool has options to disable vblank sync for OpenGL and video, but I don't know whether by setting it off it disables syncing altogether or by setting it on it forces flip operations to automatically wait for vblank. Another problem is that in interlaced modes on standard graphics cards you get a vblank interrupt for each field with no way of distinguishing between top or bottom fields; getting them the wrong way round is really messy! Certain Matrox cards let applications distinguish between top and bottom fields, but it's only (officially) supported on the TV-out (SDTV) on the second head using DirectFB. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Tue, 20 Jan 2009 18:23:21 +0200 Pasi Kärkkäinen wrote: > Please check this thread: > http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html > > Original patches: http://lowbyte.de/vga-sync-fields/ > > New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 > > Those might help.. they're about getting pure 1:1 interlaced (576i) > RGB output from a VGA card.. and the new version also has some HDTV > stuff, I guess. I don't read german so i'm not familiar with that.. > > There are also patches to maintain perfect field sync to DVB stream to > avoid tearing/stutter/jerkiness. Varying the output frame rate to keep in sync with the input stream is very clever, but I don't understand how it solves the problem of distinguishing between top and bottom fields to sync to. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Tue, Jan 20, 2009 at 04:01:17PM +0100, Frank Schmirler wrote: > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote > > I have attached a raw TS capture (~10M) containing the PMT pid 132 > > which is revealing the problem. > > Hum - PID 132 is a french dolby track, not a PMT PID... > > Cheers, > Frank > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Frank, good shot. VDR is trying to parse PID 132 as if it was a PMT !!! I have added a log message inside device.c and I have found that patPmtParser.PmtPid() returns pid 132 as PMT. The error can be localized in the patPmtParser.PmtPid function. It is a good progress. PAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0 isNITPid = 0 service id = 132, pid = 132 [5832] PMT PID = 132 PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0 pcr = 120 stream type = 02, pid = 120 stream type = 04, pid = 130 'fra' stream type = 04, pid = 131 'eng' stream type = 04, pid = 133 'deu' stream type = 06, pid = 132 AC3 'fra' [5846] PMT PID = 132 [5846] PMT PID = 132 [5846] PMT PID = 132 [5846] ERROR: can't parse PMT ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Tue, Jan 20, 2009 at 04:11:17PM +0100, Klaus Schmidinger wrote: > On 20.01.2009 16:01, Frank Schmirler wrote: > > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote > >> I have attached a raw TS capture (~10M) containing the PMT pid 132 > >> which is revealing the problem. > > > > Hum - PID 132 is a french dolby track, not a PMT PID... > > VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. > This was taken from some patch that implemented PAT/PMT handling > (don't remember which one it was, maybe it was even the code from > reel multimedia - not sure if I've missed mentioning that in the > CONTRIBUTORS file). > > Anyway, I was already wondering if simply using some fixed PMT > pid was such a good idea. What if some other stream uses exactly > that pid? Apparently this is the case in this example. I confirm, we ran into this special situation. > > So I guess it will be necessary to first collect all pids and then > check whether the default pseudo PMT pid is still free, and if > not, incresase it until a free one is found... > Too difficult because a low repetition rate PID can be ommitted by the collector. (DTD pid for example) Why not taking the real PMT pid to create the pseudo PID for the PAT? At the moment I do not really understand why this mechanism is needed in transfer mode. Alex > Klaus > > ___ > 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] Options for deinterlacing (or not)
2009/1/20 Tony Houghton : > On Tue, 20 Jan 2009 18:19:49 +0200 > "Ville Aakko" wrote: > >> 1) You need to enable sync on vblanck. > > [Snip] > >> The first is not possible on all drivers (i.e. fglrx). > > Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have > APIs for waiting for vblank and ISTR seeing a xine option for vblank > sync with Xv. Do none of these work with fglrx? Nvidia's settings tool > has options to disable vblank sync for OpenGL and video, but I don't > know whether by setting it off it disables syncing altogether or by > setting it on it forces flip operations to automatically wait for > vblank. AFAIK this is a known issue with fglrx drivers. The API is there, but with fglrx the detection is (currently) broken, at least on 8.11 (which is what I'm using currently). I think I saw someone in some forum getting vsync working with fglrx but only for 'mplayer -vo gl'. But that was an exception- -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
Klaus Schmidinger wrote: > On 20.01.2009 16:01, Frank Schmirler wrote: > > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote > >> I have attached a raw TS capture (~10M) containing the PMT pid 132 > >> which is revealing the problem. > > > > Hum - PID 132 is a french dolby track, not a PMT PID... > > VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. > This was taken from some patch that implemented PAT/PMT handling > (don't remember which one it was, maybe it was even the code from > reel multimedia - not sure if I've missed mentioning that in the > CONTRIBUTORS file). > > Anyway, I was already wondering if simply using some fixed PMT > pid was such a good idea. What if some other stream uses exactly > that pid? Apparently this is the case in this example. > > So I guess it will be necessary to first collect all pids and then > check whether the default pseudo PMT pid is still free, and if > not, incresase it until a free one is found... Hm - why don't you use the PID of the original PMT? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On 20.01.2009 22:18, Oliver Endriss wrote: > Klaus Schmidinger wrote: >> On 20.01.2009 16:01, Frank Schmirler wrote: >>> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem. >>> Hum - PID 132 is a french dolby track, not a PMT PID... >> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. >> This was taken from some patch that implemented PAT/PMT handling >> (don't remember which one it was, maybe it was even the code from >> reel multimedia - not sure if I've missed mentioning that in the >> CONTRIBUTORS file). >> >> Anyway, I was already wondering if simply using some fixed PMT >> pid was such a good idea. What if some other stream uses exactly >> that pid? Apparently this is the case in this example. >> >> So I guess it will be necessary to first collect all pids and then >> check whether the default pseudo PMT pid is still free, and if >> not, incresase it until a free one is found... > > Hm - why don't you use the PID of the original PMT? Because I don't have it ;-) It would be yet another parameter that needs to be stored in the channels.conf. I'll do it the way I mentioned, just need to give the cPatPmtGenerator the channel in the constructor so that it can choose a PMT pid that is different than any of the channel's other pids. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Tue, Jan 20, 2009 at 05:21:53PM +, Tony Houghton wrote: > Varying the output frame rate to keep in sync with the input stream is > very clever, but I don't understand how it solves the problem of > distinguishing between top and bottom fields to sync to. surely you can distinguish top and bottom fields on older (pre-avivo) Radeon cards. My vga-sync-fields patch exactly uses this feature: ---8<--- #define RADEON_CRTC_STATUS 0x005c #define RADEON_CRTC_CURRENT_FIELD(1 << 3) field = INREG(RADEON_CRTC_STATUS) & RADEON_CRTC_CURRENT_FIELD; ---8<--- BTW: I meanwhile could port the Radeon VGA2SCART thing to Intel i9xx chipsets too. Description of my Intel patch can be found here (sorry only in German): patch version I: http://www.vdr-portal.de/board/thread.php?postid=766459#post766459 patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703 For Intel chipsets you even don't have to tamper with kernel modules like radeon-drm since they already have builtin some key features needed for VGA2SCART frame rate control. This way you now can build very cheap budget VDRs based on modern hardware like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output quality equaling a FF card but at fractional cost. As with former Radeon vga-sync-fields patch even/odd fields are routed straightly from softdecoder to VGA port. No software deinterlacing takes place thus saving CPU power and resulting in an artifact free picture. All you additionally need is a special VGA2SCART adapter cable like this: http://www.vdr-portal.de/board/thread.php?postid=742945#post742945 Because VGA2SCART patches now appear to become more popular in this FF dominated VDR-world:-) VDR distribution easy-vdr just started to integrate Radeon and Intel VGA2SCART patches for everyone use. Please see also http://www.easy-vdr.de/forum/index.php?board=63.0 It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-) Due to -ENOTIME I have not yet integrated my last Intel patches to vga-sync-fields patch version found at http://lowbyte.de/vga-sync-fields/ Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On 21 Jan 2009, at 15:02, Thomas Hilber wrote: > > This way you now can build very cheap budget VDRs based on modern > hardware > like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output > quality > equaling a FF card but at fractional cost. Does it work with 915 hardware as well? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote: > Does it work with 915 hardware as well? Yup, a few days ago I successfully testet the patch on my Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles at about 60%. Please see table at http://www.vdr-portal.de/board/thread.php?postid=784548#post784548 It appears that most of recent Intel based (i9xx graphics) netbooks are suitable for VGA2SCART with frame rate control (synced fields). A complete list of VGA2SCART capable chipsets is under contruction here: http://www.vdr-portal.de/board/thread.php?postid=782181#post782181 legend: a '+' in 'PAL' column means: unsynced (with software deinterlacing) VGA2SCART is possible. a '+' in 'FRC' column means: synced (i.e. frame rate control obsoleting software deinterlacing) VGA2SCART is possible. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On 21 Jan 2009, at 16:17, Thomas Hilber wrote: On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote: Does it work with 915 hardware as well? Yup, a few days ago I successfully testet the patch on my Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles at about 60%. Please see table at http://www.vdr-portal.de/board/thread.php?postid=784548#post784548 It appears that most of recent Intel based (i9xx graphics) netbooks are suitable for VGA2SCART with frame rate control (synced fields). A complete list of VGA2SCART capable chipsets is under contruction here: http://www.vdr-portal.de/board/thread.php?postid=782181#post782181 legend: a '+' in 'PAL' column means: unsynced (with software deinterlacing) VGA2SCART is possible. a '+' in 'FRC' column means: synced (i.e. frame rate control obsoleting software deinterlacing) VGA2SCART is possible. Ok, I have this hardware; http://www.silentpcreview.com/article311-page1.html an asus mainboard i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure with some tweaking, it should be possible to run pure RGB or YPbPr out without using any vga to scart adapter. There's no english howto anywhere? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote: > Ok, I have this hardware; > http://www.silentpcreview.com/article311-page1.html an asus mainboard > i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure > with some tweaking, it should be possible to run pure RGB or YPbPr out > without using any vga to scart adapter. yeah! I guess you even could run interlaced HDMI (with a DVI to HDMI adaptor) with synced fields using that hardware. This would be especially useful for HDTV applications as software deinterlacing there is a real pain. On german vdr-portal 'durchflieger' already published some working configurations with synced fields (frame rate control) over HDMI. The radeon-frc patch README and description is written in English. Please refer to: http://www.vdr-portal.de/board/thread.php?threadid=80567 > > There's no english howto anywhere? sorry, not yet. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
