AVC / Matroska SAR discussion

[H4dd3R]

Hello everyone.

Sorry for disturbing (red wine helps).


Is there any actual way to define anamorphic aspect ratios with x264?

I was impressed by the performance of the codec, but I couldn't set an anamorphic aspect ratio with it.

I mux everything in mkv with mkvtoolnix.


If I use the vfw aspect ratio option by encode, it doesn't have any effect on playback.
Mkvmerge has it's own aspect ratio parameter. It works well with xvid, but has no effect with a x264 stream.

A problem with x264 dshow filter (I tried both Nero and ffdshow filters)?

Thxs if you can help.
I believe there is a great potential in h264 codecs. :) :D

[Sharktooth]

If you use matroska then probably the AR should be set in the container with mkvmerge.
The the latest haali parser should work btw... http://haali.cs.msu.ru/mkv/

[LigH]

The x264.exe supports it via command line parameter:

--sar width:height Specify Sample Aspect Ratio
And MPEG4-AVC/H.264 video shall reside in the MP4 container. So better use the x264.exe with a GUI (e.G. Doom9's MeGUI, or maybe x264CLIgui) to create a *.mp4 out of an AviSynth script and an AAC MP4 audio file.

[SeeMoreDigital]

If you use matroska then probably the AR should be set in the container with mkvmerge.
The the latest haali parser should work btw... http://haali.cs.msu.ru/mkv/Just to let you guys know.... All the x264 test encodes I've generated with AR signalling and muxed into MKV using AVI-Mux, auto AR perfectly in MPC - with or without Haali.


Cheers

[Sirber]

And MPEG4-AVC/H.264 video shall reside in the MP4 container.RealVideo shall reside in RMVB container and I use it in MKV, so what?

[H4dd3R]

Sharktooth, it still doesn't work with the latest haali mkv splitter (I verified it was active in mpc).

LigH, I need more time to test your solution (i'm not that fast. ;) ).
Sad if it means for mkv to die, I had an affective relation with this container. ;)

[LigH]

Okay ... at least, MKV is much more suitable vor MPEG4 content than the AVI container. ;) The MP4 container is just the "native" one.

[nm]

Sad if it means for mkv to die, I had an affective relation with this container. ;)
Like for others who replied, it works just fine for me too. Here's two ways to specify the aspect ratio:

Setting aspect ratio with x264 (tested with mplayer):
1. Use the --sar option like LigH suggested or let the encoder app handle it. At least mencoder does.
2. Run mkvmerge with --aspect-ratio 1:0 (where 1 is the video track and 0 disables aspect ratio setting in the container)
However, I'm not sure if this is really supposed to work like it does. Mkvmerge documentation doesn't tell how a zero aspect ratio is handled and I never bothered to read other matroska specs. Use at your own risk.

Setting aspect ratio in the container:
Run mkvmerge with --aspect-ratio 1:width/height -or- --aspect-ratio 1:ar (where ar is a floating point number like 2.35)

[SeeMoreDigital]

