ATSC 3.0: Raleigh/Durham - Jan 2021

ATSC 3.0 Forum
csdesigns
Posts: 75
Joined: Thu Jun 20, 2019 2:21 pm
x 21

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by csdesigns »

fisherofmen58 wrote: Thu Feb 04, 2021 5:59 pm On a side note, how to I determine resolution and frame rate
There are a few simple methods:
  • You can use a command-line player such as ffplay or mpv – these will generally print the resolution and frame rate of the channel being tuned within the command-line
  • VLC should be able to show you this information in it's info window
  • A player on mobile such as Channels provides a great deal of information regarding the tuned channel
Or, you can just refer to this chart for our area (last updated Feb 1):

Image

CBme
Posts: 144
Joined: Thu Oct 15, 2020 2:15 pm
x 19

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by CBme »

csdesigns wrote: Tue Feb 09, 2021 11:56 pm
fisherofmen58 wrote: Thu Feb 04, 2021 5:59 pm On a side note, how to I determine resolution and frame rate
There are a few simple methods:
  • You can use a command-line player such as ffplay or mpv – these will generally print the resolution and frame rate of the channel being tuned within the command-line
  • VLC should be able to show you this information in it's info window
  • A player on mobile such as Channels provides a great deal of information regarding the tuned channel
Or, you can just refer to this chart for our area (last updated Feb 1):
The caveat is that the players will not report interlaced content correctly. All HEVC content will be reported as progressive. So you may see some stations being reported as 1080p when they are actually interlaced. Rabbit Ears is also incorrect as he doesn't have a way to determine it (I had him update it for the Seattle market based on station managers validation of what was being sent).

csdesigns
Posts: 75
Joined: Thu Jun 20, 2019 2:21 pm
x 21

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by csdesigns »

CBme wrote: Wed Feb 10, 2021 11:42 am The caveat is that the players will not report interlaced content correctly. All HEVC content will be reported as progressive. So you may see some stations being reported as 1080p when they are actually interlaced. Rabbit Ears is also incorrect as he doesn't have a way to determine it (I had him update it for the Seattle market based on station managers validation of what was being sent).
That's not actually correct. HEVC doesn't technically have an interlaced encoding mode. HEVC encodes all content progressively, but then flags if the decoder should weave fields on decode to simulate interlaced encoding (or the decoder can simply stretch the vertical resolution to fit a 16:9 frame and maintain the progressive display). So when a player reports that the content is progressive, that is technically correct.

It would be wrong however if the player reports a '1080i' channel as 1080p (i.e. FHD). Instead, it should report the channel is 1920x540p59.94. I believe that most of the players I previously listed don't refer to 1080i HEVC channels as actually interlaced, though I see that VLC reports it as 1920x540p29.97, for some strange reason (but VLC sucks, so no surprise there). In the RDU market, the only station currently encoded as 'interlaced' is 117.1. All of the other channels are true progressive channels (even 105.11, which is our only 1080p channel currently). I did try to indicate this in my chart in the format distinction in how 117.1 and 105.11 were listed.

And yes, Rabbit Ears and other sites are quite far behind. I know quite a lot of even ATSC 1.0 channels in these databases are ancient by many standards. I have seen reports on some channels that haven't been updated since those channels launched by themselves as the only channel on their frequency, way back in the mid-oughts. These listings don't take into account the additional channels that have been added to a broadcaster's mux or via the repack efforts in the years since. At some point, I plan to notify them on the current RDU status, but there's still a lot in flux atm. The repack hasn't completed yet, and there are changes still to come for the ATSC 3.0 configurations.

kyl416
Posts: 137
Joined: Wed Sep 17, 2014 12:09 pm
Device ID: 1080DB11
Location: Tobyhanna, PA
x 26
Contact:

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by kyl416 »

That's because VLC uses FFmpeg for HEVC decoding, so until FFmpeg's developers address one of these open tickets, it will continue to see 1080i channels as 1920x540p:
https://trac.ffmpeg.org/ticket/4141
https://trac.ffmpeg.org/ticket/5514

CBme
Posts: 144
Joined: Thu Oct 15, 2020 2:15 pm
x 19

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by CBme »

csdesigns wrote: Wed Feb 10, 2021 9:48 pm
CBme wrote: Wed Feb 10, 2021 11:42 am The caveat is that the players will not report interlaced content correctly. All HEVC content will be reported as progressive. So you may see some stations being reported as 1080p when they are actually interlaced. Rabbit Ears is also incorrect as he doesn't have a way to determine it (I had him update it for the Seattle market based on station managers validation of what was being sent).
That's not actually correct. HEVC doesn't technically have an interlaced encoding mode. HEVC encodes all content progressively, but then flags if the decoder should weave fields on decode to simulate interlaced encoding (or the decoder can simply stretch the vertical resolution to fit a 16:9 frame and maintain the progressive display). So when a player reports that the content is progressive, that is technically correct.

