Client is sending continuous jpg to my server.
The issue is: how to make one mp4 file from all these jpg files?
I can save them all and use ffmpeg with “filename%3d.jpg”, when client finish sending files.
But is there any way to make it real-time?
Yes, there is a way. You can turn it into an mjpeg stream and mux it into an mp4 using any one of the many open source libraries that can do this. Or you can choose to reencode to a more temporal efficient codec such as h.264 to save final file size and bandwidth.
But either way, and MP4 is not usable until the last frame is written, so I'm not sure what the actually gain is from this exercise exercise.
Related
In our project we only need the audio of a video file, to reduce the uploading size for a client I'm looking for a way to convert chosen video file to audio in clientside then try to upload the file to the backend.
It's a react app by the way.
Any idea or solution or library will help.
Taking the audio track from the video is a conversion process that uses video/audio codecs and could take almost the same time as the video length itself to re-encode the streams.
It might be either a client application (downloaded on a user pc) or you have to upload the file to your backend, or to some online service that provides an Online Converter from MP4 to MP3 for example, this converter - https://conversiontools.io/convert/mp4-to-mp3. It has limitations for a free tier.
Check other links:
https://stackoverflow.com/a/17532410/4299666
I'm building a web app that uploads a local .mp4 to an S3 bucket. It's intended for low bandwidth environments. Is it possible to upload every 5th frame of an .mp4 in JavaScript on the frontend and upload this reduced .mp4?
I don't know if it's possible (I didn't find anything online) but it's certainly not easy.
It would be easier to maybe have an endpoint in a server that receives a video and returns a minified version. Like this:
Client --can you minify this video?---> Server
Client <--minified video---- Server
Client ---upload minified video---> S3 bucket
No, it’s not possible. Frames are not independent. Uploading a frame, without uploading the frames it references will crate a corrupt video.
You could make use of FFMPEG in your browser in fact. From ffmpeg.wasm:
ffmpeg.wasm is a pure Webassembly / Javascript port of FFmpeg. It
enables video & audio record, convert and stream right inside
browsers.
Check out the different parameters in regards to your nth frame rate from the documentation on FFMPEG.org.
PS: It might be better solutions to shrink the upload size, ie. compress harder, resize the video dimensions, or combinations of all these, including lowering the frame rate.
So here's the issue that I'm currently having. I need an audio player for iOS that will play mp3. Now at first glance this may seem like a trivial issue, just create an audio tag and give it the URL to the mp3 file. While this technically works, it's basically unusable since iOS needs to download the entire file before starting to play it. This results in a really long wait time when trying to play large mp3 files (could get close to a minute).
So the first thing I tried was to manually mimic the chunking that chrome does for playing mp3 files. I first sent a HEAD request to get the byte length of the audio file. Used that length / duration in seconds to get the average bytes per second and use that data to request chunks based on where the user seeks to. That didn't work since sometimes mp3 files contain metadata that throw off the calculation (like a cover image). Additionally, sometimes mp3 files use VBR (Variable Bit Rate) and then I'm well and truly screwed.
So this lead me to thinking, Safari couldn't possibly require the end user to download an entire mp4 file before playing it. So I took an mp3 file, converted it to mp4 on an online converter and tested my theory out. Voila, it worked. Safari was streaming the mp4 file in chunks and the wait time went to close to 0. Alright, so now all I need to do is convert mp3 files to mp4 files. The problem now is, I have requirement not to use my server for converting these files. I want to offload this expensive operation to the client. After looking around for a bit I found a few wasm libraries to do this, great! Nope. These wasm libraries are huge (24 MB) and would add an unacceptable amount to my already large bundles files. So this brings me to my question. Is there any way to "trick" safari into thinking that my mp3 file is mp4. What I've tried already:
On input change event -> get the file -> clone it into a new Blob with a mimeType of video/mp4 and then upload that file to the server. Chrome plays this file no problem (probably because it detects it's an mp3 file), on Safari however it's unable to play the file.
So my question is, is there any way to package the mp3 file in an mp4 container (Client Side !important) to "force" Safari into chunking the file.
Is there any way to "trick" safari into thinking that my mp3 file is
mp4
mp4 files are not seekable because the client "thinks" they are mp4. They have an index in the file that is required for the seeking to work. That index does not magically exist because the mime type was changed.
is there any way to package the mp3 file in an mp4 container (Client Side...
Yes, totally. But you must write the code and it is very complicated. You can read ISO 14496-12 document to understand how mp4 files are structured. and ISO 11172-3 and ISO 13818-3 to parse the Mp3 into frames that can be written to the MP4
I did this very thing last month, i only needed it for a 128kbps CBR mp3 live stream so i hard coded something to support that specific format, it can be modified to specifically support different bit rates though, but probably not VBR :/. Posting it here in case its of use to anyone dealing with firefox not playing an mp3 using mediasource extensions: https://gist.github.com/fanfare/0fa525af28b275fd6623942d7e9d70dd
I would like to stream an mp3. However decoding it on a sending party will eat up the bandwidth. Is it possible to retain compressed format and still be able to slice it into independently playable chunks? Then I could send them out one by one and queue up and/or stitch it back on a receiving party. From what I've heard mp3 specifically (not sure about other formats) should allow something like this by specification.
It is also highly probable that I'm fundamentally misunderstanding something about audio playback in general. Please advice.
Please check the RTP specification for the mp3 streaming
https://www.rfc-editor.org/rfc/rfc5219
the same concept of chunks and frame has been taken care in the specification.
you can use the mp3 encoded data from the mp3 file, pack them using the rtp specification and do unpack rtp and then combine/write them into mp3 file.
I am trying to stream an mp3 via javascript/html5 or flash on my webserver.
The javascript/html front end calls a script on the server which begins generating an mp3 file.
I want the file to begin playback immediately once enough audio is buffered, and to continue playing.
I am new to streaming and want to know the best method to do this in both apache server and windows iis.
At first I thought I would need to use an actual streaming protocol, such as rtp or rtsp, but it seems like it maybe better using a custom javascript player that takes the mp3 file in via http.
However the concern with http is that the file transfer will stop once the incomplete tail of the mp3 file is hit. Is there a way around this, perhaps altering the config to make the apache/iis server wait until the file is complete before terminating the transfer?
I also looked into m3u files but this seems to require a complete mp3 file, although I'm not clear on it.
Any advice/solutions/examples will be appreciated.
I don't have the exact solution, but you can try this http://learningsfromdotnet.blogspot.com/2011/11/playing-mp3-using-audio-tag-html-5-in.html.
I was trying to stream MP3 file from IIS server, had issue with Chrome because it makes a request with "Range" header. If you can make similar request with "Range" header and from server stream the piece of MP3, it might work.