tool for changing aspect ratio of mp4

[Lele-brz]

Hi all,
I'd like to know if there's some tool that let modify the Pixel aspect ratio of a given h264 track.
I know mp4box do that using PAR, but in my case I just need to modify it on a given mp4 file.

thanks for any help

bye

[SealTooGreat]

Use latest Yamb (http://kurtnoise.free.fr/index.php?dir=Yamb/), it supports custom PAR. But keep it mind that latest version is only for testing purpose, so you may find some bugs (for example it doesn't accept raw x264 stream (http://forum.doom9.org/showthread.php?p=1011230#post1011230) although previous version do - Don't know if Kurtnoise13 have fixed that). And in the same Yamb's directory you also need to extract mp4box (http://kurtnoise.free.fr/index.php?dir=mp4tools/). To change only PAR in MP4, you have to remux stream in Yamb.
If you prefer cmd you can use:

MP4Box.exe -par 1=X:Y YourVideo.mp4

..where PAR=X:Y.

EDIT:
If your MP4 was created by Nero Recode, you can't simple apply PAR changes, using mp4box, cause there would a conflict between Recode's PAR and mp4box's PAR, and player will read only Recode's PAR. To avoid that, you have to demux Recode's MP4 to raw h.264, and than mux it into MP4 using Yamb and mp4box's PAR switches

[bond]

If your MP4 was created by Nero Recode, you can't simple apply PAR changes, using mp4box, cause there would a conflict between Recode's PAR and mp4box's PAR, and player will read only Recode's PAR. To avoid that, you have to demux Recode's MP4 to raw h.264, and than mux it into MP4 using Yamb and mp4box's PAR switchescan you elaborate on this? where does recode store this own par, because there is only one place where to store par in avc streams

[SeeMoreDigital]

can you elaborate on this? where does recode store this own par, because there is only one place where to store par in avc streamsI agree....

I have encountered no problems what-so-ever adding or amending the aspect ratio signalling values of any MPEG-4 Part-10 or Part-2 video stream ;)

[SealTooGreat]

@bond
My elaboration is based on experience not on technical details.
Try to create some MP4 stream by Recode, and than change PAR using mp4box.

MPC+haali will stretch video, using mp4box's PAR, at first half of second, and than will squeeze back to Recode's PAR (cause Recode by default use Square Pixel(PAR=1:1)).

NeroShow Time (if let stream to be played for few seconds) will stretch its screen to mp4box's PAR, but keep stream on Recode's PAR, while the rest of stretched screen(exactly left and right sides) is filled with black bars.

Therefore I assume there are 2 PARs in mp4 stream or definitively something is wrong. The workaround (I always use) is one described in my previous post.

Here's example (http://www.mytempdir.com/1353087) . PAR is amended by above mentioned mp4box cmd and MP4 is created using Recode and HDTV - AVC profile.

[SeeMoreDigital]

MPC+haali will stretch video, using mp4box's PAR, at first half of second, and than will squeeze back to Recode's PAR (cause Recode by default use Square Pixel(PAR=1:1)). Okay try this: -

De-mux the MPEG-4 AVC video stream to an elementary "h.264" video stream.

Re-mux the elementary "h.264" video stream, with your required PAR value back to .MP4


Cheers

[SealTooGreat]

SMD, are you reading what I have written. :p

To avoid that, you have to demux Recode's MP4 to raw h.264, and than mux it into MP4 using Yamb and mp4box's PAR switches

[Lele-brz]

MP4Box.exe -par 1=X:Y YourVideo.mp4 as suggested does exactly what I needed.

thanks

bye

[Lele-brz]

one last question:
is there another tool that can tell the PAR of a given track and report as a standard output ?

thanks again

[SeeMoreDigital]

one last question:
is there another tool that can tell the PAR of a given track and report as a standard output ?

thanks againGSpot is pretty good. YAMB 1.6 is also able to tell you stuff like this: -

http://img241.imageshack.us/img241/5183/infose4.png


Cheers

[bond]

sounds like a bug in nero showtime

[SealTooGreat]

