There is no "public" key in AACS (at least, no in the part which uses SDR).
Each movie is symmetrically encrypted with a movie-specific key, and stored as is on the disc. All copies of a given movie use the same key; indeed, all copies of a disc are bit-to-bit identical (it would not be economically sound to do otherwise). Two distinct movies, however, use distinct keys.
From that point, the problem of giving access to the movies to all "allowed" players (and only to them) is reduced to the problem of giving them access to the movie encryption key. A movie encryption key is small (a few dozen bits), an encrypted movie is huge (several gigabytes); presumably, keys will be easier to handle. On the disc, physically, there is only one instance of the movie itself.
Each player has its own key. So one model is the following: the disk contains the movie, encrypted with the movie key $M$, and a complete set of $E_P(M)$ (movie key $M$ encrypted with player key $P$). Each player would decrypt "his" $E_P(M)$ to retrieve $M$ and decrypt the movie. If, at some point, a given player key $P$ is detected to have been leaked (e.g. there is some downloadable software which uses that key to decrypt movies), then the movie editors just have to stop including $E_P(M)$ for that key $P$ in the discs they press (we would say that the offending key is revoked).
Now, the problem with that model is that there are billions of player keys (for all the current and future players, because we want disks sold now to be playable on systems which will be built next year) so the total size of all these $E_P(M)$ would exceed the disk capacity (it would need several dozen of gigabytes, more than the movie itself). So the tree-like structures come into play. The player keys all come from a giant tree structure. The needed size on each disc is in $O(\log n) + O(r)$ where $n$ is the number of player keys in circulation (including future keys) and $r$ is the number of revoked keys. This is small enough for existing discs (in particular Blu-ray discs, which use AACS) as long as there are not too many revoked keys (the hope is that revocation will remain a rare occurrence).