TV Server (2 Viewers)

A

Anonymous

Guest
Meat_PoPsiclez said:
Why compete?

In fact, why build MP at all given we have MCE? :)

To answer your question, I don't think we have much choice.

I'm guessing that due to the common interface, Media Center Extenders have stuff that is very specific to MCE while still using uPnP as the protocol. Some things would be easy to translate, other might not and "break" the interface (for example using the TV Guide on an extender would be very difficult to sync with MP). Also I'm fairly sure MS wouldn't be too happy about someone reverse engineering them (if only by reading the XML) to connect them to a competing product. In any event, I wouldn't know cause you can't get Extenders where I am :(

But the idea is to make MP operate something like a Media Center Extender - run it and you can access anything from any other instance of MP on the network. I'm actually looking at uPnP for the protocol as all the dedicated music boxes (not just media center extenders) seem to be using it. If that means an extender can connect to it, then cool. I'll check out the Intel site - thanks.
 
A

Anonymous

Guest
benji said:
Also I'm fairly sure MS wouldn't be too happy about someone reverse engineering them (if only by reading the XML) to connect them to a competing product.

But it's not reverse engineering, upnp is a free and open specification. The only functionality that media extenders offer on top of the upnp spec is the ability to play and manage protected content. I don't think anybody here really cares about that, at least not for the forseeable future.

I'm not saying we should try to make it completely compatible with windows media extenders, but if an open and widely accepted specification exists, why try and make something that circumvents it?
 

samuel337

Portal Pro
August 25, 2004
772
0
Melbourne, Australia
I'm not sure if you guys have seen the Intel Remote IO demo or not, but would that be a better solution rather than the mediarenderer/mediaserver solution?

The difference between the two is that Remote IO is simply where the server loads an instance of an application and sends it over to the Remote IO client. All keystrokes and mouse movements on the client are sent back to the server which updates the display and sends it back to the client. In other words, its like using Terminal Services.

mediarenderer/mediaserver on the other hand, involves installing an application on the client which communicates with the server using various calls.

I'm not sure about either solution though - I just thought about the two after viewing the intel demo videos - see the remoteIO one with this link: http://mfile.akamai.com/2478/asf/ihc.download.akamai.com/2478/upnp/remote_io_upnp.asx

BTW, just thinking aloud, either of these solutions would require changes to MediaPortal, especially with the mediarenderer/mediaserver solution because a server and client version would be required. If the client version wasn't supported by frodo, every time a version changes, you would need to add the upnp code back in and change other bits then recompile it for the client.

Of course, all these problems are solved if MP was split into a backend/frontend system... In that case, you could have the backend running on the server, and the client on the other computers - if you wanted to use the server as a client as well, you would just run it on that as well, like MythTV.

Am I completely off track? What does everyone else think?

Sam
 
A

Anonymous

Guest
Meat_PoPsiclez said:
But it's not reverse engineering, upnp is a free and open specification. The only functionality that media extenders offer on top of the upnp spec is the ability to play and manage protected content. I don't think anybody here really cares about that, at least not for the forseeable future.

If thats the case, then we are really talking about the same thing. If I was to implement UPnP, then nothing specific needs to be done for Extenders.

I can't buy an Extender (I would love to check them out), but what codecs do those boxes have? Isn't the video converted to that crappy MS DRM format on the MCE box before being streamed to the extender? Also, how is the interface implemented, like for the TV Guide?
 

samuel337

Portal Pro
August 25, 2004
772
0
Melbourne, Australia
I have some answers to the questions I asked in my previous post and benji's post:

I'm basing my answers on this article (its a review of the linksys MCX) http://blog.tmcnet.com/blog/tom-keating/voip/voip-blog/linksys-media-center-extender-mcx-review.asp

It seems that MCE2005 uses the remoteIO method to communicate with the extender:
So what is going over the network? Essentially it's a remote desktop connection that's sending out a DirectX application along with the streaming raw video feed that is transported alongside the RDP connection. The higher the video quality, the more bandwidth it consumes. I had no problems with my 802.11g network, but you may get better performance and less interference using an 802.11a wireless network.

The answers to benji's codec question is:
The MCX unit actually decodes video locally, and as such is limited to the formats that it recognizes. MPEG-1, MPEG-2, and WMV video are supported. However, don't plan on watching your Divx or Xvid video files on the MCX unless you transcode the file first to the aforementioned file formats.

Also, it is interesting to note that the screen transitions do not work on the MCX boxes.

So for those who want to know how MCX works, check out the link to the video I posted earlier.

Sam
 
A

Anonymous

Guest
Raw video at d1 resolutions is 237Mbit/s (assuming 24bit 30fps) so that's definitely not the case. If it does do any decoding on the pc, it probably transcodes to mpeg2 then sends it to the extender. A high bitrate low complexity (encoder wise) stream is easy to create with relatively low cpu usage.

I'm still not convinced that's the case though, I assumed that the extenders actually decoded on the settop box, that explains why the very small limits in format compatability. If that is the case, at the very least streaming your mpeg2 tv captures / streams would work like a charm. Also, the fact that Microsoft froze the wmv9 and wma9 specs just before announcing the extenders supports this theory (also in time for the announced consideration of the formats for hd dvd)

But I digress, compatability with the extenders would be great, but not the ultimate goal here.
 
A

Anonymous

Guest
Good news, I have been working on this and have done some proof of concept code and currently have live tv from mediaportal multicasting MPEG2 to video lan clients around my network:

This is just to let you know it's in progress and is on it's way.

Current Issues:
1. Cards with non native MPEG2 output require an MPEG2 Multiplexer (not bundled with directshow, I am currently using MoonLight MultiplIX. However will need to look at rolling our own... ouch..)
2. Will not pass any routers/gateways that do not support multicasting
3. Requires additional functionality in mediaportal to support "virtual tv cards"
4. Seeing some regular stutter in video lan client (might because of multiplexer above, need to obtain a hardware card to test)
5. Requires modification and support for each supported tv card.

Now I am afraid you may not get it for christmas but rest assured it is in development.
 

Inker

Retired Team Member
  • Premium Supporter
  • December 6, 2004
    2,055
    318
    very sweet..........maybe this could be for the new year? ;-)

    Hehe, anyways, take your time, I'm sure it'll be great (I'll be glad to test any betas/alphas you might have out there).

    Thnx alot for doing this!
     

    Mars Warrior

    Portal Pro
    August 26, 2004
    158
    2
    Airy Crater, Mars
    Home Country
    OB2 said:
    3. Requires additional functionality in mediaportal to support "virtual tv cards"

    5. Requires modification and support for each supported tv card.
    Great OB2. Let me know the details about required modifications, as I have rewritten parts of the capture & graph classes to be able to support any mpeg2 card and will continue rewriting these to support radio also.

    It would be nice to at least make sure that modifications for virtual cards and required modifications for each supported tv card will work with the newly designed tv & radio classes & capture card definitions!!!
     

    Users who are viewing this thread

    Top Bottom