[Red5] flash media encoder 3.0

[Naicu Octavian]

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
side downsampling.

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
lower latency.



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.
>
> $0.02.
>
> - Art
>
> --
> http://www.xuggle.com/
> xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and
> video.
>
> Use Xuggle to get the power of FFMPEG in Java.
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090211/63794b8b/attachment.html>