[vdr] Re: PATCHES: vdr-1.2.6 (getSTC and mp2)

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Sven Goethel wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sunday 02 November 2003 23:09, Klaus Schmidinger wrote:
> 
> > Oh, I see (sorry, just briefly looked over the patch and saw that
> > there is a PID set where I didn't expect it).
> >
> > So what do you need this PCR-PID setting for, anyway?
> > After all, in live mode cDvbDevice::SetChannelDevice() does set the
> > PCR PID - or am I missing something here?
> >
> 
> replay modes/plugins has not set it .. :-(
> 
> > > i used the pid type (audio/video/Pcr) paradigma,
> > > just because of some convinient and semantic usage.
> > >
> > > but if you like to use another way .. whatever .. since it is
> > > convinient - at least the ptPcr should be available -
> > > its ok for me - change it.
> > >
> > > but i would love to bring this asap into it, to save users from
> > > patching vdr .. for those two plugins ..
> > > just my humble opinion ;-)
> >
> > If it's just about adding GetSTC() I might consider this for 1.2.6,
> > but then the setting of the PCR PID has to be dropped since that one
> > is already set - or is there a situation where this isn't the case?.
> >
> 
> plugins: vdr-dvd,
> and replay/transport modes ..
> 
> > Also, what's with the 'ePidType type=ptPcr' parameter in GetSTC()?
> > Is this to be called with other 'type's, too?
> 
> i just tried, if the STC is different for the
> ptVideo and ptPcr dvb device handle - but i guess it is not.
> (just a guess)
> 
> the default is ptPcr anyway ..
> 
> but e.g. if dvbplayer, or dvd player needs STC,
> they never opened ptPcr .. so it should be opened
> in case it is not allready ;-)
> 
> >
> > Sorry if my questions seem dumb to you, but I currently
> > don't have the time to look deeper into this, so you'll need to
> > explain to me very detailed what and why you do it ;-) After all,
> > version 1.2.6 is almost about to be released, so I can't add
> > anything that might have unwanted side effects.
> >
> 
> getSTC does not close any handles, and it just uses
> the STC ioctl .. therefore there should not be any sideeffects,
> IMHO.
> 
> cDevice::GetPidHandle just seeks for the given ePidType
> (in the set of pidHandles) and returns the 1st found one,
> or NULL.
> this can be convinient, if someone wants to do something
> with ptVideo/ptAudio, but does not want to struggle through
> the cChannel stuff .. for a allready opened pidHandle ..
> 
> i hope this makes things a little more clearly ..

I've looked a little more into this and saw that, when you
add the PID in GetSTC, you actually add a PID value of '2'
(the enum value of ptPcr), which according to Johannes
Stezenbach (in a PM) is complete nonsense.

I guess the proper way to handle this will be to open a dummy
demux file handle for each full featured DVB card and use that
one for getting the STC. GetSTC() shall not add any PID by
itself, and especially not set an arbitrary value of '2'.

> how about the mp2 PlayAudio patch ?
> 
> as i noted, i have added the same routine for
> transfer mode as well, and mimik the old dd 1st
> behavior. i have tested it with and without bitstreamout.

I want to finish the 1.2 line ASAP to be free for new things in
1.3.x, so I won't add any more stuff that I don't understand 100%.
The GetSTC() thing might be an exception, if and only if it gets
rid of the AddPid() call and does this by using a separate file
handle (let's call it fd_stc), which, as far as I understand this,
just needs to be opened on the demux device and doesn't require
any special PID to be set on.

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.