Encryption

[sfhorwa1]

So exactly what does Silicondust plan to offer their customers in regard to DRM encryption? I see a lot of what you can't do, but nothing about what you can do. I read what you plan to offer broadcasters, but not your customers. Where are you at in the certification process? Why are other tuner manufactures getting certified but you can't? If ***** beats you on certification your very expensive tuner will become a very expensive paper weight. you are a huge disappoint and are not living up to your promises regarding ATSC 3.0.

[anonymouse]

So exactly what does Silicondust plan to offer their customers in regard to DRM encryption? I see a lot of what you can't do, but nothing about what you can do.

From the first post in this thread:

Will DRM encrypted ATSC 3.0 channels play on my Android or Fire TV device?
Using a gateway product - we expect it will be possible in the future but it is not possible today. The Google Widevine DRM decryption is possible but there are other requirements that are draft/incomplete at this time. There is activity happening.

Why are other tuner manufactures getting certified but you can't?

They're not manufacturing networked/gateway devices. And A3SA requirements appear to be a moving target -- apparently they can't be bothered to offer an API.

I recommend reading at least the first page of this thread.

[DSperber]

From the first post in this thread:

Will DRM encrypted ATSC 3.0 channels play on my Android or Fire TV device?
Using a gateway product - we expect it will be possible in the future but it is not possible today. The Google Widevine DRM decryption is possible but there are other requirements that are draft/incomplete at this time. There is activity happening.

It would be a very different product. "Converter boxes"/set-top-boxes is a category that already has options from other companies, has more limited applications than a gateway product, and a whole lot of new requirements/costs behind the scenes that don't exist for a gateway product. A set-top-box, even based on Android, is supposed to be locked down and not have third party apps on it. It would also be starting from almost zero, so it's not like such a product from us would come to market in the near-future.

Android is also a platform that we feel has a path forward, so there's no real point in us making an Android-based box at this point, when someone can go buy a $20 box from Walmart of Amazon and will eventually get DRM ATSC 3.0 channels.

I'm not sure I understand what Ned is saying here, about the possible someday eventual maybe usability of an $20 ONN Android-based Widevine-based ATSC 3.0 box at Walmart that "will eventually get DRM ATSC 3.0 channels". Does that mean he's predicting that the device itself will someday be receiving updates so that it will become yet one more (and in this case very inexpensive) "one-device-per-TV" hardware solution for both DRM and AC4, thus adding yet another DRM-capable (and even possibly local AC4-capable) "one device per TV" competitor to the client/server gateway tuner/DVR product that we all bought from SD when we bought our own SD Flex 4K?

So since everybody can right now for a higher price, and someday in the future for a much lesser price, go with the "one device per TV DRM+AC4 solution", that there's no point for SD to continue moving forward with invention of any new SD "client HDHR Android/Widevine hardware device/gizmo/dongle" to support their network tuner/DVR?

All evidence from the past 15 months of "working on it (apparently not yet successfully)" suggests that A3SA is not going to support a "software-based 3rd-party app running in someone else's box". In the meantime, several other "one device per TV" competitor products HAVE been 100% successful in delivering hardware-based live-view DRM+AC4 in their hardware/software devices. And at least one also has "beta" DVR for DRM, with the other talking about possibly mid-February submission to A3SA for their "hardware-based solution" and possible late-March "publishing to customers" of the firmware upgrade so that DRM+AC4 will now also be available in their "one device per TV" product.

So we don't have to wait for a $20 product. We can spend some more money and have it today, or really soon. And if we're now willing to change our own TV watching styles, and just accept a "one device per TV" way to deal with ATSC 3.0 DRM+AC4, we don't have to wait.

Of course we here on this SD forum on this thread who've bought the SD Flex 4K don't really want a "one device per TV" implementation. We really do want a whole-home client/server network tuner/DVR for all content , ATSC 1.0 and 3.0, both DRM and non-DRM, and also possibly even cable TV (via cablecard tuners). That's really the holy grail.

And if that really required some new "hardware HDHR client device" (at each TV) from SD to complete a topology that A3SA would then truly accept, maybe that's what should have been started 15 months ago. Because today we are seemingly no closer to a DRM+AC4(local) solution than when work seriously started on this issue using a software-based approach.

