I want to capture some thumbnails from a video file which was loaded from an input file (client side).
Doing so, I have to create an Object URL by createObjectURL, then assign the Base64 value to video.src.
The problem is this didn't work with AVI format (DivX, XviD, MPEG2).
How to make it work with AVI? Or do you know any library which can capture image from a video file client side?
Any help would be appreciated.
A BlobURL is just an URL pointing to some data stored in your browser's memory.
So yes, you can very well create a BlobURL that will point to an avi file, or any kind of file actually.
Your problem here is that your browser doesn't know how to decode this file. Even if it were served from a server, it wouldn't be able to read it and thus to render it so you can grab your thumbnail.
There is no workaround to that, except maybe converting this file to a format your browser does support (e.g mp4.H264+AAC is pretty well supported).
But to do it on client side is not trivial, to my knowledge only ffmpeg-js could maybe allow us to do so, but I've never tried it myself, and I'm not sure how stable the port is, nor what's the current browser support is (for sure, it requires at least WebAssembly).
Related
I'm trying to read the contents of a text file that I have stored on my (the host's) computer. When I encountered Javascript's FileReader I thought it was the perfect tool for the job. However, every example or question I see online shows how to use it to read files that are being uploaded from the user's computer (and thus they can use the event target to point toward which file they want to read) or they use AJAX (well, at least the XMLHttpRequest object) to read their own files.
So is it possible to read from local (to the host) files using FileReader? As I am researching this question it is making me wonder if I am going about this all wrong, but is the only way to use information from a text file on a webpage through AJAX? That seems wrong, it seems like there must be an easier way.
A FileReader needs a Blob. Which is an object representing a binary file in memory.
From where this Blob comes from doesn't really matter, but you need to have it the browser's assigned memory so that FileReader can access it. FileReader won't download anything by itself.
So if you are talking about a file stored on your server, then the browser has to download it from there to the computer's memory. As to how this can be achieved, there are many ways the most common being AJAX, as long as the data is downloaded from the server and accessible, at least to build a Blob from it, then FileReader will be happy.
If you are talking about a file stored on the user's disk, then the browser needs to be granted the permission to access it and load it in its memory, this is usualy done using an <input type="file"> element, since for security reasons, browsers don't give access to the user disk otherwise.
I am looking to make a website that does three things:
The user can upload an image to the website (without a server)
-For this problem, I have found resources like Dropzone, but all seem to mandate sending the image to a server.
The uploaded file is manipulated on the client side
-For this problem, I need the uploaded file to be accessible from my JS/HTML code and I need some way for me to manipulate the file. I currently have my website with the pre-set file embedded in it, which I can then access and manipulate with JS, so the manipulation itself isn't much of the issue, but rather just accessing the file.
The user can then download the manipulated file (again, without a server)
-For this problem, I know that how to make a download button for files that have a web address (which are on a server), but is there a way to have a download button for the file that was just manipulated? I found this question here that seems to be a good starting point, but I am not sure if I completely understand the implementation of it.
Basically, I have the website framework in place (using HTML/CSS, Javascript) and I am just looking to see if this is possible to do without the use of a server, even if I have to use some other libraries. If any insight or links to potentially useful articles/libraries could be given on any one of these three points, I would much appreciate it.
Note: If this is not possible without a server, please let me know because then I will have to completely redesign everything and this whole question is trivial.
The user can upload an image to the website (without a server)
A website is typically hosted on a server. I think you mean the image is uploaded, but not stored anywhere.
The uploaded file is manipulated on the client side
There are lots of cool JS libraries to handle this, for something light you can try out https://fengyuanchen.github.io/cropperjs/
The user can then download the manipulated file (again, without a server)
So if I am understanding you are asking for an image upload -> edit -> image download. This is very possible and common. However, you will need somewhere to cache the uploaded image for the client.
If you are asking if you can upload an image directly to the DOM, you can not. You need to upload the image to the location where your files are being hosted. Imagine having an absolute path to C:/MyComputer/MyImage, it would obviously not work on any other machine than your machine.
If you need some examples on how to handle the upload image to temp location -> edit -> download let me know
I am switching our video player over from normal video sources over to chunked progressive video streaming using mpeg-dash. When using mpeg-dash rather than linking to an actual video source you link to a mpeg-dash manifest file which has all the information about each chunk and allows your player to swap in and out chunks as bandwidth changes. Now all of that seems pretty straight forward, however I am also working on setting up blob urls to obscure our source file location and I am running into issues. How does this work since all the documentation I can find on blob responses are either entirely in JS or return an XMLHttpRequest.
You can see an example here within the dash.js documentation that does exactly what I want http://mediapm.edgesuite.net/dash/public/nightly/samples/dash-if-reference-player/index.html if you inspect the element it has a blob url and loads in chunks but I cannot find any docs on how to do this.
So essentially my question is, how can you get a mpeg-dash manifest file to work in conjunction with the blob url system to obscure source URLs.
I am also working on setting up blob urls to obscure our source file location
I assure you that you're not usefully obscuring anything. The data has to come from somewhere. It's trivial to determine from where no matter how you think you're obscuring it client-side.
Don't bother with this.
How does this work since all the documentation I can find on blob responses are either entirely in JS or return an XMLHttpRequest.
The reason you see blob with web-based DASH players is that they're using MediaSource Extensions (MSE) to get the data in the first place. The video player effectively has a blob source which is managed by the browser. Your JavaScript downloads the chunks and sends them off to the browser to be ran through the codec and output to the video element.
There is a decent MSE example on MDN: https://developer.mozilla.org/en-US/docs/Web/API/MediaSource
I'm writing a web application which allows a user to select a PNG file, write an iTXt chunk to it and then save it back to their local file system. I would use the new FileWriter API to do so but currently only Google Chrome has added support for it.
Since my file is represented in memory as a binary string I use data URIs to prompt the user to save the file as follows:
window.location.href = "data:application/octet-stream;base64," + btoa(blob);
Since the mime-type is application/octet-stream the browser prompts the user to open or save it. However the problem is that the user does not know which type of file it is. So the user has to add the file extension manually.
Currently I alert the user which extension the file needs to be saved with. However this seems like an inelegant solution. Is there a better way to achieve the same result?
If this were HTTP, then you'd either have to set the content disposition to attachment, to get the file saved even if its mime type is known, or to set the file name for an attachment of octet-stream type. Neither of these headers can be emulated using the data: URI, though, so I see no way to open a “Save as…” dialog using such a URI.
Others have asked how to open a save file dialog for a js variable, and judging from the answers there, there appears to be ready-to-use solutions which work as long as the client has Flash installed (and not blocked).
So perhaps you might try severl solutions, starting with the FileWriter you mention, trying a flash-based approach if that isn't available, and falling back to data: URI with an alert message about the file name extension. That way you could probably achieve the best result possible for each client.
I recently started building a bookmarklet that displays the EXIF data of any image on a website. I chose to use Nihilogic's binary.js and exif.js libraries. For images hosted on the same domain as the parent page, the script works wonderfully. But because it uses XHR to read the binary data of images, and because XHR is restricted to same-origin requests, I can't access the binary data of any cross-site-hosted images.
Is there a way to load the binary data of an image locally (or at least without using XHR) that preserves EXIF data?
I've explored a few other directions, but I fear I don't understand them well enough to determine if there's a solution:
JSONP - I'm assuming there's no way to get binary data into one of these things.
canvas tags - these seem to produce very different base64 encodings than what PHP does, and I suspect that the EXIF data no longer exists in the new encoding.
Javascript is allowed to do special operations (like on the canvas) with same-origin images and cors-enabled images because the browser can safely assume that those would be OK to upload to the server in the first place. But then it gets complicated...
I can't access the binary data of any cross-site-hosted images.
Yes, generally it is very important that you can't. More to the point, you can't do what you want with a bookmarklet.
You can't do this with a canvas because the cors rules here are strict (for good reasons!)
In short the reasoning in general is pretty much exactly the same. Browsers are in a unique security position: A random page on the internet can show you things that are private to you, such as the hypothetical image, C:\MyPhotos\privateImage1.jpg, assuming it could guess that file path.
But that webpage is most certainly not allowed to do anything with that file other than show it to you. It can't read the binary information (EXIF information or pixel information). JavaScript is not allowed to know what that image looks like or nearly any data associated with it.
If it was able to figure that out, a random webpage would be able to try a bunch of file paths and maybe come across an image on your hard drive, and then upload the binary data of that image to a server, in effect stealing your private image.
A browser extension would be far more suited to this task than a (JavaScript) bookmarklet because of this.
Purely from the client? I doubt it. How about XHR'ing a local PHP script that runs something like exif_imagetype()? This function works on remote as well as images.