ATSC 3.0 issues

Mike Robinson

I have an HDHomeRun Flex 4k box.

* I can confirm that running


http://<IP>:5004/auto/v110.1?duration=1800 -o "${TS_FILE}"

gives me a good ATSC 3.0 transport stream file
* I can pass this TS file to a version of ffmpeg compiled from https://github.com/richardpl/FFmpeg/tree/ac4. The audio is seen and properly transcoded from AC4 to AAC.
* When using TVHeadend to record (using any of the "pass" methods), the resulting TS file lacks audio data
* When trying to use a version of tvheadend compiled against the ATCS 3.0 / AC4 aware ffmpeg, I get errors like:


Error relocating /usr/bin/tvheadend: av_guess_format: symbol not found
Error relocating /usr/bin/tvheadend: av_new_stream: symbol not found

* I have a Dockerfile that I have been using for compiling both the ffmpeg-ac4 base image and the tvheadend image if there is interest

Bob Black

My Homerun ATSC 3.0 works fine as is. I would like to see a tuner that will supplant this unit. Not try to integrate it into this system. There is a great deal of effort being expended and I am not sure it is worth the effort. IMO

Robert Cameron

I rarely check these forums as I no longer use TVH as my DVR. However, the (HTTP) tuning for ATSC 3.0 seems to mimic how they implemented CableCARD tuning. With some extra information and time, it could be possible to recognize the ATSC3 models of the tuners similar to the Prime, and instead of using frequency-based parameters use virtual channel numbers. The downside to this is that each tuner would only carry a single VChan—whereas tuning with frequency/PLP would allow for a single tuner to be used for multiple channels—but the advantage would be native ATSC3 tuner support without having to use M3U playlists to get these tuners working in TVH.

Is there enough interest in this? (I should note, though, that I am not in an ATSC3 market, so this is not something I could iterate upon as quickly as I would like.)

Mike Robinson

I understand integration similar to what is provided by TVH is more work than this, but I've got my own workaround for the time being.

I wrote a Python script that reads the XMLTV file and searches for shows that I want to record and then uses cron.d to schedule the recordings.

There's no interface for this and the recording piece is fairly simple, but it works using the modified version of FFMPEG to convert the audio to AAC and the container to MKV.

C M

"When trying to use a version of tvheadend compiled against the ATCS 3.0 / AC4 aware ffmpeg, I get errors"
That's interesting. It would be really nice to have AC4 pass-through at least, even if transcoding isn't in the cards.

Sean Micklem

C M wrote:
> "When trying to use a version of tvheadend compiled against the ATCS 3.0 / AC4 aware ffmpeg, I get errors"

> That's interesting. It would be really nice to have AC4 pass-through at least, even if transcoding isn't in the cards.

I wonder what would happen if you created a new mux under an IPTV network and in the URL field put something like this:

pipe:///path/to/AC4/ffmpeg -loglevel fatal -i http://ip_address_of_HDHR4K/auto/v1xx.x -c copy -c:a eac3 -b:a 640k -mpegts_flags system_b -f mpegts pipe:1

Make the necessary substitutions for /path/to/AC4/ffmpeg, ip_address_of_HDHR4K, and 1xx.x (using a valid channel number, remember to use the leading 1).

In theory, if you used the version of ffmpeg with the ac4 patches, it could in real time convert the audio to eac3 (or ac3 or aac or whatever format you specify). There MIGHT be some issues with audio channel mapping; I hope not but ffmpeg can remap channels with no problem if you know the correct syntax. But without knowing what the audio stream(s) look like in an ATSC3 signal it is hard to say.

I have not tested this particular usage because I have not yet been able to get a patched ac4 version of ffmpeg to compile on my backend system. So, it may require some tweaking, but it seems like it should work assuming that the patched ffmpeg can properly convert AC4 to another format.

C M

I didn't think of trying that but, it does make sense. Thanks for the input, I'm willing to use a pre-compiled ac4 ffmpeg in a docker container just for testing.
"There MIGHT be some issues with audio channel mapping; I hope not but ffmpeg can remap channels with no problem if you know the correct syntax. But without knowing what the audio stream(s) look like in an ATSC3 signal it is hard to say."

Since I'm in an active ATSC3 market with a Flex 4k would it be helpful to share info? Emby plays my channels right now with their own roll of ffmpeg, would the logs from that show the channel mapping?

Anyway, I'll try the pipe: and report back eventually.