MP4 Playback Resolution

[kalorx]

Hi all. Is it possible to use MP4Box to set an MP4 video's playback resolution, like MKVmerge can with MKVs? I have a 720x364 backup video that I'd like to have a playback resolution of 853x364, but I'd like to encode the video at 720x364 to save on size and quality.

With MKV files all I have to do is set the display resolution to 853x364. There seems to be no such option with MP4Box.

Do I have to enter the display resolution into the H.264 video itself? Is that what the "SAR" setting is? If I entered 853x364 as the SAR setting, would the video still compress at 720x364 as I'd like?

[bond]

sar is what you need indeed

there has been a tool by seemoredigital which can calculate what you need iirc, you cant simply set 853x364 there :search:

[kalorx]

That guys seems to have made a lot of tools... I can't seem to find one that does what we're talking about. I found one sort of related, but it only works on WMVs.

[Zero1]

If you did want to set the aspect ratio, you can do it in MP4box by putting this line after the importing of the video:
:par=32:27

For example this:
mp4box -add "video.264" -add "audio.aac" -fps 23.976 output.mp4

Becomes
mp4box -add "video.264":par=32:27 -add "audio.aac" -fps 23.976 output.mp4

[SeeMoreDigital]

Interestingly, QuickTime Player Pro offers something called "Transformation". Which can be set to "up-size" or "down-size" the output resolution of video streams muxed into .MP4/.MOV, automatically upon playback.

http://img161.imageshack.us/img161/7237/visualsettingsvs1.png

However, the "Transformation-ed" files can only be viewed correctly in QuickTime Player (including their embedded web media player). All other software media players ignore the additional information stored within the container.


Cheers

[kalorx]

If you did want to set the aspect ratio, you can do it in MP4box by putting this line after the importing of the video:
:par=32:27

Interesting. It worked. How does the math work on this, in case I want to create other display resolutions?

I found a PAR calculator, and according to it, a 1.17:1 aspect ratio produces 32:27. But the my video is 2.35:1, and 32:27 produces a 2.35:1 display resolution, so I'm rather confused.

[kalorx]

Interestingly, QuickTime Player Pro offers something called "Transformation". Which can be set to "up-size" or "down-size" the output resolution of video streams muxed into .MP4/.MOV, automatically upon playback.

That's actually kinda cool. I just got Quicktime Pro 7 recently, and I've been doing a lot of experiments. While this ultimately doesn't help me with my current issue (I refuse to use the qt-player to watch anything but movie trailers), it's useful information to add to my ever-expanding knowledge base on these sorts of things. Thanks!

I also find it amusing that the new Star Wars trilogy (may George Lucas rot in a very dark place) is actually what I'm working with on my current project. :)

[SeeMoreDigital]

May I ask why you chose to generate your encode at 720x364 pixels (mod-4) and not 720x368 pixels (mod-16)?

[kalorx]

MeGUI gave me a warning about that, actually. 364 is exactly what I'm left with after cropping out the black bars from my 2.35:1 source. To maintain the best possible visual quality, I wanted to avoid -- upon playback -- resizing both the width and height and just resize the width. Combined with no resize at all for compression, I thought that was the best deal.

I made an educated guess that I'd be fine keeping it in mod-4, as this is the requirement for most other codecs. What am I missing out on not working in mod-16?

[bond]

Interestingly, QuickTime Player Pro offers something called "Transformation". Which can be set to "up-size" or "down-size" the output resolution of video streams muxed into .MP4/.MOV, automatically upon playback.

However, the "Transformation-ed" files can only be viewed correctly in QuickTime Player (including their embedded web media player). All other software media players ignore the additional information stored within the container.thats indeed possible (and described in my mp4 faq), but afaik nothing but quicktime supports it and therefore i wouldnt use it

[SeeMoreDigital]

thats indeed possible (and described in my mp4 faq), but afaik nothing but quicktime supports it and therefore i wouldnt use itIndeed....

The only video DSdecoder I can think of that "might" support some level of "transformation" (at the container level) is 3ivx's :eek:

EDIT: Here's a "video only" test sample (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/368x288_-to-_1024x432.mp4) (Served from my home PC)


Cheers

[Sharktooth]

MeGUI gave me a warning about that, actually. 364 is exactly what I'm left with after cropping out the black bars from my 2.35:1 source. To maintain the best possible visual quality, I wanted to avoid -- upon playback -- resizing both the width and height and just resize the width. Combined with no resize at all for compression, I thought that was the best deal.

