There\'s two things to think about here:
1) Pack the video with the scene file (in the texture panel at your image location hit the pack button and use the pack option in the file menu before saving)
2) The filesize of the movie you whish to include. The movie file counts towards the total size of your .blend file. Sessions where the scene file uses too much diskspace compared to the amount of time it would take to render them are rejected since they use too many project resources as long as we\'re still just doing alpha testing. This is why using raw-type textures and uncompressed moviefiles in general is a bad idea - always use as much compression as possible to achieve your desired quality level.

I\'m responding here rather than in your email because other people may be interested in the answer.
There\'s several issues here:

1) I found out that the current client does not support the unpacking needed to unpack movie files into the textures subdirectory. This means that you will not be able to use movies as textures presently. I added this to the known problems page.

2) However, this may not be what you want anyways. Since your movie seems to be just another scene you can check out \"Render-to-texture\". This may, however, be an advanced feature (I don\'t know - but I certainly don\'t know how to use it anyways)

3) Generally you\'d rather like to keep any movie files in the local render pipeline rather than sending them to a distributed renderfarm. Specifically, if the movie is not used extensively in reflections, this can be done quite similar to what is described in Blender: Advanced postprocessing effects with BURP - except that you do not whish to postprocess with filters. You would have a node setup like (possibly with \"overlay\" as mix method instead of \"mix\", didn\'t test it):

Here you would render layer1 on BURP and use the technique from the tutorial to replace that with the output downloaded using CATS. layer2 is then rendered locally (directly using the movie file and Z information from the scene - you\'d have to do some occlusion stuff here if something gets in front of the movie...) and mixed in on top of the first renderlayer.
This too is pretty advanced, so you may need to read up on the node editor, renderlayers and general editing methods.
The good thing about this method is that it assumes nothing about the movie files used. They are never uploaded to BURP and you can even switch in another movie if you suddenly change your mind - you don\'t need to re-render the actual scene on BURP.

I think the video was attached, because the amount of time to send it was reaaly long

That \"the amount of time to send it was reaaly long\" is a good indication that something is terribly wrong. Whenever you get that feeling you may whish to think twice about what is going on =)

I can\'t stress enough that any bytes that you can avoid uploading to BURP will make your scene render more effeciently. This is one of the main differences between a massive supercomputer renderfarm (which has >1Gbit/s connections to every node) and a distributed renderfarm like BURP (which connects with its nodes through an internet pipe with just a few Mbit/s).

For a few supercomputer-based online renderfarms check out these commercial alternatives:
ResPower
Render Planet
BURP beats these solutions in raw renderpower by a factor of magnitude - but only if you treat it right. If not, BURP may even be slower than rendering the session on a single machine...

4) (This applies only to your particular scene file, but the issue is still general and may help others) You attached 2 copies of a 14.5MB movie file called 0001_0977.avi and 1 copy of a 41.2MB visage BURP1.avi (which was never used).
It is a good idea to check that there are no unused data-nodes in your scene file before uploading to BURP. Unused data (especially when talking about many megabytes) is really a waste of resources.