What would prevent the developers from building encoding (h.264 mp4) into Channels DVR? I know nothing about this, maybe it's a staggering amount of work so please forgive my ignorance. Recordings in mp4 format would be significantly smaller and devices like Roku can play them with ease (dare we hope for an app on the most popular streaming device on the planet?). I know the team here is small, I'm just wondering in terms of growth/roadmap if this is on the radar?
Feel free to search around on this. There is a roku app out there but it is not being developed any further. It was an experiment and the devs didn't like the roku dev environment. The roku app works for very basic functionality and that is all it will do for the foreseeable future.
I'm aware of that very old thread. The Roku app is fairly unusable. My understanding is that Roku couldn't handle playing the media content. But Roku does play in MP4 format very well. And MP4 would save us all a ton of HDD/SSD space. So, why not kill two birds with one stone and have channels encode it's recordings in a format that saves space and is compatible across many streaming devices.
I get that this is a niche dvr product but it's AWESOME and in a world where cord cutter is accelerating, it seems like a wise business plan to make the product a) much easier to use and b) compatible across many other devices.
Whatever you would gain on MP4 client flexibility, you would lose on the complications (and I'm guessing cost) of decoding/encoding/etc MP4 across multiple DVR platforms.
Maybe the number of client-only users (i.e. not DVR), ASTC3 for OTA, and the possible sunsetting of cablecard makes this viable, but it's a big rock to move.
Channels DVR Server transcodes on the fly already. It does it for out of home streaming. It does it with variable bitrate based on your connection speed. It works great.
Any Roku client would have to ONLY use transcoded video locally. This means it will lose out on the fast tuning time that Channels has, which is one of the things that Channels fans love the most. So right out of the gate, the Roku client will lose one of the top Channels features.
It doesn't mean we're not willing to do it. But building an entire Roku client from scratch to be as good as what we've built over years...is a lot of work. And knowing that it will be crippled out of the gate and not have one of our biggest features is a bummer.
We haven't ruled out a Roku app, for as you said...it's a hugely adopt platform (even if we mostly hate it 
), but it's a huge undertaking and it will have to come when we're prepared to go all in on it.
1 Like
This is an excellent reply. Thanks for helping me understand your thinking. I, too, love the quick tuning. Hadn't considered the out of home streaming and built in transcoding - that makes sense.
Curious what you don't like about Roku. I've used virtually every streaming box out there and, as an end user, it's by far the best. Is that you don't like it as a user or as a developer or both?
Another question - since I have your ear for a moment - what's the road map right now? Other than bug squashing, what does the Channels team have at the top of it's list. New features/functionality? More platforms? What do you all see as your growth opportunities?
1 Like
To me, when using a Roku, it feels like I'm using something from 1999. It's not fun, it's boring, it doesn't feel like a modern system, and more and more it's filled with ads. I don't love ads.
As for a roadmap, we don't actually discuss that. We're happier to ship stuff early into beta and talk about things that actually exist, then ship it out.
1 Like
I see you point on both fronts. As a consumer, it's nice to know what's on the horizon. I get that it's easier (and often better) to promise nothing, then over deliver (my work isn't entirely different, I get it). Anyway, thanks for a great product at a fair price. It's a rare thing.
2 Likes
I like the discussion, and think many people would like to understand more about how much delay we'd have to endure to always transcode. Since it's a recurring question on here of how to enable PiP on iOS and tvOS devices, if the Devs could give an idea of whether it's half a second, or 5 seconds delay to start transcoding, it might help people grasp why you have stuck to the native formats.
There could be side benefits to the always transcoding, like reducing bitrate for those with poor wifi. If it's not a huge undertaking to make it a setting to turn on /off, maybe people could choose for themselves which benefits they care about most.
Client based transcode decisions should be as easy as IF playerClient=Roku then Transcode = TRUE. Right ?
If you're curious about life with just transcoding, just turn it on on your client.
Set Quality for Home to a specific bitrate instead of Original.
1 Like