reply to IllIlIlllIll
Re: Optimum App for Laptop: SD-only? Those bit rate numbers (e.g., 22 Mbps) are not taking into account the video compression gains of H.264. I am sure the Optimum App streams are H.264 based. A well implemented H.264 stream of HD content should be 5 Mbps or less (i.e., at least half the bit rate of the equivalent quality MPEG-2 encoded stream).
With adaptive bit rate streaming a given program stream is encoded at multiple bit rates (resulting in various video qualities) and the network dynamically determines what bit rate the client (i.e., your laptop, iPad, etc) can best handle given the performance of the network (a function of the speed of your subscription, network congestion, and client responsiveness).
With this approach you will often see the video quality improve shortly after the streaming begins, as the algorithm gradually tries higher bit rates until it reaches an optimal rate (given the network conditions)
Hampton Bays, NY
i will do a test @ 1280x720 and measure the actual throughput downstream being used.
Cool, I look forward to your findings
reply to IllIlIlllIll
Re: Optimum App for Laptop: Bit-Rates? I did a quick test of the bit-rate when watching live TV on a laptop (wired Ethernet). I found sports HD channels in the neighborhood of 3 Mbps and non-sports HD channels closer to 2 Mbps. I did this early in the morning so network congestion should not have been a factor.
I used WireShark to make the measurements.
Can anyone confirm these numbers?
Hampton Bays, NY
i would like to know what XML setting the SL player used for that bandwidth, i havent had time to "play" with this to find out though (full time job consumes time).
the debug mode for the SL player should indicate it though.
Suffolk County NY Police Feed - »www.scpdny.com
PS3 Gaming Feed - »www.livestream.com/elitedata
Looking at the capture I see a series of HTTP "Get" commands, which I believe is the ABR algorithm requesting progressive higher bit rates when I first tune the channel (in this example Yes-HD).
So the Get data looks something like:
.../ yeshd.isml/QualityLevels(857000)/Fragments(video= ...
I am guessing the "857000" is the initial video stream bit-rate of 857 kbps.
The series of Get requests have progressively increasing quality levels (OK, with a dip in the middle)
857,000 => 2,913,000 =>1,445,000=>2,913,000
There are also a series of Gets for the Audio stream, settling at 96 kbps.
So the combined audio/video rate looks to be about 3 Mbps (if I am interpreting the QualityLevels parameter correctly).
There may be a series of other video bit rates below 2,913,000 bps, but the ABR algorithm requests the ones it thinks are likely to be the best (hence the reason it jumped from 857 kbps to 2.9 Mbps, then back down to 1.4 Mbps, and finally back to 2.9 Mbps. Also if I look at the total bit rate of the capture (with no other significant network activity other than the Optimum App) I see a bit-rate around 3 Mbps.
From what I have read the ABR client requests a "Manifest" from the ABR server that includes a list of the bit-rates available, so the laptop application knows what bit-rates are available.
I believe I found the ABR manifest XML file that is sent from the network to the ABR client in the capture. The manifest indicates there are four ABR streams made available for laptop streaming. I have listed these below (these are the MP4 video streams, audio is a 96 kbps stream that would added to the numbers below)
There may be a different set of streams for the iPhone/iPads, as these applications are not MS Smooth Streaming (Silverlight) based but rather Apple HLS.
ABR Streams for Optimum App for the Laptop
Bit Rate: 0.857 Mbps [~ 1.0 Mbps with audio]
Frame Width: 480
Frame Height: 270
Bit Rate: 1.445 Mbps [~ 1.5 Mbps with audio]
Frame Width: 640
Frame Height: 360
Bit Rate: 2.0325 Mbps [~ 2.1 Mbps with audio]
Frame Width: 960
Frame Height: 540
Bit Rate: 2.913 Mbps [~ 3.0 Mbps with audio]
Frame Width: 1280
Frame Height: 720