Re: [android-developers] Video streaming plus UI control update thread
Piren,
Thanks for taking the time to respond. I was able to figure out the problem…but I can confirm that Thread with sleep is bad. Handler is the right approach — I had something (not obvious) several layers deep in the call chain which was causing the problem.
Thanks again for your help.
Cheers,
Brad
On Nov 10, 2013, at 12:55 AM, Piren <gpiren@gmail.com> wrote:
I've done it and have had no issues what so ever (using a surfaceview).Regarding your code, your first approach (thread with sleep) is horrible, don't ever do that for any reason :) The second approach is the correct one which i have used myself with no issues.Since i see no reason why it would affect your playback like so, i suggest you just profile your app and see exactly what calls cause the slowdown.
On Saturday, November 9, 2013 5:03:07 AM UTC+2, Brad OHearne wrote:Wasn't able to get a response on this after a few days, so perhaps I'll try to frame it another way. If you:
- Have created custom controls for a video player
- Are familiar with the proper / conventional approach to updating UI controls every second / sub-second as in these kinds of apps: stopwatch, clock with second hand, video player with seek bar, music player, etc.
- Have done any background threading with regular updates to UI controls
I would love to hear from you on what worked for you, or even if you couldn't get it working, what did not work for you. Any information at this point will help narrow down the problem — the use case is very simple — update the play time on a video player every second without killing the streaming video performance.
I would love to hear from you.
Thanks,
Brad
On Nov 4, 2013, at 2:56 PM, Bradley O'Hearne <br...@bighillsoftware.com> wrote:
> Hey there,
>
> I hope everyone's week is off to a good start!
>
> I have a pretty simple use case: I am playing video streamed across the network in an app, and I need to update two SeekBars every second, one which tracks the video's timecode while playing, and the other which tracks the device volume. Simple enough, gun up a background thread, and update both every second (given that to my knowledge, I can't have the system call a listener specific to either of those functions. In a nutshell, the video streams just fine when this control-updating thread isn't running, but when it is running, the video is so chunky and slow, and audio garbled, that it isn't watchable.
>
> First, the video display is accomplished using a TextureView in combination with a MediaPlayer (the reason is that the TextureView allows scrolling / movement, SurfaceView does not). Second, I have tried a couple of different approaches for the background thread:
>
> a) I have tried a Runnable in a new Thread which updates the SeekBar controls inside of a runOnUIThread — this keeps a looping background thread and updates the controls on the UI thread, as such:
>
> new Thread(new ManagementRunnable()).start();
> ...
> public class ManagementRunnable implements Runnable
> {
> public void run()
> {
> try
> {
> updateControlState();
> Thread.sleep(1000);
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
> }
> }
> }
> ...
> public void updateControlState()
> {
> runOnUiThread(new Runnable()
> {
> public void run()
> {
> // update the timecode SeekBar
> ...
> // update the volume SeekBar
> ...
> }
> }
> }
>
> b) I have also tried using a Handler, where it runs on the UI thread, as such:
>
> new Handler().post(new ManagementRunnable());
> ...
> public class ManagementRunnable implements Runnable
> {
> public void run()
> {
> try
> {
> updateControlState();
> handler.postDelayed(this, 1000);
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
> }
> }
> }
>
> public void updateControlState()
> {
> // update the timecode SeekBar
> ...
> // update the volume SeekBar
> ...
> }
>
> The problem is, the result is the same regardless of which approach is taken — the video is unwatchable. I have tested this on a Samsung Galaxy S2 Skyrocket, and in the simulator. I've Googled this a fair amount, and it appears that the approaches above are generally the recommended approach. While video decoding and playing isn't exactly a cheap operation, I'm a little surprised that accommodating a once-per-second update brought the app to its knees, given nothing else taking place in the app.
>
> If anyone has any insight, I would really appreciate it.
>
> Thanks,
>
> Brad
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out .--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home