x264 --sar and hardware players and wd tv

[smok3]

a. can i use a custom sar for wd tv encodes (or similar hardware) or should i use one of the prescribed ones? (like 64:45 or 16:11)?

b. are there two values stored in the stream (custom one and the closest prescribed or not?)

:thanks:

[SeeMoreDigital]

a. can i use a custom sar for wd tv encodes (or similar hardware) or should i use one of the prescribed ones? (like 64:45 or 16:11)?Much will depend on whether the device supports aspect ratio signalling detection in the first place. Many still can't...

b. are there two values stored in the stream (custom one and the closest prescribed or not?)No, only one... When it comes to assigning "stream level" PAR (aspect ratio signalling) values, unlike the MPEG-2 specification (which is very limited), the MPEG-4 specification is "far more" open and flexible.

[nurbs]

I'm pretty sure the WD TV can do anamorphic. If no one gives a definit answer 'til thursday I can try it out and tell you for sure, but since even the PS3 has no problems with anamorphic encodes I don't see why it shouldn't work on the WD TV.
Apart from the AR signalling in the stream containers (MKV, MP4) can also contain AR or display size values. Normally they are read from the stream on muxing, so there shouldn't be a mismatch.

[smok3]

--sar 16:15 (4:3) appears to work correctly, i did some encodes with --sar 16:11 (16:9), but did not test that yet, should be obvious there, report will follow. :)

unrelated, thumbs:
a. any experience with embedded thumbs versus external ones, speedvise? (it takes some time for wd to actually read those jpegs, which is quite funny for the machine that should be able to do 1080p h264..., my firmware is 1.02.07)
b. if embedded are faster, what cmd tool would you suggest for embeding those? (i know there is atomic parsley, but have no experience with it..)

p.s. some of my notes regarding wd tv are here http://blog.somestuff.org/index.php?entry=entry090706-115714

[SeeMoreDigital]

Here's a link to a sample with more extreme ARS (aspect ratio signalling): -

http://www.one.seemoredigital.net/Downloads/720x576_SAR@47.25.zip

If your device can display this correctly, it can read any PAR value :)

[jmnk]

so the aspect ratio signaling can be specified in either x264 video stream, or a container, or both. For the sake of this discussion let's assume that we signal aspect ratio by providing PAR value. And let's complicate the matter by having stream level PAR being 1:1 and container level PAR being 32:27.

If I indeed have a media file where PAR is specified in --both-- container and the stream itself - which value is used by a given video player:
- is it up to a player and there's really no agreed on way? If so - does anyone know which one is used by MPC? by kmplayer? by smplayer? by mplayer? by vlc?
- is it specified in the standards? If so, what is the rule?
- are both values used? eg. first, we apply container PAR to get resolution, than we also apply stream level PAR on top of that.

also, with x264, is PAR flag always present (and defaults to 1:1)? If it is not always present, does the player assume it is 1:1 if it is not there?

[SeeMoreDigital]

so the aspect ratio signaling can be specified in either x264 video stream, or a container, or both.Both...

Containers such as: .MKV and .MOV store the aspect ratio signalling information at the "container" level.

Containers such as: .AVI, .MP4, .MPG, along with transport containers such as: .TS, .M2TS, .MTS store the aspect ratio signalling information at the "stream" level.


For the sake of this discussion let's assume that we signal aspect ratio by providing PAR value. And let's complicate the matter by having stream level PAR being 1:1 and container level PAR being 32:27.

If I indeed have a media file where PAR is specified in --both-- container and the stream itself - which value is used by a given video player:
- is it up to a player and there's really no agreed on way? If so - does anyone know which one is used by MPC? by kmplayer? by smplayer? by mplayer? by vlc?
- is it specified in the standards? If so, what is the rule?
- are both values used? eg. first, we apply container PAR to get resolution, than we also apply stream level PAR on top of that.Nowadays, most software players know from the container where to look for the aspect ratio signalling. However, hardware player manufacturers have been slower to respond to support the .MKV containers implementation.

also, with x264, is PAR flag always present (and defaults to 1:1)? If it is not always present, does the player assume it is 1:1 if it is not there?Indeed, software and hadware players will default to 1:1 if no aspect ratio signalling value is present.


Cheers

[smok3]

