UPnP uses standard TCP/IP and Internet protocols and can be used well in existing networks. Using these standard protocols, UPnP can benefit from all kinds of existing experience and knowledge, breaking all kinds of information islands and surpassing various kinds of information. The physical layer can be wired or wireless, and has the basic characteristics of mutual cooperation between devices.
Currently, DLNA (Modern Digital Home) is a very active area, and UPnP is one of the mainstream protocols. The vision of DLNA/UPnP is to build a wired and wireless interoperable network consisting of personal computers, household appliances and mobile devices, enabling device interconnection and network control within the home to enable audio and video entertainment and content sharing.
The UPnP component includes a device node, a service node, and a control node. In a UPnP network, the smallest controllable unit is the service, which uses a series of state variables to describe the "behavior" and "state" of the service. UPnP uses a variety of existing standard protocol ports, including TCP/IP, HTTP, HTTPU, SSDP, and GENA. Interoperability between devices is guaranteed using standardized protocols. In short, UPnP is built on top of various protocols, not APIs, which allows it to be applied to a variety of different platforms. At the same time, it is built on a variety of existing standards, with great flexibility, can adapt to the needs of various network equipment now and in the future.
2 The basic idea of ​​UPnP media player design
2.1 Functional Description
   The UPnP network media player can provide various entertainment information obtained from the network, which allows the control node to control it. In addition, the player can also provide control over the data stream, depending on the supported protocols. A standard UPnP network media player includes playback control services, connection management services, and media delivery services. Any media player provides at least two services: a play control service and a connection management service. The media transfer service is optional and depends on the transport protocol supported by the device. The protocol used here is HTTP GET, which provides media transport services so that data streams can be controlled during data transfer.
2.2 Process Description The media player can control the playback of the media provided by the media server in the local area network by the control node. The interaction process of the media server, the player, and the control node is as follows: the control node uses the SSDP protocol to discover one or more media servers and media players in the local area network, first locates the resources on the media server, and needs to explicitly identify the server and play. The protocols required to transfer data between devices and the data formats they all support. After these transmission parameters are determined, the control node can control the content of the transmission, such as play, pause, stop, and so on. True data transfer is done directly between the server and the media player and is independent of the control node and is therefore not included in UPnP. That is, the transmission of the content is a protocol other than UPnP. Afterwards, the control node uses the content directory service provided by the media server to obtain the protocol and data type supported by the server, and uses the connection management service of the media player to obtain the corresponding information, and compares the selected transmission protocols supported by both parties. type of data. In this design, the transport protocol used is HTTP GET, and the supported data format is MP3. Finally, the control node uses the media transport service provided by the media player to control the data stream.
This article refers to the address: http://
3 UPnP media player implementation method is designed using Intel's open source UPnP development tool Device-Builder, at Microsoft. Developed under NET Framwork. The UPnP protocol stack generated by DeviceBuilder is composed of MiniServer module, HTTP module, thread library module, XML parsing module and protocol stack programming interface. It is responsible for providing basic UPnP functions. The specific implementation process is as follows.
3.1 Generate UPnP framework Use DeviceBuilder to generate code on the corresponding platform, as it is at Microsoft. Developed under NET Framwork, so the Target Platform selected should be: Windows 98, NT, XP. Specific functions include: addressing, discovering, describing, controlling, and publishing events. The functions are combined to provide UPnP capability for the media player, but the Intel development kit generates only a framework, adding decoding, control functions, and recognition of playlists.
3.2 Add Media Decode Library Download an open source player and transform it into a media decoding library. The function of the player is abstracted into a function for external calls. The main functions are as follows:
Int decodestart(char*pBuffer): Call this function to start playing, which is equivalent to the original player's play function. pBuffer is a public buffer that stores downloaded media data.
Extem void Read(int*position): Responsible for loading the downloaded media data into the common buffer. The position pointer corresponds to the location that should be loaded in the common buffer. Since the general download speed is much faster than the decoding speed, care should be taken not to overwrite the undecoded data when loading new data.
Extern void Decode(int*Dposition): Starts decoding when the outside world calls the function, and Dposition indicates the decoding position corresponding to the common buffer.
In addition, there are functions such as pause, resume, and stop, which all correspond to the corresponding functions of the original player. The implemented media decoding library is added to the generated UPnP framework, and the functions in the library file are called at corresponding positions in the UPnP framework to implement decoding and playback control.
3.3 Playback control function After adding the media decoding library. Also need to add: real-time control of the data stream, publish messages according to the state of the player. The detailed process is as follows:
(1) Setting the transmission address When the control node selects a song from the media server, it triggers the action of setting the transmission address (provided by the media transmission service). At this time, if the player is playing, first stop the player's decoding action and prepare for the playback of the new song. Next, after the player obtains the address of the selected song (provided by the control node), the song is downloaded directly from the media server, in which the player downloads using HTTP GET. Before downloading, you need to judge the URL to see if the downloaded one is a playlist. If it is a playlist, you can't pass it directly to the player, but continue to get the first song from the address provided by the playlist. URL, then download from the media server. Finally, the function SetLastChange is called to publish its own state information.
(2) Real-time control of the data stream triggers the action of Play in the transmission control service when the size of the download reaches a certain length. At this time, the main thread creates a decoding thread, and the thread calls decodestart(char*pBuffer) in the media decoding library. The function decodes and plays the data stored in the common buffer for synchronization control, so that when the network is congested or the system has insufficient memory, the play pointer in the buffer exceeds the download pointer and causes an accident. If a playlist with multiple songs is selected, the process is similar, except that when one song is played, another song is automatically downloaded from the media server side while downloading and playing. When the user clicks next, previous, first check whether the previously saved URL is a playlist, and if not, output an error message; if not, stop the player's decoding action, undo the current decoding thread, and prepare for the new song to play. The address and port number of the next song are obtained from the playlist, the download data is started, a new decoding thread is created, and finally, the status information is released.
All actual operations, such as play, stop, pause, ..., are independent of UPnP, which only implements messaging. The control node is responsible for receiving commands to the player, and then decoding, playing, pausing, and stopping functions by the media decoding library in the player. The interaction of the media server, control node, and media player is shown in Figure 1.
 |
