x264 aspect ratio is ignored

[LonelyPixel]

I'm converting a TV recording into a new video file. It's SD TV which seems to be encoded as 4:3 but displayed as 16:9. Avidemux shows the video too narrow in the editor window. Last time I did this I went to the x264 encoder configuration on one of the last tabs and selected 16:9 PAL as output aspect ratio. The created mkv file looked correct.

Now I wanted to try and find optimal settings. I went to that config again but disabled "advanced configuration" (I have no idea about all that), medium preset, no tuning, high profile, and again that aspect ratio. I chose MP4 output because I don't need the advanced mkv features. This time, the created video played 4:3, too narrow.

What's the problem here? What have I configured wrong? What was Avidemux or x264 doing wrong? How can I fix this?

I'm continuing wasting some more time to try different things. But I'd really prefer not using the billion of settings of the x264 encoder because I can only do that wrong. I'm fine with the presets, somebody must have defined them carefully.

Avidemux version 2.7.0 on Windows 10, 64-bit.

[LonelyPixel]

It seems to work for MKV files but not MP4. So I guess I'll stay with MKV for now. Why is that difference?

[eumagga0x2a]

Please use a current nightly build matching your operating system, the 2.7.0 release is very old. Forcing display aspect ratio in the MP4 muxer is supported since 2017-11-26.

Avidemux always uses square pixel for display, so anamorphic formats look stretched vertically.

[LonelyPixel]

Umm, is 2.7.0 really old? I've just updated recently. And it's still the latest release on the website.

BTW, aspect ratio also fails with mkv and x265 (HEVC). But I'm not using HEVC because it doesn't play back properly in DVBViewer despite codec and HW support.

[eumagga0x2a]

Umm, is 2.7.0 really old?

Yes, it is.

Don't bother trying to set display aspect ratio in the codec. Do it in the muxer (Matroska or Mp4).

[LonelyPixel]

Then may I ask what's the issue with release management? The only available release is outdated. That's not an ideal state. If I switch to nightly, then my version will be outdated every day. And nightly doesn't even have to be particularly stable. Which particular nightly build from the last week can you recommend? I wasn't going to spend my time installing software and reading change logs, I was actually more interested in using it. And not every day.

[eumagga0x2a]

Then may I ask what's the issue with release management?

The lack of resources.

The only available release is outdated. That's not an ideal state.

There is no doubt about it. Quality code and artwork contributions are welcome. By the way, we are pretty close to a release, but currently it has stalled due to lack of spare time to address things which are still missing for this release.

If I switch to nightly, then my version will be outdated every day.

The same applies to a release and in general to any actively developed piece of software. No, you won't be nagged to update to the next nightly.

And nightly doesn't even have to be particularly stable.

As a rule, they are more stable than releases because they include fixes which didn't make it into the release. From time to time some stuff may be broken which worked in the release, but this is an exception.

Which particular nightly build from the last week can you recommend?

Always the latest. If you don't want to spend time installing software, use the zip version, it runs without installation.

[LonelyPixel]

If you don't want to spend time installing software, use the zip version, it runs without installation.

Oh, that's even worse. Running the installer is really quick and easy. Manually fiddling with files and things is way more work. I meant I don't want to download a package and handle it so often. If your nightlies are so stable, then maybe an automatic updater might be useful. The Google Chrome way, or like Windows store apps. Just silently updating in the background.

I'll watch out for the next release. Should I have any other issues, then I'll try the nightly. For now I have found a working solution for my problem.

But as you mentioned it: What's the difference between setting the aspect ratio in the encoder and the display width in the container? Is any of them more reliable across different player software?

[eumagga0x2a]

It is always up to player to respect the pixel/display aspect ratio or not and to decide which one to trust if the values in the stream and in the container contradict each other. At the first glance Avidemux sets square pixels at the container level for ffmpeg based muxers (Mp4, Matroska) unless manually forced otherwise (i.e. it doesn't read and use the value from the stream). The libmp4v2 based MP4v2 muxer seems not to set this field at all.

[LonelyPixel]

Do I understand it correctly that I can later edit a video file that I created today to set that field in the container? I would just copy the complete video and audio streams and make a configuration for the muxer. No re-encoding.

[eumagga0x2a]

Yes, exactly. This will work with all video players which trust the PAR/DAR values stored in the container.

[Blues]

Mkvtoolnix has header editor. No need to remux if it is already mkv.