copy/pasted from JM Reference Software Manual (JVT-AE010).pdf (which you can read here http://iphome.hhi.de/suehring/tml/JM%20Reference%20Software%20Manual%20(JVT-AE010).pdf ), i don't think it cares about containers at all...

4.7.29 VUI Parameters
VUI Parameters specify directly the values of the corresponding VUI syntax elements.
4.7.29.1 VUI_aspect_ratio_info_present_flag
Class: Boolean
Description: If enabled specifies that aspect_ratio_idc is present. Default value is 0 (disabled).
4.7.29.2 VUI_aspect_ratio_idc
Class: Numeric (Integer)
Description: Specifies the value of the sample aspect ratio of the luma samples Default value is 0 (unspecified). See Annex E, Table E-1 of the AVC text for more info.
Options:
0
Unspecified
1
1:1 (“square”)
2
12:11
4. Encoder Parameters
H.264/14496-10 AVC Reference Software Manual Page 4-45
3
10:11
4
16:11
5
40:33
6
24:11
7
20:11
8
32:11
9
80:33
10
18:11
11
15:11
12
64:33
13
160:99
14
4:3
15
3:2
16
2:1
17..254
Reserved
255
Extended_SAR
4.7.29.3 VUI_sar_width
Class: Numeric (Integer)
Description: indicates the horizontal size of the sample aspect ratio (in arbitrary units).
4.7.29.4 VUI_sar_height
Class: Numeric (Integer)
Description: indicates the vertical size of the sample aspect ratio (in the same arbitrary units as VUI_sar_width).

edit1: which wont exaplain how each player should behave of course (if i'am not mistaken...)
edit2: now if somebody has Annex E handy, please copy paste some relevant info on this.
edit3: how would a container-level signaling work? (say you can have 5 streams in it, with each has its own SAR/PAR/whatever), well it could, but why bother with two possibilities then?

[jmnk]

Both...

Containers such as: .MKV and .MOV store the aspect ratio signalling information at the "container" level. sure, but if .mkv container contains for example x264 video than the x264 stream can have its own signaling. Which I think was the reason why earlier versions of mkvtoolnix was removing signaling from the stream when it was muxing into mkv - just to avoid confusion I suppose.

Containers such as: .AVI, .MP4, .MPG, along with transport containers such as: .TS, .M2TS, .MTS store the aspect ratio signalling information at the "stream" level. Ok, I'm confused here. What do you mean by 'container storing aspect ratio at the stream level'. I thought that stream itself, like x264, may store aspect ratio regardless of what container it is muxed into. Are you saying that if mp4 muxer muxes x264 stream that --does-- include aspect ratio flag, than it just sets a flag somewhere in the container that tells players that the aspect ratio flag is in the stream? And if the stream does not have the signaling than it does include signaling in the container?


Nowadays, most software players know from the container where to look for the aspect ratio signalling. However, hardware player manufacturers have been slower to respond to support the .MKV containers implementation. again - so you are saying that the container specifies if the aspect flag to be observed is in the container, or if it is in the stream? Which would mean that a given container signaling would (or at least could) --always-- take precedence over stream level signaling? Given my experience with various players I think there's absolutely no universally agreed way of dealing with flags specified in both places.

Indeed, software and hadware players will default to 1:1 if no aspect ratio signalling value is present.


Cheers

[jmnk]

copy/pasted from JM Reference Software Manual (JVT-AE010).pdf (which you can read here http://iphome.hhi.de/suehring/tml/JM%20Reference%20Software%20Manual%20(JVT-AE010).pdf ), i don't think it cares about containers at all...



edit1: which wont exaplain how each player should behave of course (if i'am not mistaken...)
edit2: now if somebody has Annex E handy, please copy paste some relevant info on this.
edit3: how would a container-level signaling work? (say you can have 5 streams in it, with each has its own SAR/PAR/whatever), well it could, but why bother with two possibilities then?
thanks for bringing the specs to the discussion. This is exactly why I'm asking - they do not mention the container level signaling. And you bring even better example with multiple video streams, each with its own, and different aspect ratio signaling. That is kind of a reason why I was thinking that the player maybe applies container level first to all streams, and than applies each stream's signaling to each particular stream. Which would be technically OK and even logical - as long as that was agreed on rule.

[SeeMoreDigital]

sure, but if .mkv container contains for example x264 video than the x264 stream can have its own signaling. Which I think was the reason why earlier versions of mkvtoolnix was removing signaling from the stream when it was muxing into mkv - just to avoid confusion I suppose.Actually no.... MKVtoolnix removes the streams aspect ratio signalling and places it in the container, by default. So the software/hardware player does not get confused.

Ok, I'm confused here. What do you mean by 'container storing aspect ratio at the stream level'. I thought that stream itself, like x264, may store aspect ratio regardless of what container it is muxed into. Are you saying that if mp4 muxer muxes x264 stream that --does-- include aspect ratio flag, than it just sets a flag somewhere in the container that tells players that the aspect ratio flag is in the stream? And if the stream does not have the signaling than it does include signaling in the container? Refer to above.

[jmnk]

Actually no.... MKVtoolnix removes the streams aspect ratio signalling and places it in the container, by default. So the software/hardware player does not get confused.

Refer to above.Well, yes, by default. But I can certainly make it --not to remove-- stream level signaling when muxing, so I can have signaling in both places: the stream and the container (at least I'm assuming so as I can tell it not to remove stream level signaling, and I can specify container level signaling when muxing). In that case - which one is to be observed? Or which one --is-- observed?

[SeeMoreDigital]

thanks for bringing the specs to the discussion. This is exactly why I'm asking - they do not mention the container level signaling. And you bring even better example with multiple video streams, each with its own, and different aspect ratio signaling. That is kind of a reason why I was thinking that the player maybe applies container level first to all streams, and than applies each stream's signaling to each particular stream. Which would be technically OK and even logical - as long as that was agreed on rule.That article refers to a part of the official "MPEG-4 (ISO 14496) specification" (http://en.wikipedia.org/wiki/MPEG-4).

The official container, conforming to Part-14 of the MPEG-4 specification, is ".MP4"....

[SeeMoreDigital]

Well, yes, by default. But I can certainly make it --not to remove-- stream level signaling when muxing, so I can have signaling in both places: the stream and the container (at least I'm assuming so as I can tell it not to remove stream level signaling, and I can specify container level signaling when muxing). In that case - which one is to be observed? Or which one --is-- observed?If the parser in the software player fully supports the .MKV container, or if Haali's parser is installed, then the container level signalling takes precedence.

[nurbs]

About the JM Reference Software Manual.
Description: Specifies the value of the sample aspect ratio of the luma samples Default value is 0 (unspecified). See Annex E, Table E-1 of the AVC text for more info.
Options:
0
Unspecified
1
1:1 (“square”)
Does x264 default to unspecified or 1:1 if no AR is given on encoding?

[SeeMoreDigital]

Does x264 default to unspecified or 1:1 if no AR is given on encoding?In my experience, yes.

[SeeMoreDigital]

Actually no.... MKVtoolnix removes the streams aspect ratio signalling and places it in the container, by default. So the software/hardware player does not get confused.Scratch that...

According the MKVtoolnix "changelog": - 2009-04-08 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: By default mkvmerge keeps the aspect ratio information
in AVC/h.264 video bitstreams now (equivalent to specifying
"--engage keep_bitstream_ar_info" in earlier versions). A new
option "--engage remove_bitstream_ar_info" is available that
restores the previous behaviour.

* mkvmerge: bug fix: Fixed the aspect ratio extraction for
AVC/h.264 video by adding three more pre-defined sample aspect
ratios. Mkvmerge also only assumes "free aspect ratio" if the
aspect ratio type information indicates it and not if the
type information is unknown.

[smok3]

:), oh well, at least my calc can now spit the --sar value as well, (hopefully the correct one...)

[nurbs]

In my experience, yes.

Yes is kind of an ambiguous answer to an either-or question. :D

[SeeMoreDigital]

:), oh well, at least my calc can now spit the --sar value as well, (hopefully the correct one...)Way back in September 2008 (http://forum.doom9.org/showthread.php?p=1185071) I asked Mosu if he would consider adding an "--engage keep_bitstream_ar_info" option via a "check box"... and was given an emphatic "No" :(

Anyway, I've just asked him why he changed his mind?

[smok3]

Yes is kind of an ambiguous answer to an either-or question. :D
have a quick look at the encoder.c (my c s*** badly) and i think it is unspecified, also it does not set any VUI_aspect_ratio_info_present_flag, but somebody with better c/x264 knowhow can tell you something nicer :)

[nurbs]

I see, thanks.

[smok3]

Way back in September 2008 (http://forum.doom9.org/showthread.php?p=1185071) I asked Mosu if he would consider adding an "--engage keep_bitstream_ar_info" option via a "check box"... and was given an emphatic "No" :(

Anyway, I've just asked him why he changed his mind?

probably something in conflict with how matroška operates, shrug.

p.s. have encoded another clip with --sar 711/500, which is 'non-standard', should be again abvious if wd-tv can display that, reports later.

[SeeMoreDigital]

Here's a translated post by Mosu from a German forum: -
Originally Posted by Mosu
Because many hardware players can't cope with files without the SAR set within the video bitstream mkvmerge 2.7.0 was changed in a way so that the SAR is no longer removed. Personally, I think it's complete nonsense because the container - as the outer layer - is much easier to modify as the contained bitstream if you want to change the SAR. But OK, reality has told us otherwise - everyone thinks SAR within the bitstream is the way to go.

Good... we now have parity :D

[smok3]

report: both sar values (711/500 and 16/11) appears to work fine.

[SeeMoreDigital]

Nice one ;)

[smok3]

it appears mp4box can add some coverart, untested, but this might work;

mp4box.exe -add "video.264" -add "audio.aac" -itags cover="cover.jpg" "out.mp4"

[SeeMoreDigital]

it appears mp4box can add some coverart, untested, but this might work;

mp4box.exe -add "video.264" -add "audio.aac" -itags cover="cover.jpg" "out.mp4"Yea.... Dunno how "iPod" friendly they are though.... Not that I have an iPod.

The main thing I hate about iTunes, is the massive amount of unnecessary meta data it creates when generating AAC in .M4A files :devil:

[smok3]

wdtv friendly you mean.

[SeeMoreDigital]

wdtv friendly you mean.That too!