To answer your actual question:
Will this implementation work? can it protect my content from unauthorised clients, what are some of the drawbacks of using this?
No, this implementation will not protect your work because even if the client hardware is "trusted" (or "treacherous", depending on your perspective) it's still very easy to intercept communication between two computer network endpoints and capture any content and keys that are exchanged - this is especially true on typical consumer-grade devices where, unless you're using certificate-pinning, it's trivial to install self-signed certificates and DNS or ARP-spoofing to set-up a MITM attack). Your post implies you're operating over HTTP and makes no mention of preventing replay attacks so it's a trivial
wget call to download a private copy of the media - crucially you also don't mention ever encrypting the media, only limiting who can originally download it.
What are some of the drawbacks of using this?
Your approach doesn't have any real drawbacks besides being generally ineffective.
Audiovisual media encryption generally makes use of encrypted content, rather than restricted distribution (which is what you're proposing) - so anyone can download some video file, but access to the keys to decrypt it is actually tightly controlled - and because a crypto-key is generally very short (64-512 bits in length) it's much easier to protect than a multi-gigabyte MPEG stream.
Existing DRM systems built-in to computers generally rely on operating-system level (i.e. kernel-module/driver ) components to restrict the user in some way, or to hold secrets (such as decryption keys) from end-users - for example encrypted memory that the OS takes active steps to prevent userland, or even kernel-mode, debuggers from reading successfully. Note that as these are all software-based they can all be defeated eventually - usually by running the code in a virtual-machine and using the VM host to pick it apart.
Should i say DRM is only meant for the big players, i mean how does netflix protect it's content, there must be some huge amounts of money spent by these companies
While DRM is mathematically fundamentally broken (as Bob (the intended recipient) and Charlie (the attacker) are the same real-life person) it's still possible to use varying techniques to delay cracks to maximize profitability - one example is the DRM used in popular high-profile video games - which can be very aggressive (e.g. StarForce) or annoying (SecuROM, etc) - which arguably do harm sales - but the video game publishers know that these DRM systems will prevent a pirate release for at least a few weeks, and those few weeks of exclusivity will mean more sales - even though it will generate bad PR.
As for Netflix - for their web-based player they use whatever DRM is provided by the supported web-browser (the same as Hulu, etc). For Google Chrome this is provided by Widevine; Edge/IE use either Silverlight (like Flash) or Windows' built-in "PlayReady" DRM system which uses kernel-mode components to protect decryption keys. I don't know exactly how Widevine works as documentation is sparse online.