Friday, January 30, 2009

For the last few years, I've been working with 720P content. With the recent purchase of a Canon 5D, I'm now working with 1080P video. Both formats are in 16:9 aspect ratio.

720P video implies a horizontal resolution of 1280 pixels, 1280x720 frame resolution with a total of 921,600 pixels.

1080P video implies a horizontal resolution of 1920 pixels, 1920x1080 frame resolution with a total of 2,073,600 pixels.

Though this is a blog on Linux video editing, I heartily welcome good information on the often confusing subject of video compression. Here is an article on Apple's site that conveys the basic information you'll need to understand about encoding H264 videos:http://www.apple.com/quicktime/tutorials/h264.html

Rendering High Quality H264 videoIt is important to understand aspect ratio in the context of rendering high quality video. Lately, I've been encoding H264 video; specifically, I've been reducing the size of my videos to load onto an iPhone/iTouch. For this task, one of the easiest ways to assure best output quality is to make sure that both the height and width of the rendered output are divisible by 16.

A size that is an exact multiple of 16 H & V will compress a tiny bit more efficiently, or look slightly better at the same bitrate."-extracted from this conversation

To make sure the dimensions of my videos are always divisible by 16, you can do the calculations yourself, or take a look at a couple nice charts from Andrew Armstrong's site to help you choose dimensions where the height and width are both divisible by 16. To make it easy for you, there are only a few choices:1536x8641280x720768x432512x288256x144

This will avoid the dread "width or height not divisible by 16, compression will suffer" error you would see in many H264 encoders.

Robert Swain's blog was very helpful in determining x264 parameters that yield great looking video. Especially the page regarding ffmpeg presets, though I haven't yet determined what preset is best for my content. The presets listed on Robert's page need to be put into a .ffmpeg directory under your user's home directory.

Sunday, January 25, 2009

I had a bit of a rough day yesterday. I started early, about 8am, upgrading my MacBook Pro to Leopard. That process went more or less smoothly and finished around noon. Next, I had taken some video the night before and wanted to create a video that would serve as a table of contents to my archive. Also, this short video might enable me to market some of my source material as stock footage. So it might be a fun little project that shouldn't take long. I should know to never say "shouldn't take too long", because things have a way of blowing up in your face when you don't expect them to.

Converting 1080P directly to an iPod-ready formatThe goal was to convert some 1080P video from my Canon 5D directly into an iPod readable format. However, as I was overly tired on this day, my mind defeated me. Essentially what happened was that after I rendered out the video and loaded it to the iPod, I kept seeing only three quarters of the video. Flummoxed, I thought it must be a rendering problem. Long story short, I found that the problem was not with my rendering parameters, but the fact that my iTouch has a zoom/scaling feature that I forgot about, but had enabled. Here is the little bugger:

So I had spent about three hours until 2am fighting with encoding parameters, re-encoding video, transferring many test files to my Mac and then loading them to the iPod, only to find that the source of the problem was this little stupid icon on the iTouch.

Boy, am I dense.

A Learning ExperienceI did learn a few things through my travails this weekend:1) The el cheapo haze filter on my camera shows a lot of lens flare and needs to be replaced.

3) When encoding videos to H264 format, always try to use resolutions where the height and width are divisible by 16. This will make the level of compression and quality of the resulting video better. I will post separately about resolutions that are divisible by 16.

I had previously been using this string of encoding parameters to encode a video of my band rehearsals. The encode was from a DVD source file, so perhaps I will just use the 1080P as source going forward. I will have to test this out first. Strangely, the conversion of the audio from AC3 format had audible hiccups from time to time. Since this process was working fine on Fedora 7, perhaps this is just an issue with Fedora 10.

Downrezzed 1080P Video Ready for the iPodThe following two pass Cinelerra encoding parameters via yuv4mpeg stream worked well to produce a high quality video from 1080P source. In short, you will do two renders from a YUV4MPEG stream:render 1: the pipe to /dev/null in order to create the optimization logrender 2: the pipe to create the file

I chose a resolution of 512x288 because:1) the aspect ratio is the same as my 1080P source video, 16:9 (1.777)2) both the height and width are divisible by 163) there were no errors and it comes out looking great on the iPod

Rendering Parameters for a High Quality Vimeo UploadFinally, I was able to output an H264 video at 1920x1080 that looks great in Vimeo. Psych! I was able to remove the ugly bottom bar seen in Vimeo from my previous post. Here is the two-pass encoding method that I used from Cinelerra. Two notes:1) the two passes are YUV4MPEG stream renders from Cinelerra using FFMPEG and will need to be run as individual renders in Cinelerra.2) the second pass muxes (combines) a pre-rendered audio stream with the video stream. So you'll need to render that audio file first.

