Yamb 2.1.0.0 beta 2 is out...

[jmnk]

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.
@SeeMoreDigital and @Keiyakusha
well yes indeed! That's why I'm questioning both MeGUI and YAMB SAR signaling calculations. They both seem to use ITU SAR values - but never recommend that the input DVD source should be 704 and not 720.
I can see both sides of argument that one should use:
1) 720 - and SAR 8:9, or
2) 704 and SAR 10:11.
But I see little logic in using 720 and SAR 10:11. Yet that is what happens in these otherwise excellent tools. Oh yah, and why MeGUI seems to calculate these four digits SAR values for DVD type/resolution input - can't seem to get answer to othat one either.

[Kurtnoise]

Yamb doesn't use ITU values. It uses values specify in ISO...and no calculations are done inside Yamb about this. It's done by MP4box.

anyway, I don't see the problem. You can specify whatever you want here...


edit: Importing (mux) & Exporting (demux) are 2 different things for MP4Box.

[jmnk]

Yamb doesn't use ITU values. It uses values specify in ISO...
OK, you are right. But I'm not really wrong either. I wanted to say that Yamb uses values that are generally referred to, on these forums, as MPEG-4/ITU values. As opposed to MPEG-2 values. In practice I meant that the SAR for 4:3 NTSC DVD video is 10:11, and not 8/9 (or for 16:9 NTSC DVD it is 40:33 and not 32:27)
and no calculations are done inside Yamb about this. It's done by MP4box. well, after I've run some more tests, yes. I was giving YAMB too much credit :). It indeed doesn't do any calculations - it is just plain misleading.

anyway, I don't see the problem. You can specify whatever you want here...I think it can be safely argued that at the very least the option is mislabeled.

In Yamb, otherwise a nice tool, you have the following:
option labeled 'Pixel Aspect Ratio'. The dropdown box provides the following options:
4:3 PAL
4:3 NTSC
16:9 PAL
16:9 NTSC
Custom

so do these options do? well, let's assume that I selected 4:3 NTSC. Just reading the label one could think that SAR passed to mp4box would be 4:3. But that is so unusual SAR that it could not practically be that (16:9 is even more unusual). So I thought that Yamb does something like: 'I'm going to calculate what SAR to pass to mp4box such that the resulting file, regardless of its resolution, will play at 4:3 aspect ratio' - which, with the exception of labeling, would be quite reasonable. So my thinking was that depending on what the reslotion of the file is, the SAR would have to be calculated. For example, for 720x480 resolution, SAR would be 10:11. For 640x480 resolution SAR would be 1:1. And so on.
But that is --not-- what happens. It seems that while this option is labeled 4:3 NTSC it means 'SAR 10:11' - because regardless of the resolution of the file the SAR passed to mp4box is --always-- 10:11. Which happens to make some sense only if input resolution is 704x480 - because resulting file will be played at 704*10/11 = 640x480 - which happens to be 4:3. But if input resolution is for example 640x480 than the resulting file will play at 640*10/11 = 582x480 - which is really aspect ratio that has nothing to do with 4:3. In short a user needs to know that '4:3 NTSC' option means 'SAR=10:11' (and the other options mean respective SAR values). Always. Maybe it is just me that finds it confusing.
In addition, if I select 'Custom', and I enter two digits in the box - they are used verbatim, as SAR. So the 'Custom' option is the --only-- one that reflects the label, and that makes sense. But than it is inconsistent with how any other option behaves.

[Kurtnoise]

I understand what you mean but the fact is most people don't know what values correspond to 10:11 or 40:33, etc... That's why I put this in the dropdown list.

A better way would be to change the MP4Box switch (i.e replace --par by --sar ). What do you think ? It's quite easy to do...

[kypec]

I think that changing switch in MP4Box CLI is not a good idea...
I fully agree with jmnk, the PAR value could be calculated by Yamb according to input video resolution and user specified DAR=SAR. Just rename the dropdown list to "Display aspect ratio", leave the choices untouched except the last one which should be renamed to "Custom PAR (X:Y)" and everyone will be satisfied. No more confusions about is it PAR being set in the output stream? Or is it DAR?

