This project aims to replace the multimedia server application for the Gateway, GoVideo, and NetGear DVD players & set-top devices. The new server software aims to be more organized and support a wider variety of formats than Digital 5's original.
Be the first to post a text review of Digital 5 Streaming Media Server Project. Rate and review a project by clicking thumbs up or thumbs down in the right column.
I've committed the source code that I've been working with thus far. A working media server is a ways off, but some of the necessary protocols have been implemented, including: -SSDP (Simple Server Discovery Protocol) -SOAP (Simple Object Access Protocol) The DIDL-Lite protocol, a subset of SOAP for UPnP devices (like the connected players), is currently being implemented. A shell framework for the ContentDirectoryService, one of the three necessary services for a MediaServerAV (i.e. what the D5 Server Software is), was also included.
This project has definately expanded its reach since it first started! Originally, the project was intended to replace the D5 Streaming Media Server for the Gateway ADC-220 and ADC-320 Connected DVD Players. Thus, the project was called the Gateway Connected DVD Player Project, or "gwcdvd" for short. However, I've discovered that there are many more players that were developed for vendors by Digital 5, including the GoVideo D2730 and D2740 Networked DVD Players, and the Netgear MP101 and MP115 Wireless Digital Media Players. Thus, the project's name and goal have been updated to reflect that this project is aimed at more than just users of the Gateway players.
Based on the preliminary packet capture, I've been able to determine that the original Gateway server software makes use of the following protocols: 1) SSDP (for locating servers/announcing server presence) 2) SOAP (for file listings/file organization) 3) RTSP (for controlling playback of streams) I'm also under the impression that the software sends out MPEG-1 video encapsualed in RTP and RTCP packets when a video file is being played back, but I'm not entirely sure about this. Ethereal couldn't identify these packets properly at first; I forced it to decode them as RTP and RTCP on a hunch, and most of the fields seem to match up. However, playback of the RTP dump from this hasn't been very successful -- tests with RTPPlay and VLC Player indicate that the packets are being sent too fast or are not really proper RTP packets (I get some blocks of video and audio, but they are incomplete or are sent too fast). I need someone to verify this for me. In other news, it seems that the Gateway players MIGHT be able to accept either an MPEG-1 or MPEG-2 stream, so, if possible, we might be able to increase video quality by coding the new server to send MPEG-2. It seems more natural to stream MPEG-2 only because it is meant for broadcast and handles interlacing automatically. We will have to see if this is feasible or not. For the moment, the biggest challenge is determining how the existing packets are formatted.
Be the first person to add a text review.
Copyright © 2009 Geeknet, Inc. All rights reserved. Terms of Use
Thanks for your rating!
Would you also like to write a review?