Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th October 2007, 17:05   #1481  |  Link
ChrisW77
Registered User
 
Join Date: Sep 2006
Posts: 72
Why is MeGUI's muxing, for MP4 x264 video, aac audio, sooo buggy ?

For instance, just tried this

Starting job job1 at 16:49:59
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
-add "H:\dvb-t\c4newsvideo.mp4" -add "H:\dvb-t\c4newsaudio.mp4:lang=eng" -tmp J:\dvb-t-muxed -new "J:\dvb-t-muxed\c4news.mp4"
successfully started encoding
Processing ended at 16:50:00
----------------------

Log for job job1

Error - 2 input names specified, please check usage

----------------------
End of log for job1



Starting job job1 at 16:50:43
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
-add "H:\dvb-t\c4newsvideo.mp4" -add "H:\dvb-t\c4newsaudio.mp4:lang=eng" -tmp G:\ -new "G:\c4news.mp4"
successfully started encoding
Processing ended at 16:51:02

Why did the first one keep failing with
"Error - 2 input names specified, please check usage"

What the heck kind of error is that ?
Yet, the second attempt, using the exact same files, yet this time I've written them to a smaller fat32 drive, worked fine. Why ?

And, why is it that, if I dot my filenames, it always fails ?
And, if I mux to the same drive/partition, it always fails, why ?

These bugs are really annoying, in what seems like a great program, aside from a slightly poorly designed gui.

Any other programs out there that can mux AAC and x264 into MP4 ? Is avidemux, any good ?
ChrisW77 is offline   Reply With Quote
Old 12th October 2007, 22:27   #1482  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Quote:
Originally Posted by Maccara View Post
Ok, now I see where this is coming from...

DAR.cs:
Code:
public static readonly Dar ITU16x9 = new Dar(1.823M);
public static readonly Dar ITU4x3 = new Dar(1.3672M);
public static readonly Dar A1x1 = new Dar(1M);
First of all, ITU4x3 is wrong - not PAL DVD (1.36752) or NTSC DVD (1.36738). (and really, I think there should be separate values for pal/ntsc anyway)
Agreed, but I'm only an end user

I also use Jukka Aho's info on aspect ratios, but have given up trying to convince others - I mentioned it to Kurtnoise a few times in respect of the presets in Yamb, but I obviously wasn't convincing.

/snip

But that's a separate issue to...

Quote:
So, as it currently works, user should enter the _real_ dar (if already cropped), and if he's cropping in avisynth script creator, he should then calculate it again himself.