How do you guys get on with this x264 in MKV (http://homepage.ntlworld.com/seemoredigital/Test_Files/x264_720x576_with_2Ch_MP3_and_2Ch_AAC-LC_in_MKV.7z) test sample?


Cheers

[LigH]

Plays absolutely fine in MPC 6.4.8.4 (de) with ffdshow video decoder, and either ffdshow audio decoders or MPC internal decoders (both formats), with either Haali or MPC Matroska splitters. Correct AR - but it seems that letterboxes are included in the video.

[nm]

How do you guys get on with this x264 in MKV (http://homepage.ntlworld.com/seemoredigital/Test_Files/x264_with_2Ch_MP3_and_2Ch_AAC-LC_in_MKV.7z) test sample?
Aspect ratio is wrong when played back with mplayer or vlc. This is because the display width and height parameters are set to 720x576 in the container and these players prefer that info to the one in the avc stream. If I remux the clip with mkvmerge --aspect-ratio 1:0, it sets the display to 720x0 and the players read the correct aspect ratio from the video stream. Don't know about other players / splitters though.

Edit: Anyway, that trick is not a real solution. The Right Way to specify aspect ratios is to set them correctly in the matroska container, IMHO. Unfortunately mkvmerge doesn't support setting the container AR from the stream AR, at least not yet, and therefore the container AR needs to be set manually.

Btw, this discussion should probably be moved to the containers forum.

[Rash]

Yes, I get the same results here NM. ;)

[SeeMoreDigital]

The Right Way to specify aspect ratios is to set them correctly in the matroska container, IMHO. Unfortunately mkvmerge doesn't support setting the container AR from the stream AR, at least not yet, and therefore the container AR needs to be set manually.Personally, I would suggest the "right way" would be to have AR signalling in both the AVC bit-stream and in the Matroska container.... ie: cover both bases....

An implementation that's also available, should you ever decide to use the .MP4 container ;)


Cheers

[H4dd3R]

Okay ... at least, MKV is much more suitable vor MPEG4 content than the AVI container. ;) The MP4 container is just the "native" one.
Can you mux vobsubs in a *.mp4
Can you have streams lossless compressed?
I believe it should be possible do mux several heaac audio streams in (it's mpep4 audio ;) ).

If all this is possible, it is possible that mkv has lost its advantages.

[nm]

Personally, I would suggest the "right way" would be to have AR signalling in both the AVC bit-stream and in the Matroska container.... ie: cover both bases....
I agree. I was just pointing out that matroska container seems to have AR signaling by default, and it is taken from the video dimensions, not its AR. Also, I think AR handling in MPC is wrong and confuses people, because the container AR should override the stream AR. Or maybe there should be an option in the player to choose which AR to use.

[berrinam]

If all this is possible, it is possible that mkv has lost its advantages.Everything you asked about is possible (vobsubs aren't standards compliant, though), but the advantages of mkv are also due to its support of a wide variety of video and audio codecs.

[SeeMoreDigital]

... Also, I think AR handling in MPC is wrong and confuses people, because the container AR should override the stream AR. Or maybe there should be an option in the player to choose which AR to use.I don't agree!

As long as you have the appropriate filters installed and they are configured correctly, bit-stream AR signalling should be the one to go for first.

In the case of MPEG-1 and 2 streams AR signalling is in the bit-stream, although for MPEG-2/DVD, AR signalling can be assigned in the IFO file too!

Being able to choose which AR option to use (ie: stream or container), while useful, may end up making a confusing situation, even more confusing.... But that's my opinion.


Cheers

[H4dd3R]

Ok, I've got stream AR working in mkv (leaving the ar field in mkvmergegui empty).

My error was that I saved the x264 stream in avi before muxing it with sound with mkvmerge.

Seems that saving in avi with vdubmod erases stream ar info, or that mkvmerge can't read stream ar from an avi container.

Thx for your help.

[SeeMoreDigital]

Here's another MKV file for you guys to try.

This one (http://homepage.ntlworld.com/seemoredigital/Test_Files/x264_720x432_with_2Ch_MP3_and_2Ch_AAC-LC_in_MKV.7z) contains x264 video with 2Ch MP3 and 2Ch AAC-LC audio but has been cropped to 720x432 before applying AR signalling in the bit-stream.


Cheers

[nm]

or that mkvmerge can't read stream ar from an avi container.
It can't read the AR from AVC and ASP streams and that's one of the problems in this Matroska AR mess. Other is that mkvmerge insists on setting the AR from video dimensions. We would be much better off if the AR setting in the container was disabled by default.

As long as you have the appropriate filters installed and they are configured correctly, bit-stream AR signalling should be the one to go for first.
I think of the situation in this way: bitstream AR is the basic way of setting the aspect ratio and it supports AR changes in the middle of the stream, but IF it is overridden in the container, that flag should be respected instead. Currently it is done so by mplayer, vlc and the Haali splitter (at least the changelog states so).

[nm]

Here's another MKV file for you guys to try.
Still wrong AR in mplayer and vlc for the same reason as before.

[SeeMoreDigital]

Personally, I would find it far more useful to be able to place say, multiple MPEG-4 video streams encoded at different pixel frame sizes, into one container and have the "bit-stream signalling" do the talking.

For instance, if I decide to generate multiple encodes at different pixel frame sizes with different AR signalling and incorporate a menu system pointing to each encode. I don't want to get the AR locked down by the container ;)


Cheers

[nm]

Personally, I would find it far more useful to be able to place say, multiple MPEG-4 video streams encoded at different pixel frame sizes, into one container and have the "bit-stream signalling" do the talking.
But that's how Matroska does it. It has a separate AR setting for each video track.

[Doom9]

uhh guys, aren't you drifting just slightly off topic for this thread?

For instance, if I decide to generate multiple encodes at different pixel frame sizes with different AR signalling and incorporate a menu system pointing to each encode. I don't want to get the AR locked down by the containerI think at this point one geek has to tell the other to get a life ;) You could also write your own operating system and create your own CPU if you're at it, it's all possible, and certainly a great challenge...

[SeeMoreDigital]

I think at this point one geek has to tell the other to get a life ;) You could also write your own operating system and create your own CPU if you're at it, it's all possible, and certainly a great challenge...Hmm... How does this comment help Doom9?

I have to ask, although VLC player appears to be able to detect MPEG-4/AVC AR bit-stream signalling within AVI and MP4... Is anybody sure VLC can do the same for MKV, whether AR signalling it's assigned to the bit-steam or the container?


Cheers

[nm]

uhh guys, aren't you drifting just slightly off topic for this thread?
Yes. If possible, I think all the posts after #1162 should be moved to a new thread in the MPEG4 containers forum for future reference.

I have to ask, although VLC player appears to be able to detect MPEG-4/AVC AR bit-stream signalling within AVI and MP4... Is anybody sure VLC can do the same for MKV, whether AR signalling it's assigned to the bit-steam or the container?
I have tested and it does, just like mplayer. As I said before:
Aspect ratio is wrong when played back with mplayer or vlc. This is because the display width and height parameters are set to 720x576 in the container and these players prefer that info to the one in the avc stream. If I remux the clip with mkvmerge --aspect-ratio 1:0, it sets the display to 720x0 and the players read the correct aspect ratio from the video stream. Don't know about other players / splitters though.

[Haali]

We always intended Mtaroska container AR to have priority over bitstream AR, and that's how it works at least in my code.
Mkvmerge does read AR info from mpeg4 bitstream when muxing, so if you don't override it manually, you'll get the same value in both places, which is good.
Of course this doesnt apply to vfw compatibility mode in Matroska, so you will get different results in this case, depending on your codecs and players.

To get good results, you need to follow these guidelines:
* Mux h264 into Matroska only from mp4 or matroska containers. Never use avi as a source.
* Let mkvmerge read out AR info and don't override it on command line.

[nm]

Hi Haali,

Your post already answered a couple questions I had in mind, but some things are still not clear to me.

For at least MPEG4 AVC and ASP in AVI, mkvmerge seems to set the aspect ratio from video pixel dimensions. As far as I can tell, this is not good at all and confuses a lot of people. Wouldn't it be better to not set AR by default at all when the correct value can't be read from the video stream?

Previously in this thread I suggested setting the AR to 0 with mkvmerge because then at least MPlayer and VLC were able to read the correct AR from the video stream. Is this wrong and is there an official way to disable the container AR setting?

[Haali]

You will always have an AR, even if it is not written in the file, that's how the specs are. Using 0 depends on how your codecs interpret such AR, I wouldn't be surprised if some codecs crash with a division by zero error. Simply don't mux from AVI, that's an easier solution.

[stephanV]

It seems more logical that container AR overrides bit stream AR. I'm not even sure why there even is bit stream AR, it is not relevant to the encoding process. You don't save the frame rate either in the bit stream. AR is nothing more than a playback property, and I doubt a lot of people are playing back raw streams for pleasure.

[SeeMoreDigital]

I reckon I've discovered why my MKV muxes were not able to auto AR in VLC :scared:

I used the newest version of AVI-mux to generate them (because of it's ability to handle AAC audio streams) and discovered that the following setting needs to be unchecked: -

http://img368.imageshack.us/img368/5895/avimuxmkvsettings4gn.png

Anyway... my anamorphic MPEG-4/AVC in MKV muxes work fine now in VLC (I don't think I could say that sentence quickly 5 times in a row)


Cheers

[Haali]

The specs are written in such a way, that DAR defaults to image size if it is not written in the file. It is our intention that container AR has a priority. If vlc doesn't follow that, then it will be fixed sooner or later. So, to avoid any incompatibilites, specify the same value in both places when muxing to matroska, or don't set bitstream ar at all.

[Atamido]

Hmm... How does this comment help Doom9?Quick, someone strike him for a rule 11 (http://forum.doom9.org/forum-rules.htm) violation.

[Doom9]

Quick, someone strike him for a rule 11 violation.That is not even possible, the strike system is designed to reflect the hierarchy. However, I can always strike you for trash talking. Would you like that?
There's another thing that needs to be said and that won't be liked by many in this thread: anamorphic encoding is just as much antiquidated as 4:3 AR, interlacing and all the other stuff we should've gotten rid of long ago. It's not that old but it stems from the fact that SD TV is traditionally 4:3, and the resolution chosen for SDTV and DVD is a mix that natively accomodates either format properly - hence AR signalling. If you look at HD specs, the picture size is 1280x720, or 16:9, and 1920x1080, also 16:9. So, effectively anamorphic signalling is no longer necessary, now you have to flag the crappy 4:3 material so that it'll be properly displayed (or I figure they might just use black bars).

And so that you can't say I'm just posting OT stuff, I agree that the container AR signalling makes more sense to use. bitstream signalling isn't always available (in fact - except for the MPEG-4 codecs which may or may not offer that feature), which other codecs are there to make use of that feature? Matroska, unlike MP4, is completely codec agnostic and offers the same support and featuresets for all kinds of video codec, hence relying on the AR flag that is available in the container for all codecs appears the logical thing to do.

Muxing tools having additional logic to take stream ARs into account, could be something useful though for those using bitstream signalling. But that's a frontend question.

You don't save the frame rate either in the bit stream.Actually, x264.exe does that, it seems permissible but I wouldn't know of any tool that can use that info, and I was very surprised to find out that settings the FPS in x264 actually has an effect on the output, even if you can't see it in any player/processing tool afterwards.

[stephanV]

Come to think about it, a frame rate IS needed to achieve a certain bit rate... but it is weird that it is actually stored there: imagine a decoder overriding the timestamps in a VFR Matroska file with the frame rate found in the bit stream...

[SeeMoreDigital]

There's another thing that needs to be said and that won't be liked by many in this thread: anamorphic encoding is just as much antiquated as 4:3 AR, interlacing and all the other stuff we should've gotten rid of long ago. It's not that old but it stems from the fact that SD TV is traditionally 4:3, and the resolution chosen for SDTV and DVD is a mix that natively accomodates either format properly - hence AR signalling. If you look at HD specs, the picture size is 1280x720, or 16:9, and 1920x1080, also 16:9. So, effectively anamorphic signalling is no longer necessary, now you have to flag the crappy 4:3 material so that it'll be properly displayed (or I figure they might just use black bars).You'll get no argument from me there...

Putting technical issues to one side, it might have been possible for you guys residing in NTSC lands to have been enjoying non anamorphically challenged images right now.

Given that the current std-def chip-set limitation is 414,720 pixels, a 4:3 NTSC frame could have had a picture size of 640x480 pixels and an 16:9 frame could have had a picture size of 853.3333x480 (or there abouts) pixels. Neither of which would have exceeded the pixel limitation of the chip-set....

We PAL people are not so fortunate though.


Cheers