[9fans] devlpt optimization

[cinap_lenrek]

I just solderd a paralel printer cable and together to get an old
canon bjc250 to work, finding that printing on plan9 was
horribly slow compared to ghostscript on linux :-(. The printer
paused up to 5 seconds after each a row. It takes minutes to print
the first page of /sys/doc/lp.ps...

I compared the plan9 code with the openbsd driver and found
that they use an optimization to make the busy waiting faster
by using a adaptive spin loop first and then reverting to
sleeping.

Hacking a similar thing in the plan9 driver makes printing
speed acceptable again for me :-)

/sys/src/9/pc/devlpt.c:

static void
outch(int base, int c)
{
int status, tries;
+   int spin;
+   static int maxspin = 0;

spin = 0;
for(tries=0;; tries++) {
status = inb(base+Qpsr);
if(status&Fnotbusy)
break;
if((status&Fpe)==0 && (status&(Fselect|Fnoerror)) != 
(Fselect|Fnoerror))
error(Eio);
+   if(++spin < maxspin)
+   continue;
+   maxspin++;
if(tries < 10)
tsleep(&lptrendez, return0, nil, 1);
else {
outb(base+Qpcr, Finitbar|Fie);
tsleep(&lptrendez, lptready, (void *)base, 100);
}
}
outb(base+Qdlr, c);
outb(base+Qpcr, Finitbar|Fstrobe);
outb(base+Qpcr, Finitbar);
+   if(spin*2 + 16 < maxspin)
+   maxspin--;
}

The static maxspin may cause problems with multiple paralel ports
or multiprocessor machines.

Another timesaver is to know that one needs set the Parport
configuration in the PC BIOS to "Normal" or "Standard"! 
Not "Bi-Directional", "EPP" or "ECP"! Then anything works as
expected. :-)

--
cinap

Re: [9fans] Flash Video

[Akshat Kumar]

2009/2/3 Skip Tavakkolian <9...@9netics.com>:
> the original question was about flash video.
>
> many here seem to have interesting ideas, but obviously
> not motivated enough to want to plan/research/read/understand.
>
> two clues: mpeg4 and rtp

Thanks, I see there are some RFCs related to RTP,
and some particularly useful tools that could help in understanding
via example, such as [1].
If you have any references to documents or applications that could
facilitate understanding or development in Plan 9, that would
be greatly appreciated.

My idea/understanding of Web 2.0 on Plan 9 has been that we
would break apart the various mediums that diverge from the
plaintext and image, such as audio and video (which is perhaps
everything), and make simple standalone tools for accessing this
data. Then, primarily one attains just text from a direct HTTP
conversation with a webserver, and the tools providing us with this
conversation give us references to the other forms of data present
on the web site, for each of which we have a corresponding tool
for access. I'm sure this is a rather obvious style as envisioned
by just about anyone who's been using Plan 9, so a flash streaming
utility seems to be the next step.


Thanks for your input,
ak


[1] http://xenion.reactive-search.com/?page_id=7

Re: [9fans] Flash Video

[Skip Tavakkolian]

the original question was about flash video.

many here seem to have interesting ideas, but obviously
not motivated enough to want to plan/research/read/understand.

two clues: mpeg4 and rtp

>> By the way, Gnash seems to be quite useful.

Re: [9fans] Flash Video

[hiro]

On Tue, Feb 3, 2009 at 10:44 PM, Eris Discordia
 wrote:
> Very interesting. Thank you.
>
> By the way, Gnash seems to be quite useful.

Well, that depends on what you call useful...

Re: [9fans] Flash Video

[Eris Discordia]

Very interesting. Thank you.

By the way, Gnash seems to be quite useful.

--On Tuesday, February 03, 2009 12:22 PM +0100 Christian Walther 
 wrote:



2009/2/3 Eris Discordia :

I don't know of any open source implementations of Flash Player. The
software on each platform and for each browser seems to be (c) Adobe and
closed source. Does an open source implementation, however incomplete,
exist?


Well, there is"gnash", which aims to be an open source flash movie
player. It relies on ffmpeg or gstreamer to decode any video.
More info can be found on http://www.gnashdev.org/





--On Tuesday, February 03, 2009 6:30 AM -0500 Pietro Gagliardi 
 wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 3, 2009, at 5:11 AM, Eris Discordia wrote:


