top | item 38321371

TV: Now What?

80 points| ingve | 2 years ago |commonsware.com

159 comments

order
[+] jmbwell|2 years ago|reply
The fragmentation is both a flaw and a feature. It means we have diversity in media vendors, at the cost of a pretty high cognitive load to just watch something… which app is it on? What’s the account login? Search the device main search, then go to each app and do its own individual search. All while dodging ads and autoplay and “what’s new” and “for you.”

It sucks for users. But it also sucks for developers, who have to maintain multiple apps for multiple platforms, even multiple generations per platform. And this affects users too, when a version of an app eventually gets dropped because the developer decides it’s too costly to maintain.

The diversity and competition is good, but there’s got to be a better way. The AppleTV platform makes some effort to bridge the gaps, but apps have to play along, and many decide to roll their own instead of using the provided APIs, complaining about the APIs not letting them do what they want to do the way they want to do it. To which I say, getting all these apps to do something in a consistent way is the point.

But whatever. I’m in no hurry to go back to huge cable bills. We told the industry to get on board with streaming if they don’t want piracy, and they did, so now here we are. Instead of digging through BitTorrent and newsgroups, we are juggling apps. ¯\_(°_o)_/¯

[+] Osiris|2 years ago|reply
“Huge cable bills” - we’re already back there. Netflix is $23, Apple TV just increased to $10c Disney+ is now $14, Hulu is $20, Max is $16, Paramount is $10, Peacock is $6.

You can easily spend $100 /mn on streaming services.

[+] hotnfresh|2 years ago|reply
> The fragmentation is both a flaw and a feature

It’d be purely a feature if we banned shared ownership of distribution and production, like we did with movie studios and movie theaters for decades.

[+] 01100011|2 years ago|reply
I'd love to see the feds step in and force content providers to make their content available to anyone willing to make a compliant (sorry, DRM likely required)frontend. I should be able to buy content from, say, Paramount using Hulu and not be forced to use Paramount's app.
[+] hakfoo|2 years ago|reply
The answer is mandatory licensing. Maybe permit some limited ability to offer a very narrow window of exclusivity (weeks, not years) in exchange for getting a lower rate later (because we should treat attempts to wall off parts of shared culture as a an antisocial act, rather than a nifty business model.)

Every platform can have everything, at a predictable standardized rate card, so they can compete on their own merits:

* We have the best CDN/apps/software support * We have a better recommendation/discovery experience (which could include "positive curation" like "we could license everything, but our niche is Namibian Sitcoms From 1983, so we won't") * We'll cut corners (lesser encoding quality to save disc/bandwidth, or no bespoke speculative content creation) to deliver the cheapest possible experience.

The "content people" and "tech people" come from different universes with different skills and expectations, and having to wrangle the two into individual platform teams helps nobody.

