I am streaming a RTSP video from vlc on windows to ipad app. And I capture packets in wireshark. I can see RTP packets in wireshark and also the RTP header fields like payload type, timestamp, sequence number. My question is, is it possible to decode the RTP payload as H264 NAL units. Currently I can only see the bytes in payload.
You need to configure Wireshark to understand that the RTP dynamic payload type maps to H264.
To do this, use the menu; Edit->Preferences->Protocols->H264
Set H264 dynamic payload types to the value shown in the RTP decode for the payload type.
Related
I read https://stackoverflow.com/a/24890903/12279500. , But when I looking h264 over rtp I recognize Sps,Pps,Idr .... But didn't see h264 start code before each NALU.
Why is that?
How many h264 formats there are , not include Annex B and AVCC
RTP has its own payload format described
in RFC 6184
As for how many formats there are, assume infinite because nothing is stopping anybody from creating more.
The start codes are used to split each NALU in byte stream because the NALU header doesn't have length info. But in rtp protocol, the NALUs are in payload field of the packet so it doesn't need the start codes. You only need to split each rtp packet.
I would like to know the container format of the following stream:
rtsp://8.15.251.47:1935/rtplive/FairfaxVideo3595
According to ffprobe, the container format is RTSP (format_long_name = RTSP input).
I also looked through the debug messages in VLC but I did not find any information on the stream's container format. What I DID find was that the codec was H264 and that VLC was using live555 to decode the stream. The media files live555 can support according to their website (http://www.live555.com/mediaServer/) makes me think that the above stream is an H264 elementary stream and is not in a container format. Am I correct?
Also, if the stream indeed does not have a container format, is it ok to say the container format is RTP (not RTSP as ffprobe says) because that's the protocol used to send the media data?
Thanks!
RTSP is more of a handshake done with the server, while RTP is the actual stream coming in once the handshake is done and you start streaming. RTSP URLs usually start with RTSP://... and the sequence of requests goes roughly something like
RTSP DESCRIBE, RTSP SETUP, RTSP PLAY, TEARDOWN
The response from the server to DESCRIBE will contain the information you need to know about the encoding of the file (H264, JPEG, etc.) while PLAY will cause the server to start sending the RTP stream. I suggest looking up RTSP SDP (session description protocol) for how to extract this information.
In case of streams, you are most likely correct, since the protocol used for streaming is usually RTP, and it tends to go hand in hand with RTSP (however I'm unsure whether or not we can apply the term container in the context of streaming)
I am working on an implementation of RTSP in J2ME to connect to Wowza. I have the RTSP part working, and the extraction of RTP packets. I am able to decode and display the h264 video stream.
I am having problems understanding how to create an appropriate audio stream to pass to a J2ME Player object.
As part of the RTSP Setup exchange I get the following information from SDP
m=audio 0 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000/1
a=fmtp:96 profile-level-id=15;object=2;cpresent=0;config=400026103FC0
a=control:trackID=1
From this I know that I can expect RTP packets, containing MP4A-LATM format audio, and (most importantly) the mux config data is not present in line with the stream. The mux config data is 400026103FC0
I just don't know how to interpret the config string, and how I might configure a J2ME Player.
Hi I would like to stream data from my webserver.
here is the catch. The data does not exist on my server I retrieve it as a live content from another server.
So I do not have the size of the file. How do I stream this data.?
I read PCM in chunks (OF DIFFERENT SIZES) convert it to OGG.
Send the OGG HEADER and the OGG CONTENT down to html5 audio tag
Or at least this is what I want to do.
recap :
I am server "A",
There is another server "B" which servers PCM data.
Client request comes from an AUDIO tag from HTML5 to server A to get the Data In server B( This data does not have a size,constant streaming).
A recieves PCM from B
Converts to OGG.
Sends it along the http response object as binary data.
Any ideas.
HTTP/1.1 supports chunked encoding exactly for this use case.
Is there an easy not horrifyingly complex way to detect key-frame in an H264 video stream wrapped in a Transport Stream?
Also, if extra previous packets needed for the decoding of the key-frame is there a way to find those as well?
There is no super simple way of finding the I frame. You have to read the transport stream packets of the AVC stream. Then you have to assemble the packetized elementry stream packets (PES), strip the PES header and then identify the NAL type 5.
So you will need an transport stream demuxer, find the beginning of PES packets and do minimal H.264 parsing.
For demuxing you could look at this source code: http://tsdemuxer.googlecode.com/svn/trunk/v1.0/tsdemux.cpp