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
As I work to produce higher quality video, one of the things I've thought about is the possibility of getting my material aired on cable TV. So the Broadcast Standards discussion in the above Wikipedia article was very interesting. Also, it occurred to me that I've never properly understood the differences between fields and frames, in the context of telecine, or how film is transferred to video. The Wiki article above clarified it for me and is highly recommended.
Fields and frames are also useful in the context of how Cinelerra processes video.
Rendering High Quality H264 video
It 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.
Without going into the highly technical details of the H.264/MPEG-4 AVC standard or how video compression works, here is a somewhat simplistic analysis: "..it's slightly better to have dimensions divisible by 16, but only because H.264 divides up a picture into 16x16 blocks and if you have a partial block it still has to expend time and bandwidth on it. 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 that no longer exists.
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: 1536x864 1280x720 768x432 512x288 256x144 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 (again, no longer exists) 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.
Finally, this bitrate calculator for was something useful I stumbled up while researching this post.
-- the Mule --
Sven recently published a guide talking about what happened to Kino and its official website, and you can check it here,
https://www.videoproc.com/
Hello, Robert Swain here. :) It's better to use the preset files from either the 0.5 release or a current svn checkout of FFmpeg as the ones I hosted on my site were written before they were included in the FFmpeg code base.
ReplyDeleteThanks for the clarification, Robert. And thanks for the presets..they are really instrumental in simplifying the hornet's nest of libx264 parameters for the average user.
ReplyDeleteYou wouldn't happen to be going to the Open Video Conference in NYC on June 19/20, would you?
http://openvideoconference.org
We FFmpeg developers were invited but I don't think I have the time/funds to attend I'm afraid. I'm doing lots of other travelling this year. Maybe some of the others will be going. I hope flame wars about Theora (and how crap it is) don't burn the place down. ;)
ReplyDeleteI poked around the schedule of talks and luckily, it doesn't seem like there are any Theora-specific talks. But as the prime open video standard, it may get ugly!
ReplyDelete;)
I'll be there doing a real short Cinelerra demo.
You have any interesting conferences coming up?
It may be pushed and even 'accepted' (thinking of HTML 5 video tags) as the 'prime' video format but frankly it isn't. If some lawyers wanted to find some patented part of it, I have little doubt that given time and money they could.
ReplyDeleteIn any case, H.264 is the globally 'prime' video format. It's used for HD Digital Video Broadcast (television), for Internet media (Flash videos), for HD hard copy media (Blu Ray), for HD digital video recording (AVCHD cameras) and more. It seems to me like H.264 has already won.
Theora is too little too late. Its current implementation is poor and its technical features, in terms of its specification, are quite outdated so even when the Thusnelda branch is improved to the point of being good, it will not be competitive.
In fact, our 'resident' experts in the video compression field often say that MPEG-1 video may as well be promoted instead and may even be better because at least its patents have expired and so there is definitely no issue with it.
Don't misunderstand us (not that I'm representative, merely proxying comments I've seen really), free, royalty-free, open standards are definitely welcome. Theora just seems to be a bad one. It seems destined to fail even before it was released. But, we'll see. :)
I wanted to go to Linuxtag with FFmpeg, but I'm not sure I'll have the time/funds to attend that.
I totally agree with you. From an end user perspective, the quality and compression of H.264 blows everything else out of the water. Also, almost all media players accept H.264 versus Theora. I've always chosen H over T simply because my friends aren't Linux hacks like me and I just want my videos to be viewed by the widest audience possible.
ReplyDeleteLinuxtag looks very cool, though I am locking down expenses, too.