Update of jwplayer to Support HTML5

[porkcharsui]

I stumbled across this thread looking for other people investigating HTML5 player support in Subsonic. I've begun a fork called "Supersonic" that automatically tracks Subsonic's SVN releases on github "upstream" branch but with unique code commits applied. I failed to get any of Sindre's attention in 2010 about collaborative code development and contributions (viewtopic.php?t=3521) so I went ahead with the project.

Please feel free to fork "Supersonic" and send me code via pull requests. Thanks!

[Richard Fearnhead]

Thanks Citlali,

I'm going to have a look at testing out and or modifying your code to get this to work, when I can find some time.

I do have some video files I can test, so I will let you know the results of those tests in due course.

Just a quick update.

With Citlali's code the browser just returns the Get Flash player link from the code at the bottom of videoPlayer.jsp

Code: Select all

<div id="placeholder1"><a href="http://www.adobe.com/go/getflashplayer" target="_blank"><fmt:message key="playlist.getflash"/></a></div>

[Richard Fearnhead]

I can't get it to work I'm too much of a coding noob

I guess I'll just have to wait for one of the following to happen:

a) Adobe give in and start supporting ARM6 processors (Not going to happen)
or
b) Someone else works this out and it gets a HTML5 player incorporated into Subsonic
or
c) I buy a new phone that supports flash and doesn't melt in my hand (I'm too tight for that and the one I bought didn't come cheap)
or
d) I root Andriod and install some dodgy Chinese hacked version of flash (Why the hell should I risk my security because of deliberate hardware restrictions in flash??)

I guess this is what happens when proprietary formats like flash become a de-facto standard, Adobe get to choose the devices that format can play on...

Sucks big time...

[Citlali]

I can't get it to work I'm too much of a coding noob

I guess I'll just have to wait for one of the following to happen:

a) Adobe give in and start supporting ARM6 processors (Not going to happen)
or
b) Someone else works this out and it gets a HTML5 player incorporated into Subsonic
or
c) I buy a new phone that supports flash and doesn't melt in my hand (I'm too tight for that and the one I bought didn't come cheap)
or
d) I root Andriod and install some dodgy Chinese hacked version of flash (Why the hell should I risk my security because of deliberate hardware restrictions in flash??)

I guess this is what happens when proprietary formats like flash become a de-facto standard, Adobe get to choose the devices that format can play on...

Sucks big time...

It sounds like you don't have jwplayer.js in the scripts folder. Did you follow the instructions in my earlier post to download latest version of jwplayer? Also I guess the latest version is now 5.9.

Steps taken:

1. Downloaded the latest jwplayer from here:
2. Add jwplayer.js to /script (same place swfobject.js is.)
3. Add the new player.swf to /flash (I renamed it to jw-player-5.8.swf)

[ddubyat]

Well I found this topic interesting so I took a dive. Turn's out for now that html5 video is a time waste..... for now

The reason I would want to drive toward html5 is to gain better compatibility with devices and not need the flash player. Seemingly simple, but practically hard.

With the html5 video tag you get three basic containers, mp4 using h264, ogg vorbis, and google's webm. Now where to start....

h264 mp4 is the ideal container and encoding since it encodes very fast, can be hardware enhanced, and is compatible with even apple devices like the ipad. Now the bad news.... the mp4 format requires a MOOV index in the file which provides the segmentation data that allows you to seek. This file typically located at the end of the mp4 container prevents this format from streaming mostly. I say mostly because it can be moved to the front of the container, but this would require that the file already be in mp4 format with post processing done to move the MOOV bits. Bummer... a no go for anyone that wants to transcode their media on the fly.

What about webm? This is where I actually had some success and was able to get my content to render in chrome in a html5 video tag within subsonic. Initially very existing new, it turned out to be somewhat disappointing due to the poor performance in the libvpx video ffmpeg encoder. My setup was to basically use subsonic to invoke ffmpeg to convert to web format and output to the stream.m streamer available here: http://code.google.com/p/stream-m/. Then using a html5 video tag in videoPalyer jsp i could connect to the output. On my quad core intel q6700 server, 720p content failed to downsample and resize to 100k stream efficiently. The encoding process was just to slow. For comparison on this machine using a build of ffmpeg from 3-7-12 h264 seemed nearly 5-8x as fast. I also noticed that while this feed played fine in the latest version of chrome, ff had troubles, and for the love of God IE I DO NOT WANT TO DOWNLOAD THE FILE.

This leaves ogv. The first thing i did here was to test the encoding performance. It did seem much better than webm, but most of the reading I have done seems to purvey that this format although as accepted as webm has been trumped by it. I'm sure stream.m could be adapted to stream this format, but why jump on a sinking ship when compatibility is involved.

