Strange behaviour

On Wednesday 14 June 2006 18:09, Joachim Bauch wrote:
> Hi Bram,
>
> Bram Biesbrouck wrote:
> > Come on you guys, there must be someone who has a
clue?
>
> Sorry, I don't have an idea but as Steven is
refactoring the streaming
> code in the trunk, there might be some issues he's
currently working
> on...
>
> Please note that we all are developing Red5 in our free
time, so during
> the weekdays responses to emails could take some time!
;)

I'm sorry, honestly.
I'm working on this for over a half a year now, with no
earnings at all, and 
it takes 100% of my time, so I really know what you are
talking about. 
I'll take a look at the trunk to see it provides some
better results.
I think someone announced the next stable release soon, so
perhaps I should 
wait until then to work my way through the Java-code to
search for some 
bottlenecks myself and contribute my share.

b.

_______________________________________________
Red5 mailing list
Red5osflash.org

http://osflash.org/mailman/listinfo/red5_osflash.org

Strange you mention this, since that's exactly what my
project does, hear me 
out:

The captorials.com website is only one (major) module in the
larger 
Instrudeo-project. The project was started to bring
screen-capturing (video, 
not screenshots) into the "open-source world",
together with some 
revolutionary ideas surrounding this.

I started out with a simple vncrec program, studied the
source and optimised 
it. Created a new file format that only records the updated
pixels in the X 
frame buffer. The rectangle gets gzipped (RLE) and a special
"seekback-frame" 
is generated. This is the rectangle you need to go back to,
to rebuild the 
stream (in this way, when seeking backwards, you don't have
to re-generate 
the stream from frame zero).

The results I get from this method are very good. At least
the filesize 
(better than flv with one keyframe). Moreover: all lossless.
Because of the 
nature of the sequential file format, seeking is not always
very efficient, 
but I don't get any unacceptable seek-times when seeking
back.

Because I use VNC/RFB, there's no need to actively look for
the updated 
regions: RFB does this for me. Even better: with the fairly
new and optimized 
NX-protocol, it may even be possible to host different
environments that can 
be accessed (and proxied/recorded) on a central cluster,
serving a very large 
userbase.

Since the file-format gets converted to FLV by the
processing webservice, a 
lot of efficiency/tight filesize gets lost because of the
inserted keyframes, 
not to mention the need to use a proprietary fileformat. My
ultimate goal is 
to stream directly from my own file format, only sending the
rectangles to 
the client, add some logic in the flash-player and saving
enormous amounts of 
bandwidth. The main drawback for this is the needed ability
to seek through 
the files and the massive amounts of memory this will
require (commentboxes 
are drawn in OpenGL) when the load gets higher.

The whole philosophy of the project is to do more with
remote-computing 
and -recording; starting off with a client that records a
stream, a user that 
edits it (commentboxes, clipping, ...), a service that
receives the work, a 
machine that post-processes it (eg. automated translation),
and een website 
that publishes it. As I speak, all of this is implemented
(beta, roughly) and 
90% will be GPL'd before july (together with the
file-formats).

I'm not trying to push anything here, I just would like to
hear your comments 
on this. Perhaps trying to find some co-developers here and
there, or at 
least some curious users who want to experiment together
with me.

I'l love to hear more from you on this.

Bram

On Thursday 15 June 2006 01:47, . m a r c o s a u g u s t o
wrote:
> I think that screen sharing should not be tratated as
video.
> I m looking further for screen sharing, live primary...
>
> Correct me, but sorenson (video codecs in geral) isn't
all that good for
> it.. I mean.. it will send duplicated info anyway,
> I was thinking about:
>
>  getting the screen as a video inside the player
>  check all the pixels with 2 loops, get what is
changed, compact those
> pixels to png or jpg (inside the player 9)
> send only this changed information.. compacted as
image.. with its X, Y
> pos...
> And... least but not last, get the mouse as vetorial
information.. and
> transmit in SO too...
>
> what u guys think?
>
> another thing, vnc2swf.. something like vnc2red5...
sure vnc should be
> studied for this...
>
> but anyway.. the point is.. mouse as info from the
system, and send only
> and only changed pixels...
>
> On 6/14/06, Bram Biesbrouck <bbeligum.org> wrote:
> > On Wednesday 14 June 2006 18:09, Joachim Bauch
wrote:
> > > Hi Bram,
> > >
> > > Bram Biesbrouck wrote:
> > > > Come on you guys, there must be someone
who has a clue?
> > >
> > > Sorry, I don't have an idea but as Steven is
refactoring the streaming
> > > code in the trunk, there might be some issues
he's currently working
> > > on...
> > >
> > > Please note that we all are developing Red5
in our free time, so during
> > > the weekdays responses to emails could take
some time! ;)
> >
> > I'm sorry, honestly.
> > I'm working on this for over a half a year now,
with no earnings at all,
> > and
> > it takes 100% of my time, so I really know what
you are talking about.
> >  I'll take
a look at the trunk to see it provides some better results.
> > I think someone announced the next stable release
soon, so perhaps I
> > should
> > wait until then to work my way through the
Java-code to search for some
> > bottlenecks myself and contribute my share.
> >
> > b.
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5osflash.org
> > 
http://osflash.org/mailman/listinfo/red5_osflash.org

_______________________________________________
Red5 mailing list
Red5osflash.org

http://osflash.org/mailman/listinfo/red5_osflash.org

Interesting idea, just streaming thought rtmp the display
changes as
AMF at level of VNC protocol (if I did understand that
correctly)

