SerialElement is intended for concatenating media so that to the end user, it appears as a single piece of media (e.g. the first half of a video, a mid-roll ad, then the second half of the video). It's not intended for playlist support, which it sounds like is what you're looking for. (See this thread for some additional details on why.)
Right now, OSMF has no explicit support for creating playlists, you'd have to create multiple distinct MediaElements and manage the transition from one to the other yourself. Playlist support, however, is on our roadmap, and we'd like to hear any specific use cases you think a framework like OSMF should solve (and which aspects of playlists you would expect to be left up to the player developer).
I've read through the forum link ("SerialElement access") and I understand the importance you place on packaging additional information inside metadata, but I really don't understand OSMF's insistence on not allowing access to the current item of an SerialElement. I don't see how providing read-only access is such a bad thing. I don't think I'm going to win this battle with you, but this approach seems a little rigid. I want the ability to build with my own use-cases, even if they go against OSMF best practices.
The way I will program data that's going into any of the elements and metadata, is probably going to come from a value object class I've created and placed inside an array.
VideoElement(new NetLoader,new URLResource(new URL( myArray.videoUrl ));
facet1.addValue(new ObjectIdentifier("myKey"), myArray.value1 );
Could I place the whole value object inside the metadata? Does this break any metadata rules?
facet1.addValue(new ObjectIdentifier("myKey"), myArray );
So, to sum up, just by allowing us access to something like listenedChildIndex, I could choose to
either go the metadata route or have a number to directly access my array. My goal is not necessarily to
create a playlist, I just want timely access to my array data.
As for the request for playlist suggestions, I would love to participate, maybe you could start a specific discussion with some of the OSMF programmer thoughts, just to get us going.
Thanks for listening
We absolutely want to avoid clients having to (or thinking they have to) cast a MediaElement to SerialElement in order to access additional functionality. But we also absolutely don't want to limit the usefulness of SerialElement as a building block. All of the MediaElement subclasses are designed for extensibility, and you (and others) make a good point that the inability to access the current child is a limitation that may be inappropriate to impose on those who want to change the behavior, but not necessarily the API, of SerialElement. So one possible compromise would be for us to expose the currentChild (which maps to listenedChildIndex) as a protected getter on SerialElement (and perhaps a method that tells you when it changes). This would allow you to subclass SerialElement, and within the implementation of your subclass decide whether to use metadata (i.e. if you want to expose the info to clients) or work with individual child elements (if you don't).
Would this approach work for you? Do you see any downsides? If yes and no, please file a bug.
Thank you and the team for considering this addition, so later in the build cycle.
Adding a protected getter currentChild on SerialElement and some form of change method would work for me.
getChildAt how has a working buddy
I assume the change method would work while doing a seek.
I really don't see any downside, unless there are issues with ParallelElements.
How would this work with 2 or 3 SerialElements inside a ParallelElement?
I filed this change request to the bug base: FM-333 "protected getter on SerialElement"
Yeah! This makes me happy. I ended up creating my own custom SerialElement class (due to the private access when trying to extend the class), which I mentioned in the other thread. This will be very helpful. When using my custom class, scrubbing the player does change the index, so I'm pretty sure it will work across the board. I'm also pleased to hear that the updating of the metadata will be fixed as well.
So is FM-333 implemented in Sprint 10 or will it be Sprint 11?
The bug base still shows it unresolved.
I don't want it to fall through the cracks.
It's on our list for Sprint 11.
This is actually a feature very much needed, an EventHandler that dispatches the current index of the serialElement currently on display.
This has been fixed in the v0.95 release. See SerialElement.currentChild and currentChildChange.