Create an HDHomeRunIngestionEngine

[slifty]

Task

Description

Now that we have the framework for making ingestion engines close enough to where we want it for now, lets create the HDHomeRunIngestionEngine.

This will take an HD Home Run's video stream and pipe it into TV Kitchen.

Relevant Resources / Research

@reefdog has done a bunch of research around HD Home Runs and working with them; I'm hoping he can populate some of that research here.

Related Issues

A list of related issues

[reefdog]

So, yes!

Setting up and listening to your HDHomeRun

Once you have your HDHomeRun installed, you go to the magic website my.hdhomerun.com. That detects the HDHomeRun on your network and produces a screen like this:

Clicking any of those green links in the white box takes you to your device. The channel one takes you to a channel tuner that looks like this:

Each channel number points to a URL like http://192.168.0.100:5004/auto/v7.1, which is an HTTP stream you can open directly in something like VLC or FFplay, or pass into FFmpeg. I created a simple FFmpeg re-broadcaster (back when we thought that's what we'd be doing to get data from the ingesters into the countertop) with:

# In first tab:
ffmpeg -i http://192.168.0.100:5004/auto/v7.1 -f mpegts udp://localhost:23000

# In second tab:
ffplay udp://localhost:23000

What we would do for an ingestion engine would be different, of course. I assume we'd use Node to get the stream and pass it to getInputStream().

Image quality/compression

You can use ffprobe to inspect what the stream composition will be if you want, e.g.:

ffprobe http://192.168.0.100:5004/auto/v56.1
# ……some stuff removed here
Input #0, mpegts, from 'http://192.168.0.100:5004/auto/v56.1':
  Duration: N/A, start: 6667.963189, bitrate: N/A
  Program 3 
    Stream #0:0[0x31]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x34](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x35](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s (visual impaired)

Some HDHomesRun will let you request a lower-resolution or more highly-compressed version of the video, but my CONNECT doesn't:

Unlike the CONNECT and PRIME which only stream raw mpeg2 HD streams, the EXTEND features a hardware h264 transcoder which can compress video in real-time for lower bandwidth usage.

On some forum (which I frustratingly cannot find right now Update: not that it matters, but found it), it demonstrated how to append something like ?transcode=720 to the stream URLs to access those compressed variants. That of course never changed what stream I got (since my device doesn't support it), but it also didn't break it, so if we decide that one of those compressed variants is Good Enough, it may be worth requesting those variants to reduce some pipeline resource consumption.

Edit: It looks if your HDHomeRun supports transcode configuration, you'll have a Transcode Configuration preference screen. Those docs also mention the three transcoding options are "mobile (up to 720p30), heavy (up to 1080i60 / 720p60), and native (no transcode)".

Prior Work

I hacked away at some of this in the 14-explore-ffmpeg and 21-add-first-ingestion-engine branches. I don't think much of any of that work needs to be saved or re-used, but, it's there if you want it. Bear in mind it reflected a very early understanding where we thought the ingester would re-broadcast data via UDP for the Countertop to listen for.

[reefdog]

I tell you what would be pretty cool would be a simple Node package that would essentially do the work of producing that channel list for you, either by detecting the HDHomeRun on your network, or by starting at my.hdhomerun.com and scraping its way to a channel list. We could leverage that in our friendly setup CLI.

[chriszs]

So it sounds like what we want is an HTTP ingestion engine.

And then perhaps somewhere a convenience wrapper around it for HDHomeRun specifics.

The convenience wrapper might:

1. Look up device IP and port given a DeviceID, or provide a list of devices using the API at http://ipv4-api.hdhomerun.com/discover
2. Look up a channel number using a channel name, or provide a list using the API at http://<device ip>/lineup.json

The list option seems like not a good fit for the ingestion engine as currently specced, so at best we'd be providing a convenience lookup at this level.

[chriszs]

Okay, so my plan is:

1. If an IP or network name is provided, it will construct a URL around that.
2. If not, it will look up the devices on the network using the discovery URL.
3. If a device ID is specified, it will use the URL for that device.
4. If not, it will use the URL of the first device listed, warn or error if there are multiple devices.
5. Then, if a channel is specified, it will find that channel in the lineup.json by checking by both name and number, allowing partial matches.