Resolution switching between 'n' number of streams#233
Conversation
…y tech and then by resolution
…at people can choose their resolution preferences by order.
…est available resolution from those provided
Please enter the commit message for your changes. Lines starting
… the last playback position
…on whether the menu item's source is the current source
…ering new selections in localStorage
… are present. It will always play the first source even if you set this.el.src. We must remove the source elements before trying to change the src attribtue programatically.
… for resolution changes. no more timeout needed!
… to check for presence of preferred resolution value in addition to localstorage itself.
|
Very cool, thanks Dan. I haven't had a chance to dig into this yet but hope to soon. Cheers! |
|
Great! Let me know if you encounter anything. From my testing it seems the Flash component inherited the feature fine as well. |
|
Would be great to see it in upstream. Anything I can help with to see this PR merged? |
|
We've discovered an issue with this code. Basically the HTML5 spec doesn't provide a way to stop a video from buffering once it's started. In fact in Chrome and other browsers the video continues to download even after destroying the video entirely and removing it from the DOM. This means that each time you switch resolutions you initiate a new concurrent download. Ouch. There's a hacky workaround: But for me it breaks at least IE9. Quite a bummer. I'll be looking at it further. |
|
With regards to aborting the buffering - we've found this varies from CDN/host to CDN/host. One of the customers serving from an Ubuntu/Apache host suffers from the concurrent downloads whereas one serving from S3 does not - the video aborts when the streams change. It's most likely something deep in the HTTP exchange. Your mileage may vary. |
|
I've also been looking into resolution switching (amongst other things) for the company I work for and it would be great if this or something similar could be integrated into the main project. One suggestion to add to the proposed implementation however: res and default are not standard html5 tags, but custom data tags are (eg. data-res, data-res-default). Could we use these instead? In our solution we have player.js expose all custom attributes to allow for greater flexibility later. |
|
Is this planned to get into master? |
|
@onyxrev Still working with Vidcaster? If so this would be great as a plugin. We're currently drawing the line of the core at features supported by the native video element (except also supporting them in flash) and everything else will be a plugin. PS. Sorry, it's taken so long to get to this. Things got crazy. |
|
Yes, looks as though we will probably plugin-ize this guy somehow. |
|
@onyxrev any news on the plugin for resolution switching? |
|
@xdmx yes, I've pluginized it in Vidcaster's private repo and it's looking pretty good but we're running into stability issues with VideoJS 4 at large on mobile platforms. I's been delayed a bit as the stability issues make testing resolutions against mobile impossible. |
|
I hope you'll figure out that issues and release it to the public, I'd love to use it in a small project I'm developing! |
|
@xdmx the plugin addresses both Flash and HTML5. I'll talk to Vidcaster to see if we can release the code to get the community involved sooner rather than later. |
|
That would be really awesome!!! ❤️ |
|
@xdmx Resolution switching should always be a plugin since (I'm assuming) it won't ever be added to the HTML5 video spec. That's our line for core features. Though I'm looking forward to this plugin myself. @onyxrev Make sure the mobile issues you're running into get reported if they're not yet. We are working through them, even if it's slowly. |
|
@heff @xdmx @kylegregory Vidcaster has open-sourced my work on the videojs resolutions plugin. It's available here: https://github.com/vidcaster/video-js-resolutions It's not perfect but it's pretty good. Please fork and improve! |
|
Nice! Bonus Points: Set up a quick demo page on codepen.io or jsbin showing this off. You could fork one of these and drop the plugin code into the js section. Ref #413 |
|
Yeah, it'd also be nice to have some test coverage. The plugin will ignore URLs that look the same, so we'll at least need streams with different endpoints. Guess I could add a garbage parameter or something. |
|
Yeah, that could work. Noticed the target IE was 10. What keeps this from being compatible with IE9? |
|
When we built the resolution switching fork of 3.2.2 we experienced issues switching streams on IE9 so Vidcaster dropped resolution switching support for it. It's possible 4.x will fare better but we haven't tried it. If I can get a demo page up we can give it a go. |
|
Cool, sounds good. |
I'm a freelance developer hired by Vidcaster to implement resolution switching ala YouTube in VideoJS. Here's my contribution:
Here's how to specify multiple streams:
<video id="vid1" class="video-js vjs-default-skin" controls preload="auto" width="640" height="264" poster="http://video-js.zencoder.com/oceans-clip.png" data-setup='{}'> <source src="http://video-js.zencoder.com/oceans-clip_hd.mp4" type='video/mp4' res="HD"> <source src="http://video-js.zencoder.com/oceans-clip_sd.mp4" type='video/mp4' res="SD" default="true"> <source src="http://video-js.zencoder.com/oceans-clip.webm" type='video/webm'> <source src="http://video-js.zencoder.com/oceans-clip.ogv" type='video/ogg'> <p>Video Playback Not Supported</p> </video>Or if you're passing in the sources programatically:
myPlayer.src([ { type: "video/mp4", src: "http://www.example.com/path/to/hd_video.mp4", res: "HD" }, { type: "video/mp4", src: "http://www.example.com/path/to/sd_video.mp4", res: "SD", default: true }, { type: "video/webm", src: "http://www.example.com/path/to/video.webm" }, { type: "video/ogg", src: "http://www.example.com/path/to/video.ogv" } ]);A limitation of the implementation is that only homogeneous video types are resolution switchable. So you can't specify a webm SD and an mp4 HD and expect the player to pick it up. That might be correctable, but it might involve changing player "technologies" mid-play ie. HTML5 -> Flash. Technically my implementation does restart the tech on resolution change, but I didn't want to mess with actually changing technologies for this rev.
Here's what it looks like:
http://i.imgur.com/IA5el.png
Any number of resolution streams are supported. The 'res' parameter is arbitrary and doubles as the label. Could be '720p', '360p', and '240p' if you wanted. it displays in the order specified in the HTML markup or the params array.
I'd be happy to write tests if Zencoder can provide alternate bitrate sources of the 'ocean' video for use in the testing suite.
Here's the result of my testing:
Chrome (Mac & Win): pass
Safari (Mac): pass
Firefox (Mac & Win): pass
Android: pass
IE9: pass
IE8: fail (tried with Flash) however the zencoder repo without my edits didn't work for me on IE8 either
These commits only address the HTML5 side of things, not the Flash side.
Sorry about the closed pull request. I was gonna rebase but I already pushed these to my master and didn't want to screw anything up.