Yamb 2.1.0.0 beta 2 is out... [Archive] - Page 13

View Full Version : Yamb 2.1.0.0 beta 2 is out...

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17

SeeMoreDigital

24th June 2009, 09:24

Retry with the last build from here (http://kurtnoise.free.fr/Yamb/). Note that I added an option in Properties to enable "QT compatibility w/ multiple B-VOPs". Hi Kurt...

Sorry mate, I'm unable to make the muxes fully compatible with QT7 Pro. I tried all the different "Brand" options too!

I wonder what mpeg4ip is able to do that MP4box can't?

Kurtnoise

24th June 2009, 10:49

Computed info from media is still wrong :(

aaaa...it's because I didn't changed the second part. Now, it's ok I think with this build (http://www.mediafire.com/file/2ikgoo2yywj/MP4Box-0.4.6-dev_20090624.zip).

I'm unable to make the muxes fully compatible with QT7 Pro. I tried all the different "Brand" options too!
what kind of files did you try ? did you use my last MP4Box dev build ?

SeeMoreDigital

24th June 2009, 17:25

what kind of files did you try ? did you use my last MP4Box dev build ?I'm using the same files as previously uploaded... And, I'm using MP4Box-0.4.6-dev_20090622

Cheers

Kurtnoise

24th June 2009, 18:07

Using my last build (http://kurtnoise.free.fr/index.php?dir=Yamb/&file=Yamb-2.1.0.0b2_20090624.zip) and your sample from here (http://forum.doom9.org/showthread.php?p=1297834#post1297834)...Here is what I get:

http://uppix.net/8/4/6/3648ce6137bbd62fbb84bf59df3dat.jpg (http://uppix.net/8/4/6/3648ce6137bbd62fbb84bf59df3da.html) http://uppix.net/3/3/8/3a7a3e5f66996f8e7e0ae55a76f0ct.jpg (http://uppix.net/3/3/8/3a7a3e5f66996f8e7e0ae55a76f0c.html) http://uppix.net/c/b/f/7f1648fcdee8858657b796f236428t.jpg (http://uppix.net/c/b/f/7f1648fcdee8858657b796f236428.html) http://uppix.net/f/1/4/748f0e171c443b3b113dd183f5b1et.jpg (http://uppix.net/f/1/4/748f0e171c443b3b113dd183f5b1e.html)

[19:03:33] : Yamb 2.1.0.0 beta 2 24/06/2009 compile started !!!
[19:03:33] : OS type detection...Windows Vista x86 (version 6.0, Build 6002 : Service Pack 2)
[19:03:33] : MP4Box found... E:\dev\gpac\bin\gcc\MP4Box.exe
[19:03:33] : Tagger found...E:\dev\gpac\bin\gcc\MP4Box.exe
[19:03:33] : MKVextract found...e:\trash\setup\mkvtoolnix\mkvextract.exe
[19:03:33] : EAC3to found...e:\trash\setup\eac3to\eac3to.exe
[19:03:40] : ghdseethelight.mp4 loaded.
[19:04:39] : Creation of ghdseethelight remux t2.mp4...
[19:04:39] : Command Line used for Creation : "E:\dev\gpac\bin\gcc\MP4Box.exe" -brand mp42 -add "E:\TRASH\ghdseethelight.mp4#1:name=Video Track:lang=en:fps=25.000:delay=1" -add "E:\TRASH\ghdseethelight.mp4#2:name=Audio Track:lang=en" -itags tool="Yamb 2.1.0.0 [http://yamb.unite-video.com]" "E:\TRASH\ghdseethelight remux t2.mp4"
[19:04:39] : File saved in E:\TRASH\
[19:04:40] : Importing ISO File...
[19:04:40] : Importing ISO File...
[19:04:40] : File Writing...
[19:04:40] : Creation complete.
[19:04:40] : Total Time Elapsed...
[19:04:43] : Yamb 2.1.0.0 beta 2 24/06/2009 compile closed.

Brazil2

24th June 2009, 18:44

retry with the last build from here (http://kurtnoise.free.fr/Yamb/).
That fixed the issue for me, thanks :)

BTW where do you get this properties window from ? :
http://uppix.net/f/1/4/748f0e171c443b3b113dd183f5b1et.jpg

SeeMoreDigital

24th June 2009, 18:53

Okay, I now see what we're doing differently....

If you input the complete .MP4 sample, the YAMB mux (or re-mux) is compatible in QT7Pro :)

However, if you input separate elementary (.h264/.aac) streams, the YAMB mux is not compatible in QT7Pro :(

Why would this happen?

SeeMoreDigital

24th June 2009, 18:53

BTW where do you get this properties window from ? :
http://uppix.net/f/1/4/748f0e171c443b3b113dd183f5b1et.jpgQuickTime Pro

Brazil2

24th June 2009, 19:07

QuickTime Pro
OK thanks.

Now I know why I've never seen it before :D

Kurtnoise

24th June 2009, 21:06

SeeMoreDigital

24th June 2009, 22:10

I found why. So, retry with my last build updated. Same link as above...Yep, you've cracked it :D

I've generated a few test muxes and have found that you don't even have to set the "brand" option to "ISO Media File" (ie: mp42). It can be left in "Unspecified" mode (ie: isom) and QT7 Pro is still able to do its thing... Very, very nice.

May I ask. What was the underlying problem?

jmnk

24th June 2009, 22:40

SeeMoreDigital

24th June 2009, 22:49

so I should --not-- specify aspect ratio? regardless of whether I'm muxing mp4 video with mp4 audio, or h264 stream with mp4 audio?
Also, does it ,atter if I mux mp4 audio or acc audio stream?You only need to set the aspect ratio if you generated your (MPEG-4 ASP or AVC) video stream with "non-square" or "anamorphic" shaped pixels.

If you generated your (MPEG-4 ASP or AVC) video stream with "square" shaped pixels, the PAR value of the pixels will be "1:1".

Kurtnoise

25th June 2009, 07:54

May I ask. What was the underlying problem?
some "strange behavior" from the command switches...

kypec

25th June 2009, 08:03

I guess it's time to update thread title or better create a new one with your latest builds.

SeeMoreDigital

25th June 2009, 09:49

some "strange behaviour" from the command switches...I wonder. Could this explain why support for AAC in QT7 is behaving strangely too!

Currently, if you generate an .MP4 encode with say, MeGUI, AutoMKV, HDConvertX, etc. The audio stream part is not compatible with QT7 (an "Error 2041" code warning is displayed). Even after re-muxing the file again with yesterdays YAMB/MP4box builds.

To make it work, what I have to do is open an elementary .AAC stream in QT7 and save it to .MOV. Then with YAMB de-mux the .MOV back to .AAC. The resulting .AAC stream is now QT7 Pro compliant....

Cheers

Kurtnoise

25th June 2009, 10:36

I guess it's time to update thread title or better create a new one with your latest builds.
I would like to add new things before to release beta 2...

I wonder. Could this explain why support for AAC in QT7 is behaving strangely too!

Currently, if you generate an .MP4 encode with say, MeGUI, AutoMKV, HDConvertX, etc. The audio stream part is not compatible with QT7 (an "Error 2041" code warning is displayed). Even after re-muxing the file again with yesterdays YAMB/MP4box builds.

To make it work, what I have to do is open an elementary .AAC stream in QT7 and save it to .MOV. Then with YAMB de-mux the .MOV back to .AAC. The resulting .AAC stream is now QT7 Pro compliant....

with which AAC encoder ? I ran a test from Nero AAC Encoder and all is ok.

Better use : encode A/V streams with your favorite tools and mux them within Yamb. :cool:

Kurtnoise

29th June 2009, 13:53

Hi,

A new beta is available (http://yamb.unite-video.com/) from now...Enjoy !!!

Changes for the 2.1.0.0 beta 2 release (2009/06/29)

[Add-ons]
- TS/M2TS Extraction is now managed by EAC3to.
- QuickTime compatibility for AVC streams containing B-Frames.
- appleTV compliance (not tested on such device though...).
- Windows Seven support.

[Improvements]
- Better Internal Files detection.
- Better AC3-in-MP4 files creation.
- Better MKVExtract detection.
- Few tunings in the NSIS script.

[Updates]
- MediaInfo library (0.7.17)
- MP4Box (0.4.6-dev_20090629)
- MKVExtract (2.9.5)
- EAC3to (3.16)

[Regression]
- Disable temporarily the ASS/SSA Converter. Need to find a better algorithm...

[Fixes]
- Fix splitting command lines errors.
- Fix Matroska tasks conversion.
- Fix mkvtoolnix libs missing from the installer.
- Several other fixes.

parsifal

29th June 2009, 14:51

Thanks Kurtnoise!

Shapierian

29th June 2009, 16:50

Hi,

A new beta is available (http://yamb.unite-video.com/) from now...Enjoy !!!

With this latest beta and (serveral previous versions) I'm having trouble demuxing then remuxing some AAC MP4s (specifically those with PCE based channel configurations).

The channel information gets mangled and demux and mangled worse on re-mux. I believe it is related to this issue https://sourceforge.net/tracker/?func=detail&atid=571738&aid=2419144&group_id=84101 which the MP4Box devs could not reproduce.

The file is available at: http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/audio_conformance/mpeg4audio-conformance/compressedMp4/al00_44.mp4

10032

10033

Kurtnoise

29th June 2009, 17:35

why you want to demux and remux ?

Just add your mp4 file w/ or w/o any extra streams, edit the streams via Properties and create a new one...isn't that you want after all ?

Shapierian

29th June 2009, 17:45

why you want to demux and remux ?

Just add your mp4 file w/ or w/o any extra streams, edit the streams via Properties and create a new one...isn't that you want after all ?

The only reason for re-muxing was to show what QuickTime had to say about the broken demuxed file.

And in general if demuxing and then remuxing is broken then either demuxing or muxing has a bug somewhere.

Schrade

29th June 2009, 19:36

j8ee

30th June 2009, 16:11

A small gui thing - at all error/dialog boxes the text "You must set a FrameRate for Raw AVC streams, otherwise MP4Box will use his own default value 25.000)." comes up, doesn't matter what information or error it's about. And if I may suggest a slightly different wording and another use of capital letters that message would be "You must set a frame rate for raw AVC streams, otherwise MP4Box will use the default value 25.000)."

pihug12

1st July 2009, 13:14

Hello !

When I create a MP4 from a MOV from Apple Trailers (e.g. http://movies.apple.com/movies/disney/toystory3/toystory3-tsr_480p.mov) with Yamb 2.1.0.0 & MP4Box-0.4.6-dev_20090622, the sound is OOS.
Using MP4Box-0.4.5 solves the problem, but the file becomes out of sync again when I send it on Facebook Video for example.

There is probably a problem of structure in the MP4 file.

I can't find the version 0.4.6-dev_20090629.

Kurtnoise

2nd July 2009, 06:09

Testing out the new beta. Here's some problems I found:

Installed beta 2, went into Advanced Settings
Checked the box that says "Overwrite an existing output file."
Checked the box that says "Store file with all media data first (useful for streaming) - An error pops up with:

" " --overWrite doesn't exists.

Hit Next until you can't do anything else then hit Cancel. I get the following error:

Access violation at address 0056F7E5 in module 'Yamb.exe'. Read of address 00000030.
Fixed...thanks for the report.

A small gui thing - at all error/dialog boxes the text "You must set a FrameRate for Raw AVC streams, otherwise MP4Box will use his own default value 25.000)." comes up, doesn't matter what information or error it's about. And if I may suggest a slightly different wording and another use of capital letters that message would be "You must set a frame rate for raw AVC streams, otherwise MP4Box will use the default value 25.000)."
Just edit yourself the English ini file from the lang folder...;)

When I create a MP4 from a MOV from Apple Trailers (e.g. http://movies.apple.com/movies/disney/toystory3/toystory3-tsr_480p.mov) with Yamb 2.1.0.0 & MP4Box-0.4.6-dev_20090622, the sound is OOS.
what do you mean by OOS ? It plays fine for me (tested on VLC & MPC-HC)

Using MP4Box-0.4.5 solves the problem, but the file becomes out of sync again when I send it on Facebook Video for example.

There is probably a problem of structure in the MP4 file.
did you try to demux all streams and remux them ?

I can't find the version 0.4.6-dev_20090629.
part of the installer. why ?

flebber

4th July 2009, 01:47

When I am attempting to use the edit feature to write tags I am receiving an error about double naming.

The only fields entered is a title in the name field an artist name in that field and added Megui to the encoder tag field. But I receive this error across all files.

[10:40:24] : Yamb 2.1.0.0 beta 2 started !!!
[10:40:24] : OS type detection...Windows XP Professional x86 (version 5.1, Build 2600 : Service Pack 3)
[10:40:24] : MP4Box found... C:\Documents and Settings\Family\Application Data\Yamb\MP4Box.exe
[10:40:24] : MKVextract found...C:\Program Files\MKVtoolnix\mkvextract.exe
[10:40:24] : EAC3to found...c:\documents and settings\family\application data\yamb\eac3to\eac3to.exe
[10:43:05] : Tagging of poison_-_life_goes_on.mp4...
[10:43:05] : Command Line used for the tagging : "C:\Documents and Settings\Family\Application Data\Yamb\MP4Box.exe" -itags :tool=Yamb 2.1.0.0 [http://yamb.unite-video.com]" ""
[10:43:05] : Error - 2 input names specified, please check usage
[10:43:05] : Tagging of System Of A Down - Chop Suey!.mp4...
[10:43:05] : Command Line used for the tagging : "C:\Documents and Settings\Family\Application Data\Yamb\MP4Box.exe" -itags :tool=Yamb 2.1.0.0 [http://yamb.unite-video.com]" ""
[10:43:06] : Error - 2 input names specified, please check usage
[10:43:06] : Tagging of System Of A Down - Toxicity.mp4...
[10:43:06] : Command Line used for the tagging : "C:\Documents and Settings\Family\Application Data\Yamb\MP4Box.exe" -itags :tool=Yamb 2.1.0.0 [http://yamb.unite-video.com]" ""
[10:43:06] : Error - 2 input names specified, please check usage
[10:43:19] : Yamb 2.1.0.0 beta 2 closed.

Kurtnoise

5th July 2009, 15:53

using MP4 File Creation or using the Edit section ?

flebber

6th July 2009, 00:32

Edit section. The mp4's were encoded in megui and I was attempting to remux new tags in.

TomF

7th July 2009, 19:33

Hi,

I have a Yamb (-Newbie) problem (latest version): Trying to join three *.mp4 files to one file, I can do what I want. Every time I get a file as big as three single files. But playing this big file shows only a little bit more (time) than the first of the three files ...

Any idea or link...?

Thanks a lot.
Regards
Thomas

jmnk

9th July 2009, 06:06

I'm sorry if it has been asked before.
The 'Pixel Aspect Ratio' in Yamb, accessible via selecting a video track and clicking Properties - what is it supposed to specify? The label would suggest Pixel Aspect Ratio, but the options in the dropdown box are like Display Aspect Ratio values. And the outcome - the resulting muxed file after applying this Pixel Aspect Ratio - does not seem to make much sense to me.
I started with x264 video stream (resolution 720x358, flagged with --sar 1969:1620 in megui) and used 16:9 NTSC option - the resulting file plays at around 872x358 resolution. When I use 4:3 NTSC option the resulting file plays at around 720x392 resolution. How does the math works?
And why would vertical resolution ever change?

SeeMoreDigital

9th July 2009, 08:24

I'm sorry if it has been asked before.Yep... loads of times on the forum

I started with x264 video stream (resolution 720x358, flagged with --sar 1969:1620 in megui) and used 16:9 NTSC option - the resulting file plays at around 872x358 resolution. When I use 4:3 NTSC option the resulting file plays at around 720x392 resolution. How does the math works?
And why would vertical resolution ever change?Look here: -

http://forum.doom9.org/showthread.php?p=1034465

jmnk

9th July 2009, 17:39

Yep... loads of times on the forum

Look here: -

http://forum.doom9.org/showthread.php?p=1034465
@SeeMoreDigital - thanks for posting a comment. Maybe I do not see trees through the forest - but where in your response/link do I find an answer about what Pixel Aspect Ratio in Yamb is? Because the examples I provided show it is really neither DAR of the final video, nor SAR, nor PAR.

jmnk

11th July 2009, 19:18

does YAMB remove stream level aspect ratio signaling of x264 stream when muxing to mp4? Or does it replace stream level signaling with a value that matches container level signaling?

SeeMoreDigital

11th July 2009, 22:13

does YAMB remove stream level aspect ratio signaling of x264 stream when muxing to mp4? No... it leaves it intact.

Or does it replace stream level signaling with a value that matches container level signaling?No... not with .MOV or .MKV contained sources.

jmnk

12th July 2009, 05:13

does YAMB remove stream level aspect ratio signaling of x264 stream when muxing to mp4?
No... it leaves it intact..
If by "leaving intact" you mean 'does not touch it' than apparently that is not the case. See this analysis http://forum.doom9.org/showthread.php?p=1304585#post1304585
I'm as suprised as you are. Although it may not be a bad thing that YAMB appears to change stream level signaling to match conatiner level signaling - as long as that is intentional and well known (and probably optional).

Or does it replace stream level signaling with a value that matches container level signaling?
No... not with .MOV or .MKV contained sources.
I'm sorry, I do not know what you mean. Could you elaborate?

SeeMoreDigital

12th July 2009, 09:08

I'm sorry, I do not know what you mean. Could you elaborate?Both the .MOV and .MKV containers are able to support aspect ratio signalling at the container level.

When you said: "Or does it replace stream level signaling with a value that matches container level signaling?" This would suggest that your "input files" were in a container (either .MOV or .MKV) and not elementary .h264/.246 streams.

Is this not the case?

jmnk

12th July 2009, 16:41

Both the .MOV and .MKV containers are able to support aspect ratio signalling at the container level.

When you said: "Or does it replace stream level signaling with a value that matches container level signaling?" This would suggest that your "input files" were in a container (either .MOV or .MKV) and not elementary .h264/.246 streams.

Is this not the case?

Actually no. What I meant was: 'I use elementary stream x264 already flagged on stream level with SAR (let's say stream is 720x480, with SAR 40:33) as an input to YAMB, and than I select Pixel Aspect Ratio option in YAMB 4:3 NTSC (just to see what happens, not that it is good thing to have different flag in the stream and different in container). While 4:3 NTSC seems clearly to be an indication of DAR, apparently YAMB translates that to SAR (I think 10:11), taking into account input resolution. Anyway, at the end I get mp4 file where the same SAR signaling is present: on container level and on stream level. So when I unmux such mp4 back to elementary stream I do not get my stream back - I get a stream flagged with SAR 10:11 - because apparently YAMB overwrites stream level signaling with the one I specify in YAMB.
Which is kind of what previous mkvtoolnix did when muxing streams into mkv.

SeeMoreDigital

12th July 2009, 18:21

Actually no. What I meant was: 'I use elementary stream x264 already flagged on stream level with SAR (let's say stream is 720x480, with SAR 40:33) as an input to YAMB, and than I select Pixel Aspect Ratio option in YAMB 4:3 NTSC (just to see what happens, not that it is good thing to have different flag in the stream and different in container). Yes it's not a good idea to have different values for the stream and container...

While 4:3 NTSC seems clearly to be an indication of DAR, apparently YAMB translates that to SAR (I think 10:11), taking into account input resolution. Hmmm...

From your post I'm not convinced you fully understand what these abbreviations are all about.

DAR and SAR are essentially different terminologies that end up referring to one thing. The "pixels" aspect ratio value, ie: PAR.

With regard to the term "DAR" (Display Aspect Ratio), it's roots are MPEG-2 based. Essentially there are only two DAR "shapes" worth knowing about, 4:3 and 16:9.

Unlike the MPEG-4 video standard, the (main-level) MPEG-2 video standard only allows you to generate encodes using two standard-definition "height" resolutions. These are 480 and 576.

So if you have an MPEG-2 video file with a fixed height of 576 pixels and a width of say, 704 pixels, the first thing we know about the source is, it's PAL (the 576 bit gives that away).

If when we play the file, the displayed image adopts a 16:9 shape, the second thing we now know about the source is, it's been encoded with "16:9 DAR" or to be more precise "16:9 PAL DAR".

Now here's the interesting bit....... even if the afore mentioned file had a width of just 352 pixels and when played was displayed at a 16:9 shape, it would still have been encoded with "16:9 PAL DAR".

Meaning the the phrase "DAR" doesn't tell you the actual shape of the encoded pixels, it only tells you the shape of the displayed image!

The actual shape of the encoded pixels is directly related to the quantity of width pixels. Indeed, the greater quantity of width pixels the less each pixel has to be stretched width-ways.

So what does this mean? Well it means if you want to find out the actual shape of the encoded pixels we'll need to do some maths. And guess what terminology we use to describe this finished value... We call it "PAR"!

Cheers

Keiyakusha

12th July 2009, 18:49

From your post I'm not convinced you fully understand what these abbreviations are all aboutSAR is (AKA) PAR. period.
Do you mean this? If so, yes. I also think this is confusing... when one thing has 2 abbreviations.

Actually no. What I meant was: 'I use elementary stream x264 already flagged on stream level with SAR (let's say stream is 720x480, with SAR 40:33) as an input to YAMB, and than I select Pixel Aspect Ratio option in YAMB 4:3 NTSC (just to see what happens, not that it is good thing to have different flag in the stream and different in container). While 4:3 NTSC seems clearly to be an indication of DAR, apparently YAMB translates that to SAR (I think 10:11), taking into account input resolution. Anyway, at the end I get mp4 file where the same SAR signaling is present: on container level and on stream level. So when I unmux such mp4 back to elementary stream I do not get my stream back - I get a stream flagged with SAR 10:11 - because apparently YAMB overwrites stream level signaling with the one I specify in YAMB.
Which is kind of what previous mkvtoolnix did when muxing streams into mkv.

YAMB is a gui for mp4box. mp4box can set SAR by "patching" the h264 stream. If you want to override SAR, you should set "custom" value in YAMB. All above custom is some kind of presets. 4:3 NTSC is 10:11 SAR and should be valid for 704x480 resolution since 10/11*704=640
Thats why I asked you why you need to override SAR if it already there...

SeeMoreDigital

12th July 2009, 19:44

Do you mean this? If so, yes. I also think this is confusing... when one thing has 2 abbreviations.Yes... PAR and SAR are indeed the same thing :eek:

You'll have to blame the guys over at MPEG (Moving Picture Experts Group) for the "SAR" abbreviation... As far as I know it cropped up (as we know it today) in Part10 of the MPEG-4 specifications.

smok3

12th July 2009, 21:44

SeeMoreDigital

12th July 2009, 22:38

a. so if you start with 40:33 (extended sar?) and end up with 10:11 (sar), then it appears as if yamb is using sar to overwrite your extended_sar info.
b. (unrelated to a.) sar should be unspecified (according to e.2.1) only when values for sarx, sary or aspect_ratio_idc are 0.Hmmm....

If the input files resolution is 720x480 and 4:3 NTSC DAR was applied, the PAR (SAR) should be 8:9.... It would only be 10:11 if the input files resolution was 704x480.

smok3

12th July 2009, 22:41

SeeMoreDigital: check the annex e somebody posted, it is not about the correct math.

SeeMoreDigital

12th July 2009, 22:50

SeeMoreDigital: check the annex e somebody posted, it is not about the correct math.It bloody well should be :devil:

Keiyakusha

12th July 2009, 23:23

So what do the specs tell us? If I have 720x480 (no crop, no resize), for 16x9 I need to set SAR 40:33? If so, we will get right proportions assuming that our video has 16px of black borders.
But all of new DVDs that I saw (mostly anime) doesn't have black borders (well maybe little borders ~2px max) and they have right proportions with SAR 32:27.
Am I miss something?

smok3

13th July 2009, 00:15

i was trying to say only that there seems to be two options with h.264, one is SAR, the other is eSAR, yamb seems to use only the 1st one (not so with mp4box)..., however i'am not 100% sure i'am reading the specs as they should be read...

p.s. borders or no borders should not be an issue, the SAR should stay the same.

example;

no borders
http://resizecalc.somestuff.org/index.php?ssmw=720&sar=1.42222&sar2=&ssmh=576&CT=0&CL=&CR=&CB=0&mplayCrop=&trw=&dar=1.42222&dar2=&modw=&modh=&padw=&padh=&css=&doit=true
borders cropped
http://resizecalc.somestuff.org/index.php?ssmw=720&sar=1.42222&sar2=&ssmh=576&CT=80&CL=&CR=&CB=80&mplayCrop=&trw=&dar=1.42222&dar2=&modw=&modh=&padw=&padh=&css=&doit=true

Keiyakusha

13th July 2009, 00:36

i was trying to say only that there seems to be two options with h.264, one is SAR, the other is eSAR, yamb seems to use only the 1st one (not so with mp4box)..., however i'am not 100% sure i'am reading the specs as they should be read...

Ah I see... We have to wait for Kurtnoise response then.

p.s. borders or no borders should not be an issue, the SAR should stay the same.
No... I'm talking about vertical borders. As I remember on analogue TVs part of the image was cropped durring playback. That's why there was 720x480 with 16px black borders and 40:33 SAR. But now it seems that this borders is filled with "good pixels" so often we need to set 32:27 SAR. This is what I mean... EDIT: Also your example is PAL, I have no idea about it. For now let's forget about it since this is kind of OT here, which I started.

Kurtnoise
With latest two betas of YAMB I can't load PNG artwork. And if folder with PNG image also contains JPG images then all of this images is loaded instead. Can you please look at this?

jmnk

13th July 2009, 03:44

Yes it's not a good idea to have different values for the stream and container...
well, in general no. That's what I have said, right? But it is not technically incorrect - and it is the basis for this whole theoretical discussion.

While 4:3 NTSC seems clearly to be an indication of DAR, apparently YAMB translates that to SAR (I think 10:11), taking into account input resolution.

Hmmm...

From your post I'm not convinced you fully understand what these abbreviations are all about.

DAR and SAR are essentially different terminologies that end up referring to one thing. The "pixels" aspect ratio value, ie: PAR.

With regard to the term "DAR" (Display Aspect Ratio), it's roots are MPEG-2 based. Essentially there are only two DAR "shapes" worth knowing about, 4:3 and 16:9.

Unlike the MPEG-4 video standard, the (main-level) MPEG-2 video standard only allows you to generate encodes using two standard-definition "height" resolutions. These are 480 and 576.

So if you have an MPEG-2 video file with a fixed height of 576 pixels and a width of say, 704 pixels, the first thing we know about the source is, it's PAL (the 576 bit gives that away).

If when we play the file, the displayed image adopts a 16:9 shape, the second thing we now know about the source is, it's been encoded with "16:9 DAR" or to be more precise "16:9 PAL DAR".

Now here's the interesting bit....... even if the afore mentioned file had a width of just 352 pixels and when played was displayed at a 16:9 shape, it would still have been encoded with "16:9 PAL DAR".

Meaning the the phrase "DAR" doesn't tell you the actual shape of the encoded pixels, it only tells you the shape of the displayed image!

The actual shape of the encoded pixels is directly related to the quantity of width pixels. Indeed, the greater quantity of width pixels the less each pixel has to be stretched width-ways.

So what does this mean? Well it means if you want to find out the actual shape of the encoded pixels we'll need to do some maths. And guess what terminology we use to describe this finished value... We call it "PAR"!

Cheers
@SeeMoreDigital - I certainly see that you try to help - but for whatever reason we do not seem to get on the same page. I have no idea why you pass judgement that I do not get what PAR/SAR and DAR is all about. If anything, I would think that perhaps you should re-read the post twice.
I'm saying that YAMB labels its option 'Pixel Aspect Ratio'. The dropdown box provides the following options:
4:3 PAL
4:3 NTSC
16:9 PAL
16:9 NTSC
Custom
if these were indeed PAR (which is the same as SAR) values, than a video 720x480 flagged with 'Pixel Aspect Ratio 4:3 NTSC' would play at 720*4/3 = 960 x 480. But that is clearly not the case, because what this label (Pixel Aspect Ratio 4:3 NTSC) apparently means is: 'I'm going to flag video input such that the resulting video will play at 4:3 DAR'. Which results in a SAR value of 10:11 being applied to video stream 720x480. And that indeed results in final video being played at 720 * 10:11 = 654 x 480, which is almost 4:3 DAR. The 'almost' comes from the fact that if SAR of 10:11 is used than it should be assumed/understood that for DVD source we only take 704 resolution, rather than 720. If it was 704 than the final resolution would be 704 x 10/11 = 640 x 480 - exactly 4:3 DAR.
So I'm pointing out that perhaps YAMB label (at least in english language) is a bit misleading.
Now to add to the confusion, if one chooses 'Custom' option and enters two integers in the pop out box (like 4 and 3) than this values are taken by YAMB as indeed SAR values!

Am I not clear?

But the main question was if YAMB replaces signaling of the video stream when muxing. Both you and me thought --no--, but it looks like it does. Which again, could be fine, if well understood.

jmnk

13th July 2009, 03:47

YAMB is a gui for mp4box. mp4box can set SAR by "patching" the h264 stream. If you want to override SAR, you should set "custom" value in YAMB. All above custom is some kind of presets. 4:3 NTSC is 10:11 SAR and should be valid for 704x480 resolution since 10/11*704=640
.
yes, indeed, that appears to be the case. I just thought that YAMB sets container level signaling only and does not change stream level signaling. Apparently it does both.

jmnk

13th July 2009, 03:49

a. so if you start with 40:33 (extended sar?) and end up with 10:11 (sar), then it appears as if yamb is using sar to overwrite your extended_sar info.

yes indeed - perhaps this is news to you as well. It was to me and to SeeMoreDigital.