Bug? Netstream won't resume after an inital pause then seek

Question

I'm experiencing some strange behavior for which I can't find any documented knowledge.

Here's what is happening:

After calling the play() method, a netstream is paused when the NetStatus code is "NetStream.Play.Start". This disables the default behavior of automatically playing. Before resuming with either togglePause() OR resume(), perform a seek operation. When you attempt to resume with togglePause() or resume(), the netstream will not start playing again.

If you just immediately pause() then resume() without a seek() in between, it resumes fine.

Also, if you delay the initial pause by about 250ms, you can then seek() and subsequently resume() with no problems.

I posted a demo and source here: http://drinkspiller.cannonballinteractive.com/temp/ResumeAfterPauseAndSeek/

The code is the example code directly from the AS3 docs for NetStream with minor additions to handle the initial pause and handle the seek and resume buttons. There's not much to it.

Note that I am pausing by calling stream.seek(0) then stream.pause(); This ensures the first frame shows in the Video instance instead of nothing. The same behavior occurs without stream.seek(0) and only using stream.pause() to stop playback.

I've also tried delaying the call to startPaused(); until the buffer full event code but the behavior is the same.

Can anyone help me find a sensible workaround or confirm for me that this is a bug? Many thanks!

Answer 1

There are definitely some bugs at play (and some poor documentation). But, I think there are two potential issues with your sample:

1. I don't think it's a good idea to call NetStream.seek before receiving metadata about the FLV. (Consider that duration is extracted from the metadata). I don't know if there's official documentation about that, but I've found from experience it can be problematic. You might try putting any pause/seek events in the onMetaData event handler.

   My limited understanding is that metadata is included inline with the FLV data. It can be anywhere, but ideally and usually, it's at the front of the file. So when progressively downloading, the NetStream must receive enough information to get the metadata it needs to do more advanced things with the video (like seeking). That could explain why it worked for you when putting in a 250ms pause.

2. Your sample FLV is encoded differently from other FLVs I've worked with. I'm not exactly sure why, but if I changed to reference a different FLV, everything worked great (after issue #1 was addressed that is.)

   I thought maybe your sample FLV was just missing keyframes, which are required for seeking. I tried reencoding to include keyframes and it still didn't work though. I'm not really sure what's different about that FLV, and if anyone can point that out, I'd find it very useful too.

Regarding using a seek(0) call to make sure there's a poster frame... I haven't had to do that myself. This could also be related to how FLVs are encoded though.