[Red5] NetStream.time in goes funny after seek sometimes
Andy Shaules
bowljoman at hotmail.com
Thu Jun 25 20:23:47 PDT 2009
I noticed when using StreamTracker inside
package org.red5.server.stream.consumer.ConnectionConsumer Line 133 ;
Is DOUBLING timestamp values.
This affects Streaming proxie timestamps.
Line 133 : Is there no reason that we cannot just bypass the streamtracker and change to this?
int timestamp = rtmpMsg.getBody().getTimestamp();
The headers will then all be absolute, and the job to decide to send relative or absolute packets can be done by the RTMPProtocolEncoder.
THere really seems to be a mixup serverside between event-time and chunk time.
IMHO, theoreticaly: There should not be relative frames or timestamps that do not resolve to an absolute stream time between the RTMPDecoder and RTMPEncoder.
The idea of 'delta timestamps' and relative/absolute should not exist between those two objects inside of red5.
The events come into the rtmpdecoder in chunk format, decoding absolute and delta times to produce nothing but streamtime. And then when the events are exiting red5, the Encoder can optionally construct the four types of rtmp chunks by its own algorythm.
----- Original Message -----
From: Andy Shaules
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 6:57 PM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
ok, well, dunno what else was commited but I've reproduced the issue.
I would say, what ever was done to the trunk, streaming went to pots!
SO , every one else who isnt fixing anything, REVERT to http://codegoogle.com/p/red5/source/detail?r=3671
Version 3671 Has the input stream fix I submited and everything else should work just as before.
After that version... well, yeah, something has gone very wrong.
----- Original Message -----
From: Mondain
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 2:23 PM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
Cant look at the moment but I think one of them is the Channel class, then there are the RTMPEncoder and RTMPDecoder classes.
Paul
On Thu, Jun 25, 2009 at 2:16 PM, Andy Shaules <bowljoman at hotmail.com> wrote:
SO, now the questions is......
Which class encodes the messages into rtmp chunks?
And whats the name of the method that negotiates whether to send a type 0,1,2, or 3 CHUNK?
Paul?
----- Original Message -----
From: Andy Shaules
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 2:02 PM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
GO PAUL!
IMHO, there is no reason the ConnectionConsumer needs to edit the timestamps at all. They should be set by the pusher. There is also no check on the packet-relative when doing the math that is there.
I recommend to remove those edits.
Why would you push a message with a given timestamp, only to have connectionConsumer subtract the previous value?
The Object that constructs messages from scratch is the only one responsible for 'calculating' accurate timestamps. The rest should just pass-through values given.
Excepting in the case where multiple streams are glued together as one, the epoch of the 'splice' needs to be added to future values.
----- Original Message -----
From: Andy Shaules
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 1:38 PM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
ok, it seems connection consumer , which is the math guy for streaming proxie may have some error.
Lookin at it now
----- Original Message -----
From: Andy Shaules
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 1:23 PM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
1) A negative seek , an rtmp chunk with absolute time MUST be sent , and the rtmp chunk time reduced by seek delta or more precisely, the actual delta of the tag seeked to.
----- Original Message -----
From: Michael H.
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 12:53 PM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
1) Just tested this one out, and no, it doesn't.
2) There wasn't any time processing being done.
Andy Shaules wrote:
1) sounds like rtmp chunks continuing to advance during negative seek. Does the problem occure if the seeks are only in the positive direction?
To Paul, Which class handles the playback/seek? I'll happily look at the math.
2) Ive not experienced the streaming proxie issue post jitter fix. Have you removed any time processing if there was any before?
To Paul, Which class handles the math using BaseRtmpClient which the streaming proxie extends?
----- Original Message -----
From: Mondain
To: red5 at osflash.org
Sent: Thursday, June 25, 2009 11:53 AM
Subject: Re: [Red5] NetStream.time in goes funny after seek sometimes
I've noticed these issues as well, I'm looking for community assistance to help fix them. :)
Paul
On Thu, Jun 25, 2009 at 11:38 AM, Michael H. <bigdaddyexlax at gmail.com> wrote:
Since the incredibly helpful Mr. Auge posted his fix to the Mina 2.0 problem yesterday, I have been munging about with versions later than 8rc2. However, I have come across a coule of show-stoppers past r3670:
1) Past r3670, NetStream.time is sometimes increasing with every seek until it is well past the duration of the video. This buggers up the seekbar and may be causing onPlayStatus to fire multiple times (although I can't be sure about that one)
2) The jittery video fix included in r3671 seems fine for playing files, but live video seems to go completely haywire. This may be because I am using StreamingProxy to redistribute a single video stream to multiple locations.
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflashorg
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
--------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
----------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
--------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
----------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
----------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
------------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090625/893e8593/attachment-0001.html>
More information about the Red5
mailing list