Ignore:
Timestamp:
09/17/10 11:23:53 (4 years ago)
Author:
jeroen
Message:

fixed a bug in RTMPT error handling. Fixed a bug in HTTP continuous bitrate switching. Fixed a bug for playlist PNG rollovers without itemActive element. Added logic for hiding the image/description of playlist buttons when the button is <40px high or <240px wide. Added RST documentation on HTTP _droppedframes, HTTP DVR, RTMP DVRCast, RTMP _droppedframes, RTMP Tunneling and small playlist button element hiding.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/fl5/doc/publishers/httpstreaming.rst

    r1120 r1280  
    44==================== 
    55 
    6 Both MP4 and FLV videos can be played back with a mechanism called HTTP Pseudostreaming. This mechanism allows your viewers to seek to not-yet downloaded parts of a video. Youtube is an example site that offers this functionality. HTTP pseudostreaming is enabled by setting the :ref:`option <options>` *provider=http* in your player. 
    7  
    8 HTTP pseudostreaming combines the advantages of straight HTTP downloads (it passes any firewall, viewers on bad connections can simply wait for the download) with the ability to seek to non-downloaded parts. The only drawbacks of HTTP Pseudostreaming compared to Flash's official :ref:`rtmpstreaming` are its reduced security (HTTP is easier to sniff than RTMP) and long loading times when seeking in large videos (> 15 minutes). 
    9  
    10 HTTP Pseudostreaming should not be confused with HTTP Dynamic Streaming. The latter is a brand-new mechanism currently being developed by Adobe that works by chopping up the original video in so-called *chunks* of a few seconds each. The videoplayer seamlessly glues these chunks together again. The JW Player does **not yet** support HTTP Dynamic Streaming. 
     6Both MP4 and FLV videos can be played back with a mechanism called *HTTP Pseudostreaming*. This mechanism allows your viewers to seek to not-yet downloaded parts of a video. Youtube is an example site that offers this functionality. HTTP pseudostreaming is enabled by setting the :ref:`option <options>` *provider=http* in your player. 
     7 
     8HTTP pseudostreaming combines the advantages of straight HTTP downloads (it passes any firewall, viewers on bad connections can simply wait for the download) with the ability to seek to non-downloaded parts. The drawbacks of HTTP Pseudostreaming compared to Flash's official :ref:`rtmpstreaming` are its reduced security (HTTP is easier to sniff than RTMP) and long loading times when seeking in large videos (> 15 minutes). 
     9 
     10HTTP Pseudostreaming should not be confused with HTTP Dynamic Streaming. The latter is a brand-new mechanism solely supported by the Flash Plugin 10.1+ that works by chopping up the original video in so-called *chunks* of a few seconds each. The videoplayer seamlessly glues these chunks together again. The JW Player does **not yet** support HTTP Dynamic Streaming. 
    1111 
    1212 
     
    2121Several CDN's (Content Delivery Networks) support HTTP Pseudostreaming as well. We have done succesfull tests with `Bitgravity <http://www.bitgravity.com>`_, `CDNetworks <http://www.cdnetworks.com>`_, `Edgecast <http://www.edgecastcdn.com>`_ and `Limelight <http://llnw.com>`_. 
    2222 
    23 Instead of using a serverside module, pseudostreaming can also be enabled by using a serverside script (in e.g. PHP or .NET). We do not advise this, since such a script consumes a lot of resources, has security implications and can only be used with FLV files. A much-used serverside script for pseudostreaming is `Xmoov-PHP <http://xmoov.com/xmoov-php/>`_. 
     23In addition to using a serverside module, pseudostreaming can be enabled by using a serverside script (in e.g. PHP or .NET). We do not advise this, since such a script consumes a lot of resources, has security implications and can only be used with FLV files. A much-used serverside script for pseudostreaming is `Xmoov-PHP <http://xmoov.com/xmoov-php/>`_. 
    2424 
    2525 
     
    6464* The `H264 streaming module <http://h264.code-shop.com/trac/wiki>`_ uses *http.startparam=starttime* for MP4 videos. 
    6565* `Bitgravity <http://www.bitgravity.com>`_ uses *http.startparam=apstart* for FLV videos and *http.startparam=starttime* for MP4 videos. 
    66 * `Edgecast <http://www.edgecastcdn.com>`_ uses *http.startparam=ec_seek* for FLV videos. 
     66* `Edgecast <http://www.edgecastcdn.com>`_ uses *http.startparam=ec_seek* for both FLV and MP4 videos (presuming bytes for FLV and seconds for MP4). 
    6767* `Limelight <http://llnw.com>`_ uses *http.startparam=fs* for FLV videos. 
    6868 
     
    130130* Fits the *bandwidth* of the server » client connection. 
    131131* Fits the *width* of the player's display (or, to be precise, is not more than 20% larger). 
     132* Does not result in more than 25% of *frames dropped* at any time (for example, if your video is 30fps, a level that results in 8fps dropped will get blacklisted). 
    132133 
    133134As a viewer continues to watch the video, the player re-examines its decision (and might switch) in response to certain events: 
     
    136137* On a **fullscreen** switch, since the *width* of the display then drastically changes. For example, when a viewer goes fullscreen and has sufficient bandwidth, the player might serve an HD version of the video. 
    137138* On every **seek** in the video. Since the player has to rebuffer-the stream anyway, it takes the opportunity to also check if bandwidth conditions have not changed. 
     139* In the event where **framedrops** account for more than 25% of the frames of the video. The player continously monitors this metric (ruling out any one-time spikes). When 25% of frames are dropped, the current level is permanently blacklisted - i.e. it will not be used for the remainder of the playback session. 
    138140 
    139141Note that the player will not do a bandwidth switch if extreme bandwidth changes cause the video to re-buffer. In practice, we found such a heuristic to cause continous switching and an awful viewing experience. :ref:`rtmpstreaming` on the other hand, is able to switch seamlessly in response to bandwidth fluctuations. 
     
    163165         </media:group> 
    164166         <jwplayer:provider>http</jwplayer:provider> 
    165          <jwplayer:http.startparam>apstart</jwplayer:http.startparam> 
     167         <jwplayer:http.startparam>starttime</jwplayer:http.startparam> 
    166168       </item> 
    167169    
     
    172174 
    173175* The *bitrate* attributes must be in kbps, as defined by the `mRSS spec <http://video.search.yahoo.com/mrss>`_. The *width* attribute is in pixels. 
    174 * It is recommended to order the streams by quality, the best one at the beginning. Most RSS readers will pick this one. 
     176* It is recommended to order the streams by quality, the best one at the beginning. Most RSS readers will pick this one. The JW Player will do an internal sorting though, so the order is not important for the player. 
    175177* The four levels displayed in this feed are actually what we recommend for bitrate switching of widescreen MP4 videos. For 4:3 videos or FLV videos, you might want to increase the bitrates or decrease the dimensions a little. 
    176178* Some publishers only modify the bitrate when encoding multiple levels. The player can work with this, but modifying both the bitrate + dimensions allows for more variation between the levels (and re-use of videos, e.g. the smallest one for streaming to phones). 
    177179* The *media:group* element here is optional, but it organizes the video links a little. 
     180 
     181 
     182Live DVR Streaming 
     183------------------ 
     184 
     185The JW Player supports Live HTTP DVR streaming as offered by the `Bitgravity CDN <http://bitgravity.com>`_. This works as follows: 
     186 
     187* The player loads a stream, simply as HTTP download. The server returns a header saying the stream is 1GB+ long, so the Flash plugin will continue downloading the file.  
     188* On the server side, bytes are appended to the file as they come in from the live ingestion point. 
     189* The player will start with a duration of 0 seconds for the stream, and then simply use a timer to increase the duration of the stream. 
     190* Since HTTP video downloads are kept in memory, it is possible to seek back to the point where you began watching the live stream. All that time, the duration will continue to grow, so you'll also be able to instantly jump back to the **live** head again. 
     191 
     192Example 
     193^^^^^^^ 
     194 
     195The HTTP live DVR streaming mechanism is enabled by setting the player option **http.dvr** to *true*. Here is an example embed code, using the  :ref:`SWFObject embed method <embedding>`: 
     196 
     197.. code-block:: html 
     198 
     199   <div id='container'>The player will be placed here</div> 
     200 
     201   <script type="text/javascript"> 
     202     var flashvars = {  
     203       file:'http://bglive-a.bitgravity.com/tatamkt/testing/ld', 
     204       provider:'http', 
     205       'http.dvr':'true' 
     206     }; 
     207 
     208     swfobject.embedSWF('player.swf','container','480','270','9.0.115','false', flashvars,  
     209      {allowfullscreen:'true',allowscriptaccess:'always'}, 
     210      {id:'jwplayer',name:'jwplayer'} 
     211     ); 
     212   </script> 
     213 
Note: See TracChangeset for help on using the changeset viewer.