AndroidHDMI for Channels (ah4c): A virtual channel tuner using HDMI Encoder(s) + streaming stick(s)

Playground
,
#1149

It would really cool to test some of these new features like the closed caption functionality with apple tv based tuners on apple silicon based machines.

@mackid1993 is your build , especially the closed caption functionality , capable of running on Apple Silicon based machines - in docker. The closed capture feature addition for encoder based streams is awesome.

@bnhf any chance of doing the merge you mentioned several weeks ago of the ah4c:apple TV branch into the main ah4c branch like you were thinking earlier?

Would this mean the underlying VM OS that @mackid1993 is using in his beta is the same as the one used for the ah4c apple tv folks? Or would the extra new env variable you mentioned preclude using these new beta features?

Happy to lend a hand testing.

2 Likes
#1150

The model should run on ARM64 under Linux/Docker. It just depends on whether @bnhf released an ARM64 build. I think this will probably stay on its own sort of branch for now, away from Apple TV until we get it 100% stable with Android TV.

That's up to the core maintainers though, not really me. I have an Apple TV to watch TV on, but I don't have an Apple TV to use as a tuner. I also don't know what you mean by VM OS. This is just a Docker container. There's no VM involved. You know, besides the Docker environment, I think there's a misunderstanding here.

In terms of the actual closed captions, that's more dependent on the encoder than the tuner. It's slipstreaming into the MPEG TS stream. It doesn't really have anything to do with what tuner is used.

Otherwise the only issue you're going to have running on an Apple device is going to be running on the CPU. Unless dev/dri works on Apple.

I would really suggest running this under Linux. I really am someone that doesn't recommend running Docker on macOS ever. But if you have to, I'm not 100% sure GPU acceleration certain will work.

Edit: There is an ARM64 image, so I would just give it a shot and see if it works.

1 Like
#1151

I still want to do that. I'll see if I can build a combined image tomorrow under the beta tag.

1 Like
#1152

Before you rebuild, I'm experimenting with some more models right now. I'm looking to see what else is out there on Hugging Face that might be more accurate. The ones we have are really lightweight and fast, but for those with like powerful systems, there might be better options.

I'm actually adding my personal favorite model that I'm actually talking into right now, Cohere Transcribe. It's crazy fast and just works super well.

Update:

Just fixing some bugs, but Cohere Transcribe is next level and runs great on my 12700K iGPU. I'm going to mark it as GPU only because I can't see how it could possibly run on a CPU without cooking the damn thing, but this is going to be a good one. It really looks like broadcast quality transcription.

#1153

I'm going to go ahead and build a first test image for the :appletv crowd to try. It doesn't sound like Cohere Transcribe is going to be a model they'd choose anyway -- at least out of the gate. What I'm working towards here, is a combined ah4c image that works for both adb and atv -- with the new interface, and hopefully at least the CPU-based closed caption models.

#1154

For those running on servers with Intel CPUs and AMD CPUs and GPUs, this model is insane. I mean, it's using like 1% CPU with the iGPU dev/dri passed. Also, the GPU models are going to be totally gated. So, if you don't have a GPU passed, it won't even let you pick it. It'll tell you very clearly this is not going to run well in your system.

#1155

@mnwxman132 I've built a first crack at a combined image under a beta2 tag. Here's the Docker Compose, and sample env vars I'd like you to use:

