[Red5] flash media encoder 3.0
naicuoctavian at gmail.com
Wed Feb 11 10:24:37 PST 2009
I am more involved in broadcasts where the actual encoding/publishing is
done by a dedicated team with lots of hardware and cables where the
connection to the FMS server is not a problem! In such scenarios bandwidth
and cpu power for encoding is always enough. That's why I am biased towards
considering the multi bitrate encoding in FME3 a better solution than server
Your results seem very good, I wasn't expecting decoding + encoding to be so
fast! Just recently I found out that adding audio to a stream adds about
100ms in latency (tested with FMS FP 7,8,9). Video only streams have much
On Tue, Feb 10, 2009 at 7:07 PM, Art Clarke <aclarke at xuggle.com> wrote:
> > I find this feature very useful actually. Downsampling on the server side
> > would be very costly in terms of CPU and DELAY/LATENCY.
> You are right; encoding multiple streams on the client is useful.
> However, the blanket statement of "server side would be very costly"
> deserves a closer look.
> You're generally trading off the publisher's CPU load and bandwidth
> versus CPU load and latency introduced on the server. Now frankly,
> having the publisher's CPU do the work in a
> single-publisher/mutli-viewer world makes a lot of sense. Sometimes
> though it's the right choice to downsample on the server -- especially
> when publisher upload bandwidth is limited.
> In my experience many broadcasters barely have enough bandwidth to
> send one stream at a desired quality rating, and if you also broadcast
> simultaneously from that client 1-2 lower quality streams, well, you
> can make everything degrade horribly.
> And besides the CPU hit and latency introduced on the server might
> surprise you. Xuggle doesn't hand off to another process to do the
> decode/encode work -- we do it directly in the Java virtual machine!
> The result is very fast.
> For example, on one test we ran, decoding 640x480 On6 video and
> re-encoding and rescaling to 320x240 mpeg4 video in Red5 with xuggle
> added about 3-8 milliseconds of additional latency, and bumped the CPU
> load up about 5-10% on the machine we ran on during the transcoding.
> At some point we'll run more tests on downsampling performance
> (probably after FITC), or you can run the tests yourself by trying out
> the code at www.xuggle.com.
> But in short, choose the right tool for the job. If you're publisher
> has lots of upstream bandwidth, hell yeah you should make their
> machine encode multiple quality versions and broadcast them
> simultaneously -- after all, you're not paying for their CPU; they
> are. But if your publisher's upstream bandwidth is limited (which is
> I believe the cases that both Walter and Dan are concerned with),
> reencoding on the server is a valuable tool in your arsenal.
> - Art
> xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and
> Use Xuggle to get the power of FFMPEG in Java.
> Red5 mailing list
> Red5 at osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Red5