It would be wrong however if the player reports a '1080i' channel as 1080p (i.e. FHD). Instead, it should report the channel is 1920x540p59.94. I believe that most of the players I previously listed don't refer to 1080i HEVC channels as actually interlaced, though I see that VLC reports it as 1920x540p29.97, for some strange reason (but VLC sucks, so no surprise there). In the RDU market, the only station currently encoded as 'interlaced' is 117.1. All of the other channels are true progressive channels (even 105.11, which is our only 1080p channel currently). I did try to indicate this in my chart in the format distinction in how 117.1 and 105.11 were listed.

And yes, Rabbit Ears and other sites are quite far behind. I know quite a lot of even ATSC 1.0 channels in these databases are ancient by many standards. I have seen reports on some channels that haven't been updated since those channels launched by themselves as the only channel on their frequency, way back in the mid-oughts. These listings don't take into account the additional channels that have been added to a broadcaster's mux or via the repack efforts in the years since. At some point, I plan to notify them on the current RDU status, but there's still a lot in flux atm. The repack hasn't completed yet, and there are changes still to come for the ATSC 3.0 configurations.
It may be that it is technically 1920x540 with flags to interlace the content vs actually being interlaced, much of what I've read is conflicting, however according to the ATSC document, interlaced HEVC is part of the standard (See page 12 https://www.atsc.org/wp-content/uploads ... HEVC-2.pdf).
Either way, it is incorrect to assume that HEVC content that says it is 1920x1080p (or 480p) in any of the the players is actually that. For Seattle's CBS 1080i station, it was 'squished' with the ffmpeg apps like VLC, that don't support the content, reporting it is 540p. The station manager said it was 1080i. But they updated it to included a flag to "force" the aspect ratio and those same tools now report the stream they said was 540p as 1080p (again with the manager stating it is the same "1080i" broadcast).
Last edited by CBme on Thu Feb 11, 2021 12:13 am, edited 1 time in total.

CBme
Posts: 144
Joined: Thu Oct 15, 2020 2:15 pm
x 19

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by CBme »

dupe - delete
Last edited by CBme on Thu Feb 11, 2021 12:13 am, edited 1 time in total.

CBme
Posts: 144
Joined: Thu Oct 15, 2020 2:15 pm
x 19

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by CBme »

dupe- delete

csdesigns
Posts: 75
Joined: Thu Jun 20, 2019 2:21 pm
x 21

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by csdesigns »

kyl416 wrote: Wed Feb 10, 2021 10:57 pm That's because VLC uses FFmpeg for HEVC decoding, so until FFmpeg's developers address one of these open tickets, it will continue to see 1080i channels as 1920x540p:
Yes, VLC uses an older version of ffmpeg, but for quite a while now, ffmpeg/ffplay hasn't reported '1080i' HEVC content as 1080p. So not sure why ffmpeg is at blame here. ffmpeg reports 1080i HEVC appropriately as 1920x540p59.94.

nickk
Silicondust
Posts: 16595
Joined: Tue Jan 13, 2004 9:39 am
x 131

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by nickk »

csdesigns wrote: Thu Feb 11, 2021 8:22 am
kyl416 wrote: Wed Feb 10, 2021 10:57 pm That's because VLC uses FFmpeg for HEVC decoding, so until FFmpeg's developers address one of these open tickets, it will continue to see 1080i channels as 1920x540p:
Yes, VLC uses an older version of ffmpeg, but for quite a while now, ffmpeg/ffplay hasn't reported '1080i' HEVC content as 1080p. So not sure why ffmpeg is at blame here. ffmpeg reports 1080i HEVC appropriately as 1920x540p59.94.
The HEVC headers report 1080i content as 1920x540. If a player doesn't understand interlaced HEVC it will report 1920x540.

Nick

csdesigns
Posts: 75
Joined: Thu Jun 20, 2019 2:21 pm
x 21

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by csdesigns »

