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 784703 - Rtsp-over-http includes port 80 in internal uri
Rtsp-over-http includes port 80 in internal uri
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.x
Other Windows
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-08 19:27 UTC by Jeff Shanab
Modified: 2018-11-03 11:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeff Shanab 2017-07-08 19:27:05 UTC
I am having trouble using the rtspsrc for rtsp-over-http that I am starting to think is a bug. Setting protocols and/or setting rtsph does not open a socket to port 80. I am forced to actually put ":80" in the uri. When I do it ends up in the uri posted and the device does not respond. This is contrary to the standard, the device should not see the port 80 in it's url. Multiple devices tested using live555 and curl without issue. 

Tested with gst-launch on gstreamer 1.12 on windows x64 but primary usage is from c++ program.

Is this latest?, I am finding terribly outdated documentation and broken links on https://gstreamer.freedesktop.org/
Comment 1 Sebastian Dröge (slomo) 2017-07-10 06:44:35 UTC
Where exactly do you find broken/outdated documentation on the website?
The latest release is indeed 1.12.1 at this point.


It probably makes sense to use port 80 for rtsph by default, but this would break backwards compatibility with any applications that expect it to work like now. Not sure what to do about this here.
Comment 2 Jeff Shanab 2017-07-10 12:00:47 UTC
Allow me to clarify. 
According to the documentation on tunneling, the tunneling port is what you connect to but the port should NOT end up inside the rtsp headers. I have verified with other libraries using wireshark that indeed the rtsp headers remain un-udultrated.

rtsph seems to actually do nothing. it connects to port 554 
rtsph + protocol also seems to do nothing unless a port is specified. This seems odd but is workable. The problem is the rtsp headers are being messed up. 

rtspsh is not working correctly and I think the same may be true.

As for broken/outdated. I need to retract the outdated, I was getting property not supported when I was just spelling it wrong. However the links inside the pages, like 
https://gstreamer.freedesktop.org/usr/share/gtk-doc/html/gstreamer-1.0gstreamer-GstUriHandler.html#GstURIHandler-struct yield "Not Found". Just an annoyance really, I can google for them separately
Comment 3 Jeff Shanab 2017-07-18 20:18:12 UTC
Is this tied to 661530 and/or 763313 ?
Comment 4 Sebastian Dröge (slomo) 2017-11-01 11:28:08 UTC
Looks unrelated to those
Comment 5 GStreamer system administrator 2018-11-03 11:57:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/365.