 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Server Forum / Windows Media Server / March 2004Receving udp on loopback interface
Hi all, How can I configure Media Player 9 to receive a multicast udp stream on the loopback interface? I currently have a system in which Media Player reads an nsc file to receive a multicast stream on a given address, and this works fine. However, I need to adapt this so that, whilst the server is multicasting the stream, the Media Player listens on the loopback interface (I have another application that receives the multicast stream and outputs it locally). An obvious solution is to attempt to modify the nsc file so that it instructs Media Player to listen on 127.0.0.1. However, when creating the nsc file, Media Server helpfully checks that the address you specify is a multicast address, and as the nsc file is encrypted, modifying the address is not that easy. Any suggestions? Thanks, Phil. If I understand your use correctly... If your application is taking the multicast stream, doing something to it, and then resending it again why not listen directly to the resent stream using a 'normal' stream URL? (mms://localhost:output_port_of_your_app/streamname) Once your app gets down with it, it isn't multicast stream anymore. T. > Hi all, > [quoted text clipped - 7 lines] > > Phil.  SignatureTim Carter / StreamingMeeMee Frontier Digital PH: 508.982.4800 AIM: streamingmeemee MSN: streamingmeemee@hotmail.com Microsoft Digital Media MVP 2002-2004 Tim Thanks for your response. My original post wasn't too clear but, yes, my application is processing the multicast stream and resending as a local unicast In your example, how will Media Player know how to decode the stream? In the usual unicast configuration, the Media Player connects to the Server to get the bit rate, codec etc in order to be able to understand the stream. As multicast is connectionless, the Media Player reads an nsc file to obtain this information. My requirement is that the Media Player reads and understands a unicast stream, but does not connect to the Server to get the information to understand the stream. In other words, there is no concept of a publishing point or stream name or whatever, as the client knows nothing about where the stream has come from. Yet it still needs to get the bit rate, stream format, codec.... Is there any other way of getting this information, other than from an nsc file? Is it possible to write my own nsc file so that instead of reading from a multicast address, I read the unicast stream Thanks Phil ----- Tim 'StreamingMeeMee' Carter [MVP/Digita wrote: ---- If I understand your use correctly.. If your application is taking the multicast stream, doing something to it, and then resending it again why not listen directly to the resent stream using a 'normal' stream URL? (mms://localhost:output_port_of_your_app/streamname) Once your app gets down with it, it isn't multicast stream anymore T Phil Wood wrote > Hi all >> How can I configure Media Player 9 to receive a multicast udp stream on the loopback interface? I currently have a system in which Media Player reads an nsc file to receive a multicast stream on a given address, and this works fine. However, I need to adapt this so that, whilst the server is multicasting the stream, the Media Player listens on the loopback interface (I have another application that receives the multicast stream and outputs it locally) >> An obvious solution is to attempt to modify the nsc file so that it instructs Media Player to listen on 127.0.0.1. However, when creating the nsc file, Media Server helpfully checks that the address you specify is a multicast address, and as the nsc file is encrypted, modifying the address is not that easy >> Any suggestions >> Thanks >> Phil -- Tim Carter / StreamingMeeMe Frontier Digita PH: 508.982.480 AIM: streamingmeemee MSN: streamingmeemee@hotmail.co Microsoft Digital Media MVP 2002-200 Assuming that the viewer will always be running on the 'local' machine; why do you need to bother with re-creating a stream? Seems like you could use a series of directshow filters to grab the multicast stream, do whatever you need to do and then display it. By using DirectShow filters you skip the second trip to the network layer entirely. T. > Tim, > [quoted text clipped - 3 lines] > > Phil. SignatureTim Carter / StreamingMeeMee Frontier Digital PH: 508.982.4800 AIM: streamingmeemee MSN: streamingmeemee@hotmail.com Microsoft Digital Media MVP 2002-2004 Hi Tim Yes, the viewer is on the local machine. I must admit I don't know much about Direct Show. However, the processing that I am performing on the incoming data stream is at the IP level rather than on the content of the stream, so perhaps DirectShow is not suitable. Nonetheless, I'll have a look at this. In the meantime, are you saying that I can use DirectShow to receive my original multicast stream, do some kind of processing, and pass it on to play directly in Windows Media Player? Or can I use Direct Show to receive my already processed stream and pass it onto Media Player? Or do I have to build my own media player using DirectShow This whole problem has arisen because I have a demo system in which an incoming multicast stream is processed in some way then unicast locally, where it is received by the open source VideoLAN client. Because VideoLAN uses SAP to announce the stream, there is no need for any nsc-like file; all I have to do is tell VideoLAN to listen on a given port, and it can receive the processed stream. Simple as that. However, I'm keen to try and get a higher profile media client, such as Windows Media, working in the system - only, it's proving a bit more difficult than I thought Thanks for your advice Phil ----- Tim Carter [MVP/Digital Media] wrote: ---- Assuming that the viewer will always be running on the 'local' machine; why do you need to bother with re-creating a stream? Seems like you could use a series of directshow filters to grab the multicast stream, do whatever you need to do and then display it. By using DirectShow filters you skip the second trip to the network layer entirely T Phil Wood wrote > Tim >> My requirement is that the Media Player reads and understands a unicast stream, but does not connect to the Server to get the information to understand the stream. In other words, there is no concept of a publishing point or stream name or whatever, as the client knows nothing about where the stream has come from. Yet it still needs to get the bit rate, stream format, codec.... Is there any other way of getting this information, other than from an nsc file? Is it possible to write my own nsc file so that instead of reading from a multicast address, I read the unicast stream >> Thanks >> Phil -- Tim Carter / StreamingMeeMe Frontier Digita PH: 508.982.480 AIM: streamingmeemee MSN: streamingmeemee@hotmail.co Microsoft Digital Media MVP 2002-200 I have to admit that I'm at the fringes of my knowledge set when it comes to direct show filters and the media player. Normally, the player handles the setup of the filters based on the codecs, delivery method and display parameters. I wonder if it might be possible to use the WMS to 'fake it'. If you configured a WMS unicast pub point to use your local data source over HTTP as if it were a remote encoder or remote publishing point... You could then have your players connect to a standard WMS unicast publishing point. Hmm... T. > This whole problem has arisen because I have a demo system in which an incoming multicast stream is processed in some way then unicast locally, where it is received by the open source VideoLAN client. Because VideoLAN uses SAP to announce the stream, there is no need for any nsc-like file; all I have to do is tell VideoLAN to listen on a given port, and it can receive the processed stream. Simple as that. However, I'm keen to try and get a higher profile media client, such as Windows Media, working in the system - only, it's proving a bit more difficult than I thought. SignatureTim Carter / StreamingMeeMee Frontier Digital PH: 508.982.4800 AIM: streamingmeemee MSN: streamingmeemee@hotmail.com Microsoft Digital Media MVP 2002-2004 hang on - I think the solution to my problem might be that I don't need to do anything at all. It occurs to me that the multicast address given to the player is only used by the player in sending an igmp join on that multicast address. As long as the Media Player is listening on the correct port (the port that I am sending the unicast stream to) it might not matter what address is in the nsc file I'll let you know if this works.. ----- Tim Carter [MVP/Digital Media] wrote: ---- I have to admit that I'm at the fringes of my knowledge set when it comes to direct show filters and the media player. Normally, the player handles the setup of the filters based on the codecs, delivery method and display parameters I wonder if it might be possible to use the WMS to 'fake it'. If you configured a WMS unicast pub point to use your local data source over HTTP as if it were a remote encoder or remote publishing point... You could then have your players connect to a standard WMS unicast publishing point Hmm.. T Phil Wood wrote > This whole problem has arisen because I have a demo system in which an incoming multicast stream is processed in some way then unicast locally, where it is received by the open source VideoLAN client. Because VideoLAN uses SAP to announce the stream, there is no need for any nsc-like file; all I have to do is tell VideoLAN to listen on a given port, and it can receive the processed stream. Simple as that. However, I'm keen to try and get a higher profile media client, such as Windows Media, working in the system - only, it's proving a bit more difficult than I thought -- Tim Carter / StreamingMeeMe Frontier Digita PH: 508.982.480 AIM: streamingmeemee MSN: streamingmeemee@hotmail.co Microsoft Digital Media MVP 2002-200 And? Caffeine deprived minds want to know! ;-) T. > hang on - I think the solution to my problem might be that I don't need to do anything at all. It occurs to me that the multicast address given to the player is only used by the player in sending an igmp join on that multicast address. As long as the Media Player is listening on the correct port (the port that I am sending the unicast stream to) it might not matter what address is in the nsc file. > > I'll let you know if this works... SignatureTim Carter / StreamingMeeMee Frontier Digital PH: 508.982.4800 AIM: streamingmeemee MSN: streamingmeemee@hotmail.com Microsoft Digital Media MVP 2002-2004 Tim Sorry for the delay, I had some big problems with packet fragmentation that I had to sort out. But, I'm delighted to say that all is now working. The multicast address in the nsc file is not important, as long as you manually join the multicast group yourself. So, to summarise, I am using an nsc file generated by the server to receive a stream that is intercepted at the IP level by my processing application. This application does its thing and redirects the processed IP packets to a local ip address on the port that is listed in the nsc file. Media Player happily receives the stream. Job done Thanks for all your help Phil. ----- Tim Carter [MVP/Digital Media] wrote: ---- And? Caffeine deprived minds want to know! ;- T Phil Wood wrote > hang on - I think the solution to my problem might be that I don't need to do anything at all. It occurs to me that the multicast address given to the player is only used by the player in sending an igmp join on that multicast address. As long as the Media Player is listening on the correct port (the port that I am sending the unicast stream to) it might not matter what address is in the nsc file >> I'll let you know if this works.. -- Tim Carter / StreamingMeeMe Frontier Digita PH: 508.982.480 AIM: streamingmeemee MSN: streamingmeemee@hotmail.co Microsoft Digital Media MVP 2002-200 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.