So I have an IP camera that outputs a video stream I can connect to via the rtsp protocol. I want to display this in my android application, so I've set up a videoview using the following code;
VideoView vv = (VideoView)this.findViewById(R.id.videoView);
Uri uri = Uri.parse("rtsp://username:password#192.168.0.1:554/1/stream3");
vv.setVideoURI(uri);
vv.requestFocus();
vv.start();
I'm putting this in the onCreate() of the main activity class, so when the app loads up it automatically connects and starts streaming. My experience with this is that it works - but eventually gets choppy and or just stops randomnly and doesn't seem to ever get back to running again. I have to close the app and clear it from memory and restart it to get it back - but then it loses connection shortly after, meaning its pretty much useless.
I also found it seemed to lag a bit when touching on the screen objects like menus or buttons but that might just be a coincidence - I can't say for sure.
The thing is the stream is perfect from a PC on the same network via VLC using the same URL. So what am I doing wrong, and is there any better method of handling streaming video? I ultimately wanted to mate the videoview with some overlaid text and buttons, and potentially take screenshots when necessary. At the moment I'm lucky if I get video for a few seconds before it cuts out...
Some additional comments;
I've had some success running it for a longer frame of time - so it's
not always bad which makes things difficult to diagnose. But when it stops it stops.
Does videoview actively try to reconnect if it has lost a connection?
Is there a way of demonstrating this with a progress indicator perhaps -
so it doesn't look like it's doing nothing?
Related
I have an app which plays a lot of video files. It's been all good on every phone and tablet I've tested on. I just tested on an Acer Chromebook and the first few frames (maybe up to a 1/4 second) are being dropped on all video files, so the video appears to start just slightly beyond 0. Some of the videos have audio that starts immediately and so it's obvious to the user that the video is clipped at the start. I'm wondering if anyone else has seen this issue, maybe on a Chromebook or other device and if there is some simple way to deal with it?
There is absolutely nothing fancy about my code. I'm using VideoView, preload the video with setVideoURI(), then call videoView.start() on a button press.
Thanks!
This problem only appears if I make a call to seek(0). So rather than doing that to replay the video I have to load the video each time it's requested. That workaround resolves the problem.
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 am relatively new to the Flex/Air application development.
I am involved in development of an app that transmits and receives the video stream.
The bug that I am working on now is on Android device, when you are rotating the screen during video being played, the video just freezes after rotation is completed.
The class that is used for video streaming is NetStream.
I am not quit sure which peace of code I need to post here since there are really a lot of code involved in this whole video part.
My first assumption is that in process of screen rotation, Flex/Air just kills my stream, but now sure if that's true.
So, I am just wondering if anyone else had problem with video during rotation.
We also have separate function for audio and during rotation audio works pretty well.
So please any ideas would be very helpful.
Have you tried pausing the stream before rotating and resuming after? You might also be able to save the current location of the stream and re-init the stream at that point after rotation. Just a couple of quick ideas.
I have an app that shows a dancing toy in a VideoView at full screen. Sometimes another video executes over the video of the toy, in this case i have problems with the view because the video of the top shows transparent.
If i set vid1.stopPlayback(); before call the second video, it works, but i cant reproduce the first.
Is there some way to play both videos at same time?
I am not fully certain, but I got a feeling I've read simultaneous video playback may not be possible due to the way it is rendered on the screen. I can't find where I read about this, but you may try searching that way though.
I'm having problems with seeking video.
My application should resume video from place where it was stopped last time. So I do this:
videoView.seekTo(bookmark);
videoView.start(); However when it plays I hear sounds form beginning of video for about 1-2 sec. And only after that video seeks to the right position. This behavior is reproducible on HTC Nexus One, HTC G1, HTC evo. But on Samsung galaxy tab all plays normally. Anybody had similar problems? Is this bug HTC-specific? Thanks in advance.
It is definitely not specific to your phone. I am having the same issue on an HTC Incredible. The seekTo works but there is an audio glitch from the beginning of the clip. Based on the results trying to implement the custom VideoView I guess I won't go to the trouble. I am now going to see if I can mute the very beginning of the clip. I'll report back here if I succeed.
Well, I have given up on this. The only way I have found to mute the beginning of the clip is to mute the phone entirely, which would mute the background music as well. I will assume that this will be fixed sometime in the future since this is a known issue:
http://code.google.com/p/android/issues/detail?id=9135
Issue 9135: MediaPlayer/VideoView and SeekTo before initial playback starts from beginning for few millisecs
I guess that can be a reason:
from api doc
Although the asynchronuous seekTo(int) call returns right way, the actual seek operation may take a while to finish, especially for audio/video being streamed. When the actual seek operation completes, the internal player engine calls a user supplied OnSeekComplete.onSeekComplete() if an OnSeekCompleteListener has been registered beforehand via setOnSeekCompleteListener(OnSeekCompleteListener).
now Videoview does not have OnSeekCompleteListener exposed and it sucks, but Videoview is just a wrapper class for Mediaplayer and SurfaceView