I have been using media player from last 2 months with normal mp3 files.Few days back my client gave me 16kbps converted low quality files. When I played these files through Media player class.The behaviour which I observed is mentioned below:
(1) mediaPlayer.getDuration() is giving extra duration. For example : If it's 46 sec then duration is returned as 86 sec.
(2) mediaPlayer.seekTo(positionToNavigate) is not working properly and sound position is totally different than original.
I have tried to fix above things many times with different codes but these 2 problems are still there. When I play an MP3 file without conversion like normal quality 128kbps+, the sound and the seekTo work normal.
I want to mention that it is necessary to use low quality MP3 because it has small size and fast downloading from server.
If the issue is encoding/compression, is there other way to compress an MP3 with 16kbps?
Related
I am creating a video using an Android app and after this mp4 Video File is created it does not play back properly. The audio will play over a still frame from the video and then once the timer reaches the end then the video will play several moving frames.
This issue is only occurring when I create the video on a Samsung Galaxy S7 and not on any other phones.
I am not experienced in video file encoding so I do not even know where to start with debugging what is wrong with the file. If someone could explain what causes something like this That would be amazing
The first video sample decode time in your file is 1506981408/90000 - which is giant - about 4.5 hours into the stream.
So the entry is obviously bogus.
Hard to say where is bogus decode time is coming from - may uninitialized memory of some sort.
See 'stts' box offset 1052223 - first array entry.
I corrected your video and put a copy here: https://drive.google.com/open?id=0B1K1m-YmE28DMXdFemZKbXg0WFk
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
So I have an app where mp3 file is being played using the MediaPlayer. On most devices everything is fine but on Samsung and some other (like HTC One S) devices the same mp3 plays "too fast" (skipping gaps): looks like player does not handle sound gaps (silence) correctly. These mp3s are just speech and speech naturally has gaps (silence) between spoken words. And these gaps are not played correctly in terms of time - MediaPlayer just skips them. As result mp3 is played faster by the duration of all gaps it contains.
What could be a reason and solution for this?UPDATEI'd found that its about frequency+VBR. Somehow if mp3 is of 22050/24000/32000 Hz instead of 44100 or 48000 and VBR or ABR is used the issue raises up. Im using LAME for mp3 encoding. If I remove "--resample 22.05" option so the resulting mp3 becomes 44.1kHz there is no issue playing this mp3 on samsung phone. However the resulting size of mp3 becomes twice bigger which is not acceptable for me cuz in this case my apk becomes bigger than 50Mb. So now the question is how to properly compress mp3 as 22kHz/VBR/MONO.
The issue was fixed in the following way: I added a white noise to an original sound and then encoded it to MP3 format. Resulting files became bigger in size but also they become more compatible (with Samsung devices) The original audio file (made at recording studio) is too clean meaning that silence/pauses in speech (between pronounced words) has no waveform if look in sound editor, its like an ideal silence. So on variuos Samsung devices such MP3-encoded files played with described issue. However on most other devices and PCs such MP3 files played just fine. Once again - Samsung "rules"!
You need to Google our for controlling playback speed in your application I mean to say that there must be some sort of 'playback rate' variable which must be a floating point value something between 0 to 1. This might help you in some workarounds for your app hope you find this somewhat helpful in anyway . O by the way here are some useful links that might help you out as well and if not then we have to keep waiting in the waiting queue for Samsung ;-) if its specifically related to them happy coding
http://code.google.com/p/android/issues/detail?id=1961
play an mp3 with MediaPlayer class on Android issues
Regards
Anas.
Working on an Android app.
I need to record video continuously.
But the video files can only be N seconds long.
I have it working so far, and the files are being created properly. However, the time it takes to stop the MediaRecorder and start it back up again with a new file handle, I lose 2 seconds between stop/start.
Is there anything procedure-wise that I can do to mitigate this delay? I'm recording in mp4 format so I'm suspecting I can't just force a "move" on a file on the filesystem since the video needs to be packaged properly using the mp4 encoding.
Anyone know, roughly, how I might go about this?
Thanks!
I'm trying to create an app to stream live TV. Currently the problem I'm facing is that after say 10 minutes of playing, the video will freeze but the audio will carry on. This is on a 1.3mbps stream. I also have lower streams, such as a 384kbps stream, that might last an hour or so, but will still do the same. I've tested this with a local video, that is high quality (file size is 2.3gb) and that has no lag and doesn't freeze at all, so it must be something to do with the way HLS is streamed to android.
Does anyone have any idea on how to solve this problem?
Thanks