Creating/Editing StreamClip VOD in WS.WebTV (for Video on Demand Streaming playback)
support, ws.webtv, home, contents, clips, streamclip, create, edit
The difference between a Clip and a StreamClip VOD is that the StreamClip VOD stores absolute paths (URL) to video on demand files or streams. StreamClip VOD works in conjunction with the WebTV video player to allow the playback of videos from external servers, media servers or CDNs, through HTTP or RTMP protocols.
By this time, you should be familiar on how to create and edit a Clip. If this is not the case, please check the "Clips: Create/Edit" tutorial before continue reading.
In the next steps we will focus on the main characteristic of this kind of Clip: the Media Tab.
To create a StreamClip VOD...
Click on "New Clip..." button and select "StreamClip VOD".
The "Media" tab...
From this tab you will be able to enter the URL of the corresponding video files.
As you can see, there is a set of slots per each WebTV Quality and, depending on the "Target" of each Quality, you will see one or two slots (for Flash and/or HTML5).
NOTE: For more info about Qualities and Targets, check the "Configuration: Video" tutorial.
Why do you need independent URLs for Flash and HTML5?
This is beacuse the Flash video player can playback using RTMP or HTTP protocol; whereas the HTML5 video can only be played back using HTTP protocol.
Can I use the same URL for Flash and HTML5?
Only if it is a progressive/conventional URL (and the video format of the files is H.264 for the video track and AAC for the audio track) or (since WS.WebTV 2.1) if the URL is HLS (.m3u8). Example:
Using different URLS for Flash and HTML5
You can supply different URLs for Flash and HTML5. For example, you can provide a RTMP streaming URL to be used by the WS.WebTV Flash video player and a progressive or HLS URL (since WS.WebTV 2.1) to be used on the HTML5 video player. Example:
Regarding HLS support on WS.WebTV 2.1+
HLS is supported, natively, by many mobile browsers; however, this is not the case with desktop browsers. Since WS.WebTV version 2.1, HLS playback is supported through the hls.js library and should work on most modern HTML5 Browsers with MediaSource extensions. Note that since WS.WebTV 3.0.4, if the video player detects that the hls.js component can be used then it will be preferred over the native playback implementation.
NOTE: It is possible to provide, additionally, a Progressive URL for devices where the HLS playback is not possible. In order to provide both URLs (HLS and Progressive) separate them with 4 "slashes" (////) without any extra space. Example:
» CORS required!: All HLS resources (URL) must be delivered with CORS headers permitting GET requests. This is mandatory for playing back HLS on desktop browsers and Chromecast devices.
HLS Streaming playback is supported through the following (included) free third party plugins:
1. (Default) "Flashls" plugin by "mangui" (http://mangui.github.io/flashls/)
2. "OSMF HLS Plugin" by DENIVIP Media (http://blog.denivip.ru/index.php/2013/05/osmf-hls-plugin/)
It is possible to select the HLS plugin through a URL variable. Please check this socument for more info.
NOTE: HLS is not a native Flash streaming technology, because of this we always recommend to use RTMP instead of HLS. Additionally, since the plugins that enable HLS playback in Flash have been developed by third parties, we don't offer technical support for them.
Regarding HLS support on WS.WebTV 1.7.5 to 2.0
You can use HLS URLs but only in the "HTML5 - H.264" slot.
• Keep in mind that the user experience will not be as good as when using Progressive URLs, because of the high buffer time required to playback HLS.
• We recommend to, additionally, provide a Progressive URL for devices which do not support HLS. In order to provide both URLs (HLS and Progressive) separate them with 4 "slashes" (////) without any extra space. Example:
• CORS required!: All HLS resources (URL) must be delivered with CORS headers permitting GET requests. This is mandatory for playing back HLS on Chromecast and similar devices.
Can I enter the URLs for only one of the available Qualities?
Of course you can. If, for some reason, you just want to enter the URLs for a single quality, you can leave the other Qualities' fields blank.
If you are accessing files served from a CDN, use the playback URL they provided you. If you have any question, contact us.
A note about iOS, Android, etc...
On iOS (iPhone, iPad, iPod Touch), Android (without Flash), and other mobile platforms, the HTML5 video player will be used. Make sure to provide the HTTP URLs and your video files are encoded in te correct format (H.264 + AAC).
NOTE: For better mobile device compatibility, use H.264 baseline profile (level 3) - For example, this is required for correct iPhone/iPod Touch playback -.
Regarding Pseudo Streaming Playback
» On HTML5: HTML5 supports -natively- Pseudo Streaming playback for conventional, progressive, URLs.
» On Flash: Since WS.WebTV version 1.7.5+ Pseudo Streaming playback is supported, in the Flash video player, through the free third party plugin "osmf-pseudostreaming", developed by "mexxik" - Please note that the H264 Streaming Module for Apache ("mod_h264_streaming") is also required in the server that hosts the video files. Additionally, you will need to add the [ps] prefix to the video file URLs in the corresponding Flash slots.
MPEG-DASH (WS.WebTV 1.9+)
When DASH has been enabled in the WebTV, you will find an additional slot "HTML5 - DASH" for each quality. If you provide a DASH URL the HTML5 video player of the WebTV will try to use it as the first choice then, if the DASH URL fails for whatever reason, the "HTML5 - H.264" URL will be used as fallback.
Quality slots when DASH is enabled:
Multi-Bitrate URLs + Adaptive Streaming (WS.WebTV 1.9+)
Unlike a single-bitrate URL which references a single video file/stream; a multi-bitrate URL is the address to a manifest file which references several representations (qualities) of a video/stream. When you provide a multi-bitrate URL (and it can be used), the WebTV:
1. Will use it as first choice instead of the single-bitrate qualities. The single-bitrate URLs will be used only as fallback in case the multi-bitrate URL fails.
2. The qualities menu will be generated according to the qualities available in the manifest file.
3. By default, it will use adaptive streaming which means that the system will automatically (and dynamically) switch to the most appropriate quality according to the conditions of the Internet connection of the viewer, during video playback. Of course, the viewer will also be able to select (and "fix") a particular quality from the qualities menu.