How can I correct the PAR in an MP4?

[eathasa]

Hi, I have an MP4 file created by Nero Recode that has an incorrect pixel aspect ratio (10:11 when it should be the oddball 3:4).

I want to correct the file to indicate the right PAR, and ideally avoid reencoding the video/audio information in any other way.

MP4, Nero Digital H.264/AVC High Profile with DD2.0 AC/3 audio.

I tried using mp4box, and it did change the PAR flagged at the mp4 container level, but the resulting video has very low compatibility with players on my system (only VLC plays it with the new PAR; directshow players all use the old PAR, and Quicktime generates an error and refuses to play it).


Got in this situation apparently due to bugs in Windows Media Center (the DVD is of a digital TV recording, burned from WMC, and WMC encoded it wrong. Nero was able to crop as needed but not correct the PAR).

I see Handbrake options that appear to allow me to set the correct PAR, but it looks like Handbrake will reencode the video - requires me to set a bitrate/quality.


Anyone know how I can accomplish this?
Thanks!

[upyzl]

Hm... It seems that roozhou's ffmpeg may help you: http://forum.doom9.org/showthread.php?t=152419

[eathasa]

Thanks upyzl!

Strange to me how hard to find this feature is. That tool does appear to have the feature I'm looking for, but unfortunately it didn't work right for me. The project is non-critical,... it wasn't supposed to be a "project" to begin with! When I have the time to play with it some more I will ask roozhou who appears to be active here and actively developing his ffmpeg fork.
Another alternative might be re-ripping the DVD, if any encoding/ripping software can better handle PAR correction (with the ability to crop the image) at that stage.

For historical accuracy, the Quicktime trial I mention in my first post is invalid: The original mp4 generated by Nero generates the same error as the modified mp4 I noticed the error with. Perhaps due to the encoding features I enabled (8x8 transform / High Profile? AC-3 audio?) -- Anyway, that is an unrelated (and unimportant) issue.

[b66pak]

for qt and h264+ac3 change the extension from .mp4 to .m4v...
_

[SeeMoreDigital]

You can also change the PAR value of AVC video streams using YAMB...

[eathasa]

Oh, good to know re. Quicktime!
I considered YAMB, but it's a front-end for mp4box, which only changes the PAR at the container level, and the resulting mp4 doesn't play with the the corrected PAR in most video players that way -- at least on my system.

[SeeMoreDigital]

Oh, good to know re. Quicktime!
I considered YAMB, but it's a front-end for mp4box, which only changes the PAR at the container level, and the resulting mp4 doesn't play with the the corrected PAR in most video players that way -- at least on my system.
You are wrong...

YAMB is able to change PAR values at the video stream level

QuicktimePro and MP4muxer is able to change PAR values at the container level

[eathasa]

I got the understanding that mp4box (and yamb) change the PAR at the container level from the following 2009 discussion thread: http://forum.videohelp.com/threads/301849-Change-Aspect-Ratio-of-mp4-without-re-encoding -- at least two posters made that statement.

My experience seemed to reinforce that understanding: I used a March 2, 2011 Kurtnoise compile of mp4box (v0.4.6-DEV-rev2735), and changing the PAR on my mp4 worked only if the mp4 was play in VLC, but not in any other player. Also, it applied the change almost instantly, whereas the roozhou ffmpeg fork took some time to process the whole file and change all the SPS records, but the resulting file did NOT show the PAR correction in VLC -- it was ONLY corrected in directshow players! (I'm simplifying my results with this ffmpeg, as there were other issues with my results too).

In any case, neither program seemed to correct it and create a fully compatible, fully corrected file. Using them in combination, in either order, did not solve the issues either.

[eathasa]

Actually the term "video stream level" is quite possibly more accurate as to what mp4box (and yamb) does for the PAR than the term "container level" I've seen mentioned in a few places including the videohelp link I posted;

YES, when I tried mp4box, I did specify the video stream on the commandline. Nonetheless, it applied the change almost instantly, indicating it was not changed THROUGHOUT the videostream -- I suppose that would be at the "SPS level" that the ffmpeg fork tries to address.

[roozhou]

@eathasa
What problem did you get with ffmpeg? ffmpeg changes PAR in both "SPS level" and container headers. Since the modifying PAR in SPS may change stream length, it is not possible to apply in-place but a full remux is required.

[eathasa]

Hi roozhou --
What a helpful forum this is :)
Thank you for your work on the ffmpeg fork - it seems to be filling a hole!