I don't know of any open source implementations of Flash Player. The
software on each platform and for each browser seems to be (c) Adobe
and closed source. Does an open source implementation, however
incomplete, exist?


The two major ones are swfdec and Gnash, the latter part of the GNU
project. They're both at version 0.8.4, but swfdec 0.9.2 is available as
development version.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkmIKrkACgkQuv7AVNQDs+wJ+wCghd0KZynItmM56GgowKv7MxZq
XI0An03lZmRkM5PrQ1PjCY+EBlOwyRM5
=yeuI
-END PGP SIGNATURE-

[9fans] p9p page freebsd

[Markus Sonderegger]

hi,
page fails on freebsd.

# page venti.pdf
swapcontext failed: Invalid argument
Assertion failed: (0), function contextswitch, file thread.c, line 300.
874: signal: sys: abort

# gdb $PLAN9/bin/page page.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `page'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libutil.so.7...done.
Loaded symbols for /lib/libutil.so.7
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x28121d0b in thr_kill () from /lib/libc.so.7
[New Thread 0x28201200 (LWP 100147)]
[New Thread 0x28201100 (LWP 100144)]
(gdb) bt full
#0  0x28121d0b in thr_kill () from /lib/libc.so.7
No symbol table info available.
#1  0x280d55b6 in pthread_kill () from /lib/libthr.so.3
No symbol table info available.
#2  0x280d3163 in raise () from /lib/libthr.so.3
No symbol table info available.
#3  0x281b457a in abort () from /lib/libc.so.7
No symbol table info available.
#4  0x2819b9e6 in __assert () from /lib/libc.so.7
No symbol table info available.
#5  0x080611d0 in contextswitch (from=Variable "from" is not available.
) at thread.c:300
__func__ = "contextswitch"
#6  0x08061503 in procscheduler (p=0x6) at thread.c:348
t = (_Thread *) 0x280da96c
__func__ = "procscheduler"
#7  0x0805f584 in startprocfn (v=0x28258050) at pthread.c:97
fn = (void (*)(void *)) 0x80613e0 
p = (Proc *) 0x28206800
#8  0x280d0afb in pthread_getprio () from /lib/libthr.so.3
No symbol table info available.
#9  0x in ?? ()
No symbol table info available.
(gdb)

Re: [9fans] Fossil/venti performance (Was: Sources Gone?)

[erik quanstrom]

