It's actually a lot more of an interesting question than is being suggested by the answers so far. Lets suppose 2 cases:

A) SW rendering

B) HW rendering, which is much more probable and interesting.

For (A), both solution 1 and solution 2 are effectively the same. In fact, solution 2 is potentially better due to striping the rendered image in memory, and as a result you'll get some help out from linear prefetchers as you render, if you do so from top to bottom. You won't have this big stride-gap between one "row" to the next. In fact, if you're rendering sprites on some architectures, it's more efficient to translate them into a striped format anyway, regardless of whether you're using SW or HW rendering. In SW, you end up with more efficient memory use since you don't need to pay for all those little bits of the larger image that end up being waste due to imperfect packing.

For (B) you get improved efficiency by limiting the number of texture transitions, which is to say the number of times you move from one "sheet" to another. In this case, option 1 clearly has the possibility to be superior. However, packing all the frames for one "character" in one sheet doesn't help you a whole lot, becuase you'll be paying for the texture transitions per frame, even if you tend to transition back to an old sheet in the very next frame. A more interesting method is to pack things that are probable to appear in the same frame together. For example, in a sprite rendering context, putting the attack frame of your characters on the same sheet as the get-hit frame of the characters you're probable to be attacking. This of course isn't going to be something you'll do by hand, but is easy to do off-line after a bit of profiling to collect which animation frames tend to co-exist in the same game frame. Same can be said for textures in 3D games. Place textures that are likely to be seen together, not textures that belong to the same "entity" but during different times.

In short, method 1 gets you improvements if you can pack things by-frame, rather than by-entity. It's actually rather surprising how little packing by-entity helps you with regard to efficiency as compared to just having everything in its own little image, and how strongly certain textures coorelate with one another on their by-frame use, even though they are associated with different entities.