Broadcast Bit Rate

[chris319]

When encoding for ATSC, do I need to be concerned with bit rate?

[jagabo]

https://en.wikipedia.org/wiki/ATSC_standards#MPEG-2

[chris319]

I know what the standard is. The question is whether I need to be concerned with it when encoding video.

[pandy]

You need to be more precise what do you mean by ATSC. If your gaol is Terrestrial broadcast then there is very strict bitrate limit - nett bitrate for 8-VSB modulation is exactly 19.3904Mbps so you need to prevent your video encoder going above this bitrate (in fact it must be lower as you need to accommodate PSI around few tens kbps perhaps up to 100kbps and audio i.e. around 192kbps at least + perhaps other data like CC 50kbps + perhaps few tens/hundreds kbps of stuffing depends on how strict is bitrate control in your encoders). Normally video bitrate is limited to around 18.5Mbps maximum and you should never exceed it.

[JVRaines]

I know what the standard is. The question is whether I need to be concerned with it when encoding video.

If you are delivering material to a broadcaster, I'm sure they can supply you with their precise technical requirements.

[chris319]

You need to be more precise what do you mean by ATSC. If your gaol is Terrestrial broadcast then there is very strict bitrate limit - nett bitrate for 8-VSB modulation is exactly 19.3904Mbps so you need to prevent your video encoder going above this bitrate (in fact it must be lower

Yes, terrestrial broadcast.

If you are delivering material to a broadcaster, I'm sure they can supply you with their precise technical requirements.

All U.S. terrestrial TV broadcasters are confined to a 6 MHz channel, however nowadays they have digital subchannels, too. If a syndicated program is shown on 200 stations you can't expect a syndicator to query 200 TV stations and possibly provide 200 copies of his show at 200 different bit rates. Do stations take care of the extra compression needed for their particular configuration of digital subchannels? Do we start with an 18.5 MBps bit rate?

[chris319]

Here is an interesting paper on the topic:

http://ste-ca.org/images/Harmonic_ATSC_3.0_STE.pdf

[pandy]

You need to be more precise what do you mean by ATSC. If your gaol is Terrestrial broadcast then there is very strict bitrate limit - nett bitrate for 8-VSB modulation is exactly 19.3904Mbps so you need to prevent your video encoder going above this bitrate (in fact it must be lower

Yes, terrestrial broadcast.

If you are delivering material to a broadcaster, I'm sure they can supply you with their precise technical requirements.

All U.S. terrestrial TV broadcasters are confined to a 6 MHz channel, however nowadays they have digital subchannels, too. If a syndicated program is shown on 200 stations you can't expect a syndicator to query 200 TV stations and possibly provide 200 copies of his show at 200 different bit rates. Do stations take care of the extra compression needed for their particular configuration of digital subchannels? Do we start with an 18.5 MBps bit rate?

I agree with JVRaines that broadcaster should provide encoding guidelines as simply you don't have knowledge how broadcaster shape transponder (i mean how many streams and what kind of bitrate is available for you) - i've mentioned 18.5Mbps as maximum allowed bitrate for case where on transponder there is single video elementary stream and single audio 2 channel - for such situation it is wise to set encoder to not go for bitrate higher than 18.5Mbps (VBV buffer filtrate can't exceed 18.5Mbps) so in case of popular x264 you must set --vbv-maxrate 18500 .
---
Realised after while that i didn't mentioned - combined VBV buffer filtrate for ALL ES's must be lower than 19.3904Mbps so if transponder has two ES video then sum of their VBV buffer filtrate must never exceed 19.3904 (minus all other ES) - exception is statistical multiplexing where VBV buffer filtrate can be controlled adaptively. Perhaps my english is too poor to express then maybe some example can help
Assuming 2 video ES on transponder, 1HD + 1SD, assuming audio 192kbps for every video + some other associated data we may assume that for example 1Mbps can be reserved for audio and other data, thus we can use remaining 18.3904Mbps as we like for example 5Mbps for H.262 SD and remaining 13.3904 for HD then we need to guide H.262 encoder that VBV buffer rate can't exceed 5Mbps and H.264 encoder that VBV buffer rate can't exceed 13.3904Mbps - hope it is more clear.

I would recommend to ask broadcaster for this - as broadcaster may use various strategies (statistical multiplexing and mandatory re-encoding) thus you may wish to deliver higher quality video. One rule is simple - all elementary streams (or rather PID's) combined together can't exceed 19.3904Mbps - this is strict modulation (8-VSB) limit - it is like 10 Mb Ethernet - simply you can't push more data than in total 10Mbps.

Here is an interesting paper on the topic:

http://ste-ca.org/images/Harmonic_ATSC_3.0_STE.pdf

So they advised 92% of 19.3904Mbps allocated for HD video (assumption is MPEG-2 as for H.264 10 - 12 Mbps for 1080i is decent quality - in Europe some broadcasters using 5Mbps for 1080i and video is OK), 19.3904*.92=17.84Mbps - close enough to 18.5Mbps but everything depends on encoder - how good is bitrate control in encoder - for H.264 i think 10Mbps will be more than OK but for H.262... IMHO anything bellow 20Mbps is difficult but depends on H.262 encoder - some of them can deliver nice quality but this require very aggressive strategy like dynamic interlace vs progressive etc.
Broadcaster should know own strategy best - single transponder can be shared with other video (commonly HD+SD) or exclusive for HD...

[smrpix]

Broadcast spec is the station's responsibility. Deliverable specs are yours.

For example:

"The BBC requires all network television programmes to be delivered as AS-11 DPP files unless there is a specific agreement for a programmes to be delivered on tape.

All programmes delivered to the BBC must be fully editorially and technically checked and ready for transmission prior to delivery. This includes ensuring sound and picture quality are consistent throughout and there are no problems that will harm a viewers’ enjoyment of the programme, usually determined by the eyeball QC check. Crucially productions must ensure dialogue is clear and understandable by a first-time viewer.

It is the responsibility of the supplier to ensure programmes meet the editorial and technical requirements of the commission. (See sections one - four of the BBC specific technical delivery standards document (PDF).)"

[chris319]

I agree with JVRaines that broadcaster should provide encoding guidelines as simply you don't have knowledge how broadcaster shape transponder (i mean how many streams and what kind of bitrate is available for you)

They are channels, not transponders.

Did you read what I wrote? A single programming service could be carried by as many as 200 stations, each with a different configuration. It is not practical to supply a different feed for each configuration.

It would work if a single 18.5 MBps feed were provided and let each station mux its other services/digital subchannels as needed.

[pandy]

I agree with JVRaines that broadcaster should provide encoding guidelines as simply you don't have knowledge how broadcaster shape transponder (i mean how many streams and what kind of bitrate is available for you)

They are channels, not transponders.

Did you read what I wrote? A single programming service could be carried by as many as 200 stations, each with a different configuration. It is not practical to supply a different feed for each configuration.

It would work if a single 18.5 MBps feed were provided and let each station mux its other services/digital subchannels as needed.

Trust me - i use transponder instead channel intentionally (transponder imply digital RF modulation and as such available bitrate where channel usually describe only analog bandwidth - good for old TV times where single channel carry single program).
I agree, following 200 different broadcasters guidelines may look impractical but for sure they share some common denominator - this is highly theoretical discussion as you didn't provided any details (video codec, source HD or SD, online vs offline etc) - you can fill gap in missing guidelines by following so called good practices (so extrapolate from well defined guidelines hoping that they are sane people and they reducing number of problems by following people that using guidelines). Shed some light.

[Cornucopia]

Having dealt with broadcasters many times before, I agree with jvraines, et al.

You should not be giving them drop-in broadcast-rate mpg2 as deliverables, you should be giving them dubs of hi-quality masters, and then let them ingest it into their own systems, so they can fit it into their programming however they see fit.

So you find out from the individual broadcast stations and or networks what they will take as source deliverables. And then you make them and send them - however it is requested/expected. And if you have to do it 200 times, all differently, that’s what you do. That’s how it works.

Remember: these people are NOT consumers.

Scott

[chris319]

So you find out from the individual broadcast stations and or networks what they will take as source deliverables. And then you make them and send them - however it is requested/expected. And if you have to do it 200 times, all differently, that’s what you do. That’s how it works.

There are two main services for distributing syndicated programs to stations. I'm sure you are familiar with them.

There is a third way of distributing programs to stations. I'm sure you are familiar with it, too.

[JVRaines]

If a syndicated program is shown on 200 stations you can't expect a syndicator to query 200 TV stations and possibly provide 200 copies of his show at 200 different bit rates.

There are only 44 unique licensees of all the television stations in the U.S. A handful own scores of licenses each. You are not going to be faced with hundreds of different specifications.

[pandy]

What is the current state for MPEG-2 in US? SD service with 4Mbps? HD with less than 14Mbps? I assume H.264 is not supported widely on terrestrial broadcast?

[KarMa]

Broadcasters even re-encode feeds from their own satellite feed systems. With CBS/NBC/PBS/FOX stations almost always broadcasting H.264 on satellite feed systems to individual stations. Some feeds don't even use 4:2:0 but 4:2:2 and might be 10-bit instead of 8-bit. And when it comes to audio the feed might not contain AC3 or might only be stereo, even though they might broadcast in surround 24/7.

If it was my job to manage the broadcast encodings, I would not trust you at all to provide me with the type of bitrate that I want especially if it's a VBR broadcast, along with the fact that it would probably be 10x harder to inject in a pre-encode file instead of just using the hardware encoder chain. In short, broadcasters know how to re-encode your content to play nice with their MPEG2 AC3 broadcast. They will probably re-encode it no matter what so just provide a HQ source.

You need to be more precise what do you mean by ATSC. If your gaol is Terrestrial broadcast then there is very strict bitrate limit - nett bitrate for 8-VSB modulation is exactly 19.3904Mbps so you need to prevent your video encoder going above this bitrate (in fact it must be lower as you need to accommodate PSI around few tens kbps perhaps up to 100kbps and audio i.e. around 192kbps at least + perhaps other data like CC 50kbps + perhaps few tens/hundreds kbps of stuffing depends on how strict is bitrate control in your encoders). Normally video bitrate is limited to around 18.5Mbps maximum and you should never exceed it.

You are forgetting things like FEC which can eat up a few Mbits depending on what the broadcaster uses. Personally, I have never seen an over the air broadcast go over 16Mbit (sum of audio and video) while in CBR mode. So I'm assuming the remainder was made mostly of FEC data for error correction. The channel I'm talking about was an NBC station that once only had one 1080i channel, but now that NBC frequency has to share it's bandwidth and is down to 6Mbit @720p.

I assume H.264 is not supported widely on terrestrial broadcast?

ATSC supports H.264 but I guess the FCC never required H.264 decoder tuners so it just never happened, we are just stuck with MPEG2. With ATSC 3.0 they are testing out HEVC and it looks like that's the future for OTA in the US, despite AV1 being out and VP9 being out way before they tested anything.

There are only 44 unique licensees of all the television stations in the U.S. A handful own scores of licenses each. You are not going to be faced with hundreds of different specifications.

It's up to the station to re-encode the content for their own broadcast. Usually there is a single source (over satellite) and everyone needs to do their own thing with it. It might make a little bit of sense to provide individual profiles for each station but when that station uses VBR across all the channels on the one frequency (10.1 10.2 10.3 all having to share bitrate), then the level of complexity has just skyrocketed as you need to know the bitrate of the other channel that will air at the same, with a frame level of bitrate accuracy. Not happening, and anymore VBR broadcasts are very common with broadcasters trying to put as many channels on a single frequency as possible to make that $$$. You also forget that C-band satellite time is expensive, they can't be bothered to handout 10 different copies of a show for compatibility sake.

[pandy]

You are forgetting things like FEC which can eat up a few Mbits depending on what the broadcaster uses. Personally, I have never seen an over the air broadcast go over 16Mbit (sum of audio and video) while in CBR mode. So I'm assuming the remainder was made mostly of FEC data for error correction. The channel I'm talking about was an NBC station that once only had one 1080i channel, but now that NBC frequency has to share it's bandwidth and is down to 6Mbit @720p.

Nope - 19.3904Mbps is nett bitrate (useful, before FEC). After FEC 8-VSB bitrate is around 32.28Mbps

ATSC supports H.264 but I guess the FCC never required H.264 decoder tuners so it just never happened, we are just stuck with MPEG2. With ATSC 3.0 they are testing out HEVC and it looks like that's the future for OTA in the US, despite AV1 being out and VP9 being out way before they tested anything.

Ok, looks like MPEG-2 is common denominator thus i assume SD service in US has around 4 - 4.5Mbps and for HD this will be around 14Mbps (as if i recall correctly commonly on single transponder there is a single HD and single SD service).

[davexnet]

I found some samples on my PC from when I had my ATSC capture card installed
I see 13.7 mb/s for 720p and 16.6 mb/s for 1080i.

The 1080i segment appears to be a live news show

[Cornucopia]

So you find out from the individual broadcast stations and or networks what they will take as source deliverables. And then you make them and send them - however it is requested/expected. And if you have to do it 200 times, all differently, that’s what you do. That’s how it works.

There are two main services for distributing syndicated programs to stations. I'm sure you are familiar with them.

There is a third way of distributing programs to stations. I'm sure you are familiar with it, too.

I'm familiar with plenty. But it seems you aren't, otherwise you wouldn't be asking. HERE.

As mentioned, most broadcasters have an ingest workflow that includes source formats, interim Mpeg-style formats which they store for medium/long-term, and actual live/on-air formats (which are often/usually transcoded to required transmission bitrates in realtime to comply with varying multi-stream bitbudgets).
You don't want to give them their interim mpeg formats, even if you can closely match the spec and think you might have a better quality encoder/process than they do - they have other optimizations for their system that have access to that you do not, plus they often would need to incorporate additional metadata during the ingest regardless, which you would have no way of prepping ahead of time.
You clearly do not want to give them the 3rd kind, because each market will have differing bitbudgets and would most likely have to re-encode your stuff to make it fit their model, losing more quality from you work in the process.
That leaves the master dubs, whether it's physical tape, disc, or file.

Scott

[chris319]

There are two main services for distributing syndicated programs to stations. I'm sure you are familiar with them.

I'm familiar with plenty.

OK then, name them. They are very prominent in the industry.

[lordsmurf]

...

One thing you've overlooked is multicast. Many (most?) carrier signals has multiple things going on, not a single broadcast. It got really complicated starting about 10 years ago.

There are only 44 unique licensees of all the television stations in the U.S. A handful own scores of licenses each. You are not going to be faced with hundreds of different specifications.

No. All you're stating is ownership. That's has nothing to do with operations.

Having dealt with broadcasters many times before, I agree with jvraines, et al.
You should not be giving them drop-in broadcast-rate mpg2 as deliverables, you should be giving them dubs of hi-quality masters, and then let them ingest it into their own systems, so they can fit it into their programming however they see fit.

Yep, that's exactly it.
Furthermore, they often give you a list of accepted, and minimally acceptable, specs.

Remember: these people are NOT consumers.

It's so hard for consumer to grasp this concept, and is usually accompanied by whining about file size.

plus they often would need to incorporate additional metadata during the ingest regardless, which you would have no way of prepping ahead of time.

I always hated metadata. At one point in time, I had to compress (and often restore/prep) legacy content for streaming archives, as it predated the modern setups. But I was also required to insert that metadata to comply with the new standards. I did whatever I could to shift that work onto somebody else. Metadata is about a non-video as video gets, and I quite frankly did want to learn most of it.

[Cornucopia]

Not really sure what kind of CDN conglomeration or process he's questing for, but Ooyala, Wowza, Imagen etc. are big players in the hybrid online/broadcast and b2b aggregation arenas.

I think he's fishing for info. There are NO monolithic systems, because there are huge variation in architectures worldwide, based usually on native-son corporate bias. But one can at least bank on international format standards such as MXF/BXF, MPEG2 & AVC-Intra, etc.

Scott

[KarMa]

...

One thing you've overlooked is multicast. Many (most?) carrier signals has multiple things going on, not a single broadcast. It got really complicated starting about 10 years ago.

I thought I was pretty clear when talking about multicast (just didn't call it by name). And how multicasting broadcasters have to share bandwidth among all the channels on a frequency. Add in VBR among the multiple channels on the single frequency would make it impossible/impractical to make custom MPEG2 encodes that would play nicely with the other channels and not go over the bitrate budget. Making it simpler for the station to just re-encode the program on the fly.

Nope - 19.3904Mbps is nett bitrate (useful, before FEC). After FEC 8-VSB bitrate is around 32.28Mbps

Looks like you were generally right about FEC and ATSC. From my reading it looks like there are two stages of FEC at play. First one takes an idividual .TS packet (187 bytes) and creates 20 bytes of Reed-Solomon parity for error correction, and can correct 10 bytes worth of errors. The second method comes from taking the .TS packet and RS data (207 bytes) and sending that through a 2/3 rate trellis coding (error correction). Which takes every 2 bits and creates 3 bits for transmission. Meaning that our packet has expanded again from 207 bytes to 310.5 bytes. The trellis coding is also interleaved. There are some other extra data I think but that was the bulk of it. I never read the ATSC papers before so that was a learning experience.

[chris319]

Not really sure what kind of CDN conglomeration or process he's questing for, but Ooyala, Wowza, Imagen etc. are big players in the hybrid online/broadcast and b2b aggregation arenas.

Nope.

They are on the tip of the tongue of anyone who deals with television syndication.

[Cornucopia]

And yet you have avoided them throughout the thread. While also not clarifying your issue, beyond the “concern about bitrate for ATSC?”.

I remember you and your Instant Eyedropper on the YUV material troll bs. smh.

Scott

[chris319]

I remember you and your Instant Eyedropper on the YUV material troll bs. smh.

Scott

If you want the answer to the question I posed, you're not going to get it by hurling insults.

[Cornucopia]

YOU came here with a newbie-ish (for a producer) question.

We gave you legit answers.

You sidestepped & ignored those answers and instead started throwing around allusions to standards.

We know the standards and repeated our suggestions based those and on our experience.

Instead of taking our advice, or asking a legitimate counter question, like "under what circumstances do you apply this preference...?", you refer vaguely to some OTHER set of standards that you claim are the Holy Grail.

Then do a backhanded jab at my (or our, if the question was meant more generally) credentials by demanding we read your mind and fill in the blank of something you seem to consider obvious, yet still haven't come out and stated plainly.

I personally don't give a $h!t about syndication, but have worked for decades in the production/post business, supplying material to local, regional and national broadcasters & cable channels, so I know what they've asked for and what to recommend you give them. I cannot tell from your nudges & winks whether you are alluding to equipment, processes, workflows, formats & standards, supply chains, power players, or brands. So I'm certainly not going to fall for your verbal Hobson's choice.

Do you want help, or don't you? If so, stop being elliptical and pretentious. That is the mark of a troll. If you don't want to be categorized that way, don't speak that way.
We'll try to thoroughly help those who are honest and unassuming. But I'm done with helping those who are mainly in it for the head games, and you'll find little others here who would.

Scott

[pandy]

Looks like you were generally right about FEC and ATSC. From my reading it looks like there are two stages of FEC at play. First one takes an idividual .TS packet (187 bytes) and creates 20 bytes of Reed-Solomon parity for error correction, and can correct 10 bytes worth of errors. The second method comes from taking the .TS packet and RS data (207 bytes) and sending that through a 2/3 rate trellis coding (error correction). Which takes every 2 bits and creates 3 bits for transmission. Meaning that our packet has expanded again from 207 bytes to 310.5 bytes. The trellis coding is also interleaved. There are some other extra data I think but that was the bulk of it. I never read the ATSC papers before so that was a learning experience.

Usually nett TS packet size is 188 bytes (187 for 8-VSB) and gross packet size is 204 bytes, those 16 bytes are RS CRC (ATSC use 20 RS CRC bytes thus gross packet size is 207 in 8VSB but on QAM like cable this will be 208 due of 188 byte packet - depends on equipment configuration and internal practices).

I would avoid direct link between RS CRC and FEC on digital modulation side. Idea behind FEC on digital modulation is to deal with unique analog nature of transmission medium (assumption is that transmission medium is not error-free) where RS CRC targeting digital link (so it assume quasi error-free operation) - from my perspective this is fundamentally different approach - RS CRC operate on binary data where FEC (simplification) operate on analog signal, this strict separation allow also to calculate and compare eventual codding gain (RS CRC is constant for all types of digital broadcast).
There are other factors directly affecting bitrate vs channel bandwidth calculations like pilot tone, sync signal etc.

Perhaps you will find this interesting: https://www.youtube.com/watch?v=FVRRfR6wjL0 - seem there is possible to use few $ USB3toVGA converter as SDR transmitter ( https://www.rtl-sdr.com/osmo-fl2k-a-tx-only-sdr-hacked-from-commodity-5-usb-to-vga-ada...-gsm-umts-gps/ ) thus for less than 10$ you may start own 8-VSB broadcast.

[chris319]

Perhaps you will find this interesting: https://www.youtube.com/watch?v=FVRRfR6wjL0 - seem there is possible to use few $ USB3toVGA converter as SDR transmitter ( https://www.rtl-sdr.com/osmo-fl2k-a-tx-only-sdr-hacked-from-commodity-5-usb-to-vga-ada...-gsm-umts-gps/ ) thus for less than 10$ you may start own 8-VSB broadcast.

That looks pretty cool!

[chris319]

https://wolfcrow.com/blog/understanding-the-limits-of-data-rates-and-transmission/