Ok, I’ve been spending some serious time with NetStream and I have to say it sucks. Here’s 5 reasons why–feel free to add more.
- Seeking only to keyframes–this totally blows and seems completely inconsistent with other video formats. I want to choose a time to seek to and be guaranteed I’ll end up at that spot.
- Seeking is super slow until all keyframes are cached. No bull, if you have a file which you’ve completely preloaded, the keyframes aren’t cached until the video playhead reaches that point in time for the first time. If I load a file and seek to the end, the player has to chug through all of the keyframes prior to my seek point. This is slow, slow if I have video of even several minutes.
- NetStream.time doesn’t update immediately when seeked. The problem here is that since you can only seek to keyframes, you have no idea where you’ll actually end up. If you want to know what time you actually seeked to you have to loop on an interval–this is the same type of asynchronous crap that makes Flash notoriously trecherous (maybe I’m overstating it, but hopefully I’m making the point). I was optomistic that the NetStream.Seek.Notify ( introduced with Flash 8 ) would provide some help, but again it appears to only tell you when a seek is complete–NetStream.time still hasn’t been updated at this point
- The NetStream.pause() toggle is, again, slower than crap. If I’m in a “pause” state and I toggle back to “play” the flv delays a little before beginning playback and this delay seems to correspond to the renderer crapping its pants. The problem here is that if I’m trying to sync an flv to a swf the two can become significantly out of sync just by toggling back and forth between play and pause.
- There’s no way to query the flv to find out if its playing our paused. Sure, you can listen for the start of file and end of file events of onStatus, but NetStream doesn’t care to give you anything in between. Yes, I can track my toggle states, but that’s ugly and gets more problematic if I’m trying to synchronize two files of disparate lengths (one gets an end of file before the other and this play state isn’t triggered by a toggle action).
Ok, now that I’ve got that off of my chest, I’d like to say I’m a huge fan of Flash video–I just want it to be better. Hopefully, someone out there is listening and these issues will be addressed in upcoming releases of the player.
6 Comments
1. Yep, but unlike what you think Windows Media does the same thing. It does better in the way that it still does play the audio until hits a key frame. We could improve this the same way. And are you talking about progressive or streaming video? For streaming video you can enable enhanced seeking support and not have this problem.
2. That depends if you use FlashCom with enhanced seeking enabled. Google Video also has a good solution using progressive video IMO, it does intelligent rebuffering.
3. What type of behavior would you expect here? Currently the time is updated as soon as a piece of audio or video is decoded and displayed on screen.
4. Are you talking about progressive or streamed video? In case of streaming the player currently does this through RTMP which might definitly not be the best solution. A good test case where this is a real issue would be interesting for us.
5. Sounds like an enhancement request. Any ideas for a good API to query this state without making it less useable than it already is? On the other hand this is the kind of stuff we tried to abstract in the Flash 8 video component.
Keep the feedback up though, the more noise there is about this the more chances there are we will address some of this ;-)
You miserable sausage. Everyone knows that Flash Video is hip. What lengths you go to spoil your own party. C’mon get with the program bud.
Sorry this isn’t a very useful post but Tinic has already laid down the smack on yo a**. b****.
This Marina girls(the names is of a girl right ?) really puts the cherry on the cake!
Holy cow, I’ve never been called a sausage before….weiner, sure, but a sausage–sounds like an upgrade.
In all seriousness I don’t think you guys are appreciating that I’m a huge advocate of Flash video–I just feel like it can and should be more than it is.
I want to munch on Tinic’s post a bit before I respond, but I’ll have more to say.
I’m with you, I’m not sure why NetStream.Seek.Notify is useful if NetStream.time hasn’t been updated. How is the seek operation really complete if Flash thinks the time you start the seek and the time the seek is complete are the same?
And let’s not forget how ridiculous it is to try to determine whether a video has finished playing, or if you do a bunch of seeks with the FLVPlayback component it pauses until it completes ALL of them. Guh.
Flash video is great, but REALLY clunky if you try to use anything to control it other than the built-in components.
Now days with the advance of digital cameras, its common to have images bigger the 2880 x 2800, and its really lame that Flash 8 dosent support them.
2 Trackbacks
[...] Ausführliche Problemskizzierung: 5 Reasons NetStream Sucks [...]
[...] I found on brooksandrus’ blog some good reasons why NetStream sucks for various factors. May be helpful on facing some problem on this More read on his article here [...]