MeGUI - x264/XviD/lavc/Snow encoder with MP4/MKV/AVI output & audio

[turbojet]

Originally Posted by Doom9

Since I wrote the checker, this argument sparked my interest.
You asked
and I'd say it's better to error on the side of caution, is it not? Encoding a 1080p file can take some time after all. The x264 devs tend to give GUI developers pointers when something changes.. so I wonder if megui is doing something wrong they haven't brought it up - perhaps the approach of rather being safe than sorry also help them from bogus error reports.

Safe side sure but I would side with accuracy on a proven formula then to go below it which avc level checker does. The only safe thing I could understand is lowering ref by 1 if b-pyramid but some others and I have proven that b-pyramid does not affect the DPB anymore but simply playing max refs+b-pyramid in BD players. There is nothing obvious in x264 changelog to represent this however. The MeGUI wiki agrees with me on ref and b-pyramid.

Not directly.. it really depends on the resolution and framerate of the source - and that's why I wrote the checker as a tool accessible in the main form (where you load sources), and not within a codec configuration (a user may not have loaded the source or may change it.. thus making the whole idea of saving presets unworkable). And, I still don't see a way to make this any better.. you can only really enforce levels properly if you completely change the workflow - megui wasn't built around enforcing a certain workflow.. it started out with what's still there and then got the auto encoder and finally the one click encoder - properly enforcing levels only works if you go about it in a whole different way (the one click workflow).. so if you want a mandatory or optional checker, that's where you'd need to put it.. and definitely not in the codec configuration.

Clicking around in the latest version a bit I noted that selecting a level no longer enforces the constraints that can be enforced.. I guess you can have a different opinion on that, but my approach with enforcing meant you lose flexibility so it appears the current developers opted for flexibility in that case - and it's really an either or decision.. you cannot have both. Given megui's history I understand why the choice went into the current direction - non experienced users can use the premade presets and the tools to facilitate encoding whereas all options are open to the advanced users who know what they're doing. I suppose you could have a setting "I know what I'm doing" and only allow people to change codec configurations, write scripts and the likes when that's checked, but it's a lot of work trying to force people who don't know better to not hurt themselves.

All but these 2 things I brought up are already enforced by profile@level. Check different profiles, exceed max vbv of the level. I see no reason not to extend it to enforce all profile@level now that the formula for figuring it out is well known after months and months of research and testing.

The real problem with telling people to research themselves is the information available is very contradictory.

[Sharktooth]

you still dont understand x264 breaks the DPB...
so, as a matter of fact, it reports correct info about levels but the resulting stream may be unplayable on some hardware devices.
megui corrects that behaviour lowering some limits to ensure x264 will NOT break the DPB.
so whatever you can say, that wont change since it works. also you didnt prove anything about b-pyramind and DPB. As i said there is no changelog entry in x264 development that points that issue was fixed. hence it is still broken. period.

