AppleTV 4

[Taddeusz]

I watched the Apple announcements today. The new AppleTV will support apps. Maybe someone, even myself, can get an AppleTV app for SageTV going?

[tvmaster2]

Originally Posted by Taddeusz

I watched the Apple announcements today. The new AppleTV will support apps. Maybe someone, even myself, can get an AppleTV app for SageTV going?

if YouTube doesn't find its way onto AppleTV somehow, it's game over, isn't it?

[Taddeusz]

Originally Posted by tvmaster2

if YouTube doesn't find its way onto AppleTV somehow, it's game over, isn't it?

Huh? YouTube has been on Apple TV for quite some time. It's the older models that have had it stop working because of older API deprecation.

[reggie14]

Well, in all fairness I'm more of an Android guy, but the AppleTV doesn't look that compelling compared to a ShieldTV.

The remote looks terrible, and there doesn't appear to be an IR receiver for third-party remotes (e.g., Harmony remotes). I wouldn't expect hardware mpeg2 acceleration or deinterlacing, and I doubt software decoding would go much better than it did on the Shield.

[Taddeusz]

Originally Posted by reggie14

Well, in all fairness I'm more of an Android guy, but the AppleTV doesn't look that compelling compared to a ShieldTV.

The remote looks terrible, and there doesn't appear to be an IR receiver for third-party remotes (e.g., Harmony remotes). I wouldn't expect hardware mpeg2 acceleration or deinterlacing, and I doubt software decoding would go much better than it did on the Shield.

The reports I've read say the touch pad feature on the remote works pretty well. The remote is Bluetooth connected so it won't be able to be controlled by third party remotes. It does have the capability of controlling the volume of a TV or receiver.

Not sure about de-interlacing but I wouldn't expect MPEG2 acceleration. Even though it's still used for broadcast television it is largely an irrelevant technology. The same could be said of ATSC. Especially at the time of the digital switch it was a technologically inferior standard. Now that MPEG2 is so ingrained in broadcast standards its going to take as much to replace it with something better. H.264 is already part of the newer ATSC standard but I doubt there's a TV that can decode it. It's going to have to be another painful mandate to upgrade TV to a more modern CODEC.

That being said, modern processors are perfectly capable of real-time conversion of MPEG2 to H.264 as well as doing the same for interlaced H.264. Plex does a perfect job of it on my C2Q 8400. It shouldn't be too difficult to do conversion for those cases.

[Fuzzy]

Originally Posted by Taddeusz

The reports I've read say the touch pad feature on the remote works pretty well. The remote is Bluetooth connected so it won't be able to be controlled by third party remotes. It does have the capability of controlling the volume of a TV or receiver.

Not sure about de-interlacing but I wouldn't expect MPEG2 acceleration. Even though it's still used for broadcast television it is largely an irrelevant technology. The same could be said of ATSC. Especially at the time of the digital switch it was a technologically inferior standard. Now that MPEG2 is so ingrained in broadcast standards its going to take as much to replace it with something better. H.264 is already part of the newer ATSC standard but I doubt there's a TV that can decode it. It's going to have to be another painful mandate to upgrade TV to a more modern CODEC.

That being said, modern processors are perfectly capable of real-time conversion of MPEG2 to H.264 as well as doing the same for interlaced H.264. Plex does a perfect job of it on my C2Q 8400. It shouldn't be too difficult to do conversion for those cases.

MOST tv's sold today likely have the silicon to playback h.264 content - many have the capability via thumbdrive, smart tv apps, etc. That's not saying they support h.264 from the tuner, but that wouldn't be a huge leap. Of course this won't help people with older sets, but going forward, I'm guessing many tv's will support the newer ATSC standard completely.

[Carlton Bale]

Originally Posted by Taddeusz

The reports I've read say the touch pad feature on the remote works pretty well. The remote is Bluetooth connected so it won't be able to be controlled by third party remotes. It does have the capability of controlling the volume of a TV or receiver.

The Apple TV 4 does support third-party Bluetooth devices (gamepads and remotes.) So Harmony or other remotes could theoretically suport it. Similar to Playstation.

[alwzn4vr]

Apple TV supports HTTP Live Streaming which sounds very similar to the way placeshifter works. From the release notes it appears that tvOS is basically iOS 9 with a bunch of API's removed.

[reggie14]

Originally Posted by Taddeusz

That being said, modern processors are perfectly capable of real-time conversion of MPEG2 to H.264 as well as doing the same for interlaced H.264. Plex does a perfect job of it on my C2Q 8400. It shouldn't be too difficult to do conversion for those cases.

The Plex team has spent a lot of time on their transcoder. I kind of doubt we'd realistically get something that good in Sage.

Also, real-time transcoding is less annoying in something in Plex, where most of the content is commercial-free. In Sage its desirable to have faster skipping, since you're going through commercials. It certainly helps to let Plex transcode ahead a few minutes, but skipping is still seems less responsive.

But yes, computers are fast enough to handle real-time transcoding, and the latency when skipping is merely annoying, not terrible. I recently upgraded my Sage/Plex server to a Core i7 4790k with the assumption we'd be doing more transcoding. We'll certainly need it for mobile devices and placeshifting. It's just something that I think would be better to avoid when possible.

