ATSC 3.0 Mux support for US markets.
Is there a possibility for the new ATSC 3.0 standard to be added to the pre-defined muxes?
Configuration -> DVB Inputs -> Networks -> Edit network -> Pre-defined muxes.
This standard is so unpopular
dtv-scan-tables package need to include them
I wasn't search for tutorials how to scan this exotical standard used in 3 countries in world, but maby there is.
Updated by Flole Systems 10 months ago
- Category changed from Muxers to DVB
If you (or someone else) submit a PR it will be considered for merging, just like every other PR. For obvious reasons someone who is in a region that uses it should do that, everything else would be super slow and inefficient.
Alan Z. wrote:
The ATSC3.0 (HEVC) is a new OTA standard in the US (as of February 2021), that supports up to 4K resolutions. There are already some stations available, that use it.
HEVC (video coding) noting to do with Transportation technology on similar standards.
ATSC3.0 will make TV hardware change with is nonsense.
ATSC 3.0 (Advanced Television Systems Committee) is a digital terrestrial broadcasting standard that has been substantially enhanced compared with the ATSC A/53 predecessor standard. ATSC 3.0 is designed to allow network operators more flexibility, greater robustness and more efficient operation. It employs state-of-the-art encoding and modulation technologies, enabling a significantly more effective use of the limited spectrum resources. In this way, capacity is created to transfer UHD video contents and immersive audio contents to the end user via terrestrial channels with minimal resources. The consistent focus on IP technology in the baseband makes it possible to merge cost-effective terrestrial broadcasting with other IP-based services. ATSC 3.0 is the first ATSC standard to employ coded orthogonal frequency division multiplexing (COFDM). This modulation method uses a large number of orthogonal carriers, resulting in a signal that is robust against jamming. COFDM technology also makes it possible to set up spectrum-efficient ATSC 3.0 single-frequency networks (SFN). Use of the latest low density parity check (LDPC) codes in combination with Bose-Chaudhuri-Hocquenghem (BCH) codes allows the usable channel capacity to approach the theoretical Shannon limit, as does the use of non-uniform constellations (NUC) for modulation. ATSC 3.0 employs multiple physical layer pipe (multiple PLP) technology, enabling a flexible use of the channel. With the latest technologies such as Layer Division Multiplexing (LDM), an effective simultaneous crossover can be realized both for mobile reception and for stationary reception.
DVB-T2 is still better read comparsion betwin both
Updated by Michael Marley about 1 month ago
I've been doing some research and testing about this. There were similar questions asked over at MythTV and what they found is that the "libhdhomerun" interface that they and TVHeadend both use is deprecated and doesn't support setting the modulation as would be necessary to tune ATSC3. What they recommended was using the "mythhdhrrecorder" ExternalRecorder script, which just uses HTTP streaming from the HDHR using the "http://<HDHR_ADDRESS>:5004/auto/v5.1" URLs, which obviously operate by virtual channel number and repack the DASH/ROUTE encoding of the ATSC3 signal as a regular old MPEG TS. This method does, however, have the disadvantage that the HDHR isn't smart enough to reuse already-tuned muxes, for example, if you were already recording 5.1 and then started recording 5.2, it would use a second tuner for that instead of the existing tuner already tuned to the correct frequency.
TVHeadend thankfully already has most of what it needs to handle this type of streaming; you can just create an IPTV network and then add the virtual channel URLs as described above manually and it should work, whether for ATSC3 or ATSC1. (I don't have an HDFX-4K yet, so I can't test for sure.) I'm also going to look into the possibility of making TVHeadend able to parse the "http://<HDHR_ADDRESS>/lineup.json" endpoint for the "IPTV Auto" network type, which should in theory be able to automatically populate the list.
I also looked in to the possibility of working around the limitation I mentioned at the beginning of the first paragraph, and what I found is that it is also possible to construct a URL based on the physical channel (e.g. "http://<HDHR_ADDRESS>:5004/auto/ch599000000"). This of course returns the entire mux including all subchannels, which TVHeadend then identifies as separate services, allowing for watching/recording multiple services on a single mux with a single tuner (with some limitations until https://github.com/tvheadend/tvheadend/pull/1430 is merged). I'm not sure how this would react though if you used it to tune an ATSC3 mux; I couldn't find any information about this in the HDHR documentation or SiliconDust's forum. There's no reason you couldn't combine the virtual channels and the physical frequencies in the same IPTV network though, but that would of course have the same limitation for the ATSC3 channels as I described in the first paragraph.
I also wrote a shell script that parses the dvbscan data and makes service calls to TVHeadend to create an IPTV network and add all the frequencies with their physical channel URLs. The script is attached and of course must be modified for your specific configuration. Additionally, "curl" and "jq" must be installed for it to work.