Do anybody have idea that how can i convert the RTP packetized AMR audio content into standalone AMR file?
I have the dump of RTP payload and I want to convert it into the standalone AMR file. I have followed up RFC 3267 and RFC 4867 and understood the byte pattern but I havenot found anywhere the also where i can see how can i packetize the AMR frames into RTP or vice-versa.
Regards
Nitin
Done and depacketize the content using the answer givne on the link
AMR Raw Output from Wireshark not playing in players
Related
I need to stream webm video to browser from my video server.
The video server (C++) receives vp8 encoded frame packets of webcam or screen from the client with .ivf headers like <4_bytes_data_size><8_bytes_pts><vp8_encoded_data>. Also I send 4 bytes of total packet duration before the rest of data, so the server knows the presentation timestamp, size and duration of each frame.
The question is: which headers should I use for frames in order for the browser to be able to play the stream in the <video> tag. Maybe there is some standard for webm real time streaming implementing?
PS: AFAIK the webm consists of EBML markup. If the same is used in <video> tag to parse the stream, could someone explain me what are the minimal set of EBML elements for video playback (no audio, just video)?
Video tag does not support ivf. Minimum webm requirement is whatever the minimum is to package your stream.
I have Ogg format file containing OPUS frames. As per my requirement, I need to parse this file (frames/packets), and send OPUS compressed data to a remote device through RTP.
My question is in one RTP packet (assuming 48khz sampling rate)
1. One OPUS frame will be sent
2. Or multiple OPUS frames will be sent
3. Or one packet as per Ogg file format specification, which may be one frame, 2 frames or arbitrary number of frames will be sent
Each Opus RTP packet contains only one Opus packet, as defined by the Opus specification. That may contain more than one Opus frame internally, but it must have the correct header bytes to signal this and conform to other rules, so make sure you mean the same thing the spec does by "frame".
Basically, you want to send each Opus packet out of the Ogg file in its own RTP packet. There's no packing at the RTP payload level. Don't send the Id or Comment headers in the first two packets of the .opus Ogg stream, and of course you need to prepend RTP headers with the appropriate flags, timestamp and so on.
See https://git.xiph.org/?p=opus-tools.git;a=blob;f=src/opusrtp.c#l517 for a toy implementation of this.
I'm using OPUS with avcodec to encode sounds and stream it using my own protocol.
It works with the MP2 codec so far but when I'm switching to OPUS, I have this issue :
[opus # 1b06d040] Error parsing the packet header.
I suppose that unlike MP2, I need to generate a header for my OPUS encoded data stream but I don't know how.
Can someone explain me how to do that? Thanks.
This error comes from ff_opus_parse_packet() failing, which handles the raw opus packet header, what the specification calls the 'TOC' (for table-of-contents) byte and optional subframe lengths. It means libavcodec couldn't find the packet duration where it expected.
So probably your custom protocol is corrupting the data, returning the wrong data length, or you're otherwise not splitting the opus packet out of your framing layer correctly.
You don't need to invent your own protocol if you don't want to. There are two established designs: Opus over RTP for interactive use (like live chat where latency matters) is documented in RFC 7587. For HTTP streaming, file storage for recording, playback and other applications like that use the Ogg container, documented here. There are implementations of both of these in libavformat. See rtpenc.c, oggenc.c and oggparseopus.c if you're curious about the details.
I have written an application which triggers an IP Camera to stream it's data (MPEG4) over RTP. This works fine so far - I start to setup and start the stream with the corresponding RTSP commands ( DESCRIBE, SETUP and PLAY ).
While streaming I receive the usual Sender Reports and send my own Receiver Reports - Everything is working fine here.
Now with the application mentioned above, I do NOT read the stream. I have a seperate hardware , which just logs all the stuff going over the Ethernet ( a little bit like Wireshark ). Now when the whole streaming is finished I can download those logs from my hardware and extract data from them.
So what I have then is a logfile with all the data from the RTP stream as raw data.
My question would now is: How do I write this appropriately into a MPEG4 file? I know this is a very broad question and I don't expect to get a step-by-step tutorial. But actually I am a bit overwhelmed and don't know where to start.If I just memcpy all the Payload from the RTP messages sequentially into a MPEG4 file it doesn't work. Now I am also a bit confused by SDP and stuff.
Well maybe someone has a link or some help for me..?
You should first read RFC3016, which describes the RTP format of MPEG-4 stream, then you'll know how to extract MPEG-4 frames from the RTP stream.
I actually changed from MPEG4 to H.264 - it actually was a little bit easier to write a video file like this. For H.264 this answer covers it pretty much:
How to process raw UDP packets so that they can be decoded by a decoder filter in a directshow source filter
I deal with rtp packets of gtalk video. I want to make video using gtalk rtp payload data. According to my search gtalk use h264 codec for video.
I combined all of rtp payload which is send with gtalk video and wanted to play ffplay using this comment "ffplay -f h264 "filename" but I can't see
anything and I take this error "Could not find codec parameters (Video: h264, yuv420p)". I think my wrong is combining rtp payload. how can I play this payload?
Thanks for your helps.
Cheers.
It could be that you need the sequence and picture parameters sets (SPS and PPS) which are often transferred during session setup. Standard protocols used for this are RTSP and SIP though I have no clue whether gtalk uses either of these.