Thoughts on the implementation process of streaming media [posting]

Streaming media:
Because we had a little bit of directsound experience and a little bit of Network practice. come up with a routine. from the file format, DS, compression encryption, protocol commands, and various server technologies seem to be involved. (simple, don't make money, unless you like it ..)

First, if you do not use other sdks or sound engines, it is basically difficult to develop your own. directsound can satisfy the "Custom" sound. You can write the buffer and lock the playback. you can add a variety of worry mirrors before this (it seems that some people are also called dfs or something, they are all similar, I'm called a worry mirror habit ..)

Second, if you don't want to use WAV (nonsense, so large), you need to involve a set of protocols suitable for network transmission. Don't tell me zip. We need to be real-time, or lossy. Our buffer should be as small as possible. on the contrary, network buffering should be as large as possible to ensure "no card" (at least useful for VOD, such as RealONE green bars, which can always be used as a buffer)

Third, with its own compression format, it will eventually be restored to riff for playback to fill the DS buffer. of course, it can be done without compression. After all, it is only to explore its implementation. The compression part is only available from point to point. Similarly, encryption is also used here, for example, we use one hash for all the masks (you can also hear it if you play it directly... but this kind of considerations ....)

Fourth, the client creates enough network buffering. Depending on the On-demand broadcast and broadcast, the broadcast latency cannot be too large (that is, our broadcast is not live broadcast, it takes several seconds to slow down)

Fifth, server. it is troublesome for many people. by the way, do you still remember IE and IIS. they use the HTTP protocol. Media Player classic or other players can also be used for on-demand video streaming. They do not download the entire file. If you do not believe it, try it. the ultimate goal of the Protocol is to better transmit data. it also indicates that if you do not want to use your own protocol, you can refer to other protocols, and then you can make a client to read data. however, it seems that a simple protocol is much simpler (in my opinion) than http to directly create a socket and then send a simple get seek find .. enough. the port can be temporary new. In fact, for the performance of the server, hundreds of people are the limit. It is really not possible to create all the rows directly with arrays at the beginning, but it can be less troublesome. (-_-B seems to be far away)

Sixth, collaborate. the server transmits data. If more is done, it is nothing more than complicated things such as server Load balancer and multithreading .... it is not difficult but complicated to study the process. the procedure is as follows:
1. The server starts listening.
2. Start the client
3. user input
4. The client sends a request to the server
5. Establish a connection to start transmission, and select the corresponding Compression Based on the customer's needs (different sound quality)
6.1 server sending data 6.2 client filling network Buffer
7. The client starts playing the video and keeps the connection to continue data transmission.
8. Stop and disconnect (completed, abnormal)
9. The remaining content (or stop) in the client playback Buffer)

The whole seems so simple. I plan to use VB. net (2K3) + dx9sdk (05 summer. in the middle, WAV network playback is used. Although it looks like P2P, it is still CS. A maximum of two users are supported at the same time, because you do not want to involve too many sockets and threads.

If you want to make the design more reasonable, all plug-ins need to reserve interfaces, such as the compression, which can be completely independent, and then select the corresponding compression/encryption DLL according to the customer's request. this is the architectural design. we use 1 server and 2 server to discuss implementation, so we don't need to consider that large architecture... (How can I spend so much time... in addition, hundreds of people are the limit)

Original article: http://blog.csdn.net/a11s