There was an article in the New York Times this morning (Tuesday Oct 22, 2013) about the fear of radiation Fear of Radiation (NY Times). The author makes some statements about how we might have unfounded fear of radiation and that Chernobyl and Fukushima survivors and that the cancer rate has been less than expected. The author goes on to state that the number of cancer victims from ionizing radiation in Hiroshima and Nagasaki was much lower than the total number of cancer cases (527 out of 10,929 cancer cases).
I worked at Argonne National Laboratory in Chicago during the Three Mile Island incident. I heard a very interesting lecture about our knowledge of human radiation susceptibility. It turned out that all of our radiation rate numbers from nuclear bomb tests in Alamogordo, NM were in dry weather and significantly above sea level. Hiroshima and Nagasaki had significantly higher humidity and different concrete makeup than found in most US cities. Absorption of prompt radiation was higher than expected. It is likely that the Japanese people received less radiation than we expected and our understanding of how much radiation we can stand might be underestimated.
The lack of data in this area of study is amazing. We did not have the opportunity to measure radiation at Chernobyl, Fukushima, Nagasaki and Hiroshima at the most critical time, namely, when short-lived radioactive elements are most intense. By the time measurements were made, the really dangerous stuff had already decayed. The measurements need to be done the day of the event. A lot of people may have died of radiation poisoning without dying of cancer.
Meanwhile, we are afraid of radiation from cell phones. The 2-5 GHz range of radiation at a few watts is non-ionizing. It can't cause chemical reactions just by ripping electrons from atoms like with ionizing radiation. But, it can go through a cooking process. Are we afraid of light bulbs? If we are afraid of cell phone radiation, we should be afraid of sitting underneath a 75 watt light bulb. The radiation isn't all that different. We have cell replacement that repairs damage from a very slow cooking process that happens in slightly elevated temperatures.
I am not sure how we get better radiation data. We certainly do not want to purposely put people in harmful environments. But, we do need to take better and more prompt data when accidents do occur. Unfortunately, covering up the problem and politics dominates and inhibits prompt measurements.
Tuesday, October 22, 2013
Sunday, September 22, 2013
Chromecast comparison to Apple TV
I just received my Chromecast a few days ago. I have a few thoughts about it. I also have an older Apple TV (small model, but HD 720p model). The question is, can I tell the difference between 720p and 1080p?
I compared watching the series Borgia on both from Netflix. I used a small Samsung TV capable of 1080p. There is no contest in visual quality between the Chromecast and the 720p Apple TV. The color, contrast and detail is MUCH better for the Chromecast. Despite some tech blogs that say that there is no difference between 720p and 1080p for small TVs, I completely disagree. For instance, I disagree with:
Digital Trends on 720P vs. 1080P
But, interpolation must have some smoothing function, or else there will be visible artifacts (ghosts and shadows and rings) at sharp edges. It is probable that the interpolation does an effective averaging, reducing contrast and detail. This will also make the colors appear to be less vivid.
In another post, I will talk about the security of transferring a Netflix video in progress from an iPad to the Chromecast. (Note, not a big security concern, but the security is by obscurity - at least from my standpoint, how does the Chromecast pick up Netflix without the user typing in a password?). The bit rate on my network showing Borgia on my iPad results in about 5 Mbps (megabits per second) with 12 Mbps spikes. It is clear that buffering is important to the iPad. It is also clear that watching 1080p video from Netflix requires a good working network.
Ookla measured download rate by country
In my house, Chromecast has the appearance of going to the same server farm as Apple TV. This is despite the fact that Chromecast goes to Google's DNS server vice iPad going to my ISP's DNS server (why this might matter will happen in a future post). Chromecast has a lower bit rate from Netflix than my iPad for some unknown reason. The bit rate is 6 Mbps varying from 4 Mbps to 6 Mbps.
The bit rate to my Apple TV is also about 5 Mbps. It is episodic, 10 Mbps for a while followed by idle network. The bandwidth rate is not terribly different between the Netflix and all my devices despite the difference in resolution of the displayed video. In all cases, TCP was used for the video transfer, not UDP. I suspect that TCP is preferred over UDP due to the ease of bandwidth throttling with TCP technology rather than UDP.
Now that it is clear that the bandwidth from Netflix is the same regardless of the resolution of the device doing the display, it is sending compressed 1080p video. There are 1920 X 1080 pixels/second being displayed for 1080p video, probably 24 bits wide (red/green/blue 8 bits deep). But, High Definition TV displays 30 frames/second. With no compression, this would be 2 million pixels each frame, 30 frames/second resulting in 1.5 Gbps (1.5 billion bits per second). Sound is included in that bit rate, but that could be as high as 300 kbps. The compression is at least a factor of 300. If 1080i is sent rather than 1080p, then the bit rate is half and the compression would be half (150 rather than 300). The standard for over-the-air broadcast in the United States is 1080i rather than 1080p.
As for encryption, Netflix uses standard HTTP (port 80) to transfer video. It uses SIP/NOE protocol (Session Initiation Protocol/New Office Environment) in response to a GET request. The data are probably encrypted in the payload. It is possible that user identification information is embedded in the GET request (certainly, client device type is in the clear), but, clearly, Netflix is using security by obscurity (more on this on another blog). But, it is difficult to tell if encryption increases the bit rate or not. For the rest of this posting, I will assume that encryption does not increase bandwidth requirements appreciably. Netflix is not using HTTPS to transfer video, that much is clear.
From the source of video, the compression is more than a factor of 100. All my devices must expand the video internally to 2 million pixels. The Apple TV must compress the resulting image down to 900 thousand pixels in order to send this to the television at 720p. The TV has to take these 900 thousand pixels and expand it back to 2 million pixels. It is possible that the video codec for Netflix is multi-resolution, but they are not storing different copies of videos by the ultimate resolution of the end product.
The television is definitely doing an upsample to 1080p (2 million pixels) from the Apple TV. While the initial compression is quite high from the transmitting source (preprocessed compression to files at Netflix), the Apple TV is sending pictures that contain half as many pixels as the TV can display (1.5 times vertically, 1080/720 = 1.5). The Samsung television is doing an upsample by an interpolation more complicated than averaging two lines and displaying one in between.
This interpolation does do some averaging of color and detail across pixel lines sent versus displayed. This interpolation must have some smoothing function, or else there will be visible artifacts (ghosts and shadows and rings). This effective averaging ends up reducing contrast and detail. This results in a display that is visually not nearly as good to the eye.
One thing that should be clear in this discussion is that some of the discussions on the Internet indicate that maybe, one cannot tell the difference between 720p and 1080p resolution. I believe that this is too simplistic and depends on the source of the video the user is watching and connecting up to the television. If the source is largely 720p (often the case with over-the-air broadcasting and a significant fraction of television programs on cable TV), then, perhaps 720p is a better match to the source. But, if the user has a significant amount of 1080p sources of video, the 720p television will significantly reduce the contrast and detail of the picture. It is not a matter of simply how many pixels are on the screen, it is a matter of how much processing has to be done to create the display for the screen.
I compared watching the series Borgia on both from Netflix. I used a small Samsung TV capable of 1080p. There is no contest in visual quality between the Chromecast and the 720p Apple TV. The color, contrast and detail is MUCH better for the Chromecast. Despite some tech blogs that say that there is no difference between 720p and 1080p for small TVs, I completely disagree. For instance, I disagree with:
Digital Trends on 720P vs. 1080P
But, interpolation must have some smoothing function, or else there will be visible artifacts (ghosts and shadows and rings) at sharp edges. It is probable that the interpolation does an effective averaging, reducing contrast and detail. This will also make the colors appear to be less vivid.
In another post, I will talk about the security of transferring a Netflix video in progress from an iPad to the Chromecast. (Note, not a big security concern, but the security is by obscurity - at least from my standpoint, how does the Chromecast pick up Netflix without the user typing in a password?). The bit rate on my network showing Borgia on my iPad results in about 5 Mbps (megabits per second) with 12 Mbps spikes. It is clear that buffering is important to the iPad. It is also clear that watching 1080p video from Netflix requires a good working network.
Ookla measured download rate by country
In my house, Chromecast has the appearance of going to the same server farm as Apple TV. This is despite the fact that Chromecast goes to Google's DNS server vice iPad going to my ISP's DNS server (why this might matter will happen in a future post). Chromecast has a lower bit rate from Netflix than my iPad for some unknown reason. The bit rate is 6 Mbps varying from 4 Mbps to 6 Mbps.
The bit rate to my Apple TV is also about 5 Mbps. It is episodic, 10 Mbps for a while followed by idle network. The bandwidth rate is not terribly different between the Netflix and all my devices despite the difference in resolution of the displayed video. In all cases, TCP was used for the video transfer, not UDP. I suspect that TCP is preferred over UDP due to the ease of bandwidth throttling with TCP technology rather than UDP.
Now that it is clear that the bandwidth from Netflix is the same regardless of the resolution of the device doing the display, it is sending compressed 1080p video. There are 1920 X 1080 pixels/second being displayed for 1080p video, probably 24 bits wide (red/green/blue 8 bits deep). But, High Definition TV displays 30 frames/second. With no compression, this would be 2 million pixels each frame, 30 frames/second resulting in 1.5 Gbps (1.5 billion bits per second). Sound is included in that bit rate, but that could be as high as 300 kbps. The compression is at least a factor of 300. If 1080i is sent rather than 1080p, then the bit rate is half and the compression would be half (150 rather than 300). The standard for over-the-air broadcast in the United States is 1080i rather than 1080p.
As for encryption, Netflix uses standard HTTP (port 80) to transfer video. It uses SIP/NOE protocol (Session Initiation Protocol/New Office Environment) in response to a GET request. The data are probably encrypted in the payload. It is possible that user identification information is embedded in the GET request (certainly, client device type is in the clear), but, clearly, Netflix is using security by obscurity (more on this on another blog). But, it is difficult to tell if encryption increases the bit rate or not. For the rest of this posting, I will assume that encryption does not increase bandwidth requirements appreciably. Netflix is not using HTTPS to transfer video, that much is clear.
From the source of video, the compression is more than a factor of 100. All my devices must expand the video internally to 2 million pixels. The Apple TV must compress the resulting image down to 900 thousand pixels in order to send this to the television at 720p. The TV has to take these 900 thousand pixels and expand it back to 2 million pixels. It is possible that the video codec for Netflix is multi-resolution, but they are not storing different copies of videos by the ultimate resolution of the end product.
The television is definitely doing an upsample to 1080p (2 million pixels) from the Apple TV. While the initial compression is quite high from the transmitting source (preprocessed compression to files at Netflix), the Apple TV is sending pictures that contain half as many pixels as the TV can display (1.5 times vertically, 1080/720 = 1.5). The Samsung television is doing an upsample by an interpolation more complicated than averaging two lines and displaying one in between.
This interpolation does do some averaging of color and detail across pixel lines sent versus displayed. This interpolation must have some smoothing function, or else there will be visible artifacts (ghosts and shadows and rings). This effective averaging ends up reducing contrast and detail. This results in a display that is visually not nearly as good to the eye.
One thing that should be clear in this discussion is that some of the discussions on the Internet indicate that maybe, one cannot tell the difference between 720p and 1080p resolution. I believe that this is too simplistic and depends on the source of the video the user is watching and connecting up to the television. If the source is largely 720p (often the case with over-the-air broadcasting and a significant fraction of television programs on cable TV), then, perhaps 720p is a better match to the source. But, if the user has a significant amount of 1080p sources of video, the 720p television will significantly reduce the contrast and detail of the picture. It is not a matter of simply how many pixels are on the screen, it is a matter of how much processing has to be done to create the display for the screen.
Subscribe to:
Posts (Atom)