jfb_mdialog
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-10-2013
09:24 AM
Custom controls for roVideoPlayer
Hi, all,
I'm working on updating a couple of custom channels, and I need to add custom controls and behavior to the video playback component. I'm not familiar with Brightscript, so I was wondering if anybody had a pointer to some code I could crib -- setting up the player state machine, handling exceptions, &c. I've looked through the examples on the Roku Developer site, and there's nothing there that paints custom player chrome.
Any/all info is welcome.
Cheers!
I'm working on updating a couple of custom channels, and I need to add custom controls and behavior to the video playback component. I'm not familiar with Brightscript, so I was wondering if anybody had a pointer to some code I could crib -- setting up the player state machine, handling exceptions, &c. I've looked through the examples on the Roku Developer site, and there's nothing there that paints custom player chrome.
Any/all info is welcome.
Cheers!
4 REPLIES 4


Roku Employee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-10-2013
11:01 AM
Re: Custom controls for roVideoPlayer
This should get you going in the right direction: http://blog.roku.com/developer/2012/10/ ... eo-player/
jfb_mdialog
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2013
01:54 PM
Re: Custom controls for roVideoPlayer
Thanks, that was a start.
I've got my controls showing up and the state machine for trick mode finished, but I'm having two problems. One's just a documentation searching failure: I've painted stuff onto an roImageCanvas, and I can't clear the canvas. At all. I've tried clear(); clearLayer(); show(); all with sleep() in between. But nothing serves -- the canvas is preserved even across quitting the channel and restarting it. I've even added a button with addButton() in the debugger, and the button persists, even across channel installs! What's going on here?
The second problem is much scarier and more fundamental; I'm implementing new controls, and the functionality I need is, for instance, when the user pressed fast forward, the video player should pause (ok, simple enough), and a progress bar indicating where in the program the viewer is should be shown (again, easy enough), and then be updated, until the player state changes. My issue is that I do not have the ability to reuse my existing event loop, as once the player is paused, there are no more messages being received.
My main loop looks like:
I've updated it to:
The problem here is that no matter how small a quantum I use in the sleep, I'm still going to miss events, right? They don't stack? There's no way for me to inject timing messages into my event loop, right? Even if I had write access to that port, I wouldn't be able to have something firing off on a separate thread/proc of execution dumping new events into the port every e.g. 100ms.
Is this the sort of problem that can be solved in BrightScript?
I've got my controls showing up and the state machine for trick mode finished, but I'm having two problems. One's just a documentation searching failure: I've painted stuff onto an roImageCanvas, and I can't clear the canvas. At all. I've tried clear(); clearLayer(); show(); all with sleep() in between. But nothing serves -- the canvas is preserved even across quitting the channel and restarting it. I've even added a button with addButton() in the debugger, and the button persists, even across channel installs! What's going on here?
The second problem is much scarier and more fundamental; I'm implementing new controls, and the functionality I need is, for instance, when the user pressed fast forward, the video player should pause (ok, simple enough), and a progress bar indicating where in the program the viewer is should be shown (again, easy enough), and then be updated, until the player state changes. My issue is that I do not have the ability to reuse my existing event loop, as once the player is paused, there are no more messages being received.
My main loop looks like:
while true
msg = wait(0, m.messagePort)
...
I've updated it to:
while true
msg = m.messagePort.getMessage()
if msg = invalid then
m.updateUI()
sleep(some_small_quantum)
...
The problem here is that no matter how small a quantum I use in the sleep, I'm still going to miss events, right? They don't stack? There's no way for me to inject timing messages into my event loop, right? Even if I had write access to that port, I wouldn't be able to have something firing off on a separate thread/proc of execution dumping new events into the port every e.g. 100ms.
Is this the sort of problem that can be solved in BrightScript?

TheEndless
Channel Surfer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2013
02:26 PM
Re: Custom controls for roVideoPlayer
"jfb_mdialog" wrote:
The problem here is that no matter how small a quantum I use in the sleep, I'm still going to miss events, right? They don't stack?
Events queue up, so you'll never miss one unless it's sent to a different port that you're not listening to.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
jfb_mdialog
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2013
02:30 PM
Re: Custom controls for roVideoPlayer
"TheEndless" wrote:"jfb_mdialog" wrote:
The problem here is that no matter how small a quantum I use in the sleep, I'm still going to miss events, right? They don't stack?
Events queue up, so you'll never miss one unless it's sent to a different port that you're not listening to.
That's one fewer thing to worry about, then. Thanks.