sounds like a bug in nero showtime
bond, I wouldn't say that, cause if you go in same direction, there wold be a bug in mpc+halli as well (cause mpc+halli can't resize using mp4box's amended PAR). Everything is played fine on both players if you use workaround (Recode's MP4->demux->raw->mux with PAR->new MP4)

I think that mp4box's PAR cmd can not completely alter some info in Recode_MP4's header - but that's just guess.

[bond]

bond, I wouldn't say that, cause if you go in same direction, there wold be a bug in mpc+halli as well (cause mpc+halli can't resize using mp4box's amended PAR)are you sure you use directshow filters allowing anamorphic resize? eg overlay mixer2...

directshow is a mess, it could be that your issue depends on the filters used (eg nero might use a different graph than mpc aso..)

[SealTooGreat]

are you sure you use directshow filters allowing anamorphic resize? eg overlay mixer2...

I'm using haali video renderer (in MPC) and don't have any problems about anamorphic playback, except this one.
I was referring to Recode's MP4 with mp4box's PAR applied. It's not general issue as it might sound from your answer considering mpc anamorphic playback.

directshow is a mess, it could be that your issue depends on the filters used (eg nero might use a different graph than mpc aso..)
Bond, I know how to force mpc to use DS filter I need ;) after all there's a "Play->Filters" which shows currently ones in use. The truth is that both players(mpc+haali renderer and showtime) can't handle anamorphic playback of Recode's MP4 with mp4box's PAR applied. Only with mentioned workaround, everything is fine upon anamorphic playback. So your saying "sounds like a bug in nero showtime" is too fast conclusion. I would rather say that mp4box can't properly alter Recode_MP4's PAR header.
Have You tried to play sample (http://forum.doom9.org/showthread.php?p=1013042#post1013042) I uploaded, you will know exactly what I'm talking about. You also may change PAR in this uploaded Recode's MP4, using mp4box's cmd so try it for yourself and you will se that only workaround is Recode's MP4->demux->raw->mux with PAR->new MP4.

[bond]

again, there is only one place to store PAR at. either there is a bug in mp4box or nero is doing very strange things. as i believe in the later one (maybe i am wrong) i take this as a bug in nero

maybe you can find out what makes the difference between the two?

[Stux]

I agree....

I have encountered no problems what-so-ever adding or amending the aspect ratio signalling values of any MPEG-4 Part-10 or Part-2 video stream ;)

I'm not sure of a way to change the in-stream PAR in an H.264 stream, but I do know that with the 3ivx 5.0 filters you can remux an MPEG-4:2 MP4V stream and change the in-stream PAR. The Muxing filter will actually modify the visual bitstream as it remuxes it to adapt the PAR.

So basically remux from an AVI/MP4 or whatever into an MP4, set the properties of the Muxer to whatever PAR you want (instead of Pass-through), and the resulting MP4 will have the right PAR in the visual stream, not just in the container.

[SeeMoreDigital]

I'm not sure of a way to change the in-stream PAR in an H.264 stream....YAMB with MP4Box can do this....

That said, it would indeed seem the .MP4 sample SealTooGreat provided does do weird things when played in MediaPlayer Classic (even though the appropriate PAR signalling properties are present within the stream header). By contrast, the same sample when played in VLC player is displayed at the correct aspect ratio!

However, de-muxing and re-muxing the stream with YAMB, makes the sample compliant for use with both MediaPlayer Classic and VLC player.... go figure!

So basically remux from an AVI/MP4 or whatever into an MP4, set the properties of the Muxer to whatever PAR you want (instead of Pass-through), and the resulting MP4 will have the right PAR in the visual stream, not just in the container.With regard to "container level" signalling. Does this mean MPEG-4 SP in .MP4 files (re-muxed by 3ivx with container level signalling) are displayed correctly in QT7 player - without the aid of your filters?


Cheers

[SealTooGreat]

