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]<javascript:>> > 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]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > 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] <javascript:>. > > > 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.
