[mythtv-users] Uh-oh... pcHDTV slashdotted

[Dan Lanciani]

Yan-Fa Li <yanfali at best.com> wrote:

|Well that's always an issue with Binary, however, once a blob is 
|released it stays released and so long as the standard doesn't change 
|it's possible to use the old blob and ignore any new firmware with 
|cryptocrap additions.

Ah, but if that were true it should apply equally to set top boxes, shouldn't
it?  They use a blob of binary firmware as well.  Yet if we are to believe
Samsung, their box will crash (possibly even on non-protected content) if it
is not upgraded to comply with the broadcast flag detection requirement.  The
MDR-200 is unavailable because it is "back at the factory."  Are there any
boxes with FireWire out that _are_ expected to keep working?

|Are you suggesting there are timebombs in the current firmware,

I'm suggesting that there might be something that is sensitive to the
proposed flag or possibly to some *other* change that will be made to
the stream for both protected and unprotected content.

|surely 
|there's some way to test that theory ?

I don't see how.  As far as I can tell, no programming information is
available for the chipset's firmware.  For that matter, there isn't
much programming information of any kind available besides the drivers.

|Dan Lanciani wrote:
|> Doug Larrick <doug at ties.org> wrote:
|> 
|> |Dan Lanciani wrote:
|> |> Makes me wonder if they chose the format of the flag to cause problems with
|> |> pre-DRM implementations.  I hope there isn't anything in the big binary-only
|> |> firmware arrays in the pcHDTV drivers that will be similarly affected...
|> |
|> |The flag is a single descriptor in the PSIP data.  It really is just a 
|> |flag.  Easy to ignore.
|> 
|> But it might not be easy to ignore if the binary code embeded in the
|> drivers (binary for which we do not have the source) looks for it...
|> 
|> 				Dan Lanciani
|> 				ddl at danlan.*com