9 Replies Latest reply on Apr 12, 2010 6:17 PM by trundell

    Progressive delivery and LoadState.READY

    trundell Level 1

      Using the OSMFPlayer project and the http://mediapm.edgesuite.net/osmf/content/test/manifest-files/progressive.f4m sample stream, I'm not seeing a LoadEvent dispatched for the READY state.  For all of the other sample streams included in that project I am seeing this event dispatched.  Additionally I can see that the state does in fact transition to READY after LOADING by polling for the state after playback has started, it just doesn't dispatch an event for whatever reason.  Is this expected and if so can anyone give me a workaround for this missing event?

        • 1. Re: Progressive delivery and LoadState.READY
          bringrags Level 4

          With F4M files, the LoadTrait that is used to do the load operation actually gets replaced by a different LoadTrait midway through the operation.  (I won't go into the details why.)  So if you need to get the READY event, you can either listen for the LoadTrait coming and going (MediaElementEvent.TRAIT_ADD and TRAIT_REMOVE), or just listen for the READY event on the MediaPlayer (since the MediaPlayer will internally keep track of traits coming and going).  I'd recommend the latter unless you can't work with MediaPlayer.

          • 2. Re: Progressive delivery and LoadState.READY
            trundell Level 1

            Not sure I agree with this assessment.

             

            1) I already have a listener for TRAIT_ADD and TRAIT_REMOVE to pick up the change in LoadTrait instances.

            2) The MediaPlayer does not seem to enter the READY state for any content until playback completes.  From the descriptions of MediaPlayerState.READY and LoadState.READY it doesn't seem like they necessarily correspond to the same thing.

             

            Additionally, I inserted some trace statements to print out when various events were fired. For the dynamic streaming F4M content I get a trace like the following...

             

            MediaElement load state change: loading

            toggling load trait: added=false

            toggling load trait: added=true

            MediaPlayer state change: playing

            MediaElement load state change: ready

             

            For the progressive F4M content I get this...

             

            MediaElement load state change: loading

            toggling load trait: added=false

            MediaPlayer state change: playing

            toggling load trait: added=true

             

            And I never get the LoadState transition to READY. From this it seems like the MediaPlayer state might transition to PLAYING before the LoadTrait is re-added to the MediaElement.

            • 3. Re: Progressive delivery and LoadState.READY
              bringrags Level 4

              Hmm, are you running the sprint 10 release or public trunk?  We've made a lot of fixes in this area in the past few weeks, so you might need the public trunk code to see the right behavior.  I just tried the following:

               

              1. Modify MainWindow.onStateChange in the ExamplePlayer app to trace out the event.state property.

              2. Run the "Flash Media Manifest Progressive" and "Flash Media Manifest Dynamic Streaming" examples.

               

               

              In both cases, the traced events are:

              loading

              ready

              buffering

              playing

              • 4. Re: Progressive delivery and LoadState.READY
                trundell Level 1

                I'm working with the sprint 10 release and the OSMFPlayer example at the moment.  I'll try the latest trunk to see if the problem still exists there.

                • 5. Re: Progressive delivery and LoadState.READY
                  trundell Level 1

                  Hey Brian,

                   

                  I tried your recommendation with the ExamplePlayer and I see the behavior you describe when listening to the MEDIA_PLAYER_STATE_CHANGE event.  Actually I the same behavior with both the sprint 10 and trunk builds so I don't think there's a difference there.

                   

                  However, I still see the same behavior as I described earlier using the OSMFPlayer sample app, which leads me to belive that the READY state from the MEDIA_PLAYER_STATE_CHANGE event is not reliable across apps.  On both apps (ExamplePlayer and OSMFPlayer) I still see that actual LoadTrait is transitioning to READY while the trait is removed from the MediaElement...

                   

                  toggling load trait: added=false

                  media player state: ready

                  toggling load trait: added=true

                   

                  Ultimately I think there are a couple bugs here that need to be adressed.  If you can point me to the class that handles the transition of the two LoadTraits for F4M content I'd be happy to do some digging myself.

                  • 6. Re: Progressive delivery and LoadState.READY
                    trundell Level 1

                    Just as a follow up, the MediaPlayer.autoPlay value seems to dictate whether or not the player actually enters the READY state.  If you set this value to true in the ExamplePlayer app you can see that state goes directly from LOADING to PLAYING.

                    • 7. Re: Progressive delivery and LoadState.READY
                      bringrags Level 4

                      I think what's happening is that we signal the capability change event last -- MediaPlayer.updateTraitListeners does that as the last operation, after it's dispatched the event which ultimately triggers the state change event.  Does the order of events here matter?  If so, can you file a bug?  Thanks!

                      • 8. Re: Progressive delivery and LoadState.READY
                        trundell Level 1

                        The order of events matters up to the point that I would expect any media element to enter the READY state immediately before playback begins, irrespective of whether or not it is set to auto play.  This seems to be true for every other type of media other than F4M with progressive stream type.

                         

                        I'll file this as a bug and move the discussion over to JIRA.

                         

                        Thanks.