Can someone provide training or documentation about how actually video flows between two sip clients. I know basics of where client apis but don’t have much knowledge on how rtp packets are formatted , send over wire and received by other client
What are the header and what happens during packet loss
And how does a video gets converted into a rtp packet
Colin Perkins book "RTP: Audio and Video for the Internet" book is, despite being published in 2003, still the best guide for this.
Related
On AWS, how do you play video from MediaLive through the UDP output group?
For my use case, I'm building a live stream pipeline that takes an MPEG-2 transport stream from MediaLive, processes it through a UDP server (configured as an output group), and consumed by a web client that plays on HTML5 video.
The problem is: the data is flowing, but the video isn't rendering.
Previously, my output group was set to AWS MediaPackage, but because I need the ability to read and update frames over live stream, I'm trying to feed through UDP.
Is setting the output group to UDP the right approach?
The documentation is a bit sparse here. I'm wondering if there are resources or examples where others were able to play video this way as oppose to HLS/DASH.
Thanks for your post. Yes the UDP or RTP output would be the right choice of output from MediaLive. Appropriate routing rules will need to be used on any intermediary routers or firewalls to ensure that the UDP traffic can reach the client.
You wrote that 'the data is flowing, but the video isn't rendering.' This suggests an issue with the web client.
I suggest adding another identical UDP output to your UDP server and sending its output to a computer (or AWS Workspace) running a copy of VLC player. Decoding that new stream will give you a confidence monitor on the output of the entire workflow up to that point. This will help isolate the problem.
You could achieve the same result with a packet capture or TS stream analyzer if you want to go that route instead. If you go this route, I recommend trying to play back one of the packet captures locally with the web client.
I'm trying to build a system for real-time analysis on server for video streamed from the client using WebRTC.
Here is what I currently have in mind. I would capture the webcam video stream from the client and send it (compressed using H.264?) to my server.
On my server, I would receive the stream and every raw frame to my C++ library for analysis.
The output of the analysis (box coordinates to draw) would then be sent back to the client via WebRTC or a separate WebSocket connection.
I've been looking online and found open-source media server like Kurento and Mediasoup but, since I only need to read the stream (no dispatch to other clients), do I really need to use an existing server? Or could I build it myself and if so, where to start?
I'm fairly new to the WebRTC and video streaming world in general so I was wondering, does this whole thing sound right to you?
That depends on how real-time your requirements are. If you want 30-60fps and near-realtime, getting the images to the server via RTP is the best solution. And then you'll need things like a jitter buffer, depacketization etc, video decoders, etc.
If you require only one image per second, grabbing it from the canvas and sending it via Websockets or HTTP POST is easier. https://webrtchacks.com/webrtc-cv-tensorflow/ shows how to do that in Python.
I'm a newbie with RRTCC and I really dont understand how RRTCC adjusts incoming media bitrate.
I tried to read Internet Draft of RRTCC but cannot figure it out: https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-congestion-03
It calculates the estimated bandwidth based on delay and loss, so what's next?
How it can directly control the sending rate to control congestion?
The RTP receiver doesn't directly control the sending rate. It just sends status information to the RTP sender, which is the only one capable of controlling its own sending rate.
draft-alvestrand-rmcat-congestion has been replaced by draft-ietf-rmcat-gcc so I recommend that you use the later one.
In section 2. System model it explains that the RTP receiver should also act as a RTCP sender, in order to send REMB messages to the RTP sender. These messages should be sent by the RTP receiver as soon as it detects any congestion, and then keep sending it at a rate of once per second even if no congestion is happening. Then the RTP sender uses the information in the received message to decide if the transmission bitrate can be raised or should be immediately lowered.
I am one of the authors of the draft. If you are interested in understanding the design criteria you can also take a look at this paper:
G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo
Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)
Proc. ACM Mmsys 2016, Klagenfurt, Austria, May 2016
which is available for download at http://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf.
I have a GSM modem with a serial port and soldered points for MIC and Speaker. Through the serial port I can send AT signalling commands, send SMS and make/receive calls. I had to solder a speaker and a MIC to the modem card. My problem is that I want to read the audio stream as a RTP stream, possibly through some intermediate hardware/software. My goal is to ultimately get the audio as a RTP stream on some port with some RTP profile. I understand that I need to run a UDP server to serve the audio over a UDP IP-address/port tuple, but how do I get the audio to the UDP server in the first place? Codec conversion is also something that I am familiar with and am aware that I may need it.
This is a simplified diagram of what I intend to do:
GSM-modem-audio ---*1*---> audio-over UDP(ip-address:port)---->
>---*2*--> Kurento RTPendpoint---*3*--->Kurento-WebRTC endpoint
I don't know how to handle part * 1 * piece of the puzzle.
Easy way: get Rassbery-PI, get usb sound card, connect analog output of modem to sound card.
Have be no problem convert digital ALSA sound card signal to rtp stream.
More complex way - create special hardware which will do same.. oh wait! That will be like sangoma board.
Anyway it is not wise idea create something like that yourself except for educational purpose, becuase it will be costly or low quality.
we are using zte usb modem. we try to call by AT command (ATD) successfully. But there is no sound when remote device answered.
Does anyone have any idea?
My problem was associated with ZTE usb modem.
I solved the problem.
i can receive and send voice separately to voice port now. But i can not get clean sound like WCDMA UI.
how can i receive and send data with high quality?
Please look at my source code. [http://serv7.boxca.com/files/0/z9g2d59a8rtw6n/ModemDial.zip]
Does anyone now where is my error?
Thank you for your time.
a) Not all zte usb modems supports voice, to detect if modem supports check for ZTE voUSB Device in your ports list.
b) If port present, voice will go through it in pcm format, with 64kbps frequency (8000 samples per sec, 8 sample size).
In your own program, you should read audio stream from there.
stream is additionaly encoded with g.711, so you need to decode it before sending to audio device
It is fairly common to shut off the speaker after connection. Try sending ATM2, that should make the speaker always on.
Basic hayes command set:
M2
Speaker always on (data sounds are heard after CONNECT)
I'm trying to use asterisk's chan_dongle module on ZTE MF180 Datacard model with activated voices abilities.
Originally chan_dongle using raw PCM format on voice data.
But i was discover, that ZTE using ulaw format on sending and recciving voice data.
You can get voice data and save file in this format for learn by using standard Asterisk's Record(filename:ulaw) command in dialplan.
My voice data, dumped from ZTE modem in the same format.
I check it. ZTE dumped data was successefully played by Asterisk's command Playback(dumped)