locked
Does MF support HTTP and RTSP protocols? RRS feed

  • Question

  • Are media streams via HTTP/RTSP etc standardised/proprietry protocols or do they vary from manufacturer to manufacturer? I've been working with two different IP cameras, an AXIS Q1755 and a SANYO HD4000P. The Axis streams H.264 over RTP, RTSP and RTSP over HTTP. The SANYO streams H.264 from UDP broadcast and HTTP. In both cases, authentication of the media source during the rsolving process is fine. Both return Unsupported Byte Stream(could have been Unknown but I'll check it again).

    Appart from the software that comes with each camera, I can't get the cameras to stream to any other product except for one package called Luxriot. Luxriot has a list of cameras which it obviously understands how to communicate with them. Was Media Foundation framework designed to connect to these kind of network media sources?
    • Edited by The March Hare Thursday, September 3, 2009 10:16 PM clarify title
    Thursday, September 3, 2009 5:29 PM

Answers

  • The network media source in MF was designed for Windows Media Server and WMS-derived (such as WMP media sharing) media streaming, though there is no specific reason why it should not work more generally.  HTTP streaming is through the WMSP protocol, which is published but not widely used outside of Microsoft.  RTSP streaming is through the standard RTSP protocol ( http://tools.ietf.org/html/rfc2326 ), but only the ASF container is supported.  RTP is more generally supported.  HTTP progressive download is supported through the MF HTTP bytestream for all inbox formats, and could be supported by any custom media source as well.

    Part of the problem is that if vendors add their own private goo to the protocol or do not implement the protocol  correctly, the network source will not be able to deal with the stream.  This is a problem that DLNA was intended to solve, and theoretically the network source should work beautifully with any DLNA certified devices. 

    If you wanted to create your own custom network source to deal with these cameras that do not work natively, a custom scheme handler would be the way to go.  Your application would probably need to use the MF plugin control (http://msdn.microsoft.com/en-us/library/dd388507(VS.85).aspx) to make sure that its own scheme handler gets picked up over the in box one.

    As an aside: netmon (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f) is a useful tool for delving into protocol issues.  It should give some clues as to why the streaming is failing by looking for when the connection suddenly closes or when an error reply is sent.
    Tuesday, September 8, 2009 10:30 PM

All replies

  • AFAIK, there is no standard for network cameras.  A search of the dshow newsgroup will find information on this topic.

    On the subject of network protocols and MF see this recent thread:


    There are also a number of discussions on RTSP in the dshow forum.  I have not seen anything in the MF docs that suggests RTSP is supported natively in Windows 7 by MF.

    Please use Vote As Helpful (green up arrow at top-left of posts) and Mark As Answer where appropriate.
    My dshow site is http://tmhare.mvps.org.
    Thursday, September 3, 2009 10:18 PM
  • http://msdn.microsoft.com/en-us/library/aa965244(VS.85).aspx indicates various modes of RTSP support. I've managed to stream from my Windows Media Server via an MMS publishing point which is the same as RTSP video/audio streaming. Can implementing a custom scheme handler assist me at all?
    Friday, September 4, 2009 1:10 AM
  • Thanks for that link, I hadn't seen that page.  I need to download the new MSDN MF docs as a CHM so that I can search them more easily :)

    Hopefully Matt or someone else who's more familiar with this area can answer your question on the custom scheme handler.

    Please use Vote As Helpful (green up arrow at top-left of posts) and Mark As Answer where appropriate.
    My dshow site is http://tmhare.mvps.org.
    Friday, September 4, 2009 2:40 AM
  • The network media source in MF was designed for Windows Media Server and WMS-derived (such as WMP media sharing) media streaming, though there is no specific reason why it should not work more generally.  HTTP streaming is through the WMSP protocol, which is published but not widely used outside of Microsoft.  RTSP streaming is through the standard RTSP protocol ( http://tools.ietf.org/html/rfc2326 ), but only the ASF container is supported.  RTP is more generally supported.  HTTP progressive download is supported through the MF HTTP bytestream for all inbox formats, and could be supported by any custom media source as well.

    Part of the problem is that if vendors add their own private goo to the protocol or do not implement the protocol  correctly, the network source will not be able to deal with the stream.  This is a problem that DLNA was intended to solve, and theoretically the network source should work beautifully with any DLNA certified devices. 

    If you wanted to create your own custom network source to deal with these cameras that do not work natively, a custom scheme handler would be the way to go.  Your application would probably need to use the MF plugin control (http://msdn.microsoft.com/en-us/library/dd388507(VS.85).aspx) to make sure that its own scheme handler gets picked up over the in box one.

    As an aside: netmon (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f) is a useful tool for delving into protocol issues.  It should give some clues as to why the streaming is failing by looking for when the connection suddenly closes or when an error reply is sent.
    Tuesday, September 8, 2009 10:30 PM
  • After a lot of negotiating with various un-named manufacturers, many of the vendors stated in general documentation that video streaming via RTSP over HTTP was supported but in fact turned out to only provide remote control of media streams. I have found one manufacturer that has handed me everything I could have wanted with respect to development and am happy with the hardware's facilities.

    It's all non-standard by any means and will most likely require the creation of a custom source. Making a new thread in relation to this.
    Friday, September 18, 2009 6:26 PM