Convert to 3d

http://www.maximumpc.com/article/howtos/how_upgrade_your_2d_movies_3d

saved here:
Unless you’ve been living under a rock for the last year, you know that 3D is this year’s entertainment buzzword. With 3D blockbusters like Avatar scoring megabucks in the theaters, 3D cinema’s jump to the living room is all but a foregone conclusion. But where does that leave all your old 2D files and DVDs?
Thanks to a couple of very cool programs and some clever scripting, there’s hope for them yet. In this article, we’re going to show you how to use AviSynth and VirtualDub, along with a script from the 3D Vision Blog to give any 2D film the 3D treatment.

Convert to 3D with AviSynth

To convert our movies to 3D, we’re going to start with a program called AviSynth, so point your browser at bit.ly/2EO5A2 and download the newest version, then run the installer. You’re probably used to running most new programs after you install them, but don’t bother trying with AviSynth—it doesn’t have a user interface. Instead, it functions as a codec, allowing media viewers such as Windows Media Player to understand AviSynth scripts, in the form of AVS files.
As you may have guessed, we’re going to use one such AVS script to upconvert our 2D file to 3D. It’s not magic—the script simply exploits some common visual cues to take a decent stab at applying a 3D effect to a 2D movie, but it’s certainly better than nothing. The script was written by the author at the 3D Vision Blog, and is available here. Go to the site, copy the script (it’s the first big chunk of code) and paste it into notepad.
Before we can use the script it needs a little customization. First, change the filename at the beginning of the script from “Avatar_Trailer_HD.avi” to the filename of the video you want to upconvert.

Save the script with a .AVS filename extension to the same directory as the video file.

