I am trying to wrote a VR remote gaming system.
A TCP video streaming program which only send H.264 frames of screenshots from desktop to my android phone. and an Android app sending orientation data in UDP to desktop. Everything was tested in local network
If I only run the sensor sender program. I can see the game camera rotating in real-time.
But if I run the two program at the same time. TCP Screen streaming is always smooth but sensor data receiving start to delay.
Then I lower down the sending fps. It gets smoother but still not acceptable.
TCP traffic has 500KBps~1000KBps
UDP has 600Bps
Does it mean network congestion occuring? How can I overcome this?
What if I change video streaming protocal to UDP? but an I-frame may be larger than 65KB
Related
I have a problem with PeerJS and audio. In particular, I use the stream coming from mediaDevices (both audio and video). In the transmitter page I can see the stream with both audio and video tracks. Instead in the receiver page I can see only the video, and the stream doesn't contain the audio track. What could be problem?
I'm working on Windows 11 with Edge browser, both transmitter and receiver websites are in the same network and I access them through ip.
Thank you!
Not Able to switch off video on my local system, although I am able to do it with the socket signalling server, but that is not saving the bandwidth, I want to save the bandwidth, by turning the audio and video off in reality, and same should happen at peer side.
To switch of Video and Audio at your local system and to see that same effect on the peers side, you need to change the stream and renegotiate with the peer using new SDP constraints, and session constraints.
I'm developing a kind of proxy for video streaming and I'm now dealing with an issue related to packets received out-of-order (without losses). This issue (maybe) is the reason why there are frequent noises in the video playback.
Do you know by chance if VLC is able to reorder packets? If so, it would mean that the reason why there are some noises in the playback is something else, if not, I should just develop an additional layer that ensure the reception with the correct order.
Thanks.
Assuming that you are talking about RTP over UDP, AFAIK VLC uses live555 libraries for client-side RTSP/RTP functionality and live555 has a built in jitter buffer that should take care of re-ordering for you. I can't recall the size of the jitter buffer of hand but 100ms seems to ring a bell.
In case you didn't know: When developing media streaming applications (esp. over UDP) it is important to increase the size of the receiver buffer. If it is full and packets get dropped, which could explain your artifacts.
Also, UDP being unreliable means that you will experience artifacts if packets are lost/corrupted and you have no suitable mechanism to deal with it.
My iPhone application plays a wma audio stream over the mms:// protocol.
When the Wi-Fi connection drops it won't switch to 3G to continue streaming. I have enough buffer to play for another 15 seconds (I tried to increase the buffer size, but it will stop anyway).
What sort of mechanism can I implement so the playing won't stop and the iPhone changes from Wi-fi to 3G?
In other posts I saw that it should do it automatically, but in my case it doesn't, because its wma over mms protocol.
Thanks!
I may be talking out my butt, however, you could try detecting the Error from the connection when it fails. and restart the stream from your buffered location so you can resume the download. If the internet is down the iPhone should reconnect it to accommodate your new request for the mms feed.
I am a php mysql developer ... just an (below) average. and i am interested in the way television and radio are broadcasted over internet live. i want to know how it works and and what are its requirements. i must admit that i am a complete layman but i expect it do by next half month or year or so.
there're a couple of network protocols for multimedia streaming. most popular atm are RTSP and RTMP. typically you need to setup streaming server that takes audio/video from some source and streams to all connected clients. popular streaming servers are Adobe Flash Media Server, Wowza Media Server and others.
Streaming is done over TCP or UDP, depending on your requirements. TCP guarantees that no packets are lost but they can be significantly delayed. This can be smoothed by large enough jitter buffer. Streaming over TCP is often used for one-way streaming from server to client when that delay can be tolerated. UDP is used for "live" streaming, especially in chat/conference, when you cannot tolerate several seconds delay.
RTSP is open standard. You can receive and play RTSP streaming by VLC player (free). RTSP provides a "media session setup" and goes over TCP. Actual streaming is done by RTP/RTCP protocols over UDP or "interleaved" with RTSP packets over TCP.
RTMP is proprietary protocol of Adobe.