Is sprop-parameter-sets or profile-level-id the SD

Question

I'm trying to understand what is the required parameter in SDP to be able to decode H264 from RTP packets.

This is an related to this question, for the answer to that one works only in small number of cases.

Example

I am streaming from VLC with the following command.

vlc -vvv sample_video/big_buck_bunny_480p_h264.mov --sout '#transcode{vcodec=h264,vb=700,fps=20,scale=0.25,acodec=none}:rtp{dst=10.5.110.117,port=5004,ttl=1}'

This transcodes the video to:

• Bitrate: 700kbps
• Frame rate: 20 per second
• Resolution: 25% of the original

The receiver correctly accepts and interprets the stream with the following SDP file (remove the first line, its just a name).

//test.sdp
c=IN IP4 10.5.110.117
m=video 5004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=640014;sprop-parameter-sets=Z2QAFKzZQ0R+f/zBfMMAQAAAAwBAAAAKI8UKZYA=,aOvssiw=;

Command to run: vlc test.sdp

The document available here, named SIP Video Profile Best Practices in chapter 7.2 for profile-level-id states:

profile-level-id

While specified as optional (as are all parameters) in RFC 6184, the 'profile-level-id' parameter is fundamental to the setup of the codec, and is also required for any further parameters to be specified. Hence all implementations should include this parameter in their SDPs, and should interpret it when receiving it. If not included, the default value is 420010, as specified in RFC 6184.

The same document states the following for sprop-parameter-sets:

sprop-parameter-sets

H.264 allows sequence and picture information to be sent both in-band, and out-of-band. SIP video implementations should signal this information in-band, conforming to the model prevalent in H.323 and in the overwhelming majority of existing SIP video implementations, and hence this parameter should not be included.

Problem 1

The video is correctly interpreted on the receiver even when profile-level-id is removed.

//test.sdp
c=IN IP4 10.5.110.117
m=video 5004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 sprop-parameter-sets=Z2QAFKzZQ0R+f/zBfMMAQAAAAwBAAAAKI8UKZYA=,aOvssiw=;

It doesn't work without the sprop-parameter-sets.

Problem 2

I've been wire-sharking different RTCPs,SIPs and SAPs and often the SDP doesn't contain the sprop-parameter-sets.

Questions

• Please explain the meanings and differences between the two paramters
• Based on the answer to the question above, explain the contrast that occurs in the problems

Answer 1

Meanings and main differences:

As you can see in your definition of profile-level-id, it has a default and so it can be omitted in the signalling negotiation. The string contained in this parameter is in hexadecimal format and it has 3 bytes that inform the decoder about the profile, the constraints and the level that will be used to send data. This settings define several parameters like the bitrate, the resolution, the type of packets...

The parameter sprop-parameter-sets can be seen as the key to decode the data that you will be sending. It contains some bytes that will be used to encode the data, and so you share it with the receiver so that it can decode the video packets. It can also be omitted from the signalling, but they are mandatory for the decoder, so they can also be sent in-band. So if you omit them in the sdp, they need to be sent in the packets. The receiver can only decode the data after receiving this information.

Problem 1:

As stated before, profile-level-id can be omitted and it still works because the default 420010 will be used. The only difference is that the settings will be different, and probably, the video quality will be affected. For example, 42 in the default is referencing the Constrained Baseline Profile (CBP) and the 64 in your initial value in SDP is referencing High Profile (HiP).

The video is not working when sprop-parameter-sets is missing probably because vlc does not support sending that data in-band, and as I explained above, it is mandatory.

Problem 2:

Many SIP implementations has support to send sprop-parameter-sets in-band, and that's what you are capturing. Check the h264 packets in Wireshark, and you will see the description for this values in some packets.