Rendering 1920×818 or 1920×1080

[Dave Haynie]

Ok, a couple of things.

I believe the clock is an overlay/effect, right. That’s moving because it’s fixed relative to the frame, and when you render a project set at one resolution to another resolution, you change your frame size.

What’s your final target resolution. If you really want 1920×818, you need to set up your own template. That’s not a standard resolution. In fact, it’s not technically legal AVC… you need to have a resolution evenly divisible by 16. As long as you don’t care about Blu-ray, no problems.

If you’re not concerned about compatibility with other formats, set your project to 1920×832 or 1920×816 is you want to avoid possible weirdness rendering to any of the MPEG formats. You should choose an AVC output, start with one of the Internet templates, something close to what you want. Select “Custom..” on the Render As.. requester, and edit accordingly (eg, set the custom frame size). You can determine the audio rate on the audio tab here, and the container (MPEG-4, MPEG-2 TS, etc) on the System tab.

-Dave

[John Rofrano]

[Dave Haynie] ” In fact, it’s not technically legal AVC… you need to have a resolution evenly divisible by 16. “

There are different limitations for different codecs. In general, that statement can’t be true because 1080 is not evenly divisible by 16 and it is the industry standard for Blu-ray distribution.

I agree that some codecs have certain resolution restrictions but AVC is made for the Internet where there is no standard resolution. I can make a video any size I want to fit the space allocated by my web site. If you want to make an AVC video that’s 74 x 168 you can, and neither dimensions are divisible by 16. I do believe that they all have to be divisible by 2 meaning you can only render dimensions that are even numbers.

Where divisible by 16 comes in is the MPEG2 width. I believe the width of an MPEG2 file must be in multiples of 16 because of how the encoder processes macro-blocks but the height only needs to be divisible by 2. An MPEG2 file that is 96 x 38 will render just fine because 96 is divisible by 16 and 38 is divisible by 2.

Your recommendation of 816 is also fine. Either 818 or 816 will render fine as both AVC or MPEG2.

~jr

http://www.johnrofrano.com
http://www.vasst.com

[John Rofrano]

[Will Brown] “John has said that you cannot render 818 as its not a Blu Ray format:”

I’m not sure why you are using Blu-ray at all. You said “I am submitting my film to a distributor“. I assume you are sending them a file on a hard drive. I think you’d better check what formats they accept. That will determine how you should render.

[Will Brown] “Lastly, should I render at 24fps and not interlace it as I would like a film look?
(Project settings – Field order, none – Deinterlace method, none)”

This is a common misunderstanding but never, ever, NEVER, set your deinterlace method to NONE if you shot with an interlaced camera unless you are specifically placing some other 3rd party deinterlace plug-in on all of your footage. Do not confuse the project settings with the render settings. You will have huge problems if you do not deinterlace your interlaced footage properly.

So… check what formats the distributor accepts.

~jr

http://www.johnrofrano.com
http://www.vasst.com

[Dave Haynie]

[John Rofrano] “There are different limitations for different codecs. In general, that statement can’t be true because 1080 is not evenly divisible by 16 and it is the industry standard for Blu-ray distribution. “

Of course, you know that the Blu-ray specifications came directly from the ATSC specifications, the result of the “Grand Compromise” for HDTV. Part of that compromise was the enforcement of a 16:9 picture, a compromise between the computer industry’s demand for 16:10, and the film industry’s demand for 2:1.

Anyway, simple math tells you that 1920×1080 is a perfect 16:9 picture, given square pixels. Only one problem: ATSC is based on MPEG-2, which really does demand as I said; pixels sizes divisible by 16 for progressive, and vertically by 32 for interlaced.

So the ATSC folks hacked it… the ATSC standard actually broadcasts MPEG-2 as 1080×1088, the bottom 8 pixels always filler, and never displayed by display devices. Same with Blu-Ray. In the early days, this was something you had to deal with explicitly, but these days, the encoders and decoders all deal with padding/cropping automatically. So while we logically work in 1920×1080, deep down, it’s actually 1920×1088 on the disc or over the air.

[John Rofrano] “Where divisible by 16 comes in is the MPEG2 width. I believe the width of an MPEG2 file must be in multiples of 16 because of how the encoder processes macro-blocks but the height only needs to be divisible by 2. An MPEG2 file that is 96 x 38 will render just fine because 96 is divisible by 16 and 38 is divisible by 2.
“

Nope. The MPEG-2 spec requires progressive (frame coded) video to be encoded in multiple-of-16 resolutions in both horizontal and vertical, or multiple-of-32 for interlaced (field coded) video. The issue is the basic DCT macrocell, which is always 16×16 in MPEG-2. All recent encoders automatically pad out the cell… you can, for example, render from Vegas with just about no concern for pixel size… 94×38 or 92×34 works just dandy, too. But you’re still encoding 96×48 in each case. And in fact, Vegas always rounds up… no warning, nothing, but if you did render 92×36, you’d see your video a full 96 pixels wide. And if you played the resulting video in a much older MPEG-2 player, I bet you’d see the blank lines at the bottom, too. Some encoders stuff with black pixels, some just replicate the last line, which is in theory easier to encode (the x264 does it this way, a feature added about 6 years ago. Before that, you had to always specific mod16 resolutions).

My point in all of this… if you’re encoding for relatively arbitrary internet resolutions, why not get all of the resolution you’re paying for. If I encode at 1920×818, it’ll certainly work, but I’m paying for 1920×832, in terms of bit-budget, etc. So either use that extra space, or crop to 1920×816.

-Dave

[John Rofrano]

Interesting. I didn’t realize that padding was going on with the encoders. That’s good to know. So rounding up to a multiple of 16 is very desirable then. I’ll have to remember that. 😉

~jr

http://www.johnrofrano.com
http://www.vasst.com