The HLS streams do not play video, but they do play audio.
Device information:
Samsung Galaxy S5
Android 4.4.2 / Build KOT49H
Chrome 36.0.1985.131
HLS Streams that play on other Android builds and devices:
JWPlayer test videos do not play video:
http://www.jwplayer.com/html5/hls/
These Apple HLS streams also do not play video (but do play audio)
http://devimages.apple.com/iphone/samples/bipbopgear1.html
http://devimages.apple.com/iphone/samples/bipbopgear2.html
http://devimages.apple.com/iphone/samples/bipbopgear3.html
http://devimages.apple.com/iphone/samples/bipbopgear4.html
http://devimages.apple.com/iphone/samples/bipbopall.html
Using the browser application "Internet" on the Samsung S5, it will play the video for an HLS stream, which made me think this could possibly be an issue with Chrome, however, when tested on a Nexus 5 device with the exact same Chrome build (except Android 4.4.4) and the video plays fine.
Android Issue Queue has Issue 63810: No video in HLS live streaming on Android KitKat and I have contributed what I can.
What can I do to get more information about the nature of the problem?
Is this a legitimate bug with the Android 4.4.2 Samsung S5?
I've noticed this behavior among other issues on 4.4.2 with issues seeming to vary by device and manufacturer. Through experimentation I've noticed the following:
Entering or exiting full screen seems to reset the renderer. I suspect this forces the browser to create a new View or something
Reloading the video seems to help the renderer
Changing sources seems to make things worse
Our product works essentially on a playlist -- when the ended event triggers for one video we change the video src and call .load() and .play() to go to the next one. On some devices if the first src is HLS video plays fine, but if the first src is mp4 or webm then switching to HLS causes you to lose video. On other devices it's the opposite behavior -- starting in HLS fails but switching to it succeeds. On some devices HLS has video if you enter full screen before it starts to play, on others it only has video if you enter full screen after it starts to play. On some devices the full screen button disappears after you start to play.
It's not ideal and it's honestly very hacky, but I've come up with this ugly solution:
// 1.
video.addEventListener('click', requestFullScreen);
// 2.
function requestFullScreen() {
video.removeEventListener('click', requestFullScreen);
video.webkitRequestFullScreen();
}
// 3.
function reloadVideo() {
var ext = video.src.substr( video.src.lastIndexOf('.') ).toLowerCase();
if( ext == '.m3u8' ) {
video.load();
video.play();
}
}
// 4.
video.addEventListener('webkitbeginfullscreen', reloadVideo, false);
video.addEventListener('webkitendfullscreen', reloadVideo, false);
// 5.
video.addEventListener('webkitfullscreenchange', reloadVideo, false);
This is to fix the "full screen button disappears after you start playing on some devices" bug
We give this function a name so we can remove it later. If they request to exit fullscreen then they will not blame your player if the full screen button disappears. At this point they'll blame the phone and they'll refresh the page. This way people don't get pissed off if they accidentally fullscreen it again while trying to scroll
A helper function. We don't want to restart videos when going fullscreen unless we have to
The stock Internet browser throws these two events
Chrome throws this event
There are a number of other hacks I've had to implement, as well. For instance, the stock Internet browser on the Galaxy S4 does not always throw an ended event when reaching the end of a video. For this reason I have a setInterval checking every 1 second. If the video has moved less than 0.5 seconds in the last 1 seconds and it was never paused (I have a flag that's set in the resume and pause events) then assume you've hit the end.
I've had success using preload="none". Switching to auto will only play audio, using none will play both video and audio properly. This was tested on a Samsung S3, Android 4.4.2.
EDIT: autoplay also contributes to the problem. Removing it appears necessary.
Related
I have a server Icecast working with Liquidsoap to stream internet radio and I noticed there is a problem with receiving the music on some Android devices (Samsung Galaxy tab, for example) - after a few seconds of buffering of the music the playing of the music starts for about a second, then it abruptly stops, then there is a silence for a few more seconds, and only after that it starts playing normally. On some other Android devices, like HTC desire - no such thing occurs - music starts playing normally after the bufferization.
Here is the example of the stream in question: http://rdsradio.ru:8000/4th.mp3
That happens when I open the link in the browser (Google Chrome) on the Android device. With the same result I connected to the Icecast stream from the Android app, which I currently develop, using the android.media.MediaPlayer class: mediaPlayer.setDataSource("http://rdsradio.ru:8000/4th.mp3");
Also, even on those problem devices I could normally connect and listen the streams of other Icecast radio sources, like http://dancewave.hopto.org:9990/dance.mp3
- that is why I think there could be something wrong in my settings of Icecast + Liquidsoap - what makes that music stops playing in the beginning.
<burst-on-connect>1</burst-on-connect>
<burst-size>64000</burst-size>
I tried to change those parameters in /etc/icecast2/icecast.xml, like increasing the burst-size to 10-20 times or setting burst-on-connect to 0, but did not notice any difference at all (I run /etc/init.d/icecast2 reload after changing the parameters to reload the configuration).
Any idea - how to fix that behavior?
UPDATED: I tried to open the stream in VLC player on Android and it worked with no problem, so it seems the problem in using the android.media.MediaPlayer (probably the built-in HTML5 audio player in Google Chrome uses the same library). I will try to use a different Media Player in the app.
Actually, the solution was simple. The burst-size setting to 500000 in icecast.xml fixed the problem. Earlier I used /etc/init.d/icecast2 reload after changing the icecast.xml and for some reason I thought that the burst-size would also change in Icecast in the similar way, but it didn't happen. Only restart of icecast actually changed that setting.
I'm trying to embed an MP4 video in an Android Phonegap 2.9.0 application using the HTML5 video tag.
The application will be used at an exhibition and the video has to be played back offline on the device. The video also can't be played back in the native player as the back button will be locked, which I think rules out the VideoPlayer plugin (http://simonmacdonald.blogspot.ca/2011/11/video-player-plugin-for-phonegap.html).
I have set the hardwareAccelerated attribute to true, which should work on Android 4.x devices (see http://simonmacdonald.blogspot.co.uk/2012/10/partial-support-for-video-tag-in.html). I successfully got a video embedded and played back as desired from a folder on the SD card on a Motorola Xoom tablet (Android 4.0.4).
I then wanted to recreate the same on an Archos 97 Titanium HD tablet (Android 4.1.1), which will be the device used in the exhibition. Using the same code as on the Xoom (just with the folder path adjusted according to the device) the Archos tablet plays only the sound and the video itself stays black, apart from a line of changing pixels in the top left corner. If I switch to fullscreen mode the video plays fine.
Also if I stream the same video from a web server it plays back fine embedded in webview - again using the same code.
So it seems like it can cope with the video format and encoding in webview, but for some reason it does not work from the internal (or external) SD card.
Has anyone come across a similar problem and is there any solution?
Is there a problem version 4.1.1 of Android or is this likely to be an issue with the device itself?
I've an app that uses a Native Activity as it is mostly C++ code (cross platform).
I also need to play Video and Audio so have another Activity that uses MediaPlayer to play video and/or audio. This is used in conjunction with the Native Activity to play Video in front of the OpenGL rendered application.
The MediaPlayer activity is based upon that in the ApiDemos example, and works fine on MOST devices (Nexus 7/10, Galaxy S3/Tab2, even some low-cost devices like Fusion5).
BUT running it on a low-cost Scroll Plus 7" tablet - the code functions, but no Video is displayed.
The Audio plays, the Video Controls show and are usable.
NOTE: I have actually been able to hack with the code to get the Video showing - though this is not a solution it may help someone identify the problem.
In my Native Code where the Open Gl render calls eglSwapBuffers, if I comment this line out the Video shows. (I complete the rendering in a loop inside android_main)
Obviously this means my OpenGL Rendering that needs to go on in the background stops working, so I cannot fix it this way.
Device:
Scroll Plus
7" TABLET by Storage Options
Jelly Bean 4.1
From LogCat i believe it is running a CedarX-based Media Decoder/Renderer.
After 4 days on this issue, I've finally found out that the Video was being drawn BEHIND my OpenGL. Why only on this device I don't know. All the other aspects of the Video Activity (the controls etc) are in front where it should be.
The eglSwapBuffers was a red-herring, in that case I was not drawing anything to the screen.
When i run my application on the tablet(android) and hit the pause button it pauses the screen of the video but the video will jump a head how ever many seconds the pause when i un-pause the video. So if i start the video and then click pause and walk away i can come back and un-pause the video and it well jump right to the end.
The code i am using is ns.togglePause(); This same code works on the desktop and works with .flv and .f4v but will not work when i am using a mp4 on the tablet.
Has anyone seen this before or know why it would do something like this?
i am using flashdevelop to debug the application.
I found out that my problem is caused by encoding. This helped me solve my problem.I found this on adobes forms.
Video encoding is very important.
For example, use baseline profile level 3.1 for H264 for mobile
(and not High profile level 4.1 recommended for desktop).
For more information, see the MAX session of Fabio Sonnati:
"Encoding for Performance on Multiple Devices"
And if you have an Android phone/tablet, there is my AIR application
to watch Adobe MAX 2011 videos :
https://market.android.com/details?id=air.fr.inway.maxVideos2011
Search "Sonnati" for this session's video.
(For info, i use a video player based on OSMF 1.6)
The pdf presentation is available on Sonmati's blog:
http://sonnati.wordpress.com/
Ok. So there are a bagillion different Android devices. I have a video streaming service, works wonderfully for iOS. My app has a live video feature and a saved video clip playback feature (which streams to the device too). I've run some tests on different Android devices and get a whole bunch of different playback results. I am using a 640x480 h.264 base profile video. Streaming that video works only on some devices. For other devices, that same video stream can be made to stream at low resolution and that works on some devices, but still not others. The high profile streaming goes through http://www.wowzamedia.com/ (rtsp) and doesn't work on any Android device (but works on iPhone). The lowest and worst option is Motion JPEG, which works on all tested devices so far.
So my question is, how can I figure out (without having to test every device out on the market) if the device will play: 640x480 h.264 base profile - if that wont work then play the low resolution video - if that doesn't work, default to Motion JPEG.
Also, any idea why my rtsp transcoded through wowza works on the iPhone but not on any Android device (not even the Motorola Atrix)?
Streaming on android is an absolute mess. Most devices don't support anything higher than Baseline 3.0. If you encode for iPhone 3, it should generally work via RTSP. Newer versions of android support HLS, but it's hit or miss and largely dependent on specific devices.
I resolved this problem. Check RTP-realization in your streaming service and x264 profile. My RTSP-server works fine on 90% devices.
p.s
Some video frameworks in different Android versions can implement RTP and RTSP protocols with some differences.
These are some of the links/issues which I have come across, while trying to make streaming work in varied devices.
MediaPlayer seekTo doesn't work for streams
MediaPlayer resets position to 0 when started after seek to a different position
MediaPlayer seekTo inconsistently plays songs from beginning
Basic streaming audio works in 2.1 but not in 2.2
MediaPlayer.seekTo() does not work for unbuffered position
Streaming video when seek back buffering start again in videoView/Mediaplayer
Even the big shots in stackoverflow are wondering about this
If you want just streaming without seeking (which is lame), this can be achieved. But then if you receive a call while you are watching, you will end up from the start.