Seems like something regressed because I cannot play any live stream now. Neither ManualTests/video-rtsp.html nor any live content from the web works. The former just don't show anything, on the web I tried the stream at http://demo.smart-streaming.com/fms/demo/mobile.html for example and it shows an error: code: 101 domain: WebKitPolicyError Descreption: URL cannot be shown URL: http://demo.smart-streaming.com/fms/demo/mobile.html
Related: https://bugzilla.gnome.org/show_bug.cgi?id=701798 (works with GStreamer 1.0 but completely fails with git master)
(In reply to comment #0) > Seems like something regressed because I cannot play any live stream now. Neither ManualTests/video-rtsp.html nor any live content from the web works. The former just don't show anything, on the web I tried the stream at http://demo.smart-streaming.com/fms/demo/mobile.html for example and it shows an error: > > code: 101 > domain: WebKitPolicyError > Descreption: URL cannot be shown > URL: http://demo.smart-streaming.com/fms/demo/mobile.html We have 2 cases here: 1) direct rtsp link 2) rtsp link embedded on <video> For 1), all major browsers I tested (chrome/ff on linux, safari on osx) will open a "Launch Application" dialog asking to open link with an external app. For 2), we have a real issue where no video is being loaded, I am working on a fix. The question is what should we do for 1), options: 1.1) open *all* rtsp links with the mediaplayer and embed the video 1.2) show dialog asking how to open link as done in other browsers 1.3) do nothing, apps using webkitgtk+ should do it themselves Please let me know what you think.
My opinion on this is: I don't see a problem with WebKitGTK+ handling rtsp:// links itself, it's not that different from handling videos hosted on http conceptually (a user won't really know the difference, usually - it's an implementation detail) and we already play those directly. If we do not go that route, though, I think we should just do exactly what we are doing - fail with a policy error. Opening stuff on external programs should not be done by the web engine IMO, it's browser territory. So my opinion is we should either do 1.1 (I don't understand the '*all*', though - what's the alternative? playing a few? =)) or 1.3, but not 1.2.
(In reply to comment #3) > My opinion on this is: I don't see a problem with WebKitGTK+ handling rtsp:// links itself, it's not that different from handling videos hosted on http conceptually (a user won't really know the difference, usually - it's an implementation detail) and we already play those directly. > I agree here but I am not sure we want to go this route cause as I said all major browsers will request to open direct rtsp:// links in external apps. > If we do not go that route, though, I think we should just do exactly what we are doing - fail with a policy error. Opening stuff on external programs should not be done by the web engine IMO, it's browser territory. So my opinion is we should either do 1.1 (I don't understand the '*all*', though - what's the alternative? playing a few? =)) or 1.3, but not 1.2. Ignore the *all* :P, I have the same opinion here, either go with 1.3 (I believe we should) or go with 1.1 if we decide to be different from other browsers :D. As for the bug with rtsp links on <video>, I have some local fixes here and will push a patch later.
While working on the fix for rtsp links embedded on <video> I hit an issue adding 2 required gst-plugins-good patches to jhbuild. The problem is that we are using git repos + tags for gstreamer modules and jhbuild only supports adding patches to tarball repos it seems. So, any reason to use git repos + tags instead of release tarballs for jhbuild gstreamer modules? Should we bump version to git tag 1.0.10 for all gst modules except for gst-plugins-good, where we could use 1.0/HEAD (54a7fa - have the required patches applied)? To avoid having regressions I think we should change to use 1.0.8 tarballs + the required gst-plugins-good patches to fix rtsp timeout handling. What do you think?
Created attachment 210406 [details] Patch (In reply to comment #5) > While working on the fix for rtsp links embedded on <video> I hit an issue adding 2 required gst-plugins-good patches to jhbuild. > > The problem is that we are using git repos + tags for gstreamer modules and jhbuild only supports adding patches to tarball repos it seems. > > So, any reason to use git repos + tags instead of release tarballs for jhbuild gstreamer modules? Should we bump version to git tag 1.0.10 for all gst modules except for gst-plugins-good, where we could use 1.0/HEAD (54a7fa - have the required patches applied)? > > To avoid having regressions I think we should change to use 1.0.8 tarballs + the required gst-plugins-good patches to fix rtsp timeout handling. > > What do you think? Ok, the attached patch changes the gstreamer jhbuild modules to use tarballs and include the required patches to make rtsp streams work. The patch fix loading for ManualTests/video-rtsp.html and any link http://demo.smart-streaming.com/fms/demo/mobile.html if added as <video> src. The patch does not fix the "URL cannot be shown" issues when clicking on rtsp:// links directly though.
(In reply to comment #5) > While working on the fix for rtsp links embedded on <video> I hit an issue adding 2 required gst-plugins-good patches to jhbuild. > > The problem is that we are using git repos + tags for gstreamer modules and jhbuild only supports adding patches to tarball repos it seems. > > So, any reason to use git repos + tags instead of release tarballs for jhbuild gstreamer modules? Should we bump version to git tag 1.0.10 for all gst modules except for gst-plugins-good, where we could use 1.0/HEAD (54a7fa - have the required patches applied)? > > To avoid having regressions I think we should change to use 1.0.8 tarballs + the required gst-plugins-good patches to fix rtsp timeout handling. > > What do you think? The 1.0.8 tgz + patches approach is ok for me :)
Comment on attachment 210406 [details] Patch Clearing flags on attachment: 210406 Committed r155024: <http://trac.webkit.org/changeset/155024>
All reviewed patches have been landed. Closing bug.
Just FYI, the JHBuild moduleset is for testing, so it doesn't make sense to update it unless you are causing a new test to pass or adding a test.
(In reply to comment #10) > Just FYI, the JHBuild moduleset is for testing, so it doesn't make sense to update it unless you are causing a new test to pass or adding a test. The new patches on gst-plugins-good jhbuild are required to make ManualTests/video-rtsp.html work, not sure if that counts though as this is not an automated test.
(In reply to comment #11) > (In reply to comment #10) > > Just FYI, the JHBuild moduleset is for testing, so it doesn't make sense to update it unless you are causing a new test to pass or adding a test. > > The new patches on gst-plugins-good jhbuild are required to make ManualTests/video-rtsp.html work, not sure if that counts though as this is not an automated test. Great. Thanks.