OpenDCT + Transcoding + Comcast

[KarylFStein]

I am looking to try on-the-fly transcoding of a CableCard stream. The Comcast streams require transcoding to allow stable playback on mini clients. I currently transcode after using the abilities built-in to SageTV. So, I know transcoding fixes my playback issues. This does not work for live TV and causes other issues, (navigation of the UI on a mini client freezes frequently when a transcoding job is running and last week I had a runaway transcoding job that almost brought down the server).

What would be the best transcoding parameters to clean up a Comcast stream for Placeshifter/ExoPlayer that is a good balance between quality and speed?

[EnterNoEscape]

The profiles that come with OpenDCT are targeted for quality and speed. The trade-off is file size. The differences are things like resultant resolution (e.g. 1080i becomes 720p or 1080p) and frame-rate (e.g. 30fps interlaced becomes 60fps deinterlaced or 30fps deinterlaced). These changes have their own performance gains that can't be offset much by changing the encoding quality.

[Korny]

Just a couple of semi related questions,
1 Do all the channels not work or only some of them? I'm just wondering if it's a mpeg2 vs mpeg4 issue since many Android boxes don't have mpeg2 hardware decoding.
2. Is your Android box hard wired to WiFi? Mpeg2 over WiFi can be touchy
3 Does Opendct have the ability to only transcode mpeg2 and pass on mpeg4?

[EnterNoEscape]

Originally Posted by Korny

Just a couple of semi related questions,
3 Does Opendct have the ability to only transcode mpeg2 and pass on mpeg4?

The profiles are mostly tuned for interlaced content that's not already H.264 because that was the issue this feature was originally added to address. It's very easy to adjust that behavior in a large number of directions. To answer your question more plainly, yes.

[KarylFStein]

Originally Posted by Korny

Just a couple of semi related questions,
1 Do all the channels not work or only some of them? I'm just wondering if it's a mpeg2 vs mpeg4 issue since many Android boxes don't have mpeg2 hardware decoding.
2. Is your Android box hard wired to WiFi? Mpeg2 over WiFi can be touchy
3 Does Opendct have the ability to only transcode mpeg2 and pass on mpeg4?

I use Placeshifter on PCs on the LAN (wired mostly) and remotely (WiFi over the Internet), and Android on the LAN (ShieldTV wired and Galaxy Tab S3 WiFi), and remotely (WiFi over the Internet). My main problem was that skipping didn't work properly. It started with just a couple channels a year or two ago, but kept getting worse until most everything did not skip properly. I could not find any correlation between channels, video or audio format, tuner, etc. (On my previous tablet when at home I started using Phoenix Remote and MX Player Pro which played/seeked seamlessly.)

When I was last trying to figure this out my recordings were all MPEG2 and a mix of 720p and 1080i. On the ShieldTV I want to use ExoPlayer to get bitstreaming audio and that added more pickiness. Transcoding to H.264 after recording seems to have addressed things. I had a problem last week with playback being choppy, but when I came home I found there was a long-running transcoding process using a bunch of memory causing the system to swap and gobbling up most of the CPU. So I'm pretty sure that was the culprit.

[NetworkGuy]

Originally Posted by KarylFStein

I use Placeshifter on PCs on the LAN (wired mostly) and remotely (WiFi over the Internet), and Android on the LAN (ShieldTV wired and Galaxy Tab S3 WiFi), and remotely (WiFi over the Internet). My main problem was that skipping didn't work properly.

I have ALWAYS had problems with Placeshifter skipping even on the LAN. The problems disappear when I use the SageTV Client.

Why no switch to the Client for the LAN PC?

[KarylFStein]

Originally Posted by NetworkGuy

I have ALWAYS had problems with Placeshifter skipping even on the LAN. The problems disappear when I use the SageTV Client.

Why no switch to the Client for the LAN PC?

Just because Placeshifter is easier and for laptops.

[KarylFStein]

I'm a little confused by the properties files. Basically my goal is to get CableCard streams into a format that will fix whatever weirdness Comcast is putting into them that breaks things on mini clients without visually changing images on a large screen. I'm a little under water here so maybe a dumb question, but would that mean copying the ultrafast1080p file to something different then changing v.conf.t.deinterlace_only to false and v.conf.t.always to true would do what I want?

Is there some way to say transcode everything but keep the source properties (resolution and interlaced/progressive) the same? Would that even help?

Also, what sort of hit does this take on the CPU? On this last build I tried to match my "worst case" as transcoding 4 simultaneous 1080p streams over the Internet plus some overhead. My current CPU has a Passmark setting of a little over 9000 overall and a little over 2000 single threaded. If transcoding input streams is going to push it over the edge I do have a second server that is slightly less powerful, but very underutilized that could be used for transcoding input streams.

[EnterNoEscape]

Originally Posted by KarylFStein

I'm a little confused by the properties files. Basically my goal is to get CableCard streams into a format that will fix whatever weirdness Comcast is putting into them that breaks things on mini clients without visually changing images on a large screen. I'm a little under water here so maybe a dumb question, but would that mean copying the ultrafast1080p file to something different then changing v.conf.t.deinterlace_only to false and v.conf.t.always to true would do what I want?

Yes. That would transcode everything including content that's already H.264. It would also convert 1080i to 1080p30.

Originally Posted by KarylFStein

Is there some way to say transcode everything but keep the source properties (resolution and interlaced/progressive) the same? Would that even help?

To my knowledge FFmpeg isn't very good at outputting interlaced content. If you can get something acceptable with the command line ffmpeg that's interlaced to interlaced, I will see what we can do to bring that into OpenDCT, but I have a feeling it will be even worse for the CPU than just deinterlacing.

Originally Posted by KarylFStein

Also, what sort of hit does this take on the CPU? On this last build I tried to match my "worst case" as transcoding 4 simultaneous 1080p streams over the Internet plus some overhead. My current CPU has a Passmark setting of a little over 9000 overall and a little over 2000 single threaded. If transcoding input streams is going to push it over the edge I do have a second server that is slightly less powerful, but very underutilized that could be used for transcoding input streams.

I would say with a very good CPU such as i5 Ivy Bridge 2.8GHz or better, allocate 1.5 cores per stream. For a worse performer such as the Phenom II CPU's around 3.0GHz, you'll be looking at closer to 2.5 cores per stream. The CPU power is definitely a little high and many configurations will struggle with just one stream.