You probably want to encrypt the content (or at least obfuscate it). You then have to trust the encryption and the procedures related to it.
But advanced users could bypass your Java code and access to the encrypted form.
BTW, with enough efforts (including forcing the encryption), your mechanism could be bypassed. Remember that security through obscurity is a fallacy.
Storing data outside of files (e.g. in some database) does not hide it at all. An advanced user (like a motivated enough me) would find your database and could query it outside of your application. It could change a Java class loader to modify or at least trace your application's behavior, or it could even patch the JVM running your thing (or use some different, e.g. academic JVM, to run your thing). It could e.g. trace the system calls done by your app (on Linux, I'm using strace(1) on most foreign binary software I might have to install). Read perhaps Operating Systems: Three Easy Pieces.
Also, a given content (video or book) could be legally available on the consumer's computer outside of your app. Do you require that content to be duplicated (wasting resources on the consumer's computer, assumed to legally belonging to him)?
At last, as a consumer, I would never buy or use your software, because I don't trust DRM. Information wants to be free. See https://www.defectivebydesign.org/ (which also have technical arguments related to your issue that you should know, even if you disagree with the opinions there).
Read about trusted computing base.
Explain to your client that someone (outside of US law juridiction, perhaps some Chinese, Russian, French developer or hacker, more generally outside of legal reach from your client ....) will eventually reverse engineer any software trick you'll implement, and publish his understanding of your tricks on some website or forum. It is just a matter of time. Read about libdvdcss as a past example etc...
I want to obscure them or somehow restrict access to the content so it cannot be accessed outside my application.
You won't technically be able to fully restrict (that is, make impossible any) access to content on another computer (on which the OS, the JVM, the hardware etc... could be "hacked" or "compromised" or "improved" or "patched"); you just could make that difficult (using encryption or obfuscation techniques). So you have a cost-effectiveness tradeoff: how much work & resource can your client afford to make it very difficult? Or is "barely difficult" enough?