CBme wrote: Thu Feb 11, 2021 12:02 am It may be that it is technically 1920x540 with flags to interlace the content vs actually being interlaced, much of what I've read is conflicting, however according to the ATSC document, interlaced HEVC is part of the standard (See page 12 https://www.atsc.org/wp-content/uploads ... HEVC-2.pdf).
Correct, 'interlaced' HEVC, as I described it, is a fully supported mode for ATSC 3.0 and should be compliant with all HEVC decoders. The issue here is a legacy one. In the early days of HEVC development, broadcast wasn't a major target, so unfortunately the group standardizing the format didn't take into consideration all of the concerns broadcasters (really, the only group still interested with interlacing) would have with the format. Support for 'true' interlacing was not part of the initial spec approvals for HEVC, but was later added as a ratification in the form of still encoding progressively, but with the requisite flags.
CBme wrote: Thu Feb 11, 2021 12:02 am Either way, it is incorrect to assume that HEVC content that says it is 1920x1080p (or 480p) in any of the the players is actually that. For Seattle's CBS 1080i station, it was 'squished' with the ffmpeg apps like VLC, that don't support the content, reporting it is 540p.
I think I get your you're trying to say, but I don't think what you are saying is how things actually are, at least from my experience with the software tools I have at my disposal. I'm sure there are decoders out there that incorrectly report 1080i HEVC as 1080p, but from the list of tools I previously noted (which are only some basic consumer-oriented tools that I think most people have ready and free access to), 1080i HEVC is not reported as 1080p, so I am failing to understand your argument here. You keep saying 1080p, yet all of those decoders report these 1080i channels as 540p (at least in the RDU market), hence my confusion.

Also, regarding the "squished" nature of 1080i HEVC: as alluded to, since there is no true interlaced mode with HEVC, what an HEVC encoder does when ingesting an interlaced source and egressing interlaced output, is it takes each individual field from the source, separates it and then lays each field out sequentially (so, 1920x1080i @ 29.97fps/59.94Hz {each frame contains two fields} is made into 1920x540p @ 59.94fps/59.94Hz). The encoder then encodes this as is and enables a flag that tells the decoder how to present this to the viewer. Unfortunately, a lot of the open source software projects out there ignore this flag, thus you get the "squished" appearance (which isn't actually squished – you're just seeing the individual field now laid out sequentially in a progressive manner as it is encoded).
CBme wrote: Thu Feb 11, 2021 12:02 am The station manager said it was 1080i. But they updated it to included a flag to "force" the aspect ratio and those same tools now report the stream they said was 540p as 1080p (again with the manager stating it is the same "1080i" broadcast).
This is interesting... If you could PM me a link to a short capture of one of these channels, I'd love to check that out.