ConclusionThrough pain, there can sometimes be the brighter side. In this case, I learned a few things. In retrospect, I may have chosen my production company's name correctly. A mule is one stubborn beast.

The ProjectMy goal with this short production was:1) to show the capabilities of the camera2) to prove that Cinelerra was up to the task of editing 1080P content3) to output the final results to different output formats (media player, Vimeo, back into Cinelerra)

I'm a hobbyist, so I don't have a budget and "script" like Vincent Laforet. However, I like to compile scenes and organize them with musical accompaniment in thoughtful ways that are (hopefully) enjoyable to the viewer.

In regards to the imagery, about half of the shots were taken with a tripod. Where you see shakey video is obviously where I held the cam by hand. You definetly do NOT want to shoot high definition video by hand. It serves to amplify any wobbling present and looks terrible when presented on a high definition television. One thing that saved me was the stabilization provided by the Canon L series zoom lens. It is very effective in dampening bounces, though the stabilization mechanism is loud and is picked up by the camera's poor quality, but usable internal stereo microphone.

I used the 50mm mainly for the indoor shots and the zoom for the outdoor shots. I shot some of the outdoor night shots with the zoom, but then realized that the zoom doesn't do well in low light conditions since it has such a long zoom barrel. So just last week, I bought the 50mm. The 50mm fixed length (prime) lens really makes night shots clear with none of the spotty, dappled artifacts that you see with high ISO night shots. During the video, you'll notice those artifacts on the shot of the ferry.

Note that I used no filters on the shots..what you see in the video is truly what you get with the camera. As I gain expertise with the camera, I look forward to acquiring lenses over the next few years.

Once loaded in Cinelerra, I found I had quite a few assets from the last couple weeks of shooting.

If I could have one improvement made to the software, it would be to add folders to the Media bin in order to better manage assets.

I went about editing the video as normal. I applied only time-based effects, like speeding up or slowing down the video, and transitions. The time-based effects were accomplished by attaching the ReframeRT video effect:

OutputI needed to output files from the project for different purposes:1) to reimport back into Cinelerra (JPEG or MJPEG Quicktime video)2) to export/render a format usable with my MG-350HD Media Player(1080I/1080P MPEG2 video)3) to export/render a format usable for Vimeo (720P MPEG2)

For #1, I exported a Quicktime for Linux container, using MJPEG compression. I just needed the video, so I had no audio on the export. I was able to reimport the resulting file easily into Cinelerra.

Update 2008/01/13I hadn't noticed before, but after I uploaded the 720P file to Vimeo, there was a little bit of a line on the bottom of the video. I am going to have to revisit the edit to make sure I didn't mess something up.*** end update ***

I think the quality of the output can definitely be improved. However, I am glad that I was able to output to formats usable across different platforms (HDTV/Internet/Linux-Cinelerra).

Update 2008/02/08I've been working on improving the quality of the output from Cinelerra. Specifically, instead of using MJPEG source files (the first conversion from the cam), I'm converting the Canon's video to MPEG2-TS. The MPEG2-TS format has very nice quality and edits quickly in Cinelerra. Here's the full skinny:/2009/02/dark-of-winter-has-me-in-its-grasp.html*** end update ***

In SumDealing with a new media format in Linux and Cinelerra is never easy. But if you have patience, it is very satisfying to get a project done that makes your friends say "Wow" or have a laugh.

Here's an image that compares the original, Canon saved H264 video to the MJPEG conversion:

Pretty close, eh? The MJPEG video seems a little lighter and you can see more detail, though the colors are a little washed out.

2) Import into CinelerraUnlike the H264 format the Canon saves, the MJPEG conversion imports cleanly into Cinelerra without error messages. Also, on my dual, quad core Dell running Fedora 10, I get about 18fps playing back the raw video. Nice.

3) Render to YUV4MPEG stream as H264 videoI do this step in two parts:

Since I'm on Fedora, the Vimeo uploader seems to hang. So for Fedora (and I'm sure other Linux distributions) uploads seem to work better using the Basic Uploader:http://www.vimeo.com/upload/video/basicThanks Raffa!

Why Mule?

"Mules are not really stubborn. They can seem lazy because they will not put themselves in danger. A horse can be worked until it drops, but not so with a mule. The "stubborn" streak is just the mule's way of telling humans that things are not right. Mules are very intelligent and it is not a good idea to abuse a mule. They will do their best for their owner, with the utmost patience."About Mules