24

I have video which is delivered over HLS. Now I'd like to test in JavaScript if the device actually can play HLS video in HTML5.

Usually in Javascript I did something like document.createElement('video').canPlayType('video/mp4') However I can't figure out which 'type' is the right one for HLS.

Apple's Safari HTML5 Audio and Video Guide seems to suggest "vnd.apple.mpegURL" ("Listing 1-7 Falling back to a plug-in for IE")

<video controls>
    <source src="HttpLiveStream.m3u8" type="vnd.apple.mpegURL">
    <source src="ProgressiveDowload.mp4" type="video/mp4">
....

but canPlayType("vnd.apple.mpegURL") return an empty string even on iOS devices which can play actual HLS streams perfectly fine.

Is there any way to check for playback capabilities without 'external knowledge' (e.g. "check for iOS user agent and assume it can play hls")?

I know I can specify multiple sources in a element and the browser will use the first playable source. However in my case I need feed a single URL to JW Player which I can't modify. So somehow I need to find the "best playable URL" from a set of video encodings. (An open source JS library which handles source selection would be a nice workaround though.)

Felix Schwarz
  • 2,938
  • 4
  • 28
  • 41
  • I'm pretty sure no such test exists across browsers. Maybe fixing JW Player is the "right" way to go about this. – vipw Sep 17 '12 at 11:57
  • Agreed, ideally JW Player (actually all Video players for that matter) would provide "rich" playlist elements with a notion of different quality levels, formats and so on. However JW Player does not and for the project I can't assume everyone is using a patched JW Player. – Felix Schwarz Sep 20 '12 at 13:20
  • @felix, I'm just now learning video streaming, does Schmod's answer still appear to be correct? – tim peterson Mar 26 '13 at 23:37

1 Answers1

26

I haven't tested this across the board, but it looks like you should be testing for the full HLS mimetype application/vnd.apple.mpegURL instead of just just vnd.apple.mpegURL.

application/x-mpegURL and audio/mpegurl are also suitable mimetypes for the HLS m3u8 file. audio/x-mpegurl is also listed as an acceptable mimetype according to Apple, but it doesn't appear to be mentioned in the actual HLS draft spec.

In Safari on iOS and OS X,

document.createElement('video').canPlayType('application/vnd.apple.mpegURL')

returns maybe. I'm not sure if there are any other browsers that support HLS -- Android doesn't seem to like this syntax (despite some assertions I've seen to the contrary), and I believe that it may be due to the fact that the actual video playback is delegated to an external application, rather than the browser itself.

References:

  1. http://developer.apple.com/library/ios/#technotes/tn2235/_index.html
  2. http://www.longtailvideo.com/html5/hls
  3. https://datatracker.ietf.org/doc/html/draft-pantos-http-live-streaming-03
  4. http://developer.apple.com/library/safari/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/Using_HTML5_Audio_Video.pdf
Community
  • 1
  • 1
schmod
  • 777
  • 9
  • 19
  • I'm just now learning video streaming, does your answer still appear to be correct? – tim peterson Mar 26 '13 at 23:36
  • Everything here should still be correct, and the HLS mimetype seems unlikely to change anytime soon. Longtail revise their "State of HTML5 Video" report every few months, and are the best place to go for up-to-date information on the (painfully slow) adoption of the various HTML5 Video APIs. – schmod Jun 18 '13 at 14:58
  • This works on most devices - will fail on Samsung Galaxy S5 native browser - you will need a workaround for there. Overall Samsung Galacy inline HLS stream is buggy. – easwee May 05 '15 at 13:13
  • After some quick tests, this seems buggy on FireTV Silk browser also. – Jonny Oct 21 '19 at 01:56