I may be very wrong, but I for one would have instantly bought an SD "hardware HDHR client device" (one per TV) if it gave me whole-home network tuner/DVR for all my OTA needs, both DRM and non-DRM. How is that any different from current totally independent one-device-per-TV competitive products, except that if it were an SD client device that talked to an SD server that we'd then truly have whole-home "locked down hardware HDHR client devices" client/server from SD, instead of completely separate independent TV locations per the competitors?

Think Windows Media Center server + extender/TV client.

[nickk]

One device per TV type ATSC 3.0 boxes have a technical enforcement that prevents you from watching outside your home [mission critical DRM restriction]. Specifically they can only connect to the TV via HDMI and there is a limit as to how long the HDMI cable can be.

We documented, implemented, and demonstrated cryptographically strong enforcement working on the HDHomeRun video gateway. Months later the A3SA decided to spec their own way to enforce this and they haven't documented the packet-format part of the protocol yet.

Silicondust making a Android player product will not solve this. We have to wait for the A3SA.

[anonymouse]

I'm not sure I understand what Ned is saying here, about the possible someday eventual maybe usability of an $20 ONN Android-based Widevine-based ATSC 3.0 box at Walmart that "will eventually get DRM ATSC 3.0 channels". Does that mean he's predicting that the device itself will someday be receiving updates so that it will become yet one more (and in this case very inexpensive) "one-device-per-TV" hardware solution for both DRM and AC4, thus adding yet another DRM-capable (and even possibly local AC4-capable) "one device per TV" competitor to the client/server gateway tuner/DVR product that we all bought from SD when we bought our own SD Flex 4K?

No. He's saying that someday, an Android-based streaming box that fully supports Widevine for decryption will work with the SD Flex 4K to get DRM ASTC 3.0 channels. A streaming box is not the same as tuner box (which is locked down and doesn't run other apps and can only work with the TV it is directly connected to).

So since everybody can right now for a higher price, and someday in the future for a much lesser price, go with the "one device per TV DRM+AC4 solution", that there's no point for SD to continue moving forward with invention of any new SD "client HDHR Android/Widevine hardware device/gizmo/dongle" to support their network tuner/DVR?

Incorrect. You're conflating a set-top / converter / single-use box with a more versatile, can run all kinds of apps streaming box. In other words, not all boxes with an Android OS are the same: some are single use and some are multipurpose. SD is aiming for the multipurpose market while all those other manufactures are making single-purpose boxes.

So we don't have to wait for a $20 product. We can spend some more money and have it today, or really soon. And if we're now willing to change our own TV watching styles, and just accept a "one device per TV" way to deal with ATSC 3.0 DRM+AC4, we don't have to wait.

Correct. And it's been said many times already. I'm unsure why you keep harping on this like it's new information.

And if that really required some new "hardware HDHR client device" (at each TV) from SD to complete a topology that A3SA would then truly accept, maybe that's what should have been started 15 months ago. Because today we are seemingly no closer to a DRM+AC4(local) solution than when work seriously started on this issue using a software-based approach.

Yeah, hindsight and all that. That and the fact that SD is committed to supporting their existing product and design approach.

I may be very wrong, but I for one would have instantly bought an SD "hardware HDHR client device" (one per TV) if it gave me whole-home network tuner/DVR for all my OTA needs, both DRM and non-DRM.
How is that any different from current totally independent one-device-per-TV competitive products, except that if it were an SD client device that talked to an SD server that we'd then truly have whole-home client/server instead of completely separate independent TV locations per the competitors?

Because that device that talks to the SD gateway could be any Android streaming, multipurpose box and not a locked-down single use one. Further, SD is clearly stated more than once that they are committed to their current design approach and will not be building and locked-down single-use Android clients.

You have brought this up several times now and I'm not sure why you think doing so is going to change anything about what SD has decided to do. Go get your single-use DRM-capable devices already.

[snowcat0]

One device per TV type ATSC 3.0 boxes have a technical enforcement that prevents you from watching outside your home [mission critical DRM restriction]. Specifically they can only connect to the TV via HDMI and there is a limit as to how long the HDMI cable can be.