services:
  # 2026.08.16
  # GitHub home for this project with setup instructions: https://github.com/sullrich/ah4c
  # Docker Hub home for this project: https://hub.docker.com/repository/docker/bnhf/ah4c
  ah4c:
    image: bnhf/ah4c:${TAG:-latest}
    container_name: ah4c
    hostname: ah4c
    dns_search: ${DOMAIN:-localdomain} # Specify the name of your LAN's domain, usually local or localdomain
    runtime: ${DOCKER_RUNTIME:-runc} # Closed captions only. Set DOCKER_RUNTIME=nvidia for an NVIDIA GPU with the CUDA engine build. Requires the NVIDIA container toolkit
    devices:
      - ${GPU_DEVICE:-/dev/null} # Closed captions only. Set GPU_DEVICE=/dev/dri to let the Vulkan engine build use an Intel or AMD GPU. Left at the default it passes /dev/null, which always exists and does nothing
    ports:
      - ${ADBS_PORT:-5037}:5037 # Port used by adb-server
      - ${HOST_PORT:-7654}:7654 # Port used by this ah4c proxy
      - ${WSCR_PORT:-8000}:8000 # Port used by ws-scrcpy
    environment:
      - IPADDRESS=${IPADDRESS} # Hostname or IP address of this ah4c extension to be used in M3U file (also add port number if not in M3U)
      - NUMBER_TUNERS=${NUMBER_TUNERS} # Number of tuners you'd like defined - add a matching TUNERn_IP and ENCODERn_URL line below for each beyond 9
      - TUNER1_IP=${TUNER1_IP} # Streaming device #1 with adb port in the form hostname:port or ip:port
      - TUNER2_IP=${TUNER2_IP} # Streaming device #2 with adb port in the form hostname:port or ip:port
      - TUNER3_IP=${TUNER3_IP} # Streaming device #3 with adb port in the form hostname:port or ip:port
      - TUNER4_IP=${TUNER4_IP} # Streaming device #4 with adb port in the form hostname:port or ip:port
      - TUNER5_IP=${TUNER5_IP} # Streaming device #5 with adb port in the form hostname:port or ip:port
      - TUNER6_IP=${TUNER6_IP} # Streaming device #6 with adb port in the form hostname:port or ip:port
      - TUNER7_IP=${TUNER7_IP} # Streaming device #7 with adb port in the form hostname:port or ip:port
      - TUNER8_IP=${TUNER8_IP} # Streaming device #8 with adb port in the form hostname:port or ip:port
      - TUNER9_IP=${TUNER9_IP} # Streaming device #9 with adb port in the form hostname:port or ip:port
      - ENCODER1_URL=${ENCODER1_URL} # Full URL for tuner #1 in the form http://hostname/stream or http://ip/stream
      - ENCODER2_URL=${ENCODER2_URL} # Full URL for tuner #2 in the form http://hostname/stream or http://ip/stream
      - ENCODER3_URL=${ENCODER3_URL} # Full URL for tuner #3 in the form http://hostname/stream or http://ip/stream
      - ENCODER4_URL=${ENCODER4_URL} # Full URL for tuner #4 in the form http://hostname/stream or http://ip/stream
      - ENCODER5_URL=${ENCODER5_URL} # Full URL for tuner #5 in the form http://hostname/stream or http://ip/stream
      - ENCODER6_URL=${ENCODER6_URL} # Full URL for tuner #6 in the form http://hostname/stream or http://ip/stream
      - ENCODER7_URL=${ENCODER7_URL} # Full URL for tuner #7 in the form http://hostname/stream or http://ip/stream
      - ENCODER8_URL=${ENCODER8_URL} # Full URL for tuner #8 in the form http://hostname/stream or http://ip/stream
      - ENCODER9_URL=${ENCODER9_URL} # Full URL for tuner #9 in the form http://hostname/stream or http://ip/stream
      - STREAMER_APP=${STREAMER_APP} # Streaming device name and streaming app you're using in the form scripts/streamer/app (use lowercase with slashes between as shown)
      - PYATV=${PYATV:-false} # Set to TRUE to run docker-start-pyatv.sh at container start for Apple TV tuners via pyatv, instead of the default docker-start.sh used for adb-based tuners. Case-insensitive; anything else runs the default.
      - CHANNELSIP=${CHANNELSIP} # Hostname or IP address of the Channels DVR server itself
      - ALERT_SMTP_SERVER=${ALERT_SMTP_SERVER} # The domainname:port of the SMTP server you'll be using like smtp.gmail.com:587. This is for sending ah4c alerts if tuning fails.
      - ALERT_AUTH_SERVER=${ALERT_AUTH_SERVER} # The auth server for the e-mail you'll be using like smtp.gmail.com
      - ALERT_EMAIL_FROM=${ALERT_EMAIL_FROM} # The e-mail address you'd like your ah4c failure alert e-mails to show as being from.
      - ALERT_EMAIL_PASS=${ALERT_EMAIL_PASS} # Gmail and Yahoo both support the creation of app-specific e-mail passwords, and this is the way to go! It's NOT recommended to use your everyday e-mail password.
      - ALERT_EMAIL_TO=${ALERT_EMAIL_TO} # The e-mail address you'd like your alert e-mails sent to.
      #- ALERT_WEBHOOK_URL=""
      - LIVETV_ATTEMPTS=${LIVETV_ATTEMPTS} # For FireTV Live Guide tuning only, set maximum number of attempts at finding the desired channel
      - CREATE_M3US=${CREATE_M3US:-false} # Set to true to create device-specific M3Us for use with Amazon Prime Premium channels -- requires a FireTV device
      - UPDATE_SCRIPTS=${UPDATE_SCRIPTS:-true} # Set to true if you'd like the sample scripts and STREAMER_APP scripts updated whether they exist or not
      - UPDATE_M3US=${UPDATE_M3US:-true} # Set to true if you'd like the sample m3us updated whether they exist or not
      - TZ=${TZ} # Your local timezone in Linux "tz" format
      - SPEED_MODE=${SPEED_MODE:-false} # Set to false if you'd like the target streaming app to be closed after each tuning cycle (limited script support).
      - KEEP_WATCHING=${KEEP_WATCHING} # In supported scripts, set the delay before resending a tuning deeplink to prevent "Are you still watching?" type messages. Examples: Use 4h for 4 hours or 240m for 240 minutes.
      - NULL_FRAME_INSERTION=${NULL_FRAME_INSERTION:-false} # Set to TRUE to fill encoder stalls with MPEG-TS NULL packets (PID 0x1FFF) so the DVR never sees a zero-byte gap mid-recording. Case-insensitive (true/True/TRUE all work); anything else, including 1/yes, leaves the feature off.
      - PLAYBACK_DETECTION=${PLAYBACK_DETECTION:-false} # Set to TRUE to hold the stream until the device reports media audio playing and the picture is actually moving, then start on a keyframe, so a recording begins on the program rather than on the app's loading screen. Requires adb access to the tuner; network tuners only. Case-insensitive (true/True/TRUE all work); anything else, including 1/yes, leaves the feature off.
      - PLAYBACK_DELAY=${PLAYBACK_DELAY} # Set to a whole number of seconds to skip the start of each tune, so a recording begins on the program rather than on the app's loading screen. Piped through the bundled ffmpeg with -ss and stream copy; no re-encoding, and the skip starts on the next keyframe so it can run slightly past the configured value. The value is the total tune time, scripts included. Supported range is 2 to 30, since the DVR allows a tune about 30 seconds; values outside the range are clamped and logged. Ignored when PLAYBACK_DETECTION is TRUE; network tuners only. 0 or unset leaves the feature off.
      - HEARTBEAT_INTERVAL=${HEARTBEAT_INTERVAL:-0} # In supported scripts (currently osprey), seconds between keepalive keyevents sent during playback to stop the app's UI inactivity timer from resetting the stream. Set to 0 to disable.
      - NVIDIA_VISIBLE_DEVICES=${NVIDIA_VISIBLE_DEVICES} # Closed captions only. Set to all alongside DOCKER_RUNTIME=nvidia to expose an NVIDIA GPU. Empty means no GPU and is the default
      - NVIDIA_DRIVER_CAPABILITIES=${NVIDIA_DRIVER_CAPABILITIES} # Closed captions only. Set to compute,utility when using an NVIDIA GPU, so the driver the CUDA engine build needs is passed in
    volumes:
      - ${HOST_DIR}/ah4c/scripts:/opt/scripts # pre/stop/bmitune.sh scripts will be stored in this bound host directory under streamer/app
      - ${HOST_DIR}/ah4c/m3u:/opt/m3u # m3u files will be stored here and hosted at http://<hostname or ip>:7654/m3u for use in Channels DVR - Custom Channels settings
      - ${HOST_DIR}/ah4c/adb:/root/.android # Persistent data directory for adb keys
      - ${HOST_DIR}/ah4c/captions:/opt/captions # Closed caption settings, and the speech model, engine and any GPU driver downloaded from the Closed Captions page. Stays empty unless you turn captions on
    restart: unless-stopped

