MeGUI: General Questions and Troubleshooting Thread

[TheRyuu]

In the latest development version,
Is anyone else getting a screwed up aspect ratio on xvid encodes? It doesn't seem to effect h264 (mkv) encodes.

Just ran a 10hour encode and it plays back like super wide screen.

Is this a know bug?
Also, is there any way to fix this without a re-encode (I know that the resolution is correct on it too).

Thanks.

I guess I'll roll back to the latest stable version for now.
Anyone know how to fix the ar problem without a re-encode?

[foxyshadis]

Might be assigning the AR to both the bitstream and the container, what container do you use for xvid?

If that is the case, you should be able to fix it with mpeg4modifier.

[berrinam]

Searching the web suggests the definitions of DAR & PAR are well established, but that for SAR isn't - sometimes it means PAR, as you use, & sometimes DAR/PAR.Indeed, a web search does show much less ambiguity with PAR than I thought. But a number of pages also use SAR to mean PAR, including x264, so I think that's all ok.

What term do you use for DAR/PAR?No term, just video width/height.

It's also not terribly important which you treat as the derived quantity as long as the arithmetic is precise, however I'd still be inclined to go with DAR as the derived value as ime (quite limited), one tends to work with a small set of possible PARS all of which can be represented precisely as the ratio of two four digit integers. I think in practice if you wish to store DAR precisely you'd need more. Not important, just a personal choice.I don't think precision is a big concern here. Internally in MeGUI, all calculations are being done with the C# "decimal" type, which has 28 decimal digits of precision. Given that very few calculations are actually done, I think it stays very precise, and the errors in calculation are dwarfed by the (intentional) rounding done of the AR to make it fit better on standard displays. The default "acceptable error" is 5%, which I found acceptable by testing (YMMV), so I think there's a pretty big margin for error in AR calculation anyway. And even if you set that to 0%, you're likely to get a significant aspect error when you round the resizing to mod16, anyway.

As to the representation of ARs, in general, with fractions, the stuff I said about precision above means that I don't really see the point of doing it. MeGUI used to use that representation internally, to dubious advantages.

