3 Replies Latest reply on Aug 29, 2011 1:47 PM by buntingj

    Why does DurationElement block non-overridden traits?

    John Norstad

      In OSMF 0.95, I successfully used a DurationElement to implement a simple poster frame, using a serial composition constructed as follows:

       

       

      var posterImageEl: MediaElement =

      mediaFactory.createMediaElement(new URLResource(...));

      var durationEl: MediaElement =

      new DurationElement(0.0001, posterImageEl);

      var videoEl: VideoElement =

      VideoElement(mediaFactory.createMediaElement(new URLResource(...)));

      videoEl.defaultDuration = 31.67;

      var el: SerialElement = new SerialElement();

      el.addChild(durationEl);

      el.addChild(videoEl);

      With the media player's autoPlay property set to false, after loading, the poster image was displayed. When the player began to play, the poster image disappeared and the video played. This is the desired behavior.
      This code stopped working in OSMF 1.0. After loading, nothing is displayed. The poster image is not displayed until the player begins to play.
      I found the cause of the problem. In OSMF 1.0, the DurationElement class blocks exposure of all non-overridden traits when the element is neither playing nor paused. In particular, it blocks exposure of the display object trait until the element is played. So my poster image doesn't appear until the player begins to play.
      I was able to work around the problem by commenting out the line of code in DurationElement that blocks the display object trait. I replaced lines 250 through 259:

      private static const ALL_OTHER_TRAITS:Vector.<String> = new Vector.<String>();

      {

      // Everything but LOAD, SEEK, PLAY, and TIME.

      ALL_OTHER_TRAITS.push(MediaTraitType.AUDIO);

      ALL_OTHER_TRAITS.push(MediaTraitType.BUFFER);

      ALL_OTHER_TRAITS.push(MediaTraitType.DISPLAY_OBJECT);

      ALL_OTHER_TRAITS.push(MediaTraitType.DRM);

      ALL_OTHER_TRAITS.push(MediaTraitType.DVR);

      ALL_OTHER_TRAITS.push(MediaTraitType.DYNAMIC_STREAM);

      }

       

      with:

       

      private static const ALL_OTHER_TRAITS:Vector.<String> = new Vector.<String>();

      {

      // Everything but LOAD, SEEK, PLAY, and TIME.

      ALL_OTHER_TRAITS.push(MediaTraitType.AUDIO);

      ALL_OTHER_TRAITS.push(MediaTraitType.BUFFER);

      //ALL_OTHER_TRAITS.push(MediaTraitType.DISPLAY_OBJECT);

      ALL_OTHER_TRAITS.push(MediaTraitType.DRM);

      ALL_OTHER_TRAITS.push(MediaTraitType.DVR);

      ALL_OTHER_TRAITS.push(MediaTraitType.DYNAMIC_STREAM);

      }

      With this change, my code once again works properly, and the poster image is displayed on load.
      So my question is: In OSMF 1.0, why does DurationElement block non-overridden traits when the element is neither playing nor paused? Is my workaround likely to cause some kind of problem I'm not aware of?
      A related question:
      In the ExamplePlayer sample, there is a poster frame example that uses a class named PosterFrameElement that extends ImageElement to add a play trait, along with a class named PosterFramePlayTrait that extends PlayTrait to stop as soon as it's played. Is this the preferred way to do simple poster frames? This approach seems to be overly complicated compared to my simple (perhaps naive?) attempt to use a DurationElement.

        • 1. Re: Why does DurationElement block non-overridden traits?
          bringrags Level 4

          The change you're referring to was in response to this bug:

           

          https://bugs.adobe.com/jira/browse/FM-719

           

          Basically, prior to the fix for FM-719, the proxiedElement of the DurationElement would expose its traits even when the playhead was not within the range of the DurationElement.  This proved to be problematic if the DurationElement was placed within a SerialElement, in that the traits would be exposed even when the DurationElement wasn't the current child.  Typically this isn't a problem, but if you have a SerialElement (with a DurationElement) that's in parallel with a longer element, then the DurationElement will expose its traits even after its duration has been reached, which is unlikely to be an intended outcome.  So, your workaround would indeed fix your problem, but it might introduce problems in cases where the DurationElement is used in other (non-poster-frame) ways.

           

          The example in ExamplePlayer bypasses the whole issue of durations by mapping the display of the poster frame to the "play" operation.  In general, this is a useful pattern to use to include isolated chunks of logic that should be executed immediately (BeaconElement uses the same pattern).  I agree that it's more complicated than the direct use of a DurationElement, but it's much less fragile since it doesn't depend on timing in any way.

          • 2. Re: Why does DurationElement block non-overridden traits?
            John Norstad Level 1

            Thanks very much. This makes sense. I'll use the ExamplePlayer technique.

            • 3. Re: Why does DurationElement block non-overridden traits?
              buntingj

              I just tried out the poster frame example technique in ExamplePlayer.as, and although I see the mediaPlayer instance play, and then stop, I do not see my player display a poster frame. Code is as follows:

               

              _player = new MediaPlayerSprite();

              _serial = new SerialElement();

               

               

              _player.mediaPlayer.addEventListener(PlayEvent.PLAY_STATE_CHANGE, handleMediaStateChange)

               

              _player.mediaPlayer.autoPlay = true;

               

              _serial.addChild( new PosterFrameElement(new URLResource(_imageUrl)));

              _serial.addChild(new VideoElement(new URLResource(_videoUrl)));

               

               

              _player.media = _serial;

               

              If I set the PosterFrameElement to a DurationElement, and set the duration prop for something, the image appears correctly. I'm using the 1.5 Release version of the OSMF .swc file.

               

              Now I have noticed that inside PosterFramePlayTrait.as, there is a super() call to MediaTraitBase, which takes 1 string argument in it's constructor, but the super passes nothing. I'm assuming here that if the call to the super class' constructor is missing an argument, the trait won't fire the constructor correctly, as there is no fallback in MediaTraitBase.as.

               

              Any ideas here?