[Taddeusz]

Originally Posted by reggie14

The Plex team has spent a lot of time on their transcoder. I kind of doubt we'd realistically get something that good in Sage.

I don't doubt that. Just as with SageTV they use ffmpeg, albeit a modified version.

[reggie14]

The problem isn't transcoding speed- presumably if we ran x264 with the same parameters it would run at the same speed- the problem is latency. The new(ish) Plex transcoder and experimental player seemed to dramatically reduce latency. At least, it did for me on Android.

[fidget]

From reading this article, the basic SageTV UI may not be too difficult. I would like to know what the AppleTV can decode in hardware, though.

[stuckless]

Originally Posted by fidget

From reading this article, the basic SageTV UI may not be too difficult. I would like to know what the AppleTV can decode in hardware, though.

Related to the article... i think NOT allowing any form of local storage, even for caching, is a mistake. Forcing you to use icloud for any type of data peristence, means your device always requires an internet connection, so forget about packing it up and bringing it somewhere remote.

Other than that, the TVML looks interesting... I posted a thread many years ago on this forum about why not just use HTML+CSS for a media center UI... At that time, it was almost impossible given the architecture of the time... but today, using xml+javascript is possible, and not a bad idea to quickly and an easily get simpler apps off the ground.

[Vaskill]

Originally Posted by stuckless

Related to the article... i think NOT allowing any form of local storage, even for caching, is a mistake. Forcing you to use icloud for any type of data peristence, means your device always requires an internet connection, so forget about packing it up and bringing it somewhere remote.

Other than that, the TVML looks interesting... I posted a thread many years ago on this forum about why not just use HTML+CSS for a media center UI... At that time, it was almost impossible given the architecture of the time... but today, using xml+javascript is possible, and not a bad idea to quickly and an easily get simpler apps off the ground.

Just so we are clear, based on my research to date (some may be hazy):
AppleTV will:
1) allow the use of local keystore
2) allow the use of up to 1MB in local storage
3) allow the use of up to 200MB in app container (of course includes binaries)
4) has same old stream caching (it would never work without this IMHO)
5) allows local temporary storage in the form of cache, etc. that may not be lost until the system needs the space or is rebooted
6) can use third party and older Mac/AppleTV IR remotes for basic functions (basic = no siri; no gesture or motion)

I have started to storyboard an AppleTV prototype that would support the basic functions of Guide, Recordings, Search.

I will likely will be using the same API/WebServices that the Sage Web interface uses to get basic streaming and control.

It has be over a decade since I have done any hands on programming so this might take a bit.

[Taddeusz]

I'm planning on working to get the MiniClient ported to iOS

[Vaskill]

Originally Posted by Taddeusz

I'm planning on working to get the MiniClient ported to iOS

I would be very interested in that approach too, but am worried a straight port and interface shift might be awkward (also beyond my old programming skills :roll eyes. I think there is room for both approaches and hope we can collaborate

[Taddeusz]

I was hoping to be completely Swift but Google wrote j2objc. Going to try and convert MiniClient with it.

[Vaskill]

j2objc sounds like an interesting approach... certainly willing to help test as well.

[Fuzzy]

The other option, while maybe painful from the start, might be to use the miniclient.jar as inspiration, but write the apple version from scratch. the actual placeshifter protocol is not incredibly complicated, and writing native for iOS may end up with a much better result in the end.

[stuckless]

Originally Posted by Vaskill

j2objc sounds like an interesting approach... certainly willing to help test as well.

Originally Posted by Fuzzy

The other option, while maybe painful from the start, might be to use the miniclient.jar as inspiration, but write the apple version from scratch. the actual placeshifter protocol is not incredibly complicated, and writing native for iOS may end up with a much better result in the end.

While the placeshifter protocol is not overly complicated, it's by no means trivial. And certainly, the rendering part is very complicated, especially if you don't know OpenGL (which I don't -- very well)

Depending on how you feel about writing in Java... you can leverage the existing Java code. RoboVM will take java byte code and transpile it into native iOS instruction code.

In the project that I'm using.. There is a "core" project that contains all the vanilla sagetv io and processing, and there is an "android" project. The Android project is quite small, since it only has to create a server selector, and then a Rendering view to render the client. All the "real" work happens in the Core, and it delegates the rendering to the hardware specific Renderer. I was using this setup to do most of my testing on a PC before moving on to an Android specific implementation.

It is possible to create an "ios" project with the specific implementation for IOS and leverage all the shared code, from the "core". The RoboVM bindings have all the NS widget bindings so you can create a native UI from Java code. What you would need to do natively, is build a Server Selector view, and then a GL Rendering view that implements in the Rendering interface (and obviously pull it together by setting up and tearing down the views, etc). (Still not trivial, but you are shielded from all the sagetv communication code, etc)

In this scenario... this is not Java running on a VM running on iOS... this is native arm code running on iOS, directly on the CPU, no VM at all.

If you don't know Java but you do know Obj-C... then maybe j2objc would be a better choice.