Parallel MPEG-4 Video Encoder

[Guest]

Archived from groups: rec.video.desktop, comp.compression, comp.multimedia (More info?)

Hi, We are a group of students working on a project for
parallel encoder for MPEG-4 Video stream. We'd appreciate any help/idea
etc that you could provide us.
Right now, the idea is to run instances of the MPEG-4 encoder
on 2 or more "client" machines, with a "server" distributing groups of
raw frames to each and another "server" collecting the compressed
frames at the other end. We have decided to use sklmp4 library to
"build" an encoder "client".
Any ideas on how efficient this would be, or could you suggest
a more efficient one...

thanx
sanal krishnan & co

 

[Guest]

Archived from groups: rec.video.desktop, comp.compression, comp.multimedia (More info?)

santechz@gmail.com wrote:
> Right now, the idea is to run instances of the MPEG-4 encoder
> on 2 or more "client" machines, with a "server" distributing groups
of
> raw frames to each and another "server" collecting the compressed
> frames at the other end. We have decided to use sklmp4 library to
> "build" an encoder "client".

I'm not sure how far along your project is or what the capabilities of
sklmp4 is, but plan on distributing sets of frames to each encoder
instance (instead of just feeding the next frame in sequence to the
next available instance). MPEG-4 relies heavily on interframe
similarity for compression, and groups sections of time together as
GOPs (group of pictures). You will need to determine beforehand what
the length of your GOP is, and each mpeg4 encoder client will need
access to that many frames at a time. Later, the server can combine
all of the GOPs together into the final product.

Or, more optimally, have the server designate the GOP length for each
instance. Usually GOPs are split on scene changes (where 50% or more
of the frame changes compared to the last frame). The server will have
to monitor the content of what is being served and switch to a new
instance/GOP on a scene change.

The problem with distributed encoding of video is I/O -- video frames,
even losslessly compressed, can take up a lot of network bandwidth to
transmit to all of your clients. Unless encoding is quite slow and
greatly exceeds transmission time, there is not that much gain from
encoding with a single instance that has local (fast) access to the
source data. Hopefully you will have access to gigabit network speeds
to implement your project. (Note that distributed *rendering* of video
has been done for over a decade, but that is because rendering video
(3D visualization, multi-layer compositing, etc.) is orders of
magnitude slower than designing it.)

 

[Guest]

Archived from groups: rec.video.desktop,comp.compression,comp.multimedia (More info?)

Jim Leonard wrote:
> santechz@gmail.com wrote:
>
>>Right now, the idea is to run instances of the MPEG-4 encoder
>>on 2 or more "client" machines, with a "server" distributing groups
>
> of
>
>>raw frames to each and another "server" collecting the compressed
>>frames at the other end. We have decided to use sklmp4 library to
>>"build" an encoder "client".

[snip]

> Or, more optimally, have the server designate the GOP length for each
> instance. Usually GOPs are split on scene changes (where 50% or more
> of the frame changes compared to the last frame). The server will have
> to monitor the content of what is being served and switch to a new
> instance/GOP on a scene change.

I had that thought as well. It avoids introducing breaks where they're
not wanted. Of course if the O.P. is talking about two or four CPUs,
just breaking the incoming frames into N equal size bits probably
wouldn't hurt the size of the output enough to notice. If he's talking
about a cluster I don't know what the tradeoff would be.

With modern CPUs I'm not sure the bandwidth limitations of the network
aren't going to become a factor early. A good thesis project, I'm less
sure of it being useful until scaled to feature length movie size.

--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979