Seeming pretty frustrated with html5 video, there are still options. JWPlayer may or may not be a part of this future (the benefit is that is can downgrade to flash easily), but video.js looks nice as well. What we are left with is HTTP live streaming of the files and RTP streaming. These options provide true streaming of the files and not just progressive downloading and we have traditionally seen in the flv streaming we have become accustomed to. There are some commercial RTP streaming options, but I will look at some POC java code for getting the job done.

Overall, html5 video is not right for subsonic now, but perhaps with better adopted codecs or real streaming of videos there may be hope.

Thanks,
ddubaya

[porkcharsui]

Nice work ddubayat! The analysis of options you present are the same ones that confounded me when I began looking attempting to improve the video playback functionality. The Android client currently uses JWPlayer w/ Flash for video playback. Indirectly, updates to this player for "HTML5 support" could be seen as an improvement in overall video playback functionality on Android devices due to Adobe/Google decision to not support Flash in Chrome for Android.

jwplayer supports HTTP Live streaming, so this issue is definitely best phrased as a desire for better video playback functionality through improvements in the back end server software providing at least:

• Adaptive stream to handle low bandwidth situations without pausing during playback
• Seeking within files

[GJ51]

I'd rather just see VLC used as an embedded player in SS. VLC plays everything you throw at it and it would eliminate the need for transcoding on the server.

I agree that HTML5 is probably the long term solution, but as long as eveyone has diverse collections of video in different formats it would be a whole lot easier to just use VLC embedded into the webpage.

[porkcharsui]

it would be a whole lot easier to just use VLC embedded into the webpage.

I beg to differ, as VLC embedded into the browser (via browser plugin ???) and delivering the native file solves no problems, creating many more issues in it's wake. Transcoding will always be a need in Subsonic since there are always many different consumers of content at different network types. Maybe this is what you're looking for: viewtopic.php?t=5043

[ddubyat]

Nice work ddubayat! The analysis of options you present are the same ones that confounded me when I began looking attempting to improve the video playback functionality. The Android client currently uses JWPlayer w/ Flash for video playback. Indirectly, updates to this player for "HTML5 support" could be seen as an improvement in overall video playback functionality on Android devices due to Adobe/Google decision to not support Flash in Chrome for Android.

jwplayer supports HTTP Live streaming, so this issue is definitely best phrased as a desire for better video playback functionality through improvements in the back end server software providing at least:

• Adaptive stream to handle low bandwidth situations without pausing during playback
• Seeking within files

Interesting. Ideally subsonic could be changed to encode h264 easily and pipe the output to a segmenter to support http live streaming. This could be rendered in an html5 video tag or with jwplayer. Either way, it would be rather simple to override the control bar and add a few specific options:
1. A bitrate adjustment menu for clients not supporting DASH (similar to youtube's resolution adjustment)
2. An index slider that mocks the progress bar and allows you to skip to pre-designated adjustments similar to the time offset dropdown in subsonic today.

This would give us somewhat efficient encoding, real streaming, mock abr, mock seeking, and no flash player if unsupported.

[porkcharsui]

I have opened an issue on Supersonic (subsonic fork) to track my ideas / code commits for the implementation of a VLC backend. I contacted another github developer who has implemented a VLC remote control interface in Subsonic that might already have implemented the UI -> VLC remote control implementation to allow a live stream approach to conserve disk space by just changing the engine's current playback position.

[nymusicman]

Sarcasm Alert: Since the VLC Browser plugin works so well. I don't think that is a good suggestion at all. Opening the file in VLC through the external player option on a desktop works just fine for this. I think the biggest problem right now is Android. Adobe no longer supports them, phones and tablets are becoming entertainment devices and we have no way of getting our movies to play.

I think an Android external player option would fix the immediate need and then you can start looking at the long term solutions. I would think this is a quick, easy change to the android app to throw an option into settings to use an external player and not transcode at all (or transcode to mp4 to turn down the bitrate a bit for data). Just about every android player would support an mp4 file and even Google's native movie app in ICS and JB supports streaming.

[porkcharsui]

The goal is not to use a plugin, so the current Flash JW Player or a future VLC Browser plugin does not fit the model. HTML5 + mp4 support is the base requirement, although this does not address older devices that might still be able to support mp4 streaming via external applications.

VLC would only act on the back end as one of the transcode engines. A simple proof of concept is important, just need a time machine to find the time as of late.

[Loxeno]

Hi there,

I'm asking something maybe useless/noob, but why don't transcode media to mp4 and use new JWPlayer 6?
http://www.longtailvideo.com/support/jw ... at-support


If we integrate the jwplayer.html5.js into subsonic and add a transcode rule to transcode into mp4 container, maybe Subsonic will be able to support HTML5?

What about Sindre wishes? Want he to support HTML5?



Thank you blowing my mind, I really love Subsonic, hate flash, and want to get Subsonic works with HTML5.