MDAPI: Pros and Cons (1 Viewer)

[NLS]

I (almost) agree.

My TV should just be a full screen TV and whoever wants something different (like teletext or programming) should just do it through the context menu. Like a real TV.

 

[ditronics]

I´m not a programer, but I think will be easier to work with programs like progdvb serving ts or mpa streams and try to conect MP to them as client. I work with progdvb(server) to progdvb(client) and it runs fine even usng multiple DVB cards.


Regards

 

[Agarwal]

^I guess it could work, but then again it's not necesseraly less work, since the built-in "flow" of the TV video would have be to be modified in order to display TV from the network. You would also be bound to a single model of client/server. You will also lose some speed while changing channels, which is not the best for heavy channel surfers.

But yeah... it *could* work I won't be the one implementing that, however. If someone tries it, I suggest trying to work with the AltDvb Remote Server; it's a completely standalone and small software, and you would implement a true DVB MP "device driver" to make it work. MP would think it's working with a local card. I think the implementation details of AltDvb is not open, though.

 

[ditronics]

Yeap

Well I think Progdvb will be better cause it supports BDA drivers. Well zapping is a little slow when streams mpg. I am streaming using 5 cards (3 for dvb-t and 2 for dvb-s) a transponder each streaming about 20 channels (12 dvb-t and 4 dvb-s), my favorites of course, and it works really nice . Obviously it is very recommendable to have a giblan in order to give enouth band width.

 

[draktheas]

Ok, I suggest a separate thread be started if we want to discuss the possibility of taking a network streamed source and making a generic Directshow source filter for it. This is getting the thread completely off topic.

As for work on the MDAPI plugin support for MP. I personally am not for using closed source for this. The reason to me is obvious, the whole MP project is open source and any wrapper that allows use of MDAPI plugins should be as well. I don't want code that no-one can support if Agarwal disappears. No offense Arg. Obviously, I have very strong feelings about this. I also believe that any MDAPI plugin wrapper for MP would be specifically coded for MP, as it is an adapter from MP to MDAPI. It doesn't make sense to me that this could be used in other applications. Unless what you have coded is just an MDAPI plugin that you have adapted to MP.

In my opinion the proper flow for MDAPI support should be:
MP->MP To MDAPI Adapter->MDAPI Plugin
not
MP->Hacked MDAPI Plugin

Drak

 

[ASiDiE]

I don't know if this would be of any help. But a guy over in the sagetv forums has created a plugin that links up with My theatre. The source code and information is posted HERE.

 

[Agarwal]

draktheas: by nature, DirectShow filters doesn't (and should'nt) be aware in what actual application they are running. This is the whole point of DirectShow filters. Understand that I did not make MP plugins, I made generic DirectShow filters that allows to apply MDAPI filters to the stream passing through it. The filters, by themselves, do nothing. The plugins do the actual work, just as in MyTheatre of ProgDVB.

MP needs ~20 lines of code in order to support the filters, that is, the actual code to add the filters to the graph (there's 2), and the code to notify the filters of channel change (which could probably be handlded automatically by talking directly to the DVB filters, but I haven't researched that yet). That's it.

You do NOT want to handle the actual decoding inside MP; you need all the speed you can get, and C# won't give you that. MP Administrators won't allow to have the actual descrambling done by MP anyway, but they should (as I already discussed with them) be willing to support generic DirectShow filters that does.

ASiDiE: MyTheatre sucks so much, I don't even want to start talking about it It is not anywhere near suitable for use in an HTPC.

 

[ditronics]

Agree about mytheatre.

Yeah agree to open a separate thread.

Regards

 

[draktheas]

Agarwal, I was not implying that we should do any decoding or plugin directly in MP and thus C#. I understand very well the performance implications. And I was not implying that we should write the MDAPI plugin wrapper for MP in C# either. There are ways to make generic MDAPI plugin support possible without using C# but still hooking into MP directly. One way is the way you have done it. Make a directshow filter that generically supports all MDAPI plugins. And if that is how you have implemented it then kudos to you.

I still, however, stand by my original statement that I am not for making it closed source. Again the main reason for that is because if it is closed source and you are the only one that is able to build it or fix bugs then everyone that uses MP is dependant solely on you. This is not a stab at you personally. It just defeats the purpose of having an opensource project when there are certain features that are only supported if the author of a closed source project releases updates and fixes bugs. I am not trying to get you to disclose your source. If you feel you have a viable reason for keeping it closed source, then that is your choice. I am, however, recommending that someone else (whether it's me or not) create and release MDAPI support that is open source so that MP and all of it's features can remain open source and maintainable by the MP devs.

Drak

 

[Agarwal]

I kinda agree with you. But the fact is that I did *not* initially write the filters to use them in MP. It just happens that MP uses DirectShow, and as such it can use the said filters. The filters are/will be used in other (publicly or commercially available) projects of mine, which is why I can't open source them. Yet.