So basically remux from an AVI/MP4 or whatever into an MP4, set the properties of the Muxer to whatever PAR you want (instead of Pass-through), and the resulting MP4 will have the right PAR in the visual stream, not just in the container.
So you are saying that whole video can have 2 PARs, one in visual stream (can you explain what visual stream is?) and one in container?

So maybe this is issue in my provided sample - visual stream has Recode's PAR and container has mp4box's PAR. (or it's opposite ???)

Than, explanation is that mpc+haali renderer first reads PAR from conatainer(at first half of second) and than (rest of duration) from visual stream (that's why anamorphic playback isn't correct), and VLC (as SMD said, it displays correctly) from container header.

I also can confirm that my sample when played in gmplayer is displayed at the correct aspect ratio, so I assume it reads PAR from container like VLC do.

[SeeMoreDigital]

So you are saying that whole video can have 2 PARs, one in visual stream (can you explain what visual stream is?) and one in container? Yes, the "visual stream" refers to "aspect ratio signalling" embedded withn the elementary MPEG-4 AVC stream, which is placed within the .MP4 container (as per the ISO specs). Which is in-turn read by most "direct-show" decoder filters. By contrast, QT7 player does not understand "stream level" signalling, only "container level" signalling. Which (by-the-way) can be accurate to a single pixel.

So maybe this is issue in my provided sample - visual stream has Recode's PAR and container has mp4box's PAR. (or it's opposite ???)Actually no.... Recode is not capable of generating MPEG-4 Part-10/Part-2 encodes with "container level" signalling. Only "stream level" signalling.


Cheers

[SealTooGreat]

Actually no.... Recode is not capable of generating MPEG-4 Part-10/Part-2 encodes with "container level" signalling. Only "stream level" signaling.
If Recode generate "stream level" signaling, on which level does mp4box alter Recode's MP4?

[SeeMoreDigital]

If Recode generate "stream level" signaling, on which level does mp4box alter Recode's MP4?At the stream level too!

[SealTooGreat]

SeeMoreDigital, any idea about weird behavior of my stream?

edit: Switching from Haali renderer to Overlay in MPC, anamorphic playback (of my stream) is fine. Maybe it's issue in haali renderer. But again haali renderer can handle anamorphic playback, once Recode's MP4 remuxed to new MP4 (with new applied PAR signaling). Really strange and odd.
note: if you are forcing haali renderer in "External Filters", block it, before change it to overlay.

[Stux]

With regard to "container level" signalling. Does this mean MPEG-4 SP in .MP4 files (re-muxed by 3ivx with container level signalling) are displayed correctly in QT7 player - without the aid of your filters?


I'm not sure if the remuxed files are displayed correctly, in QT7.

QT6 used to use container-level PAR, most other MP4 players use stream-level PAR.

I think the 3ivx Muxer rewrites the container-level PAR to match the stream-level PAR when the stream-level PAR is either non square or being re-written. But I'm not sure on that behaviour :)

I'll look into on Monday.

[SeeMoreDigital]

I'm not sure if the remuxed files are displayed correctly, in QT7.

QT6 used to use container-level PAR, most other MP4 players use stream-level PAR.

I think the 3ivx Muxer rewrites the container-level PAR to match the stream-level PAR when the stream-level PAR is either non square or being re-written. But I'm not sure on that behaviour :)

I'll look into on Monday.Any news Stux?


Cheers

[Stux]

Any news Stux?

I looked into it a little bit, decided it needs more looking into :)

I've added it as a bug to be fixed for the 5.0.1 release.

I should have some more info when the bug is handled, probably within a couple of weeks, but right now we're focussing on other 5.0 reported bugs.

[anger98]

Here is a handy calculator to fix the aspect ratio of an image with the PAR using MP4Box
http://tools.rodrigopolo.com/mp4box_aspect_fix/

[roozhou]

Here is a handy calculator to fix the aspect ratio of an image with the PAR using MP4Box
http://tools.rodrigopolo.com/mp4box_aspect_fix/
In most cases 16:9 is an approximant. 720x480 @ 16:9 should use 40:33 instead of 32:27. The actual DAR is 20:11 not 16:9.

[CarlEdman]

As this thread has just been so fortuitously revived, let me ask a related question about an issue I recently encountered.

Almost all of my archived encodes are h264 in mp4 containers created using x264 and mp4box, though I have of course gone through many revisions of both over the years, and almost all have an encoded sample aspect ratio. This encoded sample aspect ratio is properly applied in almost all hardware (WD TV Live, Popbox, various Apple iDevices) and the software player I use, VLC.

However, recently I tried smplayer on some recent encodes and observed strangely distorted images. It was not as if the sample aspect ratio was ignored and the video just displayed as square pixels. Instead, by eyeballing it looked like the sample aspect ratio was applied twice. For example, encodes from wide-screen anamorphic DVDs were stretched horizontally further than the (32:27) SAR would require to something more like (32*32:27*27). Similarly, old TV aspect ratio DVDs were stretched vertically by what looked like (8*8:9*9) rather than the (8:9) ratio you'd expect.

Strangely enough, some of my older encodes I tested did not exhibit this problem; they displayed correctly in both VLC and smplayer. However, given the many revisions in the tools used and my own personal python tool chain, I could not even roughly pinpoint at what point that smplayer incompatibility was introduced.

Any advise on what to do greatly appreciated. Is it just a bug in smplayer (or the underlying mplayer) which I should just ignore until they fix it? Is it a double-setting of the SAR on both the container and the stream level? If so, under the standards, should one replace the other (like most players seem to do) or should they be multiplied (like smplayer appears to do)? If the latter is the correct behavior, what would be the best way to fix my encodes with the double-SAR?

[nm]

recently I tried smplayer on some recent encodes and observed strangely distorted images. It was not as if the sample aspect ratio was ignored and the video just displayed as square pixels. Instead, by eyeballing it looked like the sample aspect ratio was applied twice.

Could you post a sample clip where this happens?

[CarlEdman]

Certainly. Here is a ten-second clip (http://www.mediafire.com/file/qpcboqfo5bh6em0/Town%20%26%20Country%20%282001%29%20Clip.mp4) from one mp4 file.

Both the clip and the entire file display the same problem: Apparently correct aspect ratio in VLC and all hardware player I've tried, additional horizontal stretching in smplayer.

[nm]

Here it plays with correct aspect ratio in both MPlayer and SMPlayer. Check that the monitor aspect ratio is set to "Auto" in your SMPlayer settings and that aspect ratio is not forced manually in the menu. Also try playing it directly with the MPlayer binary that SMPlayer is using.

[CarlEdman]

How strange. I have the smplayer aspect ratio set to 'Default' (there is no 'Auto', so I think that is what you mean) and playing in mplayer directly has the same distortion. I used the MPlayer binary from the latest smplayer version ('MPlayer Sherpya-SVN-r30369-4.2.5'). Playing around with the video render setting in the smplayer preferences seems to make no difference (I use 'direct3d').

I realize that the clip I choose does not make the distortion screamingly obvious, but if you play it side by side in VLC and smplayer, I see the smplayer video being substantially wider, but with the same height as the VLC video. In other scenes, it seems quite obvious that the VLC aspect ratio is correct and the smplayer one is distorted.

[nm]

How strange. I have the smplayer aspect ratio set to 'Default' (there is no 'Auto', so I think that is what you mean)

I meant monitor aspect: Options->Preferences->Advanced, Advanced-tab, Monitor aspect: Auto

and playing in mplayer directly has the same distortion. I used the MPlayer binary from the latest smplayer version ('MPlayer Sherpya-SVN-r30369-4.2.5'). Playing around with the video render setting in the smplayer preferences seems to make no difference (I use 'direct3d').

I used SMPlayer 0.6.9 and MPlayer SVN-r32396-4.4.3 on Ubuntu with xv output.

I realize that the clip I choose does not make the distortion screamingly obvious, but if you play it side by side in VLC and smplayer, I see the smplayer video being substantially wider, but with the same height as the VLC video.

For me, both VLC and SMPlayer have exactly the same aspect ratio. In windowed playback the video window size is exactly the same: 844x462.


Try with a recent MPlayer build.

[SeeMoreDigital]

Certainly. Here is a ten-second clip (http://www.mediafire.com/file/qpcboqfo5bh6em0/Town%20%26%20Country%20%282001%29%20Clip.mp4) from one mp4 file.Why was this encode generated using non mod-16 resolutions!

[CarlEdman]

Try with a recent MPlayer build.

That was it. I used the mplayer bundled with the current version of smplayer, but apparently smplayer has not been updated (at least for windows) for a while. Using a more current mplayer build (MPlayer Sherpya-SVN-r33574-4.2.5) and the aspect ratios were correct.

So it looks it my encodes were fine and they just exposed an already-squashed bug in older mplayer versions.

[CarlEdman]

Why was this encode generated using non mod-16 resolutions!

Because non-mod 16 resolutions are perfectly legal under h264 standards. Non-mod-16 resolutions have a slight overhead, but that overhead is less than the cost of including an extra sharp black edge by including letter boxes or side panels in the encode and preferable to cutting the actual source content.

[SeeMoreDigital]

Because non-mod 16 resolutions are perfectly legal under h264 standards.
Really, please provide evidence?

[nm]

From T-REC-H.264 (http://www.itu.int/rec/T-REC-H.264):

The width or height of pictures output from the decoding process need not be an integer multiple of 16 and can be specified using a cropping rectangle.

This is part of the decoding process and is further described in the document.

[SeeMoreDigital]

From T-REC-H.264 (http://www.itu.int/rec/T-REC-H.264):

This is part of the decoding process and is further described in the document.I see, you are quoting from the following section of: H.264 03/10 (T-REC H.264-201003-I): -

http://img851.imageshack.us/img851/4985/snap2r.png

[CarlEdman]

I see, you are quoting from the following section of: H.264 03/10 (T-REC H.264-201003-I)

Exactly. Your highlighted section of the doc answers your question: The final output need not be mod-16 but can specify a smaller cropping rectangle. That is good and fine and all that occurred in the clip I posted. Unless my memory fails me, no less an authority than Dark Shikari has repeatedly stated that this is good and proper practice.

So what is your problem?

[SeeMoreDigital]

The above statement refers to "two separate fields" and "macroblock adaptive frame field coding"... ie: interlaced

[sneaker_ger]

Just look at Blu-Rays with Full-HD, i.e. 1080 lines which is not mod-16.

[nm]

The above statement refers to "two separate fields" and "macroblock adaptive frame field coding"... ie: interlaced

No, the sentence about cropping is a general statement that refers to all sampling and coding types. Cropping is done at the last stage of the HRD (hypothetical reference decoder) before the frame is given out. All general purpose H.264 decoders should conform with that.

Search for "crop" in the rest of the document to find out more.

[Audionut]

Just look at Blu-Rays with Full-HD, i.e. 1080 lines which is not mod-16.

Blu-rays have 1088 lines of vertical resolution.

[nm]

Blu-rays have 1088 lines of vertical resolution.

Which is cropped to 1080 by the decoder.

[sneaker_ger]

Blu-rays have 1088 lines of vertical resolution.

Yes, but only internally. Like every other H.264 encode. But the standard allows non-mod16 resolutions. You can feed 1080 lines to an encoder and the decoder will spit out 1080 lines. It's a black box. And whether a decoder spits out 1088, 1080 or 1084 (etc.) lines is already defined on the encoder's side, even if all of these are internally encoded with 1088 lines.

But I guess this is a philosophical question.

[Audionut]

@SMD

The encoder must encode at mod-16. But if it's fed something else, it will pad the video to bring it to mod-16 for encoding.
It has been noted various times, that over cropping to remove the sharp transition between the content and the matte bars (thus having x264 pad the content back to mod-16), can result in a bitrate reduction.
ie: It's easier to encode the content that x264 uses to pad.

[Vurbal]

The above statement refers to "two separate fields" and "macroblock adaptive frame field coding"... ie: interlaced
No, it says "pictures output from the decoding process." How does that not include progressive frames?