Software support for new HDHomeRun 4K Quatro

ATSC 3.0 Forum
Post Reply
m_theredhead
Posts: 6
Joined: Sun Sep 08, 2013 12:52 pm

Software support for new HDHomeRun 4K Quatro

Post by m_theredhead »

Hello,

Is there any word or a thread discussing what software will support the new HDHomeRun 4K Quatro when it is released?

I know there was some discussion of it on the mythtv mailing list, but I was wondering about other software like Plex, etc.

jasonl
Expert
Posts: 15341
Joined: Sun Oct 28, 2007 9:23 pm
x 7

Re: Software support for new HDHomeRun 4K Quatro

Post by jasonl »

The basic mode for the 4K is that tuning by vchannel (i.e. http tuning that is used by the HDHomeRun DVR, Plex and many other apps) will repackage the broadcast into a standard MPEG TS that is basically the same as what comes from a legacy ATSC broadcast, albeit with whatever audio and video codecs the broadcaster happens to be using. This will allow many applications to continue working with little to no modification assuming they support the audio and video codecs that your local broadcaster happens to be using. There's potentially a lot more to ATSC 3 than just the video and audio data though, and anything beyond the basic support is almost certainly going to require any applications that want to support it to actually implement the ATSC 3 specs themselves. How all of that will work with the hardware is likely something that will be developed over time. Silicondust has always been open to opening things up (where possible) to third-party developers to let them write their own software to work with the HDHomeRun hardware, and I expect that to continue on with this new model. And of course none of those developers are able to commit to anything before they have hardware to work with and actual broadcasts to use it with.

wayner
Posts: 12
Joined: Sat Aug 24, 2013 9:10 am

Re: Software support for new HDHomeRun 4K Quatro

Post by wayner »

I am a longtime SageTV user and HDHR products have been very well supported in SageTV in the past. The hope is that ATSC 3.0 files should also work in SageTV assuming that you have the correct client devices to playback 4K and HEVC - where that is applicable. This is an issue as the best client for SageTV have been proprietary SageTV extenders like the HD300 and HD200 which are now about a decade old and cannot play 4K or HEVC, unless transcoded. Generally on a LAN SageTV does not transcode.

Hopefully it takes no, or very little, work to implement in SageTV as the SageTV development community has been shrinking in recent years.

jasonl
Expert
Posts: 15341
Joined: Sun Oct 28, 2007 9:23 pm
x 7

Re: Software support for new HDHomeRun 4K Quatro

Post by jasonl »

I think OpenDCT supports vchannel tuning with all modern HDHomeRun devices, so that would probably work either out of the box or with minor modifications, assuming SageTV itself can figure out how to decode HEVC and whatever audio codec is in use. I would not expect any effort to be made to try to hammer a square peg into a round hold to make the legacy BDA system work.

RonRN18
Posts: 5
Joined: Sun Jan 24, 2016 2:04 pm

Re: Software support for new HDHomeRun 4K Quatro

Post by RonRN18 »

jasonl wrote: Sat Aug 22, 2020 9:00 pm The basic mode for the 4K is that tuning by vchannel (i.e. http tuning that is used by the HDHomeRun DVR, Plex and many other apps) will repackage the broadcast into a standard MPEG TS that is basically the same as what comes from a legacy ATSC broadcast, albeit with whatever audio and video codecs the broadcaster happens to be using. This will allow many applications to continue working with little to no modification assuming they support the audio and video codecs that your local broadcaster happens to be using. There's potentially a lot more to ATSC 3 than just the video and audio data though, and anything beyond the basic support is almost certainly going to require any applications that want to support it to actually implement the ATSC 3 specs themselves. How all of that will work with the hardware is likely something that will be developed over time. Silicondust has always been open to opening things up (where possible) to third-party developers to let them write their own software to work with the HDHomeRun hardware, and I expect that to continue on with this new model. And of course none of those developers are able to commit to anything before they have hardware to work with and actual broadcasts to use it with.
I know this is probably a stupid question but, when stated that it will repackage into a standard MPEG TS, that does not mean the MPEG-2 CODEC, does it? If the native CODEC is HEVC, it will still remain in HEVC, correct?

