Wowza Community

How does rtpForceH264ConstraintValue effect the profile_level_d?

I am using the rtpForceH264ConstraintValue to get the Chrome browser to accept profiles other than just baseline - I was successful using the 192 to get Chrome to accept the main profile (4D)- trying to get it to accept a high profile (64) - currently gets rejected with a SDP error - what value should I set the rtpForceH264ConstraintValue to? How does the rtsForceH264Constrait value relate to the profile_level_id value specified below? ,“avc1.66.30”: {profile:“Baseline”, level:3.0, max_bit_rate:10000} //iOS friendly variation (iOS 3.0-3.1.2) “avc1.42001e”: {profile:“Baseline”, level:3.0, max_bit_rate:10000} ,“avc1.42001f”: {profile:“Baseline”, level:3.1, max_bit_rate:14000} //other variations ,“avc1.77.30”: {profile:“Main”, level:3.0, max_bit_rate:10000} //iOS friendly variation (iOS 3.0-3.1.2) ,“avc1.4d001e”: {profile:“Main”, level:3.0, max_bit_rate:10000} ,“avc1.4d001f”: {profile:“Main”, level:3.1, max_bit_rate:14000} ,“avc1.4d0028”: {profile:“Main”, level:4.0, max_bit_rate:20000} ,“avc1.64001f”: {profile:“High”, level:3.1, max_bit_rate:17500} ,“avc1.640028”: {profile:“High”, level:4.0, max_bit_rate:25000} ,“avc1.640029”: {profile:“High”, level:4.1, max_bit_rate:62500} Tim

rtpforceh264constraintvalue only sets the constraint flags for the profile-level-id. It does not affect the profile or the level. Setting constraint flags to a positive value just tells the decoder that it can expect a constrained h264 bitstream.

Altering the constraint flags to positive when the source stream is not constrained is effectively lying to the browser and hoping for the best. I find that chrome will play most levels of baseline and main, but firefox will choke on main. All browsers will throw an error if the profile level id indicates that the bitstream is not constrained.

The best (as in least variable) solution is to start out with a constrained baseline source and don’t alter the constraint values in the SDP.