The change you're referring to was in response to this bug:
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.
Thanks very much. This makes sense. I'll use the ExamplePlayer technique.
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.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?