Multi Computer avi 2 mpeg2 encoder

[cgentry]

Hi,
I've been doing some research on mpeg2 encoders. I haven't found very much that was easy to understand, so I'm looking for help here.

What I'm wanting to do is create a client/server configuration for a local area network. The server would break an avi file into x number of frames and send these frames out to the clients. Each client would then encode these frames into mpeg2 streams and send them back to the server. The server would then put it all back together and write it to disk.

I do have some questions on the feasibility of these programs.

1.) I currently have only 3 computers on my LAN. Would the extra overhead of putting (on average) 25GB avi files over the network be slower than if I just used TMEPGenc?

If I used the computer lab at college, I could use around 20 computers, so this wouldn't be as bad.

2.) Can you break avi files into individual frames and then encode them like I want? I know I might need to send more frames than actually necessary to the client, but I can drop these frames at the client so I don't need to send them back.

3.) I've researched a few programs, but is there anything out there that does this already? Or can you point me to some open source applications that does somewhat what I want. (basic encoding)

Following is some pseudocode on this: (Basic idea only)

Server system:
_________________________
Start

Setup sockets
Create buffers
Open avi file
Read avi file
Fill buffers (attach headers here, so we know what frames we have -sequences)

Start LOOP
Send out packets to clients in the ready state

Receive completed packets
Strip headers
Join packets

Sanity check (see if packets have been out for to long)
If they haven't returned in awhile, send a cancel message and
resend packet to another client.

Check total processing time
Output elapsed time, time remaining.

Clean completed frame buffers
Read Avi file
Fill frame buffers

End Loop

Clean up

STOP
____________________

Client p.code

____________________

START

Create buffers
Log into server and send "READY" response

Loop

Receive packets

Send "HOLD" response to server

Process packet (Encode)

Send finished packet back

Cleanup Buffers

Send "READY" response to server

end Loop

Cleanup

STOP

______________________

[tim6661234]

I don't know of such an app but I would say that having 3 processor encoding at once (I think this is what you're after) would increase the speed of encode but you would loose this plus a whole lot more unless you're on a very fast network.

[cgentry]

Yeah, that is what I'm after. And if I had more computers on the network I could install a client on each of them too. Then I could have more processors running at once. In the lab at school, I could have around 20 processors working at once.

I am on a 100Mbps network, using regular cat5 cable, so I was hoping it would be fast enough. I talked to some of my networking teachers at school, and they said that it should be adequate as far as my network speed is concerned.

I'm also running 2.4Ghz+ computers, so the comp speed should help.

I didn't ask in my original post, but if anyone out there would like to help me do the actual coding on this project, then let me know. I know a few different languages, but I don't know C++. I was planning on coding this in C.

[BJ_M]

the problem with this is how would you handle temporal prediction as in a mpeg file ?

i.e -- part of the vectors would be on different machines .. and to equalize bitrate .. a machine (who is ahead) whould have to go back and re-encode ..

some work on this was done a while ago and proved that it was slower than a 4 or 8 cpu machine because of the lag in even a fiber network ..

non temporal type encoding works perfect though in your scenario .. as used in such programs as shake and fusion in a network rendering ..

[cgentry]

Hrmm, did whoever it was, publish their work on this problem? If so, do you know where I can find it?

As for the temporal prediction, what is it? In laymens terms please. heh, I've done alot of research, and I think I'm close to grasping alot of mpeg2 concepts, but what I gather so far is it is a way to predict motion from one frame before and one frame after? Hrmm, I'm probably wrong, but if I am, maybe someone will tell me.

As for one machine getting ahead of the other, I'm going to code it in, so I send a GOP to each machine with sequence numbers attached. When the machine returns it, then I'll send another GOP. But if it is lagging behind, I'll send a "CANCEL" message, and then send that GOP out to another machine, so one machine doesn't get to far behind.

Basically what I'm wanting to do is treat it all like building blocks. I give 3 blocks (GOPs) out, and then wait for them back. Each block has a number (sequence header) and must go on top of the previous number. If I get block 4 and 5 back, but I haven't got 6 back for awhile, I'll recreate block 6 and give it to someone else.

I'm hoping that if I can break it into small enough blocks, then the only thing the server machine will be doing is putting out pieces and pulling them back in and putting them together. All the processing will be complete on the other machines by the time the server gets back around to them.

If I'm way off on all of this, then please let me know. I want to understand it. Thanks -Chris

[BJ_M]

the problem you see that for high quality encoding -- one GOP may (will) reference anther GOP (which could be on another machine) -- unless you make all GOPs closed and same lenth -- then there goes quality

[SaSi]

the problem you see that for high quality encoding -- one GOP may (will) reference anther GOP (which could be on another machine) -- unless you make all GOPs closed and same lenth -- then there goes quality

Quite a few months ago, when I had a P3/800 and using Tmpgenc, I was into the same kind of ventures.

The temporal issue of encoding can be solved and I think the solution is easy.

Send 1000 frames to CPU-1 to encode as an open GOP sequence with the last GOP (obviously) closed.

Send frames 1001~2000 to CPU-2 while CPU-1 is still encoding.