signcarver
Expert
Posts: 9247
Joined: Wed Jan 24, 2007 1:04 am
Device ID: 10802091 131B34B7 13231F92 1070A18E 1073ED6F 15300C36
x 15

Re: Software support for new HDHomeRun 4K Quatro

Post by signcarver »

The codec used inside the mpeg transport stream may or may not use the mpeg 2 codec... typically ATSC 3.0 is expected to use HEVC or h.264 for video... audio for most will probably continue to be AC3 but may use eac3, ac4 or aac.

Since the device does not do any transcoding, what is in the stream will be whatever was broadcast.

nickk
Silicondust
Posts: 16086
Joined: Tue Jan 13, 2004 9:39 am
x 35

Re: Software support for new HDHomeRun 4K Quatro

Post by nickk »

ATSC 3.0 - video is always HEVC. Audio will usually be AC4 but is sometimes AAC.

Nick

jsmar
Posts: 24
Joined: Wed Aug 13, 2008 1:06 am

Re: Software support for new HDHomeRun 4K Quatro

Post by jsmar »

The HDHomeRun 4K and PLP's announcement shows a version of hdhomerun_config that has support for ATSC 3.0 that I don't think is in the most recent 20200907 version. Is that version available (with the source)?

Trip
Posts: 18
Joined: Sat Aug 07, 2010 6:49 am
Location: Alexandria, VA, USA
Contact:

Re: Software support for new HDHomeRun 4K Quatro

Post by Trip »

I have the same question as jsmar (hello!). I was going to grab the latest Linux software (both library and GUI) but it looks like the latest release on the website is from 9/7/2020.

- Trip

nickk
Silicondust
Posts: 16086
Joined: Tue Jan 13, 2004 9:39 am
x 35

Re: Software support for new HDHomeRun 4K Quatro

Post by nickk »

jsmar wrote: Sun Oct 11, 2020 1:59 am The HDHomeRun 4K and PLP's announcement shows a version of hdhomerun_config that has support for ATSC 3.0 that I don't think is in the most recent 20200907 version. Is that version available (with the source)?
The screenshots are from the Windows version of HDHomeRun Config GUI - included with 20201009. The PLP options will only show when an ATSC 3.0 channel is tuned.

Nick

jsmar
Posts: 24
Joined: Wed Aug 13, 2008 1:06 am

Re: Software support for new HDHomeRun 4K Quatro

Post by jsmar »

OK. But the most important part of that question was can I get the source. I have code that does its own scan and I currently have no idea how that changes with an ATSC 3.0 station. Since so far the only documentation regarding this is the "HDHomeRun 4K and PLP's" post, I figured the code would provide more details.

I'm trying to get some clarity on the plp information. It seems that you specify a PLP when tuning a station, but you can't get the plpinfo until you have tuned a station. So I'm guessing the process is to first tune a station specifying atsc3 modulation without specifying a PLP. That will tune the "first" PLP (not sure if that is always PLP 0), but that will also populate the plpinfo information so that you can now specifically tune a particular PLP. So what is the format of information returned from a get request of /tuner<n>/plpinfo?

I'm also wondering about parity of signal statistics. Let's say I first try to tune the station as an ATSC 1.0 station by specifying 8vsb modulation. If that locks then I know it is an ATSC 1.0 station and there is no reason to also try to tune it as an ATSC 3.0 station. But if it doesn't lock, can I uses the signal strength seen while reading from /tuner<n>/status while attempting to get an 8vsb lock to determine whether it doesn't make sense to even try to tune the station using atsc3 modulation?

Another possible chicken/egg problem is the ability to tune multiple simultaneous PLP's. Is there any way to programmatically determine purely from the plpinfo information which PLP's can be tuned simultaneously? Or do I need to tune each individual PLP, parse information from the raw ALP stream, and then use that information to later determine which PLP's can be tuned simultaneously?

John

Post Reply