For more details, and talks in past semesters, consult the full schedule of talks.
Past topics can (and should) be repeated occasionally. In addition, here are some topics people might like to hear about:
To give a talk, please contact swig@math.arizona.edu.
Below you will find an overview about videos. The first section gives some essential background information about videos. The second section describes how to build a video (without sound) from images using command-line unix tools. The third section discusses embedding videos in LaTeX presentations and things to consider when creating those videos.
A video consists of two main parts: video frames and an audio track. However, these two parts can be packaged in many different ways.
The inner layer of packaging are the video and audio codecs. These codecs determine how the video frames and audio track are compressed. Some examples of video codes are MPEG-4, MJPEG, H.264, and RAW. Some examples of audio codecs are MP3, AAC, WAV and RAW. RAW formatting indicates that the video and audio remains uncompressed, so the file size will be much larger but will be handled by a wider range of players.
The outer layer of packaging is the video filetype or extension. This extension will either be recognized by programs (e.g. Windows Media Player, Quicktime) or not be unrecognized. If it's not recognized by a given program, obviously the program will not play files with that extension. However, even if the filetype is recognized, the program may not have the video or audio codecs required by the inner layer of packaging (described above).
To summarize, one must be careful when creating a video file to consider where the video will be played. Below I will describe how to create videos from images (without sound) using command-line unix tools.
This section will describe how to successfully create videos from a series of images (without sound).
I will assume to start will that you have a series of images in PNG format: frame_000.png, frame_001.png, etc. The exact title is not important, just that they are numbered in order so that the images are easily sorted. Note: PNG images are good to start with because no information is lost in their compression as opposed to formats like JPEG. Since there are many steps in the process you'd like to ensure that information is not lost in compressions from step to step.
Since not all PNG files are formatted the same way, we first must ensure that each file is the approriate input type for the conversion tools to be used. The required type will be any 8bit PNG format. To convert the first PNG file to an 8bit PNG format type pngcrush -bit_depth 8 -force frame000.png 8bit_frame000.png (This must be done for each file).
The next step is to convert each PNG file to a PNM format. To do this for the first file, type pngtopnm 8bit_frame000.png > frame000.pnm.
Now we want to combine all the PNM files into a single PNM file, which can be accomplished by the following for-loop: for i in *.pnm; do cat $i >> all_frames.pnm; done;. Note: before you do this, make sure that all_files.pnm does not exist, as you are not overwriting it but appending to it.
Now we can convert all_frames.pnm to a video stream. But to do so, we now need to specify the speed that these images will be played in frames/second. To specify 1 frame/second, type pnmtoy4m -F 1:1 all_frames.pnm > movie.y4m
Finally, we can now generate a video to be played and in doing so must be careful to select the approriate video codec and container format (as described above). We also must again specify the speed of the video. To create an AVI filetype with MJPEG encoding and a framerate of 1 frame/second, type ffmpeg -i movie.y4m -r 1 -vcodec mjpeg -sameq movie.avi (the "-sameq" option indicates that the quality of the output should attempt to be equal to the quality of the input).
I will discuss some considerations for video codecs and container formats, and appropriate ones for LaTeX presentations.
One can add an embedded video to a LaTeX presentation using the movie15 package, which is automatically included in the Beamer class. However, this does not mean that an embedded video is actually part of the PDF document. In fact, it is not and must be sitting in the same directory. As a result, LaTeX is not concerned with the codecs used to create the video, but only with the extensions associated with the video (as described above). LaTeX will handle AVI and MP4 extensions (and possibly others).
One must not only consider which video extensions can be included in a PDF document generated by LaTeX, but also which ones will be handled by standard PDF viewers such as Adobe Acrobat Reader. In fact, Adobe Acrobat Reader may handle different extensions under different operating systems. Under Windows XP Service Pack 2 and Mac OS X 10.5, AVI filetypes are handled by Adobe Acrobat Reader. Under Linux, the situation is more complicated.
Although embedded videos may appear to play from Adobe Acrobat Reader, the Reader is actually using another program to play the file. Under Windows the default is Windows Media Player, whereas under Mac the default is Quicktime, which brings us to our final consideration. Different video players handle different codecs by default. I used MJPEG above since it is the only video codec that is available by default in both Quicktime and Windows Media Player.
Unfortunately, by using MJPEG, the compression scheme is not nearly are good as other available codecs and the file size may be significanly larger as a result. However, compared with RAW video, the MJPEG file is significantly smaller.
The last consideration that I would like to mention is that MJPEG is not a lossless compression scheme, which means that information is lost in the compression process. Ideally, one prefers lossless compression schemes, where all information is maintained during the compression processes. Note that the "msmpeg4v2" video codec could be used instead of "mjpeg" but the output AVI file would not play by default under Mac OS X. To see a list of all the available codecs for FFMPEG, type ffmpeg -formats. For presentations, I believe that having universally handled filetypes and codecs may be worth the tradeoffs incurred.