It seems PlayReady can't play HLS on platforms other than iOS but no obvious proofs found.
It seems PlayReady can't play HLS on platforms other than iOS but no
obvious proofs found.
That is a wrong assumption.
PlayReady is DRM technology. HLS is streaming technology. These technologies work on different level of processing during video playback. DRM technology even doesn't know anything at all about used streaming technology (or content delivery in general).
HLS is adaptive streaming technology which allows you obtaining content from the server and dynamically change the quality based on device capabilities or network conditions. HLS work on the level of Mpeg2-TS or fragmented MP4 streams.
PlayReady is DRM technology protecting the content. It does not protect whole segments or fragments delivered by adaptive streaming. You first need to demux transport container (fMP4 or Mpeg2-TS) and get elementary stream of samples. Individual samples (or sub-samples) are protected by DRM.
There is clear separation between DRM and adaptive streaming technologies which allows mixing them. The only case when these technologies meet each other is adaptive streaming manifest where you may have description of protection header or key IDs which may be DRM specific.
Adaptive technologies are not bound to platform - you can write HLS player from scratch on any platform. The situation is not the same for DRM. You either work on platform where DRM technology is already present or you have access to porting kit and you go through process to port it to the platform and meet the robustness requirements (but usually only device manufacturers have resources to go through this path).
So can you use PlayReady and HLS on another platform? Definitely! But in most cases the response is more like: You can use HLS with PlayReady on all platforms where PlayReady port is already available for you.
I think you confusion comes from Microsoft providing iOS PlayReady Client SDK. It is ready to use player with PlayReady and HLS support. You don't need to port anything, you just pay license and use the player. You can still consume HLS delivered content protected with PlayReady for example in Windows 10 UWP application. You can also have JavaScript HLS implementation and use it with PlayReady in Internet Explorer or Edge browsers. You only need to write (or use existing) HLS component.
I'm quite sure that many Smart TV manufacturers also have ready to use HLS player with support for PlayReady.
PlayReady can be used on iOS, via an SDK like the official Microsoft PlayReady iOS SDK:
https://www.microsoft.com/playready/features/ClientOptions.aspx
Here is the supported streaming formats for that SDK at the time of writing:
iOS platform
Includes a basic reference media player to build a final app
Smooth Streaming (VoD/Live)
MPEG-DASH (ISOBFF, VoD/Live)
Key rotation and blackouts
Support for HLS on iOS (VoD/Live)
PlayReady ND-Receiver functionality on iOS clients
Related
A server is in the middle
And we want you to send live video to it
And on the other hand, watch it through the HTTPS like https://server/live.pm4
What protocols can be used for this purpose?
I used to do this experimentally with nodejs dgram and ffmpeg on the raw UDP and it worked fine !
but stability and security is an issue that must be observed !
Most live (or VOD) video, for services where quality is important and/or there are a large number or users, use Adaptive Bit Rate streaming protocols at this time.
The two leading ones are HLS and MPEG DASH.
As a very high level general rule, noting that there are exceptions:
Android, Chrome Browser, Edge Browser - use MPEG DASH
iOS, Safari browser - use HLS
The introduction of CMAF () has consolidated the two formats making life for service provider easier, and the media streams can be the same for both and just tine manifest of index files to the streams are specific to DASH and HLS. Unfortunately, encrypted stream support for CMAF is not yet rolled out across all consumer devices so many services cannot use it fully yet.
On the security side, nearly all services use DRM to encrypt content and control entitlements. The leading DRM's are Google Widevine, Apple FairPlay and Microsoft PlayReady. Again, these are generally platform specific, with the usual use being:
Android, Chrome browser - Widevine
Edge Browser, X-Box - PlayReady
iOS, Safari - FairPlay
I'm using the VideoJS player and have a CMAF video so I am using HLS and DASH. I'm also using all 3 types of DRM. Fairplay for hls, widevine and playready for dash.
My question is should I include both hls and dash sources in the player and let the player decide which one to play? Or do I detect the browser and only insert the correct url based on that? Also DRM is the same. Can I just add all DRM to the player? Or should I only add the one that applies?
The use of HLS vs DASH is typically dictated by the end device and client capabilities and rules.
iOS and Safari typically use HLS and FairPlay, Android, Firefox and Chrome use DASH and Widevine and Windows and Edge use DASH and PlayReady.
Note that Widevine and PlayReady can use the same DASH stream - CENC, Common Encryption standard, allows the same stream to include both Widevine and PlayReady DRM information.
At this time, Apple iOS devices must use HLS for content greater than 10 mins over a mobile network:
2.5.7 Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps HTTP Live stream.
(https://developer.apple.com/app-store/review/guidelines/)
For this reason streams served to Apple devices are usually HLS, while DASH is used for other devices.
CMAF greatly reduces the impact of this by allowing the same segmented media stream be used for both HLS and DASH, with just the 'index' or manifest files being specific to each protocol.
For encrypted content it is a bit more complicated. At this time, FairPlay uses a different AES encryption mode, AES CBC, than Widevine and PlayReady which use AES-CTR. This means you still need two copies of the media to serve encrypted content streams.
This is changing as Widevine and PlayReady now have announced support for AES-CBC as well as AES-CTR, but it will take some time for this to roll out to deployed devices.
I'm aware that developer-preview of Chromecast receiver does not fully support Smooth Streaming manifest URL (See Update#1).
I have tested content provided by Microsoft PlayReady(TM) Test Server - Smooth Streaming assets using sample receiver app provider in GitHub project.
Smooth Streaming Support
As expected, manifest file does not work (See Update#1). But I was able to play individual ismv file (but only low bitrates). When I use higher bitrate, the video container stays black.
PlayReady Support
When I tried to play PlayReady protected low bitrate ismv file, I was expecting some sort of call back MediaProtocolMessageStream.onKeyRequested(). But there did not happen. Here is my android CustomMediaProtocolMessageStream implementation.
So, does anybody know how PlayReady or Widevine supposed to work with Chromecast? I have seen Netflix invokes some binary shell command when app is loaded in chromecast. But I assume, they worked with Google to accomplish this.
Additional SO Resources
How to play smooth streaming video in Chromecast?
Is it actually possible to play SmoothStreaming videos on Chromecast without using (format=mpd-time-csf)?
Playing Smoothstreaming URL by providing Manifest file of smoothstreaming to Chromecast device
Update #1
Based on Les Vogel's answer, smooth streaming manifest file for adaptive bitrate streaming is supported by Chromecast. You need custom player to handle that.
As far as I am aware of, currently there are two JS player which can handle that, but I don't know if they will work on Chromecast.
dash.js - By DASH Industry Forum (https://github.com/Dash-Industry-Forum/dash.js)
Microsoft HTML5 Player Framework - Part of Microsoft Media Platform (http://playerframework.codeplex.com/)
Currently, you need to write your own media player to support adaptive bitrate streaming on Chromecast.
Unfortunately, the MS test server assets do not correctly provide a CORS header, which would be needed if you wrote a javascript player.
PlayReady and Windvine are both supported. We'll be providing additional documentation shortly.
EDIT We announced the beta of the Cast Media Player Library today 2/3/14 - it supports HLS, SmoothStreaming, and MPEG Dash.
Yes, you can use "com.microsoft.playready" for PlayReady and "com.widevine.alpha" for widevine.
I'm working on a desktop application built with XNA. It has a Text-To-Speech application and I'm using Microsoft Translator V2 api to do the job. More specifically, I'm using is the Speak method (http://msdn.microsoft.com/en-us/library/ff512420.aspx), and I play the audio with SoundEffect and SoundEffectInstance classes.
The service works fine, but I'm having some issues with the audio. The quality is not very good and the volume is not loud enough.
I need a way to improve the volume programmatically (I've already tried some basic solutions in CodeProject, but the algorithms are not very good and the resulting audio is very low quality), or maybe use another api.
Are there some good algorithms to improve the audio programmatically? Are there other good text-to-speech api's out there with better audio quality and wav support?
Thanks in advance
If you are doing off-line processing of audio, you can try using Audacity. It has very good tools for off-line processing of audio. If you are processing real-time streaming audio you can try using SoliCall Pro. It creates virtual audio device and filters all audio that it captures.
I am developing a WAP/mobile website that would allow users to stream audio/video (although the priority is audio) via their mobile browsers..
For music I would be streaming mp3 files, and for video I would be streaming flv and 3gp files (but mostly 3gp).
Can anyone recommend solutions (i.e. what to use and/or a point to the right direction) to enable streaming audio/video to a mobile browser?
AFAIK, there is RTSP (probably via Darwin Streaming Server?) which is supported in most 3G devices, and flash lite. (Would using flash lite as a player even be a good idea, since the users would need to have flash lite installed on their mobile devices? I'm not that familiar with flash.)
Most mobile phones support video streaming via RTSP, and the cheapest method is the Darwin Stream Server, and it integrates with the Real Video player
As for flash lite that has limited handset support so I wouldn't recommend using it.
The only thing I would add is that without wireless carrier support streaming of data to a mobile phone can be very expensive for an end user, so please ensure that the end user knows about the potential data charges