Issue with ATSC 3.0 programming

Channels DVR Server
#1

As my Nexstar CBS station and my primary video provider are in a fight, it has become important that I be able to get to the OTA feed. The ATSC 1.0 signal doesn't reach my home well, but the ATSC 3.0 antenna is really close. There doesn't seem to be an issue acquiring the feed from the Silicon Dust tuner, the log says:

2023/07/03 23:29:30.002607 [DVR] Starting job 1688426970-ch107.1 7News at 7:30PM on ch=[107.1]
2023/07/03 23:29:30.003512 [DVR] Waiting 3h29m59.99650476s until next job 1688439570-2 WYFF News 4 at 11pm
2023/07/03 23:29:32.456985 [TNR] Opened connection to 10A420E8/0 for ch107.1 WSPA
2023/07/03 23:29:32.457406 [DVR] Recording for job 1688426970-ch107.1 from 10A420E8 ch107.1 into "TV/7News at 730PM/7News at 730PM 2023-07-03-2329.mpg" for 33m29.997111531s
2023/07/03 23:29:33.331636 [DVR] Refreshing metadata for 7News at 7:30PM (15310892)
2023/07/03 23:29:35.131191 [IDX] Generating video index for job 1688426970-ch107.1

but when the program was over, the following is in the log

2023/07/04 00:03:01.721151 [DVR] Processing file-355: TV/7News at 730PM/7News at 730PM 2023-07-03-2329.mpg
2023/07/04 00:03:01.721360 [DVR] Waiting 2h56m28.278645067s until next job 1688439570-2 WYFF News 4 at 11pm
2023/07/04 00:03:03.271545 [DVR] Running commercial detection on file 355 (TV/7News at 730PM/7News at 730PM 2023-07-03-2329.mpg)
2023/07/04 00:34:04.048870 [ENC] Starting encoder for 7News at 730PM 2023-07-03-2329.mpg in /channels-dvr/DVR/Streaming/file355-ip192.168.1.106-3088717204/encoder-0-3474318247 at 0 (0.000000) (encoder=h264_vaapi, resolution=1080, deinterlacer=hardware, bitrate=9488, segment_size=0.01)
2023/07/04 00:34:13.351097 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8d2c640] No support for codec hevc profile 2.
2023/07/04 00:34:13.352031 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8d2c640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:34:43.415303 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8d2c640] No support for codec hevc profile 2.
2023/07/04 00:34:43.451061 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8d2c640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:35:12.253760 [ENC] No segments have been generated in 20.064058722s. Stopping transcoder.
2023/07/04 00:35:12.933767 [ENC] Encoder stopped for 7News at 730PM 2023-07-03-2329.mpg in /channels-dvr/DVR/Streaming/file355-ip192.168.1.106-3088717204/encoder-0-3474318247 after starting from 0 without encoding any segments
2023/07/04 00:35:12.963852 [ENC] Starting encoder for 7News at 730PM 2023-07-03-2329.mpg in /channels-dvr/DVR/Streaming/file355-ip192.168.1.106-3088717204/encoder-0-2976120044 at 0 (0.000000) (encoder=h264_vaapi, resolution=1080, deinterlacer=hardware, bitrate=9488, segment_size=0.01)

Later, when I tried to watch it, the wheel of wait spun indefinitely, and this was in the log

2023/07/04 00:35:22.252099 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x7ff9640] No support for codec hevc profile 2.
2023/07/04 00:35:22.252823 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x7ff9640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:35:25.828008 [ENC] Stopped encoder for 7News at 730PM 2023-07-03-2329.mpg in /channels-dvr/DVR/Streaming/file355-ip192.168.1.106-3088717204/encoder-0-2976120044 after encoding 0 to 0

TOP showed a commercial detect process taking 100% of one of my 4 cores. While I was getting ready to submit this, the commercial detect process seems to have completed, and now when I try to watch the program, it works. But the commercial detect wasn't very good, plenty of false negative and false positive. But at least I can watch it. The log now shows:

