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

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 16th May 2009, 21:13   #2121  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Quote:
Originally Posted by Doom9 View Post
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.

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

Last edited by turbojet; 16th May 2009 at 23:01.
turbojet is offline  
Old 17th May 2009, 14:41   #2122  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
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.
Sharktooth is offline  
Old 17th May 2009, 15:11   #2123  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,570
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
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline  
Old 17th May 2009, 15:26   #2124  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Doom9 View Post
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?
Dark Shikari is offline  
Old 17th May 2009, 15:28   #2125  |  Link
Doom9
clueless n00b
 
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,570
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"?
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org
Doom9 is offline  
Old 17th May 2009, 18:23   #2126  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,182
from set.c ...

Code:
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;
}
Kurtnoise is offline  
Old 17th May 2009, 21:00   #2127  |  Link
Disturbance
Registered User
 
Join Date: Mar 2007
Posts: 16
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
Disturbance is offline  
Old 17th May 2009, 21:06   #2128  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Doom9 View Post
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.
Dark Shikari is offline  
Old 17th May 2009, 22:18   #2129  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
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?
turbojet is offline  
Old 18th May 2009, 00:04   #2130  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,182
what I told you ?...now, pass the 2nd. Period.
Kurtnoise is offline  
Old 18th May 2009, 00:41   #2131  |  Link
magic144
Registered User
 
Join Date: May 2005
Posts: 380
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
magic144 is offline  
Old 18th May 2009, 01:15   #2132  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Quote:
Originally Posted by turbojet View Post
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.

Quote:
Originally Posted by magic144 View Post
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.
Quote:
Originally Posted by Disturbance View Post
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?

Last edited by Sharktooth; 18th May 2009 at 01:25.
Sharktooth is offline  
Old 18th May 2009, 07:31   #2133  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Quote:
Originally Posted by Sharktooth View Post
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.
turbojet is offline  
Old 18th May 2009, 07:52   #2134  |  Link
Disturbance
Registered User
 
Join Date: Mar 2007
Posts: 16
Quote:
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
Disturbance is offline  
Old 18th May 2009, 07:56   #2135  |  Link
AkumaX
Registered User
 
Join Date: Mar 2007
Posts: 6
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...

Last edited by AkumaX; 18th May 2009 at 08:01.
AkumaX is offline  
Old 18th May 2009, 13:23   #2136  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Quote:
Originally Posted by turbojet View Post
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.

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

Last edited by Sharktooth; 18th May 2009 at 13:34.
Sharktooth is offline  
Old 18th May 2009, 13:28   #2137  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Quote:
Originally Posted by Disturbance View Post
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 is offline  
Old 18th May 2009, 13:30   #2138  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Quote:
Originally Posted by AkumaX View Post
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.
Sharktooth is offline  
Old 18th May 2009, 15:35   #2139  |  Link
magic144
Registered User
 
Join Date: May 2005
Posts: 380
Quote:
Originally Posted by Sharktooth View Post
post a feature request in the megui feature requests tracker on sourceforge.
ok done, thanks!
magic144 is offline  
Old 18th May 2009, 19:26   #2140  |  Link
AkumaX
Registered User
 
Join Date: Mar 2007
Posts: 6
Quote:
Originally Posted by Sharktooth View Post
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*
AkumaX is offline  
Closed Thread

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 21:30.


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