> I can't easily check before fossil is active, but venti takes a long
> time to start and by the time the machine is "ready", memory is full
> and half of swap is in use :-( During "snap -a" load, context
> switching and interrupts tend to swing wildly and swap is often being
> accessed (it's on IDE and the drive light can only mean swap access, I
> do have DMA active :-)

swapping goes nonlinear in a hurry.  how much memory do you have?

- erik

[9fans] Fossil/venti performance (Was: Sources Gone?)

[lucio]

> i would imagine that cpu has nothing to do with it and encryption
> would add no overhead at all.  i would image that seeks dominate
> your performance numbers.

Well, there are numerous issues.  The machine is a CPU server booting
off another fossil/venti host; it has its own rather pristine, mostly
unused Plan 9 distribution and a few other fossil partitions of which
only one is backed by venti.  I am hesitantly initialising the dump
partition because I'm not convinced I have the efficient direcory
hierarchy I want to live with.

I can't easily check before fossil is active, but venti takes a long
time to start and by the time the machine is "ready", memory is full
and half of swap is in use :-( During "snap -a" load, context
switching and interrupts tend to swing wildly and swap is often being
accessed (it's on IDE and the drive light can only mean swap access, I
do have DMA active :-)

So I would not use this particular configuration to win any
competitions.

In passing, the first time I did this, I powered the machine down a
few times because I was convinced it had stalled.  That might have
been pessimism on my part, because now that I am monitoring it
(stats), it is clear that it occasionally shows no sign of disk
activity (no seek, load in astronomical places) for long periods, only
to proceed again later.

But I do turn all snaptimes to none, which I superstitiously did the
first time and seemed to make a difference (I bet it didn't, but if
anyone suspects that a dump should finish before another starts, I
have the equipment to test the theory.

++L

Re: [9fans] Sources Gone?

[erik quanstrom]

> now getting rather jaded about the fact that my fresh fossil/venti
> server has taken five days, twice, to dump -a little over 1GB of data
> on two separate occasions, I'm not sure encryption is affordable.

i would imagine that cpu has nothing to do with it and encryption
would add no overhead at all.  i would image that seeks dominate
your performance numbers.

i don't think coraid could manage with such performance.  this
morning's dump is not outlandish but it is a bit bigger than
normal — 1.65gb in 8k blocks.  note that this isn't a super
i/o rate because kenfs doesn't go full-tilt boogy on dumps
and because the backup worm is across town.  but still, 
it does manage to complete in under 12 minutes.

Tue Feb  3 04:01:43: automatic dump Tue Feb  3 05:00:06 EDT 2009
Tue Feb  3 04:01:43: sync: before dump
Tue Feb  3 04:01:43: cwroot 48903076->49095891
Tue Feb  3 04:01:43: sync: after cw
Tue Feb  3 04:01:43: roroot 48903079
Tue Feb  3 04:01:43: ->49095894 /2009/0203
Tue Feb  3 04:01:43: sync: after ro
Tue Feb  3 04:01:43: sblock 48773434->48903080 (->49095895)
Tue Feb  3 04:01:43: sync: all done
Tue Feb  3 04:01:43: 217056 blocks queued for worm
Tue Feb  3 04:01:43: 0 falsehits
Tue Feb  3 04:01:43: next dump at Wed Feb  4 05:00:00 EDT 2009
Tue Feb  3 04:13:35: 217056 blocks copied to worm

- erik

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> One thing I've learned: some people will take a hit of a factor of
> 1000 in performance to preserve their concept of what is easy to use.
> Hence things like scipy. It works well for many people.

thanks for the reference.

this is an interesting problem.  most of the time a 1000x hit is
a great deal in the interest of simplicity.  the trick is finding
the problems you're willing to pay for.

to the original complaint about gnome and its ilk:
i don't see the argument against using file servers (rpc) instead
of shared libraries (creating a super-secret wormhole world).
it's not like the ftp/http transfers aren't all of the slowness,
at least to a first-order approximation.

- erik

Re: [9fans] Sources Gone?

[lucio]

> i'm not sure i understand.  either you have the key (score)
> and you can decrypt the whole cyphertext (read the file tree
> below), or you don't.  assuming of course that scores are too
> hard to guess.  so the solution is: don't give out the root score.

fossil/last will find the most recent root score.  Has somebody
already mentioned that?

++L

Re: [9fans] Sources Gone?

[lucio]

> but as i said, i'm naive when it comes to crypto; maybe
> there's no way of doing this with any decent degree
> of security or usefulness.

Encryption is always a two-way path: for every bit of piece of mind
encryption provides, there is a corresponding fear of losing access.
Also, encryption tends to slow things down and considering that I'm
now getting rather jaded about the fact that my fresh fossil/venti
server has taken five days, twice, to dump -a little over 1GB of data
on two separate occasions, I'm not sure encryption is affordable.

I think that venti should be protected, the recommended approach is to
place the fossil server and its venti archive on a separate physical
network (127.1 isn't too bad, but two hosts might be more convenient)
I'm not sure if one can do better than that.  It is unfortunate that
fossil and CPU services are very likely to occur on the same host.  In
that respect KenFS is a much nicer administrative entity.

++L

Re: [9fans] Sources Gone?

[lucio]

> venti really doesn't
> care what you store.

OK, enough agreement :-)

The issue is that to provide any level of privacy to venti is
impossible, it needs to be done at a higher layer.  I think the
original request was for sources to be replicated at the venti block
level, something that could have been done had it been set up with its
own venti "partition", but cannot be done with the current
configuration.

There were some tangential issues, but I think the fundamental issue
was that in comparison with ZFS (about which I know only that some of
my less fortunate Linux/NetBSD colleagues are very fond of it) venti
lacked the ability to provide block level security.  But I do not
recall the details and I think Roman is the one who needs to recap
this discussion and bring it to a conclusion.

++L

Re: [9fans] Sources Gone?

[Brian L. Stuart]

> information can't leak in principle, but root scores are dangerous, which
> is why open-access venti servers are problematic - if such a score
> *does* happen to leak, then unconditional access to all your data has
> also leaked.

If I understand correctly, this line of discussion
is primarily motivated by the idea of an open-access
venti server.  And it looks to me like we're basically
getting to the point where we're recognizing that
to make that happen would require some very deep
changes to venti and it's underlying concepts.  It
sounds like a perfect place for an intermediary
server.  The venti itself doesn't need to be open-
access if there's a proxy server that is.  The proxy
can communicate with the clients using any unique
identifying key.  It doesn't have to be the same as
the score the back-end venti uses.  And the proxy
can do any kind of authentication you want it to.

Maybe I'm misunderstanding the problem we're trying
to solve, but if the objective is to provide open
venti access but the necessary protection mechanisms
really belong elsewhere, it seems reasonable to
create the elsewhere and not incorporate them into
venti.

Just a free observation (and worth every penny).

BLS

Re: [9fans] Sources Gone?

[erik quanstrom]

> information can't leak in principle, but root scores are dangerous, which
> is why open-access venti servers are problematic - if such a score
> *does* happen to leak, then unconditional access to all your data has
> also leaked.

what prevents using a non-root score in a similar fashion?

- erik

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

Here's the best answer I can give, check this out:
http://www.scipy.org/

But as for introducing parallelism to cover the latency, it's an old
trick and works well. But do you want to be the one to tell people,
"you're going to have to introduce parallelism and fingernail-pulling
bugs because I want you to use RPC, not shared libraries". I'm sure
not going to do it, I've been handed my head enough times by the
programmers :-)

One thing I've learned: some people will take a hit of a factor of
1000 in performance to preserve their concept of what is easy to use.
Hence things like scipy. It works well for many people.

ron

Re: [9fans] Sources Gone?

[roger peppe]

2009/2/3 erik quanstrom :
>> to my mind, the biggest security vulnerability in venti
>> is the ability to unconditionally enumerate an entire file tree given
>> its root score. if the VtPointer data structures, or the
>> scores within them, were encrypted somehow, maybe
>> that vulnerability could be mitigated. scores would still
>> be useful, but only in conjunction with a (salted) key.
>
> i'm not sure i understand.  either you have the key (score)
> and you can decrypt the whole cyphertext (read the file tree
> below), or you don't.  assuming of course that scores are too
> hard to guess.  so the solution is: don't give out the root score.

i'm suggesting that the venti blocks containing pointers
(which are well separated, by design) could be stored encrypted.
so given a score, you can get a block out of venti
(as now), but you need the secret key in order to be able
to decrypt the scores contained within it. thus knowing a root score
without knowing the secret key does not enable browsing the entire tree.

obviously, you could do this for data blocks too, but then you
don't get any sharing at all.

> is there any other way to end up with the same pointer block
> than starting with the same data?

of course - two identical subtrees share the same pointer blocks,
but don't necessarily share the same root.

> i don't see how information could leak,

information can't leak in principle, but root scores are dangerous, which
is why open-access venti servers are problematic - if such a score
*does* happen to leak, then unconditional access to all your data has
also leaked.

i guess my proposal really just boils down to a way to be able
to write down scores in a not-entirely-secret place without
compromising everything.

> if you want users, groups and access control, isn't the fs the
> place to go?  i'm trying to see how doing fsey things at the
> venti level would be useful, but i don't see it yet.

the attraction, for me at any rate, is that certain operations are
really cheap and easy in venti, but expensive in the fs.
cloning/copying a multi-gigabyte tree being the canonical example.

Re: [9fans] Sources Gone?

[erik quanstrom]

> my read on the utility of rog's proposal is that you could then
> pre-exchange the crypto key via secure channel (real live handoff or
> whatnot) and then send root scores around freely over things like
> email. unauthorized parties reading your email then don't get your
> venti data.

if you want users, groups and access control, isn't the fs the
place to go?  i'm trying to see how doing fsey things at the
venti level would be useful, but i don't see it yet.

> the scheme has the advantage of being minimally intrusive, but it does
> seem to be like putting the fix in the wrong place. i'd rather see an
> authenticated connection mechanism, which would likely require more
> changes (how do you store accounts and credentials? how do you feed
> them to things like a fossil at boot?), but would have the same
> benefits and more (i'd like to provide some clients read-only access,
> for example).

i don't see the need for accounts or credentials (again, i think
the fs is there to provide those things).  but tls would be a good
idea if you plan on venti access across any potentially hostile
network.  you can steal scores off the wire.  i also don't see why
it wouldn't be trivial to add a venti-tls port and have venti just
push tls.

am i still missing something?

- erik

Re: [9fans] Sources Gone?

[Anthony Sorace]

erik wrote:
> i'm not sure i understand.  either you have the key (score)
> and you can decrypt the whole cyphertext (read the file tree
> below), or you don't.  assuming of course that scores are too
> hard to guess.  so the solution is: don't give out the root score.

my read on the utility of rog's proposal is that you could then
pre-exchange the crypto key via secure channel (real live handoff or
whatnot) and then send root scores around freely over things like
email. unauthorized parties reading your email then don't get your
venti data.

the scheme has the advantage of being minimally intrusive, but it does
seem to be like putting the fix in the wrong place. i'd rather see an
authenticated connection mechanism, which would likely require more
changes (how do you store accounts and credentials? how do you feed
them to things like a fossil at boot?), but would have the same
benefits and more (i'd like to provide some clients read-only access,
for example).

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> > Not obvious to me.  In today's (well, tomorrow's) massively multicore
> > world, I would expect a remote call to a process in another core, with
> > its own instruction cache, could easily be more efficient than a local
> > procedure call.
> >
> 
> well, there's remote calls and remote calls. Remote calls that go
> through some shared memory queue are one thing. But a remote call that
> goes through the kernel? You'd better have lots of work to amortize
> that cost. The packages I've seen do not.

