Feature request: read the MKV "width" attribute

[Manitu]

Hi all

MKV container format has an option to override the real video size with something else which the player should respect when playing the file.
Avidemux (2.6. at least supports to specify the width (but not the height) in the "Configure" option of the "Mkv Muxer".

The bad thing: when opening a video with an overridden width, Avidemux does not read the current value and preopulate the Mkv Muxer settings with the correct value.
So when opening such a video and saving it without knowing the setting, the forced width gets lost.

Maybe there is some time to improve that, as this is quite often used for anamorphed encodings.

[AQUAR]

That option sets the PAR (Pixel Aspect Ratio).
If its read by your media player, it will scale accordingly to suit the PAR of your screen, and thereby present the proper DAR (Display Aspect Ratio).

ADM inputs the video based on the SAR (Storage Aspect Ratio) and you are expected to set it up to achieve your specific needs.
To make it easier for repetitive projects, you could load your own script with predefines (not sure if that includes the MKV DAR!).

Look at the information dialog for other stats of the video input (that were the "lost" information is found!). 
Then with that information you can set up the MKV container metadata to preserve the PAR (or change it to suit other screen PAR's).

Anamorphic video is meant for "analog screens", there was a recent discussion about the merit of software scaling vs hardware scaling.
That might help you see why the automated approach isn't the best way to go (IMHO).

   

[Manitu]

Hi
I'm not sure if you are right or if my other tools are doing some magic and just show calculated values.
I have an input video (352x288) in MPEG-2 format and I store it via ADM in a MKV container with a forced width of 1280.

When I open the video with mkv merge, I can see that it has set the 'display size' to 1280x288, and not the aspect ratio.
Reopening the muxed video via ADM, I can't see the forced display width in the info dialog (even the aspect ratio is the same as before), the information is lost.
Maybe the main thing is that this display size is a plain MKV feature and as MKV is just one demuxer of a few, it is not implemented correctly.

For me, this is not really critical as I can use mkv merge to check the correct settings. but to make ADM an (almost) perfect tool, it would be glad when it can handle this option and preset the correct value.

[AQUAR]

MKV toolnix shows you the DAR (ie 1280 x288) as you have set it in ADM (by redefining the PAR at the container level.

The SAR of the video is not changed unless you resample the video.
The ADM info on your video always shows the SAR and original PAR from the video stream.

Since these do not change when you use stream copy mode, both sets of information are correct.

Confusing - Yes!

What's worse, media players are not consistent in how they use PAR meta data.
Some will default to Stream PAR and some will adhere to Container PAR.

Obviously if these PAR's are different then the DAR is going to be inconsistent across media players.
That to me is one reason to avoid automation - ie it may work for some and not for others - hence user setup is the way to cover both.

[Jan Gruuthuse]

Having trouble following this subject?
source = 352 by 288 and you want to
display =  1280 by 288

Can't be correct? DAR is (normally) used to show 16:9 correctly on 1:1 pixel display as in flat screen tv, if it shows incorrectly as 4:3?

[AQUAR]

I think Manitu probably has an AVC, with anamorphic PAL in it (that seems to have been slighly cropped at some point!).
Meaning 352/288 * 64/45 = 1.74 = 15.5/9 (almost 16/9!)

If the OP wants a DAR of 16:9 from that stored SAR then the OP could set the MKV force width flag to 16/9 * 288 = 512 (setting to 512 is ok!) to suit a screen with square pixels.

In any case its a good idea to set the "force width" to 512, as it helps to cover various media playback setups (some media players will ignore this container meta data!).

PAR meta data won't magically change the resolution, its just information for scaling that has to be done to suit the screen type.
Preprocessing by sofware (and store the new video!) or on the fly processing by hardware (keep the original video!).

If the OP wants a new video of 1280 pixels wide in widescreen DAR,  then software recode and scaling is needed.

See:  http://avidemux.org/smuf/index.php/topic,16306.0.html
And then decide what works best for a specific playback system.

[Jan Gruuthuse]

Probably more like it. Source could be from NTSC 720x540 (4:3) resized to 352x288 (still 4:3)? If I'm not mistaken.

[AQUAR]

Could be NTSC, but the figures don't quite work out as well.
352/288 * 40/33 = 1.48 = 4.44/3 (11% distorted). (widescreen NTSC)
352/288 * 10/11 = 1.11 = 3.33/3 (16% distorted) (standard NTSC)

versus about 3% distortion (widescreen PAL)

But who knows what has been done to the video?

Just to confuse even more: some videos are specified with SAR as the Sample Aspect Ratio instead of Storage Aspect Ratio.
Sample Aspect Ratio = Pixel Aspect Ratio.

I've seen this kind of statement from FFMPEG:
Stream #0:0: Video: h263, yuv420p, 352x288 [SAR 12:11 DAR 4:3], 29.97fps, 29.97 tbr, 1200k tbn, 29.97 tbc.
Here the PAR is 12:11 and fits in with 4:3 NTSC.
Not aware that this PAR is common value, but I guess it can be anything by definition.

[poutnik]

I have thought  full/half  NTSC has 480/240 height, while 352x288 is half  PAL.  ( 576/288 height )
Or, was it half PAL converted to NTSC ?

Or, I have missed something...

[AQUAR]

@ poutnik
Neither Jan or Me have a sample of the OP's video.
Hence, for us it could be anything really (based on the minimal info provided!).
Maybe NTSC for interlaced video captured at the "half" PAL resolution?
Maybe Film to PAL with pulldown recoded at the lower resolution?
Maybe NTSC frame rate at PAL SAR and oddball PAR definition (is possible!)? 

I am guessing it's most likely just video from an anamorphic PAL DVD (ie cropped for overscan)
and it being recoded at half vertical/horizontal resolution.
Maybe recoded using AVC (as that allows PAR metadata in the stream).

Have You missed something?  Sure - We all miss something  .

Since Manitu hasn't returned best we can suggest is:
The DAR of the output video is correct when it looks correct.
And manipulate the ouput with these equations 
DAR of Video = PAR * 352/288.
Force Width =  Horizontal resolution = PAR * 352 

Computer monitor's have square pixels and so only natively matches the media that has a PAR of 1:1.
ADM is a computer program and will assume the video PAR is 1:1.
So if ADM shows a picture that looks squashed or stretched you have video intended for a screen of not square PAR.

Either Way: Users need to set up ADM to give a result that suits the intended screen type and processing hardware involved.
(as per our earlier discussion!)