Best Recording Format?

[KarylFStein]

Is there a consensus on the best recording format for stability across playback methods? I have been looking at using Emby for playback, but after some dinking around with that would rather keep things in the SageTV ecosystem.

Unfortunately I can't get reliable playback locally or remotely unless it's through a local HD300, which seems to work with everything. My main playback targets are Exoplayer (local Android), Placeshifter (local and remote), and IJKPlayer (remote Android). My recording sources are OpenDCT (Ceton InfiniTV) and a Hauppauge 2550. The format from both seem to be only MPEG2. Reliable skipping is my major issue.

I have seen arguments for both PS and TS, and for pushing things through OpenDCT to SageTV to handle. Question is what would give me the "cleanest" file to use as a base to report and try to work through issues? I'm also open to changing capture devices if that would make any difference.

[Fuzzy]

Using OpenDCT through the sagetv remux should provide a clean timeline in the resulting video. MPEG2 in TS should be pretty well supported, the main issue being that MPEG2 itself is losing support out in the media world (most android devices do not have hardware decoders for it, for instance).

Alternatively, using OpenDCT to actually transcode the file to h.264 would provide a very portable file, but does take a decent chunk of cpu on the server to do, especially with multiple streams.

[Monedeath]

Originally Posted by Fuzzy

Using OpenDCT through the sagetv remux should provide a clean timeline in the resulting video. MPEG2 in TS should be pretty well supported, the main issue being that MPEG2 itself is losing support out in the media world (most android devices do not have hardware decoders for it, for instance).

Alternatively, using OpenDCT to actually transcode the file to h.264 would provide a very portable file, but does take a decent chunk of cpu on the server to do, especially with multiple streams.

Pretty much this. "Native" Mpeg2 support is going away for anything that doesn't exist as a "pure video player" such as a TV set or DVD/Blu-ray player. So if you want maximum portability going forward, you want h.264 encoded video. It also gives you the added benefit of being a more efficient compression format, so the recordings occupy less space. (Which is why portable media devices, and most "set top boxes" which are ostensibly for the purpose of streaming content from the internet don't bother with mpeg2, no streaming service will use it if they can avoid it, too much data use)