So, I think there really is a bug.
...What seems to be a newish bug (I'm fairly sure this used to work, but icbw).

Even if you ignore any mistakes Megui makes in preset dars for dvd content, dar signalling in the avs currently doesn't seem to take into account cropping, which should be handled automatically.

As I see it, whenever the script is changed by the user or some internal function, if this could affect aspect ratio the signalling should be updated.

Quote:
This is the first time I've looked at megui sources, so I'm not sure if that would be an easy fix (and what way it should be fixed in the first place), and I'm really pressed for work so I'm not sure if I could post a patch in bugtracker for that one anytime soon... Maybe it even would be better to use PAR values internally altogether (as they're more consistent) and forget about DAR? No idea how much work that would be...
I don't know the code either, but when I first saw dar signalling I wondered why they were passing dar around; par seems to be more fundamental & isn't changed by cropping. To me sar & par seem to be the most easily manipulated base values with dar being the derived value.
mroz is offline   Reply With Quote
Old 12th October 2007, 22:41   #1483  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Quote:
Originally Posted by ChrisW77 View Post
Any other programs out there that can mux AAC and x264 into MP4 ? Is avidemux, any good ?
Yamb. It's yet another mp4box gui. Or you can always read up on the commandline syntax to mp4box & invoke it directly.
mroz is offline   Reply With Quote
Old 12th October 2007, 22:54   #1484  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
2.6.1024 with dg just updated to 1.50b6.

Not sure if this should be reported as a bug, as occassionally I find dgindex (all versions) gets the audio delay wrong & I can never be sure if this is down to a bug, a shortcoming or bad source data; also I've never found a transcoding app which doesn't sometimes make these kind of errors.

That said, with dgindex the problem is usually that it'll report 0 delay when in fact some non zero value is needed.

I've just done a transcode from an ntsc dvd & it reported a delay of -464ms. Watching the result I find a sync problem indicating there should have actually been 0 delay.

Posting here to see if this is common & therefore indicative of a bug.
mroz is offline   Reply With Quote
Old 13th October 2007, 04:50   #1485  |  Link
check
phjbdpcrjlj2sb3h
 
check's Avatar
 
Join Date: Sep 2005
Location: Western Australia
Posts: 1,691
For non-megui problems report to the relevant author(s), in this case neuron2.
check is offline   Reply With Quote
Old 13th October 2007, 08:17   #1486  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by mroz View Post
I mentioned it to Kurtnoise a few times in respect of the presets in Yamb, but I obviously wasn't convincing.
really ? where did you mentioned that ? Anyway, Yamb contains only PAR presets not DAR and I certainly wouldn't add this feature in the next releases because it should be included more in the encoding step rather than in the mux one.


About delay issue, I need to test myself with some materials first before to comment this.
Kurtnoise is offline   Reply With Quote
Old 13th October 2007, 08:22   #1487  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by ChrisW77 View Post
Why is MeGUI's muxing, for MP4 x264 video, aac audio, sooo buggy ?
Obviously, you didn't run the last development build...

Quote:
Originally Posted by ChrisW77 View Post
And, why is it that, if I dot my filenames, it always fails ?
why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...
Kurtnoise is offline   Reply With Quote
Old 13th October 2007, 14:11   #1488  |  Link
ChrisW77
Registered User
 
Join Date: Sep 2006
Posts: 72
Quote:
Obviously, you didn't run the last development build...
Well, obviously. Or so it would seem. ME's web update sees nothing, is there a development binary anywhere ?

Quote:
why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...
Looks neater, and every other program out there copes with dots, so why not mp4box ?

Channel 4 News October 12th 2007.mp4

Channel.4.News.October.12th.2007.mp4

Channel_4_News_October_12th_2007.mp4

To me, personally, the dotted name looks much neater. While the spaces (when there are many many files in a directory) looks lost, while the underscore one looks like it came from a torrent site. It's just a personal thing.
But even then, if I took out the dots, the first filename is still too long and gives me the error in my first post. Just silly.
ChrisW77 is offline   Reply With Quote
Old 13th October 2007, 14:34   #1489  |  Link
Maccara
Registered User
 
Join Date: Dec 2001
Posts: 145
Quote:
Originally Posted by mroz View Post
Agreed, but I'm only an end user

I also use Jukka Aho's info on aspect ratios, but have given up trying to convince others - I mentioned it to Kurtnoise a few times in respect of the presets in Yamb, but I obviously wasn't convincing.
I have to admit, I haven't tried yamb myself, but I think Kurtnoise addressed that situation.

My point in this only is, that if software claims "ITU" is used, then values pertaining to ITU standards should really be used.

It is of course a completely different issue, if the source material actually followed ITU (i.e. in DVD case, correct active picture frame of 702x in case of PAL 720x576), but that is a moot point as long as user can freely choose differently, if he knows better (for example, if source material did infact use "Generic PAR").

Quote:
But that's a separate issue to...
Definitely agree - and not even really relevant (I just wanted to point out, that they were not ITU values - in fact, I couldn't immediately figure out from where those values had been gotten from and that's why I think there may simply be rounding error/spelling mistake there).

Quote:
Even if you ignore any mistakes Megui makes in preset dars for dvd content, dar signalling in the avs currently doesn't seem to take into account cropping, which should be handled automatically.

As I see it, whenever the script is changed by the user or some internal function, if this could affect aspect ratio the signalling should be updated.
THIS is the real bug here, and should be fixed before stable version is published.

Quote:
I don't know the code either, but when I first saw dar signalling I wondered why they were passing dar around; par seems to be more fundamental & isn't changed by cropping. To me sar & par seem to be the most easily manipulated base values with dar being the derived value.
With this, I have to agree. Although, I have to admit I haven't thought of this too deeply yet (if there actually is a difference in ease of handling, if done properly in either case).

However, I think this would be a "fundamental change" in a sense that maybe this shouldn't be implemented until stable status is achieved on current codebase. Instead just fix the current signalling bug (so it gets updated on cropping) and just assume the source is un-cropped dvd (as it does now).

If I have the time to look into this a bit more, I'll start a discussion on this in the development thread pondering on the pros & cons and if it actually should be implemented like this.

And I guess, I shouldn't except others to implement something like this just because I would think it would be better, and have to offer to actually do something about it myself in that case. (well, it would be nice to give something back too, instead of just always benefiting from others' work for free )
Maccara is offline   Reply With Quote
Old 13th October 2007, 14:57   #1490  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Quote:
Originally Posted by check View Post
For non-megui problems report to the relevant author(s), in this case neuron2.
Sorry, should do. Any idea where best to send such reports?

Mentioned it here as I thought I recalled someone asking if the newer dg was reliable enough to be included in Megui.
mroz is offline   Reply With Quote
Old 13th October 2007, 15:10   #1491  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Quote:
Originally Posted by Kurtnoise13 View Post
really ? where did you mentioned that ?
Sorry, can't find it. I thought it was on these forums a year or so ago. It involved a brief exchange on a forum, I'm pretty sure; actually, it could have been by mail, just before I joined this forum.

Quote:
Anyway, Yamb contains only PAR presets not DAR and I certainly wouldn't add this feature in the next releases because it should be included more in the encoding step rather than in the mux one.
Sorry again, I wasn't clear enough. I was merely referring to your choice of par presets for pal & ntsc 4:3 & 16:9. Yours differ (last time I checked) slightly from those given by Jukka Aho.

Last edited by mroz; 13th October 2007 at 15:47.
mroz is offline   Reply With Quote
Old 13th October 2007, 15:13   #1492  |  Link
berrinam
Registered User
 
berrinam's Avatar
 
Join Date: Apr 2005
Posts: 1,740
Quote:
Originally Posted by Maccara View Post
Ok, now I see where this is coming from...

DAR.cs:
Code:
public static readonly Dar ITU16x9 = new Dar(1.823M);
public static readonly Dar ITU4x3 = new Dar(1.3672M);
public static readonly Dar A1x1 = new Dar(1M);
First of all, ITU4x3 is wrong - not PAL DVD (1.36752) or NTSC DVD (1.36738). (and really, I think there should be separate values for pal/ntsc anyway)
I have done most of the AR stuff with very little documentation about the standards, and I don't remember where I got the above quoted numbers from. It looks like the ITU4x3 value should be 1.36752 but, by typo, the '5' got dropped. However, as this is indeed wrong, I've added a bug report: http://sourceforge.net/tracker/index...12&atid=798476

Quote:
Second, those are close only when DVD is the source, but I guess that's an ok assumption, as long as real DAR is chosen by the user.
For DVD sources, the ITU16x9 and ITU4x3 aspect ratios will be chosen. For other sources, square pixels are assumed, as the AVS creator isn't currently configured to read in AR signalling from other input files. This is definitely a limitation, and should be addressed in the future: http://sourceforge.net/tracker/index...12&atid=798479

Quote:
Then in ToSar method:
Code:
decimal ratio = ar * (decimal)vres / (decimal)hres;
return new Sar(ratio);
I'm not sure why you've quoted this; it seems correct to me.

Quote:
Maybe it even would be better to use PAR values internally altogether (as they're more consistent) and forget about DAR? No idea how much work that would be...
I'm not sure of terminology. By PAR you mean pixel aspect ratio? I assume so, but in MeGUI we call that SAR (Sample aspect ratio) so as to avoid confusion with Picture aspect ratio (which we call DAR, Display aspect ratio, in MeGUI).

Anyway, I see no reason why SAR is more consistent than DAR. Of course, when you know your film's resolution, they are essentially equivalent since you can convert between them. But SAR and DAR are complementary for the simple reason that when you resize, the DAR stays the same but the SAR might not, and when you crop, the SAR stays the same but the DAR might not. In this case, I do not see one as more consistent than the other, and it is not possible to forget about DAR because you need it for resizing.

However, I argue that DAR is a more intuitive and more fundamental concept than SAR. Consider that DAR refers to the shape of the video whereas SAR refers to the shape of the individual pixels. If someone with very little knowledge of video sees a film with the wrong aspect ratio, they will think, "the shape of this video is wrong" and not "the shape of the pixels is wrong" for the simple reason that they may not have heard of pixels.

Because of a number of reasons like this in MeGUI, DAR is exposed and not SAR. However, it makes little difference to almost all the code since most of the code just involves passing the information along and not actually processing it. And where it does matter, they SAR and DAR have pretty much equal standing: cropping needs SAR, resizing needs DAR, x264 uses SAR, xvid_encraw uses DAR.

Anyway, thanks for the useful post about MeGUI's AR problems.
berrinam is offline   Reply With Quote
Old 13th October 2007, 15:14   #1493  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Quote:
Originally Posted by ChrisW77 View Post
ME's web update sees nothing, is there a development binary anywhere ?
Options > Settings > Extra config > Auto update > configure Servers > choose development from the drop down menu
mroz is offline   Reply With Quote
Old 13th October 2007, 15:15   #1494  |  Link
berrinam
Registered User
 
berrinam's Avatar
 
Join Date: Apr 2005
Posts: 1,740
Quote:
Originally Posted by Maccara View Post
THIS is the real bug here, and should be fixed before stable version is published.
Already fixed, in rev255.
berrinam is offline   Reply With Quote
Old 13th October 2007, 15:39   #1495  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Berrinam: I think we've taken SAR to be the apsect ratio of the display using pixel counts & PAR to be the physical aspect ratio of a single pixel (thus DAR = PAR*SAR).

Searching the web suggests the definitions of DAR & PAR are well established, but that for SAR isn't - sometimes it means PAR, as you use, & sometimes DAR/PAR.

What term do you use for DAR/PAR?

Regarding which of DAR & PAR is the more fundamental, you're of course right that there's a symmetry between them & that modifying the video by cropping/scaling will each affect one of those quantities.

It's also not terribly important which you treat as the derived quantity as long as the arithmetic is precise, however I'd still be inclined to go with DAR as the derived value as ime (quite limited), one tends to work with a small set of possible PARS all of which can be represented precisely as the ratio of two four digit integers. I think in practice if you wish to store DAR precisely you'd need more. Not important, just a personal choice.
mroz is offline   Reply With Quote
Old 13th October 2007, 15:45   #1496  |  Link
mroz
Registered User
 
mroz's Avatar
 
Join Date: Sep 2006
Posts: 201
Quote:
Originally Posted by Kurtnoise13 View Post
Obviously, you didn't run the last development build...


why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...
Ah, thanks, that explains a few errors I had recently. I ended up muxing from the command line which worked, but no doubt only as I probably renamed the files in
between.

I tend to process files using the names the sources have, until I come to archive the results, so sometimes encounter naming schemes I'd not personally choose.

Out of interest, why does mp4box care? What does it do with the names? OTTOMH I can't see a requirement that would necessarily mean it couldn't cleanly handle odd filenames. This smells like a shortcoming verging on a bug.
mroz is offline   Reply With Quote
Old 13th October 2007, 18:16   #1497  |  Link
ChrisW77
Registered User
 
Join Date: Sep 2006
Posts: 72
Quote:
Options > Settings > Extra config > Auto update > configure Servers > choose development from the drop down menu
Thanks, mroz
ChrisW77 is offline   Reply With Quote
Old 13th October 2007, 19:34   #1498  |  Link
Maccara
Registered User
 
Join Date: Dec 2001
Posts: 145
Thanks, berrinam, for addressing this.

Quote:
Originally Posted by berrinam View Post
For DVD sources, the ITU16x9 and ITU4x3 aspect ratios will be chosen. For other sources, square pixels are assumed, as the AVS creator isn't currently configured to read in AR signalling from other input files. This is definitely a limitation, and should be addressed in the future: http://sourceforge.net/tracker/index...12&atid=798479
This is fair enough - DVD usually is a good assumption.

Quote:
I'm not sure why you've quoted this; it seems correct to me.
Sorry, I probably didn't address this well. The code is correct, but the issue is when we use that, we do not have _real_ ar (f.e. after cropping), which is fundamental for that formula to give correct results.

Sorry, I'm assuming here a little because I do not see DAR changing after cropping (as it should), but I haven't checked this properly from the code yet.

(Edit: This seems fixed in SVN already, sorry, didn't notice your other message until now)

Quote:
I'm not sure of terminology. By PAR you mean pixel aspect ratio? I assume so, but in MeGUI we call that SAR (Sample aspect ratio) so as to avoid confusion with Picture aspect ratio (which we call DAR, Display aspect ratio, in MeGUI).
Yes, by PAR I mean pixel aspect ratio and by DAR display aspect ratio. With this definition I have understood SAR is equivalent to PAR, no? (hopefully _I_ haven't made a fundamental error here )

Quote:
Anyway, I see no reason why SAR is more consistent than DAR. Of course, when you know your film's resolution, they are essentially equivalent since you can convert between them. But SAR and DAR are complementary for the simple reason that when you resize, the DAR stays the same but the SAR might not, and when you crop, the SAR stays the same but the DAR might not. In this case, I do not see one as more consistent than the other, and it is not possible to forget about DAR because you need it for resizing.
It all depends, what information we have available internally. Admittedly, I haven't looked at the code enough yet to have a clear opinion if indeed using par/sar would be simpler than dar. Of course assuming any of these are used correctly in the first place.

Quote:
However, I argue that DAR is a more intuitive and more fundamental concept than SAR. Consider that DAR refers to the shape of the video whereas SAR refers to the shape of the individual pixels. If someone with very little knowledge of video sees a film with the wrong aspect ratio, they will think, "the shape of this video is wrong" and not "the shape of the pixels is wrong" for the simple reason that they may not have heard of pixels.
I think here our points of view will differ a little. Definitely, for the user, DAR is more intuitive, unless they've spent enough time pondering about the whole matter.

To me, PAR is "everything" - it will define everything else. Once I know what the PAR of the source is, I can derive every other value simply from that fact. This, I have to admit, undoubtedly will somewhat cloud my view in this.

However, I might have been thinking a bit ahead of myself here (with current limitations intact). For example, if I feed an already cropped (not resized) AVI to megui, DAR is defined by the resolution & PAR. This, of course, is not very relevant, if we always assume we get full-resolution sources only and can rely on DAR - or if we can get correct DAR/PAR automatically from the source we can derive correct values anyway.

(I may need to revise above paragraph, as it maybe didn't come out very clear - English is not my native language.)

Quote:
Because of a number of reasons like this in MeGUI, DAR is exposed and not SAR. However, it makes little difference to almost all the code since most of the code just involves passing the information along and not actually processing it. And where it does matter, they SAR and DAR have pretty much equal standing: cropping needs SAR, resizing needs DAR, x264 uses SAR, xvid_encraw uses DAR.
Until I have time to look more deeply in the code, I have no choice but to agree here. At least I think the reasoning behind this is ok - just have to figure out if it is also implemented correctly (or if some bugs still remain).

Quote:
Anyway, thanks for the useful post about MeGUI's AR problems.
Thank you very much for clarifying the thinking behind this. At least makes me at more ease, knowing there shouldn't be any fundamental flaw with the whole processing and should work out fine for the purpose once the final bugs are squashed.

Last edited by Maccara; 13th October 2007 at 19:40. Reason: Some clarifications & spelling
Maccara is offline   Reply With Quote
Old 13th October 2007, 19:37   #1499  |  Link
Maccara
Registered User
 
Join Date: Dec 2001
Posts: 145
Quote:
Originally Posted by berrinam View Post
Already fixed, in rev255.
Sorry, didn't notice this. Indeed, in SVN it seems fixed. Have to test it at some point.
Maccara is offline   Reply With Quote
Old 13th October 2007, 22:03   #1500  |  Link
trooper11
Registered User
 
Join Date: Jan 2004
Posts: 106
First of all, thanks for putting together this great program, Im going to be using it quite a bit, so its a huge help.


My system is running Vista Ultimate and I have the following versions of apps:

MeGui 0.2.5.1007 (latest stable version I could find)
AviSynth 2.5.7

Now, the problem Im having is when I go to the AviSynth Script Creator. Whenever I try to add a video source (Ive tried .mkv and .avi files) MeGui crashes (there is no particular error message, just that it stops responding and Vista has to shut it down)


Is there anything else I need to install in order for this to work, or is this a bug with Vista? I even tried installing the in development MeGui version 0.2.6.1024 but I get the same crash.

Any help would be appreciated.
trooper11 is offline   Reply With Quote
Reply

Tags
megui

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.