This is a message.

Forum user: mspasov

Basic information

Registered Apr 6, 2009
Last login May 10, 2009
Forum posts 6
Direct URL http://www.flowplayer.org/forum/users/9736

Latest forum posts

Posts:

Registered:

Connection is not closed on stop, seeking opens more connections.

Posted: Apr 23, 2009

Flowplayer (3.1 and trunk r205) does not close the connection on stop and seek. I'm using it with Pseudostream and mod_h264_streaming (ver. 2.0, lighttpd 1.5), but I guess that this is valid with FLV too.

When hitting the stop button, flowplayer does not close connection and actualy continues to download content, which is realy realy pointless, since after hitting play, new connection is established.

With every seek (again mod_h264_streaming) a new connection is established, but the old one stays active. This realy wastes resources. Also - because of the throttling method mod_h264_streaming uses, lowering the max-write-idle is not an option (could lead to disconnects).

ps.
I did some hacking in NetStreamControllingStreamProvider.doStop() to force closeStreamAndConnection=true, but this does not fix (at least temporary) the problem.

Thanks.

Posts:

Registered:

Thank you for fixing this.

Posted: Apr 9, 2009

Thank you for fixing this. I have updated to head, but I'm unable to compile it. It seems HEAD is broken (or I'm missing something):


compile-lib:
     [exec] Loading configuration file /home/avatar/flex_sdk_3/frameworks/flex-config.xml
     [exec] /home/avatar/work-flowplayer-svn/flowplayer/src/actionscript/org/flowplayer/view/RotatingAnimation.as(25): col: 36 Error: Type was not found or was not a compile-time constant: BufferAnimation.
     [exec] 
     [exec]         private var _rotationImage:BufferAnimation;
     [exec]                                    ^
     [exec] 
     [exec] /home/avatar/work-flowplayer-svn/flowplayer/src/actionscript/org/flowplayer/view/RotatingAnimation.as(53): col: 34 Error: Call to a possibly undefined method BufferAnimation.
     [exec] 
     [exec]             _rotationImage = new BufferAnimation();
     [exec]                                  ^
     [exec] 
     [exec] Result: 2

I'm at r189 in core and r368 in plugins.

Posts:

Registered:

And another one..

Posted: Apr 9, 2009

Ok, here is another one. Seems to fix the rest 10% of incorrect time sync. Probably it's a border case, caused by incorrect rounding of the meta data either in flowplayer or in mod_h264_streaming..


--- PseudoStreamProvider.as 
+++ PseudoStreamProvider.as.old 
@@ -130,7 +130,7 @@
     }
 
     private function appendQueryString(url:String, start:Number):String {
-        return url + _config.queryString.replace("${start}", start == 0 ? 0 : _seekDataStore.getQueryStringStartValue(start));
+        return url + _config.queryString.replace("${start}", start == 0 ? 0 : (_seekDataStore.getQueryStringStartValue(start)+0.01));
     }
 
     override protected function onMetaData(event:ClipEvent):void {


Posts:

Registered:

Patch to fix this..

Posted: Apr 8, 2009

This fixes about 90% of the sync issues, I'll continue to dig further. It's tested only with mp4, it's possible that this breaks flv!

ps. it's my first touch with flex/as and such, I'm sure that there is more elegant and 'correct' way to do this.


Index: pseudostreaming/src/actionscript/org/flowplayer/pseudostreaming/DefaultSeekDataStore.as
===================================================================
--- pseudostreaming/src/actionscript/org/flowplayer/pseudostreaming/DefaultSeekDataStore.as	(revision 363)
+++ pseudostreaming/src/actionscript/org/flowplayer/pseudostreaming/DefaultSeekDataStore.as	(working copy)
@@ -65,7 +65,10 @@
         if (!rangeEnd) {
             rangeEnd = _keyFrameTimes.length - 1;
         }
-        if (rangeBegin == rangeEnd) return queryParamValue(rangeBegin);
+        if (rangeBegin == rangeEnd) {
+		 prevSeekTime=_keyFrameTimes[rangeBegin];
+		 return queryParamValue(rangeBegin);
+	}
 
         var rangeMid:Number = Math.floor((rangeEnd + rangeBegin)/2);
         if (_keyFrameTimes[rangeMid] >= seekPosition)

Posts:

Registered:

Related bug.

Posted: Apr 6, 2009

I think this is caused because of this bug:http://flowplayer.org/forum/8/17706

Posts:

Registered:

bug: Out of sync subtitles with mod_h264_streaming

Posted: Apr 6, 2009

Hello,

I have located a bug in pseudostreaming, that is the root all evil^H^H^H^H problems with timeline sync when scrubbing with mod_h264_streaming and pseudostreaming. After some email exchanges with the mod_h264_streaming developer we found out that the problem is somewhere in Flowplayer.

Here is my test case setup:
  • A video with overlay-ed accurate timestamp and frame numbers.
  • Subtitles with timestamp displayed every second.
  • Flowplayer 3.0.7 with flowplayer.pseudostreaming-3.1.1
  • mod_h264_streaming 2.0 with lighttpd 1.5

What I do:
I'm playing the video with the subtitles and when I scrub to time x, flowplayer.pseudostream finds the nearest keyframe x+n, and makes a request to x+n, however the time in the player stays x, and we have video playing from time x+n with drift n. Subsequent seeks makes the drift worse, usualy about 250 frames (maximum Pseudostreaming gives correct keyframe positions - x+n is at a keyframe. This is very annoying when watching closed captioned video, because subtitles are sync-ed to the x timeline.

I think the bug is trivial to fix, but hard to hit and probably causes some other problems.

Workaround (realy realy not recommended):
Until fixed, movies could be encoded with smaller max GOP size (default is 250 or around 10 sec in a 25 fps video), however this will lower the quality and enlarge the moov atom. Do this only as a last resort..

If additional information is needed, I'll be more than happy to provide it.