I am migrating from a receiver v2 to a CAF receiver (aka v3)
My understanding is that CORS headers are not required when streaming a media hosted on a different host than the receiver's if:
the media is file-based (e.g. mp4)
AND no text tracks (captions) are present with the media.
With v2, this worked as described: all my file-based media (e.g. mp4) stream just fine without the CORS headers. CORS headers are indeed needed with captioned videos or HLS
With CAF (v3) however, the receiver is complaining about missing CORS headers even with plain (no captions) mp4 video files.
Is this a bug in v3 or did I miss something from the docs?
Here is a gist containing a simple receiver that should make it easy to reproduce the issue.
Addendum: I believe this is likely a bug, linking to the issue I created
With the CAF receiver, a crossorigin attribute needs to be added to the cast-media-player tag to restore the old behavior
<cast-media-player crossorigin=""></cast-media-player>
Related
I'm using Azure Media Player for video playback and that works great. However, the media player css/js/wof files do not have any cache-control headers set. They come from the amp cdn (amp.azure.net). Am i doing something wrong? I cannot find any information whatsoever regarding Azure Media Player and client side caching. What is the recommended way to set up client side caching when using amp.azure.net ?
According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching, "HTTP is designed to cache as much as possible, so even if no Cache-Control is given, responses will get stored and reused if certain conditions are met. This is called heuristic caching." In the response to the azuremediaplayer.min.js, azuremediaplayer.min.css, and the woff2 file, I see no cache control directive as you mentioned. Therefore, there are no specific restrictions on caching. In most cases this means that all three files should be cached normally.
I'm trying to encrypt my live streaming content using DRM encryption by following instruction from https://learn.microsoft.com/en-us/azure/media-services/previous/media-services-protect-hls-with-fairplay.
This is my DRM policies and the streaming locator:
I'm able to get the MANIFEST file from the HLS URL. I found that should have another line (known as License URL?) something similar to the following, but it's not appearing inside my downloaded MANIFEST file:
#EXT-X-SESSION-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1",URI="skd://willzhanmswest.keydelivery.westus.media.azure.net/FairPlay/?kid=90e91c74-feb1-41ed-920a-3330a62279ca"
Is it something wrong when I configured the DRM? For the FAIRPLAY I uploaded .pfx file, password is in STRING format and the ASK is as given by APPLE. Is this correct or is there anything I've missed?
This is by design. The URI="skd://willzhanmswest.keydelivery.westus.media.azure.net/FairPlay/?kid=90e91c74-feb1-41ed-920a-3330a62279ca" is indeed the FairPlay license acquisition URL. sdk is per Apple's FPS spec.
If player SDK does not require explicit license URL, it knows to replace skd by https.
If player SDK requires explicit license URL, your code needs to replace skd by https.
Quick note: you are using OpenRestriction for 3 DRMs. I assume this is just for test and do not intend to do the same with production?
I'm interested in adding a security front end to AzureStorage for authentication, access control, excessive usage (rate limiter), and other features.
I've read repos on Github regarding ASP.NET Core (I'm at 5.0), however during this research I came across many issues regarding HTTP CHUNKED, and do want broad browser support (Desktop and mobile) to simply GET the ASP.NET Core protected front end, and then use that CHUNKED verb to resume downloading from Azure Storage.
How can I use ASP.NET Core to support this feature in supported Web Browsers using Blob or other implementations of Azure Disk?
I'll provide links to docs and example you can use as a reference. If I understand correctly, you want to look at the BlockBlobClient class if you're wanting to upload data in chunks.
Here's a link to the API reference for HTTP level requests. Specifically it's the Put Block request, which is what gets called when doing one of these chunked uploads through the client. You mentioned HTTP CHUNKED, I assume you're referring to the Transfer Encoding : Chunked header and the transfer mechanism? It looks like HTTP/1.1 is the supported version for the Azure Blob Storage API.
I'm not entirely clear on your concerns but I know chunked transfers are not supported in HTTP/2. Not sure what you would do about that until the service is updated at some point in the future. You said you were building a front-end, which I assume is likely a JavaScript based application of some sort? If so, you can use the Blob Storage JavaScript client library. Obviously if you're uploading from inside ASP.NET, then use the C# package.
HTTP API Reference : https://learn.microsoft.com/en-us/rest/api/storageservices/put-block
Example : Upload video in chunks Azure blob storage
Docs : https://learn.microsoft.com/en-us/dotnet/api/azure.storage.blobs.specialized.blockblobclient?view=azure-dotnet
I've worked around this but it's an interesting issue.
So using Unity and Unity Web Player (I know WebGL blah blah but it isn't baked yet and doesn't support everything we need) we are streaming video directly from Azure Blob storage.
Now the built in class WWW is a non-starter since it doesn't stream and some of these vids are fairly large. So we used a plugin and a class MovieStreamer to stream the vids. The plugin uses sockets directly but through Unity's version of mono. The sockets require a cross domain policy be available on the flash port for CORS (873 using a non-http protocol).
I had thought that setting the CORS policy on the storage server would enable this. Since the HTTP(s) CORS policy can be set by placing a crossdomain.xml in the $root and making it publicly accessible the CORS policy through API seems redundant. However, it just doesn't work. Even with all "*"s I see the same error for a missing cross domain policy even with the http crossdomain file and settings through the API.
What I did was hack things to use another streaming HTTP plugin and like magic that works since it does in fact use the crossdomain.xml. So without settings changed in AZURE socket CORS is a no go but BestHTTP works fine as does WWW.
So the questions are:
What support does Azure storage have for CORS.
Is the policy API supposed to enable the flash route?
What is the precedence between the two flows?
Keep in mind we aren't using flash it's just that the socket route piggy backs on the flash protocol.
This code sample may be of help.
I've noticed a lot of websites use m3u8 playlists on their html5 video tags, and those segment files inside the playlist appear to be h264 encoded, so I'm guessing the container is the only thing that the chromecast doesn't support in this case although I know very little about video containers and codecs so I'm probably just making no sense. So with all this in mind, is there any chance the chromecast will one day play those files?
Here is an example http://stream.gravlab.net/003119/sparse/v1d30/posts/2014/barcelona/barcelona.m3u8
Thanks.
Yes - You can using either the default Receiver, a Styled Receiver, or in a Custom Receiver and using the Media Player Library. Of course, you (the owner of the data) must turn on CORS headers for the m3u8 manifest, any sub-manifests, and for the segments and any keys on your server / CDN to support this. This requirement is due to our player being written in JavaScript and running in Chrome on the Chromecast device.
Note - for the Default Receiver & Styled Receiver, the URL to allow CORS from is www.gstatic.com. For your Custom Receiver, it will be the URL where you host your Receiver.