In general, traits are not things that we expect developers to create, since they form the core vocabulary of the system. Introducing a new trait involves a number of steps which are quite invasive to the framework (and trait can't be introduced in plugins, they need to be part of the framework). So before we would go down that path, we'd want to determine whether a problem can already be solved with the current set of traits. For fast-forwarding, because there's no explicit Flash (NetStream) API for fast-forwarding, I don't think you can gain any noticeable performance improvements over using the existing ISeekable trait. If and when Adobe adds player-level support for fast-forwarding, we would definitely consider integrating a new trait into the framework.
If I were to implement fast-forwarding, I would create a subclass of MediaPlayer which adds a new method, fastforward(). This method would set up a Timer that on some interval would call MediaPlayer.seek(), where the value passed-in is some increment over the currentTime. This would allow you to fast-forward any seekable media, not just video. (And in fact, this type of functionality we would potentially roll into MediaPlayer if it proved useful.)
Would this approach work for you?
The media player is responsable for basic function, such as play、pause. And other functions are developed by a plugin, such as seek、dynamic streaming switching、fast forward.
My opinion is like this:
1、I want to keep the original player by register a default MediaElement like VideoElement except for no seekable trait.
2、Then I creat a custom MediaElement by a plugin, which is the VideoElement having a seekable trait.
According to the above methods, it is complex and exists many repetitve operations. So I want to develop the new trait instead of creating a new MediaElement that overrides the default MediaElement.
What I want to is developing the function of seeking by a plugin. Please give me your opinion.
I'm not exactly sure why you would want to implement seeking as a plugin. Could you describe a bit more what you're trying to do (and why)? It may be that there's a better way to achieve this than what you're thinking of.
Not sure if this addresses your problem, but FYI the ExamplePlayer sample app has an example for preventing seeking, via a custom ProxyElement. Source code is here:
You can wrap any MediaElement (not just video) in this ProxyElement and seeking will be disabled/prevented.
If the new property can be developed by a plugin, there is no heavy load on the main player. What I do this is to know well the development process of the new trait.
http://analytics.anvato.com/". Its purpose is to develop the function of tracking the users' behavior in the different player by a plugin, then sending a message to the backend to process.
I want to seek to any points when the video has not completely downloaded. So I need to send a request with "http://video/car.f4v?start_time=500". The "start_time" is the point that I want to seek. I do not sure whether I can send such request.
In the circumstances, I need to develop the function of random seek by a plugin?
Can you give me some opinion?
For progressive video, this feature is not yet supported by OSMF at the client level. I understand it's possible to create a server-side script to do this (though I don't have any specific details).
For streaming video, you can specify a start time using the Subclip feature, which will be released in the upcoming sprint 8 release. For details and code snippets, see the Subclips Specification.
I am looking at the same issue as listed above, what i refer to as pseudostreaming.
I was extending the NetStreamSeekTrait and ran into a few walls doing so.
Can anyone provide me with examples of extending a trait?
if it is not intended for the traits to be extended, should the player (extending mediaplayer) handle this functionality?
Just looking for a bit of direction/feedback.
The NetStream traits (such as NetStreamSeekTrait) are not intended to be subclassed (they aren't even public per se). There may be reason for us to enable this, but I'd have to understand your use case a bit better. I would expect that you would be better off subclassing SeekTrait than NetStreamSeekTrait (i.e. that there's not much code that you can reuse from NetStreamSeekTrait). Is that accurate? Could you provide more details on what your custom SeekTrait is trying to do?
Thanks for your reply Brian,
what i am doing is looking at the est seconds loaded ((bytesTotal/duration)* bytesLoaded) and if the seek request is above that then set the file = file+offset and re-request.
This is for the pseudostreaming of an flv - I got it working to a small degree but like you said - had to break a few rules and make a few things protected to make it work.
I am now back to the drawing board to try a differrent approach - our main application subclasses the MediaPlayer and i am ovverriding the seek function there. if the time requested is larger than the est time loaded - then I am takking on the offset and resetting the VideoElement with the new url for the media player.
any suggestions would be greatly appreciated,
This sounds like a good use case for a ProxyElement that wraps the VideoElement. Your ProxyElement subclass could intercept seek requests (by providing a SeekTrait of its own) and map them to whatever makes sense (either a seek or a re-request). By doing it this way, you can isolate all of the behavior in one place (instead of in the MediaPlayer, which may be used to play other things), as well as ensure that you expose a consistent state from your ProxyElement. For example, if the seek request actually involves requesting a different URL, your ProxyElement can intercept and block any events that the VideoElement dispatches until the re-requested URL is loaded and ready, so that the MediaPlayer thinks the whole thing is a seek (and doesn't respond to any unrelated events which might put it in a different state).