I made an educated guess that I'd be fine keeping it in mod-4, as this is the requirement for most other codecs. What am I missing out on not working in mod-16?
It's always better to keep mod-16 resolution for compatibility.
Some tools/filters/etc will work with mod-4 and some other wont.
In your case i would resize to 368 (4 pixels wont distort the image too much) so the encoder will be more efficient (with non mod-16 resolutions there is a hit on compression) and it will be mod-16.

[kalorx]

Oh, alright I guess. :) I shall endeavor to encode my videos at mod-16... but instead of distorting the image, I'm just putting in black bars.

[foxyshadis]

Black bars will noticeably reduce the quality along the edges, much more than encoding to non-mod-16, and much more than resizing will affect the whole video. Your way causes the worst distortions possible. (Such a small resize will cause very minimal differences between input and output anyway.)

[kalorx]

Are you serious? For crying out loud. The very idea of enlarging the video height gives me the shivers... it will be in the back of my mind constantly while viewing.

If I stick with mod-4, what exactly am I missing out on? What tools and filters won't work with the video? If TDeint, Decomb, and ColorMatrix work fine, if I can load the video in VirtualDub and AviSynth, and compress it okay with MeGUI-x264 H.264, and mux into an MP4 or MKV container, what am I missing out on? I'm not going to stop using any of those tools and filters anytime soon -- and only those tools and filters.

[bond]

using mod 4 means that the encoder adds pixels itself to get mod 16. when playing that stream the decoder will crop again those added pixels so you dont see them

there simply is no not mod 16 mpeg video

[SeeMoreDigital]

Are you serious? For crying out loud. The very idea of enlarging the video height gives me the shivers... it will be in the back of my mind constantly while viewing.

If I stick with mod-4, what exactly am I missing out on? As Sharktooth already said: -

"It's always better to keep mod-16 resolution for compatibility.
Some tools/filters/etc will work with mod-4 and some other wont.
In your case i would resize to 368 (4 pixels wont distort the image too much) so the encoder will be more efficient (with non mod-16 resolutions there is a hit on compression) and it will be mod-16."

Which is why I mentioned it in the first place!!!!!!


Cheers

[kalorx]

Okay, okay... no need to get all "!!!!!" at me... I'm just trying to see all the angles; get exact information, that sort of thing. :)

I'm going to need that "par" setting (32:27) redone for me, though. Even after a fair amount of 'net research I never did figure out how that math worked. I'd like to maintain the aspect ratio as closely as possible. From a little experiment I've done, it seems all I'd need is the "32" altered; 27 seems to simply maintain the original height of the image.

EDIT: I did some experimentation, and determined that 30:25 would create width of 864, the closest width to maintain a 2.35:1 aspect ratio at a height of 368. I'd still like to know why that works, though; "par" seems to be a complicated topic. I've found a lot of information on the web, but none of it explains the "32:27" number.

And question: Why will black bars hurt the image quality even more? Is it just in the way that MPEG video encodes -- too much of a color differentiation? But MPEG-2 DVD video has black borders all the time...

[foxyshadis]

If someone's targeting PC playback, why bother with mod-16 resolution? Maybe if it was a standalone, or quicktime, but those have all kinds of restrictions anyway that the file might not be compatible with. x264 has such a small penalty for non-mod-16 that there's effectively no difference; xvid's also seems similarly small.

Non-mod-16 width can kill some filters, but filters rarely care about height beyond YV12 restrictions.

Changing the ratio only ever changes the width, it won't affect the height.

[kalorx]

Ah, new questions to consider from Foxyshadis (who has an awesome avatar). Doubt now once again wells up in my soul. Interesting points have been made. My videos are indeed intended solely for simple, "dependent" PC playback within an MP4 or MKV container divorced from Windows Media Player, the Quicktime Player, and the Divx Player. These videos will never be converted to anything else.

[foxyshadis]

btw, for Pixel Aspect Ratio, the math is similar to DAR: width(out) = width(in) * PAR. (DAR, for reference, is width(out) = height(in) * DAR) The only difference is whether you work with height or width to specify the AR. So if you know two things you can rearrange the equation to get the unknown.

When you have a number like 32:27, that's a ratio, another way of saying 32 / 27, or 1.185..., just a more mathy-way of writing it.

[giandrea]

On a related note... If I mux my "non mod16" raw h264 video file to MP4 with mp4box, when I play it back it shows the pixels that should be cropped, so it shows at 640x368 instead of 640x360... why? The same raw file plays perfectly with mplayer...

Are there other mp4 muxers that I could try? I tried ffmpeg passthrough to mp4, but it messes the video; I will try to compile mp4creator, but I think it's not mantained anymore...
Thanks,

giandrea

[giandrea]

OK, I just downloaded and compiled a fresh cvs of gpac, and the bug is not present anymore, now the muxed file has the correct frame size.