|
ns.seek problem in trunk
gents,
today I upgraded to the latest trunk (3941 I believe) and noticed substantial problems seeking through flvs (audio-only playing, video data eventually "catching up" and playing at 50x speed, or not playing at all, or prematurely reaching end of file etc.)... these were non-h264, non-recorded, very vanilla flvs. I tried with lots of them.
I browsed through the svn log and reverted to 3869, just before the "Merged with xuggle timestem branch" comment from Paul re: version 3895, and everything works perfect.
then I upgraded to 3895, got some compile errors (cannot find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine, seek problem has returned.
so not sure where along the way this error was really introduced, but 3869 works great ;)
d
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
We just recreated the same problem noted below. VP6 encoded .flv
playback. Try to seek to a place in the video and get results he
mentioned. Most of the time, ending with jumping to the end of the file.
Bill
devon girard wrote:
> gents,
>
> today I upgraded to the latest trunk (3941 I believe) and noticed
> substantial problems seeking through flvs (audio-only playing, video
> data eventually "catching up" and playing at 50x speed, or not playing
> at all, or prematurely reaching end of file etc.)... these were
> non-h264, non-recorded, very vanilla flvs. I tried with lots of them.
>
> I browsed through the svn log and reverted to 3869, just before the
> "Merged with xuggle timestem branch" comment from Paul re: version
> 3895, and everything works perfect.
>
> then I upgraded to 3895, got some compile errors (cannot find symbol
> Symbol "Abort" etc.)
>
> ditto w/ 3896 and 3901.
>
> jumped all the way to 3932, compiles fine, seek problem has returned.
>
> so not sure where along the way this error was really introduced, but
> 3869 works great ;)
>
> d
> ------------------------------------------------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org>
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
I assume this has something to do with our timestamp fixes; so we've traded seek for a/v sink apparently. Not sure how we'll address this one since Art is the expert on the timestamping.. and he's on vacation!! ugh
I'm open to suggestions...
Paul On Sat, Nov 7, 2009 at 4:14 PM, Sales Department <sales@...> wrote:
We just recreated the same problem noted below. VP6 encoded .flv playback. Try to seek to a place in the video and get results he mentioned. Most of the time, ending with jumping to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk (3941 I believe) and noticed substantial problems seeking through flvs (audio-only playing, video data eventually "catching up" and playing at 50x speed, or not playing at all, or prematurely reaching end of file etc.)... these were non-h264, non-recorded, very vanilla flvs. I tried with lots of them.
I browsed through the svn log and reverted to 3869, just before the "Merged with xuggle timestem branch" comment from Paul re: version 3895, and everything works perfect.
then I upgraded to 3895, got some compile errors (cannot find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine, seek problem has returned.
so not sure where along the way this error was really introduced, but 3869 works great ;)
d
-- http://gregoire.org/http://code.google.com/p/red5/http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
I see that no one has any idea about a fix.. :( I'm thinking that I need to adjust the timestamp coming in with the seek request based on the current streams modified timestamps? Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain <mondain@...> wrote:
I assume this has something to do with our timestamp fixes; so we've traded seek for a/v sink apparently. Not sure how we'll address this one since Art is the expert on the timestamping.. and he's on vacation!! ugh
I'm open to suggestions...
Paul On Sat, Nov 7, 2009 at 4:14 PM, Sales Department <sales@...> wrote:
We just recreated the same problem noted below. VP6 encoded .flv playback. Try to seek to a place in the video and get results he mentioned. Most of the time, ending with jumping to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk (3941 I believe) and noticed substantial problems seeking through flvs (audio-only playing, video data eventually "catching up" and playing at 50x speed, or not playing at all, or prematurely reaching end of file etc.)... these were non-h264, non-recorded, very vanilla flvs. I tried with lots of them.
I browsed through the svn log and reverted to 3869, just before the "Merged with xuggle timestem branch" comment from Paul re: version 3895, and everything works perfect.
then I upgraded to 3895, got some compile errors (cannot find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine, seek problem has returned.
so not sure where along the way this error was really introduced, but 3869 works great ;)
d
-- http://gregoire.org/http://code.google.com/p/red5/
http://code.google.com/p/blue5/
-- http://gregoire.org/http://code.google.com/p/red5/http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Sorry. We were focused on a different issue that the timestamp changes
caused. We have some relay servers that cause a chain reaction that
results in video stopping downstream. I guess the timestamp changes
cascade and the server can never catch up.
Anyway, if the seek knows how long the clip is (i assume it gets it from
the meta data) and in our case we show what time the seek is doing to
drop in at as you scrub the bar, then what you actually want to do is
make it drop in at a certain time, relative to the beginning of the
clip. When a seek request is made, does it ask for a new packet at the
desired location? If so, the server might be trying to deliver that
location based on the meta data and maybe that causes a race to the end
since it can't ever catch up? Is there a loop going on here?
Sorry for rambling. I was just working through it as I typed. I don't
know if it even made any sense.
Mondain wrote:
> I see that no one has any idea about a fix.. :( I'm thinking that I
> need to adjust the timestamp coming in with the seek request based on
> the current streams modified timestamps?
>
> Paul
>
> On Sat, Nov 7, 2009 at 6:14 PM, Mondain < mondain@...
> <mailto: mondain@...>> wrote:
>
> I assume this has something to do with our timestamp fixes; so
> we've traded seek for a/v sink apparently. Not sure how we'll
> address this one since Art is the expert on the timestamping.. and
> he's on vacation!! ugh
> I'm open to suggestions...
>
> Paul
>
>
> On Sat, Nov 7, 2009 at 4:14 PM, Sales Department
> < sales@... <mailto: sales@...>> wrote:
>
> We just recreated the same problem noted below. VP6 encoded
> .flv playback. Try to seek to a place in the video and get
> results he mentioned. Most of the time, ending with jumping
> to the end of the file.
> Bill
>
> devon girard wrote:
>
> gents,
> today I upgraded to the latest trunk (3941 I believe) and
> noticed substantial problems seeking through flvs
> (audio-only playing, video data eventually "catching up"
> and playing at 50x speed, or not playing at all, or
> prematurely reaching end of file etc.)... these were
> non-h264, non-recorded, very vanilla flvs. I tried with
> lots of them.
>
> I browsed through the svn log and reverted to 3869, just
> before the "Merged with xuggle timestem branch" comment
> from Paul re: version 3895, and everything works perfect.
>
> then I upgraded to 3895, got some compile errors (cannot
> find symbol Symbol "Abort" etc.)
>
> ditto w/ 3896 and 3901.
>
> jumped all the way to 3932, compiles fine, seek problem
> has returned.
>
> so not sure where along the way this error was really
> introduced, but 3869 works great ;)
>
> d
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> http://osflash.org/mailman/listinfo/red5_osflash.org>
>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> http://osflash.org/mailman/listinfo/red5_osflash.org>
>
>
>
> --
> http://gregoire.org/> http://code.google.com/p/red5/> http://code.google.com/p/blue5/>
>
>
>
> --
> http://gregoire.org/> http://code.google.com/p/red5/> http://code.google.com/p/blue5/> ------------------------------------------------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org>
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Ok, no worries.. got it fixed as far as I can tell in trunk r3949.
Paul On Wed, Nov 11, 2009 at 2:24 PM, Sales Department <sales@...> wrote:
Sorry. We were focused on a different issue that the timestamp changes caused. We have some relay servers that cause a chain reaction that results in video stopping downstream. I guess the timestamp changes cascade and the server can never catch up.
Anyway, if the seek knows how long the clip is (i assume it gets it from the meta data) and in our case we show what time the seek is doing to drop in at as you scrub the bar, then what you actually want to do is make it drop in at a certain time, relative to the beginning of the clip. When a seek request is made, does it ask for a new packet at the desired location? If so, the server might be trying to deliver that location based on the meta data and maybe that causes a race to the end since it can't ever catch up? Is there a loop going on here?
Sorry for rambling. I was just working through it as I typed. I don't know if it even made any sense.
Mondain wrote:
I see that no one has any idea about a fix.. :( I'm thinking that I need to adjust the timestamp coming in with the seek request based on the current streams modified timestamps?
Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain < mondain@... <mailto: mondain@...>> wrote:
I assume this has something to do with our timestamp fixes; so
we've traded seek for a/v sink apparently. Not sure how we'll
address this one since Art is the expert on the timestamping.. and
he's on vacation!! ugh
I'm open to suggestions...
Paul
On Sat, Nov 7, 2009 at 4:14 PM, Sales Department
< sales@... <mailto: sales@...>> wrote:
We just recreated the same problem noted below. VP6 encoded
.flv playback. Try to seek to a place in the video and get
results he mentioned. Most of the time, ending with jumping
to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk (3941 I believe) and
noticed substantial problems seeking through flvs
(audio-only playing, video data eventually "catching up"
and playing at 50x speed, or not playing at all, or
prematurely reaching end of file etc.)... these were
non-h264, non-recorded, very vanilla flvs. I tried with
lots of them.
I browsed through the svn log and reverted to 3869, just
before the "Merged with xuggle timestem branch" comment
from Paul re: version 3895, and everything works perfect.
then I upgraded to 3895, got some compile errors (cannot
find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine, seek problem
has returned.
so not sure where along the way this error was really
introduced, but 3869 works great ;)
d
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
-- http://gregoire.org/http://code.google.com/p/red5/http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
paul, thanks for your speedy attention!!
unfortunately, I'm still noticing erroneous behavior w/ a freshly built 3949...tested :
-- often need to ns.seek() twice before successful...or even corresponding log message in server.
-- audio + initial keyframe arrives immediately, but rest of video data doesn't arrive... until approximately the seeked-to-time has elapsed... and then arrives as a "fast forward" burst of images, after which it plays fine. for example, seeking to second 50 of the stream will queue the correct audio + 1 video frame, but rest of video takes about 50 seconds to arrive
Also, there are new logging messages (not present in 3869), not sure if its erroneous or not, but after each seek there are two very similar log messages with just slightly different time codes, from different sources:
[INFO] [NioProcessor-1] org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting clock time (1257994796056) to stream time (33033) [INFO] [pool-4-thread-1] org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting clock time (1257994796067) to stream time (33045)
I'm sorry I don't have the wherewithal to dig deeper than this at the moment... hope this report at least helps narrow it down. On Wed, Nov 11, 2009 at 4:25 PM, Mondain <mondain@...> wrote:
Ok, no worries.. got it fixed as far as I can tell in trunk r3949.
Paul
On Wed, Nov 11, 2009 at 2:24 PM, Sales Department <sales@...> wrote:
Sorry. We were focused on a different issue that the timestamp changes caused. We have some relay servers that cause a chain reaction that results in video stopping downstream. I guess the timestamp changes cascade and the server can never catch up.
Anyway, if the seek knows how long the clip is (i assume it gets it from the meta data) and in our case we show what time the seek is doing to drop in at as you scrub the bar, then what you actually want to do is make it drop in at a certain time, relative to the beginning of the clip. When a seek request is made, does it ask for a new packet at the desired location? If so, the server might be trying to deliver that location based on the meta data and maybe that causes a race to the end since it can't ever catch up? Is there a loop going on here?
Sorry for rambling. I was just working through it as I typed. I don't know if it even made any sense.
Mondain wrote:
I see that no one has any idea about a fix.. :( I'm thinking that I need to adjust the timestamp coming in with the seek request based on the current streams modified timestamps?
Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain < mondain@... <mailto: mondain@...>> wrote:
I assume this has something to do with our timestamp fixes; so
we've traded seek for a/v sink apparently. Not sure how we'll
address this one since Art is the expert on the timestamping.. and
he's on vacation!! ugh
I'm open to suggestions...
Paul
On Sat, Nov 7, 2009 at 4:14 PM, Sales Department
< sales@... <mailto: sales@...>> wrote:
We just recreated the same problem noted below. VP6 encoded
.flv playback. Try to seek to a place in the video and get
results he mentioned. Most of the time, ending with jumping
to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk (3941 I believe) and
noticed substantial problems seeking through flvs
(audio-only playing, video data eventually "catching up"
and playing at 50x speed, or not playing at all, or
prematurely reaching end of file etc.)... these were
non-h264, non-recorded, very vanilla flvs. I tried with
lots of them.
I browsed through the svn log and reverted to 3869, just
before the "Merged with xuggle timestem branch" comment
from Paul re: version 3895, and everything works perfect.
then I upgraded to 3895, got some compile errors (cannot
find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine, seek problem
has returned.
so not sure where along the way this error was really
introduced, but 3869 works great ;)
d
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
-- http://gregoire.org/http://code.google.com/p/red5/
http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Hmm odd.. The clip i used seemed to work great (9.flv) using the player4 player in the source tree so I'm at a loss. Any further fixes will probably have to wait for Art or Tiago to look at.
Paul
On Wed, Nov 11, 2009 at 7:02 PM, devon girard <dsgirard@...> wrote:
paul, thanks for your speedy attention!!
unfortunately, I'm still noticing erroneous behavior w/ a freshly built 3949...tested :
-- often need to ns.seek() twice before successful...or even corresponding log message in server.
-- audio + initial keyframe arrives immediately, but rest of video data doesn't arrive... until approximately the seeked-to-time has elapsed... and then arrives as a "fast forward" burst of images, after which it plays fine. for example, seeking to second 50 of the stream will queue the correct audio + 1 video frame, but rest of video takes about 50 seconds to arrive
Also, there are new logging messages (not present in 3869), not sure if its erroneous or not, but after each seek there are two very similar log messages with just slightly different time codes, from different sources:
[INFO] [NioProcessor-1] org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting clock time (1257994796056) to stream time (33033) [INFO] [pool-4-thread-1] org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting clock time (1257994796067) to stream time (33045)
I'm sorry I don't have the wherewithal to dig deeper than this at the moment... hope this report at least helps narrow it down.
On Wed, Nov 11, 2009 at 4:25 PM, Mondain <mondain@...> wrote:
Ok, no worries.. got it fixed as far as I can tell in trunk r3949.
Paul
On Wed, Nov 11, 2009 at 2:24 PM, Sales Department <sales@...> wrote:
Sorry. We were focused on a different issue that the timestamp changes caused. We have some relay servers that cause a chain reaction that results in video stopping downstream. I guess the timestamp changes cascade and the server can never catch up.
Anyway, if the seek knows how long the clip is (i assume it gets it from the meta data) and in our case we show what time the seek is doing to drop in at as you scrub the bar, then what you actually want to do is make it drop in at a certain time, relative to the beginning of the clip. When a seek request is made, does it ask for a new packet at the desired location? If so, the server might be trying to deliver that location based on the meta data and maybe that causes a race to the end since it can't ever catch up? Is there a loop going on here?
Sorry for rambling. I was just working through it as I typed. I don't know if it even made any sense.
Mondain wrote:
I see that no one has any idea about a fix.. :( I'm thinking that I need to adjust the timestamp coming in with the seek request based on the current streams modified timestamps?
Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain < mondain@... <mailto: mondain@...>> wrote:
I assume this has something to do with our timestamp fixes; so
we've traded seek for a/v sink apparently. Not sure how we'll
address this one since Art is the expert on the timestamping.. and
he's on vacation!! ugh
I'm open to suggestions...
Paul
On Sat, Nov 7, 2009 at 4:14 PM, Sales Department
< sales@... <mailto: sales@...>> wrote:
We just recreated the same problem noted below. VP6 encoded
.flv playback. Try to seek to a place in the video and get
results he mentioned. Most of the time, ending with jumping
to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk (3941 I believe) and
noticed substantial problems seeking through flvs
(audio-only playing, video data eventually "catching up"
and playing at 50x speed, or not playing at all, or
prematurely reaching end of file etc.)... these were
non-h264, non-recorded, very vanilla flvs. I tried with
lots of them.
I browsed through the svn log and reverted to 3869, just
before the "Merged with xuggle timestem branch" comment
from Paul re: version 3895, and everything works perfect.
then I upgraded to 3895, got some compile errors (cannot
find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine, seek problem
has returned.
so not sure where along the way this error was really
introduced, but 3869 works great ;)
d
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
-- http://gregoire.org/http://code.google.com/p/red5/
http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Just updated to latest trunk and it's improved. Thanks for the quick
efforts! Found a case where it doesn't work correctly, however.
First, if you jump to a new position by clicking on the seek bar, it
jumps correctly and starts playing from that spot. Also works if you
jump back to a previous position.
Where it breaks is when you grab the seek bar pointer and drag it to a
new location. In that case, it has the same behavior as previously
noted, running in fast forward to the end of the clip.
I'm guessing it is trying to jump to many locations along the seek line
as you drag it to the new location.
Bill.
Mondain wrote:
> Hmm odd.. The clip i used seemed to work great (9.flv) using the
> player4 player in the source tree so I'm at a loss. Any further fixes
> will probably have to wait for Art or Tiago to look at.
>
> Paul
>
> On Wed, Nov 11, 2009 at 7:02 PM, devon girard < dsgirard@...
> <mailto: dsgirard@...>> wrote:
>
> paul, thanks for your speedy attention!!
>
> unfortunately, I'm still noticing erroneous behavior w/ a freshly
> built 3949...tested :
>
> -- often need to ns.seek() twice before successful...or even
> corresponding log message in server.
> -- audio + initial keyframe arrives immediately, but rest of video
> data doesn't arrive... until approximately the seeked-to-time has
> elapsed... and then arrives as a "fast forward" burst of images,
> after which it plays fine. for example, seeking to second 50 of
> the stream will queue the correct audio + 1 video frame, but rest
> of video takes about 50 seconds to arrive
>
> Also, there are new logging messages (not present in 3869), not
> sure if its erroneous or not, but after each seek there are two
> very similar log messages with just slightly different time codes,
> from different sources:
>
> [INFO] [NioProcessor-1]
> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting
> clock time (1257994796056) to stream time (33033)
> [INFO] [pool-4-thread-1]
> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting
> clock time (1257994796067) to stream time (33045)
>
> I'm sorry I don't have the wherewithal to dig deeper than this at
> the moment... hope this report at least helps narrow it down.
>
> On Wed, Nov 11, 2009 at 4:25 PM, Mondain < mondain@...
> <mailto: mondain@...>> wrote:
>
> Ok, no worries.. got it fixed as far as I can tell in trunk
> r3949.
>
> Paul
>
>
> On Wed, Nov 11, 2009 at 2:24 PM, Sales Department
> < sales@... <mailto: sales@...>> wrote:
>
> Sorry. We were focused on a different issue that the
> timestamp changes caused. We have some relay servers that
> cause a chain reaction that results in video stopping
> downstream. I guess the timestamp changes cascade and the
> server can never catch up.
>
> Anyway, if the seek knows how long the clip is (i assume
> it gets it from the meta data) and in our case we show
> what time the seek is doing to drop in at as you scrub the
> bar, then what you actually want to do is make it drop in
> at a certain time, relative to the beginning of the clip.
> When a seek request is made, does it ask for a new packet
> at the desired location? If so, the server might be
> trying to deliver that location based on the meta data and
> maybe that causes a race to the end since it can't ever
> catch up? Is there a loop going on here?
>
> Sorry for rambling. I was just working through it as I
> typed. I don't know if it even made any sense.
>
> Mondain wrote:
>
> I see that no one has any idea about a fix.. :( I'm
> thinking that I need to adjust the timestamp coming in
> with the seek request based on the current streams
> modified timestamps?
>
> Paul
>
> On Sat, Nov 7, 2009 at 6:14 PM, Mondain
> < mondain@... <mailto: mondain@...>
> <mailto: mondain@... <mailto: mondain@...>>>
> wrote:
>
> I assume this has something to do with our
> timestamp fixes; so
> we've traded seek for a/v sink apparently. Not sure
> how we'll
> address this one since Art is the expert on the
> timestamping.. and
> he's on vacation!! ugh
> I'm open to suggestions...
>
> Paul
>
>
> On Sat, Nov 7, 2009 at 4:14 PM, Sales Department
> < sales@... <mailto: sales@...>
> <mailto: sales@...
> <mailto: sales@...>>> wrote:
>
> We just recreated the same problem noted below.
> VP6 encoded
> .flv playback. Try to seek to a place in the
> video and get
> results he mentioned. Most of the time, ending
> with jumping
> to the end of the file.
> Bill
>
> devon girard wrote:
>
> gents,
> today I upgraded to the latest trunk (3941
> I believe) and
> noticed substantial problems seeking
> through flvs
> (audio-only playing, video data eventually
> "catching up"
> and playing at 50x speed, or not playing at
> all, or
> prematurely reaching end of file etc.)...
> these were
> non-h264, non-recorded, very vanilla flvs.
> I tried with
> lots of them.
>
> I browsed through the svn log and reverted
> to 3869, just
> before the "Merged with xuggle timestem
> branch" comment
> from Paul re: version 3895, and everything
> works perfect.
>
> then I upgraded to 3895, got some compile
> errors (cannot
> find symbol Symbol "Abort" etc.)
>
> ditto w/ 3896 and 3901.
>
> jumped all the way to 3932, compiles fine,
> seek problem
> has returned.
>
> so not sure where along the way this error
> was really
> introduced, but 3869 works great ;)
>
> d
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> <mailto: Red5@... <mailto: Red5@...>>
>
>
> http://osflash.org/mailman/listinfo/red5_osflash.org>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> <mailto: Red5@... <mailto: Red5@...>>
>
>
> http://osflash.org/mailman/listinfo/red5_osflash.org>
>
>
>
> -- http://gregoire.org/> http://code.google.com/p/red5/> http://code.google.com/p/blue5/>
>
>
>
> --
> http://gregoire.org/> http://code.google.com/p/red5/> http://code.google.com/p/blue5/> ------------------------------------------------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> http://osflash.org/mailman/listinfo/red5_osflash.org>
>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> 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@... <mailto: Red5@...>
> http://osflash.org/mailman/listinfo/red5_osflash.org>
>
>
> _______________________________________________
> Red5 mailing list
> Red5@... <mailto: Red5@...>
> 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@...
> http://osflash.org/mailman/listinfo/red5_osflash.org>
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Hi, I believe it makes no sense calling "seek" continuosly while dragging the seek pointer, but it's your player implementation in my opinion what it's not doing what it should. I don't know if Red5 it's doing its job in that case, but take in account that you may be calling seek 30 times per second if you doit onEnterFrame in a 30FPS swf for instance
That way you'r calling many useless seek's since one seek becomes useless when you call the next seek which can be called after 33 milliseconds. Does it really make any sense?
2009/11/13 Sales Department <sales@...>
Just updated to latest trunk and it's improved. Thanks for the quick efforts! Found a case where it doesn't work correctly, however.
First, if you jump to a new position by clicking on the seek bar, it jumps correctly and starts playing from that spot. Also works if you jump back to a previous position.
Where it breaks is when you grab the seek bar pointer and drag it to a new location. In that case, it has the same behavior as previously noted, running in fast forward to the end of the clip.
I'm guessing it is trying to jump to many locations along the seek line as you drag it to the new location.
Bill.
Mondain wrote:
Hmm odd.. The clip i used seemed to work great (9.flv) using the player4 player in the source tree so I'm at a loss. Any further fixes will probably have to wait for Art or Tiago to look at.
Paul
On Wed, Nov 11, 2009 at 7:02 PM, devon girard <dsgirard@... <mailto:dsgirard@...>> wrote:
paul, thanks for your speedy attention!!
unfortunately, I'm still noticing erroneous behavior w/ a freshly
built 3949...tested :
-- often need to ns.seek() twice before successful...or even
corresponding log message in server. -- audio + initial keyframe arrives immediately, but rest of video
data doesn't arrive... until approximately the seeked-to-time has
elapsed... and then arrives as a "fast forward" burst of images,
after which it plays fine. for example, seeking to second 50 of
the stream will queue the correct audio + 1 video frame, but rest
of video takes about 50 seconds to arrive
Also, there are new logging messages (not present in 3869), not
sure if its erroneous or not, but after each seek there are two
very similar log messages with just slightly different time codes,
from different sources:
[INFO] [NioProcessor-1]
org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting
clock time (1257994796056) to stream time (33033)
[INFO] [pool-4-thread-1]
org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Resetting
clock time (1257994796067) to stream time (33045)
I'm sorry I don't have the wherewithal to dig deeper than this at
the moment... hope this report at least helps narrow it down.
On Wed, Nov 11, 2009 at 4:25 PM, Mondain <mondain@...
<mailto:mondain@...>> wrote:
Ok, no worries.. got it fixed as far as I can tell in trunk
r3949.
Paul
On Wed, Nov 11, 2009 at 2:24 PM, Sales Department
<sales@... <mailto:sales@...>> wrote:
Sorry. We were focused on a different issue that the
timestamp changes caused. We have some relay servers that
cause a chain reaction that results in video stopping
downstream. I guess the timestamp changes cascade and the
server can never catch up.
Anyway, if the seek knows how long the clip is (i assume
it gets it from the meta data) and in our case we show
what time the seek is doing to drop in at as you scrub the
bar, then what you actually want to do is make it drop in
at a certain time, relative to the beginning of the clip.
When a seek request is made, does it ask for a new packet
at the desired location? If so, the server might be
trying to deliver that location based on the meta data and
maybe that causes a race to the end since it can't ever
catch up? Is there a loop going on here?
Sorry for rambling. I was just working through it as I
typed. I don't know if it even made any sense.
Mondain wrote:
I see that no one has any idea about a fix.. :( I'm
thinking that I need to adjust the timestamp coming in
with the seek request based on the current streams
modified timestamps?
Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain
<mondain@... <mailto:mondain@...>
<mailto:mondain@... <mailto:mondain@...>>>
wrote:
I assume this has something to do with our
timestamp fixes; so
we've traded seek for a/v sink apparently. Not sure
how we'll
address this one since Art is the expert on the
timestamping.. and
he's on vacation!! ugh
I'm open to suggestions...
Paul
On Sat, Nov 7, 2009 at 4:14 PM, Sales Department
<sales@... <mailto:sales@...>
<mailto:sales@...
<mailto:sales@...>>> wrote:
We just recreated the same problem noted below.
VP6 encoded
.flv playback. Try to seek to a place in the
video and get
results he mentioned. Most of the time, ending
with jumping
to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk (3941
I believe) and
noticed substantial problems seeking
through flvs
(audio-only playing, video data eventually
"catching up"
and playing at 50x speed, or not playing at
all, or
prematurely reaching end of file etc.)...
these were
non-h264, non-recorded, very vanilla flvs.
I tried with
lots of them.
I browsed through the svn log and reverted
to 3869, just
before the "Merged with xuggle timestem
branch" comment
from Paul re: version 3895, and everything
works perfect.
then I upgraded to 3895, got some compile
errors (cannot
find symbol Symbol "Abort" etc.)
ditto w/ 3896 and 3901.
jumped all the way to 3932, compiles fine,
seek problem
has returned.
so not sure where along the way this error
was really
introduced, but 3869 works great ;)
d
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@... <mailto:Red5@...>
<mailto:Red5@... <mailto:Red5@...>>
Red5@... <mailto:Red5@...>
<mailto:Red5@... <mailto:Red5@...>>
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@... <mailto:Red5@...>
Red5@... <mailto:Red5@...>
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@... <mailto:Red5@...>
Red5@... <mailto:Red5@...>
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
------------------------------------------------------------------------ _______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Well a client shouldn't be allowed to break a
server's behaviour so it's good he mentioned it.
If you'd write a simple client that would
continously seek around you might (accidently) DDoS the server.
Perhaps we should ignore seek requests , on the
server , when the last one was less than xxx milliseconds ago.
W.
----- Original Message -----
Sent: Friday, 13 November 2009
11:01
Subject: Re: [Red5] ns.seek problem in
trunk
Hi,
I believe it makes no sense calling "seek"
continuosly while dragging the seek pointer, but it's your player
implementation in my opinion what it's not doing what it should.
I
don't know if Red5 it's doing its job in that case, but take in account that
you may be calling seek 30 times per second if you doit onEnterFrame in a
30FPS swf for instance
That way you'r calling many useless seek's since
one seek becomes useless when you call the next seek which can be called after
33 milliseconds.
Does it really make any sense?
2009/11/13 Sales Department <sales@...>
Just
updated to latest trunk and it's improved. Thanks for the quick
efforts! Found a case where it doesn't work correctly, however.
First, if you jump to a new position by clicking on the seek bar, it
jumps correctly and starts playing from that spot. Also works if you
jump back to a previous position.
Where it breaks is when you grab
the seek bar pointer and drag it to a new location. In that case, it
has the same behavior as previously noted, running in fast forward to the
end of the clip.
I'm guessing it is trying to jump to many locations
along the seek line as you drag it to the new
location.
Bill.
Mondain wrote:
Hmm
odd.. The clip i used seemed to work great (9.flv) using the player4
player in the source tree so I'm at a loss. Any further fixes will
probably have to wait for Art or Tiago to look at.
Paul
On
Wed, Nov 11, 2009 at 7:02 PM, devon girard <dsgirard@...
<mailto:dsgirard@...>> wrote:
paul, thanks for your speedy attention!!
unfortunately, I'm still noticing erroneous behavior w/ a
freshly
built 3949...tested :
-- often
need to ns.seek() twice before successful...or even
corresponding log message in server. -- audio + initial
keyframe arrives immediately, but rest of video
data
doesn't arrive... until approximately the seeked-to-time has
elapsed... and then arrives as a "fast forward" burst of
images,
after which it plays fine. for example, seeking to
second 50 of
the stream will queue the correct audio + 1
video frame, but rest
of video takes about 50 seconds to
arrive
Also, there are new logging messages (not
present in 3869), not
sure if its erroneous or not, but
after each seek there are two
very similar log messages
with just slightly different time codes,
from different
sources:
[INFO] [NioProcessor-1]
org.red5.server.net.rtmp.codec.RTMPProtocolEncoder -
Resetting
clock time (1257994796056) to stream time
(33033)
[INFO] [pool-4-thread-1]
org.red5.server.net.rtmp.codec.RTMPProtocolEncoder -
Resetting
clock time (1257994796067) to stream time
(33045)
I'm sorry I don't have the wherewithal to dig
deeper than this at
the moment... hope this report at
least helps narrow it down.
On Wed, Nov 11, 2009 at
4:25 PM, Mondain <mondain@...
<mailto:mondain@...>> wrote:
Ok, no worries.. got it fixed as far as I can tell in
trunk
r3949.
Paul
On Wed, Nov 11, 2009 at
2:24 PM, Sales Department
<sales@...
<mailto:sales@...>> wrote:
Sorry. We were focused on a different
issue that the
timestamp
changes caused. We have some relay servers that
cause a chain reaction that results in video
stopping
downstream. I
guess the timestamp changes cascade and the
server can never catch up.
Anyway, if the seek knows how long the clip is (i
assume
it gets it from the
meta data) and in our case we show
what time the seek is doing to drop in at as you scrub the
bar, then what you actually want to do
is make it drop in
at a
certain time, relative to the beginning of the clip.
When a seek request is made, does it ask for a
new packet
at the desired
location? If so, the server might be
trying to deliver that location based on the meta data
and
maybe that causes a race
to the end since it can't ever
catch up? Is there a loop going on here?
Sorry for rambling. I was just working
through it as I
typed. I
don't know if it even made any sense.
Mondain wrote:
I see that no one has any idea about a fix.. :(
I'm
thinking that I need to adjust the timestamp coming in
with the seek request
based on the current streams
modified timestamps?
Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain
<mondain@...
<mailto:mondain@...>
<mailto:mondain@... <mailto:mondain@...>>>
wrote:
I assume this has something to
do with our
timestamp fixes; so
we've traded seek for a/v sink apparently. Not
sure
how
we'll
address this one since Art is the expert on the
timestamping.. and
he's on vacation!!
ugh
I'm
open to suggestions...
Paul
On Sat, Nov 7, 2009 at 4:14 PM, Sales
Department
<sales@... <mailto:sales@...>
<mailto:sales@...
<mailto:sales@...>>> wrote:
We
just recreated the same problem noted below.
VP6 encoded
.flv playback.
Try to seek to a place in the
video and get
results he mentioned. Most
of the time, ending
with jumping
to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk
(3941
I believe)
and
noticed substantial problems seeking
through flvs
(audio-only playing, video data eventually
"catching up"
and playing at 50x speed, or not playing at
all, or
prematurely
reaching end of file etc.)...
these were
non-h264, non-recorded,
very vanilla flvs.
I tried with
lots of them.
I browsed through the svn log and reverted
to 3869, just
before the "Merged with xuggle timestem
branch" comment
from
Paul re: version 3895, and everything
works perfect.
then
I upgraded to 3895, got some compile
errors (cannot
find symbol Symbol
"Abort" etc.)
ditto w/ 3896 and
3901.
jumped all the way to 3932, compiles
fine,
seek
problem
has returned.
so
not sure where along the way this error
was really
introduced,
but 3869 works great ;)
d
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
<mailto:Red5@...>
<mailto:Red5@... <mailto:Red5@...>>
Red5@... <mailto:Red5@...>
<mailto:Red5@... <mailto:Red5@...>>
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
<mailto:Red5@...>
Red5@... <mailto:Red5@...>
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
<mailto:Red5@...>
Red5@... <mailto:Red5@...>
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
------------------------------------------------------------------------
_______________________________________________
Red5 mailing
list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Just so that its implemented correctly for testing, could someone send me a quick and dirty player that has the seek bar which works like Bill describes? If you want to hard-code the movie and url just use http://localhost:5080/oflaDemo and 9.flv
thanks in advance Paul On Fri, Nov 13, 2009 at 6:58 AM, Walter Tak <walter@...> wrote:
Well a client shouldn't be allowed to break a
server's behaviour so it's good he mentioned it.
If you'd write a simple client that would
continously seek around you might (accidently) DDoS the server.
Perhaps we should ignore seek requests , on the
server , when the last one was less than xxx milliseconds ago.
W.
----- Original Message -----
Sent: Friday, 13 November 2009
11:01
Subject: Re: [Red5] ns.seek problem in
trunk
Hi, I believe it makes no sense calling "seek"
continuosly while dragging the seek pointer, but it's your player
implementation in my opinion what it's not doing what it should. I
don't know if Red5 it's doing its job in that case, but take in account that
you may be calling seek 30 times per second if you doit onEnterFrame in a
30FPS swf for instance That way you'r calling many useless seek's since
one seek becomes useless when you call the next seek which can be called after
33 milliseconds. Does it really make any sense?
2009/11/13 Sales Department <sales@...>
Just
updated to latest trunk and it's improved. Thanks for the quick
efforts! Found a case where it doesn't work correctly, however.
First, if you jump to a new position by clicking on the seek bar, it
jumps correctly and starts playing from that spot. Also works if you
jump back to a previous position.
Where it breaks is when you grab
the seek bar pointer and drag it to a new location. In that case, it
has the same behavior as previously noted, running in fast forward to the
end of the clip.
I'm guessing it is trying to jump to many locations
along the seek line as you drag it to the new
location.
Bill.
Mondain wrote:
Hmm
odd.. The clip i used seemed to work great (9.flv) using the player4
player in the source tree so I'm at a loss. Any further fixes will
probably have to wait for Art or Tiago to look at.
Paul
On
Wed, Nov 11, 2009 at 7:02 PM, devon girard <dsgirard@...
<mailto:dsgirard@...>> wrote:
paul, thanks for your speedy attention!!
unfortunately, I'm still noticing erroneous behavior w/ a
freshly
built 3949...tested :
-- often
need to ns.seek() twice before successful...or even
corresponding log message in server. -- audio + initial
keyframe arrives immediately, but rest of video
data
doesn't arrive... until approximately the seeked-to-time has
elapsed... and then arrives as a "fast forward" burst of
images,
after which it plays fine. for example, seeking to
second 50 of
the stream will queue the correct audio + 1
video frame, but rest
of video takes about 50 seconds to
arrive
Also, there are new logging messages (not
present in 3869), not
sure if its erroneous or not, but
after each seek there are two
very similar log messages
with just slightly different time codes,
from different
sources:
[INFO] [NioProcessor-1]
org.red5.server.net.rtmp.codec.RTMPProtocolEncoder -
Resetting
clock time (1257994796056) to stream time
(33033)
[INFO] [pool-4-thread-1]
org.red5.server.net.rtmp.codec.RTMPProtocolEncoder -
Resetting
clock time (1257994796067) to stream time
(33045)
I'm sorry I don't have the wherewithal to dig
deeper than this at
the moment... hope this report at
least helps narrow it down.
On Wed, Nov 11, 2009 at
4:25 PM, Mondain <mondain@...
<mailto:mondain@...>> wrote:
Ok, no worries.. got it fixed as far as I can tell in
trunk
r3949.
Paul
On Wed, Nov 11, 2009 at
2:24 PM, Sales Department
<sales@...
<mailto:sales@...>> wrote:
Sorry. We were focused on a different
issue that the
timestamp
changes caused. We have some relay servers that
cause a chain reaction that results in video
stopping
downstream. I
guess the timestamp changes cascade and the
server can never catch up.
Anyway, if the seek knows how long the clip is (i
assume
it gets it from the
meta data) and in our case we show
what time the seek is doing to drop in at as you scrub the
bar, then what you actually want to do
is make it drop in
at a
certain time, relative to the beginning of the clip.
When a seek request is made, does it ask for a
new packet
at the desired
location? If so, the server might be
trying to deliver that location based on the meta data
and
maybe that causes a race
to the end since it can't ever
catch up? Is there a loop going on here?
Sorry for rambling. I was just working
through it as I
typed. I
don't know if it even made any sense.
Mondain wrote:
I see that no one has any idea about a fix.. :(
I'm
thinking that I need to adjust the timestamp coming in
with the seek request
based on the current streams
modified timestamps?
Paul
On Sat, Nov 7, 2009 at 6:14 PM, Mondain
<mondain@...
<mailto:mondain@...>
<mailto:mondain@... <mailto:mondain@...>>>
wrote:
I assume this has something to
do with our
timestamp fixes; so
we've traded seek for a/v sink apparently. Not
sure
how
we'll
address this one since Art is the expert on the
timestamping.. and
he's on vacation!!
ugh
I'm
open to suggestions...
Paul
On Sat, Nov 7, 2009 at 4:14 PM, Sales
Department
<sales@... <mailto:sales@...>
<mailto:sales@...
<mailto:sales@...>>> wrote:
We
just recreated the same problem noted below.
VP6 encoded
.flv playback.
Try to seek to a place in the
video and get
results he mentioned. Most
of the time, ending
with jumping
to the end of the file.
Bill
devon girard wrote:
gents,
today I upgraded to the latest trunk
(3941
I believe)
and
noticed substantial problems seeking
through flvs
(audio-only playing, video data eventually
"catching up"
and playing at 50x speed, or not playing at
all, or
prematurely
reaching end of file etc.)...
these were
non-h264, non-recorded,
very vanilla flvs.
I tried with
lots of them.
I browsed through the svn log and reverted
to 3869, just
before the "Merged with xuggle timestem
branch" comment
from
Paul re: version 3895, and everything
works perfect.
then
I upgraded to 3895, got some compile
errors (cannot
find symbol Symbol
"Abort" etc.)
ditto w/ 3896 and
3901.
jumped all the way to 3932, compiles
fine,
seek
problem
has returned.
so
not sure where along the way this error
was really
introduced,
but 3869 works great ;)
d
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
<mailto:Red5@...>
<mailto:Red5@... <mailto:Red5@...>>
Red5@... <mailto:Red5@...>
<mailto:Red5@... <mailto:Red5@...>>
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
<mailto:Red5@...>
Red5@... <mailto:Red5@...>
-- http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
<mailto:Red5@...>
Red5@... <mailto:Red5@...>
--
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
|
|
Re: ns.seek problem in trunk
Ours is tied too closely to a proprietary solution, so it wouldn't help
to send it. We're changing the code to just send seek when mouse goes
up. But the diagnosis was right, it was sending a seek message every
time it checked to see where in the time line it was.
Manuel Raña wrote:
> I guess Bill has one ;)
>
> 2009/11/13 Mondain < mondain@... <mailto: mondain@...>>
>
> Just so that its implemented correctly for testing, could someone
> send me a quick and dirty player that has the seek bar which works
> like Bill describes? If you want to hard-code the movie and url
> just use http://localhost:5080/oflaDemo and 9.flv
>
> thanks in advance
> Paul
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org>
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Guys, you discovered
the issue, Bill will workarround it, but let's think about other people
that will have this problem.
Anyone can please fill a bug at:
http://www.red5.org/report/8
So, on our free time, we will can take a look on open bugs, no matter
when, but we need the bugs registered on our system.
PS: Let's use the new mailing list. We will stop following this list in
some weeks.
Thanks,
Tiago
Sales Department wrote:
Ours
is tied too closely to a proprietary solution, so it wouldn't help to
send it. We're changing the code to just send seek when mouse goes
up. But the diagnosis was right, it was sending a seek message every
time it checked to see where in the time line it was.
Manuel Raña wrote:
I guess Bill has one ;)
2009/11/13 Mondain <mondain@...
mondain@...>
Just so that its implemented correctly for testing, could someone
send me a quick and dirty player that has the seek bar which works
like Bill describes? If you want to hard-code the movie and url
just use http://localhost:5080/oflaDemo and 9.flv
thanks in advance
Paul
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
 Re: ns.seek problem in trunk
hey guys, I just tried to post a simple video player + scrub bar including the compiled .swf...but the message was bounced from the list goes it was too large.
Here's a very small archive of just the source for those interested, it will have to be compiled with flex... should be very straightforward to create a new application based on these files.
On Wed, Nov 18, 2009 at 2:36 PM, devon girard <dsgirard@...> wrote:
sorry for the delay guys -- I've finally factored out the video seek code from (most of) my custom stuff, to create a very simple video player with a scrub bar.
I've attached an archive with a compiled .swf as well as the source files (flex app).
I've tested with revisions 3869 ( works as expected ) and 3949 ( errors as reported previously ).
paul (or anyone else who is testing with this), feel free to let me know if the player breaks, needs changes or if I forgot a dependency...
Also, should I be using the new mailing list for this topic? email to red5interest at googlegroups.com?
On Mon, Nov 16, 2009 at 6:17 PM, iMDT - Tiago Jacobs <tiago@...> wrote:
Guys, you discovered
the issue, Bill will workarround it, but let's think about other people
that will have this problem.
Anyone can please fill a bug at:
http://www.red5.org/report/8
So, on our free time, we will can take a look on open bugs, no matter
when, but we need the bugs registered on our system.
PS: Let's use the new mailing list. We will stop following this list in
some weeks.
Thanks,
Tiago
Sales Department wrote:
Ours
is tied too closely to a proprietary solution, so it wouldn't help to
send it. We're changing the code to just send seek when mouse goes
up. But the diagnosis was right, it was sending a seek message every
time it checked to see where in the time line it was.
Manuel Raña wrote:
I guess Bill has one ;)
2009/11/13 Mondain <mondain@...
mondain@...>
Just so that its implemented correctly for testing, could someone
send me a quick and dirty player that has the seek bar which works
like Bill describes? If you want to hard-code the movie and url
just use http://localhost:5080/oflaDemo and 9.flv
thanks in advance
Paul
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
Thanks Devon, I will check it out but be aware that this list will not be monitored much longer; please signup for the new lists.
Paul On Wed, Nov 18, 2009 at 2:41 PM, devon girard <dsgirard@...> wrote:
hey guys, I just tried to post a simple video player + scrub bar including the compiled .swf...but the message was bounced from the list goes it was too large.
Here's a very small archive of just the source for those interested, it will have to be compiled with flex... should be very straightforward to create a new application based on these files.
On Wed, Nov 18, 2009 at 2:36 PM, devon girard <dsgirard@...> wrote:
sorry for the delay guys -- I've finally factored out the video seek code from (most of) my custom stuff, to create a very simple video player with a scrub bar.
I've attached an archive with a compiled .swf as well as the source files (flex app).
I've tested with revisions 3869 ( works as expected ) and 3949 ( errors as reported previously ).
paul (or anyone else who is testing with this), feel free to let me know if the player breaks, needs changes or if I forgot a dependency...
Also, should I be using the new mailing list for this topic? email to red5interest at googlegroups.com?
On Mon, Nov 16, 2009 at 6:17 PM, iMDT - Tiago Jacobs <tiago@...> wrote:
Guys, you discovered
the issue, Bill will workarround it, but let's think about other people
that will have this problem.
Anyone can please fill a bug at:
http://www.red5.org/report/8
So, on our free time, we will can take a look on open bugs, no matter
when, but we need the bugs registered on our system.
PS: Let's use the new mailing list. We will stop following this list in
some weeks.
Thanks,
Tiago
Sales Department wrote:
Ours
is tied too closely to a proprietary solution, so it wouldn't help to
send it. We're changing the code to just send seek when mouse goes
up. But the diagnosis was right, it was sending a seek message every
time it checked to see where in the time line it was.
Manuel Raña wrote:
I guess Bill has one ;)
2009/11/13 Mondain <mondain@...
mondain@...>
Just so that its implemented correctly for testing, could someone
send me a quick and dirty player that has the seek bar which works
like Bill describes? If you want to hard-code the movie and url
just use http://localhost:5080/oflaDemo and 9.flv
thanks in advance
Paul
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: ns.seek problem in trunk
thanks Paul -- I've just signed up for the new list.
also, I mentioned in my first e-mail that didn't get through ... but I'll say again... please let me know if there are problems compiling simple_video_player, I may have forgotten to remove a dependency or some such annoyance.
On Wed, Nov 18, 2009 at 2:45 PM, Mondain <mondain@...> wrote:
Thanks Devon, I will check it out but be aware that this list will not be monitored much longer; please signup for the new lists.
Paul On Wed, Nov 18, 2009 at 2:41 PM, devon girard <dsgirard@...> wrote:
hey guys, I just tried to post a simple video player + scrub bar including the compiled .swf...but the message was bounced from the list goes it was too large.
Here's a very small archive of just the source for those interested, it will have to be compiled with flex... should be very straightforward to create a new application based on these files.
On Wed, Nov 18, 2009 at 2:36 PM, devon girard <dsgirard@...> wrote:
sorry for the delay guys -- I've finally factored out the video seek code from (most of) my custom stuff, to create a very simple video player with a scrub bar.
I've attached an archive with a compiled .swf as well as the source files (flex app).
I've tested with revisions 3869 ( works as expected ) and 3949 ( errors as reported previously ).
paul (or anyone else who is testing with this), feel free to let me know if the player breaks, needs changes or if I forgot a dependency...
Also, should I be using the new mailing list for this topic? email to red5interest at googlegroups.com?
On Mon, Nov 16, 2009 at 6:17 PM, iMDT - Tiago Jacobs <tiago@...> wrote:
Guys, you discovered
the issue, Bill will workarround it, but let's think about other people
that will have this problem.
Anyone can please fill a bug at:
http://www.red5.org/report/8
So, on our free time, we will can take a look on open bugs, no matter
when, but we need the bugs registered on our system.
PS: Let's use the new mailing list. We will stop following this list in
some weeks.
Thanks,
Tiago
Sales Department wrote:
Ours
is tied too closely to a proprietary solution, so it wouldn't help to
send it. We're changing the code to just send seek when mouse goes
up. But the diagnosis was right, it was sending a seek message every
time it checked to see where in the time line it was.
Manuel Raña wrote:
I guess Bill has one ;)
2009/11/13 Mondain <mondain@...
mondain@...>
Just so that its implemented correctly for testing, could someone
send me a quick and dirty player that has the seek bar which works
like Bill describes? If you want to hard-code the movie and url
just use http://localhost:5080/oflaDemo and 9.flv
thanks in advance
Paul
------------------------------------------------------------------------
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
simple_video_player_src.rar (14K) 