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 <[email protected]> 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 <[email protected]> > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > 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 [email protected]. > > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