Display/Pixel aspect ratio flags are certainly a common feature of encoding, very often used when outputting anamorphic resolutions. You can essentially force a similar display in an app like VLC via the manual aspect ratio setting. But I haven't yet seen this method in use elsewhere. For some background, in the RDU market and others I have been working with, if there is an ATSC 3.0 channel whose standard format is 1080i (typically your CBS, NBC, and PBS channels), the channel is either being encoded at 1920x540p59.94 (such as 117.1 in RDU), or is being upscaled to a true 1920x1080p59.94 (such as 105.11). But just because a channel is now being encoded at 1920x1080p59.94, doesn't mean there will be a great deal of increase in picture quality. The source feed (for the national broadcast ingested content at least) is still only 1080i, so events like football, other sports, or news will see little benefit, besides maybe a better encoding efficiency due to HEVC itself over MPEG-2 in a statmuxed environment. However, since a lot of primetime TV is actually telecined 1080p24, there could be some benefits to this output method if the appropriate measures are taken to properly pre-process and encode the content (I'd venture to say that this is not happening in most places right now however).

CBme
Posts: 144
Joined: Thu Oct 15, 2020 2:15 pm
x 19

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by CBme »

csdesigns wrote: Thu Feb 11, 2021 9:07 am
CBme wrote: Thu Feb 11, 2021 12:02 am The station manager said it was 1080i. But they updated it to included a flag to "force" the aspect ratio and those same tools now report the stream they said was 540p as 1080p (again with the manager stating it is the same "1080i" broadcast).
This is interesting... If you could PM me a link to a short capture of one of these channels, I'd love to check that out.
Sure, interested to know what your thoughts on it are. Entirely possible the station director misunderstood the specifics of what the encoding engineers were doing but to he was very certain it wasn't 1080p at the time.

Here is clip from Dec after they 'forced the aspect ratio'
https://1drv.ms/v/s!Ap22nCAxKBS7nPw6hw2 ... A?e=uLXKGd

CBS Director of Engineering: "We made some adjustments to our 3.0 HEVC signal to address what you are seeing. It’s still 1080i, but I’m hoping the changes fix the squish problem you have. Can you let me know if we’ve made a difference?"

Me: "However, I now seem to be receiving a 1080p signal from KIRO. The image is no longer squished, 3rd party apps display it in the correct aspect ratio they they do not support 1080i hvec and MediaInfo reports it as 1080p. Are you still 1080i or did something big change last week? "

CBS Director of Engineering: "We made a change to force aspect ratio, but did not change from interlaced to progressive on the delivery."

csdesigns
Posts: 75
Joined: Thu Jun 20, 2019 2:21 pm
x 21

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by csdesigns »

CBme wrote: Thu Feb 11, 2021 1:17 pm Entirely possible the station director misunderstood the specifics of what the encoding engineers were doing but to he was very certain it wasn't 1080p at the time.

Here is clip from Dec after they 'forced the aspect ratio'

CBS Director of Engineering: "We made some adjustments to our 3.0 HEVC signal to address what you are seeing. It’s still 1080i, but I’m hoping the changes fix the squish problem you have.

Me: "However, I now seem to be receiving a 1080p signal from KIRO. The image is no longer squished, 3rd party apps display it in the correct aspect ratio they they do not support 1080i hvec and MediaInfo reports it as 1080p. Are you still 1080i or did something big change last week? "
Yeah, I'm going to go ahead and definitively say that the station manager doesn't know what his engineers are doing here. Based on experience, it is also entirely possible that even the station engineers don't know that what they are currently outputting is effectively a conversion, and not just "setting some flag." Most station engineers don't have extensive encoding knowledge, they just need to make sure things work – which they've accomplished in your case, so good on them.

The example you linked is indeed 'true' 1080p (as encoded anyway). The station manager was right in that their native broadcast format (which they edit and receive in) is still most likely 1080i, but I'm guessing that because there have been various ATSC 3.0 launch issues throughout the market with interlaced HEVC and decoders out there not properly scaling the output to full frame (ie the video appearing 'squished'), the station, as others are doing as well, is converting the 1080i to 1080p (similar to WRAL in my market).
CBme wrote: Thu Feb 11, 2021 1:17 pm CBS Director of Engineering: "We made a change to force aspect ratio, but did not change from interlaced to progressive on the delivery."
Again, this is not correct, but I'd personally prefer stations encode FHD vs 1920x540p any day, so no harm done. As previously stated, as of right now, there is likely very little benefit to how they are doing this conversion. I imagine it is a simple field scale method to get the 1080i to 1080p. But there can be some pretty big benefits in the future, if a station enables some pre-processing techniques, and live events such as sports are more commonly delivered in 1080p from the national headend.

csdesigns
Posts: 75
Joined: Thu Jun 20, 2019 2:21 pm
x 21

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by csdesigns »

Here is how HEVC Interlaced should 'look' when analyzed
(there are various methods to display this depending on the analyzer application, so the example I'm showing here is with both fields simultaneously top+bottom per 'frame'; note the overlay of the CU size grid appears as squares – if this were simply a stretched aspect ratio image, these squares should appear as rectangles, because the original CU grid would be stretched accordingly):
Image

Here is how the sample cbme upload looks
(only a single field per frame, with the CU sizes still square):
Image

I have at least 8 different applications telling me the example from cbme is 1080p, not 1080i. I'm going to trust what they are reporting.

Trip
Posts: 36
Joined: Sat Aug 07, 2010 6:49 am
Location: Alexandria, VA, USA
x 1
Contact:

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by Trip »

csdesigns wrote: Wed Feb 10, 2021 9:48 pm And yes, Rabbit Ears and other sites are quite far behind. I know quite a lot of even ATSC 1.0 channels in these databases are ancient by many standards. I have seen reports on some channels that haven't been updated since those channels launched by themselves as the only channel on their frequency, way back in the mid-oughts. These listings don't take into account the additional channels that have been added to a broadcaster's mux or via the repack efforts in the years since. At some point, I plan to notify them on the current RDU status, but there's still a lot in flux atm. The repack hasn't completed yet, and there are changes still to come for the ATSC 3.0 configurations.
RabbitEars is only as updated as local sources allow. To the extent I can't find a local source, it's not updated. Contrary to popular belief, I'm not omniscient, but in places where I have regular contacts, I do think I'm pretty on top of things as a general matter.

With ATSC 3.0, the big problem right now is lack of analysis tools. TSReader makes collecting and updating technical data on RabbitEars a cinch. No equivalent tool exists for ATSC 3.0 at this point, so I'm mostly going by the limited reports posted on forums like this one. It's even harder when the few tools we actually do have, like VLC, don't actually report properly what they're seeing.

- Trip

Crash*N*Burn
Posts: 40
Joined: Sat Apr 25, 2020 8:42 pm
x 6

Re: ATSC 3.0: Raleigh/Durham - Jan 2021

Post by Crash*N*Burn »

As of February 2021, I am now able to get audio from the HEVC 1xx channels on my shield 2015. I uninstalled the version I had loaded and reinstalled the application and now able to get audio. I still don't get audio from the HEVC channels through Kodi, but that another problem.

Thank you silicondust for whatever you did in the android app to allow this to happen.

Post Reply