Yes, by PAR I mean pixel aspect ratio and by DAR display aspect ratio. With this definition I have understood SAR is equivalent to PAR, no? (hopefully _I_ haven't made a fundamental error here ;))You're correct.

I think here our points of view will differ a little. Definitely, for the user, DAR is more intuitive, unless they've spent enough time pondering about the whole matter.

To me, PAR is "everything" - it will define everything else. Once I know what the PAR of the source is, I can derive every other value simply from that fact. This, I have to admit, undoubtedly will somewhat cloud my view in this.This reasoning is misinformed. If you know the PAR and the resolution then you can calculate the DAR. But similarly, if you know the DAR and the resolution you can calculate the PAR. In this sense, they are equivalent.

[berrinam]

Might be assigning the AR to both the bitstream and the container, what container do you use for xvid?MeGUI generally does that, but I'm not aware that this was a problem. I think that wizboy's problem is indeed a MeGUI bug: I think the commandline for xvid currently doesn't include the AR.

[berrinam]

why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...I didn't know about this problem with MP4Box. If it is a real concern, then MeGUI should at least notify the user of it when they have a bad filename, and preferably provide a workaround as well.

[TheRyuu]

MeGUI generally does that, but I'm not aware that this was a problem. I think that wizboy's problem is indeed a MeGUI bug: I think the commandline for xvid currently doesn't include the AR.

Problem is, the bug wasn't here before the latest development revision.

I'll try mpeg4modifyer.
Thanks.

In the mean time, I'll roll back to the latest stable revision. If there is anything I can do to help fix that bug let me know. :p

The container was avi just to let you know. And the problem only effects xvid encodes.

Edit:
I think I traced down the problem.
Megui isn't assuming squar pixels and is setting the pixel AR to 16:9 or something along those lines.
So like a video of 704x396 is already 16:9, is being 16:9ed again after it's already 16:9 if you get what I'm saying :p (I don't know of any other way to put it, like super stretched wide screen).
Not sure if this is due to not specifying it in the command line to xvid_encraw.

Out of curiosity, why does this problem only effect the latest development release?

mpeg4modifier worked great btw :)

[berrinam]

I recently made some changes to handling of AR. xvid got left out. Hence the bug.

[pablobhz]

Hello, i'm new on this forum.
I've searched a bit around, but found no answer. Then i decided to post here.
My megui decided to crash as hell. I try to import my avs script to encode there, and it crashes. It looks like its an problem with x264.exe, but i tried to encode with another script, and it worked fine. I've just made a fresh install of windows, thinking about something with him, but no clue.
also...i have a x2 3600+ 1gb ram GeForce 7100GS M2N4-SLI
its a fine cpu for encoding.
Well, i'll also post my script. Maybe there's something with it, dunno.

Thanks for the attention. The crash message is some classical "megui found an error and it has to be closed"(I don't know how it is english).

Thanks.


Import("C:\Arquivos de programas\AviSynth 2.5\plugins\LimitedSharpenFaster.avs")
LoadPlugin("C:\Arquivos de programas\AviSynth 2.5\plugins\fft3dfilter.dll")
AudioDub(DGDecode_mpeg2source("MoetanRIP.d2v",cpu=4,info=3,iPP=true, moderate_v=20),DirectShowSource("MoetanRIP T01 2_0ch 448Kbps DELAY 0ms.ac3"))
ColorMatrix(d2v="MoetanRIP.d2v",interlaced=true)
tfm(order=-1,pp=5)
fft3dfilter()
LimitedSharpenFaster()
LanczosResize(720,480)
converttoyv12()
Trim(172,36854)

[check]

Remove the lines one by one until you isolate which causes the problem.

[Kurtnoise]

Sorry again, I wasn't clear enough. I was merely referring to your choice of par presets for pal & ntsc 4:3 & 16:9. Yours differ (last time I checked) slightly from those given by Jukka Aho.
The presets in Yamb are the same defined by the standard...

Out of interest, why does mp4box care? What does it do with the names?
MP4Box is vey sensitive with filenames because we can pass some options in it.

I didn't know about this problem with MP4Box. If it is a real concern, then MeGUI should at least notify the user of it when they have a bad filename, and preferably provide a workaround as well.
not really a big deal imo...I know that MP4Box raises errors during the mux process when subtitles have several dots in their filenames. I got also the same issue with few audio streams.

[Adub]

@pablobhz
If you load the script with MPC or virtualdub, what does it say?

[Maccara]

This reasoning is misinformed. If you know the PAR and the resolution then you can calculate the DAR. But similarly, if you know the DAR and the resolution you can calculate the PAR. In this sense, they are equivalent.

Not really misinformed - I just didn't put it well. ;) PAR is "everything" to me, because I do not change PAR (resize), unless I'm doing a format conversion (NTSC -> PAL/1:1) and I'm using sampling rate & line length as a basis for the calculations (when known), so PAR is intuitive here.

But, you of course are right. If we know any 2 of DAR/PAR/resolution reliably, we can derive rest. I just happen to usually know the PAR & cropped resolution with my my sources. But of course, with DVDs', the DAR is well defined too (assuming, of course, the DVD is mastered ok), so in that sense they're indeed equivalent.

Thanks for the interesting discussion! I'm glad to know, in megui this is at least handled correctly (seen too many "professionals" to get these wrong too, so I have learned to test / ask myself how it is done in software, which in this case unfortunately only raised questions as there were a couple of bugs :)).

[pablobhz]

@pablobhz
If you load the script with MPC or virtualdub, what does it say?

If i load the script with MPC or Vdub, it plays fine.
Well, i found out the problem is with LimitedSharpenFaster()
I checked and i've unpacked dlls correctly in AviSynth's plugin folder. But for some reason it isn't working.

I was talking about this problem with a friend, he said it coud be some problem of RemoveGrain dll's.
I will try some things and i hope it works.
Thanks everyone for attention and help.

[Edit]: I found out LimitedSharpenFaster.avs wasn't in the plugins folder. I fixed it, but megui keeps crashing. My plugins folder is a mess, is there something with it ? I always used it as it is, and i never had problems.

[ChrisW77]

I find it a bit strange that these audio problems aren't such a big deal.
I mean, if I can't name my own files how I want them to be named, ie with dots, and I can't name them using long filenames (so the dots are taken out but the filename still exists), and lastly (even more confusing as to why) why I can't write the muxed file back to the same drive/partition. :confused:

Whats the purpose of actually bothering to have a MP4 muxer if it doesn't work properly ?

These are bugs, plain and simple. Not being able to write back to the same drive, is just plain stupid, as is the long filenames.

Shame, as this is one of the best GUIs out there, ruined by a non-working mp4 muxer.

[mroz]

The presets in Yamb are the same defined by the standard...

Got a reference? I'd like to be able to compare it to Jukka Aho's analysis (http://lipas.uwasa.fi/~f76998/video/conversion/) which fits with my understanding, is well written from a technical point of view & links to several technical resources. Did you read this btw?

I can then forward such info to Jukka; if he doesn't wish to comment I'd just drop the issue again, as I don't have the relevant background to argue the case more stongly without first doing a lot more research.

Maybe Maccara can comment?

MP4Box is vey sensitive with filenames because we can pass some options in it.

Got a link to info on the details? I imagined it'd be something along those lines, but still can't see why that couldn't be implemented cleanly. Code should adhere to standards strictly when it comes to output, but as a general rule of thumb, tollerate malformed input if it can be done without ambiguity, imo.

Not a big deal, no, but if the problem can be identified & easily fixed it might as well be.

[Maccara]

Maybe Maccara can comment?


Without checking anything, I'd say we're probably talking about rounding differences here. What are the actual values used in mp4box which you think are different? (I haven't used that myself yet)

Jukka Aho gives mathematically correct values. However, in practice slightly different values are generally used (particularly for NTSC) due to rounding differences. Difference, however, is quite small and probably doesn't matter. (I think Jukka mentions in the change history he has updated the values at some point)

There will be even more variability between DVDs due to different mastering and for analogue captures due to different hardware/drivers - even cameras have slight differences. (and the dvd differences have on many occasion raised the argument, that generic par values should be favored over itu values - which is fine by me, as long as "itu" compliance is not then claimed and I have to have the option to input my own values in that case ;))

[mroz]

The differences are tiny, around 0.3% (unlike the difference between these values & those Nero Recode uses; that's about 2 to 3% last time I checked).

yamb aho yamb/aho

4:3 pal 12:11 128:117 351/352 = 0.997159
ntsc 10:11 4320:4739 4739/4752 = 0.997264

16:9 pal 16:11 512:351 as above
ntsc 40:33 5760:4739


Edit: mp4box doesn't know PAR presets; the above values are supplied by the gui Yamb to mp4box

[pablobhz]

If i load the script with MPC or Vdub, it plays fine.
Well, i found out the problem is with LimitedSharpenFaster()
I checked and i've unpacked dlls correctly in AviSynth's plugin folder. But for some reason it isn't working.

I was talking about this problem with a friend, he said it coud be some problem of RemoveGrain dll's.
I will try some things and i hope it works.
Thanks everyone for attention and help.

[Edit]: I found out LimitedSharpenFaster.avs wasn't in the plugins folder. I fixed it, but megui keeps crashing. My plugins folder is a mess, is there something with it ? I always used it as it is, and i never had problems.

Hi
I'm posting again, because i've found no clue about what is happening. I've verified all configs, all files and my megui is still crashing with LimitedSharpenFaster()
I don't know what more i can do. Maybe an filter to use instead of LimitedSharpenFaster ? Sorry, but i'm asking help since i've no more ideas.
Also checked RemoveGrain DLL's and they're allright.
Thanks
Pablo
p.s: I've used to quote the message, so anyone who reads wil know what is it about.

[PlazzTT]

I've just installed meGUI on my new system, and I'm getting this error when I try to load any d2v into the AVS Generator:
http://i23.tinypic.com/fcm98o.png

I would try the suggestions given, but it's a D2V file, and not an AVS :/

[Maccara]

The differences are tiny, around 0.3%

Yup, just different rounding used during calculations. There also may be a difference, if fractions (for resolutions) is floored, or rounded up (itu ntsc mathematically "correct" x res 710.85, and if that is used for the calcs and is done with 710 or 711 pixels, there's a slight difference).

I don't even remember myself, if it is specified anywhere when and which way values should be rounded - I've just used full precision myself usually, as does Jukka.

I'd say there's nothing to worry about - I'm not even 100% sure if not rounding for calculations is absolutely the correct way to go, so I won't argue if yamb provided values are more correct or Jukka's. ;)

(Edit: I just whipped up a quick test in excel and if I floored the numbers to 5 significant numbers, I got mostly the same values as yamb provided - this is less difference than there is between some different cameras/lenses geometry)

[foxyshadis]

Berrinam, consider something like this in scripts if any cropping is done?

global MeGUI_darx = 1823
global MeGUI_dary = 1000
xSource(...)
original = last
etc
UpdateDAR(original, last)

function UpdateDAR(clip old, clip new) {
global MeGUI_darx = MeGUI_darx * new.width / old.width
global MeGUI_dary = MeGUI_dary * new.height / old.height
}

[trooper11]

I ddint see this posted yet, so Ill ask.

Im trying to analyse the source material in the avisynth script creator and it continues to fail, giving an error.

'Source detection couldnt determine the source type'

The file is an mkv that opens and previews fine in MeGUI. Is there anything I can do to get around this? This is running on a Windows XP pc by the way. Thanks

[pablobhz]

oh
my file started to crash on MPC too.
For some reason, don't know. It was working fine on MPC.
Maybe is there something i can use instead of LimitedSharpenFaster() . But its strange, since the person who uses this told me he never had problems.
Thanks
btw, the error happens after i enqueue the job. For those who haven't readed about my problem, just look 4 messages ago, something around it. Thanks
Pablo

[ChrisW77]

Just tried Yamb, as it's a front-end for MP4box, and it worked using long filenames, dotted filenames, and wrote back to the same drive.
This proves it's not a mp4box problem, it's a megui problem.

[berrinam]

Berrinam, consider something like this in scripts if any cropping is done?

global MeGUI_darx = 1823
global MeGUI_dary = 1000
xSource(...)
original = last
etc
UpdateDAR(original, last)

function UpdateDAR(clip old, clip new) {
global MeGUI_darx = MeGUI_darx * new.width / old.width
global MeGUI_dary = MeGUI_dary * new.height / old.height
}

Nice idea, but I think the cropping problem is fixed now: MeGUI prints the correct dar in the first place (as it used to do).

Out of interest, would that Avisynth script work? I would have thought it would complain that you're redeclaring the globals, MeGUI_darx and MeGUI_dary.

[mroz]

I'd say there's nothing to worry about - I'm not even 100% sure if not rounding for calculations is absolutely the correct way to go, so I won't argue if yamb provided values are more correct or Jukka's. ;)

Thanks for the feedback & explanation. I'll buy that & shut up now :)

[rack04]

I see that the bug report for the automatic shutdown was closed. Can anyone else verify that this feature is fixed? It still doesn't work on my end.

[mroz]

Odd behavour from 2.6.1026 (not posted to bugtracker as currently not repeatable):

Queued up a huffy prerender on a 3 minute 720p d2v source (with a slow deblocking avs) followed by an x264 encode. Reused the prerender output as source for five more x264 encodes at various bitrates. Came back this morning & all looks fine; queue done on the expected timescale; files play.

...Then notice a minimised dialogue - Status: 99.91%.

Use minimise then restore to make it visible. It's from a 2nd pass of x264, I assume the final encode, claiming to be stuck at frame 8547 of 8555 (though all output within is frozen). Out of curiosity I try to alter priority; as perhaps expected this throws a stacktrace - object ref is not an instance of an object, indicating I assume that the gui has been left lying around after the underlying encode completed.

Clicking abort results in the usual warning dialogue which when ok'd makes no difference.

Manually closing the window does get rid of it.

[Blue_MiSfit]

I'm not sure why the following command line (lifted from my MeGUI log from an encode last night) split my output MKV into close to 2000 pieces, but it sure did.


Job commandline: "C:\Program Files\megui\tools\mkvmerge\mkvmerge.exe" -o "J:\Movies Work\Knocked Up\Knocked Up-muxed.mkv" --aspect-ratio 0:37/20 -A -S "J:\Movies Work\Knocked Up\Knocked Up.mkv" -a 0 -D -S "J:\Movies Work\Knocked Up\Knocked T01 3_2ch 448Kbps DELAY 0ms.ac3" --split 0M --no-clusters-in-meta-seek


I don't recall selecting anything that would split the output...

It seems like the --split 0M flag wouldn't be needed? Maybe this should have been left out. Either way, I don't have the original encoded H.264 only MKV anymore and just 2000 little pieces... :)

I'm using 0.2.6.1026, and did x264 with hq-slowest 2 pass, and muxing ac3...

Ideas??

~MiSfit

[Kurtnoise]

weird...I can't reproduce this here. You use AutoEncode or something else ?

I see that the bug report for the automatic shutdown was closed. Can anyone else verify that this feature is fixed? It still doesn't work on my end.
using the last dev build, it works fine here...

[nurbs]

I just did a quick check and the auto shutdown doesn't work for me either. I do nothing fancy, just normal encoding. The countdown window appears, but it doesn't shut down then. This is on WinXP SP2 with the latest dev build (0.2.6.1026).

[Kurtnoise]

Try this build (http://www.mediafire.com/?3mt8stwsrde) or this one (http://www.mediafire.com/?09r42uxsx2x)...

[nurbs]

Shutdown works with the second build. :thanks:
The first doesn't work.

[berrinam]

I'm not sure why the following command line (lifted from my MeGUI log from an encode last night) split my output MKV into close to 2000 pieces, but it sure did.


Job commandline: "C:\Program Files\megui\tools\mkvmerge\mkvmerge.exe" -o "J:\Movies Work\Knocked Up\Knocked Up-muxed.mkv" --aspect-ratio 0:37/20 -A -S "J:\Movies Work\Knocked Up\Knocked Up.mkv" -a 0 -D -S "J:\Movies Work\Knocked Up\Knocked T01 3_2ch 448Kbps DELAY 0ms.ac3" --split 0M --no-clusters-in-meta-seek


I don't recall selecting anything that would split the output...

It seems like the --split 0M flag wouldn't be needed? Maybe this should have been left out. Either way, I don't have the original encoded H.264 only MKV anymore and just 2000 little pieces... :)

I'm using 0.2.6.1026, and did x264 with hq-slowest 2 pass, and muxing ac3...

Ideas??

~MiSfitLike Kurtnoise, I can't reproduce this. I would really appreciate it if you detailed your exact steps, because a number of people have mentioned this. If possible, could you work out exactly what you did (including file formats), check that it is reproducible, and then post it on the SF bug tracker please?

[Blue_MiSfit]

Will do - I just tried again last night (Explicitly selecting no split this time) and got the same results.


What I did:

1) VOB Source, Indexed with DGIndex 1.5.0 b6
2) AviSynth script was a simple MPEG2Source, and ColorMatrix with no extra filters
3) Loaded script into video source. Started with HQ-Slowest for x264 as a baseline, and selected a CQM - M4G HRM v2. Adjusted keyframe intervals for FILM material (240/24)
4) Made a new profile for this called HQ-Transparent
5) Set MKV output
6) Selected Auto Encode
7) Set MKV as container, checked "add aditional content", and set 2.2 GB as target size. Set splitting to "no splitting"
8) Selected 5.1ch AC3 as audio 1 - set as English and named "English 5.1). Verified that MKV was selected and splitting was set to "No splitting"
9) Go and Start Encoding.