[jmnk]

I understand what you mean but the fact is most people don't know what values correspond to 10:11 or 40:33, etc... That's why I put this in the dropdown list.

A better way would be to change the MP4Box switch (i.e replace --par by --sar ). What do you think ? It's quite easy to do...

I think the best way would be to replace the options in the dropdown box to read:

40:33
32:27
10:11
8:9
Custom

and leave the label the way it is, and leave mp4box command line options the way they are. And maybe some short manual, or a tooltip.

I agree that perhaps those that do not know 10:11, 40:33 and so on will not get any smarter - but those that do know will not be confused.

[smok3]

A better way would be to change the MP4Box switch (i.e replace --par by --sar ). What do you think ? It's quite easy to do...
PAR and SAR are basically the same thing, so i don't understand what are you saying?

p.s. The problem with current pulldown selection is that you are calling it PAR (but the values are DAR's).

edit: the second 'problem' is that yamb doesn't seem to read any SAR/PAR/DAR values from video (mp4) files, so assuming i just wan't to mux in the audio, i will get wrong file on output?

[SeeMoreDigital]

I think the best way would be to replace the options in the dropdown box to read:

40:33
32:27
10:11
8:9
Custom
Not really... Those values will only work if the source resolutions are either 720x576 or 720x480.

The whole purpose behind "4:3 DAR" and "16:9 DAR" options is you don't need to know the sources "width" resolution.

The current "drop-down" options are fine, they just need to follow the same calculation method as used for MPEG-2.

[jmnk]

View Post
I think the best way would be to replace the options in the dropdown box to read:

40:33
32:27
10:11
8:9
Custom
Not really... Those values will only work if the source resolutions are either 720x576 or 720x480.

The whole purpose behind "4:3 DAR" and "16:9 DAR" options is you don't need to know the sources "width" resolution.

The current "drop-down" options are fine, they just need to follow the same calculation method as used for MPEG-2.
@SeeMoreDigital - again, you haven't exactly read the post explaining the problem, did you. The thing is these values are --not-- DAR, they only appear to be so.
In practice the only fool-proof option is to leave one option 'Custom' requiring a user to enter the desired SAR. The other four option --could-- be there to aid a user - if there was manual/tooltip explaining when one should use those.
And these values will work not only for 720x576 or 720x480 input resolutions, they will work for any resolution that need to be stretched on playback by these values. Which in practice means --any-- resolution that originated from PAL or NTSC DVD and was not resized, but was/could have been cropped. So, for example, if you have a 16:9 NTSC DVD where actual image resolution is 720x448 (and you cropped 16 pixels of black bars off the top and 16 pixels off the bottom) than SAR 32:27 is perfectly correct.

Unless you are suggesting that Yamb leaves these options as true indication of what DAR will be on playback and Yamb correctly calculates the desired SAR to pass to mp4box. Which would be fine as well, but the 'Custom' option behavior would have to be changed. And Kurtnoise apparently doesn't want Yamb to do any calculations.

[Keiyakusha]

Not really... Those values will only work if the source resolutions are either 720x576 or 720x480.

The whole purpose behind "4:3 DAR" and "16:9 DAR" options is you don't need to know the sources "width" resolution.

For example in most cases I want to make 720x480 to be resized to 853.3 on playback so I need to set 32:27 sar. Then I see 16:9 DAR option and oops, output is wrong because its actually 40:33 SAR
You DO need to know sources "width" resolution because YAMB doesn't calculate anything. I also can have 640x480 and want it to be 853x480 on playback... so DAR values can be misleading here even for those who don't know anything about SAR.

[SeeMoreDigital]

For example in most cases I want to make 720x480 to be resized to 853.3 on playback so I need to set 32:27 sar. Then I see 16:9 DAR option and oops, output is wrong because its actually 40:33 SAR
You DO need to know sources "width" resolution because YAMB doesn't calculate anything. I also can have 640x480 and want it to be 853x480 on playback... so DAR values can be misleading here even for those who don't know anything about SAR.Yea... So what's required are DAR options that actually work correctly....

Or do away with everything except the "custom" option. Which you could use in-conjunction with my ARS calculator (http://www.one.seemoredigital.net/Downloads/ARS_Calculator.zip) ;)

[Keiyakusha]

Yep, I this is my point too. By the way, I'm using ARS calculator for some time and this is the only tool I'm happy with in all this SAR/DAR mess.

[SeeMoreDigital]

Yep, I this is my point too. By the way, I'm using ARS calculator for some time and this is the only tool I'm happy with in all this SAR/DAR mess.Thanks...

I guess if it was able to run without .NET, it could be incorporated into other applications.

[kypec]

PAR and SAR are basically the same thing, so i don't understand what are you saying?No, they are not. They differ numerically and that is the cause of all the confusions and misinterpretation. One needs to understand nothing but a simple formula: SAR = FAR * PAR
Given that FAR (frame aspect ratio alias width [in pixels] / height [in pixels]) is never 1 in real life then SAR != PAR in mathematical terms.

[Kurtnoise]

edit: the second 'problem' is that yamb doesn't seem to read any SAR/PAR/DAR values from video (mp4) files, so assuming i just wan't to mux in the audio, i will get wrong file on output?
what ? I don't understand what you mean...if your input video *already* contains any AR infos, Yamb uses it as well during the mux. It just a 1:1 copy in this case.



Anyway guys, I'll see what can I do to improve this in the future.

[smok3]

what ? I don't understand what you mean...if your input video *already* contains any AR infos, Yamb uses it as well during the mux. It just a 1:1 copy in this case.

i assumed it works that way, only that is not clear from the gui, so this seems to be a root for confusion.

One needs to understand nothing but a simple formula: SAR = FAR * PAR
Given that FAR (frame aspect ratio alias width [in pixels] / height [in pixels]) is never 1 in real life then SAR != PAR in mathematical terms.

kypec, where did you get this 'formula', any links? (you are wrong)

[Kurtnoise]

i assumed it works that way, only that is not clear from the gui, so this seems to be a root for confusion.
why it's confusing ? MP4Box is smart enough for a such thing. ;) No need to tweak it...

[Wilbert]

No, they are not. They differ numerically and that is the cause of all the confusions and misinterpretation. One needs to understand nothing but a simple formula: SAR = FAR * PAR
No, that's wrong (as smok3 says). It should be SAR = 1/PAR. With SAR being the sample aspect ratio and PAR being the pixel aspect ratio as used in the mpeg-2/mpeg-4 specs.
It might be that you use a different meaning of SAR, but that's not the meaning as used in the specs.

[smok3]

nope, SAR=PAR.
link (s)
http://www.transcoding.org/cgi-bin/transcode?action=browse&diff=1&id=Aspect_Ratio
http://www.mir.com/DMG/aspect.html

[Brazil2]

Kurtnoise, what's new in MP4Box-0.4.6-dev_20090715 ?

Is it still compatible with Yamb 2.1.0.0 beta2 ?

[Kurtnoise]

Kurtnoise, what's new in MP4Box-0.4.6-dev_20090715 ?
you can specify framerate as fraction :
MP4Box -fps 24000:1001 -add input.h264 output.mp4

Fix wrong bitrate calculation as noticed by kypec.


Is it still compatible with Yamb 2.1.0.0 beta2 ?
sure...unless I missed something.

[kypec]

No, that's wrong (as smok3 says). It should be SAR = 1/PAR. With SAR being the sample aspect ratio and PAR being the pixel aspect ratio as used in the mpeg-2/mpeg-4 specs.
It might be that you use a different meaning of SAR, but that's not the meaning as used in the specs.
The formula I mentioned is truly wrong. The error was caused by my assumption that SAR is precisely the same thing as DAR. What is that SAR standing for then? One of you call it Signalling Aspect Ratio while other refers to it as Sample Aspect Ratio. Which of these is right?

Anyway I'm pretty sure that DAR = FAR * PAR is correct. I use this calculation for all my XviD & x264 encodes from DVD sources and never experienced anything wrong with them. Of course, my AVS scripts are all producing CROPPED picture (http://forum.doom9.org/showthread.php?p=1034465#post1034465), no black bars/mattes whatsoever.
Assuming that DAR (Display AR) is the ratio of final picture viewer is supposed to see on the screen = Horizontal width (measuring units are irrelevant in this case) divided by Vertical height, let's say 16:9=16/9=1.777777
FAR (Frame AR) is the ratio of physically encoded pixels in the video stream, let's say for resolution 640 x 512 it means FAR=640/512 (square pixels are assumed in this case)=1.25
Given those numbers I have to set the PAR (Pixel AR describing the proportions of single pixel a.k.a. width to height ratio) to 64:45 because PAR=DAR/FAR=(16/9)/(5/4)=64/45

[smok3]

according to itu, SAR is sample aspect ratio, according to human imagination it may be 'salad aspect ratio' (yes, this acronyms are a mess...).

http://blog.somestuff.org/images/sample_aspect_ratio.png

[Kurtnoise]

you can specify framerate as fraction :
MP4Box -fps 24000:1001 -add input.h264 output.mp4

Fix wrong bitrate calculation as noticed by kypec.

Forgot also to mention MPEG-4 SLS detection...

[kypec]

Kurtnoise, there seem to be some weird behaviour of your/yours host webserver.
When I type in the browser dialog http://kurtnoise.free.fr/Yamb (notice the uppercase Yamb) everything is working ok:
http://i29.tinypic.com/2ldg74w.jpg

However, after changing Yamb to lowercase yamb http://kurtnoise.free.fr/yamb, your page is unreachable -> redirected to:
http://i28.tinypic.com/2h5ql2g.jpg

I'm sure that URL should be case insensitive as such, if they are not something is not right.
BTW I'm using FF3.0.11 but IE7 exhibits the same results so it's definitely not a browser problem :mad:

[Kurtnoise]

nothing is weird...the uppercase is mandatory. :p

[smok3]

usually only domain names are case insensitive, the rest depends on the server OS/server patches/ect.

[kypec]

usually only domain names are case insensitive, the rest depends on the server OS.
Well, then his server is poorly configured I guess. Never before I experienced case-sensitive URL links on the web, ever :eek:

[smok3]

nope, most of the web is on apache/*nix, so that is to be expected, example;
http://forum.doom9.org/Faq.php 'fails'
http://forum.doom9.org/faQ.php 'fails'
http://forum.doom9.org/faq.php ok
http://Forum.DOOM9.org/faq.php ok
edit: and we are again totally off topic, my apologies to the op.

[sneaker_ger]

Hi,

with the following version of YAMB, the "keep nvops" feature when adding xvid avis does not work:
http://yamb.unite-video.com/Yamb-2.1.0.0_beta2_setup.exe

[Kurtnoise]

what do you mean by "it doesn"t work" ?

could you post the logfile please ?

[sneaker_ger]

The nvops are dropped as if "nodrop" wasn't set.[22:46:20] : Yamb 2.1.0.0 beta 2 started !!!
[22:46:20] : OS type detection...Windows XP Professional x86 (version 5.1, Build 2600 : Service Pack 3)
[22:46:20] : MP4Box found... C:\Dokumente und Einstellungen\xyz\Anwendungsdaten\Yamb\MP4Box.exe
[22:46:20] : MKVextract found...C:\Programme\MKVtoolnix\mkvextract.exe
[22:46:20] : EAC3to found...c:\dokumente und einstellungen\xyz\anwendungsdaten\yamb\eac3to\eac3to.exe
[22:46:23] : NvopTest_oBf_50_AviSource.avi loaded.
[22:46:27] : NvopTest_oBf_50_AviSource.mp4 will be overwritten.
[22:46:27] : Creation of NvopTest_oBf_50_AviSource.mp4...
[22:46:27] : Command Line used for Creation : "C:\Dokumente und Einstellungen\xyz\Anwendungsdaten\Yamb\MP4Box.exe" -add "C:\Dokumente und Einstellungen\xyz\Desktop\mp4test\NvopTest_oBf_50_AviSource.avi#video:fps=25.000:nodrop" -itags tool="Yamb 2.1.0.0 [http://yamb.unite-video.com]" -new "C:\Dokumente und Einstellungen\xyz\Desktop\mp4test\NvopTest_oBf_50_AviSource.mp4"
[22:46:27] : File saved in C:\Dokumente und Einstellungen\xyz\Desktop\mp4test\
[22:46:27] : Importing AVI Video Stream...
[22:46:27] : File Writing...
[22:46:27] : Creation complete.
[22:46:27] : Total Time Elapsed...

[Spicae]

How to extract chapters from mp4 files? not find this function using Yamb 2.1.0.0 beta 2.
I used Yamb 2.0.0.8 but it doesn't seem right.
It came up with "CHAPTER02=02:30:30.000"(9030.000) when actually 90.30s.

[Kurtnoise]

How to extract chapters from mp4 files? not find this function using Yamb 2.1.0.0 beta 2.

Menu Editing -> Extract Streams from AVI/MOV/MP4/TS files...

[Spicae]

Sorry,I don't make it clear. I meant that i can see the chapter info using 2.0.0.8. but in 2.1.0.0 beta 2 when i input the file I could only find video and audio track listed in "content".

[Kurtnoise]

I'll check it out asap...

[Keiyakusha]

Hmm... Strange stuff happens with me...
If I do following:
Start YAMB -- Click on "Create Mp4..." -- Click on "Back" -- Click on "Editing" -- Double-click on "Extract streams..." -- Choose .mp4 file (1st stream and extract to raw are selected by default) -- Click Next -- Click Finish (after its done) -- Confirm that I want to quit -- I see report that mp4box crashed and then I see this infinite loop (http://www.petaimg.com/u308/8Yambloop.jpg).
If after starting I will NOT go to the -- Click on "Create Mp4..." -- Click on "Back" -- this is NOT happens.

[Joyce7]

Just did some tests with .264, .aac, and .idx, and everything worked really fine as expected.

Nice work.

[j8ee]

When having three files named 1_video.h264, 2_video.h264 and 3_video.h264, and using yamb to put the first file in mp4, it deletes all three h264-files.

[Undead Sega]

Is it possible or to even add a feature where u can add a .SUP stream to a MP4 container with this?

[Kurtnoise]

When having three files named 1_video.h264, 2_video.h264 and 3_video.h264, and using yamb to put the first file in mp4, it deletes all three h264-files.
ok...fixed.

Is it possible or to even add a feature where u can add a .SUP stream to a MP4 container with this?
nope.

[juGGaKNot]

Can i use it cli only ? for muxing avi with aac.

[Kurtnoise]

nope...

[Undead Sega]

nope.

Why is this may i ask? :( isnt there any container out there besides for MKV that can accept a SUP stream?

[Kurtnoise]

why ? because it's not supported.

M2TS/VOB containers support SUP format as well.

[rack04]

Can i use it cli only ? for muxing avi with aac.

YAMB uses mp4box for muxing. Are you asking about muxing to avi? If so, you'll need to find another program.

[Undead Sega]

well it is not like a M2TS/VOB containers can have AVC streams :(

if i am correct, a SUP file is a raw dvd subtitle stream?

[SeeMoreDigital]

well it is not like a M2TS/VOB containers can have AVC streams :(Eh!

M2TS is "the" container used by Blu-ray and AVC-HD for storing MPEG-4 AVC video streams...

[Undead Sega]

ahh okay then, my bad, but ti cannot be read on the Xbox 360 correct?

[Undead Sega]

anyone?

anyways, ive tried out making a VobSub which i did successfully, and tried inserting it as a tream in YAMB, everything seems to have been going well but i think when it came to the subtitle stream it failed completely and didnt complete creating the file. I believe the VobSub is fine but i dont know why this is happening to me, impretty sure that MP4Box and YAMB can accept VobSub am i correct?