Come on guys, it took longer for you to write all those "meh I hate those asking for homeworks" than actually replying... I'm new around here, so I don't know in what measure you get asked this stuff: I hope that by answering I won't cause a massive invasion of pupils willing to finish their duties quickly!
I think the OP is pretty confused about what RAM really is, so I'll try to make it a bit clearer, if I can
Last time I studied RAM architecture the book spoke about latches and nands circuits. It wasn't too hard to understand, although this technology has been supersteded when humanity got rid of manual switches to set bits.
All I can explain is that a nand latch can hold a bit (1 or 0) as long as it's not instructed to change it - that is, RAM needs to receive electricity in order to keep data, and you can only access it while it's not receiving maintenance charge. So, I think you can safely imagine that a nand circuit receives a signal that won't alter its content, say 11, then the system can send a signal to either alter or read its content, then it needs to wait for another refresh cycle. I might be wrong on some part (hopefully not completely), so probably someone could explain you this point better than this.
Anyways there are whole books on the subject, so a quick post is far from being exhaustive!
Video reproduction strictly depends on the software used - ideally you will have a circular buffer being read continously - that is, an amount of reserved RAM being continously overwritten right behind the reading position, so that on the next round shown pictures will be different and you only need a small limited amount of memory to show even a huge movie (that's what the prechache 2 seconds option in WinAmp and other players does, set the size of the ring, and why when your player freezes you hear the same piece of audio over and over, the buffer is not being refreshed anymore!).
That's just the final step, and displayed frame often resides on video memory. However the process is much more complicated as compression is taken into account - you need a buffer for storing data being decompressed, likely some temporary storage for decompression and finally a circular buffer for final display. Also, streamed videos like those on youtube might only exist in RAM.
The amount of RAM a program can use - people will correct me if I'm wrong - depends whether your software is running in protected mode or not, at least on intel processors. Also, the OS is an important factor: apparently, even the latest Windows won't allow an application to use more than 4 GB, although they might be running as 64bit apps (for 32 bit applications, in normal conditions you can only address 4 GB, and that's the limit of a 32 bit value, 2^32-1).
During file transfer, as someone already said it depends: a "normal" copy will be composed of a program loading data into a buffer and dumping it somewhere else, while other methods only rely on the drivers themselves. I'm not sure about DMA transfers, I might say it only uses controller's cache, but you can double check on wikipedia. Anyways as an example I'm reasonably sure that Nintendo DS' DMA copy doesn't use anything else other than source and destination locations (which may be on the cartidge).
Anyways programmers rarely have to worry about how electronics actually work, unless there is a special need. Most of the time you ask for a buffer and you're happy with it - you don't even know if it's in RAM, swap, VRAM or aonly-god-knows-where (thanks to M$, we have loads of C# gurus delivering critical apps and not even knowing what a cache hit is).
Hope I was of help!