hello can anyone help me regarding this..........?

there is no fool proof way, but you could embed the videos into the application, when you needed to play them create a memory stream from the resource and play it from there, or copy it to temp, play it then delete it afterwards.

the only tactical way would be to create your own video codec that has custom drm, and only allow it to be played via a code your application has.

Even then, a crafty pc user could always find a way to copy it. There is a FREE utility out now that lets your copy blu-ray disk. Your asking a hard question.

"" what Diamonddrake said. Even the hollywood movie industry and the RIAA is having a hard time stopping people from copying any digitial multimedia that you can consume on a PC. They have even integrated DMRA in to the Windows operating system yet copying is still a problem.....

All I have to say about that is good luck! You can spend a lot of time to make it very difficult for the user to copy but as of today you will never solve this issue.

i know it is a hard question that is why it is my problem,.......
Well can u tell me how can i implement this...........

okey thanks sknake for your suggestion ................
well can you tell me how can i implement what Dimonddrake said.........
" when you needed to play them create a memory stream from the resource and play it from there, or copy it to temp, play it then delete it afterwards."

You can check out this article over at msdn. It outlines adding embedded resources to a project. Embedded resources are stored in a resource file rather than in their native format on the harddrive. They cannot be editted so this is only suitable for non-changing resources.

Never used it myself so i'm not sure how it affects embedded resources, but obfuscation helps to prevent reverse engineering of your software.
Although, as sknake rightly pointed out, if someone wants your media badly enough they will find a way...P2P sites abound with proof of that :p

I don't believe windows media player or most other video players support rendering a video from a managed .NET stream. Due to the large size of files they usually buffer internet streams to temp files on the harddrive and play, or temp files located somewhere else. If you use a linked resource and it contains a relative file path then the video file itself will be deployed as a standalone "file.mov" which is not the desired behavior as they could easily get at the movie. What you could do is embed the video as a resource and at runtime you could extract the contents of the resource to the windows %TEMPDIR%, play the video from the temp dir, and then delete it afterwards. A clever user will figure out how to rip the file from the temp dir.

You could use a non-standard temp directory but then you will run in to security issues where your app may work on some machines and not others. Again someone clever could just monitor the process for disk I/O and figure out where the reads are taking place and locate the temp file anyway so I think you will be causing yourself a lot of headache to hide the file in a non-standard-temp-directory.

So now that we have established that an embedded resource with a temporary directory is the best bet we need to implement it. First off please refer to this thread on embedding files as resources in your project:
http://www.daniweb.com/forums/thread215055.html

OK so now we have a movie file embedded as a resource and the above thread shows how to extract the resource .. but we need to extract it to a temp directory. So you would want to extract it like so:

Using GetTempFileName() also creates a filename like "tmpACC.tmp" so it is not obvious that file is a video file. It will be a large file so it is reasonably easy to deduce what files are videos

OK so now we have an embedded resource that we can play --- but I would add one more level of security that I will not cover here. There are programs out there (google "resource thief" or "resource hacker") that extract a program's resource items so you can rip off their artwork or other resources, which is exactly what you are trying to prevent.

In this code snippet:
http://www.daniweb.com/code/snippet217409.html

I have an example of encrypting a string with the Rijndael encryption classes in the .NET framework. You should look in to how to encrypt your entire video file using streams and then embed the encrypted video. At runtime you should decrypt the embedded resource, and write the decrypted contents out to a temp file. This will essentially make resource thiefs useless against your assembly since the video contents are encrypted.

Oh and be sure to keep in mind that .NET assemblies can be decompiled using reflector. That being said you need to hide what you are doing with the encryption:
* Put the initialization vector and keys in two different classes, located in two different files.
* Use ROT-13 encryption on the stored keys. This will further obfuscate the true keys
* You could also encode the keys differently
* Make the keys longer than you need. IE if you need a 16 bit key then use a byte[] array of 1000 and take out the middle 16 bytes
* Dont reference the keys directly in code. Use reflection to access the member so you don't have a strong link between the decryption mechanism and the keys

But all of this work can still be undone if they decompile the code, right?
Yes. It can. Use a .NET Code Obfuscator when you build your releases.

But can't they still rip the video stream that is being sent to the video card for rendering?
Yes, they can. With vista and later the video can be encrypted with AES accessible only to the operating system and video card. You could use a license to sign your video file. Read here for more info:
http://www.sharewareconnection.com/d...n-solution.htm

But with all of this work I still have a plan video file located in the temporary directory. Isn't all of this work undone if they locate the file?
Yes, it is. If you can find an embedded video player that lets you control the file position and how it reads the file then you could write a bunch of trash to the file, then good video, then more trash, then more video, continue. You could then instruct the video player on what segments of the video file to read.

I hope this helps ... and proves that all of this work is hard, a pain in the ass to support code for, and can still be worked around.

I couldn't have said it better myself sknake! I think the best practice would be, if you are scared someone will copy your video, put a watermark on it. that way if someone does copy it, its obvious, and everyone knows where it came from, that's one of the many reasons TV stations keep a logo at the corner of the screen.