GNOME Bugzilla – Bug 697308
rtph264 payloader: configure the output caps with the profile-level-id parameter
Last modified: 2013-05-21 07:58:18 UTC
Created attachment 240691 [details] [review] rtph264pay: add profile-level-id to the out-caps Currently, the profile string is created in the gst_rtp_h264_pay_set_sps_pps function but never used (just freed directly). Additionally, according to the RFC (http://www.ietf.org/rfc/rfc3984.txt), the optional parameter profile-level-id, when present, must be included in the "a=fmtp" line of SDP.
The reason we don't set it in the output caps is that in the SDP offer/answer model, profile-level-id flows from the receiver to the sender. It informs the sender of the maximum capabilities of the receiver. And because it is just a string, we can not use the GStreamer negotiation mecanism as non-equal strings can also be valid. The first byte must be either the same or 0x42 (baseline), the second byte must be equal or smaller than what the receive wants, and the third byte is a bit-array that must be a superset of what the receiver supports. Only in the send-only case can you use it to describe the stream, but in that case, it is redundant as the same information is also in the SPS (which you put in sprops-parameter-sets in the SDP).
If you were doing a RTSP server, it might actually make sense, if it is really a requirement for you, we make could add a send-only property that would control what gets put in the caps. There is a pretty exhaustif table of the properties of most codecs that have standardised RTP payloading here: http://cgit.collabora.com/git/farstream.git/tree/gst/fsrtpconference/fs-rtp-codec-specific.c#n171
Would be nice to add some rtph264pay docs and describe this there (or at least a comment in the code so it can be added to docs later).
Thank you for your explanation. Yes, it would be nice to have a send-only property. Alternatively, the pbutils library could be extended with some helper functions making it much easier to decode the sprop-paramter-sets information and extract more information from the sps data, e.g: codec_utils_h264_get_sps_pps (...); codec_utils_h264_get_max_bit_rate (...); // needed for b= line codec_utils_mpeg4video_get_max_bit_rate (...); etc What do you think?
I might make sense to add a bitrate=(int)X or max-bitrate=(int)X (for fixed and variable bitrates) to the application/x-rtp caps for the codec where it's easy for the payloader to figure it out. That said, I don't think in H.264's case it makes much sense to try to guess that from the Level, this is more something you would set on the encoder, no ?
I do not know if I understand you correctly. What do you mean by guessing the bitrate value from the level information? The max bit rate values are present in ISO/IEC 14496-10:2008 table A-1 and the only thing you need to know is the level and the constraint set information. Am I misunderstanding something? Just summarizing: in the send-only case I would like to configure the output caps with the profile-level-id (it has to be present in the fmtp line of the SDP) and bit rate (this information is needed for the bandwidth SDP line).
The profile will indeed provide you with an absolute upper bound, but it is likely to be much higher than the actual max bitrate output by the encoder. So you should get much better information directly from the encoder.
It may actually make sense to have the encoders output GST_TAG_BITRATE and GST_TAG_MAXIMUM_BITRATE and use that to set the b= line
Ok. The bitrate is also no problem any longer. Thank you for your explanation. Going back to the profile-level-id and the suggested by you the send-only property in the payloader: what would the default mode be? Sending and receiving (<=> send-only == FALSE)?
Hello again, profile-level-id is present in the out-caps in rtpmp4vpay. There is no offer/answer mode in that case. Should it be? Thank you for any answer!
I guess ideally yes, I think in practice no one does calls using MP4V-ES