2023/07/04 00:41:01.810620 [DVR] Commercial detection for 7News at 730PM 2023-07-03-2329.mpg finished with 4 markers in 37m58.539218642s.
2023/07/04 00:44:34.094356 [ENC] Starting encoder for 7News at 730PM 2023-07-03-2329.mpg in /channels-dvr/DVR/Streaming/file355-ip192.168.1.106-3359933698/encoder-0-2096025391 at 0 (0.000000) (encoder=h264_vaapi, resolution=1080, deinterlacer=hardware, bitrate=9488, segment_size=0.01)
2023/07/04 00:44:34.258882 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] No support for codec hevc profile 2.
2023/07/04 00:44:34.258903 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:44:34.779430 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] No support for codec hevc profile 2.
2023/07/04 00:44:34.779620 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:44:35.322097 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] No support for codec hevc profile 2.
2023/07/04 00:44:35.322128 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:44:35.829023 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] No support for codec hevc profile 2.
2023/07/04 00:44:35.829128 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] Failed setup for format vaapi: hwaccel initialisation returned error.
2023/07/04 00:44:36.399798 [HLS] ffmpeg: file355-ip192.168.1.106:  [hevc @ 0x8668640] No support for codec hevc profile 2.

(These last two lines repeat over and over again with different times, although, as I said, I was able to watch the program).

What's going on here?

#2

Your ATSC 3.0 station is most likely DRM'd. Although you can record the signal, the picture is scrambled and can't be processed. I suggest you do a search for "NextGen" and that's all explained ...

#3

Nope. I know what DRM looks like here. First, Silicon Dust returns an error when you try to tune a channel with DRM "Content Protection Required". Secondly, I can watch the program, so not scrambled. Another station is scrambling their signal, but not this one. Yet.

#4

OK, glad you know all about the NextGen problems. Then it looks like it's a HEVC codec problem with the decoding process ... have you tried playing back the file on VLC?

#5

What is your server hardware? Client hardware?

#6

Server: Debian Linux on 4 cores / Intel(R) Core(TM) i5-4210U CPU @ 1.70GH (no GPU)
Client: Windows 10 on 4 cores / Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz 2.67 GHz (Nvidia GeForce GT 1030 GPU), no HEVC plug in

#7

Google "ffmpeg No support for codec hevc profile 2"

#8

Is there some particular article that you thought I would be interested in? Nothing there is really checking any boxes for me.

#9

Generally, it's pointing out that you're not the only one having problems decoding HEVC profile 2 since ffmpeg hasn't fully supported it yet. Unfortunately, ATSC 3.0 is using a codec that is not part of the mainstream. I'm thinking that since ATSC 3.0 is still developing and the FCC has pushed back the adoption to 2026 or 2027, it's likely going to change even more. ATSC 1.0 is plain, old mpeg and will be supported at least through 2027. It might just be easier to find another way to receive and record your CBS station.

#10

The ATSC 1 station is at VHF 9, which limits my antenna choices (I've even tried a homemade Yagi that improved things a bit, but not enough) and becomes unwatchable when the leaves fill in on my neighbor's trees (and isn't great the four months they're gone). I'd have to extend a mast 20 feet above my chimney to get over those trees.

Absent the log messages and poor (and CPU hogging) commercial detection (and the inability to watch it while commercial detection is going on), it would be fine. I just happened to try a test while commercial detection was running.

It would be great IF... you could disable commercial detection on certain channels instead of it being an all or nothing thing. That way I could just turn it off on the ATSC 3.0 channels and still use it on the others (where it works "good enough" but not great).

#11

You can disable com check by channel using:
curl -XPUT http://192.168.0.232:8089/comskip/ignore/channel/6074

Fill in your own IP and channel.

Ken

1 Like
#12

You are the man. I tried that for my channel and got back "true". I'm testing now. :slight_smile:

#13

You might try on an actual client and not the web interface.

#14

You might try on an actual client and not the web interface.

That could make a difference on playback (if it doesn't have to recode), but commercial detection isn't a client-based operation. I will try watching on an "actual client" and see what's in the logs.

And, yes, the CURL PUT did suppress comskip for the channel.

2 Likes
#15

Atsc3 does take more processing power to run comskip and it isnt as accurate. It could be that your server is taxed doing the comskip and when your web interface calls for transcoding, it just cant handle it. I bet you will have zero issues playing back on a real client (almost anything is better than the web interface). As for the inaccurate comskip, you can edit the markers yourself in the web interface. Thats typically what i do when im not busy and feel like tinkering.

#16

I did have exactly zero issues with an Android TV client, as no transcoding was done, so it looks like something I can live with.

BTW, on the DRM subject, there's a petition on change.org about asking the FCC to prohibit DRM on ATSC 3.0 OTA. It's likely got zero chance but, if you'd like to go on record...

https://www.change.org/p/tell-the-fcc-no-drm-encryption-of-atsc-3-0-broadcasts

(Note the contribution request is from change.org itself, not the petition sponsor.)

#17

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.