MeGUI - x264/XviD/lavc/Snow encoder with MP4/MKV/AVI output & audio [Archive] - Page 43

turbojet

14th May 2009, 22:42

VBV should NEVER be set until the user chooses to set it. megui will warn you if you set the buffers too high.
the inaccuracy is there to "protect" from b-pyramid problems.

Why should vbv never be set until the user chooses?

If you take a 90 minute high action movie, set it to L4.1 and encode for BD25 output without any vbv you are likely to exceed the maximum bitrate and it will skip at times. Same can be said for DVD9 target but to a lesser extent.

What b-pyramid issue are you talking about?

1920x1080 24fps up to --ref 4 with and without b-pyramid is allowed in L4.x
According to AVC Level Checker 1920x1080 24fps L4 max is --ref 3 without b-pyramid or --ref 2 with b-pyramid.

1280x720 24fps up to --ref 9 with and without b-pyramid is allowed in L4.x
According to AVC Level Checker 1280x720 24fps L4 max is --ref 8 without b-pyramid or --ref 7 with b-pyramid.

Sharktooth

14th May 2009, 22:55

coz you dont want restrictions on ratecontrol if you dont need them. they would harm final quality.
b-pyramid problems are playback problems on hardware devices (DPB violations). if you add b-pyramid you should lower the refs by 1 to ensure compatibility. AFAIK that's a x264 problem.
btw, regarding the level checking in the config, it's not manageable since megui doesnt know about input file properties during the encoder configuration.

turbojet

15th May 2009, 00:22

coz you dont want restrictions on ratecontrol if you dont need them. they would harm final quality.

Very debatable on if it may hurt quality if it's within reason L4.0 would allow 50 mbps for less than a second, 25 mbps for more than a second, L4.1 would allow 135 mbps for less than a second, 62.5 mbps for more than a second.

If someone is setting level aren't they using it for a specific device that requires these types of level restrictions?
What I suggest wouldn't affect anything if you aren't setting level or vbv is already compliant.

b-pyramid problems are playback problems on hardware devices (DPB violations). if you add b-pyramid you should lower the refs by 1 to ensure compatibility. AFAIK that's a x264 problem.

This used to be the case but it was changed months ago so b-pyramid doesn't affect DPB.

btw, regarding the level checking in the config, it's not manageable since megui doesnt know about input file properties during the encoder configuration.

It could just as easily get this info on input like avc level checker does currently. What I'm suggesting is putting avc level checker functionality in the x264 config and getting rid of the level checker function.

Sharktooth

15th May 2009, 01:04

