Hi, thanks for your response!
Except the thing is, we know it does have the bandwidth for it, right? As I said earlier, prerecorded content at 1080i60, if Direct Stream and MPEG2 are enabled within the Plex Roku app, is in fact remuxed to HLS without issue:
But for DVR, or anything else, the MPEG2 enabling flag is respected, and the material appears to be remuxed unmolested (listed as ‘copy’).
I also pointed out that even Live TV MPEG2 at 1080i60 works when Direct Play is forced, and the ts stream is just served straight up without being remuxed to HLS–but again, this has the very significant drawback of seeking not working at all:
My ‘solution’ to this was to enable ‘Force’ under Direct Play, thus getting the original 1080i MPEG2 stream untouched. Unfortunately, this absolutely breaks seeking , at least on Rokus.
So with respect to enabling MPEG2, this seems like a transcoding logic bug. Some path is being taken with recorded content that isn’t being taken with live content. They should change this behavior or at very minimum account for it publicly, though I have no idea what possible justification they could have for this. It looks like an oversight rather than an intentional decision.
As for this suggestion–
thanks for your concern and suggestion, but, I have enough WAN bandwidth at both locations where I watch recorded shows such that any postprocessing or reencoding is unnecessary the vast majority of the time.
It looked like you might have had the right idea re the transcoding problem…
…but, the very chart you link to itself allows for both L4.1 and L4.2. Further drilling it down by hardware itself:
and you quickly find that while legacy models like Roku 2s or 3s are limited to 1080p30, and can only do 60p for 720p content and lower, basically everything newer than that, including my Roku Premiere+ 4620X and Roku Ultra 4640X, do not have any such caveat. It’s plausible that there is some ‘Roku encoding profile’ that Plex came up with years ago, when Roku 2s and 3s proliferated, and was never updated or complicated, I guess. I really hope that isn’t what happened, but if it did, I’d encourage them to revisit.
Beyond this, the Plex Roku app specifically has a ‘Maximum h.264 Level’ setting that allows you to set the maximum H.264 profile anywhere from ‘4.0’ to ‘5.1’, along with an ‘Auto’ setting and Profile 4.1 appearing as ‘(Recommended)’–this even though only legacy Rokus appear to actually be limited to Profile 4.1 per the implications of the chart I just linked to. Anyway, the setting here appears not to affect transcoding targets–I had it set to 5.1 (I do have some content above 4.2) the entire time I’ve experienced this issue. The accompanying description for the setting in the app reads:
Choose the maximum H.264 level to be considered when deciding if the media will Direct Play, Direct Stream, or Transcode.
This seems to imply that this just sets a maximum for native H.264 content. If the encoding profile for an entire class of devices precludes transcoding above 4.1, this does not override. But they should consider allowing it do so or adding another such setting that does, if they don’t revisit and/or update their device encoding profiles entirely.
All that said, even if you were right about H.264 profiles that Rokus support–and this doesn’t seem? to be supported by their own docs–that wouldn’t explain why remuxing/copying 1080i60 MPEG2 content is enabled in literally every case except for Live TV, which is when the lion’s share of people will ever encounter such content to begin with. I really hope they address this at least, though I’d also appreciate some server-side experimental override that enabled full-rate rather than half-rate deinterlacing when transcoding, or maybe a client-side override for maximum H.264 level which accomplishes the same.
Failing that, I’ve been wondering if I could manually implement all of this. There is a thread I found the other day where you and some others appear to do just such a thing for audio:
but I don’t really understand how it is intercepting these commands, whether it is feasible for video transcoder settings as well (particularly on a Win7 box), or which settings are causing half-rate deinterlacing (though from your response here, I’d hazard that it’d be the target Level) or precluding a straight remux from being done for Live TV MPEG2.