Sample env vars:

TAG=latest
DOMAIN=localdomain tailxxxxx.ts.net
DOCKER_RUNTIME=runc
GPU_DEVICE=/dev/null
ADBS_PORT=5037
HOST_PORT=7654
SCRC_PORT=7655
IPADDRESS=htpc6:7654
NUMBER_TUNERS=5
TUNER1_IP=firestick-rack1:5555
ENCODER1_URL=http://encoder_48007/0.ts
TUNER2_IP=firestick-rack2:5555
ENCODER2_URL=http://encoder_48007/4.ts
TUNER3_IP=firestick-rack3:5555
ENCODER3_URL=http://encoder_48007/8.ts
TUNER4_IP=firestick-rack4:5555
ENCODER4_URL=http://encoder_48007/12.ts
TUNER5_IP=firestick-travel2:5555
ENCODER5_URL=http://encoder_23393/0.ts
STREAMER_APP=scripts/firetv/dtvdeeplinks
PYATV=true
CHANNELSIP=media-server6
ALERT_SMTP_SERVER=smtp.gmail.com:587
ALERT_AUTH_SERVER=smtp.gmail.com
[email protected]
ALERT_EMAIL_PASS=xxxxxxxxxxxxxxxx
[email protected]
UPDATE_SCRIPTS=true
UPDATE_M3US=true
TZ=America/Denver
SPEED_MODE=false
KEEP_WATCHING=4h
NULL_FRAME_INSERTION=false
PLAYBACK_DETECTION=false
PLAYBACK_DELAY=0
HEARTBEAT_INTERVAL=0
HOST_DIR=/data
NVIDIA_VISIBLE_DEVICES=
NVIDIA_DRIVER_CAPABILITIES=
#1157