4 After the test and analysis system is developed, test it on two desktops that are on the same LAN. The test process is as follows: First, start the AVWizard program in the Intel UP-nP tool set on one machine. The program is actually the media server and control. A combination of nodes that provides both the functionality of a media server and the ability to provide control points. To start the media player on another machine, AVWizard first scans the network for devices it supports. After discovering the media player, it obtains the device description file of the player and displays the name of the player. Select an MP3 with AvWizard and send the address to the specified media player (UPnP MediaRender). The player starts to download MP3 from the address specified by the media server, and starts playing when downloaded to a certain length. The detailed process is described as follows:
As can be seen from Fig. 2, when AVWizard selects a song, the player outputs: "Invoke: UPnPAVTransport_SetAVTransportURI...". Triggers the action of setting the transport address in the media transport service in the player. Tell the URL and port number of the media that the player needs to download. Then, when you click play in the AV Wizard, you can see that the player output in Figure 3 is: "Invoke:UP-nPAVTransport_Play(0,1)", trigger playback. The play action in the media transfer service starts downloading the content to be played. At the same time, the player starts to create the decoding thread, and outputs: "Create thread success!!", indicating that the decoding thread is successfully created, and the media decoding is called in the decoding thread. A function in the library. The media decoding library: "...The main proccess start...player_init", initializes the media decoding library, decodes and starts playing music.
 |
5 Conclusions This shows that the media player is successful, but there are shortcomings: the interface is not friendly enough because it is developed directly on the code generated by Intel's open source UPnP development tool DeviceBuilder. The innovations in implementing the media player are as follows: (1) Development directly on the UPnP framework generated by Intel. Compared with many existing open source UPnP SDK developments, there is no need for device initialization and registration, and no work for UPnP. The manual operation of the process allows the developer's attention to be completely focused on the services that need to be added, without paying attention to the cumbersome protocol communication details and simplifying the design and development of UPnP applications. However, the disadvantage is that many SDK development packages are similar in the industry. The ability to directly use the generated UPnP framework is not conducive to replacing the protocol library on demand. (2) The corresponding protocol framework can be generated on different operating systems to shield the differences of the development platform, so that developers can implement the required services on the appropriate platform. (3) The service itself can also be added as a module to the application. For example, the media decoding library is added as a separate module to implement loosely coupled applications and components, which can be implemented according to changing conditions and requirements. The feature extension of the player provides a good foundation.
FTTH Tools are necessary for the assembly of mechanical splices and bring you a higher working efficiency.They are especially used in FTTX solution,combining the function of indoor stripper,cleaver,cleaning,and testing. A series of FTTH tools is visual Fault Locator, fiber optic cleaver, fiber optic cable handle optical power meter, fixed length guide rail groove, fiber optic connector cleaner, fiber toolkit, FTTH cable crimping tool, fiber cable stripper, etc. Foclink,a reliable supplier of FTTH tools,is always beside u 7*24.
FTTH Tools
Fiber Optic Tool Kit,FTTH Planning Tool,Fiber Optic Tester,Fibre Optic Checker
Foclink Co., Ltd , http://www.scfiberpigtail.com