it's not debatable. setting VBV params forces the ratecontrol to behave in a different way and setting a level means setting a flag in a bitstream. if you want to specify VBV limits you can always do it.
about b-pyramid and DPB stuff, it was changed but it's still not perfect and still causes problems. as you can read on the megui presets thread:... Removed b-pyramid from all DXVA group presets... this time it is FOREVER until x264 gets properly patched.
x264 is still broken (http://forum.doom9.org/showthread.php?p=1180816#post1180816) in that way.
so, dont argue with me about b-pyramid... i will never consider it a reliable option... it's not even so usefull... i prefer one more b-frame or even one more ref instead...
It could just as easily get this info on input like avc level checker does currently. What I'm suggesting is putting avc level checker functionality in the x264 config and getting rid of the level checker function.nope, since you can set up the presets without loading an input file. avc level checker is what the name says, a "checker". it doesnt "set" anything except enforcing limits if and only if certain options are set out of specified level limits.

turbojet

15th May 2009, 01:46

it's not debatable. setting VBV params forces the ratecontrol to behave in a different way and setting a level means setting a flag in a bitstream. if you want to specify VBV limits you can always do it.

Ya it is a little different output. But again why would someone set a level if they wanted the level to be broken?

about b-pyramid and DPB stuff, it was changed but it's still not perfect and still causes problems. as you can read on the megui presets thread:
x264 is still broken (http://forum.doom9.org/showthread.php?p=1180816#post1180816) in that way.
so, dont argue with me about b-pyramid... i will never consider it a reliable option... it's not even so usefull... i prefer one more b-frame or even one more ref instead...

All I can say is BD players that used to fail max reference frames + b-pyramid now play them just fine. Presets or usefulness have nothing to do with this discussion.

nope, since you can set up the presets without loading an input file. avc level checker is what the name says, a "checker". it doesnt "set" anything except enforcing limits if and only if certain options are set out of specified level limits.

Then it warns the output will be non-compliant to the level set and tells the user to change level or whatever setting breaks it.

Sharktooth

15th May 2009, 01:58

Ya it is a little different output. But again why would someone set a level if they wanted the level to be broken?
Coz some devices/softwares check for the level flag but are capable of decoding higher bitrates than those specified in the level (some cellphones for example...).
All I can say is BD players that used to fail max reference frames + b-pyramid now play them just fine. Presets or usefulness have nothing to do with this discussion.
The reason i pointed you to that thread was to prove x264 has not been fixed and your statement:
This used to be the case but it was changed months ago so b-pyramid doesn't affect DPB.
was wrong
Then it warns the output will be non-compliant to the level set and tells the user to change level or whatever setting breaks it.
yes. also, VBV parameters are checked against the level during the preset configuration.

userix

15th May 2009, 07:12

Thanks for your replies. :)

I apologize for not being specific in my initial post. The file I am encoding is from one of my anime DVDs. It's not that the whole encode is crappier, only the beginning of the episode, which starts with a static scene, and then cuts to another static scene. On the Q6600 encodes, those 2 static scenes seem blockier (noisier) when compared to the old Dell encode. The rest of the encode, including future static scenes, seem fine afterwards. What gets me is why are the aforementioned static scenes encoded on my Q6600 blockier than those of my old Dell encode?

I have attached screenshots taken using MPC of the two static scenes I am talking about. The noise in the first scene is subtle, but you can clearly see the difference between the 2nd static scene. Of course, when watching it in full screen, the differences stand out much more.

In addition, when I encode the video using 2-pass xvid encoder with same bitrate on the Q6600, the 2 static scenes are the same quality as the Dell encode. It seems only when I use x264 encoder on my Q6600, I get crappier results. Boggles the mind.

Are you sure you're using the same x264 profiles? One small change like --partitions none and --partitions all can make a huge difference in quality and encoding time.

I'm pretty sure. I downloaded the same stable version to both computers, then proceeded to update it to the newest files available at the same time. Therefore, the profiles I downloaded through the update module are the same. I double check the command line arguments being fed and they are identical on both machines.

So you use the same decoder for the encoding
and the same decoder for playback on both machines?
Which decoder for playback; deblocking en/disabled?
Same bitrate, same filesizes of your encoded files?
To much variables to guess without log files and avisynth scripts....:D

I haven't looked at the logs specifically, but I figure if I create the d2v and avs script files in the same exact manner on both machines, I should get the same results, right? Bitrates are set the same for both comps. The size of the video encodes aren't exactly the same, but it's only off by 200k-300k. I have CCCP codec pack installed on both comps and use MPC to playback the files. I am not sure what you mean by using the decoder for encoding. MEGUI uses the x264.exe file it gets from the update, which is located in the MEGUI tools folder.

In addition, I'd say compare both encodes on the same machine...

I can rule out the decoding issue for playback, because I took the old Dell encoded file and played it on my Q6600 and it looks great, just like on my Dell. I played the Q6600 encoded video on the Q6600 and the old dell and it looks the same: blockier static screens at the beginning of the video.

turbojet

15th May 2009, 17:09

Coz some devices/softwares check for the level flag but are capable of decoding higher bitrates than those specified in the level (some cellphones for example...).

First time I've heard of this but I'm not familiar with cell phones. Can they decode any bitrate that's consistent over a second?
If not do you know how much higher bitrate they can decode?
Also if not leaving blank vbv may produce a skipping/unplayable output and the current situation of allowing up to vbv max doesn't help the matter. Looking at megui presets all of the cellphone profiles seem to follow level standards.

The reason i pointed you to that thread was to prove x264 has not been fixed and your statement:

was wrong

I'm pretty sure the fix was after November which is when that was posted. At least I remember checking a few BD players in January 2009 against --ref 4 --b-pyramid at 1920x1080 and they weren't playing, now the same players are playing the same 2 options with current x264 builds.

While b-pyramid may or may not be fixed how it should be, it doesn't seem to hinder playback anymore which is what the DPB formula only concern is.

yes. also, VBV parameters are checked against the level during the preset configuration.

VBV can never exceed the level because of how the x264 settings enforces the max rate so the check will never see a bad vbv setting or am I missing something?

Sharktooth

15th May 2009, 17:28

it depends on the device chipset or the software. for example, some media players/decoder want level 4.1 streams or they wont use DXVA. however they're capable of decoding streams with different limits from the L4.1...
the megui presets for cellphones and PDAs come as standard presets at levels 1.0, 1.1, 1.2 and 1.3. but it's not a secret there are cellphones that support level 1.x at much higher bitrate limits.
about the DPB, it was never fixed. the discussion ended with that thread and, if you read it, there is a chance the encode will be played back... but you can NEVER be sure since x264 continues to violate the DPB.
the VBV retrictions are FIXED by profile/level. they do not depend on res or fps, so they are checked when you create the preset. if you specify an invalid VBV rate for the specified profile/level, megui will warn you. i cant see a reason to change that behaviour.

turbojet

15th May 2009, 17:43

it depends on the device chipset or the software. for example, some media players/decoder want level 4.1 streams or they wont use DXVA. however they're capable of decoding streams with different limits from the L4.1...

Can you give some examples?

the megui presets for cellphones and PDAs come as standard presets at levels 1.0, 1.1, 1.2 and 1.3. but it's not a secret there are cellphones that support level 1.x at much higher bitrate limits.

Can you give some examples?

about the DPB, it was never fixed. the discussion ended with that thread and, if you read it, there is a chance the encode will be played back... but you can NEVER be sure since x264 continues to violate the DPB.

Everything on that thread pre dates my broken and playable tests.

the VBV retrictions are FIXED by profile/level. they do not depend on res or fps, so they are checked when you create the preset. if you specify an invalid VBV rate for the specified profile/level, megui will warn you. i cant see a reason to change that behaviour.

Are fixed by preset? yes. Fixed by level? Not currently, but my suggestion is VBV and references stay in compliance to the level set.

Sharktooth

15th May 2009, 18:17

the only DXVA decoder that can handle levels OVER 4.1 is MPC-HC AVC decoder. other decoders require Level 4.1 (just the flag on the bitstream!!!).
Some nokia phones and other phones (cant remember the models) have enough CPU power to decode AVC at levels higher than 1 or 1.x but are limited to those levels. you can safely encode at bitrate higher than level 1 or 1.x and the phone is perfectly able to play back the encode.
Again, x264 still violates the DPB. there is no entry in the changelog that says it was fixed. HENCE IT'S STILL BROKEN.
VBV restrictions are fixed by level/profile: http://en.wikipedia.org/wiki/H.264#Levels
That said, the discussion is over. You're speaking of something you dont even understand and i have no time to waste.

turbojet

15th May 2009, 18:30

When level is set in megui the vbv is not touched thus level does not fix vbv!
But ok I guess there still will not be a gui that has full range of settings and ensures the file will be within spec.
The threads and posts concerning this problem will continue to flood this forum.
Granted it shouldn't be gui's responsibility to fix x264's caveats but most people seem to think it should be.

Sharktooth

15th May 2009, 19:51

As i said, AVC Level checker is just a CHECKER. it wont change any parameters you set except for the fact that it wont permit the user to specify a level and non coherent parameters/options.
By that purpouse it will warn you when you select it, plus another check is run when you set up the preset... and if something is not coherent it will switch level to unrestricted/autoguess. THIS WONT CHANGE coz it is the only LOGIC thing to do.
Also there is only 1 person that rised this (not a-)problem and that person is you. So, by logic, im correct in stating your conclusion are illogical.
MeGUI is not an one click solution software. Users MUST KNOW what they're doing and looking for a table on wikipedia is not even so hard... expecially when it's the first hit when you type "AVC Levels" on google...

turbojet

15th May 2009, 20:19

I never suggested changing VBV to not autoguess when it's set higher then the level refers to, this will produce a compliant file however there are many situations where x264 and megui won't output a compliant file.

I'm not sure you understand what I'm suggesting which is to ensure that when level is used the file complies to that level. Currently the only thing it does is restrict vbv which is a start. The inaccurate avc level checker is pretty much hidden and a lot of megui users don't even know it exists.

The problem is every few days there's another post on this forum about a file not playing on their device m mainly due to too many references and resolution but vbv also comes up at times. I thought of a solution to all but the resolution problem and this is it. If someone has a better solution I'm all ears.

If/when megui outputs AVCHD/BD these issues will get even more and more popular and they'll directly point to MeGUI wouldn't you like to prevent these posts?

Profiles help but there's always people who are going to change things on a whim, some guide told them, etc. There is one common thing between H.264 encoders and H.264 devices and that's level, an encoder that complies to it is much more user-friendly then one that doesn't.

Kurtnoise

16th May 2009, 05:42

put a feature request on SF, we'll see what can we do for megui 1.0...;)

Sharktooth

16th May 2009, 14:51

I never suggested changing VBV to not autoguess when it's set higher then the level refers to, this will produce a compliant file however there are many situations where x264 and megui won't output a compliant file.
that depends on the user. if a user wants to set a level but doesnt want to put limits on the bitrate why should we add that restriction?
the user should also get informed on what he's doing. megui is not a software for the first idiot that thinks encoding is just a matter of some random mouse clicks.

I'm not sure you understand what I'm suggesting which is to ensure that when level is used the file complies to that level. Currently the only thing it does is restrict vbv which is a start. The inaccurate avc level checker is pretty much hidden and a lot of megui users don't even know it exists.
avc level checker is not inaccurate. it's made around x264 and it wont change until x264 will be fixed (if it ever will...).

The problem is every few days there's another post on this forum about a file not playing on their device m mainly due to too many references and resolution but vbv also comes up at times. I thought of a solution to all but the resolution problem and this is it. If someone has a better solution I'm all ears.
ppl could RTFM... as i said, you must know what you're doing...

If/when megui outputs AVCHD/BD these issues will get even more and more popular and they'll directly point to MeGUI wouldn't you like to prevent these posts?
i dont see any problems. there are presets for AVC-HD/BD. You should either use them or RTFM...

Profiles help but there's always people who are going to change things on a whim, some guide told them, etc. There is one common thing between H.264 encoders and H.264 devices and that's level, an encoder that complies to it is much more user-friendly then one that doesn't.
we dont fix idiots... just our software that is NOT MADE TO BE IDIOT PROOF on purpouse.

turbojet

16th May 2009, 19:46

put a feature request on SF, we'll see what can we do for megui 1.0...;)

OK I'll do that

that depends on the user. if a user wants to set a level but doesnt want to put limits on the bitrate why should we add that restriction?
the user should also get informed on what he's doing. megui is not a software for the first idiot that thinks encoding is just a matter of some random mouse clicks.

Isn't one of the few restrictions of H.264 levels max bitrate?

avc level checker is not inaccurate. it's made around x264 and it wont change until x264 will be fixed (if it ever will...).

They give different results. x264 warns correctly, avc level checker does not.

ppl could RTFM... as i said, you must know what you're doing...

i dont see any problems. there are presets for AVC-HD/BD. You should either use them or RTFM...

we dont fix idiots... just our software that is NOT MADE TO BE IDIOT PROOF on purpouse.

All rants that solve absolutely nothing. I also see no where in help explaining the levels so this would be misleading.

Doom9

16th May 2009, 20:56

Since I wrote the checker, this argument sparked my interest.
You asked
They give different results. x264 warns correctly, avc level checker does not.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.

Isn't one of the few restrictions of H.264 levels max bitrate?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.

turbojet

16th May 2009, 21:13

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

17th May 2009, 14:41

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

17th May 2009, 15:11

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 (http://forum.doom9.org/showthread.php?p=730001#post730001). 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

17th May 2009, 15:26

Doom9

17th May 2009, 15:28

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

17th May 2009, 18:23

from set.c ...:D

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

17th May 2009, 21:00

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

17th May 2009, 21:06

turbojet

17th May 2009, 22:18

Kurtnoise

18th May 2009, 00:04

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

magic144

18th May 2009, 00:41

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

18th May 2009, 01:15

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.

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.
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

18th May 2009, 07:31

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 (http://forum.doom9.org/showthread.php?p=1277785#post1277785) 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

18th May 2009, 07:52

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

18th May 2009, 07:56

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

18th May 2009, 13:23

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 (http://forum.doom9.org/showthread.php?p=1277785#post1277785) 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

18th May 2009, 13:28

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

18th May 2009, 13:30

magic144

18th May 2009, 15:35

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

ok done, thanks!

AkumaX

18th May 2009, 19:26

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*

Disturbance

18th May 2009, 20:13

your problem is probably due to avisynth going out of memory.

well i dont see how i have 4gb of ram, and i always had encoded multiple videos at a time, just all of a sudden stopped working like that, and can only encode 1 at a time now

turbojet

18th May 2009, 20:56

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.

DPB only matters for hardware devices. I care about compliant encodes as well which is why I brought up this suggestion. Currently megui can roam way outside of compliance to the level set.

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.

There's a big difference between seeing something written and actually experiencing it. Please correct me if I'm wrong but you seem to be basing everything you write off of what you read and not by experience. I don't believe everything I see, in fact I really don't believe there are any hardware devices that used to handle b-pyramid + (max-ref - 1) that don't handle b-pyramid + max-ref with current x264 builds all BD players tested so far handle it and it's by far the majority of the market. I'd encourage people to prove me wrong and I won't get angry about it at all. I've never seen an x264 dev claim that b-pyramid hasn't changed recently and this information is starting to spread.

I agree with you that x264 is the real culprit in all of this and should be responsible to output compliant streams. I already suggested it to them and if you know anything about how they stand on hardware compatibility they've always taken it as a laughing matter, at least the ones on Doom9 and that hasn't changed, Instead they delegate the responsibility to frontends. So here I am suggesting it to one of the more popular frontends that already has some things enforced and still seems to be worked on.

There's no reason to get angry and there's no reason to resort to insults. The only thing that gets me is you claim things over and over again but it's tough to take them seriously when they are so bland, please be more specific about your claims.

Doom9

18th May 2009, 22:07

That last post suddenly rang a bell (http://forum.doom9.org/showthread.php?t=145612&page=2)... suddenly, I see the futility of this discussion all the more clearly.

turbojet

18th May 2009, 23:09

That last post suddenly rang a bell (http://forum.doom9.org/showthread.php?t=145612&page=2)... suddenly, I see the futility of this discussion all the more clearly.

You are going way off topic here but I brought up completely valid points in that discussion, all of which are still true. m2ts has much more compatibility then mkv, m2ts allows lossless subs mkv doesn't, very few(none?) commercial software supports mkv while m2ts is widely supported. I also had experience with popcorn hour and tvix 6500 long before that discussion and it's true that some mkv's won't play correctly while the same audio/video/subs muxed to m2ts plays fine and its reproducable. It's yet TBD if mkv will still be widely talked about in 2011 but I never said it will or won't just that I bet it wouldn't.

Anyhow it's pretty clear that some megui devs want levels to stay non-compliant and they want to keep avc level checker as contradictory to even megui help files (wiki). They'll even start personal attacks to try to prove their point, not good support imo.

I guess my only hope is one of the dev's will actually see why this is important like MPEG1/2 encoders, XviD and DivX did long ago and were very open minded on the matter.

I'm done with this discussion and will just start ignoring every post that comes in regarding broken playback because levels are completely ignored.

Disturbance

19th May 2009, 00:49

well then would u be able to try help with the problem i am having? :D

Sharktooth

19th May 2009, 02:56

well i dont see how i have 4gb of ram, and i always had encoded multiple videos at a time, just all of a sudden stopped working like that, and can only encode 1 at a time now
on windows a 32 bit process cant allocate 4 gigz of ram. when hitting 2 gigz it goes nuts.
simplify your avisynth script.

@turbojet: your points are not valid at all and you still dont want to understand you're wrong. plain and simple. go polluting another place.
from now on i will sistematically ignore all your posts.

Disturbance

19th May 2009, 03:42

sharktooth i dont see how i use the same general scripts and then all of a sudden stops wanting to do it

Sharktooth

19th May 2009, 03:56

trying costs nothing.
the error happens on a dll which is made by microsoft so we cant really debug it...

Clumpco

20th May 2009, 10:51

Yoshiyuki Blade

20th May 2009, 15:10

Has anybody had any problems with update 0.3.1.1037?
Just updated and started an encode, got this immediately:
-[NoImage] Error starting job
--[NoImage] Exception message: starting encoder failed with error 'Process has exited'
--[NoImage] Stacktrace: à MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
--[NoImage] Inner exception: null

[EDIT] - Rolled back x264.exe to 1148 and normal service was resumed.

I've had an error with that too, I suppose I should roll back and give it a shot as well.

EDIT: It seems the build from Skystrife is borked somehow. I tried the one from techouse (http://forum.doom9.org/showthread.php?p=1287751#post1287751) and it works fine.