Send frames 2001~3000 to CPU-3 while CPU-1 is still encoding and CPU-2 just started to encode.

Then wait and meditate.

As soon as CPU-1 finishes, receive the encoded stream and store it. Respond back with frames 3001~4000.

As soon as CPU-2 finishes, bla bla bla.

The only penalty is that you get a closed GOP every 1000 frames (probably more often as the encoder may decide to close a GOP by itself).

You can't start out deciding how long a GOP is. You must let the encoder s/w decide that. Also, sending too few frames to each CPU will degrade performance as all CPUs will spend most of the time connecting and communicating.

Also, load balancing the whole is less critical, unless the machines are not the same speed. Even then, after sending the first 1000 frames, and receiving the resulting stream back, the despatcher PC will have a fairly accurate bechmark of each machine, so the second batch can be fine tuned towards each machine's speed. The slower will get less than 1000 frames and the faster will get more than 1000 (or any similar combination).

The only issue with this whole scenario is how to feed the video to an MPEG-2 encoder s/w. Perhaps a command line arguments option would help with that.

[FOO]

This would be non-deterministic but...
You could divide up the original AVI by scene
changes and send segments on that basis.
Scene changes close the previous GOP anyway.

[BJ_M]

VEGAS 5 will have network rendering -- i guess of mpeg2 also ... so we can see how they do it ..

prob. just chop up the files ..

[cgentry]

Can someone point me in the right direction for some good websites that cover most of the video jargon. Some of it I know, some I don't. Also if you know of some good video programming sites. post them please. I'm not bad at programming, but I don't know much about video programming, and this program is something that I think will be useful.

Scene changes was mentioned. Would it be possible to quickly traverse an avi file to find out where scene changes occur? Or would the operations to do that slow my system down enough to make this program obsolete?

Another thing. Since I'm not going to write a mpeg2 encoder from scratch. (For one I don't know how) Which open source application offers the best one to pull out and use in my code? (If this program ever comes into being it will be open source as well) I will probably code this in C/C++.

[FOO]

Forgive me . I admire good initiative
but I think you are dreaming and very young.

Would it be possible to quickly traverse an avi file to find out where scene changes occur

There are smart people that have been working on this for years.
Why don't you know this ? Because you are all mouth and lazy.

[cgentry]

Forgive me . I admire good initiative
but I think you are dreaming and very young.

Well I may be dreaming, but I am 26 years old, so hardly "young" as you put it. I have been programming for six years.

There are smart people that have been working on this for years.
Why don't you know this ?

Because I just started looking into video encoding.

Because you are all mouth and lazy.

And this post did nothing but attack my character. No true help from someone who knows about this subject. What I asked for is links to helpful information. I could very well be the next "smart" person to figure out a way to do this. Just because people have tried in the past does not mean that it cannot work, especially in the tech area. Newer faster computers make things that failed in the past suddenly possible.

As for being lazy, most programmers are. I have, however, looked at a large number of sites and programs. This research has taken me all over the web, but when you ask a question like this, you never know what new place you will find.

[BJ_M]

http://heroines.sourceforge.net/libmpeg3.php3

http://www.projectmayo.com/

http://www.the-labs.com/Video/


http://www.hal9k.com/cug/links/subject161.htm

more stuff on google search ///

[cgentry]

Well I have found optical scene detection in nandub. I believe I can make this work for my program. As for an open source mpeg2 encoder, what would be the best one to borrow code from? I've found several, but I have always used cce in the past, so I don't know anything about the open source encoders.

[cgentry]

I've been looking through ffmpeg and I noticed that it syncs the audio and video by the audio time. For this application I only want to process the video. Will I have sync problems if I just ignore the audio? Or should I just use the time code from the audio stream and send this information along? Thoughts on this?

[FOO]

Who is writing this program anyway ?

[cgentry]

I will be writing this program. Probably in C so it is as fast as possible.

[BJ_M]

"fast as possible" would be assembler wouldn't it ?

[cgentry]

Yeah, but I don't know assembler, so "fast as possible" would be C for me :0)

[FOO]

I think you should use COBOL or FORTRAN

[BJ_M]

Hollerith punch cards -- yea for sure the way to go ...

[SaSi]

I've been looking through ffmpeg and I noticed that it syncs the audio and video by the audio time. For this application I only want to process the video. Will I have sync problems if I just ignore the audio? Or should I just use the time code from the audio stream and send this information along? Thoughts on this?

Actually, to time the video stream audio isn't required.

If the encoder is told that the frame rate is [nn] then it marks the MPEG stream accordingly. You can give the wrong frame rate if you want and the encoder will correctly give you a stream of the wrong framerate.

And, not that I come to think about it more, if you don't want DVD compatible MPEG-2, you can avoid GOP headers (the only place where any reference to time is made) and the video stream will have only the frame rate encoded in the sequence header to tell decoders what the frame rate is.

PS. Don't want to discourage you, but your questions indicate that you have a lot of reading and searching to do before you start writing any code.

And if you care for advice from someone who has been programming for 22 years or so, approach this so that you avoid any code development. That way you will write some to enjoy and your project may reach the finish line with something useful.