ignorant question.

is the cost in latency or cycles?  if the cost is latency
and your application is parallel, could the simple trick
of having multple outstanding help?

- erik

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Tue, Feb 3, 2009 at 2:55 AM, Richard Miller <9f...@hamnavoe.com> wrote:

> Not obvious to me.  In today's (well, tomorrow's) massively multicore
> world, I would expect a remote call to a process in another core, with
> its own instruction cache, could easily be more efficient than a local
> procedure call.
>

well, there's remote calls and remote calls. Remote calls that go
through some shared memory queue are one thing. But a remote call that
goes through the kernel? You'd better have lots of work to amortize
that cost. The packages I've seen do not.

thanks

ron

Re: [9fans] Sources Gone?

[erik quanstrom]

> to my mind, the biggest security vulnerability in venti
> is the ability to unconditionally enumerate an entire file tree given
> its root score. if the VtPointer data structures, or the
> scores within them, were encrypted somehow, maybe
> that vulnerability could be mitigated. scores would still
> be useful, but only in conjunction with a (salted) key.

i'm not sure i understand.  either you have the key (score)
and you can decrypt the whole cyphertext (read the file tree
below), or you don't.  assuming of course that scores are too
hard to guess.  so the solution is: don't give out the root score.

(ot: you could think of a venti tree as a keyring, but that's
just nutty.)