But as also mentioned by Fuzzy, the transcodes take a lot of CPU, and the better quality transcodes will take even more CPU+time to do. (It isn't unusual to take longer to transcode a recording from mpeg2 to h.264 than the run time of the recording being transcoded; depending on how much CPU you have to throw at it)

[KarylFStein]

My understanding is that H.264 is not supported by the HD300. Is that true?

[Fuzzy]

Originally Posted by KarylFStein

My understanding is that H.264 is not supported by the HD300. Is that true?

No, that is false. H.264 is supported very well by just about anything you'd access sage with, except the old Hauppauge MediaMVP.

[Monedeath]

Originally Posted by KarylFStein

My understanding is that H.264 is not supported by the HD300. Is that true?

I can personally confirm that the HD200 will play back h.264 encoded content So I can't imagine why the HD300 wouldn't.

[Taddeusz]

Originally Posted by Monedeath

I can personally confirm that the HD200 will play back h.264 encoded content So I can't imagine why the HD300 wouldn't.

All the SageTV branded media extenders support H.264. The only limitation is that the HD100 only supports level 4.0 which limits its ability to play full Blu-ray video. Both the HD200 and HD300 support level 4.1 so they'll both play full Blu-ray video.

[trk2]

Originally Posted by KarylFStein

My understanding is that H.264 is not supported by the HD300. Is that true?

You're probably thinking of H.265.

[KarylFStein]

OK, I must have been thinking of something else. H.265 maybe.

So if I wanted to test H.264 is that something SageTV can do internally on the fly (assuming my CPU can keep up) or is it a post-recording translation?

[Monedeath]

Originally Posted by KarylFStein

OK, I must have been thinking of something else. H.265 maybe.

So if I wanted to test H.264 is that something SageTV can do internally on the fly (assuming my CPU can keep up) or is it a post-recording translation?

SageTV itself has no built-in "real-time" transcoding capability. So it would be something that happens after the recording completes. And if you're wanting better quality, you'd probably setup a script, and have a third party program such as Handbrake do the transcode instead.

That being said, OpenDCT evidently can transcode things using FFmpeg in near real-time, depending on how much CPU/memory you have to throw at it. But as it will be a "fast transcode" you're going to lose at least some video quality in the trade off.

The HDHomeRun series now has some (non-CableCard) units that even have the option of doing the h.264 transcoding for you, which I think Sage can natively support, although I'd probably use SageDCT to act as go between all the same. But once again, you're dealing with a "fast transcode" and there will be a quality hit that comes with trying to do it in real time.

And AFAIK, h.265 isn't supported by SageTV at all at this point in time, but I could be wrong. The old extenders certainly don't support it.

[EnterNoEscape]

Originally Posted by Monedeath

And AFAIK, h.265 isn't supported by SageTV at all at this point in time, but I could be wrong. The old extenders certainly don't support it.

The old extenders don't support it, but the Android miniclient appears to have no issues with it.

[Fuzzy]

Originally Posted by Monedeath

SageTV itself has no built-in "real-time" transcoding capability. So it would be something that happens after the recording completes. And if you're wanting better quality, you'd probably setup a script, and have a third party program such as Handbrake do the transcode instead.

That being said, OpenDCT evidently can transcode things using FFmpeg in near real-time, depending on how much CPU/memory you have to throw at it. But as it will be a "fast transcode" you're going to lose at least some video quality in the trade off.

The HDHomeRun series now has some (non-CableCard) units that even have the option of doing the h.264 transcoding for you, which I think Sage can natively support, although I'd probably use SageDCT to act as go between all the same. But once again, you're dealing with a "fast transcode" and there will be a quality hit that comes with trying to do it in real time.

And AFAIK, h.265 isn't supported by SageTV at all at this point in time, but I could be wrong. The old extenders certainly don't support it.

If you are just looking to have h.264 for the compatibility, and not really for the size reduction, then going from h.262 @ 14-17Mbps (ATSC) to h.264 @ 10Mbs-12Mbps, even with a fast transcode profile, is not really going to be much of a drop in quality.

[EnterNoEscape]

Originally Posted by Fuzzy

If you are just looking to have h.264 for the compatibility, and not really for the size reduction, then going from h.262 @ 14-17Mbps (ATSC) to h.264 @ 10Mbs-12Mbps, even with a fast transcode profile, is not really going to be much of a drop in quality.

Something some people may not be aware of is that with software H.264 encoding, you can have only two of these three things: small size, high quality, fast encoding. I traded off small size since the goal was compatibility. I tested and verified that the profiles that come with OpenDCT to the best of my own visual acuity did not change the visual quality of the stream in any noticeable way short of what can happen when you de-interlace or scale down in resolution.

[mechling-burgh]

If you do on the fly trans coding on the OpenDCT don't you also loose subtitles I thought you said once before.

[EnterNoEscape]

Originally Posted by mechling-burgh

If you do on the fly trans coding on the OpenDCT don't you also loose subtitles I thought you said once before.

That's correct, you lose closed captioning. OpenDCT has an option to extract (using CCExtractor) the closed captioning to .SRT files live. I also made changes to the SageTV core so that it supports this this live. There is one caveat: the .srt files cannot be written through the media server.

[Fuzzy]

Originally Posted by EnterNoEscape

That's correct, you lose closed captioning. OpenDCT has an option to extract (using CCExtractor) the closed captioning to .SRT files live. I also made changes to the SageTV core so that it supports this this live. There is one caveat: the .srt files cannot be written through the media server.

.srt files seem to be better supported across the range of sagetv clients than closed captioning, however, so in the end, this is probably better. I wasn't aware of the media server limitation - I wonder if there's an improvement we can make to the core to allow the writing of associated files via the media server. I mean, I don't really see much harm in allowing files with a different extension to be WRITEOPEN'd with the same UploadID.

[EnterNoEscape]

Originally Posted by Fuzzy

.srt files seem to be better supported across the range of sagetv clients than closed captioning, however, so in the end, this is probably better. I wasn't aware of the media server limitation - I wonder if there's an improvement we can make to the core to allow the writing of associated files via the media server. I mean, I don't really see much harm in allowing files with a different extension to be WRITEOPEN'd with the same UploadID.

It's not a permissions issue. That would be dead simple to fix up (as you described). It's the CCExtractor binary would need to be modified to support it. I can pipe the output for one stream from CCExtractor, but if I do two, it needs to be done in CCExtractor's proprietary format which also leaves me doing all of the formatting that CCExtractor would have done for me. The best way might be to add media server support to CCExtractor, but I have not really looked into that yet.

Edit: Since the media server does checks for specifically authorized files, in this same frame of mind, I would have it also validate that the file being created has a known subtitle extension when it has a different extension than the expected file.

[Fuzzy]

Originally Posted by EnterNoEscape

It's not a permissions issue. That would be dead simple to fix up (as you described). It's the CCExtractor binary would need to be modified to support it. I can pipe the output for one stream from CCExtractor, but if I do two, it needs to be done in CCExtractor's proprietary format which also leaves me doing all of the formatting that CCExtractor would have done for me. The best way might be to add media server support to CCExtractor, but I have not really looked into that yet.

I haven't looked at CCExtractor, I had just assumed it could output the .srt contents to stdout, which you then could have opendct shoot over to the mediaserver. That said, modifying ccextractor to be able to 'write' to an stv://[uploadid]@[sagetvserver]/path/to/file.srt would be very clean.

[EnterNoEscape]

Originally Posted by Fuzzy

I haven't looked at CCExtractor, I had just assumed it could output the .srt contents to stdout, which you then could have opendct shoot over to the mediaserver. That said, modifying ccextractor to be able to 'write' to an stv://[uploadid]@[sagetvserver]/path/to/file.srt would be very clean.

It can output to stdout, but it can only output one srt at a time like that. The configuration in OpenDCT allows one to output more than one close caption stream. I had to do an interesting work around on Windows regarding pipes because they were broken until recently and I haven't had a chance to update the code used in OpenDCT. Since I don't need the workaround anymore, I guess it's possible to just run two copies of OpenDCT to get the two separate streams.

[Fuzzy]

Originally Posted by EnterNoEscape

It can output to stdout, but it can only output one srt at a time like that. The configuration in OpenDCT allows one to output more than one close caption stream. I had to do an interesting work around on Windows regarding pipes because they were broken until recently and I haven't had a chance to update the code used in OpenDCT. Since I don't need the workaround anymore, I guess it's possible to just run two copies of OpenDCT to get the two separate streams.

If I knew anything about .c, I'd probably look at adding the stv: (media server) format to ccextractor, as that sounds like it'd be the most versatile thing in the end. I mean, there is MythTV specific code in there, don't see why there shouldn't be SageTV specific code in there as well.