Display Aspect Ratio - If and how to set

[guju]

I made a copy of a typical movie DVD (PAL ,760 x 576) to my HD (orig streams in a MKV).
The display aspect ratio (in original and copy) was 4:3, and the copy showed fine.

Now I wanted to squeeze it a litte more (HEVC).
With "standard settings" the DAR 4:3 seems to get lost,
and the compressor's config don't seems to be the right place to set it.

My questions:
Is the only (right) place to set the DAR the output format of the muxer?
(But not all formats support DAR).
Or is it better to resize the movie to the destination format?
(Better quality, and done once & forever)

[eumagga0x2a]

760x576 is not the PAL resolution, it is either 720x576 or 704x576 displayed at 4:3 or 16:9 DAR. I would not resize the movie but simply set the desired DAR in the container. It doesn't matter that not all muxers support it. The two that matter (mp4 and mkv) do.

[guju]

Yes, sorry, 760 was a typo.
And thankyou for confirming the newbie's guess about setting the DAR. 
(Still: Would it be an idea to let Avidemux set the DAR from source by default?)

And then my thinking was that it would be better to resize the movie
+ better quality (than "on the fly" when viewing)
+ saves ressources (done once and forever)
- slightly more space (due to enlarged resolution)
Why am I wrong?

[eumagga0x2a]

Still: Would it be an idea to let Avidemux set the DAR from source by default?

AFAIR the existing video filter interface in Avidemux doesn't allow passing aspect ratio information. It was also a design choice (probably for performance reasons as the fallback video output, used by default on Windows, is not hw accelerated) to use square pixel throughout the application.

And then my thinking was that it would be better to resize the movie
+ better quality (than "on the fly" when viewing)
+ saves ressources (done once and forever)

Videos, especially standard definition videos, are seldomly watched without scaling, they get usually scaled on-the-fly by the graphics card or TV set hardware anyway with very high quality and minimal overhead. Basically, my feeling was that 720x576 is standard and the original resolution, so don't change what is not broken.

On the other hand, if the video is interlaced, you really should insert a good deinterlacer (in Avidemux: yadif) into the filter chain before feeding images to the encoder. This is very important.

[guju]

...

On the other hand, if the video is interlaced, you really should insert a good deinterlacer (in Avidemux: yadif) into the filter chain before feeding images to the encoder. This is very important.

Wait a minute ...
(I have to realize that deep hole that just opened in front of me ...  )

Actually until now I literally never cared about interlacing.

Does this mean that every time my source video is interlaced I have to deinterlace it before any filtering/ encoding?

In the example of this thread the standard DVD is interlaced.
I simply resized and hevc-encoded it into an MKV.
MediaInfo doesn't show "Scan Type" from that, but in the "encoding settings" it says "interlace = 0",
so I presume it's progressive.
However the quality is undistinguable from the source ... (?)

[eumagga0x2a]

Interlacing is the greatest inconvenience and generally a PITA as all displays nowadays expect progressive video images.

Does this mean that every time my source video is interlaced I have to deinterlace it before any filtering/ encoding?

Yes, you really should, especially when resizing. Always deinterlace first, resize second.

In the example of this thread the standard DVD is interlaced.

Sometimes I experienced fake interlaced material, i.e. technically the video is interlaced, but both halfs belong to a single progressive frame. If you don't see jagged outlines with fast moving objects when stepping through the video in Avidemux, it is most likely the case. This would also explain why the visual quality remains good after re-encoding. You don't need a deinterlacer then.

[guju]

Well - all I can say again:  Thank you for your hint and your help! 

Maybe it would be an idea ... to prevent unexperienced like me to worsen movies,
to give a message in Avidemux, when "save" is clicked, and the source is interlaced and in the filter chain/ encoder
there is no deinterlacer?
(And even profs may forget it sometimes).

To my experience it would generally (in our world) be a good idea to more give assistance/ hints,
to prevent quality loss/ miss-handling, instead of doing it ever more complicated ...

Greetings!

[fish]

You don't state how the video will be viewed. I change the DAR of mp4's that display at the wrong ratio by using Yamb. It doesn't re-encode the video but I don't know whether it works  for anything other than playing in Windows Media Player Classic. One thing I don't understand is, if you are going to re-encode the video to HEVC, why you don't simply resize the video at that stage or if it is just display ratio change you need, set the player to display at the desired ratio.
If you want to try Yamb simply, double click on create an mp4, drag your video into Yamb, select just the video track in the window and on the right click the properties tag. At Pixels Aspect Ratio select custom. In your case i think you want to change the video from displaying at 16:9 to display at 4:3 or to make sums easier 16:9 to 12:9.
So to keep the height the same enter 100 (think of it a percent) in the right hand box.
12/16 = 0.75 so enter 75 in the left hand box. When you save the video (change the name slightly or save in a different location) it should play at 4:3 without changing settings in your player every time.
If you re-edit the video you will need to repeat the process as this doesn't change the video dimensions, simple how it is displayed.

