IMHO *the* issue with building a HTPC is how to get a decent video signal out of it. Video will almost always look better on an NTSC or HD television than a computer monitor. Computer monitors have a sharp response function that is tuned for single-pixel desktop graphics, not continuous video signals. This is why DVDs that look great on a TV often look crummy on a computer display.
Consumer graphics cards with "Video Out" are not acceptable because there is not a one-to-one mapping between VGA pixels and video samples. Nor is there any guaranteed synchronization to the video scan rate.
I consider a hardware video codec with a true *video* (digital, component or S-video) output essential for any PC to drive a television.
And IMHO multi-head single-board cards are a far better solution than multiple cards. There is no bus contention for bandwidth, the one card can take it all. And there are no complex synchronization issues as with multiple cards - it's comparatively trivial to split the framebuffer across more than one display. Less complexity means better support and fewer bugs. (I have never been happy with the hack-like state of multi-card graphics in Windows or XFree)
This opens up a lot of interesting DRM schemes... e.g. What if Photoshop refused to import images unless they were captured and signed on a "professional" camera that costs 5x more than a "consumer" camera with identical parts except for the private key? Or what if consumer video equipment refused to record video signed by "professional" keys? (DRM from the CCD onwards...)
This "cache-only" thing is a good idea. Modern Mac OSX programs handle metadata this way - if a resource fork is present in the file, they use it, otherwise they generate a new one based on the file contents. But there are exceptions. I was bitten because Final Cut Pro 4 does NOT like opening project files that are missing their resource fork. I store files on an NFS server and made a habit of deleting the "._foo" auxillary files that OSX spews all over the place to store resource forks on a UNIX filesystem. Final Cut did not like this...
I'm actually unsure about my earlier statement... Profiles would only save you part of the 8-bit computation - you still have to multiply the numbers *somewhere* - and you can always dither to minimize artifacts. (although it's surprising how few image-manipulation programs bother to dither... it can be done in about 4 lines of code for crying out loud...)
There is no perfect solution for dealing with matching primaries, because in the end three numbers aren't enough information to reconstruct the full spectrum of light. As soon as we get greater than 8 bits of depth, we'll have to start asking for more than 3 color components:)
Color profiles and gamma serve different purposes... Gamma is about mapping pixel values to luminance, color profiles are mainly about dealing with devices that use different primaries.
In the video/film world we worry about gamma but don't care very much about differing primaries (we just "color correct" stuff until it "looks right" on the display). Whereas print graphics people obsess about primaries while pretty much ignoring gamma (they manually "gamma correct" stuff until it "looks right").
It's probably because video/film graphics only has to deal with a few sets of primaries (NTSC, Rec. 709, film stocks) whereas print people have to worry about a zillion different devices (every scanner, printer, etc). Gamma is vital in video to avoiding quantization artifacts and making dark areas look right. But in print the worry is "if I print a color image and then scan it back in, will the scanned colors visually match those on the paper?"
Perhaps one motivation for "embedded" color profiles is avoiding the need to transform 8-bit pixel values and thus introduce quantization artifacts.
Not all of Apple's products are without manuals. The massive, well-printed documentation that comes with Final Cut Pro and DVD Studio Pro is extremely useful. The manuals are very well-written and go far beyond simply explaining all the menu items one by one.
"The government's view of the economy... If it moves, tax it. If it keeps moving, regulate it. And if it stops moving, subsidize it."
Re:Short Mission Duration (given the cost)
on
Spirit Rolls on Mars
·
· Score: 2, Informative
Right now Martian summer is slowly becoming Martian winter, and Mars is moving away from the sun (its orbital eccentricity is higher than earth's and has a major effect on Mars' climate).
So the solar cells will provide less power due to the lower sun angle and brightness, even without any dust accumulation.
Assuming no major mishaps, what will eventually kill the rover is lack of power to heat the electronics at night. Electrical components don't last very long unprotected from the wild temperature swings on Mars.
That said, NASA always builds tons of redundancy into its hardware, so I wouldn't be surprised if the rovers outlasted their design lifetimes...
I second the recommendation of a DV bridge. Make sure to get one with locked audio (e.g. ADVC-100). Most "TV in" cards have serious audio sync problems because they do not lock the sample rate of the audio to the incmoing video frame rate.
I assume the 1000 is a typo, the ADVC-1000 is a professional high-end product ($2000), the ADVC-100 is the consumer model ($200-$300).
Unfortunately that's not an acceptable solution for me... Most kinds of rendering and compositing require linear, spectral representations of light (i.e. RGB). I've been working on a system that converts floating-point linear RGB color directly to Y'CbCr, but this is *highly* unusual. Industry practice is still 8-bit RGB -> 8/10-bit Y'CbCr (with all inherent confusion about black levels, banding, etc).
I hope you're wrong, but I have a feeling you're right.
I would like to see Y'CbCr recognized for what it is: a lossy compression method. Nothing more, nothing less.
I am fine with Y'CbCr as a compressed transmission and storage format, but not as an interface (in the same sense that JPEG DCT coefficients are a storage/transmission format, not an interface). It just causes too many problems going to/from RGB (especially at 8 bits), and is limiting in the sense that nobody in the video world has an incentive to see beyond 4:2:2, since there's no popular RGB interface.
I would propose video systems where Y'CbCr is used for *compression*, but the *interface* would be RGB. Most studio video formats already use some kind of internal compression (e.g. DCT) but the SDI interface standard is uncompressed (albeit not RGB).
I would like to see an uncompressed RGB interface standard become popular. (I know dual-link RGB SDI exists, but hardly anyone uses it - I'm talking about DVI or even something based on FireWire).
I daily come up against annoying problems in Y'CbCr-RGB conversion. If only there were at least some agreement on how to do THAT. (and please people, go look up "dithering" sometime). And enforce a standard for field dominance. That would help me out a lot...
Admittedly, the film guys are behaving a little bit like spoiled brats in refusing to adopt HD formats because of 4:2:2 acquisition or insisting that 1920x1080 pixels doesn't capture all the information in a film frame. (I got the distinct impression from Sony reps that they are developing higher-resolution systems simply to humor arrogant film bigots:). On the other hand, what they get in the end may be really great...
The slow merging of HDTV and film technology is pushing to eliminate subsampling and Y'CbCr (YUV) color space entirely. George Lucas, after shooting Episode II in 4:2:2 Y'CbCr, insisted that Sony develop 4:4:4 RGB equipment for Episode III.
I *hope* this will continue to the point where Y'CbCr can be dropped entirely (there isn't much use for it aside from chroma subsampling), as well as interlacing. These things cause serious problems in computing... Every time you see stair-step artifacts, improper telecine, mis-matched black levels, banding in gradients, or black rectangles in screenshots of media players, you can thank interlacing and Y'CbCr color space.
(but they *are* quite effective as compression algorithms, and also clever hacks, in their time - how *else* are you going to send full-color motion video in 6MHz of radio bandwidth using 1950's technology?)
I created all of the animation in these pieces associated with NASA's MER mission. The best way to view them is the 9-minute launch-to-landing music video at:
I also made a bunch of new animation for a NOVA documentary, "Mars, Dead or Alive," which will be shown on PBS January 4-6 (the first MER landing is late night Jan. 3).
The trailers NASA made look neat. Wish they had used our 24p master rather than interlaced video sources though.
A big problem here is that none of the major DRM systems has a cheap, widely-available encoder. e.g. To make a CSS-scrambled DVD you have to go to a major replicator (and pay big $$$), you can't do it with iMovie.
I think a DRM system by Microsoft would actually be somewhat better than DRM by Hollywood, since Microsoft is more likely to offer an encoder to end users. (half of their rheotoric about Palladium is how it will help regular users "secure" their own documents...)
I also find it very annoying that you need to keep the original CD with you (and in good condition) in order to play the game. I thought the purpose of hard disks was to store data so you didn't need the game media every time you wanted to play:(
I actually needed to turn up the sensitivity much higher to get most spam... I have it at 4.0, and 1-2 per day still get through. Also I tweaked up the scores for many tests that had strangely low values (like HTML-only mail, or various suspicious header lines, which ship with scores in the 1-2 range; I tweaked those up to 3.5). I also look at each spam that gets past the filter, and turn up the scores so that it would get caught next time.
What really helped though was training the Bayesian filter on a new batch of 500 recent spam messages. Once I did this the hit rate went way up.
I like Spamassassin's approach of combining Bayesian filtering with rule-based message analysis. Most of the time Bayes will nail it, but when it doesn't, the other rules usually do.
This happened to me the other day. I got a new version of BitTorrent. New version of BitTorrent required new version of Python. New version of Python required new version of glibc. And about a zillion packages depend on a specific version of glibc. I gave up.
The biggest culprits I've found are glibc and libstdc++ (and libgcc_s.so with recent software). It's shameful that these fundamental libraries tend not to be backward- or forward-compatible. If glibc were as stable as say msvcrt.dll, we'd be in much better shape. As it is today, you CANNOT take any C++ program compiled (non-statically) on one distribution and have it work automatically on all other distributions. This is *embarrassing*, and one of the reasons many software vendors hesitate to support Linux. If stdc++ doesn't work, how can you expect libfoo to work?
It does not help that the maintainers of glibc and gcc don't seem to care about ABI compatibility much at all. These are the packages where it should be of *most* importance.
Book counterfeiters probably also have access to a scanner and good OCR software. Maybe a little more effort than tricking it out of Amazon's system, but not too much. (just pay some poor guy to scan and flip pages)
It will be good for Congresspeople to get lots of calls from irate grandmothers who can't record their kids' home videos:)
Personally I think studios and broadcasters would benefit TREMENDOUSLY if they adopted an iTunes-style model, i.e. for-pay or advertising-supported access to ANY show ANY time, on demand, with reasonable, limited DRM (isn't it great we can use iTunes as a basis for comparison now, rather than Napster?:). The technology to do this is here NOW. Unfortunately the US government is paying too close attention to the whining of the media industry, not realizing they are using draconian DRM as a substitute for sound business planning.
What I find most repellant about the "broadcast flag" is that nowhere does it codify fair-use. The flag is all about PREVENTING copying; it serves as a technological proxy for copyright law. But unlike a human, a technological system can't make judgments about whether you are within fair use. You can't tell the broadcast flag "I'm just time-shifting for my own viewing" or "it's to show my students." It just automatically assumes you are a criminal.
I fully expect the "broadcast flag" in all media will be set by default to the most restrictive setting (no recording at all?). Why wouldn't they do this? It would shut down all home recording of TV for any purpose (time-shifting, education, watching shows not carried by your local broadcaster, etc). I haven't seen the final rules, so perhaps the most restrictive setting will be less than "no recording at all." Maybe "record, but play back only once and delete thereafter?"
Mandatory copy-prevention laws are MUCH more dangerous now that we have the DMCA. I was never too concerned about Macrovision, since there are ways around it if you really want to record something, and it's within your legal rights. But there is no legal way around a digital system. (technically you *are* allowed to hack it *yourself*, but you're not allowed to distribute automatic hacking tools - and very, very few people have the knowledge to hack a DRM system on their own)... Outside DMCA jurisdiction this is not a big deal, but here in the US it will get harder and much more expensive to obtain "unrestricted" equipment
Or consumer-level recording equipment will add the broadcast flag automatically, preventing you from making copies of your own stuff. If this sounds like fantasy, it's not. I use a consumer MiniDV deck for dumping my CG animation to tape. Several times it has refused to record DV streams or dupe VHS tapes (of my own work) with some kind of "copying prevented" warning. I expect this kind of behavior to show up a lot more often if copy-prevention bits are mandated.
Plus it seems that mandatory copy-prevention is the best way to kill new recording media (R.I.P DAT for consumers, SDMI, "Secure" Digital, etc).
The replies may be right about this being a knee-jerk reaction by the MPAA. Perhaps they do not currently see the consequences for consumer recording, but I feel it acutely, and it's just too tempting to close the "final loophole" and shut off all consumer recording forever.
My hope is that Apple or even Microsoft will end-run around this whole mess by encouraging media distribution in a format not controlled by the mandate (Quicktime, WMV, etc). MS seems really eager to convert broadcasters and optical video discs to WMV; if that happens, anything goes. Of course MS will have its DRM system, but I'm actually a lot less scared of DRM by Apple or Microsoft than DRM by the MPAA or TV broadcasters.
The more I think about it the more I agree this is [i]exactly[/i] what the broadcast flag is about. It's not about stopping piracy*. It's about stopping low-budget Mac-wielding filmmakers from threatening Hollywood... Amazing consumer-level media tools do no good if they can't record anything.
*I love how the article positions the broadcast flag as a "magic bullet" against internet piracy. As if one bit is going to stop anyone from doing anything...
Slashdot Mirror
IMHO *the* issue with building a HTPC is how to get a decent video signal out of it. Video will almost always look better on an NTSC or HD television than a computer monitor. Computer monitors have a sharp response function that is tuned for single-pixel desktop graphics, not continuous video signals. This is why DVDs that look great on a TV often look crummy on a computer display.
Consumer graphics cards with "Video Out" are not acceptable because there is not a one-to-one mapping between VGA pixels and video samples. Nor is there any guaranteed synchronization to the video scan rate.
I consider a hardware video codec with a true *video* (digital, component or S-video) output essential for any PC to drive a television.
And IMHO multi-head single-board cards are a far better solution than multiple cards. There is no bus contention for bandwidth, the one card can take it all. And there are no complex synchronization issues as with multiple cards - it's comparatively trivial to split the framebuffer across more than one display. Less complexity means better support and fewer bugs. (I have never been happy with the hack-like state of multi-card graphics in Windows or XFree)
This opens up a lot of interesting DRM schemes... e.g. What if Photoshop refused to import images unless they were captured and signed on a "professional" camera that costs 5x more than a "consumer" camera with identical parts except for the private key? Or what if consumer video equipment refused to record video signed by "professional" keys? (DRM from the CCD onwards...)
This "cache-only" thing is a good idea. Modern Mac OSX programs handle metadata this way - if a resource fork is present in the file, they use it, otherwise they generate a new one based on the file contents. But there are exceptions. I was bitten because Final Cut Pro 4 does NOT like opening project files that are missing their resource fork. I store files on an NFS server and made a habit of deleting the "._foo" auxillary files that OSX spews all over the place to store resource forks on a UNIX filesystem. Final Cut did not like this...
I'm actually unsure about my earlier statement... Profiles would only save you part of the 8-bit computation - you still have to multiply the numbers *somewhere* - and you can always dither to minimize artifacts. (although it's surprising how few image-manipulation programs bother to dither... it can be done in about 4 lines of code for crying out loud...)
:)
There is no perfect solution for dealing with matching primaries, because in the end three numbers aren't enough information to reconstruct the full spectrum of light. As soon as we get greater than 8 bits of depth, we'll have to start asking for more than 3 color components
Color profiles and gamma serve different purposes... Gamma is about mapping pixel values to luminance, color profiles are mainly about dealing with devices that use different primaries.
In the video/film world we worry about gamma but don't care very much about differing primaries (we just "color correct" stuff until it "looks right" on the display). Whereas print graphics people obsess about primaries while pretty much ignoring gamma (they manually "gamma correct" stuff until it "looks right").
It's probably because video/film graphics only has to deal with a few sets of primaries (NTSC, Rec. 709, film stocks) whereas print people have to worry about a zillion different devices (every scanner, printer, etc). Gamma is vital in video to avoiding quantization artifacts and making dark areas look right. But in print the worry is "if I print a color image and then scan it back in, will the scanned colors visually match those on the paper?"
Perhaps one motivation for "embedded" color profiles is avoiding the need to transform 8-bit pixel values and thus introduce quantization artifacts.
Not all of Apple's products are without manuals. The massive, well-printed documentation that comes with Final Cut Pro and DVD Studio Pro is extremely useful. The manuals are very well-written and go far beyond simply explaining all the menu items one by one.
"The government's view of the economy... If it moves, tax it. If it keeps moving, regulate it. And if it stops moving, subsidize it."
Right now Martian summer is slowly becoming Martian winter, and Mars is moving away from the sun (its orbital eccentricity is higher than earth's and has a major effect on Mars' climate).
So the solar cells will provide less power due to the lower sun angle and brightness, even without any dust accumulation.
Assuming no major mishaps, what will eventually kill the rover is lack of power to heat the electronics at night. Electrical components don't last very long unprotected from the wild temperature swings on Mars.
That said, NASA always builds tons of redundancy into its hardware, so I wouldn't be surprised if the rovers outlasted their design lifetimes...
I second the recommendation of a DV bridge. Make sure to get one with locked audio (e.g. ADVC-100). Most "TV in" cards have serious audio sync problems because they do not lock the sample rate of the audio to the incmoing video frame rate.
I assume the 1000 is a typo, the ADVC-1000 is a professional high-end product ($2000), the ADVC-100 is the consumer model ($200-$300).
Unfortunately that's not an acceptable solution for me... Most kinds of rendering and compositing require linear, spectral representations of light (i.e. RGB). I've been working on a system that converts floating-point linear RGB color directly to Y'CbCr, but this is *highly* unusual. Industry practice is still 8-bit RGB -> 8/10-bit Y'CbCr (with all inherent confusion about black levels, banding, etc).
I hope you're wrong, but I have a feeling you're right.
:). On the other hand, what they get in the end may be really great...
I would like to see Y'CbCr recognized for what it is: a lossy compression method. Nothing more, nothing less.
I am fine with Y'CbCr as a compressed transmission and storage format, but not as an interface (in the same sense that JPEG DCT coefficients are a storage/transmission format, not an interface). It just causes too many problems going to/from RGB (especially at 8 bits), and is limiting in the sense that nobody in the video world has an incentive to see beyond 4:2:2, since there's no popular RGB interface.
I would propose video systems where Y'CbCr is used for *compression*, but the *interface* would be RGB. Most studio video formats already use some kind of internal compression (e.g. DCT) but the SDI interface standard is uncompressed (albeit not RGB).
I would like to see an uncompressed RGB interface standard become popular. (I know dual-link RGB SDI exists, but hardly anyone uses it - I'm talking about DVI or even something based on FireWire).
I daily come up against annoying problems in Y'CbCr-RGB conversion. If only there were at least some agreement on how to do THAT. (and please people, go look up "dithering" sometime). And enforce a standard for field dominance. That would help me out a lot...
Admittedly, the film guys are behaving a little bit like spoiled brats in refusing to adopt HD formats because of 4:2:2 acquisition or insisting that 1920x1080 pixels doesn't capture all the information in a film frame. (I got the distinct impression from Sony reps that they are developing higher-resolution systems simply to humor arrogant film bigots
The slow merging of HDTV and film technology is pushing to eliminate subsampling and Y'CbCr (YUV) color space entirely. George Lucas, after shooting Episode II in 4:2:2 Y'CbCr, insisted that Sony develop 4:4:4 RGB equipment for Episode III.
I *hope* this will continue to the point where Y'CbCr can be dropped entirely (there isn't much use for it aside from chroma subsampling), as well as interlacing. These things cause serious problems in computing... Every time you see stair-step artifacts, improper telecine, mis-matched black levels, banding in gradients, or black rectangles in screenshots of media players, you can thank interlacing and Y'CbCr color space.
(but they *are* quite effective as compression algorithms, and also clever hacks, in their time - how *else* are you going to send full-color motion video in 6MHz of radio bandwidth using 1950's technology?)
I created all of the animation in these pieces associated with NASA's MER mission.
t ml
The best way to view them is the 9-minute launch-to-landing music video at:
http://athena.cornell.edu/the_mission/rov_video.h
And downloads including a DVD-spec MPEG-2 stream at:
http://www.maasdigital.com/gallery.html
I also made a bunch of new animation for a NOVA documentary, "Mars, Dead or Alive," which will be shown on PBS January 4-6 (the first MER landing is late night Jan. 3).
The trailers NASA made look neat. Wish they had used our 24p master rather than interlaced video sources though.
A big problem here is that none of the major DRM systems has a cheap, widely-available encoder. e.g. To make a CSS-scrambled DVD you have to go to a major replicator (and pay big $$$), you can't do it with iMovie.
I think a DRM system by Microsoft would actually be somewhat better than DRM by Hollywood, since Microsoft is more likely to offer an encoder to end users. (half of their rheotoric about Palladium is how it will help regular users "secure" their own documents...)
I also find it very annoying that you need to keep the original CD with you (and in good condition) in order to play the game. I thought the purpose of hard disks was to store data so you didn't need the game media every time you wanted to play :(
I actually needed to turn up the sensitivity much higher to get most spam... I have it at 4.0, and 1-2 per day still get through. Also I tweaked up the scores for many tests that had strangely low values (like HTML-only mail, or various suspicious header lines, which ship with scores in the 1-2 range; I tweaked those up to 3.5). I also look at each spam that gets past the filter, and turn up the scores so that it would get caught next time.
What really helped though was training the Bayesian filter on a new batch of 500 recent spam messages. Once I did this the hit rate went way up.
I like Spamassassin's approach of combining Bayesian filtering with rule-based message analysis. Most of the time Bayes will nail it, but when it doesn't, the other rules usually do.
If J random web server loses power and drops off-line, that's not a network outage. All but the most mom-and-pop of ISPs have redundant power anyway.
This happened to me the other day. I got a new version of BitTorrent. New version of BitTorrent required new version of Python. New version of Python required new version of glibc. And about a zillion packages depend on a specific version of glibc. I gave up.
The biggest culprits I've found are glibc and libstdc++ (and libgcc_s.so with recent software). It's shameful that these fundamental libraries tend not to be backward- or forward-compatible. If glibc were as stable as say msvcrt.dll, we'd be in much better shape. As it is today, you CANNOT take any C++ program compiled (non-statically) on one distribution and have it work automatically on all other distributions. This is *embarrassing*, and one of the reasons many software vendors hesitate to support Linux. If stdc++ doesn't work, how can you expect libfoo to work?
It does not help that the maintainers of glibc and gcc don't seem to care about ABI compatibility much at all. These are the packages where it should be of *most* importance.
http://www.ifilm.com/filmdetail?ifilmid=115368
the main site: http://www.geocities.com/cobweb_films/
It's a bit lengthy but the humor is precious.
"Do you know who this is, Neo?"
"Mom?"
"Guess again Neo."
"... Mom?"
"Can you drive that thing?"
"Not yet... Operator! I need a program for an '82 Subaru Swift!"
Book counterfeiters probably also have access to a scanner and good OCR software. Maybe a little more effort than tricking it out of Amazon's system, but not too much. (just pay some poor guy to scan and flip pages)
It will be good for Congresspeople to get lots of calls from irate grandmothers who can't record their kids' home videos :)
:). The technology to do this is here NOW. Unfortunately the US government is paying too close attention to the whining of the media industry, not realizing they are using draconian DRM as a substitute for sound business planning.
Personally I think studios and broadcasters would benefit TREMENDOUSLY if they adopted an iTunes-style model, i.e. for-pay or advertising-supported access to ANY show ANY time, on demand, with reasonable, limited DRM (isn't it great we can use iTunes as a basis for comparison now, rather than Napster?
What I find most repellant about the "broadcast flag" is that nowhere does it codify fair-use. The flag is all about PREVENTING copying; it serves as a technological proxy for copyright law. But unlike a human, a technological system can't make judgments about whether you are within fair use. You can't tell the broadcast flag "I'm just time-shifting for my own viewing" or "it's to show my students." It just automatically assumes you are a criminal.
I fully expect the "broadcast flag" in all media will be set by default to the most restrictive setting (no recording at all?). Why wouldn't they do this? It would shut down all home recording of TV for any purpose (time-shifting, education, watching shows not carried by your local broadcaster, etc). I haven't seen the final rules, so perhaps the most restrictive setting will be less than "no recording at all." Maybe "record, but play back only once and delete thereafter?"
Mandatory copy-prevention laws are MUCH more dangerous now that we have the DMCA. I was never too concerned about Macrovision, since there are ways around it if you really want to record something, and it's within your legal rights. But there is no legal way around a digital system. (technically you *are* allowed to hack it *yourself*, but you're not allowed to distribute automatic hacking tools - and very, very few people have the knowledge to hack a DRM system on their own)... Outside DMCA jurisdiction this is not a big deal, but here in the US it will get harder and much more expensive to obtain "unrestricted" equipment
Or consumer-level recording equipment will add the broadcast flag automatically, preventing you from making copies of your own stuff. If this sounds like fantasy, it's not. I use a consumer MiniDV deck for dumping my CG animation to tape. Several times it has refused to record DV streams or dupe VHS tapes (of my own work) with some kind of "copying prevented" warning. I expect this kind of behavior to show up a lot more often if copy-prevention bits are mandated.
Plus it seems that mandatory copy-prevention is the best way to kill new recording media (R.I.P DAT for consumers, SDMI, "Secure" Digital, etc).
The replies may be right about this being a knee-jerk reaction by the MPAA. Perhaps they do not currently see the consequences for consumer recording, but I feel it acutely, and it's just too tempting to close the "final loophole" and shut off all consumer recording forever.
My hope is that Apple or even Microsoft will end-run around this whole mess by encouraging media distribution in a format not controlled by the mandate (Quicktime, WMV, etc). MS seems really eager to convert broadcasters and optical video discs to WMV; if that happens, anything goes. Of course MS will have its DRM system, but I'm actually a lot less scared of DRM by Apple or Microsoft than DRM by the MPAA or TV broadcasters.
and before anyone else points out, yes I was tired and slipped into BBcode...
The more I think about it the more I agree this is [i]exactly[/i] what the broadcast flag is about. It's not about stopping piracy*. It's about stopping low-budget Mac-wielding filmmakers from threatening Hollywood... Amazing consumer-level media tools do no good if they can't record anything. *I love how the article positions the broadcast flag as a "magic bullet" against internet piracy. As if one bit is going to stop anyone from doing anything...