At this point, you’re all set to view your movie in 3D. To do so, simply open a media player that works with AVS scripts (such as Windows Media Player) and tell it to open your freshly created .AVS file. Assuming you’ve done everything right so far, you should see an extra-wide version of your video, with two slightly different frames playing side by side. This is the 3D file, formatted to play with Nvidia’s 3D Vision technology. If you would prefer anaglyph (red/cyan) 3D, for use with a pair of filter glasses, you need to make a quick modification to your script. Comment out (by adding a # to the beginning of the line) the line that says StackHorizontal(f2, f1). Then, uncomment (by removing the #) the line that says # MergeRGB(f2.ShowRed, f1.ShowGreen, f1.ShowBlue).

Save Your 3D Video with VirtualDub

So, we’re looking at our video in 3D. Now we’re done, right? Not quite. AviSynth works in real-time, synthesizing an AVI (get it?) from a source file and a script, frame by frame, as the media player requests those frames. This is hard on your CPU, and means that if you want to view the file on any other computer, you’ll need to install AviSynth first. Instead, we’ll now show you how to permanently save the 3D video to your hard drive.
To save the movie, you’ll need a program called VirtualDub. VirtualDub is a lightweight, open source video editor which is especially good at quickly reencoding videos. Go to the VirtualDub site and download and extract the program.

The next step of the process is to make sure that VirtualDub has the tools it needs to make a high quality copy of the 3D movie. More specifically, it needs codecs—one for video and one for audio. The Xvid MP4 and LAME MP3 codecs are excellent, open source examples of each. If you don’t already have these codecs installed for use with some other media program, you’ll need to get them now. The Xvid codec can be found here, and the LAME codec can be downloaded here. Once you’ve downloaded both, run the installers to registers the Codecs in Windows.
Set VirtualDub to use Xvid by clicking Video -> Compression… and then selecting Xvid MPEG-4 Codec. Set it up for audio by first clicking Audio -> Full processing mode and then clicking Audio -> Compression… and selecting MPEG Layer 3.

Finally, open the .AVS file for your 3D video, and click File -> Save as AVI. Give your file a name, and you’re done.

testing ssl wireshark capture

http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/

How to decrypt SSL with Wireshark

Step one – set up an SSL-protected server to use as a testbed
To illustrate the process, we’re going to use OpenSSL to generate a certificate and act as a web server running HTTP over SSL (aka HTTPS) – it’s quite straightforward.
To begin with, we need to get ourselves a self-signed certificate that our HTTPS server can use. We can do this with a single command:
openssl req -x509 -nodes -newkey rsa:1024 -keyout testkey.pem -out testcert.pem
OpenSSL will ask you for some input to populate your certificate with; once you’ve answered all the questions, the output of this command is two files, testkey.pem (containing a 1024 bit RSA private key) and testcert.pem (containing a self signed certificate). PEM (Privacy Enhanced Mail) format files are plaintext, and consist of a BASE64 encoded body with header and footer lines. You can look at the contents of your key and certificate files in more detail like this:
openssl rsa -in testkey.pem -text -noout (output here)
openssl x509 -in testcert.pem -text -noout (output here; more info here)
We need to perform one tiny tweak to the format of the private key file (Wireshark will use this later on, and it won’t work properly until we’ve done this):
openssl rsa -in testkey.pem -out testkey.pem
Now we’re ready to fire up our HTTPS server:
openssl s_server -key testkey.pem -cert testcert.pem -WWW -cipher RC4-SHA -accept 443

The -key and -cert parameters to the s_server command reference the files we’ve just created, and the -WWW parameter (this one is case sensitive) causes OpenSSL to act like a simple web server capable of retrieving files in the current directory (I created a simple test file called myfile.html for the purposes of the test).
The -cipher parameter tells the server to use a particular cipher suite – I’m using RC4-SHA because that’s what’s used when you go to https://www.google.com. The RC4-SHA cipher suite will use RSA keys for authentication and key exchange, 128-bit RC4 for encryption, and SHA1 for hashing.
Having got our server up and running, we can point a browser at https://myserver/myfile.html and retrieve our test file via SSL (you can ignore any warnings about the validity of the certificate). If you’ve got this working, we can move on to…
Step two – capture some traffic with Wireshark
Fire up Wireshark on the server machine, ideally with a capture filter like “tcp port 443″ so that we don’t capture any unnecessary traffic. Once we’re capturing, point your browser (running on a different machine) at https://myserver/myfile.html and stop the capture once it’s complete.
Right-click on any of the captured frames and select “Follow TCP stream” – a window will pop up that’s largely full of SSL-protected gobbledegook:

Step three – configuring Wireshark for decryption
Close the TCP Stream window and select Preferences from Wireshark’s Edit menu. Expand the “Protocols” node in the tree on the left and scroll down to SSL (in newer versions of Wireshark, you can open the node and type SSL and it will take you there).
Once SSL is selected, there’s an option on the right to enter an “RSA keys list”. Enter something like this:
10.16.8.5,443,http,c:\openssl-win32\bin\testkey.pem
You’ll need to edit the server IP address and path to testkey.pem as appropriate. If this has worked, we’ll notice two things:

• Wireshark’s SSL dissector can look into otherwise encrypted SSL packets and dissect the protocol inside:
  
• We can right-click on any of the captured frames that are listed as SSL or TLS and select “Follow SSL stream”:

Nice
You can read about this step in the Wireshark Wiki here.

Why it works

So, why does this work? Our test server, in common with a very large proportion of HTTP-over-SSL webservers, is using RSA to exchange the symmetric session key that will be used by the encryption algorithm (RC4 in this case). Below is an extract from RFC2246:

F.1.1.2. RSA key exchange and authentication
With RSA, key exchange and server authentication are combined. The public key may be either contained in the server’s certificate or may be a temporary RSA key sent in a server key exchange message.
After verifying the server’s certificate, the client encrypts a pre_master_secret with the server’s public key.

The server can of course decrypt the pre_master_secret passed to it by the client (by using the server’s private key in testkey.pem), and subsequently both the client and the server derive the master_secret from it – this is the symmetric key that both parties will use with RC4 to encrypt the session.
But the server isn’t the only one with the private key that corresponds to the public key in the server’s certificate – Wireshark has it as well. This means it is able to decrypt the pre_master_secret on its way from the client to the server, and thereafter derive the master_secret needed to decrypt the traffic.