Subversion actually has the some of the best large-file handling of any modern revision control system. Git, Mercurial, Bazaar, etc. all have architectural or platform-specific limits (usually 2 or 4 GB, because they mem-map files to do various things). Git could probably be a good fit for your use case as a "stupid content tracker", if you can deal with pushing files to a git repo on a server and then doing a commit on the server via script. See this question for more (and its links about the memory-mapping issues on different platforms).
A bigger issue is that the "binary diff" and compression functionality provided by revision control systems is generally ineffective on most large media files, since they are already compressed and change so much. For example, if you have two movie files, and edit one to remove 4 seconds from the middle, you would think that it should be easy to store only the changes. But in fact, when you edit that file, even if you don't re-encode the video, the time-codes for each frame get shuffled around, resulting storing almost the whole file again. You might want to just turn off the compression and diff features in your tool if possible to save on CPU and backup time.
The only large files I've seen Subversion or Git do well with are SQL database backups, which uaually have a page-like structure and change very little from one backup to the next. And of course log files, which just compress like crazy even with gzip.