You can subscribe to this list here.
2003 |
Jan
|
Feb
(30) |
Mar
(3) |
Apr
(17) |
May
(17) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: John A. <Jo...@ad...> - 2003-02-21 11:15:00
|
Robert =20 Thanks for having a look over what I've done so far, very helpful = indeed. See my comment on the issues you've raised below. =20 Cheers =20 John =20 > Do you have some mechanism to root out duplicate entries? I use the the Description.ID property as the key. > I'd call these methods "AttachToTIF" and "DetachFromTIF" to make it = clear > which component the one being attached is.=20 Fair enough. I'll change that. =20 > You seem to have a bug in there, > though: If I understand your code correctly, you are retrieving the > services on a "Program Changed" notification. Why that? You should do = it on > a "Service Changed" notification. Yes, I had spotted that too and I'll change that today. > But there is a bigger problem: You are doing all this in the callback > function from the TIF, which is a no-no, as you may be blocking the = TIF. > You are supposed to do the retrieval from a different thread, e.g. by > posting an application-specific message to the main window thread, and = do > the retrieval in your windows message handler proc... Good spot, I'd missed that bit in the docs on first reading. I'll sort = that out today too. All I need to do is delay my updating of the tables = when the user asks to see the changes rather than when they happen, that = should keep our calls back in the window thread and allow the TIF to be = unblocked. > I'm not quite clear how you keep the relation between a TuneRequest = object > and the application-specific information...? Not sure what you're asking here, The TuneInfo object holds a single = ITuneRequest object and we can attach any number of properties to this = object, So far I've added Name which is initialised to Description.Name = and a keyed number which will be user definable. I'll add IsFavourite = and maybe some way of changing the order of channels later. John |
From: Robert S. <rob...@gm...> - 2003-02-21 09:29:50
|
From: "John Adcock" <Jo...@ad...> > Just a quick update on where I am with the "Guide Store Loader" > component I'm putting together. Wow, you're quite busy there :-) > 1) load up previously saved Tune Requests > 2) Attach to a filter graph, find and connect to the TIF > to listen for updates > 3) Save all the Tune Requests Do you have some mechanism to root out duplicate entries? > My names for things are probably completely rubbish but here is > an outline of what each does > > coclass TuneRequestStore (interface ITuneRequestStore) > this holds a COM array of all the tune info allows supports > Load, Save, AttachTIF I'd call these methods "AttachToTIF" and "DetachFromTIF" to make it clear which component the one being attached is. You seem to have a bug in there, though: If I understand your code correctly, you are retrieving the services on a "Program Changed" notification. Why that? You should do it on a "Service Changed" notification. But there is a bigger problem: You are doing all this in the callback function from the TIF, which is a no-no, as you may be blocking the TIF. You are supposed to do the retrieval from a different thread, e.g. by posting an application-specific message to the main window thread, and do the retrieval in your windows message handler proc... > coclass TuneInfo (interface ITuneInfo) > Holds a single tune request as well as the name of the channel and > other info at that level as well as an array of ProgramInfo objects > holding any guide info I'm not quite clear how you keep the relation between a TuneRequest object and the application-specific information...? Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: John A. <Jo...@ad...> - 2003-02-21 08:04:05
|
Just a quick update on where I am with the "Guide Store Loader" component I'm putting together. It's almost working properly. It now can=20 1) load up previously saved Tune Requests 2) Attach to a filter graph, find and connect to the TIF to listen for updates 3) Save all the Tune Requests My names for things are probably completely rubbish but here is an outline of what each does coclass TuneRequestStore (interface ITuneRequestStore) this holds a COM array of all the tune info allows supports Load, Save, AttachTIF coclass TuneInfo (interface ITuneInfo) Holds a single tune request as well as the name of the channel and other info at that level as well as an array of ProgramInfo objects holding any guide info coclass ProgramInfo (interface IProgramInfo) Holds program information At the moment the program information doesn't yet work and the save still saves too much info. I'll try and fix both this weekend. John |
From: <li...@mi...> - 2003-02-18 19:57:02
|
I'm not sure how helpful it'll be to you, but I've uploaded the source to the application I made to test the driver and view all the channels (except the radio channels that cause the mystery crash within the Cyberlink audio decoders). It has several flaws, like it crashing inexplicably on John's computer (although he could investigate that now), the driver name being hardwired in (I've not got driver selection working yet, I think I need to save the whole property bag instead of the CLSID, since that's just for KsProxy.ax), and the wrong aspect ratio seemingly being selected by OverlayMixer2 all the time, although I suspect that'd be fairly easy to fix since it's being fed the right frame size (e.g. just need to set the output size to the input size manually, or somesuch). Anyway, it also shows how I originally stored my channels if you're interested in my bizarre registry scheme. I also wasn't sure how to add those funny tags John put on the driver files so they're not in there, but I think everything else is right. Thanks, Colin |
From: John A. <Jo...@ad...> - 2003-02-18 19:13:03
|
> I'll let you know how it goes. Just to give you a flavour here is the xml for a channel with the code I'm using at the moment <Channel1 clsid=3D"{15D6504A-5494-499C-886C-973C9E53B9F1}"> <Tuning_20Space vt=3D"13" = clsid=3D"{C6B14B32-76AA-4A86-A7AC-5C79AAF58DA7}"> <Name vt=3D"8">SimpleTV</Name>=20 <Description vt=3D"8">SimpleTV DVB Tuning Space</Description>=20 <Network_20Type vt=3D"8">{216C62DF-6D7F-4E9A-8571-05F14EDB766A}</Network_20Type>=20 <Default_20Locator vt=3D"13" clsid=3D"{9CD64701-BDF3-4D14-8E03-F12983D86664}"> <Frequency vt=3D"3">481833</Frequency>=20 <InnerFECMethod vt=3D"3">1</InnerFECMethod>=20 <InnerFECRate vt=3D"3">2</InnerFECRate>=20 <OuterFECMethod vt=3D"3">-1</OuterFECMethod>=20 <OuterFECRate vt=3D"3">-1</OuterFECRate>=20 <ModulationType vt=3D"3">3</ModulationType>=20 <SymbolRate vt=3D"3">6900000</SymbolRate>=20 <Bandwidth vt=3D"3">8</Bandwidth>=20 <LPInnerFECMethod vt=3D"3">-1</LPInnerFECMethod>=20 <LPInnerFECRate vt=3D"3">-1</LPInnerFECRate>=20 <HierarchyAlpha vt=3D"3">0</HierarchyAlpha>=20 <GuardInterval vt=3D"3">1</GuardInterval>=20 <TransmissionMode vt=3D"3">1</TransmissionMode>=20 <OtherFrequencyInUse vt=3D"11">0</OtherFrequencyInUse>=20 </Default_20Locator> <System_20Type vt=3D"3">1</System_20Type>=20 <Network_20ID vt=3D"3">0</Network_20ID>=20 </Tuning_20Space> <Locator vt=3D"13" clsid=3D"{9CD64701-BDF3-4D14-8E03-F12983D86664}"> <Frequency vt=3D"3">481833</Frequency>=20 <InnerFECMethod vt=3D"3">-1</InnerFECMethod>=20 <InnerFECRate vt=3D"3">-1</InnerFECRate>=20 <OuterFECMethod vt=3D"3">-1</OuterFECMethod>=20 <OuterFECRate vt=3D"3">-1</OuterFECRate>=20 <ModulationType vt=3D"3">3</ModulationType>=20 <SymbolRate vt=3D"3">-1</SymbolRate>=20 <Bandwidth vt=3D"3">8</Bandwidth>=20 <LPInnerFECMethod vt=3D"3">1</LPInnerFECMethod>=20 <LPInnerFECRate vt=3D"3">0</LPInnerFECRate>=20 <HierarchyAlpha vt=3D"3">-1</HierarchyAlpha>=20 <GuardInterval vt=3D"3">1</GuardInterval>=20 <TransmissionMode vt=3D"3">1</TransmissionMode>=20 <OtherFrequencyInUse vt=3D"11">0</OtherFrequencyInUse>=20 </Locator> <Original_20Network_20ID vt=3D"3">9018</Original_20Network_20ID>=20 <Transport_20Stream_20ID vt=3D"3">8197</Transport_20Stream_20ID>=20 <Service_20ID vt=3D"3">8261</Service_20ID>=20 </Channel1> Note that I shouldn't need to save the Tuning Space information but apart from that it's working OK and needs no knowledge of the innards of the ITuneRequest through the magic of IPersistPropertyBag. John |
From: John A. <Jo...@ad...> - 2003-02-18 18:57:16
|
> > [service database needed] > > > Point taken :) > > > I'm planning to have a first look at it today. > My first attempt can only be described as a failure :( > The IPersistPropertyBag interface on the ITuneRequests=20 > doesn't seem to store either the identity or the real locator=20 > information. I think I've found my problem and am working on a basic channel store implementation. It will be fairly quick and dirty to start off with but should be usable for basic use. I'll hopefully check in a first cut tomorrow afternoon and then test it properly tomorrow evening. I'll let you know how it goes. John |
From: John A. <Jo...@ad...> - 2003-02-18 08:00:10
|
> [service database needed] > > Point taken :) > > I'm planning to have a first look at it today. My first attempt can only be described as a failure :( The IPersistPropertyBag interface on the ITuneRequests doesn't seem to store either the identity or the real locator information. > On the database issue, I finally understand what the=20 > Microsoft Unified Tuning Model is supposed to be for. You are=20 > supposed to have "abstract" tune requests your application=20 > retrieves from somewhere and puts on a component (probably=20 > the video control) to tune into that service.=20 Glad you are coming round... > The application=20 > is not supposed to be concerned with the details of the tune=20 > request, not even if it's analog or digital TV or whatever. For the video control it doesn't matter but I think it needs to be able to tell if it's analogue as there is no network provider for analogue so the graph building is very different. > The problem is that this "somewhere", the infamous "Guide=20 > Store", has not been implemented by Microsoft (yet?), that's=20 > why the entire idea breaks, and the application _does_ need=20 > to bother with the details of the tune request, and know=20 > which parameters to fill in there. Not if "someone" has set up the tuningspace properly for you. I think it's possible to have everything work without too much knowledge of the way the parameters work assuming we build a guide store. =20 Also the interfaces on the COM objects should allow you to create and destroy them in a generic way without knowing the actual details. > So the "right" database solution, as intended by Microsoft,=20 > would be a "Guide Store", which stores tune request objects.=20 > However, I think that is up to Microsoft to implement, as I'm=20 > not sure it can be done without them (or can it?).=20 It can. > That means=20 > whatever solution we come up with would be a "stopgap"=20 > solution until Microsoft get their act together and deliver=20 > fully functional components. My conclusion is that we can=20 > thus go for a "quick&dirty" solution :) I'd like to build a nice interface but behind that there may be a quick and dirty implementation. I'll start looking at it today. > I am still having some headaches with the TIF, though. For=20 > one, it always barfs on the same 6 services in the PREMIERE=20 > bouquet (GetServiceProperties returns 0x80040005), and then=20 > it apparently has a bug which causes it to get confused when=20 > the frequency is switched too often - GetServiceProperties=20 > will then return some bogus number, which does not seem to be=20 > a legitimate error code. I will try if maybe pausing or=20 > stopping the filter graph and then rerunning it makes the TIF=20 > feel more comfortable with the frequency switching... Did you meet with MS? Do you have a good bug reporting channel so that hopefully we can get some of this fixed in DX 10? John |
From: John A. <Jo...@ad...> - 2003-02-18 07:49:59
|
> Has SourceForge lost the archive of this mailing list? When I=20 > visit the Project Mailing Lists page on their website, I find: I think it takes a few days for the archive to be set up, seems to be there now. John |
From: Robert S. <rob...@gm...> - 2003-02-17 17:14:36
|
Has SourceForge lost the archive of this mailing list? When I visit the Project Mailing Lists page on their website, I find: bdadev-cvs (not yet archived) (go to Subscribe/Unsubscribe/Preferences) cvs commits to the project bdadev-discuss (not yet archived) (go to Subscribe/Unsubscribe/Preferences) Discussion about BDA developement :( Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: Robert S. <rob...@gm...> - 2003-02-17 16:58:53
|
From: "John Adcock" <Jo...@ad...> [service database needed] > Point taken :) > I'm planning to have a first look at it today. On the database issue, I finally understand what the Microsoft Unified Tuning Model is supposed to be for. You are supposed to have "abstract" tune requests your application retrieves from somewhere and puts on a component (probably the video control) to tune into that service. The application is not supposed to be concerned with the details of the tune request, not even if it's analog or digital TV or whatever. The problem is that this "somewhere", the infamous "Guide Store", has not been implemented by Microsoft (yet?), that's why the entire idea breaks, and the application _does_ need to bother with the details of the tune request, and know which parameters to fill in there. So the "right" database solution, as intended by Microsoft, would be a "Guide Store", which stores tune request objects. However, I think that is up to Microsoft to implement, as I'm not sure it can be done without them (or can it?). That means whatever solution we come up with would be a "stopgap" solution until Microsoft get their act together and deliver fully functional components. My conclusion is that we can thus go for a "quick&dirty" solution :) Following that strategy, I implemented a channel scan in my app today. It takes a "locator" file as the input, a classic "INI" file of the format: ; Name=Frequency;Modulation;Symbolrate [Locators] SK 02=113000;3;6900000 SK 03=121000;3;6900000 ... It then generates a tune request given these parameters (these are the DVB-cable parameters, but others could be simply appended), tunes in to each frequency, tries to retrieve the services found from the TIF and generates an output INI file of the format: ; TSID=Frequency;Modulation;Symbolrate [Locators] 10001=113000;3;6900000 10002=121000;3;6900000 ... ; ONID:TSID:SID=NetworkName;ProviderName;Description [Services] 61441:10001:53204=MSG MediaServices GmbH;DigiKabel;TV Polonia 61441:10001:53205=MSG MediaServices GmbH;DigiKabel TR;Kanal D ... So this is my "Guide Store" database file format. I am still having some headaches with the TIF, though. For one, it always barfs on the same 6 services in the PREMIERE bouquet (GetServiceProperties returns 0x80040005), and then it apparently has a bug which causes it to get confused when the frequency is switched too often - GetServiceProperties will then return some bogus number, which does not seem to be a legitimate error code. I will try if maybe pausing or stopping the filter graph and then rerunning it makes the TIF feel more comfortable with the frequency switching... Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: John A. <Jo...@ad...> - 2003-02-17 09:42:39
|
> "When the method is successful, it returns S_OK." Hmmm, I suspect this is a documentation shortcut, I've seen some = DirectShow functions complete with special results and it is the sort of = thing that MS seem to change at will. I think both ways are fine in = this instance I was just pointing it out as all the vanilla COM = documentation says never to check just for S_OK. > That produced a new problem for me - now that I can switch services so > quickly, I really need to implement some service database to have some > services to switch between :-) Point taken :) I'm planning to have a first look at it today. I was having fun with = the stream buffer stuff over the weekend which in the end seems to work = pretty well as long as the source and sink are in seperate processes. = I'll post more on this once I've had a think about the design issues = this throws up for me. John =20 |
From: Robert S. <rob...@gm...> - 2003-02-17 02:12:06
|
From: "John Adcock" <Jo...@ad...> > > if (Result == S_OK) > Just a small point, COM return codes allow for success with > information so it is more correct to use > if(SUCCEEDED(Result)) > which allows those instead (FAILED() is also defined and > should be used when you want to spot failure codes) I am a bit cautious about these macros. SUCCEEDED returns TRUE for S_OK and S_FALSE, which is not always desirable. The documentation on all of the functions I used says: "When the method is successful, it returns S_OK." Thus I am checking for _exactly_ that result. A result of "S_FALSE" would be an error to me. > > With this workaround, it takes me about 1 second to switch > > from one station to another, as opposed to 10-15 seconds before. > Thanks for getting to the bottom of this! That produced a new problem for me - now that I can switch services so quickly, I really need to implement some service database to have some services to switch between :-) Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: John A. <Jo...@ad...> - 2003-02-16 20:10:29
|
> if (Result =3D=3D S_OK) Just a small point, COM return codes allow for success with information so it is more correct to use=20 if(SUCCEEDED(Result)) which allows those instead (FAILED() is also defined and should be used when you want to spot failure codes) > With this workaround, it takes me about 1 second to switch=20 > from one station to another, as opposed to 10-15 seconds before. Thanks for getting to the bottom of this! John |
From: Robert S. <rob...@gm...> - 2003-02-16 13:33:14
|
Hi, as Colin also experienced, there is a bug in the BDA TIF that makes service switching within the same multiplex take very long, because the BDA TIF completely reloads all tables. I traced the bug to the ITuneRequest::GetLocatorData() method, which should return S_FALSE if the locator data (=the multiplex) is unchanged. Unfortunately, it returns S_OK when there is _any_ frequency set in the TuneRequest's locator data. Thus, the workaround is to eliminate the frequency right after submitting the tune request: Result = Tuner->put_TuneRequest(DVBTuneRequest); if (Result == S_OK) { Result = DVBCLocator->put_CarrierFrequency(-1); if (Result == S_OK) { Result = DVBTuneRequest->put_Locator(DVBCLocator); } } Now you can quickly switch to another service by e.g.: DVBTuneRequest->put_SID(28114); Result = Tuner->put_TuneRequest(DVBTuneRequest); Note that you MUST NOT set the ONID or the TSID, or this will again trigger the TIF reload. With this workaround, it takes me about 1 second to switch from one station to another, as opposed to 10-15 seconds before. Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: John A. <Jo...@ad...> - 2003-02-15 13:30:55
|
> From: Robert Schlabbach [mailto:rob...@gm...]=20 > From: "John Adcock" <Jo...@ad...> > > I'm maybe keener to use the BDA terms instead so that ATSC=20 > users will=20 > > also be catered for but I agree my names were rubbish. >=20 > I'm not sure we will be able to cater ATSC users, it seems to=20 > be very different (and much less complex?). Just how widely=20 > available is ATSC anyway...? I think it's used for terrestrial broadcasting in major US cities so I'd guess a potential audience of about 200m. > > The channel number must be somewhere in the SI as there are=20 > channels=20 > > such as CH14 CH15 that will appear on a STB as channels 14=20 > & 15, these=20 > > channel numbers are also refered to by broadcasters so they must be=20 > > fixed in some way, my guess is in the BAT table. >=20 > I don't see anything like this in the BAT table, and I have=20 > to admit I wouldn't even know what term to look for=20 > ("channel" surely isn't it). Are you sure this is not just a=20 > feature of the application, that it recognizes these services=20 > by their name...? I'm not aware of DVB applications here in=20 > Germany that automatically put ARD on 1 and ZDF on 2... All the DVB STBs I've seen here (DVB-T and DVB-S) seem to know what "channel" to allocate a service to. I think the "channel" I'm expecting is a three digit number, this may be contructed in some way from the other details but I couldn't see any obvious way this would be done. John |
From: Robert S. <rob...@gm...> - 2003-02-15 12:03:52
|
From: "John Adcock" <Jo...@ad...> > I'm maybe keener to use the BDA terms instead so that ATSC users > will also be catered for but I agree my names were rubbish. I'm not sure we will be able to cater ATSC users, it seems to be very different (and much less complex?). Just how widely available is ATSC anyway...? > The channel number must be somewhere in the SI as there are channels > such as CH14 CH15 that will appear on a STB as channels 14 & 15, these > channel numbers are also refered to by broadcasters so they must be > fixed in some way, my guess is in the BAT table. I don't see anything like this in the BAT table, and I have to admit I wouldn't even know what term to look for ("channel" surely isn't it). Are you sure this is not just a feature of the application, that it recognizes these services by their name...? I'm not aware of DVB applications here in Germany that automatically put ARD on 1 and ZDF on 2... Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: John A. <Jo...@ad...> - 2003-02-15 11:44:10
|
-----Original Message----- From: John Adcock=20 Sent: 15 February 2003 09:38 To: 'Robert Schlabbach' Subject: RE: [Bdadev-discuss] Storing channels > From: Robert Schlabbach [mailto:rob...@gm...] > From: "John Adcock" <Jo...@ad...> > > The first problem I see is that of channel persistence, >=20 > I think to avoid confusion in the future, we should learn to > use DVB terms as early as possible. It is difficult to me as=20 > well, but what you mean is called a "service" in DVB terms.=20 > Note also that a "show" is called a "program" in DVB. This is=20 > not to be confused with the MPEG-2 meaning of "program",=20 > which is a service in DVB terms... I'm maybe keener to use the BDA terms instead so that ATSC users will also be catered for but I agree my names were rubbish. > > I see something like this (this is loose definition for the=20 > real thing=20 > > will obey what I think is normal c++ good practice). The only odd=20 > > thing is I think we need a way to allow up and down channel=20 > changing=20 > > as well as access via digit keys or an OSD, this what the channel=20 > > numbers are for. Is a default number available anywhere in the SI? >=20 > From my experience and the output I have seen from you, it=20 > seems the broadcasters already broadcast the service=20 > information in an ordered manner, i.e. ITV-1, ITV-2, etc in=20 > your case, so just using the order in which the services are=20 > enumerated as the default order seems like a good idea. The channel number must be somewhere in the SI as there are channels such as CH14 CH15 that will appear on a STB as channels 14 & 15, these channel numbers are also refered to by broadcasters so they must be fixed in some way, my guess is in the BAT table. John |
From: John A. <Jo...@ad...> - 2003-02-15 09:40:50
|
> Ah, probably an intended usage restriction due to licensing :( Bizarrely it worked within the video control in vb or html but not in c++, the audio side didn't work with the intervideo filters at all unless you specified an MPEG 1 stream so I'm glad to see the back of them. If you simple unregister them windvd will still run but they won't be used in automatic graph building. When you two move up to XP the Sonic decoders with DXVA hardware acceleration are very nice indeed picture wise and don't use up much CPU. John |
From: John A. <Jo...@ad...> - 2003-02-15 09:29:53
|
> I just noticed that when I click the "Reply" button on a=20 > bdadev e-mail, the response goes to the sender, not to the=20 > mailing list. Is this normal for sourceforge mailing list, or=20 > can this possibly be fixed so that the list e-mails have a=20 > proper reply-to line? That's changes now although sourceforge have had the habit in the past of losing this setting. I've also changed the reply-to on the cvs checking list to this list. John |
From: Robert S. <rob...@gm...> - 2003-02-14 03:56:21
|
From: "Colin D. Munro" <li...@mi...> > What I was hoping to do was to just program up the demultiplexer myself > with the required stream IDs, so that the audio/video began being fed > into the decoders almost immediately, then when the TIF finally got its > data, it would just set the decoders to the same IDs, and (hopefully) > no disruption to the output would occur (or if it did, it would just be > a slight glitch, not like waiting 30 seconds). I don't think that will work. The BDA TIF reprograms the demux no less than three times when it receives a tune request: 1. DVB fixed location PIDs only (0x0000, 0x0010-0x0014) 2. DVB fixed location PIDs + PMTs 3. DVB fixed location PIDs + PMTs + component PIDs You might use the ServiceChanged notification to reprogram the demux every time to "override" the changes the TIF has made, but this would be a nasty hack. > Yeah, while experimenting I began to get the impression the TIF could > do with some work to make it nicer to use, but you make use with what > you have, so I just got on with using it :) BTW, the TIF seems to be a cut-down (or should I say "crippled"?) version of some Intel piece of software. Windows XP even has its "Guide Store" component (PSISLOAD.DLL), which Microsoft first mentioned in the DirectX docs as a supplied component, then later changed it to a third party component. Also, the DLL help database on the Microsoft website lists a number of undocumented interfaces on the TIF (e.g. "EnumBouquets"). So it looks like Microsoft removed a lot of functions from the TIF, and is continuing to do so. I will ask them what this is all about and tell them that we need a *much* better piece of software than this... Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: Robert S. <rob...@gm...> - 2003-02-14 03:40:39
|
From: "Colin D. Munro" <li...@mi...> > Oddly, the InterVideo audio/video decoders don't seem to like being > loaded by anything except media players that use RenderFile(), the > TechnoTrend software and so on. If you try to load it programmatically > (like I initially did with my test application), it just ends the > process. Ah, probably an intended usage restriction due to licensing :( > I believe John had the same problem. What I did was to program > my test to allow you to select the decoders to use the first time > it's run, and picking the Cyberlink PowerDVD decoders works fine. You can do that with SimpleTV as well. Change line 883 in the sources: // use the first enumerated Video Decoder filter CopyMemory(&Application->VideoDecoderData, &Application->VideoDecoderList[0], sizeof(Application->VideoDecoderData)); change the "[0]" to "[1]" to have it use the second enumerated video decoder. Then you will have to delete the registry subkey: HKEY_CURRENT_USER\Software\Robert Schlabbach\SimpleTV Upon the next start, it should use the other video decoder. > > Could you try inserting all these filters in GRAPHEDIT, then > > inserting the DVB-T Network Provider, right-clicking its > > Antenna Out pin and selecting "Render"? Does this work? > > I tried this, it left the "BDA MPE Filter" and "BDA IP Sink" filters > unconnected, but connected everything else up the way it was meant to. Hmm, those should have been connected as well, but maybe it was the restricted video decoder that hindered the process...? Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: Robert S. <rob...@gm...> - 2003-02-14 03:28:37
|
From: "Colin D. Munro" <li...@mi...> > <application root key>/Multiplexes/<transport stream ID>/<network > provider id>/<service id> > Within the <transport stream ID> key is a value Frequency which > represents the frequency of that multiplex. Hmm, ONID:TSID:SID is the standard location information for DVB. I think the intended approach is to keep _two_ tables, one with ONID:TSID:SID and the related Service Information, and one with the TSID -> reception parameters (not only carrier frequency, but also DVB-T demodulator parameters) assignments. Microsoft actually does this quite nicely with the separate ILocator objects which hold the reception parameters. > I was also thinking of storing the audio/video(/etc.) IDs for quicker > switching here since just using the service ID means it takes up to > 30 seconds to change channel, since it's waiting for new program > information tables to get these for the demultiplexer. Ah, so am I not the only one suffering from this! It's silly, the TIF has already gathered all the information it needs, yet when all it would need to do is reprogram the demux to switch to another service on the same frequency, it resets and restarts gathering information. I will ask the Microsoft guys on Saturday why this is not working "right". How do you think you can implement the quicker switching? I don't think you can - as soon as you put a new tune request to the Network Provider, the BDA TIF will reset no matter what. I think what is really missing is some "backend storage" of the BDA TIF, however this does not seem to be possible. While you may be able to query the information the TIF gathered, I see no way to put it _back_ to the TIF. IMHO, Microsoft has to do a whole lot of work to the TIF to make this work satisfactorily. And if they don't do it, we may have to write a fully functional TIF replacement... Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: Robert S. <rob...@gm...> - 2003-02-14 03:28:31
|
From: "Colin D. Munro" <li...@mi...> > The log is attached below (although I've no idea if it worked right). It didn't :( More at the end of this e-mail. > The problem is basically that the NITs, which include the frequency of > each multiplex, are for another transmitter than the transmitter which > we can receive here. Great, this shows just how new this technology is to the broadcasters as well ;) FWIW, I have a channel on my cable in which the DVB SI information says it is on 386MHz when it is in fact on 402MHz. > The ITuneRequests returned by the TIF for services > include every channel on every multiplex, including the new frequency > to switch to (although you can't seem to query that, it only seems to > know them internally), You can, but there is one thing Microsoft did not mention properly: After you obtain an enumerated ITuneRequest from the TIF, it is lacking component and locator information. You must query and use the ITuneRequestInfo from the BDA TIF, which has methods to fill in the missing information. The "SimpleTV" application already does this. > It was very confusing when I first attempted to use these, I thought it > would be a simple matter of telling it which service I wanted to view, > but when I did so, my driver was told to go to these frequencies which > seemed to have no relation to the frequencies I needed. At first I > thought it was some sort of strange internal channel -> frequency map > the Network Provider might be using (hence my post to Usenet regarding > that) but I eventually made a note of all the frequencies it tried to > go to for each multiplex, then consulted a list of UK digital > terrestrial transmitters, and discovered they matched up with Black > Hill, another transmitter I believe is near here, but we can't get (due > to hills in the way). At least, that's what I'm sure is happening :) I would say we should not stick to the "bugs" our broadcasters are making, but rather design by the standards anyway. However, we will have to put in some kind of "override" capability to make the application ignore such erroneous information. > --------Output log-------- > Trying DVB-C... > Trying DVB-T... > Trying DVB-S... It should have stopped at DVB-T. Unfortunately, the graph building must have failed :( > Network Tuners - 2 filters found: > Nova-T BDA driver > Sample BDA Tuner Filter I suppose this matches the contents of the "BDA Source Filters" group you see in GraphEdit? Anyway, it looks good. > Video Decoders - 3 filters found: > InterVideo Video Decoder This should work as well. > Audio Decoders - 2 filters found: > CyberLink Audio Decoder Hmm, maybe this is the problem? > Multi Protocol Encapsulators - 1 filters found: > BDA MPE Filter > > IP Sinks - 1 filters found: > BDA IP Sink These are ok. Could you try inserting all these filters in GRAPHEDIT, then inserting the DVB-T Network Provider, right-clicking its Antenna Out pin and selecting "Render"? Does this work? If not, what changes make it work? Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: Robert S. <rob...@gm...> - 2003-02-14 03:26:12
|
From: "John Adcock" <Jo...@ad...> > The first problem I see is that of channel persistence, I think to avoid confusion in the future, we should learn to use DVB terms as early as possible. It is difficult to me as well, but what you mean is called a "service" in DVB terms. Note also that a "show" is called a "program" in DVB. This is not to be confused with the MPEG-2 meaning of "program", which is a service in DVB terms... My suggestion would be to make the internal structures as "DVB" as possible, so we do not create structures that will not work for future enhancements. The DVB way of addressing a service is ONID:TSID:SID. Maybe we should keep three separate tables internally: 1. ONID:TSID:SID and the corresponding information received (service name, service description, components, PIDs) 2. TSID -> reception parameters (locator) assignments 3. User defined "station memory" number -> ONID:TSID:SID The first two would be updated automagically during reception (where we may need an option to suppress updates to table 2 due to the problems Colin outlined). > I see something like this (this is loose definition for the real thing > will obey what I think is normal c++ good practice). The only odd thing > is I think we need a way to allow up and down channel changing as well > as access via digit keys or an OSD, this what the channel numbers are > for. Is a default number available anywhere in the SI? From my experience and the output I have seen from you, it seems the broadcasters already broadcast the service information in an ordered manner, i.e. ITV-1, ITV-2, etc in your case, so just using the order in which the services are enumerated as the default order seems like a good idea. > class CChannel > { > ITuneRequest* GetTuneRequest() > BOOL IsActiveForPrevNext > } Aside from the name of this class (maybe "CServiceMemory"?), I would consider a "two stage" approach to get an ITuneRequest object. The first step is to get a ONID:TSID:SID "URL" for a user-defined "station memory" number, the second to get an ITuneRequest for this "URL". The latter will be needed when selecting shows out of the EPG. The ONID:TSID:SID<->user-defined number retrieval should be available in both directions, and an error should be returned if there is no corresponding entry. As to the GetNext/GetPrevious, do we really need this? I think a simple array with the user number as the index and the ONID:TSID:SID URLs as the contents would suffice. That would also simplify detecting erroneous double assignments. Only a method to query the highest used index would be needed then. If the application then gets a "+/-" request, it could increase/decrease the user number, wrap around if it gets below 0 or above the highest used index, and repeat that until it gets a valid ONID:TSID:SID URL for a number (endless loops should be detected;). Then, of course, we would need a method to enumerate the available ONID:TSID:SID URLs in the database. How about using a standard COM enumerator object for this? Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
From: Robert S. <rob...@gm...> - 2003-02-14 03:23:41
|
Hi, I just noticed that when I click the "Reply" button on a bdadev e-mail, the response goes to the sender, not to the mailing list. Is this normal for sourceforge mailing list, or can this possibly be fixed so that the list e-mails have a proper reply-to line? I will resend my previous responses, which only went to you guys individually, to the list once more. P.S.: Colin, could you increase your line lengths in OE to 75 characters? The quoted text wraps way too much with your current line length... Best Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |