[PATCH] Improvements for analog cards

[SciDoctor]

That is an excellent idea.

Trial and error the first time a card is detected and then strore the correct pins in DB for future reference.

[tourettes]

Originally Posted by SciDoctor

That is an excellent idea.

Trial and error the first time a card is detected and then strore the correct pins in DB for future reference.

Maybe that "trial and error" should be done only in the configure part?

[SciDoctor]

Having just rolled back my tuner drivers to CATS 6.2 which are NSP software only drivers (ie no posibility of a confusion of hardware mpeg) there is a fundimental flaw in the auto graph build of the TVSEREVR whcih probably affects quite a few software cards.

The problem is there may be two or more filters that essentialy do one job and may share jobs between audio and video ;the TVSERVER is only finding the first and ignoring the second before it moves on.

With the ATI cards I have tested the x-bar has two filters (ATI TV audio crosbar and ATI rage theatre video cross bar ) before the capture filter.

The tv audio crossbar handles audio and video, the TV server can't cope with this

When the TVserver tries a filter and fails it doesn't seem to try another filter but closes the graph build .

2008-01-02 20:04:08.750000 [8]: analog: Tune:tv: Freq:0 Channel:128 Country:United Kingdom Tuner:Antenna Video:Tuner
2008-01-02 20:04:08.750000 [8]: analog: build graph
2008-01-02 20:04:08.750000 [8]: analog: AddTvTunerFilter ATI TV Tuner
2008-01-02 20:04:08.875000 [8]: analog: AddCrossBarFilter
2008-01-02 20:04:08.875000 [8]: analog: AddCrossBarFilter try:ATI TV Audio Crossbar 0
2008-01-02 20:04:08.875000 [8]: analog: FindCrossBarPin type:Video_Tuner direction:Input
2008-01-02 20:04:08.890625 [8]: analog: FindCrossBarPin inputs:5 outputs:4
2008-01-02 20:04:08.890625 [8]: analog: pin 0 type:Video_Composite
2008-01-02 20:04:08.890625 [8]: analog: pin 1 type:Video_SVideo
2008-01-02 20:04:08.890625 [8]: analog: pin 2 type:Video_Tuner
2008-01-02 20:04:08.890625 [8]: analog: FindCrossBarPin found pin at index:2
2008-01-02 20:04:08.890625 [8]: analog: ConnectFilter()
2008-01-02 20:04:08.890625 [8]: analog: PinDest:name:2: Video Tuner In [6/1] Direction:Input Connected:False
2008-01-02 20:04:08.890625 [8]: analog: pinSource 0:name:Analog Video [5/1] Direction:Output Connected:False
2008-01-02 20:04:08.890625 [8]: analog: pins connected
2008-01-02 20:04:08.890625 [8]: analog: AddCrossBarFilter succeeded
2008-01-02 20:04:08.890625 [8]: analog: AddTvAudioFilter
2008-01-02 20:04:08.890625 [8]: analog: FindCrossBarPin type:Audio_Tuner direction:Input
2008-01-02 20:04:08.906250 [8]: analog: FindCrossBarPin inputs:5 outputs:4
2008-01-02 20:04:08.906250 [8]: analog: pin 0 type:Video_Composite
2008-01-02 20:04:08.906250 [8]: analog: pin 1 type:Video_SVideo
2008-01-02 20:04:08.906250 [8]: analog: pin 2 type:Video_Tuner
2008-01-02 20:04:08.906250 [8]: analog: pin 3 type:Audio_Line
2008-01-02 20:04:08.906250 [8]: analog: pin 4 type:Audio_Tuner
2008-01-02 20:04:08.906250 [8]: analog: FindCrossBarPin found pin at index:4
2008-01-02 20:04:08.906250 [8]: analog: AddTvAudioFilter try:ATI TV Audio 0
2008-01-02 20:04:08.921875 [8]: analog: ConnectFilter()
2008-01-02 20:04:08.921875 [8]: analog: PinDest:name:TVAudio In [5/1] Direction:Input Connected:False
2008-01-02 20:04:08.921875 [8]: analog: pinSource 0:name:Analog Video [6/1] Direction:Output Connected:True
2008-01-02 20:04:08.921875 [8]: analog: skipping pin
2008-01-02 20:04:08.921875 [8]: analog: pinSource 1:name:Analog Audio [6/1] Direction:Output Connected:False
2008-01-02 20:04:08.921875 [8]: analog: pins connected
2008-01-02 20:04:08.921875 [8]: analog: AddTvAudioFilter succeeded:ATI TV Audio
2008-01-02 20:04:08.921875 [8]: analog: AddTvCaptureFilter
2008-01-02 20:04:08.937500 [8]: analog: AddTvCaptureFilter try:ATI Rage Theater Video Capture 0
2008-01-02 20:04:08.953125 [8]: analog: AddTvCaptureFilter failed to connect to crossbar
2008-01-02 20:04:08.968750 [8]: analogispose()

[BKCH]

Hi Misterd,

Sounds like a great patch!!!

I wanted to ask three questions:

1. If I have an Hauppauge card (PVR-250MCE) - which is a H/W encoding card - would you expect any benefit??
2. Do you plan to roll this patch into the SVNs?
3. I'd like to test the patch but I'm not sure how to roll back - can you provide any information about how to delete the new table "SoftwareEncoder" in the db?? (I use Microsoft SQL). (sorry for the Noob question!!)

[misterd]

Originally Posted by diehard2

Hi misterd, looks like you've done quite a bit of work. I can shed a bit of light on why it is so slow to build the analog graph sometimes. The problem is with pin connections. It takes forever when a pin connection is rejected (you can see this in graphedit) and is the reason for my special hack with the hauppauge cards. An ideal fix (which I've been too busy to implement) would be to create the graph using the current methods and

1. iterate through the graph and get each filter's CLSID, the order of the filter in the graph, and the pin connections (by name)
2. Store this information in the database (or an xml file)
3. When the tv server is run again, if the card is in the system and nothing has changed, it will check the database, add all of the filters by CLSID, and connect each pin on the correct filter by pin name. This will make the appropriate connections directly instead of using trial and error.

This would be extremely fast.

Graph building takes here ~1 second. For me this is fast enough, but for sure there are improvements and your idea is really good. My problem is that you need a fallback system when something has changed and than update the db etc.
During my tests I found out that it only takes very long to connect pins, if you try to connect to a pin that is already connected to a different pin. Therefor my modifications just checks at first, if the pin is already connected.

Originally Posted by SciDoctor

Having just rolled back my tuner drivers to CATS 6.2 which are NSP software only drivers (ie no posibility of a confusion of hardware mpeg) there is a fundimental flaw in the auto graph build of the TVSEREVR whcih probably affects quite a few software cards.

The problem is there may be two or more filters that essentialy do one job and may share jobs between audio and video ;the TVSERVER is only finding the first and ignoring the second before it moves on.

With the ATI cards I have tested the x-bar has two filters (ATI TV audio crosbar and ATI rage theatre video cross bar ) before the capture filter.

The tv audio crossbar handles audio and video, the TV server can't cope with this

When the TVserver tries a filter and fails it doesn't seem to try another filter but closes the graph build .

The TvServer tries different filters, but only while it tries to add a specific one. There is no retry if there an error occurs somewhere later in the graph building process.
Perhaps I will think about how such a problem could be solved at weekend.

MisterD

Originally Posted by BKCH

1. If I have an Hauppauge card (PVR-250MCE) - which is a H/W encoding card - would you expect any benefit??
2. Do you plan to roll this patch into the SVNs?
3. I'd like to test the patch but I'm not sure how to roll back - can you provide any information about how to delete the new table "SoftwareEncoder" in the db?? (I use Microsoft SQL). (sorry for the Noob question!!)

1. Perhaps the channel switching is also improved here, but I'm not quite sure.
2. Since I'm not a developer of MP, I can't commit the patch into SVN.
3. You have to connect to the db server with the SQL Server Management Studio. Than select the Database "TvLibrary" and delete there the table by right-clicking on the table and selecting "Delete".
But I highly suggest only to try the patch, if you know what you are doing. The reason is quite simple. If the patch will be included sometime in SVN and you haven't deleted the table properly, you'll get an error when you update to this version. Perhaps I will post some delete scripts at weekend when I find some time.

MisterD

[diehard2]

Graph building takes here ~1 second. For me this is fast enough, but for sure there are improvements and your idea is really good. My problem is that you need a fallback system when something has changed and than update the db etc.
During my tests I found out that it only takes very long to connect pins, if you try to connect to a pin that is already connected to a different pin. Therefor my modifications just checks at first, if the pin is already connected.

This is driver specific. My hauppauge card still takes a long time to connect even for unconnected pins, and it is in the graph building section. I would suggest that in the graph building section from the database, you will add filters by CLSID from the database. If a filter cannot be added, rebuild using the trial and error method, save to the new configuration to the database. If all filters are added successfully, start to connect all pin connections in the database. If a pin connection fails, rebuild based on trial and error. Just a suggestion if you have time and you are interested.

BTW, if you get heavy into the directshow stuff, you might find the hresult class useful. It uses PInvoke to get directx error messages. I don't know if the dll source is in the tree, but you can PM me if you would like access to that. There is a function in there that translates hresults into helpful human readable messages.

[misterd]

Originally Posted by diehard2

I would suggest that in the graph building section from the database, you will add filters by CLSID from the database. If a filter cannot be added, rebuild using the trial and error method, save to the new configuration to the database. If all filters are added successfully, start to connect all pin connections in the database. If a pin connection fails, rebuild based on trial and error. Just a suggestion if you have time and you are interested.

Interest for sure, but I will promise that you won't be able recognize the old code anymore. The reason is that I find the two classes almost readable and would split-up theme in several more or something else.
But the main problem is the time, because my life has changed with the beginning of the new year. Another problem is that I actually wanted to finish my teletext module. Time will tell

MisterD

[cracksloth]

what would be truly nice is the ability to import a saved graphedit GRF file to allow mediaportal to properly recognize an "odd" card and then have mediaportal remember this configuration for the future. for whatever reason i have a relatively common but old s/w card (wintv radio) and it's completely confounded me in media portal, but i can get it to render in graphedit. any possibility of such an import function?

[misterd]

First of all there must be a documentation of the file format and it must be allowed to use it in an other software.
If this is true, than it would be possible to something like this.
But IMHO I don't think that such a feature will be implemented in the (near) future. I think that a feature where the user can modify the automatically identified components is more realistic. But before we could think about something like this, we should implemented the suggested way of diehard2 first.

MisterD

[misterd]

I Just updated the files in the first post for Revision 16907. There are no changes in the code, because I got almost no feedback, if it's working or not. It's just a recompile for this new version, including all changes of the team.

Your feedback is really appreciated, especially when it's working for you. This makes the decision team more easier to include this patch into SVN.

I didn't create a remove script for the database, because I'm thinking about a patch installer or something like this, which also can remove the patch. Unfortunately this will take some time, before I can provide something like this.

I'm currently thinking about the whole graph building in TvServer for analog cards. This is why I didn't implemented a retry function in the graph building process. There are so many cases and scenarios that have to be included to get a simple and easy to use system for the end-user. On the other hand I think that the TvServer needs a little bit more flexibility (encoders, multiplexers) in that case too, so the user can tweak the graph to get his card working. I think editing DB or using GraphEdit isn't the right way for the normal end-user. I hope that when I have finished brainstorming I have solution that fits for more cards than now and has an improved graph building speed by using the DB.
I'm also wondering why the TvServer tries to get a video and audio multiplexed stream and than demultiplexes it, before it get multiplexed again and connects to MPFileWriter. I'm just asking myself, for which reason this demultiplexing step is needed. I see in the code that in some cases it is useful for differing between tv and radio, but in many cases this goal could be achieved in a better way.
Any help is very welcome, especially testers are needed, when I have finished the new version But I would like to see this patch included in SVN before the new version is ready, because my work will be based on it.

MisterD