Remote location with another DVR server. In order to minimize the number of ATSC 3.0 channels on HDHR devices used I decided to stream through the DVR w/o transcoding. Both Direct and HLS. Unlike going directly to HDHR there are artifacts on the screen like purple areas when using HLS or the stream is frequently stalling when going direct TS. Going directly to HDHR is fine except it uses an extra tuner.
To follow up here and close this. The channel I am having problems with is having issues even when watching directly from HDHR. Switching to ATSC 3.0 did worsen the reception in the case of this station.
ATSC 3.0 program are unwatchable when going through another DVR. The audio gets ouf of sync after a while. Wonder if I am the only one having issues watching ATSC 3.0 live program through another DVR.
What other DVR ?
Another like 'not the same'. Could you read the OP before jumping the gun?
I was asking what DVR so I can see if I use it ... and see if I have the same problem why ask for help and not give info. SMH You are officially on my ignore list. LOL
Maybe you can be appreciative of @Edwin_Perez trying to help you as most on this forum ignore your posts. You can also give details of what your setup is and and not be cryptic if you want assistance.
1 Like
I described the setup in the original post. What else do we need?
This works:
Apple TV ⟾ Local DVR (Custom M3U TS) ⟾ VPN ⟾ Remote HDHR
but uses an extra tuner.
This does not work:
Apple TV ⟾ Local DVR (Custom M3U TS/HLS) ⟾ VPN ⟾ Remote DVR ⟾ HDHR
What is the m3u URL you are using? Is it transcoding?
Nope.
I tried HLS
http://10.8.0.2:8089/devices/ANY/channels/111.1/hls/master.m3u8?codec=copy
and TS
http://10.8.0.2:8089/devices/ANY/channels/111.1/stream.mpg?codec=copy&format=ts
HDHR directly:
works best. It seems the remote DVR server mangles the ATSC 3.0 streams somewhat.
This in the logs on the remote DVR when HLS streaming:
2023/04/30 19:54:43.326090 [HLS] Starting live stream for channel 111.1 from 10.8.0.1
2023/04/30 19:54:43.758038 [HLS] ffmpeg: ch111.1-dANY-ip10.8.0.1-remux: [hls @ 0x853f1c0] Stream HEVC is not hvc1, you should use tag:v hvc1 to set it.
2023/04/30 19:54:43.758257 [HLS] ffmpeg: ch111.1-dANY-ip10.8.0.1-remux: [mpegts @ 0x85bad40] Stream 1, codec ac4, is muxed as a private data stream and may not be recognized upon reading.
2023/04/30 19:54:43.758268 [HLS] ffmpeg: ch111.1-dANY-ip10.8.0.1-remux: [mpegts @ 0x85bad40] Stream 2, codec ac4, is muxed as a private data stream and may not be recognized upon reading.
2023/04/30 19:54:45.905873 [HLS] Probed live stream in 2.579584126s: hevc 1920x1080 progressive 7085889bps
2023/04/30 20:13:35.189306 [SNR] Statistics for ch111.1 KNTV: ss=78%,76%-84% snq=73%,53%-82% seq=99%,0%-100% bps=0 pps=396,205-621
Try dropping the codec=copy and just use format=ts
Didn't change anything. Still sucks. In terms of levels of suck:
TS > HLS >> HDHR direct
HDHR direct is almost perfect but costs an extra tuner at the remote location.
You probably haven't done any actual real world testing:
When you use the stream.mpg endpoint, it implies a TS stream and all codecs are as in the original. In short, if you're using that endpoint, all query parameters are moot.
Great, so the server ignores these so they do not affect anything. I just removed all query parameters.
An extra data point now is it takes 20 seconds for the TS stream to start if the remote is already recording the channel. When the stream starts the ATV shows Total Cache: 18.7s video + 18.2 audio Channels not being recorded by the remote DVR start in less than 5 seconds.
Something is clearly broken here.
What is the behavior when using the stream.mpg endpoint via the DVR? ffmpeg is not involved when using the stream.mpg endpoint.