OpenDCT: An open source digital cable tuner.

[KarylFStein]

Originally Posted by brandypuff

i second that. With the renewed interest in SageTV development and the pretty stable v9 open source beta along with the very useful OpenDCT application, i plan on continuing with Sage for as long as my extender hardware keeps going. It's too bad new extenders aren't being produced anymore. To this day, i don't believe there is a better PVR solution than SageTV.

Thanks for the dedication and hard work to everyone who has put into keeping SageTV alive. Long Live SageTV!

The Android client is shaping up nicely making it possible for an inexpensive Android box to act as an extender.

[EnterNoEscape]

The Android miniclient is the reason I'm working on live transcoding abilities now instead of later. I was going to put it off because I figured it would be a real hassle, but while it is taking a lot of time to get things the way I want them, the audio/video sync problems that I thought I would run into just based on experience from the executable don't exist which is very encouraging.

[EnterNoEscape]

Originally Posted by troll5501

Thanks for adding the new property and for the quick bug fix! With 0.4.27 the I/O and CPU stats are back to normal. I increased the min flush to 8MB and I'm happy with the performance now. There is still an occasional flush that wasn't there before, but it's probably a good idea to have it.

Well...it was a very small bug that would have very unexpected results for people paying attention and the gradle script only takes about a minute to compile, package everything and upload it again. You're welcome.

I know with ZFS it's usually recommended to just let it do it's own thing. If it interests you, I can also make it disabled by providing -1.

[jm9843]

Originally Posted by EnterNoEscape

The Android miniclient is the reason I'm working on live transcoding abilities now instead of later.

What is this going to achieve? Will OpenDCT, running on a capable host, do real-time transcoding to formats/containers that offer better compatibility with Android? Any other details you'd like to tease (e.g. formats, hardware requirements)?

[troll5501]

Originally Posted by EnterNoEscape

If it interests you, I can also make it disabled by providing -1.

If you don't mind adding this, I think it would be nice to have the option to disable the flush. Thanks again!

[EnterNoEscape]

Originally Posted by jm9843

What is this going to achieve? Will OpenDCT, running on a capable host, do real-time transcoding to formats/containers that offer better compatibility with Android? Any other details you'd like to tease (e.g. formats, hardware requirements)?

It will just be MPEG-TS and MPEG-PS because those are the kind of containers that SageTV expects from a network encoder. Other ones are possible, but MPEG-TS especially is very well suited for live transcoding.

So far I have a fast interlaced detection method that bases it's assumptions on the decoded frame being flagged interlaced. This has worked really well over several samples I was able to acquire. It basically checks up to 60 valid video frames and if 30 of them are interlaced, it's assumed that the content is interlaced. Anything more thorough would be a waste of resources. Since the biggest focus is to be able to deinterlace content into progressive content, you will be able to optionally set OpenDCT to only transcode if the content is interlaced. Otherwise it will just copy the streams similar to what it does already. It could also be configured to transcode to H.264 based on if the content is MPEG2.

The hardware requirements are somewhat high. My VM is hosted on an i7-4790K. I currently have a filter in place that scales to 720p if the resolution is greater than 720p because 1080p for example is extraordinarily resource intensive even on very fast settings. My two core VM can transcode H.264 1080i 29.97fps content scaled to 720p at 45fps. I'm also looking into hardware acceleration like QuickSync and DXVA2, but those will not likely be available at first. You will also be able to create your own transcoding profiles. There will be ones available by default and maybe even a way to have OpenDCT auto-detect what will probably work best.

Audio is just being copied. We'll cross that bridge if there's ever a good reason to mess with it. Also when you transcode video, you lose things like closed captions, so down the road I want to add support for cc_extractor (which can be compiled into FFmpeg) to convert the captions to subtitles. I could also just add the original video stream as a second video track, but I don't know if SageTV would support that.

[fresnoboy]

Originally Posted by EnterNoEscape

It will just be MPEG-TS and MPEG-PS because those are the kind of containers that SageTV expects from a network encoder. Other ones are possible, but MPEG-TS especially is very well suited for live transcoding.

