johnb-7 / hdhr-ac4 Goto Github PK

This project aims to emulate an HDHomerun tuner that supplies ATSC 3.0 programs with AC3 audio.

License: Apache License 2.0

Dockerfile 20.10% Python 79.90%

hdhr-ac4's Introduction

hdhr-ac4 v1.5.0

Update

May 2024 Added docker image to GitHub Container Registry. This can be used instead of building your own. It was built using the latest repo and "emby-server-deb_4.8.0.21_amd64.deb" for ffmpeg.

Quick start:

docker run -p 80:80 -p 5004:5004 -e "HDHR_IP=192.168.1.1" -e "HOST_IP=192.168.1.2" -e "DEVICEID_SWAP=1" ghcr.io/johnb-7/hdhr-ac4:1.5

I have been using this with Plex DVR for quite some time. It has been rock solid and reliable. DRM has been enabled on all but one channel in Atlanta. Maybe one day DRM will be sorted out and I can get all the channels again. It was fun while it lasted.

Description

This project aims to emulate an HDHomerun tuner that supplies ATSC 3.0 programs with AC3 audio.

About

This project started as a way for me to support ATSC 3.0 programs on my home netowrk. I already have an HDHR5-4k tuner and thought the transition would be straight forward when ATSC 3.0 programs went live in Atlanta. The signal and video quality were much better, but the AC4 audio every program was using was supported by nothing I owned.

This application pretends to be an HDHomerun device that offers ATSC 3.0 programs. When a request comes in to tune one of the programs, it forwards that request to a real HDHomerun device and passes the resulting stream back to the original requester after converting the AC4 audio stream to AC3 audio.

Why?

This allows my HDHR5-4K to serve ATSC 3.0 programs to my Emby server(now native support?) and PLEX server with Live TV and DVR functionality. Converting audio to AC3 before the server receives it allows everything to work as it always has with HDHomerun tuners.

Configuration

Set in docker environent

HDHR_IP - REQUIRED. The IP address of your real HDHomerun device

HOST_IP - REQUIRED. The IP address where hdhr-ac4 is running

DEVICEID_SWAP - OPTIONAL (1 or 0, default 0) If the Device of the HDHomerun you are connecting to should be reversed. This ensures you have a unique DeviceID to prevent any collision with your physical HDHomerun device.

hd_home_run.py

Contains the ffmpeg command:

[
    "/bin/usr/ffmpeg",
    "-nostats",
    "-hide_banner",
    "-loglevel",
    "warning",
    "-i",
    "pipe:",
    "-c:a",
    "ac3",
    "-c:v",
    "copy",
    "-f",
    "mpegts",
    "-",
]

This should not need to be changed, but can be modified if the ATSC 3.0 streams needs specifi ffmpeg handling.

Build Docker Container

Download the latest Emby installer from https://emby.media/linux-server.html and save it in the docker build directory. Update Dockerfile to point to the file. Currently using emby-server-deb_4.8.0.21_amd64.deb Example Dockerfile build command:

docker build -f Dockerfile -t hdhr-ac4 .

This build uses ffmpeg binary from Emby. The Emby team has a custom version of ffmpeg tha has several improvements over the original ffmpeg branch. Version 1.0.0 of this docker build created the custom ffmpeg from scratch which took much longer and is a little dated at this point. A quick explanation for the docker build that is based on ubuntu 20:

The ffmpeg container extracts Emby installer

The final container copies in ffmpeg binaries. Python is installed and a few python modules added. The 2 python files are copied over and the launch command is set.

Run Docker container

Example container run command:

docker run -p 80:80 -p 5004:5004 -e "HDHR_IP=10.1.1.2" -e "HOST_IP=10.0.0.100" -e "DEVICEID_SWAP=1" hdhr-ac4

The HDHomerun API being implemented is here: https://info.hdhomerun.com/info/http_api

The container runs HTTP servers on port 80 and 5004 and supports the following HTTP requests:

