How to Stream Live Video From Your iPhone to the JW Player
by Pablo Schklowsky on May 03, 2012
A few people have asked us if they can stream live video from their iPhones directly to the JW Player. If you're willing to install and configure a few applications, the answer is yes! This guide will provide step-by-step instructions on how to do it.
This tutorial is broken up into three steps:
Step 1: Set up Your Streaming Server
First, you'll need to download and install Wowza Media Server. They have a free 30-day trial available. Once you've installed Wowza, you'll need to configure your Wowza server, by editing files in the install directory. This is different for each platform, but you should be able to easily find where Wowza has installed its files.
- Find the applications folder in the Wowza installation folder. By default, there will be nothing there except for a folder called vod. Create a new folder for your live streaming application. We'll call it livu.
- Next, open up the conf folder and create another folder called livu. Then copy the Application.xml file from the conf folder to the livu folder.
- Now open up the Application.xml file. Find the <StreamType> property and change it from default to live.
- Still in Application.xml, find the <PublishMethod> property and change it from digest to none. This will turn off authentication for live stream publishing, so you should only do this for testing purposes.
- Back in the conf folder, open up the file called VHost.xml. You'll need to copy and paste the entire <HostPort> section, so that we can set up the port for our live stream ingestion (RTSP). In the new <HostPort>, edit the <Port> property to read 554.
Note: On Mac OS X, you'll need to set this value to a number higher than 1024. This is because ports below 1024 must be opened by processes with admin privileges. For example, to avoid trouble, set the <Port> value to 5544. - Now, simply start up your Wowza Media Server. If this is your first time running Wowza, you'll be prompted to enter in your trial license number. When it's started up, make sure your RTSP port (554 or 5544) was successfully enabled.
Step 2: Set up Your iPhone to Stream to Wowza
Now that you've got your streaming server set up, it's time to set up your iPhone to stream live video. We're going to use a $2.99 app called Livu, which is specifically designed to work with Wowza Media Server. Grab it by searching for "Livu" in iTunes, or by clicking here. Once you've downloaded the app, here's how to configure it:
- Open up the configuration menu, and in the Host field, enter the IP address for the computer hosting your Wowza Media Server instance.
- Under App, enter /livu/iphone. If you named your live streaming application something different in your Wowza setup, use that name here instead of livu.
- Under Port, enter the port your configured for RTSP ingestion in step 6 of the Wowza setup.
- If you disabled authentication in step 4, you can leave the User Name and Password fields blank.
- Once everything's configured, press the Save button.
- The Livu app should now activate your iPhone's camera. Click the icon in the top left to start streaming.
- If you've configured everything properly, a message will display saying "Stream Started." You're now broadcasting!
Step 3: Set up the JW Player to Play the Stream
If you've made it this far, the hard part is over. Now all that's left is to configure the JW Player to play your live stream. Here's the embed code you'll need to set up your player:
<div id="player"></div>
<script type="text/javascript">
jwplayer('player').setup({
streamer: "rtmp://192.168.0.160/livu", // Replace this with your own IP address
file: "iphone"
});
</script>
That's all there is to it. If you've set everything up correctly, the player will display the live video stream from your iPhone!
The State of HTML5 Video Report - JavaScript, Market Share, Fullscreen, and More...
by Jeroen Wijering on April 19, 2012
In January 2012, we announced the launch of our online resource, The State of HTML5 Video Report. Since its launch, we have had a tremendous response from our community. The page itself has been tweeted over 3,000 times, received 30,000 visits the day of its launch, and is still actively circulating the digital sphere.
Three months after its initial launch, we have updated the report with some very interesting findings. First, you will find a new JavaScript section, dedicated to video scripting using the video tag. Common use cases for this are the rendering of custom controls (like JW Player does) or page interaction with the video timeline (like Popcorn.js does). Second, you will find all existing tests updated with results from the latest browsers and mobile platforms. We highlight some interesting findings below.
Market Share
Compared with our statistics from last quarter, we already see shifts in market share. By market share, we mean the portion of the online market that is controlled by a particular browser / device:
IE 6/7/8 are declining quickly; their market share has gone from approximately 28% to 22% in the last few months. IE9, however, is growing (up to 11% market share from 9%). Chrome & Firefox are growing as well. Both have surpassed the share of IE 6/7/8.
Additionally, Android now has surpassed Opera. In terms of the mobile market, iOS still controls roughly 2x (4%) more than the other platforms, due to its dominance over the tablet market & recent success with the iPhone 4S. Other mobile platforms are virtually nonexistent.
Android 4.0
While Android 4.0 (Ice Cream Sandwich) was released last year, not every device-maker has updated their devices to the latest operating system. Still, some devices (like the Galaxy S2) now run ICS, so we have included it in our test results. Unfortunately, we found Android 4.0 to exist as a mixed bag of new features and new bugs. Some of the more interesting findings were:
- Support for WebM video decoding. It is in software though, so larger or longer videos do not play.
- Support for Apple HLS streaming. Unfortunately, quality switching has not yet been implemented.
- The video tag controls are still buggy. It is still difficult to start a video in HTML5.
- The scripting API is still a bit buggy - no metadata, no errors & no buffering. API for playback and seeking have improved though.
- Videos play inline on mobile phones, which creates an awkward UX. A fullscreen button is available, but it is as equally hard to click as the play button (e.g. they are both tiny).
Fullscreen API
There have been several updates on the state of Fullscreen playback in HTML5, which is pretty exciting for online video. While Chrome & Safari already supported the Fullscreen API, Firefox recently introduced support for it too (view our test page here). Thus, between these three browsers, the majority of the browser market supports fullscreen playback in HTML5. Opera is actively working on fullscreen support; presumably IE10 will introduce beta support as well.
Other interesting developments that you should stay tuned for more information on include Firefox's drop in support for the fullscreen button, and the discussion around fullscreen support in mobile devices, which becomes more relevant now that Android 4.0 plays the video inline.
We hope you take a look at the most recent version of our published report, share with your community, and send us your feedback! Feel free to post your comments directly to this blogpost, or join the discussion on our Facebook page.
Encoding WebM Videos
by Jeroen Wijering on March 06, 2012
WebM is coming up on its second anniversary. Released by Google as a royalty-free alternative to MP4, the video format has slowly gained traction on the web. MP4 still rules by a wide margin, but WebM has dethroned Ogg as the other leading format for HTML5 video.
This post describes two tools for encoding WebM videos: a desktop client and a cloud service. Both are free, easy to set-up and painless to understand. Which one you choose depends upon your personal preference - or the restrictions your company's IT department imposes.
Desktop Encoding
For desktop encoding, Firefogg is the best option. It is not a standalone tool, but an addon for the Firefox web browser. If you have Firefox installed, go to Tools » Addons to search for and install Firefogg. If you don't have Firefox, get it here.
With Firefogg installed, go to Tools » Make Web Video to start an encode. Now select your original video, select your output preset (360p is a good one) and click encode. Firefogg starts crunching and minutes later your WebM video will be done.
Select Advanced Options in step 2 to customize the video Size and the audio/video Quality. The sweet spot for video quality seems to be 7 (smallest file without artifacts). The sweet spot for audio is 3 (112 kbps). Be sure not to change any of the other options, unless you know what you're doing!
That is it on the desktop side - short and simple. Firefogg may not have the best looks, but it gets the job done. If you're looking for something more professional, check out Sorenson Squeeze. It has many more options, but is also not free.
Cloud Encoding
Now let's go online. Our very own online video platform, Bits on the Run, is easy, free and capable of WebM encoding. Sign up for a Free Account and log-in to the dashboard. Go to Account » Settings » Templates and click Add new Template to create an encoding template. Set the format to WebM Video.
On the next page, set the Target width to 480 pixels and the audio/video quality to the good tradeoff option. This gets you the same results as the Firefogg settings above. Next, set the Automate option to Automatically apply, so your WebM video are automatically built every time you upload a new original. Save the template.
Now go to the Videos section to upload an original video. When the upload is complete, go to the Transcodes tab to see the encoding progress. Your WebM template is listed here. When the WebM transcode is done processing, you can click its yellow Publish icon to copy/paste its URL, or to download it to your computer.
Like Firefogg, Bits on the Run provides a basic encoding interface with only the essential controls. A dedicated transcoding service like Zencoder.com offers many more options, but is also much harder to use.
The End Result
If you're reading this post in Chrome, Firefox or Opera, the resulting WebM video can be seen below. It is embedded using this JW Player setup. The unavoidable MP4 version is encoded separately, so Internet Explorer and Safari users are not left out:
That is all for now! Much more info can be found on the WebM project site. In particular, this page has a wealth of information about encoding parameters. Visit their blog for news on hardware, software and ecosystem support.
HTML5 Takes the Lead on Android Devices
by Pablo Schklowsky on February 28, 2012
Even before Adobe's announcement back in November that it would cease supporting Flash on Android devices, it was becoming clear to us at LongTail Video that the JW Player would need to shift its focus on Android devices towards HTML5 mode. We took the first step with the release of the 5.9 player, which now embeds itself in HTML5 mode on all Android devices by default, since our testing has shown that Android is fully capable of playing HTML5 video. But there are several reasons why HTML5 should be the delivery mode of choice on Android, with or without Flash. This blog post will attempt to address a few of them.
Limited Future Support for Flash
This one should be obvious, so we'll get it out of the way. After the current generation of Android devices running Froyo (2.2), Gingerbread (2.3), Honeycomb (3.x) and Ice Cream Sandwich (4.0) are either phased out or upgraded to future Android versions, Flash will no longer be supported in the browser.
Video Player Behavior on Mobile Devices
It is difficult to put forth a general rule for how video players should behave on mobile platforms. In fact, the term "mobile" is itself too general in this context, since viewing a web page containing video is a very different experience depending on whether you are viewing on a smartphone with limited screen real estate, versus watching on a tablet with more room for your fingers to interact with the content.
If you load the JW Player on an Android smartphone in Flash mode, you will get the same version of the player you would have gotten had you loaded it on a desktop browser. However, everything will be scaled to the size of your phone's screen, including all of the button controls. Not only would the buttons be hard to press, but they wouldn't really make sense in the context of watching video on a phone. Conversely, the player's HTML5 mode relies on the phone's own built-in video controls, which are optimized for the screen size. Additionally, HTML5 video will always play in full-screen mode on Android smartphones, which is a much better experience.
Viewing video in a browser on a tablet isn't as cut-and-dry of an issue. The screen is larger, so it is possible to have a usable video playing inside of the page content. This can be done in both Flash and HTML5 modes, so the decision of which to use comes down to performance (despite its reputation, Flash doesn't perform that poorly on most Android devices when it comes to video) and usability (the built-in HTML5 controls are optimized for touchscreens, while the Flash controls would need to be modified to work well on touch devices).
Lastly, we feel that it is important to provide a consistent experience across all mobile devices, not just Android devices. Switching to HTML5 playback for Android means that users on both Android and iOS devices will see the same things:
- Fullscreen-only playback (on phones)
- No overlays on top of the video player while a video is playing
- Built-in touch screen controls
Flash Embedding on Mobile Browsers
One issue we've noticed with Flash for Android is that it "steals" interaction events from the browser. For example, if you're scrolling down a page using the one-finger swipe gesture, and your finger happens to brush over a Flash element on the page, Flash will interpret this as a mouse click. In the case of the JW Player, the player will begin to play, when what you actually wanted to do was scroll down the page. Using native HTML5 elements eliminates this sort of behavior, since those elements distinguish between different types of gestures.
HTTP Live Streaming (HLS)
Beginning with Ice Cream Sandwich, Android devices will support HTTP Live Streaming (HLS), which has become the de facto standard for streaming video over HTTP. This is the same format which is used to stream video content to iOS devices. Unfortunately, HLS is not supported natively in the Flash player, making this another reason to favor HTML5 over Flash on Android. For an explanation of what HLS is and why it's important, check out our blog post on the subject.
Android Support in the JW Player Going Forward
For all of the reasons described above, we feel that it is necessary to focus our Android development efforts on HTML5 and not Flash. Flash mode will still be used as a failover on Android devices which support it; for example, if your player configuration specifies an RTMP stream (which can't be played in HTML5 mode), the Flash player will still be used. And if you disagree with our decision, you can still specify Flash as your primary renderer by setting the modes block in your player configuration. But we think you'll find that for Android, HTML5 is the best way to go.
HTML5 Video Ads: Coming To a Mobile Device Near You
by Pablo Schklowsky on February 21, 2012
As HTML5 grows its share of the online video market, web video publishers are beginning to look for ways to monetize videos being played outside of the traditional Flash advertising methods. But when someone watches a video in HTML5 mode, what should that experience be like? What's possible, given the current state of the tech?
HTML5: Desktop vs. Mobile
Before we begin talking about the challenges that face HTML5 video ads, it's valuable to acknowledge that video in HTML5 can behave very differently on the desktop compared to the same HTML code running on mobile devices. Here are some of the primary differences:
| HTML5 Desktop | HTML5 Smartphone | HTML5 Tablet | |
|---|---|---|---|
| Clickable Overlays | Yes | No | Depends* |
| Clickable Video | Yes | No | Depends* |
| Companion Ads | Yes | Not visible | Yes |
| Fullscreen mode | Optional | Always | Optional |
| Customizable controls | Yes | No | Yes |
| Available Bandwidth (probable) | LAN/WAN | 3G/4G/WAN | 3G/4G/WAN |
* Platform-specific
As you can see from the table above, some concepts that advertisers take for granted, such as video ads which cause a web page to be displayed when clicked, are not possible on smartphones. For example, on most mobile devices, once an HTML5 video begins playing, whether it's an ad or not, the phone will enter fullscreen video playback mode. In this mode, the user has full control over the playing video, including the ability to seek to the end of it.
Technical Challenges
As the major ad networks are beginning to offer support for HTML5 video ads, they face several important challenges.
Video Codec Incompatibility (WebM vs. MP4)
One issue which HTML5 video publishers are already familiar with is that to support all platforms, video must be encoded into multiple formats — WebM (or Ogg Theora) for Firefox, and H.264 for everything else. Second, someone (whether the browser, ad network, video player, or publisher) will need to select the appropriate format and display it to the user. This can be difficult to implement in an ad scenario, especially if ad networks don't account for the user's browser when generating an ad response.
Crossdomain Issues
An additional technical concern is that loading external assets (a VAST XML response from an ad server, for example) brings with it certain restrictions in JavaScript. These restrictions need to be worked around on the server hosting those assets.
<Video> Tag Access
Depending on the implementation, most ad networks require direct access to the player's <video> tag in order to play an ad in HTML5. This makes sense, considering that in iOS, each distinct <video> tag placed on a page needs to be clicked by the user in order for the video to be played. If the ad were to be played in a new <video> tag which was placed on top of the player, the user would need to click "play" twice - once for the ad and another time to watch the main video. This presents some interesting problems. While the ad is playing, the player needs to treat the events flowing from the <video> tag differently than if the main video were playing. After the ad has played, the video tag needs to be restored to its original state (the video playing, its position, etc).
Industry Roundup
Considering the relative newness of HTML5 video (and the challenges listed above), it's unsurprising that not many video ad networks have implemented full HTML5 support yet. That being said, there are a few ad networks who have made some progress on this front:
- Google recently released HTML5 support in their Interactive Media Ads (IMA) product. This implementation allows publishers to set up VAST ads, with certain limitations based on device compatibility. The JW Player's Google IMA Plugin includes beta support for HTML5 mode.
- YuMe has been steadily improving their HTML5 support, which is now supported in the JW Player's HTML5 mode via the YuMe plugin.
- Most other video ad networks (Tremor, SpotXchange, BrightRoll, and others) have either announced, or are currently implementing support for mobile devices, which will mean HTML5-compatible ad media.
Future Considerations
As in Flash, as more publishers attempt to handle more sophisticated scenarios, new techniques must be devised to handle them. Dynamic bitrate switching, for example, allows publishers make on-the-fly optimizations for video ads based on screen resolution and available bandwidth. Apple HLS (HTTP Live Streaming) is on its way to becoming the standard streaming format on mobile devices — with competition coming in the form of MPEG DASH, which was ratified as an ISO standard last week. Both HLS and DASH are based around the idea of a manifest file, which keeps track of smaller chunks of video that can be stitched together into a single seamless video. To insert an ad into this stream can be as simple as adding the ad chunks inside of the manifest file at the appropriate times, a technique known as dynamic ad insertion. A more general optmization we'll be moving towards is ad delivery which is optimized for variable-bandwidth environments, as many mobile users are viewing content over slower wireless networks.
In short, we're still a long way from having a turnkey video advertising solution for all HTML5 viewers, but we're closer than ever before to achieving that goal.
- 1 of 14
- ››