"kbenson" wrote:
I've often wondered why more developers don't take advantage of the video overlay capabilities.
"TheEndless" wrote:"kbenson" wrote:
I've often wondered why more developers don't take advantage of the video overlay capabilities.
I imagine it's because it requires the UI to be completely custom drawn, even down to the buffering bar. The Crackle channel does that, as does my Jewelry TV channel, and, of course Hulu Plus, but it's an awful lot of extra work for very little additional utility. It also presents a foreign UI to the end user, which may or may not be desirable from a support perspective.
"retrotom" wrote:"TheEndless" wrote:
I imagine it's because it requires the UI to be completely custom drawn, even down to the buffering bar. The Crackle channel does that, as does my Jewelry TV channel, and, of course Hulu Plus, but it's an awful lot of extra work for very little additional utility. It also presents a foreign UI to the end user, which may or may not be desirable from a support perspective.
I would agree with TheEndless here. We are/were doing this in Gabby. Using roVideoPlayer has its challenges. You will have to reinvent everything that the SDK gives you with roVideoScreen. You will lose (potentially) critical time just to create a buffering/loading screen. We still don't have a screen overlay for seeking. The tiniest things that are part of the user experience will cost you time better spent on other features. If you can avoid it, do so.
"kbenson" wrote:
I was thinking more from the point of view of doing it well once, and reusing the code elsewhere. If done right, it could add quite a bit of polish to a channel, and really differentiate it from the rest. Then again, I have little to no experience with video channels, so all I can do is imagine. 😉