On 6/14/06, Bram Biesbrouck <bbeligum.org> wrote:
> Strange you mention this, since that's exactly what my
project does, hear me
> out:
>
> The captorials.com website is only one (major) module
in the larger
> Instrudeo-project. The project was started to bring
screen-capturing (video,
> not screenshots) into the "open-source
world", together with some
> revolutionary ideas surrounding this.
>
> I started out with a simple vncrec program, studied the
source and optimised
> it. Created a new file format that only records the
updated pixels in the X
> frame buffer. The rectangle gets gzipped (RLE) and a
special "seekback-frame"
> is generated. This is the rectangle you need to go back
to, to rebuild the
> stream (in this way, when seeking backwards, you don't
have to re-generate
> the stream from frame zero).
>
> The results I get from this method are very good. At
least the filesize
> (better than flv with one keyframe). Moreover: all
lossless. Because of the
> nature of the sequential file format, seeking is not
always very efficient,
> but I don't get any unacceptable seek-times when
seeking back.
>
> Because I use VNC/RFB, there's no need to actively
look for the updated
> regions: RFB does this for me. Even better: with the
fairly new and optimized
> NX-protocol, it may even be possible to host different
environments that can
> be accessed (and proxied/recorded) on a central
cluster, serving a very large
> userbase.
>
> Since the file-format gets converted to FLV by the
processing webservice, a
> lot of efficiency/tight filesize gets lost because of
the inserted keyframes,
> not to mention the need to use a proprietary
fileformat. My ultimate goal is
> to stream directly from my own file format, only
sending the rectangles to
> the client, add some logic in the flash-player and
saving enormous amounts of
> bandwidth. The main drawback for this is the needed
ability to seek through
> the files and the massive amounts of memory this will
require (commentboxes
> are drawn in OpenGL) when the load gets higher.
>
> The whole philosophy of the project is to do more with
remote-computing
> and -recording; starting off with a client that records
a stream, a user that
> edits it (commentboxes, clipping, ...), a service that
receives the work, a
> machine that post-processes it (eg. automated
translation), and een website
> that publishes it. As I speak, all of this is
implemented (beta, roughly) and
> 90% will be GPL'd before july (together with the
file-formats).
>
> I'm not trying to push anything here, I just would
like to hear your comments
> on this. Perhaps trying to find some co-developers here
and there, or at
> least some curious users who want to experiment
together with me.
>
> I'l love to hear more from you on this.
>
> Bram
>
> On Thursday 15 June 2006 01:47, . m a r c o s a u g u s
t o wrote:
> > I think that screen sharing should not be tratated
as video.
> > I m looking further for screen sharing, live
primary...
> >
> > Correct me, but sorenson (video codecs in geral)
isn't all that good for
> > it.. I mean.. it will send duplicated info anyway,
> > I was thinking about:
> >
> >  getting the screen as a video inside the player
> >  check all the pixels with 2 loops, get what is
changed, compact those
> > pixels to png or jpg (inside the player 9)
> > send only this changed information.. compacted as
image.. with its X, Y
> > pos...
> > And... least but not last, get the mouse as
vetorial information.. and
> > transmit in SO too...
> >
> > what u guys think?
> >
> > another thing, vnc2swf.. something like
vnc2red5... sure vnc should be
> > studied for this...
> >
> > but anyway.. the point is.. mouse as info from the
system, and send only
> > and only changed pixels...
> >
> > On 6/14/06, Bram Biesbrouck <bbeligum.org> wrote:
> > > On Wednesday 14 June 2006 18:09, Joachim
Bauch wrote:
> > > > Hi Bram,
> > > >
> > > > Bram Biesbrouck wrote:
> > > > > Come on you guys, there must be
someone who has a clue?
> > > >
> > > > Sorry, I don't have an idea but as
Steven is refactoring the streaming
> > > > code in the trunk, there might be some
issues he's currently working
> > > > on...
> > > >
> > > > Please note that we all are developing
Red5 in our free time, so during
> > > > the weekdays responses to emails could
take some time! ;)
> > >
> > > I'm sorry, honestly.
> > > I'm working on this for over a half a year
now, with no earnings at all,
> > > and
> > > it takes 100% of my time, so I really know
what you are talking about.
> > >  I'll take
a look at the trunk to see it provides some better results.
> > > I think someone announced the next stable
release soon, so perhaps I
> > > should
> > > wait until then to work my way through the
Java-code to search for some
> > > bottlenecks myself and contribute my share.
> > >
> > > b.
> > >
> > >
_______________________________________________
> > > Red5 mailing list
> > > Red5osflash.org
> > > 
http://osflash.org/mailman/listinfo/red5_osflash.org
>
> _______________________________________________
> Red5 mailing list
> Red5osflash.org
> 
http://osflash.org/mailman/listinfo/red5_osflash.org
>


-- 
Roberto Saccon

_______________________________________________
Red5 mailing list
Red5osflash.org

http://osflash.org/mailman/listinfo/red5_osflash.org

On Thursday 15 June 2006 09:49, Patrick gutlich wrote:
> Just a thought,
> Darron Schall did a vnc viewer in actionscript 3
> http://www.darronschall.com/weblog/archives/000192.cfm

This is interesting, I'll look into it.

> There's a program that records vnc-streams to file:
> http://www.sodan.
org/~penny/vncrec/

vncrec is the program I started from.
I added seekbacks, OpenGL commentboxes (directly importable
from blender) and 
exporting to every video format supported by ffmpeg, plus
libflv.

> So now all we need is a vnc-server that streams these
files..
> you'd need flash player 9

That server would be fairly easy I guess.
Perhaps embedding the libinstrudeo engine in Red5 with JNI.

> But I think it would be great to see this happen.

me too 

b.

_______________________________________________
Red5 mailing list
Red5osflash.org

http://osflash.org/mailman/listinfo/red5_osflash.org