The History Channel had a great TV show simply called "The Universe", on the human history of our current understanding of the Universe.
As the show proceeded, I found I was pausing the TV and sharing with Christine some footnotes of the history of these discoveries, and the various other ideas I've concocted along the way.
I realized that I had never shared these ideas, and (aside from college level math and Physics classes) lacking the scientific and mathematical sophistication to prove any of them out, I figured I would share them here, warts and all. I'm not aware of anyone else who has had these ideas, so as far as I'm aware, they are my own thoughts that attempt to explain certain phenomena.
These ideas (I hesitate to call them anything approaching even a hypothesis) came to me as I'd read Sagan (in high school) and Hawking (in college).
One idea relates to the Big Bang theory and whether we are in a constantly expanding, contracting or steady state universe. Simply stated, my idea is that the universe continues to expand until the energy imparted upon all of the mass is sufficiently expended such that the universe begins to contract.
As it does, a critical mass begins to coalesce, and once enough of it does, the concentration of mass/gravity/energy gets so great that the fundamental nature of mass/gravity/energy are fundamentally changed for a fraction of a second, and the totality of this primordial mass explodes in (another) big bang. In essence, the entire universe is like a human heart, contracting and expanding in many cycles of creation and destruction.
A particular corollary to this idea is that the universe is comprised of precisely enough matter (not an iota less or more) to cause this cycle to occur/reoccur. Without this corollary, it would leave the door open to the premise that many galaxies could have existed (and presumably were wiped out) at the time of the big bang from a previous big bang, but "missed the party" because the critical mass was accumulated before they were close enough to take part. Interestingly, this may also be a possible explanation for the uniform distribution of cosmic radiation described as the "horizon problem". Of course, a solution to this problem already exists (see Alan Guth's Inflationary Theory)...
Another idea relates to a model to help explain the idea of time dilation (Einstein's theory of relativity).
When you put your hand outside a window of a moving car, you experience the motion of molecules over your hand. The faster you move, the more molecules you experience. So the relationship of air to movement through it is: "the more you move through the more motion of molecules you experience".
If you assume that time is universal (time elapses at any observable point in the universe) and it is independent of matter (in the vacuum of space, time passes whether you are near a massive object or not), but dependent of velocity (a clock on a jet will show the passing of less time than one on the ground), you need a model that allows you to move through space, and experience the passage of less time the faster you move.
Or, the opposite of the experience when you put your hand outside the car... One way to make this analogy conform is to instead consider the cooling effect you feel when you put your hand outside the window. If we assume that matter exudes time, like perspiration comes off an athlete, the faster you move through space time, the more the evaporation effect takes place, and the more cooling effect the athlete experiences.
So, the fabric of space time is like the molecules of air that cause the "evaporation" of time. The faster you move through it, the more "cooling" (dilation of time) you experience.
In this model, time is intrinsic to mass (in nothingness, there is nothing to measure the passing of time-- so this assumes that energy, radiation, matter must exist-- time exudes through it like perspiration through skin), and the speed at which the mass moves through space (the speed at which a mass of air passes over your skin) defines the amount of time that elapses (the cooling capacity of the air to provide the cooling effect).
Just like molecules of air have the ability to absorb moisture through condensation, space time has the ability to "absorb time" relative to the speed mass moves through it. I suspect that this phenomenon, dilation of time, is related to the quantum effect of the Heisenberg uncertainty principle... Here's how I picture that might work: Einstein used the model of the fabric of space time. There exist fundamental "gaps" in this fabric such that no two points can be closer than a Planck distance apart from each other (quantum effect of the Heisenberg uncertainty principle). It's these "gaps" which form the ability of space to "absorb time". The faster you move over this fabric, the more time it is able to wick off. In a sense, you might say that in given "square yard" (or "cubic yard", if you'll admit that space is more like a three dimensional "gel" than a two dimensional "fabric") of space, there is a particular "planck density" at which time can elapse.
The nature of moving closer to the speed of light over it causes you to travel over more "(time consuming) gaps in the fabric of space time"...
Sun, 28 Sep 2008
Thu, 25 Sep 2008
HDR Trifecta
Couldn't help myself... again...
Photoshop and iPhoto were open, as were some images just begging to be HDRed.
This is of a terrace just outside of Naples on the island of Capri (yes, the one that Capri pants are named after).
Photoshop and iPhoto were open, as were some images just begging to be HDRed.
This is of a terrace just outside of Naples on the island of Capri (yes, the one that Capri pants are named after).
Comments are closed for this story
Newest HDR Image, Take 2
I couldn't help myself, I found another bracketed photo I took of the ruins at Segesta, in Sicily.
Enjoy!
Enjoy!
Comments are closed for this story
Newest HDR Image
One of the things I'm really glad I did on my European Disney Cruise last summer was to take bracketed exposures of various shots.
That means I can come back and process some HDR (High Dynamic Range) photographs of those scenes.
The one for today is a shot of what I call "The Mouse at the Wheel" (Disney calls it "Helmsman Mickey"), a sculpture in the atrium of the Disney Magic inspired by "The Man at the Wheel", a cenotaph in Gloucester Mass.
I tried to avoid giving the photo the appearance of false color you sometimes get with HDR photos.
That means I can come back and process some HDR (High Dynamic Range) photographs of those scenes.
The one for today is a shot of what I call "The Mouse at the Wheel" (Disney calls it "Helmsman Mickey"), a sculpture in the atrium of the Disney Magic inspired by "The Man at the Wheel", a cenotaph in Gloucester Mass.
I tried to avoid giving the photo the appearance of false color you sometimes get with HDR photos.
Comments are closed for this story
Sun, 21 Sep 2008
Fox On Demand, Powered by Move Networks
Earlier this week, my Crapcast DVR decided that it didn't want to record the second episode of the Fox TV show "Fringe". I only realized this after Christine asked me if I'd deleted the episode.
After checking Fox's website, I realized that, in fact, the DVR failed to record the show. Before I could head to iTunes to download the episode, Fox's website seemed to have the show available for free.
After installing a plugin (Firefox calls it the MoveNetworks Quantum Media Player), within minutes I was downloading what appeared to be a near HD quality video stream of the full episode... without ads (well teasers/trailers seems like a small price to pay, but no ads inline, although when I just checked again, there do seem to be a few short ads interspersed)...
Warning: Geek content follows. For those not moderately interested in the mechanics behind this technology, suffice it to say, this is cool stuff, definitely check it out. The rest of this post will delve into the details of how it works.
I was skeptical of the video quality, but the approach that the MoveNetworks technology uses is ingenious. First, they split up the video into what they call "streamlets", or small "digestible" segments of video.
The advantages of this are multiple. First, if any network congestion or slowdowns are encountered by the client (which apparently has logic built in to determine if any frames are dropped), it can request the next streamlet of video at a slightly lower bitrate until the quality of the video matches the capacity of the network connection.
Secondly, this also means that there's very little buffering, and gives each viewer the best quality video that their connection can support at any given time.
Curious, I used tcpdump (for the nontech readers of this blog, this is a packet sniffer that allows the inspection of the data packets used for Internet communications) to identify what's happening underneath the covers.
The first question I wanted to know was whether they were using TCP or UDP. Typically streaming video uses UDP because it is generally a better protocol to use with applications which are time sensitive. In other words, if your connection gets really slow, there's no point in using a packet of data which contains video from 3 seconds ago. Video players that stutter back to 3 seconds ago once the data is obtained would be annoying. Much like Lucy should have done on the chocolate conveyor belt, let the ones go that are already on the floor, and focus on the ones coming down the line.
Interestingly, MoveNetworks uses TCP. With a "streamlet" strategy, they prefer to use the standard HTTP protocol (which uses TCP) which means they can use common web servers like Apache to keep their infrastructure costs low. (More on this in just a bit) Again, because their client has the intelligence to request smaller data packets when necessary, they intend to guarantee that the client only ask for data streams of "digestible size", to help guarantee that they drop very few frames of data.
Incidentally, this is a technique that TCP itself uses in negotiating window sizes. A window size, in the TCP protocol, is a negotiation technique that allows clients and servers to determine the ideal amount of data to be sent. Clients and servers that can handle larger and more packets gradually increase their carrying capacity until transmission failures occur, and then back off to about half that speed. The process continually repeats, providing, on what would on average appear to be 75% of the capacity of the network between the client and the server.
After what appears to be various tracking data being passed back to MoveNetworks, and some SSL traffic (secure traffic presumably intended to verify that the player requesting the data is an authorized player to help ensure that media pirates can't decode or fetch the streams), and a brief XML conversation, multiple HTTP streams are initiated at once to a content distribution network, or CDN. In this case, the CDN used is Limelight Networks, a competitor to the more widely known Akamai. (Note to the LimeLight security team-- you ought to suppress your server's response signature, as it's clear to anyone with a packet sniffer that you're using Apache/2.2.3.(CentOS))
All of this negotiation happens in a matter of 5 seconds or so. When the negotiation and authentication is complete, a standard HTTP request of "GET /qmplivefox/foxvod/ad/3ajn03/E575E001FD8 E254DB2E983A09D3B93F1_0400000003.qss HTTP/1.0" is requested from Limelight servers: "Host: move-od-405.vo.llnwd.net". The user agent is reported as "QSP.21:1[0].R{0-51698}". Interestingly enough, the portion of the user agent R{0-51698} is also requested as a standard HTTP content range header: "Range: bytes=0-51698".
As stated earlier, this is accompanied immediately by two other requests, this time with "Range: bytes=51699-10339" and "Range: bytes=103398-".
Generically, the responses tend to look like this (all standard HTTP stuff): "206 Partial Content", "Accept-Ranges: bytes", "Cache-Control: max-age=864000", "Content-Type: application/qss", "Age: 392446", "Date: Sun, 21 Sep 2008 04:33:06 GMT", "Last-Modified: Tue, 06 Nov 2007 03:41:11 GMT", "Expires: Fri, 26 Sep 2008 15:32:20 GMT", "Content-Range: bytes 0-51698/155097", "Content-Length: 51699", "Connection: close".
18ms later, the second response comes back with "Content-Range: bytes 51699-103397/155097", and 1ms after that, "Content-Range: bytes 103398-155096/155097".
Once these streams complete downloading, three new requests are made for 50KB of data each, this time for an incremented URI: "/qmplivefox/foxvod/ad/3ajn03/E575E001FD8E254DB2E983A09D3B93F1_0400000004.qss". It takes just 3 seconds to fetch another 150KB of data, so it would seem the initial packets establish a bitstream that is roughly 50KB/sec. (Compared to the H.264 codec, this bit rate would support a resolution of roughly 352x288@15.2 frames/sec)
Periodically, the https traffic continues to presumably update auth tokens to allow additional streams to be downloaded.
I didn't try to introduce network problems to see how the streams would be throttled back, but evidenced by decent video quality for nearly an hour, my broadband connection was able to sustain video quality that is of impressive quality.
Move has entered into agreements with other TV networks such as ABC and CW, which are also apparently using the Move technology. The client makes similar requests, "GET /vod/BBB87026/hss_113_finale_episode_1785344/A6B4B2BC1D05974993B831362BD5D9E4_0500000007.qss", although the traffic in this case goes to "stream.qec8.qcg1.qcn3.movenetworks.com" instead of to a CDN.
ABC shows a 1 minute ad you can't skip, unlike Fox, for each video "chapter". The ABC stream never got faster than "1623kbps" while watching Lost, and on the CW network, Supernatural never got past "730kbps" on my network. Traceroutes show that the ABC datacenter I'm using is in San Jose, and the CW network is also using the Limelight CDN.
These bitrates confirm my suspicion that the streams don't quite hit 720p HD quality, although they compare well to DVD quality.
After checking Fox's website, I realized that, in fact, the DVR failed to record the show. Before I could head to iTunes to download the episode, Fox's website seemed to have the show available for free.
After installing a plugin (Firefox calls it the MoveNetworks Quantum Media Player), within minutes I was downloading what appeared to be a near HD quality video stream of the full episode... without ads (well teasers/trailers seems like a small price to pay, but no ads inline, although when I just checked again, there do seem to be a few short ads interspersed)...
Warning: Geek content follows. For those not moderately interested in the mechanics behind this technology, suffice it to say, this is cool stuff, definitely check it out. The rest of this post will delve into the details of how it works.
I was skeptical of the video quality, but the approach that the MoveNetworks technology uses is ingenious. First, they split up the video into what they call "streamlets", or small "digestible" segments of video.
The advantages of this are multiple. First, if any network congestion or slowdowns are encountered by the client (which apparently has logic built in to determine if any frames are dropped), it can request the next streamlet of video at a slightly lower bitrate until the quality of the video matches the capacity of the network connection.
Secondly, this also means that there's very little buffering, and gives each viewer the best quality video that their connection can support at any given time.
Curious, I used tcpdump (for the nontech readers of this blog, this is a packet sniffer that allows the inspection of the data packets used for Internet communications) to identify what's happening underneath the covers.
The first question I wanted to know was whether they were using TCP or UDP. Typically streaming video uses UDP because it is generally a better protocol to use with applications which are time sensitive. In other words, if your connection gets really slow, there's no point in using a packet of data which contains video from 3 seconds ago. Video players that stutter back to 3 seconds ago once the data is obtained would be annoying. Much like Lucy should have done on the chocolate conveyor belt, let the ones go that are already on the floor, and focus on the ones coming down the line.
Interestingly, MoveNetworks uses TCP. With a "streamlet" strategy, they prefer to use the standard HTTP protocol (which uses TCP) which means they can use common web servers like Apache to keep their infrastructure costs low. (More on this in just a bit) Again, because their client has the intelligence to request smaller data packets when necessary, they intend to guarantee that the client only ask for data streams of "digestible size", to help guarantee that they drop very few frames of data.
Incidentally, this is a technique that TCP itself uses in negotiating window sizes. A window size, in the TCP protocol, is a negotiation technique that allows clients and servers to determine the ideal amount of data to be sent. Clients and servers that can handle larger and more packets gradually increase their carrying capacity until transmission failures occur, and then back off to about half that speed. The process continually repeats, providing, on what would on average appear to be 75% of the capacity of the network between the client and the server.
After what appears to be various tracking data being passed back to MoveNetworks, and some SSL traffic (secure traffic presumably intended to verify that the player requesting the data is an authorized player to help ensure that media pirates can't decode or fetch the streams), and a brief XML conversation, multiple HTTP streams are initiated at once to a content distribution network, or CDN. In this case, the CDN used is Limelight Networks, a competitor to the more widely known Akamai. (Note to the LimeLight security team-- you ought to suppress your server's response signature, as it's clear to anyone with a packet sniffer that you're using Apache/2.2.3.(CentOS))
All of this negotiation happens in a matter of 5 seconds or so. When the negotiation and authentication is complete, a standard HTTP request of "GET /qmplivefox/foxvod/ad/3ajn03/E575E001FD8 E254DB2E983A09D3B93F1_0400000003.qss HTTP/1.0" is requested from Limelight servers: "Host: move-od-405.vo.llnwd.net". The user agent is reported as "QSP.21:1[0].R{0-51698}". Interestingly enough, the portion of the user agent R{0-51698} is also requested as a standard HTTP content range header: "Range: bytes=0-51698".
As stated earlier, this is accompanied immediately by two other requests, this time with "Range: bytes=51699-10339" and "Range: bytes=103398-".
Generically, the responses tend to look like this (all standard HTTP stuff): "206 Partial Content", "Accept-Ranges: bytes", "Cache-Control: max-age=864000", "Content-Type: application/qss", "Age: 392446", "Date: Sun, 21 Sep 2008 04:33:06 GMT", "Last-Modified: Tue, 06 Nov 2007 03:41:11 GMT", "Expires: Fri, 26 Sep 2008 15:32:20 GMT", "Content-Range: bytes 0-51698/155097", "Content-Length: 51699", "Connection: close".
18ms later, the second response comes back with "Content-Range: bytes 51699-103397/155097", and 1ms after that, "Content-Range: bytes 103398-155096/155097".
Once these streams complete downloading, three new requests are made for 50KB of data each, this time for an incremented URI: "/qmplivefox/foxvod/ad/3ajn03/E575E001FD8E254DB2E983A09D3B93F1_0400000004.qss". It takes just 3 seconds to fetch another 150KB of data, so it would seem the initial packets establish a bitstream that is roughly 50KB/sec. (Compared to the H.264 codec, this bit rate would support a resolution of roughly 352x288@15.2 frames/sec)
Periodically, the https traffic continues to presumably update auth tokens to allow additional streams to be downloaded.
I didn't try to introduce network problems to see how the streams would be throttled back, but evidenced by decent video quality for nearly an hour, my broadband connection was able to sustain video quality that is of impressive quality.
Move has entered into agreements with other TV networks such as ABC and CW, which are also apparently using the Move technology. The client makes similar requests, "GET /vod/BBB87026/hss_113_finale_episode_1785344/A6B4B2BC1D05974993B831362BD5D9E4_0500000007.qss", although the traffic in this case goes to "stream.qec8.qcg1.qcn3.movenetworks.com" instead of to a CDN.
ABC shows a 1 minute ad you can't skip, unlike Fox, for each video "chapter". The ABC stream never got faster than "1623kbps" while watching Lost, and on the CW network, Supernatural never got past "730kbps" on my network. Traceroutes show that the ABC datacenter I'm using is in San Jose, and the CW network is also using the Limelight CDN.
These bitrates confirm my suspicion that the streams don't quite hit 720p HD quality, although they compare well to DVD quality.
Comments are closed for this story
Ceding Our Leadership Position
We're letting the Indians win an important race.
No, I'm not talking about the "outsourcing" situation, which is simply an inevitable component of the current landscape when you have a population of well-educated engineers and call center workers in an economy where the prevailing wage is far more competitive than it is locally. As the Indian economy matures, the Indian services market (whether it's a C++ programmer or a call center operator) will begin to price itself out of the market, and those jobs will move to China, South America, and eventually Africa. Note to hopeful 3rd-world countries: follow India's lead and you too can witness the growth of a prosperous middle class...
Rather, I'm talking about some news this morning which indicates we're losing a race we should be in, that of space exploration. It appears somebody gets it in the Indian space administration, something that NASA has been unable to impress upon our current leadership. I'm talking about the harvesting of He3 from the moon.
In an article today, I was simultaneously excited (to hear the Indians are pursuing it) and chagrined (that it wasn't the US) to hear that India's mission to the moon has as a central focus, the prospect of mining He3.
No, I'm not talking about the "outsourcing" situation, which is simply an inevitable component of the current landscape when you have a population of well-educated engineers and call center workers in an economy where the prevailing wage is far more competitive than it is locally. As the Indian economy matures, the Indian services market (whether it's a C++ programmer or a call center operator) will begin to price itself out of the market, and those jobs will move to China, South America, and eventually Africa. Note to hopeful 3rd-world countries: follow India's lead and you too can witness the growth of a prosperous middle class...
Rather, I'm talking about some news this morning which indicates we're losing a race we should be in, that of space exploration. It appears somebody gets it in the Indian space administration, something that NASA has been unable to impress upon our current leadership. I'm talking about the harvesting of He3 from the moon.
In an article today, I was simultaneously excited (to hear the Indians are pursuing it) and chagrined (that it wasn't the US) to hear that India's mission to the moon has as a central focus, the prospect of mining He3.
Indian space scientists expect to map the lunar surface for the helium-3 (He-3) mineral to fuel nuclear power plants and frozen water as they make final preparations for India’s mission to the moon, expected to blast off next month.This is great news for humanity in general, because it means somebody is taking a leadership position for sustainable, non-polluting nuclear energy. It's bad news for the US, however, because it means that the Indians are beating us to the punch in harvesting He3 nuclear fuel.
Non-radioactive He-3 is scarce on earth but believed to be abundant on earth’s natural satellite and is seen as a promising fuel for advanced fusion reactors to generate power...
"The mission will help us locate He-3, which has the potential to produce a large amount of energy. It is expected that in a few years we can transport it from the moon to run nuclear plants and generate electricity," the director of the Indian Space Research Organisation’s (ISRO) satellite centre T K Alex said.
"Probably 10 years from now fusion reactors which can use He-3 will be available. Our second mission to the moon, Chandrayaan-II, will also have a lunar lander and help us collect samples of the mineral."
"In the next 40 years, it will be possible to transport it to the earth," he said.
Comments are closed for this story
Tue, 09 Sep 2008
Music Recommendation: Ravenous Soundtrack
My friend Rus blogged about an Icelandic band called Amiina, and one of their tracks, Hemipode (check out his blog for a listen) reminded me of one of my favorite soundtracks, the "Ravenous" soundtrack.
It's eerily atonal at times, and electronic at times, with bluegrass themes, and catchy choruses. You can listen to track samples at last.fm. True, some of the tracks sound like a Junior High band trying to warm up.
Others, however, such as Boyd's Journey, The Cave, Run, Manifest Destiny, and particularly the End Titles tracks fill a void in my musical repertoire like none other can. I love listening to Manifest Destiny in my car with the bass turned up really high. That's a track that needs to be felt to be experienced well.
One nice thing about modern technology is playlists. You can skip the uninspiring tracks (which probably fill a great purpose in the telling of the story of the movie-- this is a true soundtrack), and instead listen to music magic like Manifest Destiny.
My rating: (considering the playlist option to exclude uninteresting tracks) five stars.
Postscript: Manifest Destiny has, what I'd tonally call, what resembles a "dailing tone" or "busy signal" as one of its themes. Here are a few more songs that use that theme. Please submit any of your favorites that you think match.
It's eerily atonal at times, and electronic at times, with bluegrass themes, and catchy choruses. You can listen to track samples at last.fm. True, some of the tracks sound like a Junior High band trying to warm up.
Others, however, such as Boyd's Journey, The Cave, Run, Manifest Destiny, and particularly the End Titles tracks fill a void in my musical repertoire like none other can. I love listening to Manifest Destiny in my car with the bass turned up really high. That's a track that needs to be felt to be experienced well.
One nice thing about modern technology is playlists. You can skip the uninspiring tracks (which probably fill a great purpose in the telling of the story of the movie-- this is a true soundtrack), and instead listen to music magic like Manifest Destiny.
My rating: (considering the playlist option to exclude uninteresting tracks) five stars.
Postscript: Manifest Destiny has, what I'd tonally call, what resembles a "dailing tone" or "busy signal" as one of its themes. Here are a few more songs that use that theme. Please submit any of your favorites that you think match.
- In the Meantime, by Spacehog (YouTube video -- by the way, Spacehog rocks)
- Vienna Calling (YouTube video -- by the way, Falco rocks too)
- Kraftwerk (YouTube video -- do I have to say it?)
- Pink Floyd - Young Lust/Empty Spaces Interlude (YouTube video, 4:55 in)
- The Penguin Cafe Orchestra - Telephone and Rubber Band (YouTube video - in case you thought you'd heard the Spacehog music before)
Comments are closed for this story
URL:
Title:
Comment/Excerpt: I've watched a lot of Move Networks content (my wife loves watching Bones on Fox's website, because the quality we get through their player is better than we get via DirecTV -- no HD DVR unfortunately). To your comment about the bitrates you saw from ABC and CW, it seems they allow their customers to decide what maximum bitrates to allow for their content. ABC.com even seems to use different max bitrates from show to show -- they list some of their shows as "HD" and some not. My guess is this is to make it easy for networks to define bandwidth usage limits. Nice info on their streaming, I hadn't done a tcpdump myself, interesting stuff.