rtmp streams: problem with high start time and with 3.2.11 visible buffering animation (regression)

[GoogleCodeExporter]

1. regression with 3.2.11: when the buffer reaches the next stream the 
buffering animation is shortly visible. Can be observed on the plugin page 
itself:
http://flowplayer.org/plugins/streaming/rtmp.html#combining-streams

This did not happen in 3.2.7 - see this page for a comparison:
http://flowplayer.blacktrash.org/test/rtmp-streams.html

2. There is a problem in _both_ versions when the start property of the stream 
is very high. Observe the 2nd stream switch in my demo: the movie "races" for a 
split second.

Original issue reported on code.google.com by blacktrashproduct on 13 Jun 2012 at 4:44

[GoogleCodeExporter]

I just noticed this aswell

Original comment by electrot...@gmail.com on 15 Jun 2012 at 6:23

[GoogleCodeExporter]

couple of valid reasons, play.start is sent during each clip, for some reason 
within this time the clip metadata is null, so the screen is handling the 
startup animation. preventing onbegin being triggered between clips will help 
this. 

Original comment by electrot...@gmail.com on 15 Jun 2012 at 6:30

[GoogleCodeExporter]

https://dl.dropbox.com/u/3394987/flowplayer.rtmp-3.2.10.zip it will now prevent 
onbegin from being dispatching during the rtmp playlists. 

Original comment by electrot...@gmail.com on 15 Jun 2012 at 7:00

[GoogleCodeExporter]

unless there is another problem this is fixed for now ;)

Original comment by electrot...@gmail.com on 15 Jun 2012 at 7:03

• Changed state: Fixed

[GoogleCodeExporter]

If this is fixed, why hasn't the fix made it into the new release as 
flowplayer.rtmp-3.2.11 ?

Original comment by blacktrashproduct on 26 Jun 2012 at 7:21

• Changed state: Accepted

[GoogleCodeExporter]

closing , this is fixed, have to hold on release for #598

Original comment by dani...@electroteque.org on 26 Jun 2012 at 8:02

• Changed state: Fixed