We documented, implemented, and demonstrated cryptographically strong enforcement working on the HDHomeRun video gateway. Months later the A3SA decided to spec their own way to enforce this and they haven't documented the packet-format part of the protocol yet.

Silicondust making a Android player product will not solve this. We have to wait for the A3SA.

Has Silicondust lodge or consider lodging some complaints or breithings to the FCC? Considering how horrible a partner A3SA has been, I mean looking at what they have said would be allowed vs the rules they have given you seems they are talking out of both ends of there mouth.

[signcarver]

The two are not in conflict... The supposed "Encoding Rules" are not real rules... just a virtually empty set of promises of what they would like the stations to do and can be changed at any moment (just takes a few brodacsters to change those encoding rules). Every one of those rules MUST have the opposite capability from the device/player in place to become certified in case they wish to change them (the rules they posted even state "for encrypted broadcasts that are simulcast" which isn't always going to be the case).

SD/nickk most likely can't comment much on "Months later the A3SA decided to spec their own way to enforce this and they haven't documented the packet-format part of the protocol yet" but if I am understanding such correctly, I am actually a bit glad to see this (I know it caused problems and expenses for SD) as I was worried about further delays when half a dozen STBs all wanting to be their own gateway device needing to get a half a dozen different methods approved... it makes much more sense to have 1 or two such standards and they all work together (which is why I wouldn't mind such using DTCP2 if such was really an option... personally I think the first thing ATSC/A3SA should have doe is say DTCP2 isn't ready for such (nothing can support it unless one wants to be tied to one manufacturer for both client device and tuner) so lets allow 1080p and below to use DTCP-IP (from what I have been able to read of DTCP2 this is actually how they envisioned such, even permitting transposing to 1080p when needed to connect to a DTCP-IP capable device and they state DTCP2 is for 4K.8K content). I also see such change possibly making it into streaming devices such as roku, apple tv, etc. even though SD seems to think they won't be able to write an "app" for such thus concentrating on android/fireTV (and soon new fireTV products may not be a part of that).

[nickk]

personally I think the first thing ATSC/A3SA should have doe is say DTCP2 isn't ready for such (nothing can support it unless one wants to be tied to one manufacturer for both client device and tuner) so lets allow 1080p and below to use DTCP-IP

We tried asking for exactly that. Problem is DTCP1 doesn't have a way to specify all the usage restriction options broadcasters want.

[jwklinck]

One device per TV type ATSC 3.0 boxes have a technical enforcement that prevents you from watching outside your home [mission critical DRM restriction]. Specifically they can only connect to the TV via HDMI and there is a limit as to how long the HDMI cable can be.

We documented, implemented, and demonstrated cryptographically strong enforcement working on the HDHomeRun video gateway. Months later the A3SA decided to spec their own way to enforce this and they haven't documented the packet-format part of the protocol yet.

Silicondust making a Android player product will not solve this. We have to wait for the A3SA.

Until someone makes a box that takes the HDMI Input that now goes to the TV, takes it as input and then and acts as a gateway on your network.

[foxbat121]

One device per TV type ATSC 3.0 boxes have a technical enforcement that prevents you from watching outside your home [mission critical DRM restriction]. Specifically they can only connect to the TV via HDMI and there is a limit as to how long the HDMI cable can be.

We documented, implemented, and demonstrated cryptographically strong enforcement working on the HDHomeRun video gateway. Months later the A3SA decided to spec their own way to enforce this and they haven't documented the packet-format part of the protocol yet.

Silicondust making a Android player product will not solve this. We have to wait for the A3SA.

Until someone makes a box that takes the HDMI Input that now goes to the TV, takes it as input and then and acts as a gateway on your network.

That's where HDCP is supposed to prevent that, in theory. Such device will never be granted a licensed certificate/key for HDCP. Then, we have seen certain DRM certified ATSC 3.0 box doesn't enforce HDCP at all.

However, broadcasting live HDMI signal over network requires 10+Gbps bandwidth, beyond what majority of the home network can handle.

[diplexer]

Would just like to hear from SD if they are giving up on solving DRM since A3SA basically has put too many restrictions to overcome in a cost effective way? It's got to be eating into your resources, time, and profits to the point it's no longer worth risking the company. Especially if ATSC 3 never takes off.

[nickk]

Would just like to hear from SD if they are giving up on solving DRM since A3SA basically has put too many restrictions to overcome in a cost effective way? It's got to be eating into your resources, time, and profits to the point it's no longer worth risking the company. Especially if ATSC 3 never takes off.

As already stated many times we are doing DRM.

[howardc1243]

I'm not sure I understand what Ned is saying here, about the possible someday eventual maybe usability of an $20 ONN Android-based Widevine-based ATSC 3.0 box at Walmart that "will eventually get DRM ATSC 3.0 channels". Does that mean he's predicting that the device itself will someday be receiving updates so that it will become yet one more (and in this case very inexpensive) "one-device-per-TV" hardware solution for both DRM and AC4, thus adding yet another DRM-capable (and even possibly local AC4-capable) "one device per TV" competitor to the client/server gateway tuner/DVR product that we all bought from SD when we bought our own SD Flex 4K?

No. He's saying that someday, an Android-based streaming box that fully supports Widevine for decryption will work with the SD Flex 4K to get DRM ASTC 3.0 channels. A streaming box is not the same as tuner box (which is locked down and doesn't run other apps and can only work with the TV it is directly connected to).