[+] cherrycherry98|2 years ago|reply
I would like to see a standardized streaming protocol be developed. That way there can be a market for the client side (different apps that organize content you've subscribed to) and for the server side (like web servers are commodities). It would eliminate content providers having to roll their own streaming back ends and front end apps for so many platforms.
[+] Aerbil313|2 years ago|reply
The fragmentation is a phase until the industry matures. Take a look at other industries, like woodworking. They have established practices which don’t change much.

The software industry has so much potential I don’t expect it to mature for another hundred years. Although some patterns are emerging, like strong typing and universal cross-platform runtimes (most notably Web).

[+] c0wb0yc0d3r|2 years ago|reply
> It means we have diversity in media vendors, at the cost of a pretty high cognitive load to just watch something… which app is it on?

So do you have a YouTube, Spotify, and an apple music sub?

When it comes to music, I'm not sure I've once thought "which app?"

The only reason the consumer has to think about it is greed.

For something like this, I'm not sure I'll ever buy a streaming device with a JavaScript interface. Steam has one, and it's slower than the old one by far.

Who am I kidding, I'm not gonna buy it because I don't need Amazon "sidewalk"

[+] m463|2 years ago|reply
> huge cable bills

now we have to pay for the internet + streaming service(s)

and most "big" internet providers keep increasing their prices.

[+] jncfhnb|2 years ago|reply
The answer is streaming sites like SFlix
[+] StableAlkyne|2 years ago|reply
I wonder if anyone is saving statistics on torrent traffic. It was huge in the 00s, then dropped as streaming became a thing.

Now that the companies are back to rent-chasing (it's abhorrent that some of them still show ads even when you pay), it would be interesting to see what the numbers look like. Could be cool to compare to music, because Spotify and Pandora have been relatively not scummy.

[+] geerlingguy|2 years ago|reply
Plex, Jellyfin, LibreELEC, Kodi... those are the best solutions for those wanting to manage their own destiny and TV experience.

You can run them on practically anything and there are Tiny PCs, stick-form-factor Raspberry Pi devices (like CM4 TV Stick), and other silent small boxes you can attach to a TV for a thin client interface or just a shared media library / TV experience.

It'd be nice if Amazon, Apple, Netflix, et all had integrations though, besides wrapping a browser window.

[+] foobiekr|2 years ago|reply
The Jellyfin user experience would be a ton better if the client app for the iphone/ipad actually took advantage of local playback instead of relying on transcoding. Random seeks, rewinds, and especially subtitles timing are all better if the client is just accessing a file stream. This is especially true as the codecs change and the on-NAS GPUs fall behind due to the lifecycle differences.
[+] slothtrop|2 years ago|reply
Since all of these streaming platforms are available on the browser, it should be trivial to run this through a pc/pi even without API support, if a little cumbersome. SHould also run faster than the ad-ridden software on Firestick/Chromecast/Apple-tv.
[+] barbazoo|2 years ago|reply
> Plex, Jellyfin, LibreELEC, Kodi... those are the best solutions for those wanting to manage their own destiny and TV experience.

As long as one produces their own content, right?

[+] scarface_74|2 years ago|reply
You can’t run Plex well on just about anything if you need to support transcoding
[+] ggm|2 years ago|reply
So hear me out, I have this crazy idea.

For all the people who can't afford OTT services like hbo and Netflix and prime and apple tv, how about we remove all the excess IP overhead and send the mp4 over broadcast RF using a band like 700mhz from local hills or if need be make towers. We can pay by watching ads or something.

I mean sure, call me crazy, imagine everyone having to watch the news and movie at the same time, neat right? Wouldn't that be cool. Hell we could probably even send about 5 or so different signals out.

[+] easeout|2 years ago|reply
Last year, I puzzled over how to watch my local sports team of choice and got mired in questions about streaming services and local blackouts and licensing. Then I bought a ten dollar antenna for my TV.
[+] ctoth|2 years ago|reply
Please consider accessibility while you're building this. The number of TV apps which don't use the Accessibility APIs is probably worse than on any other platform. Apple TV (as usual) is the best, but still has issues.
[+] analog31|2 years ago|reply
Granted, we're kind of Luddites, but my wife and I were going home from a social gathering, where some people were talking about the latest TV shows. My wife said to me: "I was embarrassed to admit it, but I don't know how to watch TV any more."
[+] therealdrag0|2 years ago|reply
You made me realize that I grew up without cable and not having some or all the streaming services is basically the same. It doesn’t matter too much.
[+] asow92|2 years ago|reply
There's a Canadian company that tried to do this a few years ago: https://www.youtube.com/user/YouiLabs

Not sure what's come of it since their cert at https://youi.tv is broken at the moment.

My experience with it was working at a big tv network who was trying to port all of their native tv apps over to this platform.

From what I recall:

It was a pain for designers because they had to retool their Sketch workflow to Adobe After Effects, which nobody liked. The idea was that the designer would design the view layer in AF and pass it along to the dev for integration. In retrospect, I think this was a mistake: developers should have been doing that from the beginning, as the workflow was similar to VBA or Storyboards and required intimate knowledge of how the view would be integrated into the code.

Most developers who worked with it loved it or hated it. It bridged the gap between platforms, but came at the cost of losing out on unique native platform features without writing complicated C++ bridging code on each platform.

The idea sounds solid at first, but you're really just trading one massive problem for another.

[+] gavinray|2 years ago|reply
Server-driven UI is a thing that's been gaining traction in recent years.

To my knowledge, at least a few FAANG companies have adopted this for the reasons mentioned in the article (AirBnB, Lyft, Expedia)

https://github.com/csmets/Server-Driven-UI

There are a few frameworks that cater to this -- most of them are variations on an API that returns JSON describing view components and state/actions.

For instance, DivKit:

- https://github.com/divkit/divkit

- https://divkit.tech/playground

It's a decent idea IMO, though I have no personal experience with it. I guess time will tell whether it catches on at-large though.

[+] kolanos|2 years ago|reply
> Roku uses a proprietary language and UI toolkit

I thought Roku was originally based on Silverlight, but I may be misremembering. I can't find any source to validate that.

But Roku still quietly has the biggest market share in this space.

[+] hotnfresh|2 years ago|reply
They use a language called BrigthScript that’s closest to Visual Basic. It was originally intended for digital signage. A few years back they “improved” it with XML crap that you have to use to describe public methods of your objects(!) and stuff. It was better before (docs and examples for old and new style exist).

Notable quirks include the XML companion files for code interface descriptions (in the newer SDK, anyway), and single = doing double-duty as assignment and comparison.

[edit] oh but my understanding is that big players get a different SDK with the ability to e.g. use C libraries, which is how they’re able to look & work so much like they do on other platforms.

[+] sanitycheck|2 years ago|reply
As someone who's used BS & Silverlight, I would say they are not alike except very superficially (XML for layout - but Android also has that).

I'd have to look quite hard to find a language I like less than BrightScript, it's horrible.

[+] thakoppno|2 years ago|reply
Brightscript is the name of their application language. Sounds similar enough to Silverlight to me. I bet it’s just a mix-up.
[+] justinator|2 years ago|reply
I know Netflix was def. Silverlight to begin with due to supporting DRM.
[+] epaulson|2 years ago|reply
The article is about what UI toolkits are used to build content apps for TVs and TV devices like FireTV/Apple TV, but I wish for a world where using those apps weren't my only options.

It'd be nice if TVs and streaming service apps were better participants in the open-protocol smart home. I'd like it to be possible to call an API on my TV from say Home Assistant to tell my TV to turn on, switch to Netflix, and play the next episode of a show - though honestly I'd settle for just control over linear TV channels and to be able to say 'switch to channel 55' at an API level and have it work cross-vendor without having to use their native app. Maybe you can do this with CEC and stick a little raspberry PI and stick it into the TV with HDMI, but the CEC content controls seem very limited.

Apple's got some kind of a start for this since they've got a way to feed data into Siri and their internal guide, including telling the AppleTV device what's currently playing and what should be considered 'up next' but they're all private APIs, I think, and only work if the content providers sign deals with Apple directly.

Maybe a future version of the Matter standard will incorporate media playback, right now I think it's just changing volume and pausing whatever's playing on a speaker, and so a long way from being able to control what the actual content being played is.

[+] jwells89|2 years ago|reply
A standardized approach would also let you use the OS’ standard video player widget which is practically always and upgrade from whatever needlessly custom-rolled players streaming apps tend to use. In fact the entire reason I subscribe to some services via Apple TV channels rather than directly is so I can watch their content on the standard tvOS player and skip the official apps.
[+] BlueTemplar|2 years ago|reply
I would guess that you can do a LOT with VLC and a little bit of scripting ?
[+] badrabbit|2 years ago|reply
The thing is, apps for TVs work relativley well. If I could run something in an RPI that accepts infrared remote control as an input device and have run all the drm-y media services, and have it work reliably with low maintenance, I would much prefer that!

If Amazon makes their custom Linux OS open source and allow users to modify and update the fire tv sticks, that would be even better!

[+] petepete|2 years ago|reply
If your TV supports CEC you'll be able to control your Raspberry Pi with your TV remote. It works perfectly with OpenELEC, I suspect other platforms are fine too.
[+] yaur|2 years ago|reply
A bunch of smart tvs already use react native so from the perspective of a developer that already has to support everything we don’t expect this to require a ton of work.

About 2/3 of our users are on some version of Android (which excludes fire tv) so will still be our most relevant target platform.

[+] boerseth|2 years ago|reply
The pendulum swings back to server-side.
[+] ghaff|2 years ago|reply
The thing is I'm not sure that people in general have a lot of issue with client-side fragmentation. It's more the content silos on the server side. But then people didn't like cable bundles either.
[+] pmontra|2 years ago|reply
What if we ban subscriptions and have to pay per view? Of course that would be great for me because I watch one episode of one or two TV series per week when there is something I like to watch and then nothing for months. It would be probably bad for people that like to watch something every day, unless prices are substantially low or there are volume discounts. But a volume discount is more or less the definition of a subscription.
[+] uoaei|2 years ago|reply
I kind of imagine a "toll road" style streaming service where the cost per minute or per view is told up front. Endless opportunity for dynamic pricing which is how the companies would justify the effort to implement such a model. Some offerings can be free through promotions or other means, and demand can be much more readily quantified on the supply side by calculating net profit.
[+] ugh123|2 years ago|reply
I think YouTube runs as some kind of browser-based app on a lot of devices. Mainly due to fragmentation and development challenges but it also gives them a consistent environment to integrate custom codecs and DRM checks. The UI is pared down to be a convincing app.
[+] jadbox|2 years ago|reply
This seems likely to me as well.

> To me, this level of fragmentation, coupled with the nature of content-centric TV apps, suggests that a server-defined UI approach might work well.

[+] hammock|2 years ago|reply
There still has to be some client side interface, an OS, a browser, thin client, I/O, some layer right?

Trying to thing of another example where a screen is just a dumb-as-can-be terminal