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. |
|
|
Thread Tools | Search this Thread | Display Modes |
16th May 2009, 21:13 | #2121 | Link | ||
Registered User
Join Date: May 2008
Posts: 1,840
|
Quote:
Quote:
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. |
||
17th May 2009, 14:41 | #2122 | Link |
Mr. Sandman
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.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
17th May 2009, 15:11 | #2123 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
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 |
17th May 2009, 15:26 | #2124 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
17th May 2009, 15:28 | #2125 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
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 |
17th May 2009, 18:23 | #2126 | Link |
Swallowed in the Sea
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
|
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; } |
17th May 2009, 21:00 | #2127 | Link |
Registered User
Join Date: Mar 2007
Posts: 26
|
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 |
17th May 2009, 22:18 | #2129 | Link |
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? |
18th May 2009, 00:41 | #2131 | Link |
Registered User
Join Date: May 2005
Posts: 395
|
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 |
18th May 2009, 01:15 | #2132 | Link | |||
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
Quote:
now, if you still dont want to understand, i will ignore further posts from you. Quote:
Quote:
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! Last edited by Sharktooth; 18th May 2009 at 01:25. |
|||
18th May 2009, 07:31 | #2133 | Link | |
Registered User
Join Date: May 2008
Posts: 1,840
|
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. |
|
18th May 2009, 07:52 | #2134 | Link | |
Registered User
Join Date: Mar 2007
Posts: 26
|
Quote:
i am at a loss as to why it does this |
|
18th May 2009, 07:56 | #2135 | Link |
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. |
18th May 2009, 13:23 | #2136 | Link | ||
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
Quote:
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:
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.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! Last edited by Sharktooth; 18th May 2009 at 13:34. |
||
18th May 2009, 13:28 | #2137 | Link | |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
Quote:
your problem is probably due to avisynth going out of memory.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
|
18th May 2009, 13:30 | #2138 | Link | |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
Quote:
apple stuff has common settings, while PSP is different. both apple (ipods/iphones... etc) and PSP wont accept normally muxed files.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|