So far I have a fast interlaced detection method that bases it's assumptions on the decoded frame being flagged interlaced. This has worked really well over several samples I was able to acquire. It basically checks up to 60 valid video frames and if 30 of them are interlaced, it's assumed that the content is interlaced. Anything more thorough would be a waste of resources. Since the biggest focus is to be able to deinterlace content into progressive content, you will be able to optionally set OpenDCT to only transcode if the content is interlaced. Otherwise it will just copy the streams similar to what it does already. It could also be configured to transcode to H.264 based on if the content is MPEG2.

The hardware requirements are somewhat high. My VM is hosted on an i7-4790K. I currently have a filter in place that scales to 720p if the resolution is greater than 720p because 1080p for example is extraordinarily resource intensive even on very fast settings. My two core VM can transcode H.264 1080i 29.97fps content scaled to 720p at 45fps. I'm also looking into hardware acceleration like QuickSync and DXVA2, but those will not likely be available at first. You will also be able to create your own transcoding profiles. There will be ones available by default and maybe even a way to have OpenDCT auto-detect what will probably work best.

Audio is just being copied. We'll cross that bridge if there's ever a good reason to mess with it. Also when you transcode video, you lose things like closed captions, so down the road I want to add support for cc_extractor (which can be compiled into FFmpeg) to convert the captions to subtitles. I could also just add the original video stream as a second video track, but I don't know if SageTV would support that.

This is very cool. I also run SageTV virtualized under Windows Server 2012, on a dual CPU E5-2670 based motherboard. The E5-2670's (8 cores each) are under $100 each on ebay, and are an amazing value, so I have CPU power to spare, and being able to do high quality de-interlace/transcode on record would be nice not just for avoiding de-interlacing when streaming to an android client, but also for storage efficiency (if going straight to H.264).

Thanks for building OpenDCT. I have had issues with the other network encoders with SageTV that never quite made recording troublefree, but OpenDCT has been great so far. I record to a ZFS volume on a NAS, which is quite fast, so never could understand the issues, but glad it all is playing well now.

Thank you for your work!

Mike

[EnterNoEscape]

While things can be tweaked in any direction, my primary focus is making the content transcode quickly live in high quality with the best possible device compatibility. File size is secondary because to get files really small at the same quality generally can't be done in real-time without hardware assisted encoding. Experience has told me you can only have two out of these three when encoding with software: speed, efficiency, quality.

But don't let this scare you; I can transcode my test 2 minute 1080i H.264 clip to 720p in under 2 minutes and the file size is exactly the same. I also have a 2 minute 1080i MPEG2 ATSC clip that will transcode even faster and comes out one third the size. The picture quality is very good (it looks a little sharper than an HD-PVR recording), but if I don't constrain the bitrate to baseline, the picture quality get so good, it is nearly indistinguishable to my eye from the original content on my HD300 and on some players I'm sure it looks even better because it's already deinterlaced.

[mistergq]

How do you set up regular HDHomerun (now cable card devices) to be used with OpenDCT?

[EnterNoEscape]

Originally Posted by mistergq

How do you set up regular HDHomerun (now cable card devices) to be used with OpenDCT?

Are you asking how to use the currently experimental HDHomeRun ATSC support?

[brandypuff]

Question? Why do you need to de-interlace?

[nyplayer]

Originally Posted by brandypuff

Question? Why do you need to de-interlace?

the miniclient has problems playing back 1080I H.264 recordings from the Hd Homerun Prime is one reason because of interlacing.

[EnterNoEscape]

There are also plenty of players with very poor de-interlacing abilities. I see no reason to leave the content interlaced. That being said, if you really want to retain the interlacing, it should be possible, but you'll be creating your own transcoding profile.

[brandypuff]

I'm not sure where to post this but lately i have been having issues with one of my Prime HDhomerun tuners missing recordings. See the attached image. I am using OpenDCT. The other tuners work ok. Isn't this odd that only one tuner has a problem?

Now i did setup a separate system with SageTV v9 and assigned that tuner (-2)
to try out v9 a few weeks ago. But i am not recording anything with it on the other system and have disabled OpenDCT on that system as well as to not conflict with recording on my main system. Just thought I would mention this detail.

Any ideas? I just tried to record 3 shows simultaneously and the one on the Prime tuner -2 failed to record due to capture device failure.

[nyplayer]

Originally Posted by brandypuff

