. An alternative way of putting it is that this is my justification for purchasing what will amount to a $4000 camera!Import: which format works well?
Since Cinelerra is rather picky about the types of video it accepts (see my original Quicktime compatability document), it was a challenge to find a Cinelerra-editable intermediate format for that test 1080p video I told you about in the first part of this two-part blog entry. The video is a five-second city scene of a bicycler launching from a stop. That video is 23MB.
Keep in mind that various versions of media encoders (like ffmpeg and mplayer) do not always implement codecs and container formats consistently. Also, program dependencies for the encoders across different Linux distros complicate matters. So what I state as working below may not work for you. (Your mileage may vary). Note that I am currently using Fedora 7, 64-bit.
Caveats aside, transcoding the biker video to the following formats did NOT work:
- I420 from ffmpeg
- rawvideo (RAW YV12) from ffmpeg
Here are a couple formats that did work:
1) MJPEG output from ffmpeg
2) RAW YV12 output from mplayer
MJPEG from FFmpeg
Playback Performance
This format seems to be a likely candidate, as I got about 15fps on my dual, quad core Dell SC1430 in Cinelerra.
File Size
The resulting file size is small..about 35MB for five seconds of 1080P.
Image Quality Compared to Original
The image quality is very good. However, the colors seem bit oversaturated and dark in contrast to the original. With a bit of tweaking to the conversion command, I might be able to get more realistic colors out of the conversion. Here's a comparison shot:
Editing Notes
No problems surfaced with a couple initial edits and renderings. As this is a compressed format, there will be some loss of quality over successive encodings.
Here is the command I used to convert the video:
ffmpeg -i Video1.MOV -b 3000k -vcodec mjpeg -ab 256k -ar 44100 -acodec mpeg4aac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 testmjpeg.mov
This is the same conversion command that I ran in part I of this blog entry.
Information about the file looks like this in mplayer:
Playing testmjpeg.mov. ISO: File Type Major Brand: Original QuickTime Quicktime/MOV file format detected. [mov] Video stream found, -vid 0 VIDEO: [jpeg] 1920x1080 24bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG decoder) ==========================================================================
RAWYV12 from mplayer
Playback Performance
Playback is slow, 7fps, roughly 1/2 the speed of MJPEG. Not a show stopper.
File Size
Huge. About 450MB for about five seconds of video. Woah!
Image Quality Compared to Original
Image quality is very good as well. Less saturated then the mjpeg version. That's what almost 100MB/sec pays for.
Editing Notes
This is an uncompressed format, corresponding to the YUV 4:2:0 spec:
http://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y.27V12.29
Also, here is an excellent article on understanding color sampling:
http://www.dvxuser.com/articles/colorspace/
Cinelerra loads the raw YV12 file, but the timeline does not show thumbnails. Not a show stopper, but a bit of a bummer. The one benefit of yuv4mpeg stream from mplayer is that you can feed that stream directly into mjpegtools for further processing.
Update 2008/11/22
It seems that 1080p in raw yuv format is actually unusable in my Fedora 9 Cinelerra install. When I load a project with a large raw yuv file, Cinelerra hangs for ten minutes as it loads the file. Once loaded, the GUI tends to freeze for another ten minutes. Thus, it seems that MJPEG may be my only choice for rendering 1080p.
I will continue to experiment.
end update
Here is the command I used to convert the video:
mplayer Video1.MOV -vo yuv4mpeg
I received this message while trying to convert the video
************************************************
**** Your system is too SLOW to play this! ****
************************************************
Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
- Try -ao sdl or use the OSS emulation of ALSA.
- Experiment with different values for -autosync, 30 is a good start.
So, I amended my command to add the autosync feature, which gradually adjusts the audio/video synchronization based on audio delay:
mplayer Video1.MOV -autosync 30 -vo yuv4mpeg
That seemed to alleviate the messages. Without redirecting to a specified filename, Mplayer outputs a file called "stream.yuv".
Information about the file looks like this in mplayer:
Playing stream.yuv. YUV4MPEG2 file format detected. YUV4MPEG2 Video stream 0 size: display: 1920x1080, codec: 1920x1080 VIDEO: [YV12] 1920x1080 12bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 1920x1080 => 1920x1080 Planar YV12 [ASPECT] Warning: No suitable new res found! [ASPECT] Warning: No suitable new res found! Selected video codec: [rawyv12] vfm: raw (RAW YV12) ==========================================================================
Quality
There seem to be quite a difference in the colors rendered by each format. The MJPEG-formatted file seems to much closer to the original than the raw YV12.
Applying Effects
For fun, I applied an oil painting effect to this five seconds of video. I then rendered the output to MJPEG format. I was disappointed to find out that five seconds of video with the oil paint effect applied takes a full three minutes and twenty seconds to render at 1080p in my dual, quad core Dell SC1430. Holy cow! I guess I won't be doing Star Wars green screens in 1080p!
In the interest of full disclosure, the oil paint effect is a notorious CPU hog and is not indicative of the type of work the average editor will perform. Another note: while rendering the output, all eight CPUs were maxed out at 95% utilization. Kowabunga!
To give people hope, applying a simple title to the image doesn't do too much damage to load on the CPU. The video with a title rendered to MJPEG format took twenty seconds.
Thoughts
My goal is to get some really fantastic looking video rendered from Cinelerra. In combination with the new Canon and some wise encoding choices, I believe I should be able to do this. This article shows that I'm getting closer, but I'm not there yet. I'm hoping to get closer with another round of experimentation.
One final thing..be ready to spend money on RAM. I noticed my paltry 2GB was immediately sucked up by Cinelerra when I was doing these various test videos. I'm going to get another 4GB and will let you know if that helps.
more to come.
The Mule
No comments:
Post a Comment