Which apps do native MPEG2 PIP currently?
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
@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.
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?
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.
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:
There are multiple ways to approach this:
-
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.
-
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.
-
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.
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.
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?
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.
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?
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.