Well,/. is not exactly a reliable 0-dayz news source either.
Many of the things I see here I have seen elsewhere days or even weeks ago. Some WAG articles on theinquirer and other sites are often surprisingly accurate and months ahead of official party lines.
How long do MP3 players last on a single charge? There are models that last over 50h on a single AA battery but alkaline AA batteries are 1.5Vx2800mAh VS 3.6Vx600mAh for modern phones, often less for super-small phones - my sister's phone has a 3.6Vx450mAh battery. So, a combined cell+MP3 device would have well under 20h of playback time if any calls are answered or placed - also keep in mind that effective battery capacities have to be derated according to current. Forget or be otherwise unable to recharge after any extended playback period and your battery may go dead on your next call.
Simply do not buy into proprietary DRMed format and stick with plain MP3/OGG/AC3/etc. players.
This would pretty much restrict people to smaller online stores, P2P downloads and CD-ripping but at least these formats are freely transcodable and transportable.
The PS3 might already be close to 30GB/s but it does not have the ~1GB RAM the decoding would require... 2x256MB for the front/back buffers tiled as 16x9 480x480x64bits, 256MB for intermediate images and processing buffers and 256MB to buffer the input stream. I forgot to take into consideration the fact that the buffers would have to be half-precision: if all intermediate results were stored in some 8bpp format, the final output would be horrible. This roughly doubles my previous bandwidth estimate to 70-80GB/s.
So, simply connecting the RAM and meeting the bandwidth requirements would require going distributed. Decoding the video would require roughly three 1+8 cells so, a 4x(1+8) setup where each chip would have 256MB of ~20GB/s RAM and ~10GB/s interconnects (HT?) to two other cells and the IO hub should work nicely. From this point, the remaining major challenges would be load-balancing and making sure the system can pull through worst case scenarios where the motion is concentrated on one cell's tiles/RAM. In the worst case, tiles can be shrunk and shuffled until the distribution evens out again and the extra cell should easily offset any extra overhead.
The even bigger challenge lies at the other end of this tunnel: capturing and encoding the source video. The raw video at 10bpp is ~3.5GB/s. Trying to store this as-is would require something like an array of 32 10x200GB RAID6 arrays to provide 51TB at 5.1GB/s, plenty fast but at 25TB for 2h of shooting, it would give litteral new meaning to the phrase "deleted scenes". Of course, the same overlapped tiling and quad-cell architecture should be able to produce lossless real-time 10X compression and save the day here as well. The huge array would still be necessary to sustain multiple cameras, feed the offline transcoders and store their outputs, serve 70Mbps QHD resolution review/planning streams and 700Mbps UHD screening streams, along with the low-compression streams during final editing and mastering.
The PS3 Cell has seven DSP cores tuned to do the sort of number-crunching necessary for decoding and rendering. A Cell DSP can work on 8 half-precision floats per clock while x86(-64) can only work with 4 single-precision per clock at best since current x86 CPUs only have one MAC (multiply-accumulate) block in their FPUs. So, a single 1+8 Cell can churn out 16X as many half-precision floats as a x86 CPU can churn out its lowest (overkill) precision. A 8xOpteron system would be less than half-way to matching a single cell's DSP power.
The 3GB/s RAM bandwidth was only the output buffer's write bandwidth assuming (an impossible) single-pass decoding. You also needs another 3GB/s to be passed on to the projector at the same minimum rate so, there goes another 3GB/s. The DSPs can do some processing re-ordering to reduce RAM reads and writes but chances are that the processing will need an average of at least two passes (read+write) so that is another 12GB/s + another 6GB/s for frames where many pixels hit three passes as a safety margin. Add RAM latency and idle cycles, the target flies to 30GB/s and beyond. With DDR2-533, this would mean going with octuple channels.
As for moving the data, yes, once it is transcoded to sub-DVD size it becomes trivial. Getting and transcoding the original 250-500GB UHD stream would be a less trivial - the download at 10Mbps still takes most of a week assuming 500GB sources are somehow made available online... breaking in a theater or having a clerk do the copy or steal an array would be possible if the security is somewhat weak though. Since PCs lack the Cell's DSP power, transcoding on PCs would take days mostly because of the UHD decoding and down-sampling using filters to preserve some fine details instead of point-sampling.
But you're right for distribution, it ultimately does not really matter. No matter how non-practical the initial re-encoding may be and no matter how much the studios push DRM to prevent us from copying stuff, we still only need one person with the know-how and motivation to successfully pull it off.
Decoding can be distributed by tiling... but this could be quite sub-optimal if all the changes are concentrated in a distinc region subset. This can be reduced by splitting the job in more regions but that would increase the amount of overlap across regions (to avoid tearing across regions) and also increase the dispatcher's workload. My WAG is that the distributed single stream decoder would require ~25% more processing power than the 16xHD approach. While packing this much processing power in a single chip might be diffucult, I think I would be more concerned about giving it enough RAM bandwidth to do its job given that the decoded raw video alone is already over 3GB/s - this easily beats the difficulty of delivering even 1Gbps to the beast.
Wether the movies are distributed by network or by disks, people might still be able to swap them around, preferably from an unencrypted copy stored on the primary server or local arrays. But even after getting this hypothetically unencrypted file, transcoding it on commodity hardware to a more usable format would take quite a few cpu-days... but after this step, you're back at DVD resolutions and quality, defeating much of the point of getting the UHD video source.
As for distribution, I am WAG-ing many ISPs would gladly trade (or substantially discount) a 100Mbps link for banners in movie theaters' halls and/or ad clips.
400Mbps seems like a reasonable worst-case scenario but I would expect full-frame single-stream video to go a fair bit lower given that HD has 6X SD's resolution but uses less than 3X as much bandwidth. Even 300Mbps total would probably still be conservative.
400Mbps = 50MB/s, a three disk RAID0 array can handle that even if each drive bottoms out at 20MB/s. With a five drive RAID5 array, the array would bottom out around 80MB/s. Given the cost of the projection and sound system equipment (over $200k), putting a 1GB buffer (a 15 second safety margin for less than $75) in the decoding equipment to smooth out any hiccups in the storage/network system would be a sensible thing to do.
For fragmentation, most movie theaters usually show only 2-3 features in any given room at any given time. Defragging could be done by simply wiping out the drives and doing an automated multicast overnight re-copying from backups/master every time the screen's lineup is changed. If each screen has its own storage, the access pattern will be 99.99% linear from here. For distribution, a 100Mbps fiber link could take care of that in about 12h per movie, less than the time it takes to duplicate, ship and shuffle reels (or 10+ Blu-Ray disks) and you only need one master image for however many screens the theater may have.
Another problem when you compare a 16 HDD setup to a RAID6 (active spare) is that you need 10 extra drives. With a $500 hardware RAID6 controller and $150 HDDs VS 16x $100 HDDs, the RAID6 solution is still $200 cheaper and has double-fault tolerance. Whith the individual HDD setup, you have zero tolerance with nearly three times as many drives (and power) until you at least double it all up and make the RAID6 solution at least $1800 less expensive. Sure, the RAID is a potential single-point failure... but who wants to watch a movie with 1/16 of the screen missing anyway?
UDH is 16X the resolution but if encoded as one single stream, the extra redundancy would make it possible to encode an UHD stream using less than 10X HD's bandwidth and still achieve better results. The 16X increase in pixel count combined with more motion compensation and processing inefficiencies would quite possibly lead to a more than 20X increase in required processing power.
1Gbps is not so bad for movie theaters... that's only 125MB/s, the realm of mid-range five disk RAID5 arrays or entry-level RAID0. If each screen has its own RAID5 array, this would work fairly well. Also, 1Gbps is pretty high so I am guessing actual deployments will have lower bitrates, somewhere in the 400-600Mbps range, comfortably within GbE and RAID5 realms. Since SD is 10Mbps and UHD has ~50X SD's resolution, 500Mbps seems like a perfectly reasonable rate target.
$100/sqft is for consumer-grade stuff which is typically under 15% efficient. For the more efficient aerospace-grade stuff which is at least 25% efficient (IIRC, 27% was the minimum for qualification 3-4 years ago), you will be closer to $1000/sqft.
More efficient and less expensive cells at the high-end will not translate into cheaper panels for consumer-level stuff because the pricing gap between the two grades will remain substantial for a long time to come... unless this DARPA funding leads to a major cost-cutting and efficiency breakthrough.
UHD is only ~100X the resolution of SD so 1Gbps would be the most they might require if they used MPEG2. But the higher the resolution, the easier it usually is to find redundancy in images and sequences so 500Mbps or less would be fairly realistic even with MPEG2. H264 might be able to reduce this to less than 100Mbps but the computing power necessary to encode and decode the video in realtime would be somewhat insane. Not having the encoding and decoding processing power necessary to handle compression is most likely the reason why NHK did its demos with a raw digital video stream.
If the OLED/LEP people from 2004 were right, 2006 should bring us the first-gen desktop/laptop OLED displays... and if their projections on scalability and low price turn out to be right, we might get affordable 50" quarter-UHD/quadruple-HD (3840x2160) displays early in the next decade. Gamers may have to give up on 16xAA for a while to run this at its native resolution.
Since the OLED/LEP people managed to fix blue's short lifespan early this year, maybe they will soon be ready to start making larger displays for stuff besides battery-operated semi-disposable devices, perhaps just in time for me to replace my twitching CRT.
Although I have never owned a GPS locator, I have seen people have a hard time getting satellites even while standing in the middle of nowhere, I am betting GPS would be completely useless in a city. Sure, GPS' precision is limited... but even with a land line I may be placing calls from 100+ meters away using my long-range cordless phone.
I am not aware that precision localization was required by law... it is neither economically nor technically (and even legally) feasible for cellular operators to guarantee accuracy. All they can do is a reasonable effort using differential timings from multiple towers (at least three) that are in range but major cities are full of null-zones and other trouble spots (particularly around/inside sky-scrapers) that can easily throw off these computations by tens of meters.
This stuff was on Discovery Channel months ago... and NHK's plans are to use it for movie theaters. Availability for home system was not discussed and it will certainly take a while, if it ever does get there. The DC overview of the UHD system did not say much about the audio system that went with it though. (Nor did it go into any sort of details about how the system was setup for the demonstrations.)
I do not necessarily know/remember the address of the place I went to... I only remember the turns to take to get there or simply followed someone there and did not note the address or forgot it. I do not own a GPS phone. I do not own a camera phone.
In a building, there may not be a nearest open (pay-)phone. Yes, GPS usually works in forest but (as you presumably implied) pretty much nothing else does. Yes, baby Bells & co. do rake it in, that is why some of them are plotting to charge fees to third-party online service providers to recover their lost LD income.
Land lines go through the POTS. The costs of establishing and maintaining a dedicated virtual circuit through the POTS scale with the number of traffic exchanges and length fiber/copper the call goes through. With POTS, you are guaranteed a steady audio stream under all but the worst conditions thanks to the static virtual circuit (reserved bandwidth) established when the call is initiated. With VoIP, any change in IP routing from source to destination can cause packet loss and out-of-order reception that will cause skips or delays in the audio streams.
VoIP is fire&forget, the network operator does not have to make any delivery guarantees. POTS calls however requires that a whole virtual circuit (64kbps each way) be reserved for the duration of the call. On most fibers, telephony traffic has absolute priority over IP and POTS pay for that privilege. This is a large part of why LD over POTS is much more expensive. Meeting POTS' zero-tolerance requirements in data delivery is much more expensive than meeting VoIP's "whenever".
The best compiler currently available for AMD's x86 and x86-64 is ICC... you only need to remove code path discrimination that will run optimized code/libraries only on Intel CPUs.
The sooner they get their dumb laws through, the sooner they will make their market implode. The faster gizmo companies are forced to comply with the *AA's rules, the sharper the blow on Joe Public will be. If we fight each and every of the *AA's dumb laws, we give them more time to plot their next move and contingency plan. The more gradual these moves due to opposition, the more likely the restrictions are of going unseen by Joe Public.
Any sudden move that disrupts Joe Public's routine will directly hit the studios' bottom lines in the near future. Any attempt at cushioning the blows through oppotition will turn disruptive changes that could shake the industry into progressive changes that may be acceptable for a larger percentage or possibly a large majority of the public.
We need disruptive changes to make Joe Public pick up arms against the entertainment industry and this is not going to happen if a minority successfully/partially/incrementally delays the *AAs's plans. The only thing that can cause the greedy bastards to wake up is the menace of a total market collapse by letting them alienate their customer base and the fastest way to get there is to let them lock us in/out, causing Joe Public to revolt due to the sudden disappearance of interoperability accompanied by generally unacceptable restrictions imposed by DRM.
The average person does not react to non-disruptive changes - "I do not do (or think I am doing) anything illegal therefore this stuff should not affect me". Let the studios blanket us with incompatible or otherwise non-interoperable DRM and disrupt people's habits, things should become much livelier when protests scale up to a few milion people. Only then will some of those overpaid execs realize that assaulting customers with DRM ultimately is the greater evil.
It may not be the path of least inconvenience but it does look like the only definitive way out. Until we let them get what they want and burn themselves with it, they will relentlessly pursue it. The sooner this happens, the sooner they will STFU and (maybe) give up.
Actually, how many bits you can cram in 1Hz of bandwidth depends on the SNR.
From Shannon: bps = BW * log2(1 + S / N)
So, with a 30dB SNR you get BW * log2(1+1000) = you could almost encode 10bits of data per Hz of bandwidth... a little under 10Mbps per 1MHz.
Since this modulation has smaller sidebands, more energy gets packed in a narrower band, enhancing the signal's strength while reducing the amount of noise picked up. It makes sense and I imagined something like this years ago. It looks basically like a single-cycle version of FSK or PSK but I think these should not look quite as clean as they did on their plots. (Well, they did stop at 100kHz resolution.)
As far as the signal generation goes, I am guessing they used an FPGA to drive an ADC and DAC for their prototypes and their 50mW is only the DAC's power output, not the entire receiver/transmitter power. They insist a lot on the signal's power but they say nothing about the system used to generate, transmit, receive and decode the signal.
There is a simple fix for that: use the phone's built-in GPS receiver.
No consumer-level data network (WiFi, WiMax, etc.) is aware of its location. Since VoIP goes through data networks which may be re-routed through other networks (someone routing calls using SSL to some other machine), it is impossible to determine the exact location based on the traffic's apparent point of origin.
100% 911-compliant VoIP is unlikely to ever happen because the 'line' is not tied to any fixed infrastructure. Cell phones have the towers, cable/dsl/phone have the coax/phone cable but VoIP is not tied to any particular endpoint/network/etc. anywhere on the planet. Even if a GPS receiver is built into the VoIP phones, these still depend on being able to detect the satellites and will fail to provide a location if there are a few reinforced concrete buildings around the area. Even if the GPS is cell-assisted, even cell phones stop working inside larger reinforced concrete buildings and there are dead zones all around towns too.
VoIP is not for critical calls. AFAIK, it was never intended to be and never will be. For VoIP to work, you have to trust that: 1) Your WiFi handset will work 2) Your WiFi router will work 3) Your ADSL/Cable/whatever modem will work 4) Your ISP link will work 5) Your VoIP company's servers will work 6) etc.
VoIP has more than double the number of middle-men compared to land lines and cell phones. Every link is a potential point of failure and any failure is very likely to lead to a dropped call, assuming the failure did not prevent you from placing the call in the first place. Last thing you want to have to do when you need to make an urgent call is troubleshooting your network.
The entertainment industry is pushing these projects to protect the perceived faults in their business models and future business opportunities.
By fighting their projects, we risk successfully saving them from themselves without them realizing how close they came from falling off their own cliff. If that happened, they would most likely become even more arrogant than they already are. Letting them have their dumb laws and alienate their customers to the point of causing a market implosion will forcibly hammer some much needed sense into the entertainment airheads.
Letting them do as they want may not be pretty but trying to prevent it will only make things worse for a longer time by delaying the inevitable. They will keep acting like spoilt kids until they get clubbed by reality. The sooner they get clubbed, the sooner sanity may be restored.
Let them waste their money and resources for futile fixes for problems that do not exist. Let them alienate their customer base by creating unnecessary complexities and complications. Help them commit technical suicide so we can start with a clean slate as soon as possible.
With a low-cost FPGAs, it would be absolutely possible to implement encrypted storage in the form of an ATA-to-ATA bridge.
I'm sure forensic teams would have a blast trying to decript an AES512 volume... and to make the drive imaging more difficult, the encryption could be 'seeded' using the drive's firmware, model#, serial# and anything else that may be relatively unique, including a timing challenge to verify that the bridge is really connected directly to a drive and not to some other bridge.
Use a removable external firmware chip for the FPGAs and once the police unplugs the computer, they indirectly destroy the only firmware copy they had and leave their forensic team with no clue about the actual data scrambling algorithm.
Sounds like an interesting project for my Master's.
Then you get a ~1h break while the drive is being restored from the original's image... or nearly no break at all if they expected this and pre-imaged the drive a few times.
You are going to need a fairly large and sturdy suitcase to fit the magnetron and its PSU... a microwave oven transformer weights about 1kg, the UPS that feeds it is another ~1kg (without battery and casing) and the batteries are another ~5kg. (Though you could cut nearly 2kg by building your own 12V or 24V to 2.5kV/1kW step-up converter.)
The simplest thing would be a spark gap housed in a wave-guide... but this would be really loud when driven with the sort of energy levels necessary to generate disruptive and potentially destructive amounts of RFI.
I'm fine with companies tracking my personal info if UK-style laws are adopted. IIRC, some of the more interesting clauses went something like this: 1) companies shall not use nor retain information whose origins is not documented 2) companies must make all the info they have on an individual including sources at the individual's request 3) individuals may have companies delete records unless the company can justify keeping the records of terminated accounts
This way, companies would at least have to think at least twice before collecting, using and distributing data.
I just happened to get a job interview for a DSL company this week... the job is primarily about testing DSLAM and DSL modem firmware/hardware combinations on simulated and field test loops up to 5000' - validation before deployment for a major Canadian ISP. If I get that job, I should have a pretty good idea about how good all things DSL are going to be for the foreseeable future.
Slashdot Mirror
Oops.
Hold on a second while I hack together some sort of multi-channel 5.1 headphone.
Well, /. is not exactly a reliable 0-dayz news source either.
Many of the things I see here I have seen elsewhere days or even weeks ago. Some WAG articles on theinquirer and other sites are often surprisingly accurate and months ahead of official party lines.
How long do MP3 players last on a single charge? There are models that last over 50h on a single AA battery but alkaline AA batteries are 1.5Vx2800mAh VS 3.6Vx600mAh for modern phones, often less for super-small phones - my sister's phone has a 3.6Vx450mAh battery. So, a combined cell+MP3 device would have well under 20h of playback time if any calls are answered or placed - also keep in mind that effective battery capacities have to be derated according to current. Forget or be otherwise unable to recharge after any extended playback period and your battery may go dead on your next call.
Simply do not buy into proprietary DRMed format and stick with plain MP3/OGG/AC3/etc. players.
This would pretty much restrict people to smaller online stores, P2P downloads and CD-ripping but at least these formats are freely transcodable and transportable.
The PS3 might already be close to 30GB/s but it does not have the ~1GB RAM the decoding would require... 2x256MB for the front/back buffers tiled as 16x9 480x480x64bits, 256MB for intermediate images and processing buffers and 256MB to buffer the input stream. I forgot to take into consideration the fact that the buffers would have to be half-precision: if all intermediate results were stored in some 8bpp format, the final output would be horrible. This roughly doubles my previous bandwidth estimate to 70-80GB/s.
So, simply connecting the RAM and meeting the bandwidth requirements would require going distributed. Decoding the video would require roughly three 1+8 cells so, a 4x(1+8) setup where each chip would have 256MB of ~20GB/s RAM and ~10GB/s interconnects (HT?) to two other cells and the IO hub should work nicely. From this point, the remaining major challenges would be load-balancing and making sure the system can pull through worst case scenarios where the motion is concentrated on one cell's tiles/RAM. In the worst case, tiles can be shrunk and shuffled until the distribution evens out again and the extra cell should easily offset any extra overhead.
The even bigger challenge lies at the other end of this tunnel: capturing and encoding the source video. The raw video at 10bpp is ~3.5GB/s. Trying to store this as-is would require something like an array of 32 10x200GB RAID6 arrays to provide 51TB at 5.1GB/s, plenty fast but at 25TB for 2h of shooting, it would give litteral new meaning to the phrase "deleted scenes". Of course, the same overlapped tiling and quad-cell architecture should be able to produce lossless real-time 10X compression and save the day here as well. The huge array would still be necessary to sustain multiple cameras, feed the offline transcoders and store their outputs, serve 70Mbps QHD resolution review/planning streams and 700Mbps UHD screening streams, along with the low-compression streams during final editing and mastering.
Ain't large-scale systems wonderful?
The PS3 Cell has seven DSP cores tuned to do the sort of number-crunching necessary for decoding and rendering. A Cell DSP can work on 8 half-precision floats per clock while x86(-64) can only work with 4 single-precision per clock at best since current x86 CPUs only have one MAC (multiply-accumulate) block in their FPUs. So, a single 1+8 Cell can churn out 16X as many half-precision floats as a x86 CPU can churn out its lowest (overkill) precision. A 8xOpteron system would be less than half-way to matching a single cell's DSP power.
The 3GB/s RAM bandwidth was only the output buffer's write bandwidth assuming (an impossible) single-pass decoding. You also needs another 3GB/s to be passed on to the projector at the same minimum rate so, there goes another 3GB/s. The DSPs can do some processing re-ordering to reduce RAM reads and writes but chances are that the processing will need an average of at least two passes (read+write) so that is another 12GB/s + another 6GB/s for frames where many pixels hit three passes as a safety margin. Add RAM latency and idle cycles, the target flies to 30GB/s and beyond. With DDR2-533, this would mean going with octuple channels.
As for moving the data, yes, once it is transcoded to sub-DVD size it becomes trivial. Getting and transcoding the original 250-500GB UHD stream would be a less trivial - the download at 10Mbps still takes most of a week assuming 500GB sources are somehow made available online... breaking in a theater or having a clerk do the copy or steal an array would be possible if the security is somewhat weak though. Since PCs lack the Cell's DSP power, transcoding on PCs would take days mostly because of the UHD decoding and down-sampling using filters to preserve some fine details instead of point-sampling.
But you're right for distribution, it ultimately does not really matter. No matter how non-practical the initial re-encoding may be and no matter how much the studios push DRM to prevent us from copying stuff, we still only need one person with the know-how and motivation to successfully pull it off.
Decoding can be distributed by tiling... but this could be quite sub-optimal if all the changes are concentrated in a distinc region subset. This can be reduced by splitting the job in more regions but that would increase the amount of overlap across regions (to avoid tearing across regions) and also increase the dispatcher's workload. My WAG is that the distributed single stream decoder would require ~25% more processing power than the 16xHD approach. While packing this much processing power in a single chip might be diffucult, I think I would be more concerned about giving it enough RAM bandwidth to do its job given that the decoded raw video alone is already over 3GB/s - this easily beats the difficulty of delivering even 1Gbps to the beast.
Wether the movies are distributed by network or by disks, people might still be able to swap them around, preferably from an unencrypted copy stored on the primary server or local arrays. But even after getting this hypothetically unencrypted file, transcoding it on commodity hardware to a more usable format would take quite a few cpu-days... but after this step, you're back at DVD resolutions and quality, defeating much of the point of getting the UHD video source.
As for distribution, I am WAG-ing many ISPs would gladly trade (or substantially discount) a 100Mbps link for banners in movie theaters' halls and/or ad clips.
400Mbps seems like a reasonable worst-case scenario but I would expect full-frame single-stream video to go a fair bit lower given that HD has 6X SD's resolution but uses less than 3X as much bandwidth. Even 300Mbps total would probably still be conservative.
400Mbps = 50MB/s, a three disk RAID0 array can handle that even if each drive bottoms out at 20MB/s. With a five drive RAID5 array, the array would bottom out around 80MB/s. Given the cost of the projection and sound system equipment (over $200k), putting a 1GB buffer (a 15 second safety margin for less than $75) in the decoding equipment to smooth out any hiccups in the storage/network system would be a sensible thing to do.
For fragmentation, most movie theaters usually show only 2-3 features in any given room at any given time. Defragging could be done by simply wiping out the drives and doing an automated multicast overnight re-copying from backups/master every time the screen's lineup is changed. If each screen has its own storage, the access pattern will be 99.99% linear from here. For distribution, a 100Mbps fiber link could take care of that in about 12h per movie, less than the time it takes to duplicate, ship and shuffle reels (or 10+ Blu-Ray disks) and you only need one master image for however many screens the theater may have.
Another problem when you compare a 16 HDD setup to a RAID6 (active spare) is that you need 10 extra drives. With a $500 hardware RAID6 controller and $150 HDDs VS 16x $100 HDDs, the RAID6 solution is still $200 cheaper and has double-fault tolerance. Whith the individual HDD setup, you have zero tolerance with nearly three times as many drives (and power) until you at least double it all up and make the RAID6 solution at least $1800 less expensive. Sure, the RAID is a potential single-point failure... but who wants to watch a movie with 1/16 of the screen missing anyway?
UDH is 16X the resolution but if encoded as one single stream, the extra redundancy would make it possible to encode an UHD stream using less than 10X HD's bandwidth and still achieve better results. The 16X increase in pixel count combined with more motion compensation and processing inefficiencies would quite possibly lead to a more than 20X increase in required processing power.
1Gbps is not so bad for movie theaters... that's only 125MB/s, the realm of mid-range five disk RAID5 arrays or entry-level RAID0. If each screen has its own RAID5 array, this would work fairly well. Also, 1Gbps is pretty high so I am guessing actual deployments will have lower bitrates, somewhere in the 400-600Mbps range, comfortably within GbE and RAID5 realms. Since SD is 10Mbps and UHD has ~50X SD's resolution, 500Mbps seems like a perfectly reasonable rate target.
No need for a fancy Blu-Ray/HDDVD/whatever array.
$100/sqft is for consumer-grade stuff which is typically under 15% efficient. For the more efficient aerospace-grade stuff which is at least 25% efficient (IIRC, 27% was the minimum for qualification 3-4 years ago), you will be closer to $1000/sqft.
More efficient and less expensive cells at the high-end will not translate into cheaper panels for consumer-level stuff because the pricing gap between the two grades will remain substantial for a long time to come... unless this DARPA funding leads to a major cost-cutting and efficiency breakthrough.
The article linked here was 24Gbps for RAW video.
UHD is only ~100X the resolution of SD so 1Gbps would be the most they might require if they used MPEG2. But the higher the resolution, the easier it usually is to find redundancy in images and sequences so 500Mbps or less would be fairly realistic even with MPEG2. H264 might be able to reduce this to less than 100Mbps but the computing power necessary to encode and decode the video in realtime would be somewhat insane. Not having the encoding and decoding processing power necessary to handle compression is most likely the reason why NHK did its demos with a raw digital video stream.
If the OLED/LEP people from 2004 were right, 2006 should bring us the first-gen desktop/laptop OLED displays... and if their projections on scalability and low price turn out to be right, we might get affordable 50" quarter-UHD/quadruple-HD (3840x2160) displays early in the next decade. Gamers may have to give up on 16xAA for a while to run this at its native resolution.
Since the OLED/LEP people managed to fix blue's short lifespan early this year, maybe they will soon be ready to start making larger displays for stuff besides battery-operated semi-disposable devices, perhaps just in time for me to replace my twitching CRT.
Although I have never owned a GPS locator, I have seen people have a hard time getting satellites even while standing in the middle of nowhere, I am betting GPS would be completely useless in a city. Sure, GPS' precision is limited... but even with a land line I may be placing calls from 100+ meters away using my long-range cordless phone.
I am not aware that precision localization was required by law... it is neither economically nor technically (and even legally) feasible for cellular operators to guarantee accuracy. All they can do is a reasonable effort using differential timings from multiple towers (at least three) that are in range but major cities are full of null-zones and other trouble spots (particularly around/inside sky-scrapers) that can easily throw off these computations by tens of meters.
This stuff was on Discovery Channel months ago... and NHK's plans are to use it for movie theaters. Availability for home system was not discussed and it will certainly take a while, if it ever does get there. The DC overview of the UHD system did not say much about the audio system that went with it though. (Nor did it go into any sort of details about how the system was setup for the demonstrations.)
I do not necessarily know/remember the address of the place I went to... I only remember the turns to take to get there or simply followed someone there and did not note the address or forgot it.
I do not own a GPS phone.
I do not own a camera phone.
In a building, there may not be a nearest open (pay-)phone.
Yes, GPS usually works in forest but (as you presumably implied) pretty much nothing else does.
Yes, baby Bells & co. do rake it in, that is why some of them are plotting to charge fees to third-party online service providers to recover their lost LD income.
Land lines go through the POTS. The costs of establishing and maintaining a dedicated virtual circuit through the POTS scale with the number of traffic exchanges and length fiber/copper the call goes through. With POTS, you are guaranteed a steady audio stream under all but the worst conditions thanks to the static virtual circuit (reserved bandwidth) established when the call is initiated. With VoIP, any change in IP routing from source to destination can cause packet loss and out-of-order reception that will cause skips or delays in the audio streams.
VoIP is fire&forget, the network operator does not have to make any delivery guarantees. POTS calls however requires that a whole virtual circuit (64kbps each way) be reserved for the duration of the call. On most fibers, telephony traffic has absolute priority over IP and POTS pay for that privilege. This is a large part of why LD over POTS is much more expensive. Meeting POTS' zero-tolerance requirements in data delivery is much more expensive than meeting VoIP's "whenever".
The best compiler currently available for AMD's x86 and x86-64 is ICC... you only need to remove code path discrimination that will run optimized code/libraries only on Intel CPUs.
I did not miss it.
The sooner they get their dumb laws through, the sooner they will make their market implode. The faster gizmo companies are forced to comply with the *AA's rules, the sharper the blow on Joe Public will be. If we fight each and every of the *AA's dumb laws, we give them more time to plot their next move and contingency plan. The more gradual these moves due to opposition, the more likely the restrictions are of going unseen by Joe Public.
Any sudden move that disrupts Joe Public's routine will directly hit the studios' bottom lines in the near future. Any attempt at cushioning the blows through oppotition will turn disruptive changes that could shake the industry into progressive changes that may be acceptable for a larger percentage or possibly a large majority of the public.
We need disruptive changes to make Joe Public pick up arms against the entertainment industry and this is not going to happen if a minority successfully/partially/incrementally delays the *AAs's plans. The only thing that can cause the greedy bastards to wake up is the menace of a total market collapse by letting them alienate their customer base and the fastest way to get there is to let them lock us in/out, causing Joe Public to revolt due to the sudden disappearance of interoperability accompanied by generally unacceptable restrictions imposed by DRM.
The average person does not react to non-disruptive changes - "I do not do (or think I am doing) anything illegal therefore this stuff should not affect me". Let the studios blanket us with incompatible or otherwise non-interoperable DRM and disrupt people's habits, things should become much livelier when protests scale up to a few milion people. Only then will some of those overpaid execs realize that assaulting customers with DRM ultimately is the greater evil.
It may not be the path of least inconvenience but it does look like the only definitive way out. Until we let them get what they want and burn themselves with it, they will relentlessly pursue it. The sooner this happens, the sooner they will STFU and (maybe) give up.
Actually, how many bits you can cram in 1Hz of bandwidth depends on the SNR.
From Shannon: bps = BW * log2(1 + S / N)
So, with a 30dB SNR you get BW * log2(1+1000) = you could almost encode 10bits of data per Hz of bandwidth... a little under 10Mbps per 1MHz.
Since this modulation has smaller sidebands, more energy gets packed in a narrower band, enhancing the signal's strength while reducing the amount of noise picked up. It makes sense and I imagined something like this years ago. It looks basically like a single-cycle version of FSK or PSK but I think these should not look quite as clean as they did on their plots. (Well, they did stop at 100kHz resolution.)
As far as the signal generation goes, I am guessing they used an FPGA to drive an ADC and DAC for their prototypes and their 50mW is only the DAC's power output, not the entire receiver/transmitter power. They insist a lot on the signal's power but they say nothing about the system used to generate, transmit, receive and decode the signal.
There is a simple fix for that: use the phone's built-in GPS receiver.
No consumer-level data network (WiFi, WiMax, etc.) is aware of its location. Since VoIP goes through data networks which may be re-routed through other networks (someone routing calls using SSL to some other machine), it is impossible to determine the exact location based on the traffic's apparent point of origin.
100% 911-compliant VoIP is unlikely to ever happen because the 'line' is not tied to any fixed infrastructure. Cell phones have the towers, cable/dsl/phone have the coax/phone cable but VoIP is not tied to any particular endpoint/network/etc. anywhere on the planet. Even if a GPS receiver is built into the VoIP phones, these still depend on being able to detect the satellites and will fail to provide a location if there are a few reinforced concrete buildings around the area. Even if the GPS is cell-assisted, even cell phones stop working inside larger reinforced concrete buildings and there are dead zones all around towns too.
VoIP is not for critical calls. AFAIK, it was never intended to be and never will be. For VoIP to work, you have to trust that:
1) Your WiFi handset will work
2) Your WiFi router will work
3) Your ADSL/Cable/whatever modem will work
4) Your ISP link will work
5) Your VoIP company's servers will work
6) etc.
VoIP has more than double the number of middle-men compared to land lines and cell phones. Every link is a potential point of failure and any failure is very likely to lead to a dropped call, assuming the failure did not prevent you from placing the call in the first place. Last thing you want to have to do when you need to make an urgent call is troubleshooting your network.
The entertainment industry is pushing these projects to protect the perceived faults in their business models and future business opportunities.
By fighting their projects, we risk successfully saving them from themselves without them realizing how close they came from falling off their own cliff. If that happened, they would most likely become even more arrogant than they already are. Letting them have their dumb laws and alienate their customers to the point of causing a market implosion will forcibly hammer some much needed sense into the entertainment airheads.
Letting them do as they want may not be pretty but trying to prevent it will only make things worse for a longer time by delaying the inevitable. They will keep acting like spoilt kids until they get clubbed by reality. The sooner they get clubbed, the sooner sanity may be restored.
Let them waste their money and resources for futile fixes for problems that do not exist. Let them alienate their customer base by creating unnecessary complexities and complications. Help them commit technical suicide so we can start with a clean slate as soon as possible.
With a low-cost FPGAs, it would be absolutely possible to implement encrypted storage in the form of an ATA-to-ATA bridge.
I'm sure forensic teams would have a blast trying to decript an AES512 volume... and to make the drive imaging more difficult, the encryption could be 'seeded' using the drive's firmware, model#, serial# and anything else that may be relatively unique, including a timing challenge to verify that the bridge is really connected directly to a drive and not to some other bridge.
Use a removable external firmware chip for the FPGAs and once the police unplugs the computer, they indirectly destroy the only firmware copy they had and leave their forensic team with no clue about the actual data scrambling algorithm.
Sounds like an interesting project for my Master's.
Then you get a ~1h break while the drive is being restored from the original's image... or nearly no break at all if they expected this and pre-imaged the drive a few times.
You are going to need a fairly large and sturdy suitcase to fit the magnetron and its PSU... a microwave oven transformer weights about 1kg, the UPS that feeds it is another ~1kg (without battery and casing) and the batteries are another ~5kg. (Though you could cut nearly 2kg by building your own 12V or 24V to 2.5kV/1kW step-up converter.)
The simplest thing would be a spark gap housed in a wave-guide... but this would be really loud when driven with the sort of energy levels necessary to generate disruptive and potentially destructive amounts of RFI.
I'm fine with companies tracking my personal info if UK-style laws are adopted. IIRC, some of the more interesting clauses went something like this:
1) companies shall not use nor retain information whose origins is not documented
2) companies must make all the info they have on an individual including sources at the individual's request
3) individuals may have companies delete records unless the company can justify keeping the records of terminated accounts
This way, companies would at least have to think at least twice before collecting, using and distributing data.
I just happened to get a job interview for a DSL company this week... the job is primarily about testing DSLAM and DSL modem firmware/hardware combinations on simulated and field test loops up to 5000' - validation before deployment for a major Canadian ISP. If I get that job, I should have a pretty good idea about how good all things DSL are going to be for the foreseeable future.