We have a Wowza setup (4.0.1) configured with origin-edge live repeater:
wowz://originhost:1935/origin
With most stream names, this works fine, but if the broadcast stream name contains a space (or various other non-alphanumeric characters), then we get an error reported at the origin:
Invalid LiveMediaStream URL[wowz://originhost:1935/origin/Testing12/Test Test] : java.net.URISyntaxException: Illegal character in path at index 44: wowz://originhost:1935/origin/Testing12/Test Test|at java.net.URI$Parser.fail(URI.java:2829)|at java.net.URI$Parser.checkChars(URI.java:3002)|at java.net.URI$Parser.parseHierarchical(URI.java:3086)|at java.net.URI$Parser.parse(URI.java:3034)|at java.net.URI.(URI.java:595)|
We’re passing the URL encoded stream name to the repeater, but it looks like it’s decoding it before passing it on the the origin. If we double-encode the stream name (Test Test —> Test%20Test —> Test%2520Test), we can play it, but surely we shouldn’t need to?
In my tests, I was able to publish a stream “test test” (space between the two words) and playback using the url encoded version via the test players (i.e. test%20test) as expected. My suggestion would be to eliminate the use of spaces or setup a custom module to do so from published stream names.
If you don’t use the repeater functionality, it does work fine with spaces and other characters. Our problem is that we’re using the repeater (configured as in the original post), and that’s when we hit the issue.
We try to playback with using the URL encoded version (test%20test), but when the repeater forwards the request on to the origin, it has already decoded it to “test test”, which isn’t valid.
That would work fine if we had a small number of stream names we know in advance, and we could set up specific aliases for those stream names which have odd characters in them. However, that’s not the case for us, since our broadcasters can make up whatever stream name they like.
On the other hand, the module you suggest using includes the full source, so we could try to modify it to do the appropriate aliasing itself, automatically. We need to figure out how hard that will be to do first, though…
While I wouldn’t suggest keeping with spaces in the names of your streams, I just did a couple tests in origin/edge scenario in this manner. I used “test test” as the playback url within the test players and I was able to leverage the stream name alias module and define an alias map that accommodated the space between them (origin & edge).
aliasmap.play.txt
test test=test%20test
*=${Stream.Name}
This would resolve the stream with the space to the origin as expected. Give that a try.
You might look into the nameToAlias function and do your url encoding there as to automate this issue. One alternative idea would be to uniform all published stream names using a similar approach during publish (to remove spaces).