For the love of god Adobe please, please, please fix NetStream. At the very minimum make it so the NetStream.Seek.Notify event is only fired after NetStream.time has been updated.

Also–I want to sue Adobe for false advertising when it comes to h.264 seeking not being tied to keyframes. Yes there’s an index and yes Flash Player spits out a metadata event that lists those seekpoints (very cool stuff), but that index is made of times that correspond to keyframes (at least this seems to be the case with the videos created by MainConcept’s SDK that I’ve been working with. If keyframes aren’t required, please post some documentation on how to update this “index” with times you’d like to be able to seek to.
The NetStream.time seeking *BUG* leaves devs in the trenches to drum up nasty code trying to figure out what time we actually seeked to.


If you run the bit of code shown above you can see how NetStream.time is updated at some point after the seek operation has been completed.

While we’re at it, explain to me why QuickTime appears to be ABLE TO SEEK TO ANY POINT IN TIME in an h.264 file. I’m sure it boils down to some fancy explanation about Quicktime looking backward and forwards into reference frames and creating the video frame. Isn’t there a way for Flash Player to do this? Or at least duplicate the trickery that Windows Media Player uses (as described by Tinic in a comment on my blog post from 3 years ago). Give us something to avoid playhead jumpiness and the ability to seek throughout the video.
I love Flash. I love the agressive codec moves (MPEG4-AVC rules). But the devil is in the details and NetStream just hasn’t improved and that’s super frustrating.
Strange, I have been doing flash for a few years now and only until today did I get a job that needed me to make my own player. I have to say that seeking, displaying and getting info about a stream is really convoluted.
Funny I should see this post today. I really love that you can’t just add an addEventListener to get onMetaData. That sure makes my clean code go to shit.
QuickTime is also a 66 meg download so probably has a lot more libraries to deal with it
Having spent the greater part of the last 4 years rolling custom video player applications around NetStream, I can completely feel your pain. While status event behavior has appeared to be more consistent in recent iterations of the player, the solution that I’ve sometimes employed, when given the chance (whenever I have access to the interface designer prior to the client signing off on whatever I’m working on) is to remove the scrubber handle completely from the UI. Instead of clicking and dragging, the user simply clicks anywhere on the progress bar and the seek is initiated. Because there’s no display object being dragged, the nasty snap back artifact is removed. Some would argue that this removes functionality, since the action of dragging a handle back and forth affords the opportunity to “scrub” (emphasis on quotes) the video, but performance has historically been so poor when doing rapid short seek()’s, it’s not a feature I ever code in anyway.
I guess we have to start making some noise…
“Keep the feedback up though, the more noise there is about this the more chances there are we will address some of this ;-)” (Tinic Uro, 3 years ago).
Hey Brooks,
Thanks for bringing this stuff up. It may sound ridic or pandering but I actually look for well formed issues and bugs like this as it gives us a clear model of what we have to do better. So for the most part, I agree with you.
It’s worth putting a bug in to make sure that the stream time is already updated once the NetStream.Seek.Notify comes up. If you haven’t already please file a bug on this here
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform&product=16
You can file it under Flash Player, that link is for Flash Media Server, the product that I work on.
Speaking of which the messaging surrounding seeking sounds a little confused. FMS offers seeking for all codec types with iFrame precision, Progressive Flash Video does not. The docs are wrong if they indicate otherwise, and that should be corrected with a bug there too.
Feel free to contact me directly if you or anyone else you know have more ‘it sucks’ feelings on NetStream or Flash Video – they’re useful.
Asa
Flash Media Server
[...] > 3 Years Later, NetStream Still Sucks [...]
Hi there,
I recently stumbled upon this bug and entered it into the Adobe bugbase: http://bugs.adobe.com/jira/browse/FP-1705
Please vote for this to get it done in the future!
I agree. Netstream is very convoluted in its behavior, and in my opinion, its API.
I agree. Netstream has convoluted behavior and API. The jumpiness blows my mind.
[...] gibt schon eine ganze Weile eine lästige Unart des NetStream-Objekts von [...]
[...] I have many video projects where NetStream breaks, and I need to fix it. Â Additionally, I have many cool video scrubbing, pausing, and DVD like [...]
Hi there,
today the ticket was updated in the bugbase saying that an employee of Adobe is looking into this thing – finally :)
Hopefully there will be a solution soon!
http://bugs.adobe.com/jira/browse/FP-1705
Hi, NetStream is making the browser crash in 10.1…? It´s simple, the sound start, the character start to talk and keeps seeking the flv that make it open and close the mouth, the sound completes the character go to an iddle position and keep seeking the last flv where the character is blinking etc…I´ve been using this for the past 2 years without ptoblem and know it seems that when I go to frames it make the swf heavier, until it crashes…!!!
var nc:NetConnection = new NetConnection();
nc.connect(null);
var ns:NetStream = new NetStream(nc);
character.attachVideo(ns);
var my_sound:Sound = new Sound();
my_sound.onLoad = function(success:Boolean)
{
if (success)
{
ns.play(“character_going_talk.flv”);
ns.onStatus = function(info:Object)
{
trace(info.code);
if (info.code == ‘NetStream.Play.Stop’)
{
ns.play(“character_talk.flv”);
ns.onStatus = function(info:Object)
{
if(info.code==’NetStream.Play.Stop’)
{
ns.seek(0);
}
}
}
}
}
};
my_sound.onSoundComplete = function()
{
ns.play(“character_going_rest.flv”);
ns.onStatus = function(info:Object)
{
trace(info.code);
if(info.code == ‘NetStream.Play.Stop’)
{
ns.play(“character_rest.flv”);
ns.onStatus = function(info:Object)
{
if(info.code==’NetStream.Play.Stop’)
{
ns.seek(0);
}
}
}
}
};