After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731749 - rtph264pay negotiation broken
rtph264pay negotiation broken
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-06-16 20:48 UTC by Olivier Crête
Modified: 2018-05-11 17:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Olivier Crête 2014-06-16 20:48:42 UTC 
This simple pipeline fails:
gst-launch-1.0 videotestsrc ! video/x-raw, format=Y42B ! x264enc ! rtph264pay ! application/x-rtp ! fakesink

This is because of a clash between RTP offer/answer negotiation and gstreamer caps negotiation. In GStreamer's caps negotiation "application/x-rtp, encoding-name=H264" means any profile, but in the SDP world, it means the baseline profile. Since we try to merge both, we tried to come up with some solution with clever caps ordering, but it breaks if the input isn't 4:2:0.

My newest suggestion is to just add a "sdp-offer-answer" property on the payloader to switch between the GStreamer mode where no property means anything and sdp O/A mode means baseline/minimum.
Comment 1 Edward Hervey 2018-05-05 15:03:14 UTC 
Olivier ? Any update ?
Comment 2 Olivier Crête 2018-05-11 17:56:46 UTC 
No real update, the problem is still there, I'm not sure how much I care. I think the end solution is maybe to not use GStreamer caps negotiation as SDP offer asnwer compatible, but to add some code to the elements that implement SDP O/A (like Farstream does and WebRTCBin probavbly should do to) that handles this corner case.