http://HOST:80/ - returns info and version about hdhr-ac4 docker

http://HOST:80/discover.json - returns the same response as the real HDHomerun device, but substitutes the hdhr-ac4 IP address in the appropriate locations.

http://HOST:80/lineup.json - queries the real HDHomerun device for its service list and then does the following:

replaces all the IP addresses with the hdhr-ac4 IP address

strips out all non ATSC3 programs

http://HOST:5004/auto/{program} - forwards the request to the real HDHomerun device, and then pipes the stream through ffmpeg and then back to the orignal requester

http://HOST:80/lineup_status.json - returns the same response as the real HDHomerun device

Notes

Please report issues or send pull requests here: https://github.com/johnb-7/hdhr-ac4

Channel changes are a little slower due to the extra step

VLC was used a lot in the early testing. Example URL for host 192.168.1.1 with program 111.1: http://192.168.1.1:5004/auto/v111.1

The development container (Dockerfile-dev) is very similar but does not automatically launch the application and can be mounted using your editor of choice for debugging the Python application or ffmpeg. It also installs some extra software specifically for development.

Many thanks to the Emby team for the ffmpeg with working AC4. Since its open source software, there should not be any problems here.

License

This project is release under the Apache 2.0 license

hdhr-ac4's People

Contributors

Stargazers

Watchers

Forkers

gunsuka owenb321 whichken kylesanderson fearthecowboy epijunkie robbadler ricksterlab themoosman cr08 scacner

hdhr-ac4's Issues

Discoverable by/compatible with HDHR app?

I have my HDHR Connect 4K set up with Emby and all is fine, but it would be great if this service could be natively used by the HDHR app. On my HiSense Android TV, if I stream any ATSC 3 channels, there won't be any audio, as there's no built-in support for AC4. Using the Emby app is a solution of course, but sometimes I prefer to watch things a bit more real time (i.e. sports).

Not sure if that's possible, but awesome work on this either way.

Trying to figure out how to use binary in other docker containers

Hello,

I'd like to be able to use the ffmpeg binary in other docker containers. If all docker containers are using the same OS (ubuntu:latest for example) should I be able to copy the libraries from /usr/lib and the ffmpeg executable from /usr/bin/ffmpeg into the new container?

I did try this and it seemed to run but the AC4 appeared not to be processed when pushing a stream into ffmpeg.

Do you think this is possible? am I missing a step?
I tried moving the Dockerfile to ubuntu:latest to make sure they match but then it complains that python isn't available. I changed the apt-get to use python3 rather than python but now i get other errors that I am unclear how to resolve

checking for xcb-proto >= 1.13... no
configure: error: Package requirements (xcb-proto >= 1.13) were not met:

Variable 'PYTHON_PREFIX' not defined in '/opt/ffmpeg/lib/pkgconfig/xcb-proto.pc'

--UPDATE1--
I tried changing the deps line from python to python2 but i get the same error still

Additional question. If i'm trying to do the transcoding in another docker and use this ffmpeg executable is there something obvious i am missing here? I believe the -c:a ac3 is the key component here to convert the ac4 to ac3?

-hide_banner -loglevel error -i [URL] -c:a ac3 -c:v copy -f mpegts pipe:1

appreciate any assistance.

Plex not detecting audio stream

Plex is unable to detect an audio stream. Audio works perfectly fine when viewed in VLC.

Can't tune stations using mod=qam16

I have 4 non DRM stations in my area that I can tune to. 3 of them work fine, the ones using mod=qam256. When I try to tune the one channel that is using mod=qam16 I get the error, "Could not tune channel. Please check your tuner or antenna." All four channels work fine with the HDHR software.

Issue with docker build

Any idea what this means? trying to build this on my Synology device

