[MPlayer-users] Playing m3u8 playlist with additional token parameters
Reimar.Doeffinger at gmx.de
Mon Apr 15 08:52:22 CEST 2013
On Fri, Apr 12, 2013 at 12:28:18AM -0400, Reza Rizvi wrote:
> I am trying to TEST a Live HLS stream (m3u8 playlist) using MPlayer on
> Linux. Here is the command I'm using to test the stream:
> mplayer -user-agent 'Apple-iPhone3C1/801.293' -noconsolecontrols -nocache
> -nolirc -nomouseinput -identify -vo null -ao null -frames 0 -v -playlist
> You will notice the "wmsAuthSign" and then a token, this is because the
> streamer is using the WMSAuth plugin for Wowza (http://www.wmsauth.org).
> The streamer is our partner so we have a valid token and I am able to play
> the streams fine using VLC and other methods using a valid token.
> The problem is MPlayer is not allowing this token in the command line.
> Here is the output that I'm seeing:
> Connecting to server streamer37.eboundservices.com[184.108.40.206]: 80...
> --- HTTP DEBUG HEADER --- START ---
> protocol: [HTTP/1.0]
> http minor version: 
> uri: [(null)]
> method: [(null)]
> status code: 
> reason phrase: [Forbidden]
> body size: 
> 0 - Server: FlashCom/3.5.7
> 1 - Content-Length: 0
> --- HTTP DEBUG HEADER --- END ---
> Server returned 403: Forbidden
> No stream found to handle url
> Error while opening playlist file
> Operation now in progress
> Error parsing option on the command line: -playlist
> Notice the "403 forbidden" code, this occurs when the WMSAuth model is not
> accepting the token. I'm assuming MPlayer is not treating this URL as a
> valid one for HLS due to the extra token parameters. Is there any way to
> make this work? We are trying to build a testing script that will evaluate
> if the streams are working periodically and it works great for
> "non-protected" streams but we're having trouble with this WMSAuth model.
First, HLS is not a playlist format, if you try to play it as playlist
it's not going to work well.
More proper support is available by playing via FFmpeg (prepend
ffmpeg:// to the URL).
The next thing is that the URL in either way will just be passed on
as-is, so it should be working just fine - for fetching the playlist.
However if you always return the same playlist and expect that parameter
to also be passed to the main file URLs or that MPlayer preserves
cookies the server tries to set that isn't going to work, you'd have
to return an individual playlist item that contains the proper
wmsAuthSign - however I don't think that scheme can work since it relies
on the request being made immediately after receiving the URL from the
server, so it can't really work for HLS if you want to protect more
than the playlist itself.
Either way you can use programs like wireshark or tcpdump to check what
requests MPlayer makes and if they are what you expect.
Interestingly none of the examples for this scheme use HLS, so I am not sure anyone
ever thought about how to use it there...
More information about the MPlayer-users