Change Pixels Aspect Ratio of mp4 files

Logged In: YES
user_id=1062728

What an excellent idea.

Currently I have to de-mux the video stream from MP4 to AVI
and use MPEG4 Modifier in order to change the PAR/DAR

However, MPEG4 Modifier only works with MPEG-4 SP and
ASP streams, not AVC streams.

Kurtnoise13's request prompts me to suggest further
implementations. Such as VOP and Quant Type analysis
and whether the stream is interlaced or progressive

Cheers

Logged In: YES
user_id=815447

latest MP4Box version on CVS has PAR modifying
capabilities, tested with both MPEG-4 SP/ASP and AVC
streams. PAR can also be specified at import time.

Enjoy it.

Logged In: YES
user_id=786427

ok i tried it and found two problems with avc:

on avc:

Code:
-add input.mp4#3:par=1:1
didnt work: "bad parameters" (3 was of course the correct
trackid)

Code:
-add input.264:par=20:10
on an input.264 that had already a par set, worked syntax-
wise but the output had no par set in the raw stream

Code:
-add input.264:par=20:10
on an input.264 that had NO par set, worked perfectly

on asp:

Code:
-add input.mp4#3:par=20:10
on an input.mp4 that had NO par (1:1) set, worked perfectly

Code:
-add input.mp4#3:par=20:10
on an input.avi that had already a par set, worked perfectly

Code:
-add input.avi:par=20:10
on an input.avi that had NO par (1:1) set, worked perfectly

Code:
-add input.avi:par=20:10
on an input.avi that had already a par set, worked perfectly

Code:
-add input.m4v:par=20:10
on a raw input.m4v that had NO par (1:1) set, worked perfectly

Code:
-add input.m4v:par=20:10on a raw input.m4v that had already
a par set, worked perfectly

another thing, not really a problem:
it seems mp4box writes the par always as "custom par" and
doesnt use the shortcuts for 16:9 pal (16:11) which i tested
for example (i think you can save a few bits by using the
shorts)

Logged In: YES
user_id=815447

I can't reproduce any of your pbs with my AVC test files.
Could you upload a sample for which PAR fails?

regarding pre-defs PARs for m4v, indeed they were missing,
should be fixed on CVS.

Logged In: YES
user_id=1062728

Hi Jean,

Over on Doom9, Kurtnoise13 reported that the following
custom DAR values worked okay: 16:15 for 4:3 PAL, 8:9 for
4:3 NTSC, 64:45 for 16:9 PAL or 32:27 for 16:9 NTSC

You can read more about it, from here
http://forum.doom9.org/showthread.php?
p=728546#post728546 - onwards!

Cheers

SeeMoreDigital

Logged In: YES
user_id=786427

i have the two problems noted for avc with this sample:
http://home.pages.at/bond_/anamorphic.mp4

Logged In: YES
user_id=815447

this should now be fixed on CVS, the par rewriter for AVC
was broken.

Logged In: YES
user_id=786427

"regarding pre-defs PARs for m4v, indeed they were missing,
should be fixed on CVS."

is done indeed now for avc and asp

wasnt able to test the avc rewriter fix till now tough

Logged In: YES
user_id=786427

i think i found a glitch in mp4box' -info option on
the "indicated track size":

http://tinypic.com/favkvm.png

i get the same strange big values when running -info on an
anamorphic ateme encode (the same i linked to below
already)

when changing the ar with mp4box i get correct values shown
as the screenshot above shows too

"this should now be fixed on CVS, the par rewriter for AVC
was broken."

fixed indeed

Logged In: YES
user_id=786427

"i think i found a glitch in mp4box' -info option on
the "indicated track size":
http://tinypic.com/favkvm.png
i get the same strange big values when running -info on an
anamorphic ateme encode (the same i linked to below
already)
when changing the ar with mp4box i get correct values shown
as the screenshot above shows too"

now fixed

Logged In: YES
user_id=142439

The -par feature in the latest CVS gpac seems to work just
fine. However, after properly setting the PAR value, and
copying the file.mp4 to a mac, quicktime does not respect
this value.

Further, if I make the adjustment in the 'movie info' window
in quicktime, and the 'Export' the file using 'passthrough'
mode, the resulting .mp4 file is opened properly in
quicktime. IOW, quicktime now respects the PAR value.

Is it difficult (or non-standard) to also set the PAR value
such that quicktime will also recognize it properly as it
comes out of MP4Box?

Logged In: YES
user_id=786427

qt does some mov-centric thing not being standardised for
mp4 afaik

if you want correct anamorphic resizing, get apple to write
a good player ;)

Logged In: YES
user_id=1062728

Yes.... to confirm what Bond mentioned.

Although QT7 is able to play MPEG-4 AVC streams which
contain AR signalling, it's unable to recognise the AR
signalling and display the encode at the correct shape!

QT7 includes an option called "Visual Settings" that can
be used to alter the shape of the encode but will save the
resulting file to .MOV

Cheers

Logged In: YES
user_id=142439

The reason I think it should be working is: when exporting a
.mp4 file from quicktime (using passthrough so that the x264
encoding is not touched), the resulting file -does- respect
the AR (when played in quicktime). Copying that .mp4 file
back to linux, it also plays properly in mplayer (with
correct AR). MP4Box -info file.mp4 also shows (what appears
to be) a valid .mp4 file. So quicktime is doing something
semi-standard if the .mp4 files it produces can:

- open properly in quicktime, with proper AR
- open properly in other media players, with proper AR

Whereas those files produced by x264+MP4Box can:

- open properly in other media players, with proper AR
- NOT open properly in quicktime (bad AR)

I realize you can change the "Visual Settings" in quicktime
and save as a .mov. But since you can also 'export' as .mp4
from quicktime, and that file seems to play properly
everywhere, I was wondering if MP4Box could also flip the
proper bits in the same manner, since it appears to be standard.

I can supply some sample files which demonstrate this if
necessary.

Logged In: YES
user_id=786427

read my statement again...

some more details: iirc qt stores ar info on the container
level, which is NOT standardised for .mp4
mpeg defines the ar info to be stored in the video
bitstream instead

if you do what you described, storing the ar on the
container level, on a file which has the ar info also in
the bitstream you will have two ar infos stored in the file:
now every .mp4 player will correctly ignore the info on the
container level and will take the ar info from the
bitstream and resize, as it should be done

qt on the other hand is a crappy and incomplete mpeg-4
player, and therefore doesnt read out the ar info on the
bitstream level
instead it expects the ar info on the container level (as
doable in .mov). if you have stored that info as you
described in .mp4, qt will find it and will resize. still
this is not the way it has to be done with mpeg-4 video

so the thing is:
1) quicktime is a crappy and incomplete player not
supporting anamorphic resize as its defined by mpeg
2) .mp4 doesnt define the ar info storage on the container
level, so you shouldnt use it

concluding this means you either
1) shouldnt use quicktime, but use a better player or
2) get apple to fix quicktime

understood?