> of course, this would mean that pointer blocks would no longer
> be shared between file trees, but it's my suspicion that
> they don't use a significant percentage of overall storage.

is there any other way to end up with the same pointer block
than starting with the same data?  conversely if either
data anywhere "below" (forgive the imprecision), pointer
blocks will change all the way up to the root and the root
will not be shared.  i don't see how information could leak,
either.

am i missing something?

- erik

Re: [9fans] Sources Gone?

[roger peppe]

in the past i've pondered, in my crypto-naive way, if it
might be possible to make venti (or at least vac) somewhat
more secure by applying some kind of crypto to the
data structures containing scores.

to my mind, the biggest security vulnerability in venti
is the ability to unconditionally enumerate an entire file tree given
its root score. if the VtPointer data structures, or the
scores within them, were encrypted somehow, maybe
that vulnerability could be mitigated. scores would still
be useful, but only in conjunction with a (salted) key.

of course, this would mean that pointer blocks would no longer
be shared between file trees, but it's my suspicion that
they don't use a significant percentage of overall storage.

this wouldn't require a change to venti itself.

but as i said, i'm naive when it comes to crypto; maybe
there's no way of doing this with any decent degree
of security or usefulness.


2009/2/3 erik quanstrom :
>> >> I'm not sure how you'd fix this.  What if only a portion of the block
>> >> belongs to me and the other happens to be the password file?
>> >
>> > venti just stores whole blocks.
>>
>> Yes, but the content isn't guaranteed to be from a single user.  In
>> fact, venti has no clue.  Change that and it's not venti anymore.
>
> exactly.  but it's important to note that it's crypto hard to guess
> somebody else's block.  since blocks are addressed by content, you
> can't share a block with someone else unless both of you stored
> the same block.  now if you are worried about libventi blocks with
> pointers to other blocks, the same logic applies.  venti really doesn't
> care what you store.
>
> - erik
>
>

