| II Site Design Gmail 2005-08-26, 2:45 am |
| I think the polling, chat and other interactive thingies are great but is=
n't=20
that what Breeze is for?
At Macromedia I am constantly being told that Flash Com Server is for Fla=
sh=20
Video (though I am referred to a partner CDN for deployment).
I think that if people want to hook their little webcams up, develop some=
=20
polls and Q&A for a short business conference that is fine, use Breeze. B=
ut=20
for those of us who are looking for a cross-platform, cross-browser solut=
ion=20
to streaming dv quality video on the web, shouldn't Flash Com Server be o=
ur=20
answer? Where is your emphasis placed, on video or interactivity?
If we are looking for more interactivity and less dependent on video than=
I=20
would guess that is what Breeze was developed for. However, if we are=20
looking for a video streaming solution and less dependent on interactivit=
y,=20
is that not what FCS was developed for? If so, then why is the bandwidth=20
limit so small (10 mbps) but the connectivity so great (2,500)?
Yes, interactivity is great and it could distinguish FCS from other video=
=20
streaming servers, but if we are limited so much by how much bandwidth we=
=20
can consume, FCS is relegated to a scaled down version of Breeze and noth=
ing=20
more.
Please, Dave, Kevin, Stefan, Simon, Bill, someone, what is FCS for? Why w=
as=20
I given a shirt at the NAB 2004 conference that says "Question the=20
Rectangle"?
P.S. Dave, sorry for highjacking your thread. I hope that we can reply to=
=20
one another back and forth without really interupting your initial inquir=
y.
-Aaron
----- Original Message -----=20
From: "Kevin Day" <toasty-A9G4PF0S4yWzR313v1King@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Thursday, August 25, 2005 2:16 AM
Subject: Re: [FlashComm] What FlashCom features do you=20
wantinafutureversionofFlash?
On Aug 25, 2005, at 2:35 AM, Simon Skr=F8dal wrote:
> I agree that the pricing is ridicolous - it might not have been so bad=
a=20
> few
> years ago, but today 'everyone' is on broadband, and video is being=20
> pushed
> more and more on the net.
>
> We use FCS on a smaller scale, but are still challenged with the=20
> licensing.
> Hopefully MM will lift some restrictions soon, though...
>
> I don't agree with some of your points regarding AS and server-side
> functionality. While I am sure you might be able to do similar stuff (=
for
> video) on other streaming servers, I don't believe they are as easy to
> develop as on the FCS, and of course, FCS offers more than just video
> streaming... (I'd like to see a Real conferencing application using SM=
IL
> that compares to what you can build with Flash).
>
I don't disagree that FCS has some positives. Being able to easily
build cross-platform players is handy. AS isn't a bad language overall.
But, I question the cross-platform player necessity these days when
there are products like Real's Universal server that can stream in
multiple formats at once, or that both Real and Apple have improved
their practices with their players to a point that most people won't
avoid them anymore.
FCS also has some really strong negatives that nearly cancel out it's
positives.
There's no debugger at all other than spitting out trace statements.
FCS can't recompress streams or transcode them in any way. If I want
dialup users to be able to watch a live stream, everybody watches a
dialup quality stream.
There's no development environment other than sticking .as files on
the server.
It has no I/O with the outside world at all other than HTTP RPC.
FCS can't execute local processes, call functions written in other
languages, or even read from a local file.
FCS can't export streams to any other format, nor do any scriptable
tools have any way of converting them.
The only protocol supported by FCS is RTMP for streaming. RTMP isn't
documented.
You cannot export still frames from recorded streams.
The server can only seek or play/pause. You can't do a simulated fast-
forward/rewind by skipping everything but keyframes and sending as
fast as possible like other players can.
Replication works great for live streams, not so great for recorded
streams.
Lemme explain how our development cycle went with FCS.
"Yay! We can do cross platform players and encoders/broadcasters!"
+10000 points
"Holy crap! Look at the license pricing!" -5000 points
Macromedia Sales: "Don't worry, it's EITHER 2500 clients or 10mbps.
The limit only takes effect if you exceed both!" +5000 points (This
was said to me on two occasions)
We start recreating a product that we already have written both using
Quicktime and Helix.
"Ugh, it takes at least twice the bandwidth to have live streams look
as good as they do on QT or Helix" -500 points
"Where's the debugger for writing server code?" -500 points
"You mean there's no way to have the server export still frames,
convert the flv to anything else, or edit the recorded FLV in any way
at all?" -500 points
"I can't read or write local files, access a database, or do anything
without making RPC calls to an application server to do everything?
Why are we putting logic on the FCS at all then?" -1000 points
"We need to buy a license just to do development. No, the developer
version won't work for testing, we use more bandwidth with two
clients than it allows." -1000 points
"The server runs out of CPU at about half as many megabits as our
quicktime and helix versions" -1000 points (need to buy an extra server)
"Oh, we can't support multiple bitrates of the same live stream
unless the client publishing the stream sends multiple bitrates."
-1000 points
"We can't work around that last problem because even though we can
sorta parse the FLV using ffmpeg, the audio codec is proprietary and
we can't read that no matter what." -500 points
"Even if we ignore the audio, anything we do to change an flv
externally isn't seen by the server anyway. Won't work at all for
live stuff." -500 points
"Asking the server to send less frames per second to help users on
slower connections doesn't work as advertised." -500 points
"Beta users complain that the stream is much more likely to stutter
or get interrupted than the existing QT/Helix versions, even at the
same bit rate" -500 points
Decide that even though it's got major features missing that QT/Helix
would allow us to do, and development took several times longer than
developing the Helix and QT versions, we might as well launch it to
see how it goes with real usage.
Macromedia Sales: "I don't know where you heard that about the
licensing. It's $4500 per 10mbps you want to stream, or $7000 for
unlimited use for 90 days!" -eleventy-billion points.
Look on everyone's face at the meeting where our 3-year cost
projection for using FCS was 14 times more expensive than the next
most expensive choice, as well as using twice as much bandwidth
needing a second server and more RAM per server? Don't ask. 
We did end up buying a few 10mbps licenses and are using FCS in a
very limited fashion. We could deal with the shortcomings if we had
to, but not the price.
Simon:
If you're talking about non-streaming related services - do you need
FCS at all for it? We're doing multi-room several-hundred person chat
systems just over XMLSockets to a mini server we wrote. When you're
already having to put database access, logging, authentication and
everything else in a different language on a different server, taking
the next step to just have Flash talk directly to that server is
pretty small.
Server-side shared objects are cool, but we haven't found anything
that NEEDED them - everything they do can also be done for free with
remote calls.
Maybe I'm missing it, but I'm not really aware of anything else FCS
can do that either isn't related to streaming (that only FCS can do
because it's speaking a proprietary protocol with the client) or
shared objects (which we worked around not having in a few hours). If
you don't need either of those, I don't think it belongs in FCS. You
can do it for free with no license headaches at all in PHP, Java
Servlets, Ruby on Rails or whatever.
And that's the real problem with the pricing. If it was cheap enough
that you didn't have to sit there counting every connection and every
bit going in and out of the server, we'd be using it for more.
Because we're having to pay so much for it, we're a lot more willing
to find ways of not using FCS. I don't think that's a situation that
Macromedia is really served well by putting us developers in.
Dave:
I'm really sorry your original post got hijacked into a licensing
rant, but... You gotta understand- It really doesn't matter what you
do with FCS at this point, any of us who are using it in volume just
can't afford it. I don't care if it did everything every person in
this thread has asked for and made me dinner every night. For the
$175k that FCS would have cost us for the length of this project, we
could have hired a half-dozen programmers for 6 months to code us a
streaming server from scratch that completely met our specs and still
had money left over to buy hardware.
I've told Macromedia Sales people myself this exact situation, and
got told "Nobody else has ever complained about the price, it's cheap
when you think about it! We're not changing the price, it's non-
negotiable. How many can I put you down for?"
=3D---------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D---------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailma...fo/flashcomm=20
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|