[eumagga0x2a]

I assume, MP4Box manipulates in this case just the container metadata. You achieve the same with the Mp4 muxer in Avidemux with or without re-encoding. Many (all good ;-)) players respect DAR specified at the container level. I advise against resizing during re-encoding if this is not absolutely necessary (in case the target equipment is known to be incapable of interpreting DAR container metadata).

[fish]

Ah yes, I didn't know that feature was there in mp4 without re-encoding, I think I have noticed that in Mpeg TS or it may have been MKV. I think a custom option would be a handy addition for weird or non standard video sizes, that play at the wrong DAR. The original pixel aspect ratio could be 1:1, 4:3 PAL or NTSC, 16:9 PAL or NTSC or the video could be cropped to some non standard size which tends to lead to unreliable results when changing the DAR using standard 16:9 and 4:3 settings.

[guju]

This DAR thing seems to be another PITA ... 

However I do agree now that one should only resize to the DAR if not resized when viewing in the actual device again.
Which very seldom will be the case.

BTW
As my movie seems to be "fake interlaced" - isn't there a simple technical way to determine that?
By looking at the motion vectors (but how?) for example?

[fish]

You should be able to tell very easily by zooming in on a high motion area. In WMPC press 9 on your number key pad and alt 1-9 to pan around. It may also use MBAFF which is a mixture of interlaced and progressive, although I've never seen a movie encoded like that.  MBAFF is usually used for TV broadcasting but even movies broadcast on TV are in progressive. As far as I know only movies that have been telecined for American TV or DVD would be interlaced. In PAL land I think they just speed them up to 25 fps.

[guju]

Thanks for the information.
Still, MediaInfo says most of the standard movie DVDs to be interlaced. ().

However after playing around I would like to report an effect about DAR setting:

The scenario as above quite simple:

First I copied the streams from a standard movie DVD to MKVs.

That MKVs consist of 720 x 576, PAL. DAR: 4:3.

When playing that with MPC-HC (View / Aspect Ratio set to "Default")
the video shows with 768 x 576 as expected (W * (4/5) * (4/3)).
A saved frame is 720 x 576.

OK so far.

Now I let Avidemux read the MKV and do a simple copy of audio and video
and "output format" forced DAR = 4:3 for the MKV output.
It plays alright.

If I don't set the DAR in the output format, MPC shows a 720 x 576 movie.
OK too.
BUT MediaInfo still says DAR 4:3, PAL.
(Actually MediaInfo shows identical info. Although "somewhere" there
MUST be the information of forced DAR as MPC plays it different)

[eumagga0x2a]

I did a brief test encoding a short 720x576 16:9 mpeg2 clip with x264 to H.264 using MKV as container to determine video player behavior when info from the codec and from the container disagreed. I tested with mpv, vlc, totem and ffplay. I also checked with MediaInfo.

For the first round, I enabled the 64:45 pixel aspect ratio in the codec settings. No display width or DAR forced at the container level. From the video players above only totem displayed the video at 16:9 DAR, mediainfo also showed 16:9 as DAR.

For the second round, I forced display width / DAR at the container level. Pixel aspect ratio in codec settings was set to 1:1. All players played the sample at 16:9 DAR. MediaInfo showed 16:9 as "Display aspect ratio" and additionally 5:4 as "Original display aspect ratio".

The lesson is clear: the chances to get the desired result are much higher when setting DAR at the container level. Setting both in codec and in the container doesn't harm, but few players honor the former.

Technically MKV doesn't store a rational for DAR but simply stores the display width. The DAR menu in the Avidemux' MKV muxer facilitates the procedure for users.

MediaInfo is not a tool to explore MKV structures, use MKVToolNix or an equivalent for that.

[guju]

Thankyou for the test!
This DAR thing seems to be a little ... "delicate".

Meanwhile I did tests for myself, and got strangest effects
if using (crop) filter in the procedure:
The shown videos have never the size I expected.
Either I misunderstand all that, or within the filterchain
there are unexpected DAR values used (from the codec?).

Concrete Example:
Croping my orig video from above to 698x448.
MKV output DAR 4:3.
=> Too small in width.