It has been a long time for people trying to download videos from those sites not allowing them to do, and now they are using the HTML5 element with blob: URL created from MediaSource. Anyway whatever the source is, the video is buffered
and played in the browser so the data must be somewhere.
There are solutions like https://superuser.com/questions/1033563/how-to-download-video-with-blob-url, which is kind of useful for those sites not strictly protected, not working in the extreme case.
So here let's assume that all scripts are strictly obfuscated with network transmission encrypted, and how should we extract the data buffered to be displayed.
Solutions are not limited, except from reimplementing a browser myself.
Edit
The scenario seem like Youtube a lot, but it is impossible to trace anything through the heavily obfuscated script neither the encrypted network transmission.
Related
I have two iframe elements loaded with each their document, both of the same origin domain.
The document loaded in the first frame obtains some media stream (using getUserMedia) and will attach the stream to a player.
The document loaded in the second frame also has a player and I want to re-use the same media stream for this player as well.
Searching for a solution I came across the RTCPeerConnection class article at Mozilla Developer Network and then some examples of using it.
But it looks really heavy for a simple use case like mine. I just want to share the stream between two frames in the same browser and on the same computer.
Is what I have found the only way to achieve this?
If so is there any way to improve the performance (less CPU usage)?
Or is there another way to achieve the above mentioned use case?
I can't quote a relevant Web standard publication at the moment, to assert the behaviour I am about to describe is "standardised", but I have empirically verified it (playing back of a media stream in another frame) is trivial to accomplish with Google Chrome, Microsoft Edge or Mozilla Firefox, if the frames/documents share the same origin.
Being how these are the most popular user agents, especially for applications that depend on the MediaStream class, their capability should suffice for your application, I presume.
The crux of the solution is that the aforementioned user agents do not distinguish between frames of the same origin with regard to playing back a media stream.
Meaning that yes, if you can use the following code in your application, assuming player refers to some HTMLMediaElement and media_source to some MediaStream object:
player.srcObject = media_stream;
...then the code will work "from another frame" as well (provided that other frame is of the same origin, of course).
There is no special case that you have to address. To play back the same media stream in multiple documents/frames, you can (and should, methodically) be assigning the same media stream object to the srcObject property of some media element that is part of any one of the documents, as long as the documents share the same origin.
The performance should arguably be optimal, since the media stream is one and the same and is thus "shared" by all media playback elements. You are not duplicating the stream, after all.
I am certain the proposed solution becomes invalid when you attempt to play back a media stream created in context of one origin, with a media playback element that is associated with another origin. You may be able to duplicate the media stream by copying its data segments, blob by blob or source buffer by source buffer, perhaps, using message passing that assumes both frames cooperate on either end of the communication channel (through postMessage), but that will definitely not be performance optimal, I'd imagine, if at all possible.
I'm using VideoJs to play various videos. Some bigger than others.
Here's a simple scenario. A video starts playing that has 100mb length in total with a duration of 10 minutes. If the user skips to minute 2 then a call will be made to the backend to server the whole remaining video.
That's not good as far as user experience goes.The download time can be quite big and the player will be stuck in loading until it's finished.
Ideally what I'd want for it to do is download in chunks of 5-10 seconds.
Honestly javascript isn't my strong point so I don't really know where to being in doing that.
The backend accepts byte ranges. And I also have a Varnish.
Also I'm not opposed to using another video player if the one I'm currently using is not ok or for some reason doesn't support what I'm looking for.
Any pointing in the right direction is greatly appreciated.
For anybody who comes across this question and has the same problem:
https://info.varnish-software.com/blog/caching-partial-objects-varnish
Also make sure that varnish forwards the Range header.
This is quite possibly an issue with your file or server configuration, and not necessarily VideoJS. When you want users to be able to seek beyond the current buffer, you're usually talking about psueudo streaming.
To do this, your server must:
Support byte-range requests (you indicated that your back-end does support this)
Return the correct content-type header
Since you stated your server does support byte-range requests, I'd double check the content-type header.
Also, if you are using H.264 MP4 files, you might need to optimize them for streaming by moving the metadata (MOOV atom) to the beginning of the file. Some video encoders also refer to this as "fast start". A standalone application that can do this to already encoded MP4s is qtfaststart.
Otherwise, VideoJS should support seeking automatically. You can find a number of examples of them on JSFiddle.
You can also try to seek programmatically to see if that behaves any differently:
let player = VideoJS.setup("video");
player.play();
player.currentTime(340); // time to seek to
I have an web page where users can view videos.
But the problem is when I inspect the page, it shows the video url.
So is there any idea how we can hide video source like youtube and other videos portal ?
There is no way to hide the video URL entirely without resorting to browser plugins. You can obscure it though, but in most cases they won't be worth it.
Using Media Source Extensions you can deliver segments of video data using obscured urls. And the URL won't be immediately visible in the source of the page. This is similar to what Youtube or Netflix does but requires massive engineering work on the backend. This is also the technique used to play MEPG-DASH with e.g. dash.js or shaka-player.
Set it using Javascript, so it's not viewable with view source, it won't help with inspecting though.
If your issue is people copying the stream URL and using it in their own players, then you might look at protecting it with some sort of tokens security. This is supported by almost any CDN out there, and there are plenty of open source systems to do it in most programming languages.
Lastly, if the issue is that you don't want anyone to copy the content, you can apply DRM protection. One of the easiest and straightforward ways to get started with that, might be using Azure Media Services.
I use Google's downloadDataURI function to download the PNG exported by a Google Chart.
In Chrome is working well, but in Firefox instead of downloading, replaces the html content with the PNG that is generated.
Anybody knows how to fix that behavior in Firefox?
First of all, this doesn't look like it is a Google project at all, but just a project somebody put up on the free Google Code hosting service (+ appspot)
What it does:
It checks if the browser is "webkit", and if not just changes the location to the data URI. This is exactly what happens in firefox and why the PNG is displayed instead of being downloaded.
Otherwise, it will construct a hidden <form> and <input> and post it to some random HTTP appspot server. And this does not sound very secure. The people running the appspot instance could log requests and/or a man-in-the-middle attacker could passively monitor the unencrypted transmission.
Honestly, I wouldn't use this service, ever, because I cannot trust the transmission channel, and I cannot trust the people behind it.
Instead, consider using <a download=... >, e.g. see Is there any way to specify a suggested filename when using data: URI?
im just interested how firefox plugins like DownloadHelper, is able to automatically find .flv URL
There are a bunch of possible approaches and DownloadHelper seems to implement a couple of them. If you extract the .xpi file (which is a ZIP file) and look in the components folder, you'll see a bunch of different handlers for getting videos. I haven't looked at it thoroughly but you'll notice that dhYoutubeProbe.js basically extracts the video ID from the DOM and then plugs that into a standard YouTube URL pattern for fetching FLVs.
dhNetworkProbe seems to implement a more sneaky and interesting approach - it monitors the browser cache and/or HTTP requests for transfers of media files to get the underlying file's URL.
You could also look at how Firebug or similar monitor HTTP requests and responses. Playing an FLV via Flash player logs to Firebug like any other (non-streaming) request.