I wonder what is the best option to store a single picture and short voice memo in one file? That needs to be openable by mobile phones in browser (iOS, Android) and preferably be shown as a single full screen photo and sound playing in background.
Effectively i'm looking for a most size efficient combination of something like MP3 + JPG.
If i do it in a single .mov i guess i loose a lot of space due to compression of each and the same frame 24 frames/second.
A rough list of options which comes to mind:
.mov
Mpeg4
H.264
QuickTime
HTML5 video format (Theora?)
store it in Flash (but this is not supported by iOS)
EDIT1:
tried storing h.264 in .mp4 container, files are small enough (around 1Mb), but somehow it does not work on an Android phone of my friend. Probably i need more testing, but it seems Android OS does not like proprietary codecs...
My most intuitive solution for this would be to store a JPEG and an MP3 separately on the server. To download one entity as a single unit, download a bit of JSON or XML data that contains pointers to the picture and the audio file.
If you are set on having one file do the job, you might try embedding the JPEG inside the ID3 metadata of an MP3 file (this type of metadata functionality exists to, e.g., store album art with a music file). You would want to make sure that the ID3 tag is near the start of the file. JavaScript within the mobile browser could fetch the file, a third party library could do the ID3 parsing (some Googling reveals that such libraries exist; don't know if they all support fetching a JPEG image). Then the JS would need to be able to feed the file into an audio tag for playback, which I'm not sure is possible.
Another thing to experiment with is a .MP4 which encodes the audio track along with a single video frame with a really, reeeaaallly long duration. You would have to experiment to determine if the mobile browsers handle that gracefully while also allowing smooth audio seeking. If they don't, then perhaps re-encode the frame with every 1-5 seconds to keep the bitrate minimal.
Related
Currently, I have been making streaming video player app. so for that reason I want to use dash streaming. I have a normal URI of video from my firebase storage. but for dash streaming, I think I need a file that ends with .mpd.
ExoPlayer player = new ExoPlayer.Builder(context).build();
player.setMediaItem(MediaItem.fromUri(**dashUri**));
player.prepare();
what I have to do to convert normal to URI which ends with .mpd.
So, how can I do that?
You actually have to covert the video file to a fragmented format and typically will want to make it available in multiple bit rates, which means transcoding it also.
The reason for this is that DASH is an ABR protocol - it breaks multiple renditions of a video into equal size, time wise, chunks and the player can then request chunk by chunk, choosing the best bit rate version of each chunk depending on the current network conditions and the device type.
See here for more info: https://stackoverflow.com/a/42365034/334402
Open source tools exist to create DASH files from mp4 - see some examples here (links correct at time of writing):
https://github.com/gpac/gpac/wiki/DASH-Support-in-MP4Box
https://www.ffmpeg.org/ffmpeg-formats.html#dash-2
My android app plays videos in Exoplayer 2, and now I'd like to play a video backwards.
I searched around a lot and found only the idea to convert it to a gif and this from WeiChungChang.
Is there any more straight-forward solution? Another player or a library that implements this for me is probably too much to ask, but converting it to a reverse gif gave me a lot of memory problems and I don't know what to do with the WeiChungChang idea. Playing only mp4 in reverse would be enough tho.
Videos are frequently encoded such that the encoding for a given frame is dependent on one or more frames before it, and also sometimes dependent on one or more frames after it also.
In other words to create the frame correctly you may need to refer to one or more previous and one or more subsequent frames.
This allows a video encoder reduce file or transmission size by encoding fully the information for every reference frame, sometimes called I frames, but for the frames before and/or after the reference frames only storing the delta to the reference frames.
Playing a video backwards is not a common player function and the player would typically have to decode the video as usual (i.e. forwards) to get the frames and then play them in the reverse order.
You could extend ExoPlayer to do this yourself but it may be easier to manipulate the video on the server side if possible first - there exist tools which will reverse a video and then your players will be able to play it as normal, for example https://www.videoreverser.com, https://www.kapwing.com/tools/reverse-video etc
If you need to reverse it on the device for your use case, then you could use ffmpeg on the device to achieve this - see an example ffmpeg command to do this here:
https://video.stackexchange.com/a/17739
If you are using ffmpeg it is generally easiest to use via a wrapper on Android such as this one, which will also allow you test the command before you add it to your app:
https://github.com/WritingMinds/ffmpeg-android-java
Note that video manipulation is time and processor hungry so this may be slow and consume more battery than you want on your mobile device if the video is long.
I've been exploring the documentation and examples at http://bigflake.com/mediacodec/ by Fadden, and applied patch http://bigflake.com/mediacodec/0001-Record-game-into-.mp4.patch to the breakout game. Unfortunately, after compiling the code, I realized it doesn't work, producing video files that aren't streamable.
I see the following error:
"The mp4 file will not be streamable."
According to Fadden, this should be fixed by checking the mBufferInfo.flags (https://stackoverflow.com/questions/23934087/non-streamable-video-file-created-with-mediamuxer), which is already done in his code, so I'm at a complete loss. Did anyone else get the video recording patch to work?
The warning you're seeing is just a warning, nothing more. MP4 files aren't streamable anyway in most cases, in the sense that you would be able to pass the written MP4 over a pipe and have the other end play it back (unless you resort to a lot of extra trickery, or use fragmented MP4 which the android MP4 muxer doesn't write normally). What streamable means here is that once you have the final MP4 file, you can start playing it back without having to seek to the end of the file (which playback over HTTP can do e.g. with HTTP byte range requests).
To write a streamable MP4, the muxer tries to guess how large your file will be, and reserves a correspondingly large area at the start of the file to write the file index to. If the file turns out to be larger so the index doesn't fit into the reserved area, it needs to be written at the end of the file. See lines 506-519 in https://android.googlesource.com/platform/frameworks/av/+/lollipop-release/media/libstagefright/MPEG4Writer.cpp for more info about this guess. Basically the guess seems to boil down to: "The default MAX _MOOV_BOX_SIZE value is based on about 3 minute video recording with a bit rate about 3 Mbps, because statistics also show that most of the video captured are going to be less than 3 minutes."
If you want to turn such a non-streamable MP4 file into a streamable one, you can use the qt-faststart tool from libav/ffmpeg, which just reorders the blocks in the file.
You can check Intel INDE Media for Mobile, it allows to make game capturing and streaming to network:
https://software.intel.com/en-us/articles/intel-inde-media-pack-for-android-tutorials
simplest capturing:
https://software.intel.com/en-us/articles/intel-inde-media-pack-for-android-tutorials-video-capturing-for-opengl-applications
youtube streaming:
https://software.intel.com/en-us/articles/intel-inde-media-pack-for-android-tutorials-video-streaming-from-device-to-youtube
I want to write an app on Android to record snoring sounds of a sleeper and analyze it afterwards (i.e., not in real-time) for signs of a medical condition called obstructive sleep apnea.
The Android devices I've experimented with have voice recorders that produce a file format called .3ga. I want to programmatically read in the audio file and look at the amplitude for each individual time-sample. Then I can analyze that for patterns. Would this be easier if I converted this to a different format, e.g., MP3, and if so how can I do that programmatically?
I did a Google search on this and most of the hits seemed to be related to audio recording or playback which are unrelated to what I'm trying to do. I haven't coded anything yet because I don't know how to get started.
You are looking to do sample-based analysis on a raw audio signal, but the formats you mention are compressed. You will need to either deal with raw samples directly, or decompress the audio and then analyze.
Since you said you can do this work after-the-fact, why not upload to a server and analyze there?
In my app I need to play videos from sdcard. Now it works fine on Galaxy S,Galaxy Tab2, But on some chinese tab Like "Giada" It is not working at all.
I have 4 different activities to play videos like. First activity plays a menu video which has navigation link to other activity. Problems I am facing.
First Video plays properly but looping failed and app closed.
If I navigate to other activity to play another video it says "Can't Play Video" and closed Some time it plays same video but not complete and closed app in between.
Video Extension: MP4
Resolution : 1024x600
Playing From : SDCard.
Target Tab Specification.
Resolution : 1024x600
Android :4.1
Tried with Video View and SurfaceView.
Help me out any help will be regreted.
The answer to this question will never be consistent across all devices or across all videos.
Whether a given video file will play in a given player depends on three things:
The video container format (file type).
The codecs the video (and potentially audio) streams are encoded with
Your player's support for that combination of container format and codec
The codec and player/device support for it is almost certainly the cause of the inconsistent results you've seen. (A codec, if you didn't know, is basically a repeatable mathematical formula that tells your system how to turn bits and bytes packed into a file into moving pictures(and back again, for that matter))
There are a large variety of video codecs in the video files floating around out there. Support for these codecs is wildly inconsistent just due to the history of video distribution. Many devices won't support streams encoded with certain codecs. There are a variety of reasons for this, but the most common are obscurity or licensing costs.
For example, up until a few years ago, almost everything was encoded in an .FLV container with an On2 VP6/VP7/VP8 codec. This is causing headaches today because while On2 owned these codecs, they kept a tight rein on the licenses. That didn't relax until .FLV had already begun to lose relevance, and so there is not a whole lot of (legitimate) software out there that can work with On2-encoded content.
What all of this means is that there is no silver bullet. All video will never run on all devices, at least not without the aid of video players that install and use their own codecs to decode the streams.
Needless to say, this does not include the libraries provided to you and your end users by the factory-installed Android libraries.
So, what do you do? Well, short of producing a video player that carries its own codecs, you can most effectively address the problem with a two-step approach:
Target specific devices that you want your application to work on
Encode your content to use use a video codec that works on all the devices you want to target. You may need to produce two copies of your video if you find that there is no codec that works across all devices you plan to support.
Today, the widest support is available with an MP4 container and a video stream encoded with the H.264 (AVC) codec. As I said, there is no silver bullet, and H.264 support is not universal by any means, but this one format will be playable more potential users than any other single choice you could make, due to its popularity and wide support in modern desktop and mobile environments.
Some tools you may find helpful:
MediaInfo will let you peek inside MPEG-flavored video containers to see what codecs are in use. This will be helpful in determining which devices are having trouble with which codecs.
FFmpeg is an encoding application that can convert your content to MP4/H.264
Android Supported media formats
List of supported media audio/video formats.
Good luck!