3 Replies Latest reply on May 26, 2010 5:04 PM by bringrags

    Seeking and Buffering events

    fallenCEO Level 1

      I have a fully loaded http video and every time I use a seek function the MediaPlayerStateChangeEvent fires off a MediaPlayerState.BUFFERING event.

       

      This confuses me a little because I don't expect any Buffering events in a fully loaded http video.

       

      Is it right for OSMF to fire these buffering events for all 'seeking' ?

       

       

       

      regards

        • 1. Re: Seeking and Buffering events
          bringrags Level 4

          This is intentional.  The "buffering" state is meant to map to the UI being inactive -- we map seek events and buffering events into that one state, so that at the UI level you don't need to check for multiple states.  (We debated this a bit, and ultimately felt that it was better to make things easy for the UI developer, rather than being overly precise with the semantic of the event/state.)

          • 2. Re: Seeking and Buffering events
            fallenCEO Level 1

            Brian, thanks for the fast response,

             

            >> to make things easy for the UI developer

             

            That's probably a good thing - I have often got into a mess with buffering events firing off in all directions leading to

            crazy UI effects.

             

            However in this case I don't want the buffering view to show when the user seeks.

             

            So how best to handle this whilst still coding to the OSMF api ?

             

            I'd like to avoid the flags and suchlike:

             

            if (seeking == false) {

            showBufferAnimation()

            }

             

            regards

            • 3. Re: Seeking and Buffering events
              bringrags Level 4

              In that case, you would need to check the seeking state to determine whether to show the animation (i.e. the approach you're hoping to avoid).  I don't see a problem with this, as the state is managed by the MediaPlayer, so it's only one additional line of code on your side.

              1 person found this helpful