I have a https secure page https://apps.iacampaigns.co.in/test.html over which i have embedded a youtube video iframe.
The call to this iframe is made over https but there after calls like //r1---sn-n2xjug5oxu-qxae.c.youtube.com/videoplayback?algorithm=throttle are made over http.
Therefore now my page has mixed content and it becomes not totally secure.
I checked and found http://apiblog.youtube.com/2011/02/https-support-for-youtube-embeds.html.
This confirms that till FEB 2011 although youtube had moved to https parts like video bitstream were still available only over http.
I would like to know the current status of this.
Are the video bit stream urls still available over http only?
Yes, that's the current state. We understand the need but don't have anything to share at this time
Related
There is sample code to play video in Decentraland. This link
However, I want to play video from a playlist in YouTube channel. Is there any sample code you can reefer me?
Unfortunately you cannot directly access any Youtube videos due to a CORS policy set on their side. This is not an issue with Decentraland itself, but rather with Youtube and other content providers that have a similar CORS policy.
Youtube and Twitch (for example) have their own javascript players that not only display ads but also gather information about the viewer. Seeing as this is the basis of their income, they do not want people bypassing this and just viewing the video for "free".
You may notice that youtube videos work in CryptoVoxel for some reason. This is due to some trickery that the game is doing, where it is loading in the html/js and placing the video on-top of the game itself. (At least that is what I've heard)
In the meantime I strongly suggest you look into hosting your videos on another platform like Vimeo. You can directly access the video files if you pay for their service. Alternatively, you can host your videos on an Antmedia server through a cloud hosting service like Digital Ocean. Both of these are great options.
I am trying to build a web app for users to easily add text (as open caption) and other assets in my app as overlays in real-time to their YouTube live stream video.
They will use their camera to record their video, and select from my app which text should be added to the video.
Then, the video will be sent to Youtube live through their API.
Here are my questions:
First of all, I was wondering if mixing video + subtitle and sending it to Youtube's rtmp url can be done from the client side, so it's simple and lightweight.
Second, should I encode the output being sent to Youtube? Can this be done from the browser too?
I'm only seeing a few node.js frameworks, and even they're not very mature (or is Webcodecs for this purpose?). Is a web app a poor choice for this task?
Lastly, if I do need a server to process the video, where should the encoding happen (from the user's machine, or in the server, or both?)? Is my server most likely going to be the bottleneck given YouTube's infrastructure, since video files are huge and my server is limited?
I am new to video streaming, so please excuse my lack of understanding of the subject. Also, if there's any good resource for my problem, please share them with me.
First of all, I was wondering if mixing video + subtitle and sending it to Youtube's rtmp url can be done from the client side, so it's simple and lightweight.
You can do the video compositing and audio mixing and what not, but browsers don't support RTMP. To get the data to an RTMP server, you need to send it to a server where it is proxied off to the final URL.
They will use their camera to record their video, and select from my app which text should be added to the video.
Yeah, that's no problem at all. Draw everything to a canvas every frame.
Second, should I encode the output being sent to Youtube?
Yes, you must. Check out the Media Recorder API.
Lastly, if I do need a server to process the video, where should the encoding happen (from the user's machine, or in the server, or both?)?
The video has to be encoded client-side to get to the server in the first place. The server can then hopefully just repackage with flv and send it along. If the browser doesn't support H.264 in its Media Recorder API, then you'll have an intermediary codec like VP8, and you'll have to transcode server-side.
A few years ago, I wrote a tutorial on how to do all of these steps here: https://github.com/fbsamples/Canvas-Streaming-Example Note that the tutorial is in the context of Facebook, but this should teach you the concepts.
Every time a user starts a live stream on YouTube, a new ID is generated for the stream, along with the corresponding video and URL. Currently, if I want to embed a live stream, I can use YouTube's sharing functions to add the video to my page in an iFrame.
When the user stops streaming, embeds of the live stream automatically switch to showing a recording of that stream. However, if the user starts broadcasting again later on, the embed will continue to show the old recording instead of switching to the new stream. This is because the video ID in the embed is hard-coded and each stream generates a new video ID.
My goal is to create an embed that will automatically display a user's live stream whenever they are streaming, and show an indication of whether they're online or offline. Is there an embed URL that would allow me to do this, or is there something in the API that might help?
I want to embed other streams that aren't just my own, so I need to do this in a way that doesn't require the streamer to log in or authenticate on my site.
If you know the ID of a YouTube channel, and if that channel streams a livestream set to Public, an iframe with this URL will show it:
https://www.youtube.com/embed/live_stream?channel=YOUR_CHANNEL_ID_HERE
See https://stackoverflow.com/a/39582176/470749
Unfortunately I haven't found a similarly simple way to permanently embed the YouTube chat for that livestream.
As far as I can tell, there's nothing built into the YouTube API that would allow you to embed a channel's current live stream automatically without knowing its ID. That said, it's possible to implement this yourself by writing a custom API and hosting it on your own server.
I recognize that this can look like a daunting task, so I've laid out some rough steps below to get you started.
Set up an endpoint on your own server. You could accept a
channelId argument or hard-code one, depending on how extensible
you want this to be.
Query YouTube's search endpoint1 for the specified channelId and eventType=live. An HTTPS request for this will look something like this:https://www.googleapis.com/youtube/v3/search?part=snippet&channelId=[CHANNEL_ID]&eventType=live&maxResults=1&order=date&type=video&key=[YOUR_API_KEY]
Check the search JSON response. If it returns any results (data.pageInfo.totalResults > 0), you know that the channel is live.
If the channel is live, redirect the request to your server directly to the live video's embed URL based on the video's ID in the query response (data.items[0].id.videoId).
If the channel isn't live, create a placeholder as you see fit, or make a second request to search for eventType=completed for past broadcasts, eventType=upcoming for scheduled broadcasts, or remove the eventType parameter to get the most recent video.
Once you have a server that can respond and redirect requests, you can embed an iFrame in your page that points directly to your API URL. Your server will handle the logic and, using the redirect, change the iFrame to a YouTube video player automatically, without requiring you to perform client-side logic or expose your API key2.
1 As with all YouTube API requests, search#list queries will count towards your daily quota. If you intend for this to be a high-traffic endpoint, you could either request an increased quota from YouTube, or implement a caching solution on your end to cut down on the number of requests you make.
2 GCP (Google Cloud Platform), which you'll use to manage your access the YouTube Data API, has pretty good protections against API key theft for times when you do have to expose it on the client side. That being said, best practice is to keep your key secret by storing it only on the server whenever possible.
I'm working in analyze the live tv streaming from TVB(HK)
Well known the url(s) to watch them are:
http://token.tvb.com/stream/live/hls/mobilehd_hdj.smil
http://token.tvb.com/stream/live/hls/mobilehd_j2.smil
http://token.tvb.com/stream/live/hls/mobilehd_inews.smil
We can directly watch by url(s) above in any apple native software(such as QuickTime, Safari) no matter in Mac or iOS. And also known they are using AppleCoreMedia framework. But it won't works in other platforms. You will get HTTP 200 but "access denied" in content.
I analyzed all the traffic about it. I found that the HTTP request(by CoreMedia) to the endpoint(the server really provide video) contain a header:
x-playback-session-id: xxxxx
The video arrived instead of "access denied" message after I add the header manually(I tried in Chrome or Firefox), no matter what the user-agent is. But the problem occur is, I can't find any other place contain this header in earlier request(since it redirected a few times) in the traffic I dumped. So I'm curious what AppleMediaCore did when it playing http stream? Did it calculated a session id(or hash) or it got the id from somewhere i missed?
p.s. I'm not sure TVB do a IP check or not. Since they had a copyright or legal concern so maybe blocked to access from somewhere. You maybe need a VPN.
Finally I found the answer. The x-playback-session-id is a UUID comes from the AVPlayer Framework. But in fact this won't affect I got token or not. The real token is HTTP cookie.
Authorization process I found:
token.tvb.com redirect to vod server with a couple of GET value
VOD Server check GET value and set cookie if valid. Also respond m3u8 file(contains several different quality stream url)
Player will request one or more url in m3u8 to retrieve streams. VOD server will then check cookie and user-agent as token.
In the coming time player will keep using the cookie and user-agent as token to request ts files.
p.s. HLS from TVB for android has different process I haven't figure out. But I found that if user-agent contains "Android" then authorization will fail.
I am trying to understand how the HTTP Live Streaming protocol that Apple supports on their iOS devices as well as on Safari protects the key that unlocks the content.
The way I understand it, the .m3u8 file holds the whole thing together and references the content (in MPEG2 TS container, AES 128 encrypted) and the key to the TS file.
Like in this example:
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:7794
#EXT-X-TARGETDURATION:15
#EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52"
#EXTINF:15,
http://media.example.com/fileSequence52-1.ts
#EXTINF:15,
http://media.example.com/fileSequence52-2.ts
#EXTINF:15,
http://media.example.com/fileSequence52-3.ts
#EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"
#EXTINF:15,
http://media.example.com/fileSequence53-1.ts
Assuming a browser based playback where the <video> element is fed a m3u8 file in the "src" attribute. In this case, even if the key is delivered via https, how can I make sure that the user does not simply enter the https URL in his browser and saves the key to his hard drive? The way I understand the mechanism, the key download is done by the <video> tag as it plays the m3u8 source using the browser's https stack -- how is the legitimate client inside the browser distinguished from the user just typing it into the address bar? This must be really obvious, but I just don't see it...
All the best,
dansch
how can I make sure that the user does not simply enter the https URL in his
browser and saves the key to his hard drive?
You can have an SSL client key/certificate in the app, and thereby authenticate "the app" for playing the content. Then you'd avoid leaking your content to other devices than your app.
But that would mean you'd need to somehow hide your ssl-key/passphrase inside the app. And there are unfortunately also problems getting the video player on iOS to use the ssl key authentication...
Some interesting pointers can be found here: https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html
This will require custom work in iOS, but also in Android and web players.
Serve keys from a protected HTTPS realm. Before playback begins, your app can use NSURLConnection to authenticate itself, providing credentials that are kept hidden.
Use cookies over HTTPS. Your app can make a connection to an HTTPS server and authenticate the app in an app-defined way. Your server can then issue a cookie that applies to the key URLs. You should set the cookie to expire long after playback is complete. The server must then require the presence of a valid session cookie in future GET requests for the keys.
For maximum reliability, if the expiration date is in the near future, the server should update the cookie’s expiration date in its response to future GET requests.
Specify the keys in the .m3u8 files using an app-defined URL scheme. The app should register a custom NSURLProtocol to handle requests for those URLs. The player then calls back into your app when it needs to load a key URL; your app can then obtain the key using a secure side channel and can provide it to the player.
If you're only targeting iOS, then you should use Apple Fairplay DRM which handles the authentication of the keys.
The answer is not obvious at all. You're essentially required to invent your own key delivery if you want it to be secure. One option is to set a cookie for authorized users, and to verify the cookie in the key server. This will keep someone from being able to just use the key url to bypass your security.
Keep in mind that it still only takes one legitimate client to leak the key for your security to be invalidated.
The best way is to use Apple HLS supported encryption.HLS support 128 bit AES encryption and the client player need to decode the stream.
how is the legitimate client inside the browser distinguished from the user just typing it into the address bar?
Interesting distinction, the suggestion is the browser the user is using is legitimate when playing the video embedded in the web page, and illegitimate when accessed via the address bar.
But there is no actual distinction there, I don't think you are missing anything.
How would you give rights to a browser and not a user? Cannot a user just write their own browser?
I know, it seems unlikely a user would write a browser, but these types of discussions are always about unlikely scenarios anyway. An unlikely user might find a way to view the m3u8 as plain text, they might download the keys directly, they may use those keys to unencrypt and eventual piece together the video segments.
Or, something that is far more likely - use screen recording software to copy any video that they can play in the browser.
In my opinion, if a user is authorized to play the video, they can, unfortunately also copy the video - because there's no way to prevent the display of the video being redirected into something that is no longer encrypted - at least in the environment of a desktop computer that is playing a video in a browser.
Anyway, my understanding is that you can protect the keys by requiring authorization to get the keys, but if the user has that authorization, then - well they can get the keys.
Have a look here
https://datatracker.ietf.org/doc/html/draft-pantos-http-live-streaming-13#section-6.3.6
the playlist will have to specify a key tag for each segment. so a player will be able to identify a key required to decrypt a segment.
Browsers do not support DRM out of the box. HTML5 specify that it can be done via EME (Encrypted media extensions) whoever not implemented atm.
so your options are:
use flash and fetch the keys via your own algorithm
write your own plugins(extension)
be big like Netflix and agree with browser
vendors to support your DRM aka content protection and key
distribution.
Apple's implementation of HTTP live streaming does not support DRM.
See FAQ number 16 on https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html