In the end I have nearly 2000 tiny little MKV files, most under 3 MB in size. The video looks _great_ but audio is desynched in all the pieces.

I'm guessing either MKVMerge is at fault, or MeGUI is passing it an incorrect command line.

I have all the latest tools via auto-update as of 10-18.


***MeGUI log (end deleted for size's sake):

Generating jobs. Desired size: 2.2 GB

Desired size of this job series: 2.2 GB
Split size of this job series: 0 bytes

Looking for job processor for job...

Processor found!



------------------------------------------------------


Starting job job1 at 12:33:28 AM

Starting preprocessing of job...

Doing bitrate calculation...
Desired video size after subtracting audio size is 1866915KBs. Setting the desired bitrate of the subsequent video jobs to 1917 kbit/s.
Preprocessing finished!

successfully started encoding

Processing ended at 1:55:05 AM

----------------------

Log for job job1

Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 1 --bitrate 1917 --stats "J:\Movies Work\Knocked Up\Knocked Up.stats" --keyint 240 --min-keyint 24 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --me dia --threads auto --thread-input --sar 3083:2500 --cqmfile "D:\x264 Matricies\High Bitrate\Transparent\M4G HRM V2.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --output NUL "J:\Movies Work\Knocked Up\Knocked Up.avs"
avis [info]: 720x480 @ 23.98 fps (191270 frames)
x264 [info]: using SAR=3083/2500
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:1931 Avg QP:22.55 size: 36705
x264 [info]: slice P:59137 Avg QP:24.54 size: 15189
x264 [info]: slice B:130202 Avg QP:26.18 size: 7170
x264 [info]: mb I I16..4: 36.4% 0.0% 63.6%
x264 [info]: mb P I16..4: 18.3% 0.0% 0.0% P16..4: 80.4% 0.0% 0.0% 0.0% 0.0% skip: 1.3%
x264 [info]: mb B I16..4: 0.8% 0.0% 0.0% B16..8: 23.6% 0.0% 0.0% direct:65.5% skip:10.1%
x264 [info]: final ratefactor: 24.77
x264 [info]: direct mvs spatial:99.5% temporal:0.5%
x264 [info]: kb/s:1908.0

encoded 191270 frames, 39.07 fps, 1908.18 kb/s

----------------------

Starting postprocessing of job...

Job completed successfully and deletion of intermediate files is activated

Postprocessing finished!

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


Looking for job processor for job...

Processor found!



------------------------------------------------------


Starting job job2 at 1:55:05 AM

Starting preprocessing of job...

Preprocessing finished!

successfully started encoding

Processing ended at 11:54:03 AM

----------------------

Log for job job2

Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 2 --bitrate 1917 --stats "J:\Movies Work\Knocked Up\Knocked Up.stats" --keyint 240 --min-keyint 24 --ref 10 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 3083:2500 --cqmfile "D:\x264 Matricies\High Bitrate\Transparent\M4G HRM V2.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --output "J:\Movies Work\Knocked Up\Knocked Up.mkv" "J:\Movies Work\Knocked Up\Knocked Up.avs"
avis [info]: 720x480 @ 23.98 fps (191270 frames)
x264 [info]: using SAR=3083/2500
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:1931 Avg QP:16.65 size: 52900
x264 [info]: slice P:59137 Avg QP:19.17 size: 19881
x264 [info]: slice B:130202 Avg QP:20.52 size: 4866
x264 [info]: mb I I16..4: 12.9% 80.4% 6.7%
x264 [info]: mb P I16..4: 2.0% 8.6% 0.4% P16..4: 46.3% 21.7% 19.4% 0.0% 0.0% skip: 1.5%
x264 [info]: mb B I16..4: 0.2% 0.6% 0.0% B16..8: 19.3% 1.8% 3.8% direct: 0.9% skip:73.4%
x264 [info]: 8x8 transform intra:78.5% inter:99.4%
x264 [info]: direct mvs spatial:88.7% temporal:11.3%
x264 [info]: ref P 53.7% 19.4% 7.2% 5.3% 3.0% 3.8% 2.3% 1.9% 1.3% 2.0%
x264 [info]: ref B 72.7% 13.9% 4.1% 3.2% 1.3% 1.4% 1.1% 0.9% 0.6% 0.8%
x264 [info]: kb/s:1916.8

encoded 191270 frames, 5.33 fps, 1917.10 kb/s
desired video bitrate of this job: 1917 kbit/s - obtained video bitrate (approximate): 1919 kbit/s
----------------------

Starting postprocessing of job...

Job completed successfully and deletion of intermediate files is activated

Found intermediate output file 'J:\Movies Work\Knocked Up\Knocked Up.stats', deleting...
Deletion succeeded.

Postprocessing finished!

End of log for job2
-------------------------------------------------------


Looking for job processor for job...

Processor found!



------------------------------------------------------


Starting job job3 at 11:54:03 AM

Starting preprocessing of job...

Preprocessing finished!

successfully started encoding

Processing ended at 11:56:07 AM

----------------------

Log for job job3

Job commandline: "C:\Program Files\megui\tools\mkvmerge\mkvmerge.exe" -o "J:\Movies Work\Knocked Up\Knocked Up-muxed.mkv" --aspect-ratio 0:37/20 -A -S "J:\Movies Work\Knocked Up\Knocked Up.mkv" --language 0:English --track-name "0:English 5.1" -a 0 -D -S "J:\Movies Work\Knocked Up\Knocked Up T01 3_2ch 448Kbps DELAY 0ms.ac3" --split 0M --no-clusters-in-meta-seek
mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:39:56
'J:\Movies Work\Knocked Up\Knocked Up.mkv': Using the Matroska demultiplexer.
'J:\Movies Work\Knocked Up\Knocked Up T01 3_2ch 448Kbps DELAY 0ms.ac3': Using the AC3 demultiplexer.
'J:\Movies Work\Knocked Up\Knocked Up.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
Track 1 of 'J:\Movies Work\Knocked Up\Knocked Up.mkv': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 888/480.
'J:\Movies Work\Knocked Up\Knocked Up T01 3_2ch 448Kbps DELAY 0ms.ac3' track 0: Using the AC3 output module.
Warning: 'J:\Movies Work\Knocked Up\Knocked Up.mkv': A track with the ID 0 was requested but not found in the file. The corresponding option will be ignored.
The file 'J:\Movies Work\Knocked Up\Knocked Up-muxed-001.mkv' has been opened for writing.


The cue entries (the index) are being written...
The file 'J:\Movies Work\Knocked Up\Knocked Up-muxed-002.mkv' has been opened for writing.


The cue entries (the index) are being written...
The file 'J:\Movies Work\Knocked Up\Knocked Up-muxed-003.mkv' has been opened for writing.


The cue entries (the index) are being written...
The file 'J:\Movies Work\Knocked Up\Knocked Up-muxed-004.mkv' has been opened for writing.


I will post this on the SF page, as soon as I figure out how to!

~MiSfit

[Blue_MiSfit]

Reported. Let's hope this gets identified quick! :)

I haven't checked on MeGUI in awhile (a few months) and have noticed some very nice improvements. Great work guys!!

~MiSfit

[Kurtnoise]

@nurbs: great...just a request from me : could you test the Avisynth Creator in this build (http://www.mediafire.com/?2semmomqfae) please ? It's just to know if the Save Dialog event works fine...


@Blue_MiSfit: I'm trying to reproduce your issue but for the moment I can't...

[nurbs]

@Kurtnoise13: The Avisynth Script Creator works fine for me.

[Sharktooth]

@Blue_MiSfit: i cant reproduce it too

[Blue_MiSfit]

I will try erasing and re-installing all of meGUI and let it auto update everything. It's possible it got goofed up when I did my last big update.

[trooper11]

I was just wondering if there had been any progress on getting around the mediainfo problem in vista.

I tried downloading and installing the latest mediainfo (7.5.3 versus the 7.4.4 used in megui by default) and copied the mediainfo.dll to the megui folder, but megui still crashes whenever I try to open a video in the avisynth script creator.


I see a mediainfowrapper.dll file that isnt included with the mediainfo install, so I dont know if that file needs to be updated as well or not.

It definitely seems to be an issues with the mediainfo interaction. I even went as far as disabling preview, but that didnt change things either. I am using the latest build fo megui (2.6.1027).

[Sharktooth]

mediainfo in included in megui. you dont need to manually update it and however the version included with megui is 7.5.3...

[Morte66]

A question out of curiosity...

meGUI has the option to do a pre-rendering job the huffYUV (or it'll be back soon). huffYUV encodes in YUY2, but the AviSynth scripts associated with meGUI usually work in YV12. So there is presumably some conversion going on. I was wondering, is this lossless (data transposition), or nearly lossless (just arithmetic roundings), or not lossless (e.g. blocks getting merged/split)?

Or have I just completely misunderstood the whole thing?

[Kurtnoise]

by definition, huffYUV is a lossless codec.

[mroz]

That doesn't answer Morte66's question. There's potentially a colour space conversion involved.

As it happens, Mencoder does Megui's huffy encode & it insists on YV12 input (indeed, if your script doesn't output YV12 it will add a call to ConvertYV12() at the end).

So if your script works in YV12 there are no problems, however if, say, you were using YUY2 in your script there would be data loss as the conversion would take you from chroma shared between 2 pixels to shared between 4 pixels.

As an aside, I've seen nasty results from chaining just two colourspace conversions. Scenario: I was using VDub to do a huffy encode which by default was encoding in YV12 space, however I couldn't get VDub to accept YV12 input, so as a quick fix added a conversion to YUY2 (I figured this would be ok as it is more refined than YV12). It turned out the conversions from YV12 to YUY2 to YV12 introduced a nasty yellow colour cast. In the end I configured VDub to encode in YUY2 & got rid of the colour cast. Always keep colour space conversions to a minimum. Which reminds me, I should have looked into why VDub wouldn't accept YV12 for me...

[Morte66]

So if your script works in YV12 there are no problems, however if, say, you were using YUY2 in your script there would be data loss as the conversion would take you from chroma shared between 2 pixels to shared between 4 pixels.

But AFAICT huffYUV encodes in YUY2 (or RGB), not YV12. At least it says so here (http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html) . And I see no YV12 option on the ffdshow encoder. What makes you say it encodes in YV12? Is there a newer version kicking about or something? I'm confused...

[Morte66]

by definition, huffYUV is a lossless codec.

HuffYUV is lossless, but a stream starting in YV12 and going to huffYUV YUY2 and back to YV12 may not be lossless. That's what I'm trying to clarify.

To put it another way, if you took a YV12 stream and did ConvertToYUY2().ConvertToYV12(), would that be a lossless process?

[mroz]

But AFAICT huffYUV encodes in YUY2 (or RGB), not YV12. At least it says so here (http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html) . And I see no YV12 option on the ffdshow encoder. What makes you say it encodes in YV12? Is there a newer version kicking about or something? I'm confused...

I assume that description applies to that specific implementation. Megui uses Mencoder which contains its own. The only thing I can say for certain is that it will insist on YV12 input as I said - I've read the source code which inserts the conversion if the format isn't YV12 (see MPlayer sources trunk\libmpdemux\demux_avs.c around lines 259-282).

As to the ffdshow implementation, it allows a choice of YUY2 & YV12. I'm using rev 1058 Mar 22 2007 though I have no reason to assume this is a new option. See VFW config -> Encoder tab -> Generic options -> colourspace.

[Morte66]

I assume that description applies to that specific implementation. Megui uses Mencoder which contains its own. The only thing I can say for certain is that it will insist on YV12 input as I said - I've read the source code which inserts the conversion if the format isn't YV12 (see MPlayer sources trunk\libmpdemux\demux_avs.c around lines 259-282).

As to the ffdshow implementation, it allows a choice of YUY2 & YV12. I'm using rev 1058 Mar 22 2007 though I have no reason to assume this is a new option. See VFW config -> Encoder tab -> Generic options -> colourspace.

Ah, got it. That all makes sense. Thanks.

[rack04]

Should the input DAR in the avisynth creator automatically select the correct DAR of the source? The last .ts OTA HD recording I tried it defaulted to 1:1.