SKIP: tests/test_shutdown_stress_tipc
SKIP: tests/test_sub_forward_tipc
PASS: tests/test_term_endpoint_tipc
SKIP: tests/test_address_tipc
PASS: tests/test_abstract_ipc
PASS: tests/test_security_curve
PASS: tests/test_socks
./config/test-driver: line 107: 21190 Alarm clock "$@" > $log_file 2>&1
FAIL: tests/test_many_sockets

Testsuite summary for zeromq 4.3.2

TOTAL: 100

PASS: 92

SKIP: 7

XFAIL: 0

FAIL: 1

XPASS: 0

ERROR: 0

============================================================================
See ./test-suite.log
Please report to [email protected]

make[3]: *** [Makefile:7041: test-suite.log] Error 1
make[3]: Leaving directory '/home/libzmq'
make[2]: *** [Makefile:7149: check-TESTS] Error 2
make[2]: Leaving directory '/home/libzmq'
make[1]: *** [Makefile:8174: check-am] Error 2
make[1]: Leaving directory '/home/libzmq'
make: *** [Makefile:6926: check-recursive] Error 1
The command '/bin/sh -c DIR=/home/libzmq && mkdir -p ${DIR} && cd ${DIR} && curl -sLO https://github.com/zeromq/libzmq/archive/v${LIBZMQ_VERSION}.tar.gz && echo ${LIBZMQ_SHA256SUM} | sha256sum --check && tar -xz --strip-components=1 -f v${LIBZMQ_VERSION}.tar.gz && ./autogen.sh && ./configure --prefix="${PREFIX}" && make && make check && make install && echo rm -rf ${DIR}' returned a non-zero code: 2

Publish to GHCR

Hello! I am wondering if there's any plans to publish this project to GHCR?

Errors in readme

The readme referencing lineup.json contains some incorrect (maybe just outdated?) info:

replaces the ATSC3=1 entry with AudioCodec=AC3

There are two errors here-

The actual HDHomeRun's lineup.json doesn't contain any ATSC3=1 entries.
hdhr-ac4's lineup.json doesn't contain AudioCodec=AC3 anywhere. It only contains AudioCodec=AC4 entries. (However streamed output audio is still encoded as AC3.)

I'm not sure if this means the documentation just needs updating, or if it means the code isn't doing what's intended.

Buffering Issue

Getting this error when streaming an ATSC 3 channel.

2023-03-05 19:41:36 INFO: 172.17.0.1:38416 - "GET /auto/v161.1 HTTP/1.1" 200 OK 2023-03-05 19:41:48 [mpegts @ 0x23aa1c0] Could not find codec parameters for stream 3 (Audio: ac4 (AC-4 / 0x342D4341), 0 channels, fltp): unspecified sample rate 2023-03-05 19:41:48 Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options 2023-03-05 19:43:28 INFO: 172.17.0.1:44232 - "GET /auto/v161.1 HTTP/1.1" 200 OK 2023-03-05 19:43:43 [mpegts @ 0x13261c0] Could not find codec parameters for stream 3 (Audio: ac4 (AC-4 / 0x342D4341), 0 channels, fltp): unspecified sample rate 2023-03-05 19:43:43 Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options 2023-03-05 19:44:15 [ac4 @ 0x143e100] substream audio data overread: 4 2023-03-05 19:44:15 Error while decoding stream #0:1: Invalid data found when processing input

It streams for a couple of minutes and then starts buffering, right when it says "Error while decoding stream". My PC is wired with Ethernet. Any guesses?

works well with a couple tweaks

I was able to get his docker container spun up and running pretty quickly, but had to make a couple tweaks to the Dockerfile:

Line 518: change git repo to https://github.com/makrsmark.git (old one no longer has an AC4 branch; got new repo from https://trac.ffmpeg.org/ticket/8349, so hopefully it's reputable enough)
Line 533: comment out --enable-avresample \

For ref, i built this inside a Ubuntu 22.04 LXC container and after the build it worked flawlessly right out of the box.

Thank you for pulling this together!