Support setting fmtp even when rtp type does not match with a warning.

[xenon]

Issue

When the rtp type does not match the fmtp type the current behavior is to fail (ie: too pedantic of a parse in this case as it does work if we ignore that).

Changes

• I've changed the behavior so that we will try the non-matching fmtp type as a last resort instead of failing immediately
• Added a test using the RTSP DESCRIBE for a camera with this issue

[scottlamb]

Thanks! I appreciate the included test data.

Without this patch, is it failing to work entirely? My intent (and what I remember seeing with other cameras) is that it just ignores the out-of-band codec parameters (which are optional anyway) but will see any included in-band. And so far I've never encountered a camera that doesn't include them in-band.

[xenon]

Thanks! I appreciate the included test data.

Without this patch, is it failing to work entirely? My intent (and what I remember seeing with other cameras) is that it just ignores the out-of-band codec parameters (which are optional anyway) but will see any included in-band. And so far I've never encountered a camera that doesn't include them in-band.

I should clarify what I mean by fail is that the following assertion fails before these changes assert!(p.streams[0].parameters().is_some()); (see the added test). Or to answer your question: No it doesn't fail entirely but it does drop the parameters which are otherwise fine.

I think this is somewhat independent of whether or not the user wants to ignore out-of-band codec parameters it's more related to how pedantic we want to be about constructing them. (ie: pedantic -> None, not pedantic -> Some but may not be perfectly accurate). I don't think this contradicts your goal of using in-band information. The patch just makes out-of-band params less pedantic in this case.

Also thank you for creating the library in the first place.