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-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to