Good luck

[cgentry]

You are very right. I do need to do alot more research. Part of that research is in posting a problem like this and seeing how others who are more knowledgeable would deal with it. I do learn fairly well from reading, but every helpful post I have received has guided me closer to what I really want to do. Each new idea helps me shape my searches so I find relevant information.

The reason I thought the audio was needed is that after ripping a dvd with dvd2avi in forced film mode, I have to load the audio into TMPEnc along with the video or I get sync problems. I understand this to mean that TMPEnc is adding frames so the framerate will be 29.97fps. How this is affected by the audio time, I don't know. Of course this could just be a feature of TMPEnc, since when I do the same thing with CCE I don't have the same problems.

P.S. I have been told this project is not worth doing since others have bogged down a fiber optic line trying it. However, I can transfer a whole ~6-7GB dvd from one computer to another over my LAN in 5-6 minutes. At these transfer rates I find it difficult to believe that the network would not be able to handle the load.

[FOO]

OK RAW RGB is 110 Gb/hr and DV is 13 GB/hr
A DVD is 2 Gb/hr

Think about that. You want to send stuff that's not encoded yet

[babybear]

There are smart people that have been working on this for years.
Why don't you know this ? Because you are all mouth and lazy

.

The above statement ... just ticks me off...

I have only been around for a short time, great site, learned alot and read alot from both seinor and new posters.
It seems that alot of people, myself included are here trying to learn.
When people ask a few questions or think of new and or helpfull ideas, some of the replies people get are similar to the above. This in my opinion discourages myself and other people to post their ideas, questions and findings.

Isn't this why the forums exist?

People who have posted 2599 times and have been members for a year (Joined: 24 Mar 2003) should have a considerable knowledge of the hobby and I and others would look up to them to help out rather than posting such useless crap.

I may be 10 or 75 years of age, I may also be lazy but I certainly don't want to waste my time reading crap like this. If I don't have any questions or contributions to the thread then I just read and learn.

This is my 2nd post in the forums and will be my last post here in the forums..

Just my 2 cents.


Sorry.... cgentry I was drawn into this thread by your idea as I to have a few PC's at my disposal and want to put them to work but do not have the skills to write the programs yet.... but learning.... Great idea by the way!

Cheers

[FOO]

This is my 2nd post in the forums and will be my last post here in the forums

Thank you

[cgentry]

OK RAW RGB is 110 Gb/hr and DV is 13 GB/hr
A DVD is 2 Gb/hr

That is a good point. What I'm wanting to encode is DV. Some of it is family movies at roughly 30 minutes each. Others is full length VHS movies that I want to put to dvd. These can get quite large, weighing in at around 40GB. Still 40GB of information can be handled in less than 2.5 hours. Consider in that 40GB you have your audio stream. Stripped out this will take a small portion away from that number. Then when the information is encoded and sent back it will be in dvd-compliant mpeg2 format. That means you won't have to send the full 40Gigs across the wires twice. Just the 6-7GB(With sequence headers and information attached by client program) plus the original 40GB minus the audio stream.

This is still alot to send to different workstations, but if you have fast workstations then there will be little processing time involved. That means for each cycle of the server program you can send out some frames and receive some back. If you have enough clients, then you can encode at almost the speed that your data is travelling across the network.


and to babybear

This is my 2nd post in the forums and will be my last post here in the forums

Don't give up just because someone tells you that it is a stupid idea or doesn't help at all. Sometimes people who criticize will actually point out a flaw in your design. The more "constructive" criticism you get the better you are able to plan.

[FOO]

Mr. Babybear has seen fit to deprive us all of his wisdom by
using PMs . I think everyone should benefit instead of just me.

*******...

and my response...

If you are so self righteous , why do you sneak around
and send private PMs . Post it on the forum , you coward.
what business is it of yours anyway . I never insulted you.
What are you , ? Forum police ?

[SaSi]

That is a good point. What I'm wanting to encode is DV. Some of it is family movies at roughly 30 minutes each. Others is full length VHS movies that I want to put to dvd. These can get quite large, weighing in at around 40GB. Still 40GB of information can be handled in less than 2.5 hours. Consider in that 40GB you have your audio stream. Stripped out this will take a small portion away from that number. Then when the information is encoded and sent back it will be in dvd-compliant mpeg2 format. That means you won't have to send the full 40Gigs across the wires twice. Just the 6-7GB(With sequence headers and information attached by client program) plus the original 40GB minus the audio stream.

Well, I must say this:
The project you are discussing is an interesting research task if only to get you to understand several different apsects of encoding and networking.

But the excuse you present is really fun!
Are you going to spend a couple of months researching and designing, and then several months bulding a distributed encoder just to encode home video?
Better off to use Tmpgenc, in highest quality mode, 2 pass. It will be at least 1000 times faster.
If you want to make use of stray PCs around you, just install the encoder s/w on each of them and encode in parallel.

[FOO]

I think you should skip worrying about the encoder.
Use an existing one . and fool it by feeding it video
via frameserving technology through a LAN

That would even be good with 2 computers
Computer1 resizes and filters , sends it to computer 2
which encodes.