ATSC 3.0

Lost Dog
Junior
Posts: 31
Joined: Sat Feb 08, 2014 4:18 pm
United States of America

Re: ATSC 3.0

Post by Lost Dog » Sun Apr 04, 2021 3:43 pm

kmdewaal wrote:
Sun Apr 04, 2021 7:21 am
And now also the patch.....
Log attached!

I'll let you know when I hear back from someone at SiliconDust.
Attachments
mythtv-setup.20210404153634.23224.log.zip
(54.92 KiB) Downloaded 297 times

Lost Dog
Junior
Posts: 31
Joined: Sat Feb 08, 2014 4:18 pm
United States of America

Re: ATSC 3.0

Post by Lost Dog » Sun Apr 04, 2021 11:41 pm

For AC-4 support I tried manually editing the MythTV FFMPEG directory with the patches here:

https://github.com/FFmpeg/FFmpeg/compar ... ff=unified

It keep throwing an error during compile:

Code: Select all

libavformat/mpegts.c: In function ‘ff_old_parse_mpeg2_descriptor’:
libavformat/mpegts.c:2077:25: error: ‘AVStreamInternal’ {aka ‘struct AVStreamInternal’} has no member named ‘request_probe’
 2077 |             st->internal->request_probe = 0;
      |                         ^~
make[2]: *** [ffbuild/common.mak:59: libavformat/mpegts.o] Error 1
make[2]: *** Waiting for unfinished jobs....
I know zero about coding but I've been trying to copy the ac-3 formats seen in mpegts.c but so far no luck... No idea why "request_probe" throws an error.

User avatar
kmdewaal
Developer
Posts: 358
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: ATSC 3.0

Post by kmdewaal » Mon Apr 05, 2021 8:55 am

For this error you can try

Code: Select all

st->request_probe = 0
The AC-4 patch must be from a different version of ffmpeg than what is in mythtv. But it just might work....

Lost Dog
Junior
Posts: 31
Joined: Sat Feb 08, 2014 4:18 pm
United States of America

Re: ATSC 3.0

Post by Lost Dog » Tue Apr 06, 2021 11:13 pm

kmdewaal wrote:
Mon Apr 05, 2021 8:55 am
For this error you can try

Code: Select all

st->request_probe = 0
The AC-4 patch must be from a different version of ffmpeg than what is in mythtv. But it just might work....
That seemed to work and it compiled cleanly but I was not able to get any audio playback. At this point I think it's a bit beyond my pay grade...

User avatar
kmdewaal
Developer
Posts: 358
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: ATSC 3.0

Post by kmdewaal » Wed Apr 07, 2021 3:37 pm

The way forward is to make a development branch of mythtv and then update ffmpeg to the development version that supports AC-4. Since that is also beyond my pay grade we have to ask this friendly and then it just might happen, but we have to have ATSC-3.0/AC-4 recordings first to make that useful.

User avatar
gigem
Developer
Posts: 2
Joined: Fri Feb 07, 2014 8:19 pm
United States of America

Re: ATSC 3.0

Post by gigem » Thu Apr 08, 2021 9:33 pm

The current, internal, HDHR recorder in MythTV is incompatible with the HDHR5-4K except when only ATSC 1.0 channels are used. The reason is due to a limitation in the HDHR API. There is no way to specify which modulation is needed when allocating a tuner. This limitation is very unlikely to be fixed as Silicon Dust considers that old, API to be obsolete.

The only current way to record mixed ATSC 1.0 and 3.0 programs with the HDHR5-4K is to use the external, mythhdhrrecorder (https://github.com/garybuhrmaster/mythhdhrrecorder). That recorder works because it uses the new, HTTP API preferred by Silicon Dust.

In addition, MythTV must be configured to use the HDHR5-4K with two videosources. One videosource must only contain the ATSC 1.0 channels and have up to 2 tuners assigned to it. The other videosource must only contain the ATSC 3.0 channels and have up to 2 tuners assigned to it. As I understand it, that is the only way to force the use of either ATSC 1.0-only or ATSC 1.0/3.0 tuners. Without that control, there will be cases where recordings fail because the correct type of tuner is not available when needed.

Lost Dog
Junior
Posts: 31
Joined: Sat Feb 08, 2014 4:18 pm
United States of America

Re: ATSC 3.0

Post by Lost Dog » Fri Apr 09, 2021 4:53 am

Here's the reply from someone on the SiliconDust forum:
libhdhomerun is a waste of your time for this since the way MythTV uses it is designed around broadcasts being transport streams. ATSC 3 doesn't use transport streams, so there's really no point in trying to cram that square peg into the round hole. You're better off using ExternalRecorder and mythhdhrrecorder. When tuning by virtual channel as mythhdhrrecorder does, the HDHomeRun converts the stream to a TS in realtime, so it more or less just works with existing solutions as long as you support HEVC and AC-4. I assume MythTV already has HEVC support implemented for European countries that are using it. AC-4 support exists in an ffmpeg fork that you can find linked elsewhere on this forum.

User avatar
kmdewaal
Developer
Posts: 358
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: ATSC 3.0

Post by kmdewaal » Fri Apr 09, 2021 10:47 am

OK, those are both good answers. The way forward is to use the mythhdhrecorder and the externalrecorder. Once you have that all running it would be very good to put the whole procedure somewhere on the MythTV WIki to help everybody who is struggling with this. And once there are recordings we can have a go at the AC-4 audio.

ulmus-scott
Junior
Posts: 40
Joined: Sat Jun 05, 2021 12:50 am
United States of America

Re: ATSC 3.0

Post by ulmus-scott » Tue Sep 28, 2021 1:47 am

Regarding codec support in ffmpeg, see:
#5514 (Interlaced HEVC Steam not Decoded Properly) maybe also https://trac.ffmpeg.org/ticket/4141
#8349 (Dolby AC-4 Support)
I couldn't find anything about MPEG-H 3D audio.
On the first two tuners it can detect the ATSC 3.0 channels but they have the same virtual number as the ATSC 1.0. This causes problems (SiliconDust's solution for the hdhomerun_config_gui app is to [prepend] a 1 to the start of the virtual number to separate the ATSC 3.0 from 1.0).
This is a reasonable solution to be able to uniquely identify each channel. N.B. the channels must carry equivalent programming to use the same channel number.

From ATSC A/65 §6.3.1 Terrestrial Virtual Channel Table and Annex B, major_channel_number shall be between 1 and 99 and minor_channel_number shall be between 1 and 999 (0 is reserved for analog).

From ATSC A/331 §6.3 Service List Table (SLT) (also refernces A/63 Annex B), I’m not sure if the range of major channel number is [1, 99] as above or [1, 999]. Regardless, adding 100 will generate unique ids.

Post Reply