I'm not sure where to post this but lately i have been having issues with one of my Prime HDhomerun tuners missing recordings. See the attached image. I am using OpenDCT. The other tuners work ok. Isn't this odd that only one tuner has a problem?

Now i did setup a separate system with SageTV v9 and assigned that tuner (-2)
to try out v9 a few weeks ago. But i am not recording anything with it on the other system and have disabled OpenDCT on that system as well as to not conflict with recording on my main system. Just thought I would mention this detail.

Any ideas? I just tried to record 3 shows simultaneously and the one on the Prime tuner -2 failed to record due to capture device failure.

Do you have this property set to true on your production environment .. that way you will not get halt detected errors if for ever reason your tuner is in use... it will force an unlock and use it. I have it set to false on my test system and true on my production system have yet to have a halt detected on my production system.

always_force_external_unlock=true

[brandypuff]

ugh. i checked and i only enabled it for one tuner because i didn't know it was a per tuner parameter. OK, let's try again...

[BobbyDing]

Originally Posted by EnterNoEscape

Are you asking how to use the currently experimental HDHomeRun ATSC support?

I had completely missed this (added ATSC support in V.4.xx). I understand it's experimental, but thank you for expanding support to the connect tuners. I'd like to try this on my test machine and if successful, to the production server. The test pc is Win7 and SageTV7. I have V.03.xx successfully running on my production server right now. The only setup link I've found for Windows is for Daweeze's install instructions for V0.3.x.xx. Are there setup instructions for V0.4.xx on windows? I suspect it's Java 1.8 and I'll need to remove SageDCT. Anything else I need to do different for V0.4.xx?

And then the question.... How to I enable/use the ATSC support with Prime support? I have 1 Prime, 4 Connects and 2 Extends. Except for the Prime, all others are using OTA from 2 different markets.

Thanks!

Bobby

[EnterNoEscape]

Originally Posted by BobbyDing

I had completely missed this (added ATSC support in V.4.xx). I understand it's experimental, but thank you for expanding support to the connect tuners. I'd like to try this on my test machine and if successful, to the production server. The test pc is Win7 and SageTV7. I have V.03.xx successfully running on my production server right now. The only setup link I've found for Windows is for Daweeze's install instructions for V0.3.x.xx. Are there setup instructions for V0.4.xx on windows? I suspect it's Java 1.8 and I'll need to remove SageDCT. Anything else I need to do different for V0.4.xx?

And then the question.... How to I enable/use the ATSC support with Prime support? I have 1 Prime, 4 Connects and 2 Extends. Except for the Prime, all others are using OTA from 2 different markets.

Thanks!

Bobby

Java 1.7 is still ok.

Yes. Starting on 0.4.23 and up to enable "native" HDHomeRun discovery which also enables devices other than the Prime to be used, you need do the following:

1. Stop the SageTV service.
2. Stop the OpenDCT service.
3. Open opendct.properties.
4. Change the value of discovery.exp_enabled to true.
5. Start the OpenDCT service and wait a few seconds.
6. Start the SageTV service.

After making those changes, you should now see new tuners in SageTV named after all of the discovered HDHomeRun devices that responded on your network. I'm curious with so many HDHomeRun devices how well it will perform. If you don't see everything the first time, restart the SageTV service.

The Connect devices also have HTTP streaming capability that OpenDCT can use if you have done a channel scan via the web interface on the Connect. If for any reason the URL doesn't work, it has a failsafe to just use RTP. You should find HTTP to be more reliable. If it causes you any grief, you can turn it off by setting hdhr.allow_http_tuning to false. The Extend can also do transcoding via HTTP, if you want you can set the "global" profile via hdhr.extend_transcode_profile. If you're just trying to save disk space, I would just use 'heavy'. Check the release notes for 0.4.25-Beta on what profiles are available.

It's just labeled experimental in case something bad happens, so you're prepared for some potentially interesting troubleshooting. By testing this functionality out you're also testing out the way the Prime will eventually be handled too.

[nyplayer]

I have it running with 4 Connects (8 Tuners) and 2 Primes (6 Tuners) for a total of 14 tuners and I have yet to get a halt or missed a recording I am using pooling with force tuner lock on all my tuners. Sharing them all with HDHomerun DVR and my SageTV test System

[EnterNoEscape]

I forgot that you had that many tuners. I guess heavy use has been very much tested.