I found that Netfilx can prevent users from screen capturing on their videos. If you do screen capture on their videos, you will get black screen.
How does it work? What technique is involved in?
This is usually functionality provided by the DRM systems and the devices or browsers secure media path.
You may find that certain browsers support this and other don't, depending on where the combination of device, browser or player and DRM system supports it.
It is an evolving story and those that don't currently support it typically will have plans to add support.
Related
Is possible download a MPEG Dash content with DRM?
How can I decrypt using the MPD file?
I tried download all M4S segments (audio and video) but when I join the segments the video doesn't work properly.
The site is using Widevine platform for DRM.
I tried too youtube-dl and dash-proxy but again unsuccessfully.
I searched on Google but I didn't succeed.
No because it's not part of the browser. The browser implements EME which allows to 'offload' decoding a video to a 3rd party software.
When you download chrome, you download another compiled "CDM" app which does the decoding and is a 'black box'. So you'd need to modify that black box CDM, not the browser. So only option is then the screen capture.
MS has a system that even prevents screen capture software (since windows controls OS) Chrome desktop CDM has weaknesses but not in the league of 'youtube downloader'.
Also Google doesn't provide CDM for modified browsers.
A researcher on twitter a couple years ago claimed to defeat the encryption by directly cracking the encryption itself, based on knowledge of what the CDM was doing. At this point though, it's beyond 'look the other way' and you would definitely be in legal jeopardy if you distributed such information or content.
In the future, Google would like all of this to be done in hardware further making it hard to defeat. Eg once they got several hardware manufacturers to put a chip in their monitors, they might literally say "if you want to watch google play or netflix, you need an 'secure monitor' (you know, so people don't spy on you...) ".
It's basic economics. If you can't live without netflix, they will lock it down and make you pay for each view. If you're 'meh' they will make it 9.99 and reel you in. If you literally prefer some 'open source movie website where everythings free, though lame' They will just try to track your interests, for a better day when they can make something irresistible you will pay for.
At this point people are pretty 'addicted' so encryption chips are being put into monitors, motherboards, video cards, even cables connecting the monitor to computer. But if they squeeze too hard, people will just walk away. But their data models now would warn them if people were getting to that limit, so it's unlikely.
EDIT: today I came across a code repository which is a chrome extension that will tell you the decryption key as it decrypts a video. I won't post the link here (but it's currently at github publicly). It contains the private key that is used by the Google Widevine CDM to decrypt the keys (which are sent encrypted from the license server). So if you have access to watch a video (eg you rent a video at google play) then you can see the key, download the mp4, then use ffmpeg to decrypt the mp4 with that key that was reported while you played the video. You would then have an unencrypted video. This is why Google tells their content providers to only provide 'low quality' versions for desktop browsers, and reserve high quality (eg 4K) content for environments where decryption is happening in a hardware chip.
I am assuming you are asking how you can handle the DRM part and that the download part is ok, using dash-proxy or similar?
The way the DRM works with DASH streaming is that the player streaming the video will recognise from the manifest and/or the video stream that the video is encrypted when you try to play it and will ask the DRM license server for the license.
For widevine it requires the URL of the license server to be configured or input into the player - see the the example at Shaka player: https://shaka-player-demo.appspot.com and choose custom asset from the drop down list and you will see how you have to enter the License Server URL.
If you have downloaded the video then the player will still need to recognise that the video is encrypted, that the DRM system is widevine and will need to be told the license server to request the license from.
The player can recognise the content is encrypted from the MP4 PSSH box - a header which indicates it is encrypted and the DRM system being used, in your case Widevine.
If you don't have authorisation or the video was originally a live stream or if it had some time constraints you may not be granted a license. Similarly, if you are planing to watch it offline, then you will need to receive a persistent license (one that is valid on the device for some time) which may not be available for the video you want to watch.
If you have the key used for encrypting the content, You can try the dashdownloader script from github hosted in Drm-Dash-stream-downloader repository. It uses ffmpeg for aes-128 encrypted content and mp4decrypt from Bento tools SDK for other cipher suites.
I'm trying to understand what the introduction of the Web Audio API has meant for the development of web based games.
Flash games can of course do some quite advanced audio processing, and for simpler games the audio element was maybe enough. But how has Web Audio API changed the game dev scene? In terms of what can be done, supported platforms and so on.
Supported platforms are Chrome, Safari (with some prefixing caveats) and Firefox across all supported hardware/OS platforms; IE is working on development, though the longer tail of versions will take a while to deploy.
Web Audio enables very complex processing, but also very precise timing and multiple sounds; sound management is far, far easier than previously possible in HTML5. In short, Web Audio dramatically improves the story for game audio development on the Web - which, of course, was one of its goals.
My Chromecast app isn't for video but rather shows an information flow (sorry to be vague). I want the app to be free and monetized by occasional and/or banner onscreen ads, on the TV not the mobile device. In order to do this I need an ad network (AdWords, etc.) that has a fit for the display-only, full screen, non-clickable, nature of Chromecast but has a JavaScript/REST/etc. API that I can use from browser on the Chromecast device. Anyone have a suggestion? Google?
You might check Vistar Media. They have ads that play on TVs you see in public spaces such as Hotel Lobbies. You would need to probably have significant volume. I think Brightroll might have some media as well. You could potentially run video ads from someone like Virool.
I was wondering whether it is possible to capture audio data from other sources like the system out, FM radio, bluetooth headset, etc. I'm particularly interested in capturing audio from the FM radio and already investigated all possibilities including trying to sniff the raw bluetooth communication between the phone and the radio device with no luck. It's too bad Android only allows recording audio from the MIC.
I've looked at the Android source code and couldn't find a backdoor to allow me to do that without rooting the device. Do you, at least, have any idea how to use other devices (maybe access somehow /dev/audio) say via NDK or even better - Java (maybe Reflection?) to trick the system to capture the audio stream from say, the FM radio. (in my case I'm trying to develop the app for the HTC Desire)
PS. And for those of you who are against using undocumented APIs, please don't post here - I'm writing an app that will be for my personal use or even if I ever publish it I will warn the user of possible incompatibilities.
I've spent quite some time deciphering the audio stack, and I think you may try to hijack libaudio. You'll have trouble speaking directly to the hardware (/dev/*) because many devices use proprietary audio drivers. There's no rule in this regard.
However, the audio hardware abstraction layer (HAL) provided by /system/lib/libaudio.so should expose the API described at http://source.android.com/porting/audio.html
The Android system, and especially audioflinger, uses this libaudio HAL to find available devices, deal with routing, and of course to read/write PCM data.
So, you could hijack the interaction between audioflinger and libaudio, by renaming the later, and providing your own libaudio which decorates the real one. Doing so, you should be able to log what happens and very possibly intercept FM radio output, provided that this is not directly handled by the hardware.
Of course, all this requires rooting. Please comment if you manage to do this, that interests me.
I recently downloaded a barcode reading application for my phone, an LG KU990i (AKA the Viewty) However, there's a problem that renders the application nearly useless: the Viewty has 2 cameras -- the main one, and a secondary camera located on the face of the unit -- and it is the secondary camera that is unfortunately set as the phone's default video capture device. As you can't point the secondary at anything and see what it's pointing at at the same time, it makes it a bit difficult to snap a barcode!
According to the JSR-135 spec, it is possible to specify a video capture device other than the default... if you know the device name. This does not appear to be documented anywhere on LG's Web site, nor does the JSR-135 spec describe any way of enumerating the devices on a phone... or is there? Failing that, are there any naming conventions for video devices commonly in use that LG might be using?
I've logged a ticket with LG, but as it's an old device, I don't imagine them breaking their backs in getting back to me... I should also point out that this is purely for my own curiosity so no-one here should feel obliged to break their backs either!
As far as I know there is no way to get list of all available catpure:// urls.
All urls I know:
capture://image,
capture://video
capture://devcam0
capture://devcam1
Source:
http://www.forum.nokia.com/info/sw.nokia.com/id/bc00e4ce-7df3-4527-962c-d39843a808d0/MIDP_Mobile_Media_API_Support_In_Nokia_Devices_v1_0_en.pdf.html
LG responded to my support ticket. Apparently, it's not possible to access the primary camera on the Viewty from Java, making it pretty much useless for barcode scanning. Answer reproduced here for search engines.
You support ticket has been answered. Please visit the LG Mobile Developer Network and login to check the answer at [My Page > My Tickets].
KU990i default video capture device is the secondary camera
Answer :
Hi,
KU990i have to Two camera module
differently.
Main camera using Joran chipset and
sub(front camera) using Qualcomm
chipset.
Joran chip doesn’t supported JSR135.
Therefore, we couldn’t supported to
the JSR135 using for main camera.
(it is H/W limitation)
It was inform to operator already and
we remember operator was confirm it.
So that, we only supported sub camera
for JSR135.
BR,