Apple Screen in Screen support

Channels iOS Feature Requests
#15

I’ll add a couple of more things here:

  1. Given the massive upswell in the forum on TVE - I’m not so sure that the “majority” of the user base is using pure OTA. But even if it is, it’s not a justification to alienate what is clearly a very significant double-digit percentage of the user base. That argument just doesn’t hold water.

  2. Expecting Apple to be anything other than Apple is unwise, to put it kindly. :smile: They will not support MPEG-2. You have to live in the world we are in, not the one people want to exist. In this world, Apple has made it’s roadmap clear. They’re looking forward, not back. Channels is choosing to be addled by a 25-year-old legacy codec and forcing everyone to stick their collective heads in the sand that the iOS and tvOS worlds aren’t marching on.

Reencode the video to H.264 automatically, or give users the option to do so. It’s not rocket science in 2020. Again - this is 2020 and we’re here talking about a codec that old guys like me were around for the creation of. :smile: We have the technology to do this. Hell, we have hardware-accelerated capabilities to do this in 2020.

Yet we’re left to sit here and watch the rest of the world go by, or create absolutely unnecessary workarounds like creating a web app or web shortcut to do what the app should do by default and create the best user experience.

Except it doesn’t.

By choice. The developers aren’t helpless. They’re perfectly capable of implementing all this. They’ve built a terrific app and DVR solution in the face of a lot of competition...but that doesn’t mean it’s perfect, and it needs to evolve in this dimension substantially.

@racameron I’m not sure what you’re defending here. To say that “they can’t because Apple won’t let them” is just not an honest answer. It isn’t. This is a solved problem. Lots of other players have solved it. It’s long past time for Channels to solve it.

1 Like
#16

Let me concede the point that sure, the app, without connecting to the DVR, can’t do it.

But those of us that pay (aka me), would gladly pay for a solution that does.

To use your argument, the experience is already compromised - because this is an app that has two experiences - one for non-DVR users, and one for DVR users. The non-DVR experience is the best it can be. The DVR experience is crippled in some ways (PiP, but there are other ways as well unfortunately).

I’ve been around this app since it’s initial launch. I’m well aware of it’s history. Not prioritizing this feature after several years of PiP availability is unconscionable.

And I’d argue...let the developers speak for themselves, and clearly explain their roadmap and position. We’re just a bunch of non-developers (of this app), some of us paying for many years (aka me). I have a voice. I will avail myself of it. Let’s not stifle discussion.

1 Like
#17

PIP feature would be really, really appreciated.

When I need to do someting else on the iPad and want to listen to the tv, I need to switch to the tvhclient app. I would like to dismiss tvhclient app, but cannot do it for now

#18

If you use the web client for Channels on the iPad, instead of the app, then Picture in Picture works.

1 Like
#19

This, right here, is the response to all of your whining. This reasons PIP have not been implemented have been explained repeatedly throughout this forum by the developers and advanced users. Just because you don't like the answers, it doesn't invalidate those legitimate reasons — smile

#20

Resorting to name calling is unnecessary.

The Channels developers have their opinions, and they’re certainly entitled to them. I, and others, are entitled to ours.

Try to engage in constructive discourse without resort to name-calling - it’s unhelpful and doesn’t foster a sense of community or civility.

I disagree with the one of the intentional design choices that the developers have made in an otherwise terrific product and service that I’m happy to continue paying for. I’m an advanced user and a developer myself. My avenue to make a case for a feature and lobby for a different course is this forum. That my passion resonates with some people who also want to see this feature see the light of day is great to see and hopefully, at some point, the developers either reconsider or find an effective way to offer functionality that can be implemented if the developers choose to prioritize it.

There are tradeoffs in offering PIP to users. I get that. My point is that the tradeoffs tip significantly in favor of implementing this. To say that it is a technical impossibility to currently implement this feature is simply not true. You don’t need to take my word for it - there are several apps in the App Store today that do this, as I and others have pointed out. I have a sense for what it involves to implement this and what the tradeoffs are.

The Channels developers have chosen to prioritize other things. That’s okay. It’s their party.

I am still a paying user, and the developers have provided this forum to discuss features people want to see. Well, here it is. People want to see this. :slight_smile:

1 Like
#21

Which apps do native MPEG2 PIP currently?

#22

The root of the issue is a little more foundational than just an "intentional design choice".

The inability to support PiP for Apple clients stems from Channels' original purpose of delivering live TV viewing from OTA network tuners. OTA broadcasts are predominantly—and as far as I'm aware in the US, exclusively—H.262/MPEG-2 encoded. Because of this, playing these streams natively was not (is still is not) supported by Apple's system. This required the development of a video player separate from Apple's. An unfortunate side effect of this is that PiP is not allowed for video players other than Apple's own.

As Channels has matured from a program for simply viewing live TV streams from OTA broadcast sources to a full-fledged DVR ecosystem supporting many different sources, it still has not forgotten its roots. As such, Channels still defaults to streaming directly from the OTA tuners when possible, which requires it to use its custom video player. This has also led to the client apps each maintaining their own live buffers, instead of routing everything through the DVR as other platforms do. Because of these two aspects of Channels' heritage, its lack of support for PiP on Apple platforms is more than just an "intentional design choice", but rather an architectural foundation paradigm different from other DVR software packages.

