If I may just pick up on Todd’s explanation of why H.264 isn’t an editing format and expand it a bit:
H.264 doesn’t compress individual frames, it compresses into blocks containing a series of frames called GOP, which stands for Group Of Pictures. When a computer plays an H.264 file it has to decode blocks of frames to display them, which isn’t a big deal (it’s technically quite complex but modern computers are well up to the task). But when you want to edit the pictures you want to end one clip on a particular frame and start the next clip on a particular frame and there’s every chance that those frames won’t be the last one of a GOP on the outgoing and the first frame of a GOP in the incoming, so to do the edit the computer has to decode the whole of the GOP containing the end frame of the outgoing shot AND the whole of the GOP containing the first frame of the next shot AND create an new GOP showing what you need to see. That’s quite a big processing and memory load for even the most up to date computer (and that re-compressing to make the new GOP is where the picture quality drop that Todd mentioned happens). So what happens is that you can see your clips when you play them and you’ll do a couple of edits and all will appear to be well, then you’ll do another couple of edits and the computer will slow down and pretty soon it will grind to a halt because it’s got too much work to do. Some software and hardware will cope for longer before running into problems, and if you’re working with high quality (broadcast standard) pictures you’ll “hit the wall” much quicker than you would with lower data rate material.
Most editing codecs, like ProRes, compress each frame separately (which is known as all I-frame), but it’s actually a bit more complicated than it might seem – Sony’s XDCAM is actually a GOP codec but one which does accomodate editing (I could make an educated guess for why that’s the case, but I’m not certain).