So since everybody can right now for a higher price, and someday in the future for a much lesser price, go with the "one device per TV DRM+AC4 solution", that there's no point for SD to continue moving forward with invention of any new SD "client HDHR Android/Widevine hardware device/gizmo/dongle" to support their network tuner/DVR?

Incorrect. You're conflating a set-top / converter / single-use box with a more versatile, can run all kinds of apps streaming box. In other words, not all boxes with an Android OS are the same: some are single use and some are multipurpose. SD is aiming for the multipurpose market while all those other manufactures are making single-purpose boxes.

So we don't have to wait for a $20 product. We can spend some more money and have it today, or really soon. And if we're now willing to change our own TV watching styles, and just accept a "one device per TV" way to deal with ATSC 3.0 DRM+AC4, we don't have to wait.

Correct. And it's been said many times already. I'm unsure why you keep harping on this like it's new information.

And if that really required some new "hardware HDHR client device" (at each TV) from SD to complete a topology that A3SA would then truly accept, maybe that's what should have been started 15 months ago. Because today we are seemingly no closer to a DRM+AC4(local) solution than when work seriously started on this issue using a software-based approach.

Yeah, hindsight and all that. That and the fact that SD is committed to supporting their existing product and design approach.

I may be very wrong, but I for one would have instantly bought an SD "hardware HDHR client device" (one per TV) if it gave me whole-home network tuner/DVR for all my OTA needs, both DRM and non-DRM.
How is that any different from current totally independent one-device-per-TV competitive products, except that if it were an SD client device that talked to an SD server that we'd then truly have whole-home client/server instead of completely separate independent TV locations per the competitors?

Because that device that talks to the SD gateway could be any Android streaming, multipurpose box and not a locked-down single use one. Further, SD is clearly stated more than once that they are committed to their current design approach and will not be building and locked-down single-use Android clients.

You have brought this up several times now and I'm not sure why you think doing so is going to change anything about what SD has decided to do. Go get your single-use DRM-capable devices already.

what makes the hdhomerun unique is the hdhomerun gateway tuner is the driver and the network router is the provider and as thus the gateway tuner is serving as a sub-server, and being connected to the network router it then can broadcast a very short-range signal through the home.

that is the bane in a3sa's backend.

[matthewjbauer]

Do we have an ETA when DRM will be enabled? My local ABC, NBC, and CBS went DRM. Fox and CW don't do DRM yet though and I can't get PBS (although PBS shows up as ATSC 3.0). I won't be surprised if in the next 6 months that I lose all ATSC 3.0 stations to DRM (defeating the whole reason I purchased the Flex 4k over something else). If we're gonna be honest here, I don't think that we're going to get DRM decryption any time soon. Those tuner boxes that have DRM basically have it because they don't record and allow only 1 TV and there are so many rules and regulations surrounding it (too many to list here). I know Nickk said SD is working on DRM or something A3SA compliant, but I'll only believe what I see when I have the update on my device.

[nickk]

Do we have an ETA when DRM will be enabled?

No ETA yet... we have to wait for A3SA to finish and release a spec that can be implemented.