Re: [9fans] Sources Gone?

[erik quanstrom]

> >> I'm not sure how you'd fix this.  What if only a portion of the block
> >> belongs to me and the other happens to be the password file? 
> > 
> > venti just stores whole blocks.
> 
> Yes, but the content isn't guaranteed to be from a single user.  In
> fact, venti has no clue.  Change that and it's not venti anymore.

exactly.  but it's important to note that it's crypto hard to guess
somebody else's block.  since blocks are addressed by content, you
can't share a block with someone else unless both of you stored
the same block.  now if you are worried about libventi blocks with
pointers to other blocks, the same logic applies.  venti really doesn't
care what you store.

- erik

Re: [9fans] Flash Video

[Pietro Gagliardi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 3, 2009, at 5:11 AM, Eris Discordia wrote:

I don't know of any open source implementations of Flash Player. The  
software on each platform and for each browser seems to be (c) Adobe  
and closed source. Does an open source implementation, however  
incomplete, exist?


The two major ones are swfdec and Gnash, the latter part of the GNU  
project. They're both at version 0.8.4, but swfdec 0.9.2 is available  
as development version.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkmIKrkACgkQuv7AVNQDs+wJ+wCghd0KZynItmM56GgowKv7MxZq
XI0An03lZmRkM5PrQ1PjCY+EBlOwyRM5
=yeuI
-END PGP SIGNATURE-

Re: [9fans] Flash Video

[Christian Walther]

2009/2/3 Eris Discordia :
> I don't know of any open source implementations of Flash Player. The
> software on each platform and for each browser seems to be (c) Adobe and
> closed source. Does an open source implementation, however incomplete,
> exist?

Well, there is"gnash", which aims to be an open source flash movie
player. It relies on ffmpeg or gstreamer to decode any video.
More info can be found on http://www.gnashdev.org/

Re: [9fans] Pegasus 2.6 is released

[Richard Miller]

> if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.
> 
> I hope the reason is obvious :-)

Not obvious to me.  In today's (well, tomorrow's) massively multicore
world, I would expect a remote call to a process in another core, with
its own instruction cache, could easily be more efficient than a local
procedure call.

Re: [9fans] Flash Video

[Eris Discordia]

I don't know of any open source implementations of Flash Player. The 
software on each platform and for each browser seems to be (c) Adobe and 
closed source. Does an open source implementation, however incomplete, 
exist?


Videos embedded in SWF files are encoded in Sorenson's MPEG-4 profile.



--On Monday, February 02, 2009 8:14 AM -0500 "Devon H. O'Dell" 
 wrote:



2009/2/2 Akshat Kumar :

2009/2/2 Skip Tavakkolian <9...@9netics.com>:

it might require a c-section.
might want to start with VLC or ffmpeg.



My aim was just to get 9fans talking about it.
Hence, the pushing.

But yes, what information can you provide
about either of those, with regards to porting
or creating natively?


The Flash file format is an open standard
(http://www.adobe.com/devnet/swf/). To be useful for encoded video,
you'd need a VP6 codec (which seems lolno) and x264. It would probably
be possible to do at least the x264 stuff via ffmpeg, which is
probably not too difficult to port -- it's pretty simple code and the
codecs are easily portable. To be useful for anything else, you'd also
need a bytecode interpreter that understood the compiled actionscript
-- it's just a bytecode-compiled ECMAScript, and I believe its details
are also found in that PDF. The rest is being able to display JPG/PNG
raster images and antialiased TTF and vectors. (Flash allows you to
embed fonts into the generated SWF output as well).

--dho


ak

Re: [9fans] Sources Gone?

[Richard Miller]

> ownership doesn't mean anything at the venti level.  it really
> is just a virtual disk drive with lba80 content addressing.

I think you mean lba160.