Slashdot Mirror

What were you saying about HEVC being too expensive to be available in less-expensive devices?

$40 for a 4k HDR h.265 Roku is pretty much mainstream. Which means aV1is dead-in-the-water.

AV1 hardware acceleration will be TWO YEARS behind the $40 Roku, and you can be sure that it will cost OVER $100 o release (like the first 4k Roku).

HEVC enjoyed early adoption beause of early phone spec war. My Galaxy S4 had HEVC playback built in,

HEVC encode support was added to devices after the S4 a Apple, because video storage space is limited on a cellphone. The TVs have actually been slow to adopt HEVC compared to the rest of the industry, but 4k TVs with HEVC haw been around fo five years now, an 4k BluRay is almost two years old. Both are standard devices that don't support AV1.

The other upcoming standard hat will also kill AV1 is ATSC 3.0.

https://www.atsc.org/newslette...

Part of ATSC 3.0, the standard A/323 defines a wireless uplink transmitter, supporting the Internet Protocol, built into your TV set, operating on a different frequency band than the downlink broadcast signal which contains the video stream.

By implementing this standard, a TV becomes a two-way communication device even if you don't plug it into Ethernet or WiFi.

ATSC 3.0 will be delivered over-the-air, just like 1.0. The difference is the signal is based on "internet protocol" for reasons that make it easy for any device (tablet, phone) to receive the signals. Also, ATSC 3.0 is designed for two-way communication. What is interesting is how they plan on doing this. Turns out there may be plans to have what is called a "Dedicated Return Channel" (DRC), which is a separate frequency that the TV uses to transmit data to the broadcast station. DRC can be read about here: https://www.atsc.org/candidate... If this turns out to be true, it's essentially a "free" over-the-air quasi internet connection controlled and limited by the broadcast station. This is a pretty significant detail.

It's going to be a fake standard that will be illegal for anyone to implement without getting permission (which you do by paying money and signing a contract agreeing to make the software not work very well). Here is the part of the ATSC 3.0 standard about "security".

It's got DRM.

If you aren't pirating yet, then you're going to be supporting this expansion of DRM. You really should be pirating, and even your non-geek friends and family members should be doing it too. Pirate, so that you don't have to pay money for boxes that implement this shit which is intended to break things. Pirates don't have to use shitty hardware or software. It's the easiest thing to do (fewer hassles than paying), and also the best experience by a wide margin.

You don't need 0ms. If you can keep it under 50ms it's undetectable for most humans. 40ms seems to be a minimum human nervous system latency. Spiders can do 20ms, but spider music is a niche case.

Looks like they DID in fact use something similar. Someone else pointed to this specifically. (PDF warning)

Thanks for the PDF warning. I mean we are all SO FUCKING STUPID that we would never think to move the cursor over that link for the 0.3 seconds it takes to glance at the URL and see that for ourselves. We are in fact so dumb, we always click a link random strangers provide without ever checking out anything about it.

We'd be lost without you, man.

Looks like they DID in fact use something similar. Someone else pointed to this specifically. (PDF warning)

That's actually a part of the reason the FCC has taken so long to pass the regulation in the first place. However, that argument no long applies. The technical document describing it is here. That document describes the Normalization process the commercial should be sent though to make it in compliance. Someone could probably try to subvert it, but that's what the reporting is for. If there is a complaint then the FCC will go back and look to see if it was a problem with the Algorithm or if it was someone subverting it.

By the way, both the CALM Act (Public Law 111-311) and the FCC Report and Order refer to ATSC A/85 "Techniques for Establishing and Maintaining Audio Loudness for Digital Television".

The CALM Act references ATSC RP A/85, which in turn references ITU-R BS.1770, which is a loudness measure based on integrating audio power multiplied by a frequency weighting curve that weights higher frequencies more and lower frequencies less.

They will enforce it by adhering to the standards that were written long before the law was.

Will the loudness of a particular ad be determined by...

...its peak loudness...
"blah blah BLAH!! blah blah blah" = BLAH!!

...or its mean loudness...
"blah blah BLAH!! blah blah blah" = BLAH