While Channels can support PiP for Apple clients, its present inability to do so is not a choice. Also, as an "advanced user and developer", I'm sure you can understand how completely changing the foundation of an application ecosystem requires more than just a cursory shift. If Channels were to offer support for PiP on Apple, it could only do so by changing its default behavior, and limiting—or in some cases, outright breaking—established functionality for some users. Such a change is no simple matter, and requires far more thought and UX consideration than I think you've given the issue.

2 Likes
#23

@racameron I appreciate the heritage of Channels, and it’s always good to remember how Channels grew up as an app (and now a service too). We’re debating semantics though - it is an intentional design choice to maintain the OTA-first ethos.

I suspect a significant portion of the users on the paying end of the app (aka me) are using Channels primarily for it’s DVR capabilities. The paradigm in a DVR-centric worldview is different than an OTA-centric one...and that’s the very thing I’m calling out.

I’m paying for a full-featured DVR and client, but the client end of the feature set is, in this case, constrained by that OTA-centric perspective.

I get that many (for now) OTA broadcasts are still in H.262. Hopefully with ATSC 3.0, things will progress and broadcasters move to more modern formats, but that’s going to take the better part of a decade, I suspect. However, limiting the capabilities of the Channels client to the lowest common denominator in 2020 is unnecessarily constraining. Both can be supported, if the developers chose to do so - either by releasing an app that’s specific to DVR users, or by incorporating it into the mainline app and give the user the choice of which player or mode to use.

Yes, it involves writing (perhaps a substantial amount of ) new code, and I get that it’s more work for the developers - but the app shouldn’t be constrained by the design assumptions that were made years ago.

Originally, Channels wasn’t intended to feature a DVR - the developers pursued building one only after getting tired of waiting for the forever-delayed (at the time) SiliconDust DVR. They were originally building what was essentially a full-featured SiliconDust client.

Then they entered the DVR space. What it seems hasn’t happened, and continues to be missed, is a reevaluation of what the client experience should be and what parts of the app’s heritage should be kept and which should be evolved or deprecated. They did reevaluate their architecture and what they wanted to do and be as a company. They changed their pricing model. Introduced subscriptions. What they didn’t do is reevaluate what the client should be able to do.

Channels is making a choice not to support this functionality. The choices are only going to get harder and the technical debt is only going to accrue. Hard, opinionated choices are what great experiences are made of...I respect the developers’ choices, even if I disagree with them, and will continue to argue for modernizing several years worth of design decisions.

You’re trying to argue that changing the app or it’s underlying architecture would break things for some users - perhaps, but the app is already compromised in some ways for those of us who use iOS regularly in our workflow - and it’s not just supporting PIP that’s problematic, there are other limitations imposed by maintaining a rigid view that the app legacy should be maintained at the expense of everything else. It involves choices of what you want to support and what you don’t.

#24

What solution do you propose to support PIP for all content? The only way to do that would be to transcode all MPEG2 content in real time, which has a ton of downsides. Is that what you’re asking for, ultimately?

#25

I don’t know which should be the primary one, but could someone please combine the various separate requests all asking for this into a single request?

Two others very easy to find right away:

I don’t know why people are creating duplicate requests. There aren’t so many topics here that it is hard to skim before posting and search would have identified them. Search works well too.

@maddox @tmm1

#26

I gave some background, and tried to explain the greater UX issues. I get that you have your own views. In response, I guess I'll just offer you the developers' own words on the issue, and consider this closed:

#27

There are multiple ways to approach this:

  1. There were two apps, originally. One for OTA, and one specifically for the DVR. One answer is to differentiate these apps to focus on their specific, intended audiences, and let users choose which app to use for which purpose.

  2. The “workaround” that the developers posit isn’t a workaround at all. It’s essentially “use Safari and then we don’t need to worry about what the app is doing”. If they want to make the DVR / webUI a true workaround, they’d need to fully implement, support, and document an API (it is partially documented at https://getchannels.com/api/ ) that supports things like enumerating the complete list of recordings. The current API isn’t sufficient to create a working client - it’s sufficient for a remote control app. Then, those that use inFuse / Plex / something else have a way to effectively access the content and stream to our heart’s content.

  3. A better “workaround” would be for Channels to give you an option to open a recording (or Live TV) in Safari and take you there rather than the compromised user experience of “exit the app yourself, go to Safari, type in the URL for the webUI, navigate to the recording, hit play”. This alone would remove substantial, unnecessary, user experience deficiencies in providing PIP.

#1 requires real effort and time.
#2 requires a moderate amount of time and energy.
#3 should be very easy to add.

#28

A previous beta of Channels did exactly this. While in theory it sounds easy and great, reality demonstrated that it was anything but, and iOS had issues with this automation. It was eventually scrapped because it was both buggy and poor UX.

#29

What about give us an option in settings to switch to the native system video player and just playback the m3u playlist as is http://IP:8089/devices/ANY/channels/1205/hls/master.m3u8?codec=copy? This could open up for multi-view functionality and act as a simple m3u player?

#30

If the content is a format supported by the native video player that would probably work fine. It’s when the content is a format not supported by the native player that things get complicated.

#31

But there is no Safari on tvOS (AppleTV.)

And if I was on my Mac wanting Picture in Picture, why wouldn’t I just use Safari and the Channels webUI to begin with?

#32

https://community.getchannels.com/t/holiday-surprise-pip-beta/25188

1 Like
#33

Amen. Glad to see the modernization work is complete and Channels has this awesome capability. Now...I shall go gorge myself in PIP goodness.

Thanks all.

#34