I should have a pretty big release ready soon on my own fork with a couple of new models to try. And just some general bug fixes. I'm putting a big focus on concurrent streams right now and making sure captions don't fall behind when you have like five tunes going.

#1158

@bnhf Should I just rebuild with TAG=beta2 instead of TAG=appletv? Is there a risk I loose all my settings?

Thank you both for your work here!

#1159

Yes.

Nothing in your persistent data directories should be touched. What settings are you specifically concerned about?

#1160

Turns out that Cohere Transcribe isn't as heavy as I thought it was. It should really be for iGPUs or real GPUs if you have one, but I think most people can use it. I expect to have something kind of soon that people can test out. I'm just still running into issues with it falling behind, and pretty much everything falling behind when a couple of tunes are going at once. But ultimately, my goal is to have Parakeet as a model for just smaller systems and Cohere as the model for people running larger servers. Just in terms of accuracy to performance trade offs, that seems to be the best pick if you just want a clean split and ease of use. Also, Cohere doesn't use a whole lot of RAM. It uses about 2 GB and it can share it.

Edit: It turns out Cohere Transcribe also runs pretty well on CPU, like, reasonably well. 6x realtime on my 12700k with a 3 streams going.

#1161

Nothing in particular. It's been working great for the last few weeks. I'll go ahead with it and let you know.

#1162

I did a huge amount of work today, and I'm almost ready to push something and make it available on a test tag on my own repository.

So, Cohere Transcribe can run on my five year old 12700K easily five streams just with CPU backing no GPU at all, but I recommend one to three on CPU with no integrated graphics support or anything like that. It just gets a little warm. More are obviously doable, like I stated, but it might start to impact other services running. That's why it's useful if you don't have any sort of integrated graphics to exclude tuners from closed captioning if you do choose to use Cohere. The nice thing about Cohere is it can share memory across tuners, so it really doesn't use a whole lot of RAM. With Vulkan as the back end, it doesn't even break a sweat. I'm marking that the recommended model for most people because it runs on a CPU just fine and it's extremely accurate, like broadcast quality accurate.

Now, I added a second model, and it's just very small. I haven't really tested it much yet. And it's meant for just very small machines like Synology's running a Celeron.

I'm going to update this comment once I'm ready for people to actually test.

Update ghcr.io/mackid1993/ah4c:beta

You must reinstall the Vulkan drivers. The ones that are from yesterday's build are out of date. Really out of date. I found they were from 2022.

