Quote:
Originally Posted by VGeorgie
Any programmer skilled in the art of working with digital media could do this for you, but as I noted above, the idea is covered by no fewer than a half-dozen patents, not just for digital media but for all kinds of media. This limits the options, at least if you want to keep from being sued.
The basic idea is to seek the media to a specific keyframe, then decode that keyframe to an RGB bitmap. You insert a watermark of your choice into the RGB channels. A stenographic watermark (itself, covered by various patents by Digimark, Kodak, Macrovision, and others) is not normally visible to the eye, and the better systems resist loss of mark even if the video is cropped, resized, or resampled.
You then re-encode the frame, and replace the one in the stream. When done properly, the re-encoded frame will be the exact same size in bytes as the original. This is the tough part, but there are ways to deal with this. Some stream types allow you to chunk in the new frame, then tack on the remainder of the stream. With a fast hard drive and CPU the delay isn't too bad, a few seconds maybe for a largish 100MB file.
|
Thanks, VGeorgie. You seem to be quite knowledgeable in this field. It is a pity that the big guys have patented this crucial technology. I am wondering why the file size (100 MB) has an impact on performance when you are only replacing a few frames. Does the entire file have to be re-copied on the harddisk before serving it to the client? Or is it possible to simply make a precise surgeon cut and modify the necessary frames on-the-fly as the video is being delivered to the user? So the video server can start streaming immediately, and not wait for re-encoding the keyframes which are hidden further down the stream.
Ron, it is probably a waste of time watermarking the content because it will not stop anyone from pirating it. However, you still maintain the branding if you have a watermarked logo. Yeah, why have the stenography when you cannot litigate the pirate. Litigation would also reveal the method used, and open one up for being sued for using the patents. As someone said earlier in this thread there is also the entire issue of correctly identifying the downloader.
PR_Tom, fake security might be a deterrent on the casual pirate. Good idea. Because one needs to be an expert in the field anyway to be able to detect the hidden stenography.
But how do you detect when a member clicks Download in his illegal toolbar? In the server logs and browser DOM events it will look just like regular legitimate traffic. If I am not mistaken.
This thread is great. Valuable info