I was finally able to mux a file that plays with the correct aspect ratio in all the players I tried -- yay!

I have some fairly minor concerns with the output from ffmpeg that I will explain to you .. but I will get back to you on that. I just spent a lot of time typing a message here detailing all that but accidentally hit a link with my mouse and when I hit "back" in my browser to get back to this thread, my detailed message was gone. :/...

One significant oddity/confusion for me was that the SAR had to be set to 3:4 to get my desired PAR of 3:4. I also used the aspect command line option to set DAR to 4:3 (I got inconsistent playback aspects in different players without that)

SAR × PAR = DAR (Pixel aspect ratio - Wikipedia (http://en.wikipedia.org/wiki/Pixel_aspect_ratio))
DAR=4:3, PAR=3:4
Solving for SAR:
SAR = 4:3/3:4 = 16:9

The same Wikipedia article explains that SAR is simply the pixel ratio (pixels wide/pixels high); in my case:
SAR = 704:396 = 16:9

Does SAR have a different meaning to ffmpeg?

[nm]

Does SAR have a different meaning to ffmpeg?

For x264 and FFmpeg (and most other modern video tools),

SAR = Sample Aspect Ratio = Pixel Aspect Ratio

[roozhou]

I recall someone in this forum introduced FAR (Frame AR) to avoid confusion between Sample AR and Source AR.

[J_Darnley]

Just use the frame size. Stop the TLAs

[eathasa]

Ah, well, that would explain it :)

Next question: Why is it necessary to set both the sample aspect ratio and the display aspect ratio -- if either one is honored, the other is a given. Is there a reason that both values are stored and can be inconsistent with each other?

[eathasa]

J_Darnley - haha, I had to think about that for a minute. And yes, they make things more complicated, especially when you invent new ones, but they do save on typing, too. For command lines arguments, I like it when both a long form and short form argument are defined. For general usage, though, a minimum of abbreviations is best, since communication is the objective.

I assume sample aspect ratio was named that because the concept of "sample" was somehow better or more forward-thinking than pixel, but pixel is the common person's term for the addressable picture elements (hey, how about APE :D), and I would think I knew what "PAR" was in this context without prior experience or reading the manual.

[roozhou]

Ah, well, that would explain it :)
Next question: Why is it necessary to set both the sample aspect ratio and the display aspect ratio -- if either one is honored, the other is a given. Is there a reason that both values are stored and can be inconsistent with each other?
Because sar is not always honored by players. Some players (e.g. QuickTime) requires a valid DAR value in MP4.

IMO DAR should not be set unless there is no place to put sar in the bitstream(e.g. WMV3). So ffmpeg build from my fork does not write DAR for mkv since no player requires DAR in MKV.

[sneaker_ger]

That violates the Matroska spec as then the DisplayHeight and DisplayWidth are to be interpreted as PixelHeight and PixelWidth. A spec compliant player would have to display the file as SAR 1:1.

[SeeMoreDigital]

Because sar is not always honored by players. Some players (e.g. QuickTime) requires a valid DAR value in MP4.Actually, Quicktime player does not respect aspect ratio signalling placed at the "video stream level" at all. It looks for it at the "container level"... The Apple guys refer to it as a "Transformation" option.

And in-case any of you are interested (with the exception of the Apple TV player) not a single hardware player respects "container level" aspect ratio signalling whether it be .MKV, .MOV or .MP4!


Cheers

[sneaker_ger]

And in-case any of you are interested (with the exception of the Apple TV player) not a single hardware player respects "container level" aspect ratio signalling whether it be .MKV, .MOV or .MP4!

PopCornHour C-200 respects mkv AR info for h.264 AFAIK.

[SeeMoreDigital]

PopCornHour C-200 respects mkv AR info for h.264 AFAIK.No, it picks up the aspect ratio signalling from the video stream!

Indeed, Mosu had to modify MKVmerge GUI some time ago, so it no longer removes aspect ratio signalling at the stream level "by default"...

[sneaker_ger]

No, it picks up the aspect ratio signalling from the video stream!

I read on their forum that they implemented it in one of their firmware updates, but I don't own one so I cannot verify.

[SeeMoreDigital]

I read on their forum that they implemented it in one of their firmware updates, but I don't own one so I cannot verify.
Thanks for letting me know... lets hope somebody can indeed confirm.