also you still dont want to UNDERSTAND (and that's your problem, not ours) that the megui workflow doesnt permit to do what you want... and remember megui is a gui for advanced users, not for newbies, so it's pretty normal the megui users should know what they're doing.

[Doom9]

You seem to mistake the AVC level checker for a generic AVC level checker - which it is not. Given that x264 isn't really respecting AVC levels, megui's checker is a best effort attempt by both x264 and megui developers to help people create streams which are compliant - but there are no guarantees that they really will be compliant since x264 isn't level aware and the developers have repeatedly and over years refused to change that.

The formulas used by megui come directly from the megui developers - and they are outlined here. Regardless of how many players you'll find that have no trouble playing streams that have as much reference frames as the actual specs allow - that's no indication that those streams are really compliant. It's not just encoders that may not respect specs, decoders can have the same issues as there's certainly one decoder out there that does require full compliance and it will fail utterly and then the user will blame the megui developers for the failure. Specs are nice and all but anybody who has ever implemented a specification written by a third party is well aware that specs are one thing and the real world is quite another - and you need to develop for the real world. It doesn't help you if you can insist on the fact that you are doing everything right when your software doesn't work the way people expect it - if you rely on some other component that sees things differently and they won't adapt it or only some undetermined time in the future, you simply have no choice but to relax constraints on your own end where you're in control.

But if it really bothers you so, download the megui source code, open up AVCLevels.cs, comment out lines 128 - 133 and recompile (there's a batch file for you to do that in the root of the source.. it used to work with just the .net runtime 2.0 installed so you don't even need to install an SDK or IDE to do that) and voila.. the level checker now calculates ref frames according to spec, and not according to what the x264 devs think you should to be on the safe side when using levels.

And as for my second point, it took me but one reply to understand sharktooth's frustration with you.. I gave you a perfectly valid explanation why your idea doesn't work.. and you completely ignore it. My take of that behavior is that you think you know better anyway - but in that case what you should do is write your own GUI.. or create a fork of megui which implements just the workflows where your ideas to work. We can talk again about whether it makes sense to do levels according to specs when you've been on the receiving end of "bug reports" yourself for a couple of months

[Dark Shikari]

Originally Posted by Doom9

You seem to mistake the AVC level checker for a generic AVC level checker - which it is not. Given that x264 isn't really respecting AVC levels, megui's checker is a best effort attempt by both x264 and megui developers to help people create streams which are compliant - but there are no guarantees that they really will be compliant since x264 isn't level aware and the developers have repeatedly and over years refused to change that.

Have you been under a rock for the past three years or something?

[Doom9]

Actually, yes, I have in a manner of speaking ... you might have noted the lack of commits during that time

Would you be so kind then to give an updated to the situation over akupenguin's post I linked to in my post just before this one... sort of a "rock shock"?

[Kurtnoise]

from set.c ...

int x264_validate_levels( x264_t *h, int verbose )
{
    int ret = 0;
    int mbs = h->sps->i_mb_width * h->sps->i_mb_height;
    int dpb = mbs * 384 * h->sps->i_num_ref_frames;
    int cbp_factor = h->sps->i_profile_idc==PROFILE_HIGH ? 5 : 4;

    const x264_level_t *l = x264_levels;
    while( l->level_idc != 0 && l->level_idc != h->param.i_level_idc )
        l++;

    if( l->frame_size < mbs
        || l->frame_size*8 < h->sps->i_mb_width * h->sps->i_mb_width
        || l->frame_size*8 < h->sps->i_mb_height * h->sps->i_mb_height )
        ERROR( "frame MB size (%dx%d) > level limit (%d)\n",
               h->sps->i_mb_width, h->sps->i_mb_height, l->frame_size );
    if( dpb > l->dpb )
        ERROR( "DPB size (%d frames, %d bytes) > level limit (%d frames, %d bytes)\n",
                h->sps->i_num_ref_frames, dpb, (int)(l->dpb / (384*mbs)), l->dpb );

#define CHECK( name, limit, val ) \
    if( (val) > (limit) ) \
        ERROR( name " (%d) > level limit (%d)\n", (int)(val), (limit) );

    CHECK( "VBV bitrate", (l->bitrate * cbp_factor) / 4, h->param.rc.i_vbv_max_bitrate );
    CHECK( "VBV buffer", (l->cpb * cbp_factor) / 4, h->param.rc.i_vbv_buffer_size );
    CHECK( "MV range", l->mv_range, h->param.analyse.i_mv_range );
    CHECK( "interlaced", !l->frame_only, h->param.b_interlaced );

    if( h->param.i_fps_den > 0 )
        CHECK( "MB rate", l->mbps, (int64_t)mbs * h->param.i_fps_num / h->param.i_fps_den );

    /* TODO check the rest of the limits */
    return ret;
}

[Disturbance]

G'day, lately I've been having a problem with megui, when ever i use multiple workers at once, ie 2 workers, they get to about 0.8% and then megui just closes, no error dialogue it just closes down, in my scripts i have all my plugins loaded in script, i use the latest avisynth 2.5.8, and once it actually came up with an error and im my events viewer it spits this out at me

Faulting application megui.exe, version 0.3.1.1035, faulting module msvcr80.dll, version 8.0.50727.1433, fault address 0x000173d0.

anyone have any idea what could be the problem

[Dark Shikari]

Originally Posted by Doom9

Actually, yes, I have in a manner of speaking ... you might have noted the lack of commits during that time

Would you be so kind then to give an updated to the situation over akupenguin's post I linked to in my post just before this one... sort of a "rock shock"?

x264 will yell loudly about all violations of significant level limits.

[turbojet]

AVC level checker's formula is inaccurate for the way x264 works today. Come to think of it, it really did take years to figure out the correct formula. Those years of work don't even really play a role in today's encoding because only one thing has any mention of it, x264, all it does is warn you and expects the user to figure out the error.

MeGUI enforces some parts of levels but ignores some others, I consider this incomplete and suggest to complete it for the better of the program. Others think it's intentional and not all parts of the level should have to be followed and the common excuse seems to be you need to be an advanced user or use profiles. The way I see it for the majority of people who aren't 'advanced', ensuring levels gives the user a lot more freedom while still ensuring playback while one change in a profile can break playback.

x264 gives an accurate yell but if megui can't hear it does it make a sound?

[Kurtnoise]

what I told you ?...now, pass the 2nd. Period.

[magic144]

hey guys,
just came across an issue with MeGUI last week

when using the AutoEncode feature, I ended up with an .mkv that was larger (by 2MB) than the chosen target size (8152 MB, DVD-9)

am I right in assuming that MeGUI IS NOT taking into account the size of the subtitle stream when calculating bitrate?

this is the first time this has ever happened, but I tried playing around with the standalone bitrate calculator tool and it seems to confirm my assumption

I have more recently been using BDSup2Sub to make VobSub idx/sub pairs which are obviously significantly larger than .srt text files, so whereas before the .srt files would have had little or no impact on target size, this is not necessarily true with VobSub

anyway, in a nutshell, if my assumption is correct (?), will MeGUI incorporate a bitrate adjustment to take into account the size of the subtitles in its AutoEncode calculations?

thanks for such a brilliant tool!

m

[Sharktooth]

Originally Posted by turbojet

AVC level checker's formula is inaccurate for the way x264 works today. Come to think of it, it really did take years to figure out the correct formula. Those years of work don't even really play a role in today's encoding because only one thing has any mention of it, x264, all it does is warn you and expects the user to figure out the error.

MeGUI enforces some parts of levels but ignores some others, I consider this incomplete and suggest to complete it for the better of the program. Others think it's intentional and not all parts of the level should have to be followed and the common excuse seems to be you need to be an advanced user or use profiles. The way I see it for the majority of people who aren't 'advanced', ensuring levels gives the user a lot more freedom while still ensuring playback while one change in a profile can break playback.

x264 gives an accurate yell but if megui can't hear it does it make a sound?

you still dont want to UNDERSTAND... read again what i wrote... x264 will break the DPB in some situations. the megui level checker ensures that wont happen.
now, if you still dont want to understand, i will ignore further posts from you.

Originally Posted by magic144

hey guys,
just came across an issue with MeGUI last week

when using the AutoEncode feature, I ended up with an .mkv that was larger (by 2MB) than the chosen target size (8152 MB, DVD-9)

am I right in assuming that MeGUI IS NOT taking into account the size of the subtitle stream when calculating bitrate?

this is the first time this has ever happened, but I tried playing around with the standalone bitrate calculator tool and it seems to confirm my assumption

I have more recently been using BDSup2Sub to make VobSub idx/sub pairs which are obviously significantly larger than .srt text files, so whereas before the .srt files would have had little or no impact on target size, this is not necessarily true with VobSub

anyway, in a nutshell, if my assumption is correct (?), will MeGUI incorporate a bitrate adjustment to take into account the size of the subtitles in its AutoEncode calculations?

post a feature request in the megui feature requests tracker on sourceforge.

Originally Posted by Disturbance

G'day, lately I've been having a problem with megui, when ever i use multiple workers at once, ie 2 workers, they get to about 0.8% and then megui just closes, no error dialogue it just closes down, in my scripts i have all my plugins loaded in script, i use the latest avisynth 2.5.8, and once it actually came up with an error and im my events viewer it spits this out at me

Faulting application megui.exe, version 0.3.1.1035, faulting module msvcr80.dll, version 8.0.50727.1433, fault address 0x000173d0.

anyone have any idea what could be the problem

be more specific. what jobs you assigned to the workers?

[turbojet]

Originally Posted by Sharktooth

you still dont want to UNDERSTAND... read again what i wrote... x264 will break the DPB in some situations. the megui level checker ensures that wont happen.
now, if you still dont want to understand, i will ignore further posts from you.

You never said x264 will break DPB until now but you said may which I took as you weren't sure. But since you now know it will please give x264 settings and device(s) that are affected by this broken DPB with the current build so the community can test it and possibly fix it.

Also please don't go linking to posts back in November, we've already been through that and x264 b-pyramid behavior has changed since. I don't know why it's undocumented or if it's mentioned in some other way in the changelog but the real test is checking on hardware which some people have already done, myself included. I was tipped off by this post and rather than say it's not in changelog so I don't believe it I went and tested and he was correct as is the megui wiki.

[Disturbance]

be more specific. what jobs you assigned to the workers?

when i encode something i use a automated 2 pass, but i also add an analysis pass as well, and i assign the sets of 3 to a worker, so say for example i have 2 videos i want to encode, i load the avs, Queue analysis pass, and then the enqueue button, go to the "queue" tab and set the 3 created jobs to a single worker, then i repeat the process for the other video, set those 3 created jobs to another worker, then i hit "start" and then the 2 workers start the analysis pass gets to %0.7 then megui with no error window or anything just completely closes,

i am at a loss as to why it does this

[AkumaX]

I have a couple questions from the last couple builds from the Core;

Is there a specific reason why Device target was added? Does specifying a device do anything special rather than keeping it normal? (please elaborate whether it makes a difference for iPod Touch/iPhone/PSP encoding)

I recently tried an encode for my iPod Touch. I selected the Device-Iphone profile, with a resolution of 640x360. However, after the encode (whether selecting normal or iphone for the device target), it plays back at an AR of 20:13 - it's playing back @ 640x416 on my iPod, VLC, QuickTime, and MPC-HD (w/ K-Lite). Any reasons why?

Thanks!

edit: forget question#2, I just restarted MeGUI and it encoded fine now. Weird...

[Sharktooth]

Originally Posted by turbojet

You never said x264 will break DPB until now but you said may which I took as you weren't sure. But since you now know it will please give x264 settings and device(s) that are affected by this broken DPB with the current build so the community can test it and possibly fix it.

Coz it MAY break the DPB. that means it will not sistematically do that but WILL do in some occasions.
Breaking the DPB means it will produce a non compliant stream and i dont give a sh!t what devices wont play that coz what i care is it will be non compliant to the standard.

Also please don't go linking to posts back in November, we've already been through that and x264 b-pyramid behavior has changed since. I don't know why it's undocumented or if it's mentioned in some other way in the changelog but the real test is checking on hardware which some people have already done, myself included. I was tipped off by this post and rather than say it's not in changelog so I don't believe it I went and tested and he was correct as is the megui wiki.

ppl may say whatever they want... so if they lie you will believe lies? no entry in the changelog means it hasnt been fixed.
sagekilla maybe refers to the fact the situation has been improved (coz before november x264 was wildly braking the DPB) but it's still buggy.
also note how Dark_Shikari, a x264 dev, posted here during our discussion BUT didnt say i was wrong.
why dont you ask him instead of pissing me off?
also you may continue to speak forever but things wont change until x264 will be fixed. what you will get, instead, is a very high probability to get insulted to death for being such a retarded.

[Sharktooth]

Originally Posted by Disturbance

when i encode something i use a automated 2 pass, but i also add an analysis pass as well, and i assign the sets of 3 to a worker, so say for example i have 2 videos i want to encode, i load the avs, Queue analysis pass, and then the enqueue button, go to the "queue" tab and set the 3 created jobs to a single worker, then i repeat the process for the other video, set those 3 created jobs to another worker, then i hit "start" and then the 2 workers start the analysis pass gets to %0.7 then megui with no error window or anything just completely closes,

i am at a loss as to why it does this

do you know what the analysis pass does?
your problem is probably due to avisynth going out of memory.

[Sharktooth]

Originally Posted by AkumaX

I have a couple questions from the last couple builds from the Core;

Is there a specific reason why Device target was added? Does specifying a device do anything special rather than keeping it normal? (please elaborate whether it makes a difference for iPod Touch/iPhone/PSP encoding)

I recently tried an encode for my iPod Touch. I selected the Device-Iphone profile, with a resolution of 640x360. However, after the encode (whether selecting normal or iphone for the device target), it plays back at an AR of 20:13 - it's playing back @ 640x416 on my iPod, VLC, QuickTime, and MPC-HD (w/ K-Lite). Any reasons why?

Thanks!

edit: forget question#2, I just restarted MeGUI and it encoded fine now. Weird...

some devices require some special muxing.
apple stuff has common settings, while PSP is different.
both apple (ipods/iphones... etc) and PSP wont accept normally muxed files.

[magic144]

Originally Posted by Sharktooth

post a feature request in the megui feature requests tracker on sourceforge.

ok done, thanks!

[AkumaX]

Originally Posted by Sharktooth

some devices require some special muxing.
apple stuff has common settings, while PSP is different.
both apple (ipods/iphones... etc) and PSP wont accept normally muxed files.

really? that's strange... because then i don't understand how i'm able to encode for ipod touch/psp if these muxing profiles for specific devices weren't set before. it's always worked *shrug*