You just go and download them on the captions page.

Then you want to download Cohere Transcribe, which is there and available for download in the captions page as well. It works just fine on CPU especially if you only have a few tuners. If you have more than a few, my 12700K, which is several years old, works just fine with iGPU. I have not tested the NVIDIA path yet and won't be because I don't have the hardware to do so. So, hopefully, someone can test that.

I also added another model called Moonshine Streaming Tiny which is surprisingly accurate and extremely lightweight. This will run on CPU with several concurrent streams really quickly with minimal CPU usage. So for the CPU path, especially those running on like a tiny Synology, this is the way to go. For those with integrated graphics, please use Cohere Transcribe. It's a much nicer experience. It works really well and is really close to broadcast quality.

I kept it to just two models and nixed Parakeet because honestly it was transcribing things terribly in my opinion. Cohere works best for most people with most computers and servers. And for smaller systems, Moonshine works really well. For a 48 megabyte model, I was really impressed with the transcription quality. Moonshine does not share memory amongst streams, it's just not able to, but Cohere does. So you load Cohere once and load up a bunch of streams, and it uses the same amount of RAM for everything. Moonshine will use more RAM per number of tunes, that's just unavoidable, but it does use less CPU, so it's kind of the trade off there.

cc: @bnhf if you want to create a beta3

1 Like
#1163

Only downside of cohere transcribe is it'll sometimes on silence it'll hallucinate the word thank you. Other than that, it's fantastic. This is actually extremely common with speech-to-text models.

Update:

Made several more changes. I added CEA-708 support and fixed some bugs. Transcription is much, much faster now. It's like close to real time. I may have also fixed the random thank yous.

#1164

Sounds good. I'll do that -- but probably tomorrow. Congrats!

EDIT: Over 100 commits in the last 11 hours? Wow!

1 Like
#1165

I've been working at this all day. And yes, wait until tomorrow because I'm refactoring right now. Cohere has a lot of quirks.

It hallucinates on audio, like music, and it hallucinates on silence. And I have workarounds for it. There are documented workarounds. So I'm refactoring a separate cohere.go so we can easily maintain those workarounds.

It's really an incredible model, and at the point I have it, it's basically real time, insanely accurate. I'm really impressed.

I'm sorry for the commit spam. It took a lot of work to get this to a point where it was stable.

#1166

@mackid1993 I have :beta2 up-and-running this morning, but none of the GPU-based speech engines are showing as available. Do I need to download the Vulkan drivers first? And, if so, shouldn't we add those to build?

EDIT: Answered my own question. The GPU option appeared after downloading the Vulkan driver. Same question about whether we should just add that to the build though.

BTW, the interface looks great. Nicely done.

1 Like
#1167

Thank you so much. Yeah, I didn't want to clobber your Dockerfile with all of those extra drivers. I believe I also went to Debian backports because the ones coming from apt were very old.

If you want to take a look at what I did, maybe it's worth adding to the Dockerfile. I wanted to respect your authority with Docker. lol :grin:

#1168

Would now be a good time to build :beta3?

1 Like
#1169

Yeah, I was kind of pushing until 3 a.m. yesterday.

Everyone will have to download new Vulkan drivers. The ones that I was pulling from apt were really old, and these are from backports and are much newer and actually seem to transcribe much faster.

And I cleaned up the user interface quite a bit and just tuned the models a lot better. I also fixed a race condition with the $PLAYBACK_DETECTION that seemed to be brought on by the closed captioning. It's back to tuning, I think even faster now with the playback detection enabled.

I made Cohere the primary recommended model because I think it's best for most systems. And I added Nemotron again as kind of a model for multilingual setups where you need different languages other than the eight or nine that Cohere supports. Finally, I added that moonshine model for very lightweight systems.

I also added memory calculations so users know about how much RAM they should expect to use if all their tuners are active.

I think it's good enough for a beta 3 with the expectation that there might be rough edges, and I was also fighting a failed tune issue on first start last night that I believe I resolved. It was essentially an issue where it was taking longer than 30 seconds to pull up a stream, which caused Channels to time out. I'm 99% certain I fixed that, or at least have a bandaid on it and some belt and suspenders to keep it from happening.