On Thu, Dec 17, 2015 at 8:07 PM, Jim Porter <[email protected]> wrote:
> Improving Ease of Adoption > -------------------------- > > First, I think the most important thing we can do right now is make it > easy for people to run Firefox OS on their TV. We can't expect > enterprising hackers to go buy a Panasonic TV with Firefox OS if they > want to contribute; we need an easier way. The Raspberry Pi would be a > great solution here. First, it's very cheap ($35); second, you can > already install other media centers onto it (Kodi), so we know it should > meet our hardware needs; and third, it's already got a very active > developer community. > Agreed. Barrier to entry is way to high. The only party that benefits from baking an OS into the TV is the OEM as they can sell new hardware when the OS gets clunky. It would be better for Mozilla and users if the OS was portable and could run on any TV/monitor. I don't think we should be thinking of TV as anything other than a dumb monitor. Which OS is projected onto this monitor is the user's choice and they should be free to change it and move it to new hardware. If we're serious about putting users first, we should give them choice and protect them from lock-in. The "Holy Grail" of Media > ------------------------- > > In media center development, people often talk of a "holy grail": > completely unified media content from multiple sources. If I want to > watch Jurassic Park, I don't really care where the video comes from > (Netflix, Hulu, somewhere locally, etc); I just want to watch the movie. > One way we could handle this would be to expand the "Rocket Bar" to > allow searching inside of individual apps. Apps could provide an > endpoint to respond with search results given a particular query, which > we'd then aggregate into a single list. That would make it easy to find > content, no matter where it is.[1] > > Another, more-thorough way to handle this would be to turn each media > provider into nothing more than a data source that populates some > system-wide database. This would be even more content-focused, but would > require us to be able to scale up to truly massive amounts of content. > > Unfortunately, most of the major video providers (e.g. Netflix, Hulu, > Amazon) are *very* concerned about controlling users' experience. They > want to be able to plaster their logo on the screen as much as possible, > and to ensure that they can advertise all their other shows so they keep > you around longer. Netflix in particular enforces this through a closed > API and DRM-protects all their videos. This means we have to rely on > Netflix to provide an app for our platform; hopefully, the fact that > we're just Gecko under the hood will make this easier (although I'm not > sure how EME works on a real device). > > Local Content > ------------- > > Because of the restrictive nature of most video streaming services, I > think it's very important for us to be able to play locally-stored > media, either on the device itself or on some other device on your LAN. > Many users already have local content (especially music), and we should > let them play that. It's also an important part of upholding the Mozilla > Manifesto: the Manifesto makes it very clear that we should enable users > to control the content they consume. One of the best ways to allow for > this is to let them control the media files themselves; this also helps > us to support smaller media providers like Bandcamp and VHX that > typically provide their media as downloads. > > This could also tie in with Fabrice's "FoxBox" idea; however, I don't > think we should *require* pairing our media center platform with another > device of our making. Users should be able to use any device that uses > common media/file-sharing standards. That means supporting some > combination of UPnP (aka DLNA), Ampache, SMB, NFS, etc. > > Enriching Content > ----------------- > > As an extension of local content, we'll want the ability to "enrich" > that content by downloading additional information about each video. > (Unlike audio content, videos very rarely have metadata stored within > the file, and usually the only information you have is in the filename). > Software like Kodi has already established a great way forward here: > content scrapers. There are a bunch of websites out there that provide > information about media that we could use to pull in things like movie > posters, plot summaries, cast and crew lists, etc. Here's an example > (the default movie scraper in Kodi): https://www.themoviedb.org/ > > Centralizing Media Playback > --------------------------- > > If we're creating a device centered around media playback, it might make > sense to move the core playback code (as well as queuing) into the > system app. This would let us manage *all* video/audio in a central > location, and allow for things like queuing up videos from different > sources so they play one after the other. This is a nice feature if > you're hosting a party. I'm not sure how we'd handle videos on ordinary > websites, though; we don't have a way of knowing what *kind* of content > they are. > > Remote Control > -------------- > > In my experience using media centers, it can be pretty convenient to > control the media center via a touchscreen-based remote (read: an app on > your phone/tablet). I believe we already have a basic remote like this, > mainly for navigating webpages, but we should expand this to allow > controlling playback, navigating through lists of content, etc. We could > easily make this cross-platform by just hosting a webpage from the TV > that other devices on the LAN can connect to. FlyWeb would make > discovery even easier. > > It would also make sense to provide something like a JSON API so that > people could write their own remote control apps, and do other creative > things. However, that's probably not necessary in the short term. > > Conclusion > ---------- > > The above points are the main design-related things that I think we > should focus on. There are lots of other things that make up a good > media center (e.g. age-restricted profiles so your kids can't watch > R-rated movies), but I've tried to cover the most important ones. I'll > hopefully be following this email up with a more implementation-oriented > message that talks about what APIs people expect out of devices like > this, etc. > > - Jim > > [1] This is actually what the Xbox 360 does with its "Bing" search. > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