If its the first one, it's all good. If it's the second, this could get ugly. (The specs are posted but tl;dr and I'm no audio engineer.)

.

Dynamic range compression? What we have (had?) in the UK was a decibel limit, so in some cases* they just lifted everything under the limit to increase loudness. Lots of hassle for that. The law seems to legally enforce ATSC guidelines for loudness on programming when broadcasting ads, which on my cursory reading means that there's a strict loudness level and dynamic range they have to work to.

*Notoriously, when Lost came over here they ran an extra ten minutes of ads per episode and made them ridiculously loud

Simply saying the volume can't be above X dB means that commercials will be at exactly X dB for the entire time. Or they'll start using odd/distorted/alarming sounds (sirens, glass breaking, babies crying, etc)

The CALM Act refers to the use of ATSC A/85 'Recommended Practice: Techniques for Establishing and Maintaining Audio Loudness for Digital Television', which is mainly based on the ITU-R BS.1770 LKFS apparent loudness measurement, which is a frequency-weighted power measurement.

The truth is that an expected loud noise (like seeing someone pull the trigger on a gun that then shoots) is less apparently loud than a surprise loud noise (like a bomb going off without notice), but there is no way to effectively measure that with a mechanical device.

There are other known temporal issues with loudness perception that also are unlikely to be fully comprehended by BS.1770 LKFS, but it is the best thing we have right now.

I suspect that folks may be able to hack the current lineup of WRTs to spit out an ATSC signal.

No, there is absolutely no way this could occur. ATSC is 8VSB modulation, which is completely unrelated to the modulation technique used in WiFi.

But if you really want to try, here is all you need to do....

Beyond that, the creation of a 19 Mbps MPEG-2 TS of appropriate quality for DTV broadcast (PCR accuracy of 500nS, for example) is pretty tough to do without professional equipment, though maybe you could make a really, really crappy signal...

Except one thing - ATSC digital television uses A/52b for audio (you probably know this as AC-3 or "Dolby Digital").

A/52b is a lossy audio format. It does not matter that you can get lossless compressed 48kHz audio that uses less bitrate than a raw PCM file (and it is likely that the compressed file is just PCM ran through a block-sorting compressor, e.g. gzip).

LAME at 160kbps gives better quality than L3A (Fraunhofer IIS's codec) at 256kbps, I'll give you that, as a lot of standards never quite specify details for the encoder, or allow a lot of flexibility in the bitstreams. But here, we are discussing ATSC digital television. You have to compare results against the same codec.

I am not aware if A/52b standardizes an encoder, but if not, then, like ISO/MPEG Layer-III Audio, it is quite possible (and quite often happens with ISO/MPEG Layer-III Audio, compare LAME v. hardware encoders) to have a decent software encoder produce better quality streams at lower bitrates than an inferior hardware encoder.

However, the only way that a lower bitrate can yield better quality is if the ATSC codecs are similiar to ISO/MPEG Layer-III Audio in that the standards only specify a decoder, leaving a wide variety of possible encoders. Without a standardized encoder, you generally end up with a less than optimal reference encoder (which was the case with ISO/MPEG Layer-III Audio) and a plethora of different hardware and software encoder implementations, each employing highly differing encoding schemes, providing highly varying quality yet bitstream compliant results.

The rest of Slashdot is rather technically clued-in, rather it's you that is technically clueless.

I hate loud commercials too, but this is just too much government IMHO

Since Broadcasters (OTA/Cable/Fiber) all have to have FCC licenses, the government is already involved in the minutia of their business practices.

Here's what the bill is asking broadcasters to follow:
http://www.atsc.org/standards/a_85-2009.pdf

It's 72 pages and I don't have the technical knowledge to understand it all anyways, but I think the original idea of "commercials cannot be louder than the program's average volume" is a pretty simple alternative to guidelines written by the industry.

Though I don't doubt that content owners would surely love to impose DRM on broadcast content, it's simply not provided for in the ATSC specifications for MPEG2 over-the-air transport streams.

Actually, the ATSC spec does allow any abitrary types of packets to be inserted into the stream. These could be used for DRM authorization, etc. The ATSC spec as adopted by the FCC is a more relevant link, as is the conditional access specification, which specifically deals with this sort of thing.

But, the FCC requires that the OTA broadcast be unencrypted, so normal MPEG-2 that is receivable by all will be there as long as the FCC controls the station license.

The upshot of this is that nothing prevents a station from sending a 480i MPEG-2 stream as the unencrypted one, and adding an encrypted MPEG-4 1080/60p stream for paying customers. At this point, only market forces (in particular, network affiliations) will keep this sort of thing from being the standard for OTA TV in the US.

Though I don't doubt that content owners would surely love to impose DRM on broadcast content, it's simply not provided for in the ATSC specifications for MPEG2 over-the-air transport streams.

Actually, the ATSC spec does allow any abitrary types of packets to be inserted into the stream. These could be used for DRM authorization, etc. The ATSC spec as adopted by the FCC is a more relevant link, as is the conditional access specification, which specifically deals with this sort of thing.

But, the FCC requires that the OTA broadcast be unencrypted, so normal MPEG-2 that is receivable by all will be there as long as the FCC controls the station license.

The upshot of this is that nothing prevents a station from sending a 480i MPEG-2 stream as the unencrypted one, and adding an encrypted MPEG-4 1080/60p stream for paying customers. At this point, only market forces (in particular, network affiliations) will keep this sort of thing from being the standard for OTA TV in the US.

Fair enough; although that suggests that it's been in the works for rather a long time(!)

I actually couldn't find the date on Wikipedia, looking at various articles such as the ATSC one. It's probably there, and/or I'll try to remember to add it.

But, from http://www.atsc.org/aboutatsc.html

On December 24, 1996, the United States Federal Communications Commission (FCC) adopted the major elements of the ATSC Digital Television (DTV) Standard (A/53).

That's when it was *adopted*. The committee itself was formed in 1983.

If you want to blame the FCC for something, blame them for selecting ATSC. Why on earth they chose MPEG2 when everyone else gets MPEG4 or H.264 is anyone's guess (greed from patent holders maybe?).

Development of the ATSC standard started in 1987, with the decision to use digital being decided in 1993. The FCC adopted the standard in 1996.

No need to guess as to why they didn't use a MPEG4(1998) or H.264(2003), they simply didn't exist when the standard was established.

If you want to blame the FCC for something, blame them for selecting ATSC. Why on earth they chose MPEG2 when everyone else gets MPEG4 or H.264 is anyone's guess (greed from patent holders maybe?).

Development of the ATSC standard started in 1987, with the decision to use digital being decided in 1993. The FCC adopted the standard in 1996.

No need to guess as to why they didn't use a MPEG4(1998) or H.264(2003), they simply didn't exist when the standard was established.

The redistribution control descriptor ("RC Descriptor","Broadcast Flag") is contained in ATSC Program and System Information Protocol (PSIP).

According to ATSC A/65, the RC descriptor is mandatory in the PMT and EIT tables for broadcast, and if ATSC is carried over cable, it needs to be in the PMT and EIT as well (if there is an EIT).

The question is "how were you watching the show, and how did it get to you"?

If you were watching analog terrestrial broadcast television or on your cable analog tier, there is no ATSC stream to have the broadcast flag.

If you were watching on digital cable or satellite, the question is whether the original ATSC PMT and/or EIT were appropriately carried to you. Many cable and DBS providers re-compress the original ATSC signal, and in the process of doing so they may or may not properly carry the PSIP tables to the end user. It is also possible that your cable MSO has a direct fiber video connection to the television station, in which case the PSIP tables are not effectively sent to the cable MSO in the first place.

If you are using an analog output (composite, component, or S-Video) of a digital cable or satellite decoder box to go into your recording device, there is no broadcast flag present at the recording device.

If the broadcast flag in the PSIP tables doesn't reach your recording device, obviously even compliant devices won't know not to record.

Theoretically, any ATSC digital television decoder that has an HDMI output should only be willing to send broadcast flagged video to HDCP encryption compliant devices. Some DVI output devices will adhere to this as well if they support HDCP.

Can we please call it the proper name, the "redistribution contol descriptor" in PSIP EIT, as defined by ATSC A/65C!

Yes, I mean the US government has been so good at mandating the switchover of standards. I mean the Metric Conversion Act of 1975 worked flawlessly. The end of analogue TV in the US happened in 2006 exactly as the FCC mandated in 1997.

I do think the best thing the FCC did for the digital television switchover is to make the sales of analogue TVs illegal. The same should be done for IPv6.

Well, here in the USA, the government is taking away spectrum from a well established industry:

http://www.atsc.org/faq/faq_general.html

Oh, and they are requring everyone in the US to buy a new TV or STB (At least we get better pictures). All because the FCC wanted to allow secondary use on the unused channels for first responder dispatch radios.

Granted, most of the problem could have been avoided with some reasonable thinking from all parties involved, but hey, we're Americans! We want an unresonable response to a reasonable situation!

I think you mean ATSC

That programming guide information is sent over both cable and terrestrial broadcast systems.

If you pay for what is already being sent into your house for free, what does that say about you?

"I can't code?"

Look at http://www.atsc.org/ for free specs.

Yes,

PSIP data is your guide data, ratings, descriptions, and everything else except the new version of closed captions. EIA-708? There is actually more to the full protocol, but that is really outside this discussion

See, a broadcast shop will generally have a PSIP generator which feeds the encoder a data stream. It generally provides 12 hours or more of data. (I would have to look, but I think its 3 four hour block or 4 3 hour blocks)

Newer or more expensive encoders are capable of generating PSIP information on their own and take input over the network. Which is just a little too expensive... so everyone in the industry scrambled to bolt on PSIP generators for a cost effective solution ... unless you were lucky enough to have one of the nice models.

Granted, most shops are probably just getting all of their data fed to them from a provider, but some places (those who value money) will generate this on their own.

So yeah, the broadcast flag is embedded in there and could be set by someone further upstream, but the control always has been in the broadcasters hands.

Here, we just extract the information from the database of our traffic/billing program and feed it into a vendor software package which then shoots it off to the PSIP generator. This generator in turn feeds directly into our encoder via an ASI port. The encoder provides an mpeg stream our DTV transmitter finds tasty. (God awful design if you ask me, but the full PSIP protocol wasn't required until Januarish... so most of the older units take dynamic PSIP data from an ASI port)

So it might remain there as a legacy item, but I'm sure most will get an update or two that will remove it.

Now, to be perfectly honest, when I went over the standards for PSIP... I don't recall the broadcast flag being in there, but it was probably labeled something else.

I might be wrong... feel free to read up on it...
http://www.atsc.org/standards/a_65b.pdf

Mind you, not everything in the protocol is required... you would have to read up on the FCC rules and regulations (September 04 release) for a large portion of the specifics.

ATSC Standard A/80:
Modulation and Coding Requirements for Digital TV (DTV) Applications Over Satellite
17 July 1999, Download PDF File
This document defines a standard for modulation and coding of data delivered over satellite for digital television contribution and distribution applications. The data can be a collection of program material including video, audio, data, multimedia, or other material. It includes the ability to handle multiplexed bit streams in accordance with the MPEG-2 Systems layer, but it is not limited to this format and makes provision for arbitrary types of data as well. QPSK, 8PSK and 16 QAM modulation modes are included, as well as a range of forward error correction techniques.

Prediction: a broadcast flag will not be adopted by any country that uses PAL.

The gap in quality between PAL and HDTV is much less than that between NTSC and HDTV, so HDTV is a very difficult sell in these countries. Adding extra limitations would kill it stone dead. Since the U.S. implementation of the flag is specific to ATSC, there's no compatibility reason for any PAL-based equipment to support it, either.

Very well,

Would you accept a link from ATSC?

http://www.atsc.org/news_information/papers/1995_a cats/finalrpt.html

For scanning, the standard includes two HDTV formats: a 720 lines x 1280 pixels per line format at 24, 30, and 60 frames per second progressively scanned, and a 1080 lines x 1920 pixels per line format at 24 and 30 frames per second progressively scanned and 60 fields per second interlaced scanned. Two SDTV formats also are described: 480 lines by 704 pixels per line in both 4:3 and 16:9 aspect ratios, and 480 lines by 640 pixels per line in 4:3 aspect ratio. Each SDTV format offers progressive scanning modes.

DVB = Digital Video Broadcast
ATSC = Advanced Television Systems Committee

It would appear that the american digital TV standard is ATSC's 8VSB . But that may change to DVB-T anyway, which is the standard in Australia and the UK. As for encryption, that only comes into effect if you choose to get your digital from a cable or satellite company which requires the use of a smart card. There is no reason that a PC card can't descramble over the air broadcasts of digital TV. Look here for examples of US digital TV cards.

How you got rated +4 informative is beyond me.

It's amazing how the US still see's itself as the centre of the world and is still bent on adopting a different standard to everyone else when it comes to pretty much anything. Mobile phones, power systems, etc.
There is some perfectly good software being written in Australia but it just happens that it doesn't yet support digital TV either.

Showshifter seems to be the major one thats going with DVB at the moment, and once it supports my card, is probably the one I'll go with.

The problem with this flag is that it is basically undefined at this point in time. If you look at the actual spec of the Redistribution Control Descriptor ( Spec is here ) you will find that it can be up to 257 bytes in length including header. The header in effect is just a flag and the length of the descriptor in bytes. SO basically they could implement any type of DRM they want in this without ANY oversight until someone takes them to court and challanges the application of the descriptor in real life.

In the US, HD DTV terrestrial broadcasts are done with a MPEG-2 transport stream of maximum 19.39 Mbps using the ATSC standard.

In practice, most people will be receiving HD at slightly lower speeds to allow a multiplexed SD feed (2-4 Mbps) in the ATSC channel along with the HD feed (15-17 Mbps)

I am under the impression that most DBS HD will also be in the 10-20 Mbps department. HDNet programming varies from 10 Mbps to 18 Mbps, while DBS HBO HD only goes up to 15 Mbps.

Uncompressed HD is somewhere around 1.485 Gbps. The "standard" for broadcast HD tapes is HDCAM which is at 140 Mbps. Then it gets squished down to below 19.39 Mbps for broadcast. So there is a lot of compression before you get over the air.

The FCC assigned a royalty sharing organization, ATSC, to deliver a "unified" Digital Television system. But ATSC had no motivation to use the improved European-developed COFDM DTV system now the world-wide DTV standard. Unlike ATSC, it works. You can get it free over the air or in a bus. I believe former FCC director William Kennard is to blame. He didn't want to slow down the "lucrative" 3G auctions. Now we're stuck with a broken DTV system, the VHF auctions are delayed (again), and everyone lost...except the cellular carriers.

In the UK, all you need is a $99 box with rabbit ears. US broadcasters are stuck. They may eventually be forced into PPV and soft porn since only rooftop antennas can pick up ATSC. The FCC let this happen. It's criminal negligence."

Wi-Lan isn't Wi-Fi (802.11b)- wi-lan is W-OFDM, wireless t1/e1- and they have a great technology for the reception of HDTV so that you don't get the silly black blocks that disrupt signal,-- but instead, the FCC chose to back 8-VSB, an inferior technology.

The greater question is, why is the FCC deciding this? They didn't decide which cell phone technology was going to reign, only which frequencies we'd use.

Sources? http://www.wi-lan.com

commentary: If we were to follow the 'lead' from the ATSC then this is what the future would look like. The Americans are still in denial about the Brazilian (and other) DTT test results (denying the basic facts that a single carrier system can never work for wireless DTT) and have carried out their own tests arriving at their own conclusions using incorrectly configured DVB-T equipment. The sooner the US drops its single carrier 8-VSB based standard in favour of an OFDM solution the better for all concerned. A report summarising why DTV is not happening in the US (example of flawed thinking: DTV does not necessarily mean HDTV). Unfortunately, DVB and ISDB have (so far) been unable to agree on a common OFDM way forward even though both standards are nearly exactly the same (ISDB improved the DVB-T standard with the addition of extra time interleaving, band segmentation and the option for 4k carriers). However, due to the wide acceptance of DVB-T and its myriad other supporting standards it is unlikely that ISDB compliant equipment will ever be deployed outside of Japan.

Take-up of Digital TV in the UK has been the most successful in the world in percentage terms (the US is not far behind); but can it continue to grow at the same pace? ITVdigital, the DTT service provider in the UK, launched with an early (2k carrier) release of DVB-T and had been reasonably successful (although I am sure some would disagree?) with over 1.2 million subscribers up to the end of 2001. Unfortunately, due to a combination of factors ITVdigital are in danger of closing down and are currently in administration. The BBC in their annual R&D review for 2000-2001 (Digital Television Distribution section) list some of the issues associated with DTT in the UK and give an interesting insight into how improvements can be achieved. Thanks to the wealth of experience gained in the UK other European DTT service providers will be able to provide a more advanced and improved service to their customers. Get the insider views on the UK DTT experience from the following newsgroup: uk.tech.digital-tv;

Just visit the ATSC for all the documents you need are right there under "Standards".

See, for example, this draft (PDF), and this report (MSWord doc).

Technical information is available from the ATSC website. The RC descriptor is in document A/65A, Amendment 3.

You can build your own ATSC compliant MPEG transport stream recorder/playback with a PC and this PCI card. It even has a DTV tuner as well, so you just hook it up to an antenna.

That said, there is plenty of DTV content out there already. Most major networks have HD primetime programming, and simulcast their analog broadcasts on their digital channel in SD. There are even special HD content producers such as HDNet (backed by Mark Cuban of Broadcast.Com fame)

As someone that works in the HDTV industry, broadcasters use the ATSC standard for HDTV broadcasts. Where does MPAA come in to this equation?

No. The FCC regulates over-the-air transmissions of television and they have standardized ATSC which is basically unencrypted MPEG-2 at a maximum data rate of 19 Mbps. ATSC also has AC-3 support just in case PBS wants to broadcast surround sound.

HDTV is 1920x1080 at a few different frame rates.

Actually, there are six HDTV formats, according to the Advanced Television Standards Committee:

1920x1080 @ 24 fps (1080p24, or just "24p")
1920x1080 @ 30 fps (1080p)
1920x1080 @ 60 fps (1080i)
1280x720 @ 24 fps
1280x720 @ 30 fps
1280x720 @ 60 fps

The ATSC has also approved 12 (!!) formats for digital standard definition TV.

More info here: http://www.atsc.org/press/PR_Def.html

The standard for Digital Video (and digital cable) in the US is ATSC (Advanced Television Systems Committee). Because American business people are such pains in the ass, of course we are the only country in the world not using DVB. Many companies are not using ATSC or are using DVB because it is cheaper anyway so there is sort of mass chaos right now in America.

The FCC has no interest in phasing out analogy but does have interest in standardizing ATSC.

Your box doesn't request a channel, but rather a frequency range which carries multiple channels. It's actually, a bit more sophisticated than that though...

• MIT is a private institution. Yes it gets money from public grants & programs, almost every accredited institution does. MIT is no more a public or government entity then the trade schools that advertise on late night TV. Furthermore even parts of the US Gov't doing public work can now claim IP on some of their products.
• Yes MIT uses Graduate Students and no they don't generally earn much. On the other hand putting them to work probably does keep their tuition down a bit and heck, if you don't like it you can always go someplace else (courts rarely require X years attending MIT as part of a sentence and the campus is very open, one is free to leave it and not return at any time.) However this has nothing to do with the topic and just gets brought up every time a .edu issue is raised.
• The US HDTV standards happened after the FCC ran a competition in which four finalists emerged. Rather then a winner-take-all situation emerging (which would of taken years with the legal wrangling) a pooling of the "best" of a various technologies was brokered. As the patent & other IP issues around HDTV were spread out amongst several institutions and companies a pool was created held by the companies who now dubbed themselves "The Grand Alliance". Then as any other number of projects have done (DVD, Firewire, etc.) an examiner was brought in to determine exactly what IP was required then a formula was put in place to compensate the IP owners and everything got signed off on.
• MIT earns some large sum of money every year from it's IP material, money which helps fund them. Sony does the same from it's own portfolio. In this case MIT's IP is used through the Grand Alliance agreement, something which Sony seems to have now decided to ignore. Whether or not you agree with all details of all IP in this case it seems rather strightforward and not to fall into any of the areas which so many folks find offensive.
• Yes MIT (a US institution) can sue Sony (a company HQ'd in Japan.) Internationial trade has been going on since we first worked out nations and the laws are rather straightforward in cases like this. Did anyone other then a few sappy posters think that this was a new situation, that one couldn't sue an offshore entity?

Adobe refuses to support TIFF-FX unless Xerox releases rights for its MRC technology to Adobe.

Xerox, meanwhile, won't back TIFF-FX unless Adobe promises to support the standard in its next version of TIFF.

A license will be made available without compensation to applicants desiring to utilize the license for the purpose of implementing the standard.

Adobe refuses to support TIFF-FX unless Xerox releases rights for its MRC technology to Adobe.

Xerox, meanwhile, won't back TIFF-FX unless Adobe promises to support the standard in its next version of TIFF.

A license will be made available without compensation to applicants desiring to utilize the license for the purpose of implementing the standard.

Prior to approval of such a proposed ATSC Standard, the ATSC shall receive from the patent holder (in a form approved by the ATSC Executive Committee) either: assurance in the form of a general disclaimer to the effect that the patentee does not hold and does not anticipate holding any invention whose use would be required for compliance with the proposed ATSC Standard or assurance that:

(a) A license will be made available without compensation to applicants desiring to utilize the license for the purpose of implementing the standard, or

(b) A license will be made available to applicants under reasonable terms and conditions that are demonstrably free of any unfair discrimination.

This assurance, along with a statement of the basis for considering such terms and conditions reasonable and free of any unfair discrimination, shall be submitted to the ATSC Executive Committee for review.

Not that this has any effect on patent claims.

- Mycroft