HD HomeRun ATSC 3.0 quad tuner

[spaceship9876]

A quad ATSC 3.0 tuner has been announced, it will be released in July: https://www.kickstarter.com/projects/1275320038/hdhomerun-atsc-30/

 

Are you planning on adding support?

 

ATSC 3.0 tv channels in america will be using the Dolby AC-4 audio codec btw, which your program doesn't support at the moment.

[HaraldL]

If I'm not wrong there is still no Dolby AC-4 decoder for windows. AC-3 can be used free now so Dolby "invented" AC-4 with new patents so they can again charge a license fee for every installation or any device that supports it. I assume Dolby will prohibit any free codecs for AC-4.

 

DVBViewer must not handle AC-4 itself, it must only detect it and pass it to the installed windows codecs, if there are suitable ones. Just like current audio or video formats. And perhaps in the future add a select box to choose between multiple codecs if there will be more than one.

[spaceship9876]

I wonder whether DVBViewer could licence a dolby AC-4 decoder and sell that as a separate addon for DVBViewer, that would allow people to decode AC-4 audio streams. You could do the same with the MPEG-H audio codec which is used by South Korea in their implementation of ATSC 3.0.

[hackbart]

Griga pointed me to this topic. Well Harald is right, AC4 is not available at the moment, but the bigger issue is that ATSC 3 is the pear under the apples. This means you can not compare the way it is sent to DVB. On DVB and ATSC1 resp. ISDB you have a mpeg2-ts stream which contains the audio, video and data packets. On ATSC3 you have UDP transmissions which are either provided via a format named ROUTE or MMTP. In both cases you get mpeg4 dash segments which are wrapped into several other transport formats. What I did in the last year and as a side project it is not really complete is a system which extracts those segments and wraps them into Mpeg2-TS. This works quite well so far I was able to test it.

 

 

This screenshot is a tool which I made in the past and it allows amongst other things testing the transmissions and the resulting dvb compatible stream. 

 

Christian

PS: Yes I plan to integrate ATSC3 devices via this workaround directly into the DVBViewer. There are still things missing, like the epg integration and the emergency alert, as well as the subtitles. 

[spaceship9876]

btw 62 areas of america will have ATSC 3.0 broadcasts by the end of this year which totals 70% of the population: https://www.atsc.org/nextgen-tv/deployments/

Edited April 23, 2020 by spaceship9876

[hackbart]

I know, I have access to several machines around the states, allowing me to record and test the current transmissions. The bitrate of ATSC3 is slightly better than the one of DVB-T2, but after more than one year working with it, I still have no idea why they use this new kind of transmission system, based on UDP and Mpeg Dash. I even compared the overhead based on the real transmission with my results in dvb-ts format. The last one is a bit bigger, but not really worth to mention. The biggest down side is that if you have transmission issues you can loose a complete audio/video segment. A segment can have a duration of 1-2 seconds. I'm aware that the ALC header does have in the most cases a transfer length information and the offset of a packet, which decreases the missing data, but this is not always the case. 

The whole system is a mixture of several modern technologies used and does not seem like it is from the same mould. I made so many curses while implementing the system, even the hardest boiled tinker would blush. 

[spaceship9876]

The reason might be $$$. ATSC 1.0 i think costs tv manufacturers $50 per tv to licence or at least used to. It might just be a means of making money for the companies involved. Also ATSC 3.0 supports targeted advertising via your ip address and viewing habits so broadcasters will make more money from ads.

[hackbart]

Maybe, the problem is that the whole system seem to be a construct based on a couple of free solutions assembled by a group of millennials together (meant sarcastic not offending). You do have smart parts, especially those when it comes close to hardware and it gets ugly the higher you get to the data. A lot of the information is written in human readable xmls, which are gzipped and or provided as mime data. A lot of the explanations are wishi-washi. My latest approach is to assemble the most of the required information while ignoring about 90% of the rest. This works well, but it is definitively not in the way of the inventor. My first one (which I dropped) was, typical german, sticking to the specs. I somehow had the wrong understanding of what a specification is and how it should be handled  

 

Christian

PS: But what I can say is that our converter runs perfectly fine with live transmissions, if not encrypted. So once atsc3 devices will be out we can add support for them into the DVBViewer. Subtitles and epg probably not at the beginning, but audio and video..

[hackbart]

Just as short information. The next DVBViewer will have a plugin system which allows hardware plugins. The first hardware plugin which will be released after the new DVBViewer is available is a ATSC3 support. Since I don't have any physical devices here at the moment (except the Redzone Receivers) I decided to listen to 224.0.23.60:4937 and to deal with the ATSC3 Multicast stream. I know that a couple of devices will stream them on the local network. The plugin wraps the whole content to a TS Stream and provides the data to the DVBViewer. I also include the subtitles and electronic program guide. So ATSC3 behaves exactly like DVB-T2 here in Europe. At the moment I write these lines I watch some test broadcasts from Sinclair directly in the DVBViewer. For testing I have them as PCAP Wireshark recordings streams with a PCAP player on my pc.

 

Christian