MeGUI Bug-Report Thread

[Doom9]

@cmw: please make a screenshot from the preview window when you load the source in the avisynth script creator, another one after having pressed autocrop, and then save the script, post the script contents and make another screenshot from what you get if you preview the script (or open it in your favorite media player.. your pick). Also, what is DAR set to?

[cmw]

Ok, I did all the stuff. For making it not any more confusing, i took a NON-Interlaced Source (Analyse will correctly declare it as progressive), but as you can see, the aspect ratio isn't correct.

There is no DAR set at all (I could set it by hand, but this always worked automated with previous versions).


Picture after load:
http://cmw.cybton.com/afterload.png

Picture after autocrop:
http://cmw.cybton.com/aftercrop.png

Preview Picture:
http://cmw.cybton.com/preview.png

AviSynth Script:


DirectShowSource("C:\Dokumente und Einstellungen\Chaos Raven\Eigene Dateien\Eigene Videos\Du bist Deutschland.avi",fps=25,audio=false)
#blank deinterlace line
crop(2,30,-2,-32)
LanczosResize(352,240)
#denoise



I noted that when I load the Preview, the icon for ffdshow video decoding appears. Is this correct?

best regards, gmw

[Richard Berg]

The problem is that there's no way to tell MeGUI whether the sections you're cropping out are part of the active pixel area or not. That is, sometimes you crop to remove borders, in which case the reduced area should be treated as the active pixel area. Other times, you crop active pixels just because you don't want them for whatever reason. And then if you're me, you do a little of both on the same video, and further split that crop into mod8 and non-mod8 pieces...

...suffice to say, no GUI (including PARanoia; I've discussed this with incredible before) supports all of these possibilities.

[Richard Berg]

Bug: in the latest code, encoding AAC with BeSweet, the bitrate parameter isn't passed on the command line so you end up with larger than expected files. Probably not worth fixing if we're moving to Avisynth exclusively soon.

[dimzon]

Bug: in the latest code, encoding AAC with BeSweet, the bitrate parameter isn't passed on the command line so you end up with larger than expected files. Probably not worth fixing if we're moving to Avisynth exclusively soon.
FAAC or NAAC ?

[Richard Berg]

FAAC, sorry

[max-holz]

Probably not worth fixing if we're moving to Avisynth exclusively soon.

And the people that want to continue using BeSweet?

[dimzon]

FAAC, sorry
fixed

[Richard Berg]

And the people that want to continue using BeSweet?
Speak up now with the BeSweet features you need, to make sure they make it into the Avisynth implementation.

[Inc]

Ok, I did all the stuff. For making it not any more confusing, i took a NON-Interlaced Source (Analyse will correctly declare it as progressive), but as you can see, the aspect ratio isn't correct.

There is no DAR set at all (I could set it by hand, but this always worked automated with previous versions).


Picture after load:
http://cmw.cybton.com/afterload.png

Picture after autocrop:
http://cmw.cybton.com/aftercrop.png

Preview Picture:
http://cmw.cybton.com/preview.png

AviSynth Script:


DirectShowSource("C:\Dokumente und Einstellungen\Chaos Raven\Eigene Dateien\Eigene Videos\Du bist Deutschland.avi",fps=25,audio=false)
#blank deinterlace line
crop(2,30,-2,-32)
LanczosResize(352,240)
#denoise


Tricky,
based on that you did everything correct, .... to me this clearly shows that you did import in MeGUI a captured video where the source gots 352x240.

"Du bist Deutschland" is a german commercial. So you did take a ntsc VCD resolution for capturing? Why? Well, back to the point.
352x240 is a std. NTSC resolution.
In such a case where common std. resolutions are beeing imported into MeGui, internally it should recognise that one as a source with PAR 4320/4739 as its common 352x240 ntsc.
You do crop 30 at top, 2 at left, 2 at rigth and 32 at the bottom, thus you do end up in 348x178. which gots a DAR of ... 348*(4320/4739):178 = 317:178
Forcing that to be resized to 320 will result in a height of 320/(317/178) = 180

Lets see ... that one brought to 320x180 (MODx not taken into account).

http://img465.imageshack.us/img465/9631/unbenannt21bq.jpg (http://imageshack.us)

So as 320x180 isnt Mod16, just finally use 320x176 and do enter in the encoder the DAR of 317:178 or a PAR of 176:180. ( MOD16Height/TrueHeight ... so the width finally will de shrinked to its correct display state)


@ Richard
So I do think it doesnt base on what of the image has been cropped but whats the input itself?
And if cmw did everything ok, then MeGUI should take that case into account.

[Richard Berg]

I'm not sure which way MeGUI does it -- I've never used the Avisynth editor -- but I know you can't tell it whether you're making a "black bars crop" or a "content crop," so it's certain to get one of the two wrong.

[Doom9]

@cmw: thanks for promptly posting these screenshots. Actually, unless the source is a d2v, we have no way of knowing the DAR.. so we should assume 1:1 DAR. That should do the trick for you.
In cases where we have an input DAR, it is what should be (and is considered to make the PAR calculations). But the bottom line is that if it's 4:3, you should resize down to the proper resolution and use a 1:1 PAR, if the source has a 1:1 DAR (source != d2v.. we don't take input flag into accounts, and via directshowsource the ds filter will stretch a video that has a container or bitstream par), it's 1:1 PAR for you as well. The only scenario where you can opt not to go for a 1:1 PAR is if the input is a 16:9 D2V source (from a DVD of course since HDTV once again uses 1:1 DAR).

[max-holz]

Speak up now with the BeSweet features you need, to make sure they make it into the Avisynth implementation.

Simply I want to continue to use BeSweet and not Avisynth for audio. I want that the app gives a choice as now

[Doom9]

Simply I want to continue to use BeSweet and not Avisynth for audio. I want that the app gives a choice as nowWell.. that's where open source helps you. Create a fork..
As Richard pointed out, we're receptive towards objective reasons why you're currently using BeSweet.. but "because I've always used it" doesn't count as it's highly subjective. I actually find myself in the same boat as many.. I've never encoded audio via AviSynth so I'm a little wary too (and that's the main reason BeSweet support is still in). But at the point where I become convinced that we're not incurring any additional problems and have personally assured myself that encoding via AviSynth works properly, in the end it comes down to code management.. one encoding path is easier to manage than two, and avisynth gives flexibility to do things that we can't do with BeSweet. The day I add the video cutter, I'm not willing to write workarounds that stop you from using it because you want to use besweet for audio encoding, or worse, mess around with existing ac3/dts/mpa cutters that will always result in suboptional results.

[Inc]

but I know you can't tell it whether you're making a "black bars crop" or a "content crop," so it's certain to get one of the two wrong
Depending on that I do catch up your thought well .....
That is imho not importand where things will be cropped. They're just pixels.
But what counts is a correct source detection.
And here we can archive that using a simple way:

Do use some constants in MeGUIs code for comparing with the source sizes:

for example like done in GripFit (I know we are not in the development thread) ...

.....
if(source.fps >= 24.6 && source.fps <= 25.4)
return PAL;
else if(source.fps >= 23.7 && source.fps <= 24.3)
return NTSC_P;
else if(source.fps >= 29.7 && source.fps <= 30.3)
return NTSC_I;
else
return 0; // Unknown (maybe QT? or whatever)

.....
..
...


if(NTSC_P == standard || NTSC_I == standard)
{
if(720 == w && 480 == h)
return 72.0 / 79.0; // .... 4320/4739 would be correct but we need a smaller fraction
else if(704 == w && 480 == h)
return 72.0 / 79.0;
else if(544 == w && 480 == h)
return (72.0 / 79.0) / (3.0 / 4.0);
else if(528 == w && 480 == h)
return ((72.0 / 79.0) / (3.0 / 4.0))*(544 / 528); // ... same µs like 544!
else if(480 == w && 480 == h)
return 108.0 / 79.0;
else if(352 == w && 480 == h)
return 144.0 / 79.0;
else if(352 == w && 240 == h)
return 72.0 / 79.0;
} else if(PAL == standard)
{
if(720 == w && 576 == h) // DVD
return 128.0 / 117.0;
else if(704 == w && 576 == h)
return 128.0 / 117.0;
else if(544 == w && 576 == h)
return (128.0 / 117.0) / 0.75;
else if(528 == w && 576 == h)
return ((128.0 / 117.0) / 0.75)*(544 / 528);
else if(480 == w && 576 == h)
return 128.0 / 78.0;
else if(352 == w && 576 == h) // 1/2 D1
return 256.0 / 117.0;
else if(352 == w && 288 == h) // VCD
return 128.0 / 117.0;
}
return 0; // from here on we do assume PAR1:1 inputs
// Or we do use Libs/dlls like Mediainfo

[Doom9]

for example like done in GripFit (I know we are not in the development thread) ...That's making the assumption that you'll never get a 1:1 DAR source having any of these resolutions.. a petty big assumption if you ask me. I prefer the handling outlined before where only d2v DARs are taken into account..the rest is rendered 1:1.

[max-holz]

Well.. that's where open source helps you. Create a fork..
As Richard pointed out, we're receptive towards objective reasons why you're currently using BeSweet.. but "because I've always used it" doesn't count as it's highly subjective. I actually find myself in the same boat as many.. I've never encoded audio via AviSynth so I'm a little wary too (and that's the main reason BeSweet support is still in). But at the point where I become convinced that we're not incurring any additional problems and have personally assured myself that encoding via AviSynth works properly, in the end it comes down to code management.. one encoding path is easier to manage than two, and avisynth gives flexibility to do things that we can't do with BeSweet. The day I add the video cutter, I'm not willing to write workarounds that stop you from using it because you want to use besweet for audio encoding, or worse, mess around with existing ac3/dts/mpa cutters that will always result in suboptional results.

ok, where can I find an exhaustive guide that teach me how to encoded audio via AviSynth?

[Doom9]

there's really nothing to learn.. it's just a single click. Instead of besweet and dlls you need some other executable and dlls.. but that's all in the guide (which you should have no trouble finding).

[Inc]

That's making the assumption that you'll never get a 1:1 DAR source having any of these resolutions.. a petty big assumption if you ask me. I prefer the handling outlined before where only d2v DARs are taken into account..the rest is rendered 1:1.

A simple "Check inputs for common mpeg1/2 resolutions" checkbox in the settings would solve that and make MeGUI for many Cappers and DVB'ers verrrrrrry verrrrry valuable. LIKE ME! :D . Sorry I'm not in C# so I would directly assist if i could.

[max-holz]

Sorry another question, the bug in the bitrate calculator is fixed?
I ask that cos I'am seeing the status form during my encoding, I tell to the bitrate calculator that I want 2 CD file size taking care of audio track that I encode separately (I don't use the autoencode button), now I see that projected filesize is 1429195. If the file will be created with this size, when I merge it with the audio track it will be more than 2 CD.I'am at 4,7% of the encoding. Perhaps the projected file size that I see in status form is very variable.

[Doom9]

DVB'ersDVB means MPEG-2 streams which in turn means DGIndex and we have the DAR from that. And if you capture analogue.. I have no quarrel not accodomating something for which I have a whole book of swearwords to describe. Oh yeah, and how many TV broadcasts are actually widescreen with a 16:9 DAR? Very few. And there's nothing wrong with resizing to playback resolution on the fly when capturing regular (4:3) shows.

[Doom9]

Sorry another question, the bug in the bitrate calculator is fixed?I remember asking you for the logfiles.. but I didn't see anything posted. For all I know.. you're doing something wrong. The log truthfully reports any bitrate recalculations it's doing. People not posting logfiles are really abusing the patience of every single developer that takes his time to help out.. some day in the future, I can assure you that we'll stop being so accomodating and strictly enforce the "no log no service" policy and only reply to reports that accomodate to the established groundrules for bug reporting (see the first post in this thread). Whatever we have to guess, derive, ask back is time we could spend to improve megui instead.

[max-holz]

I remember asking you for the logfiles.. but I didn't see anything posted. For all I know.. you're doing something wrong. The log truthfully reports any bitrate recalculations it's doing. People not posting logfiles are really abusing the patience of every single developer that takes his time to help out.. some day in the future, I can assure you that we'll stop being so accomodating and strictly enforce the "no log no service" policy and only reply to reports that accomodate to the established groundrules for bug reporting (see the first post in this thread). Whatever we have to guess, derive, ask back is time we could spend to improve megui instead.


Starting job job1-1 at 23.13.34
Job is a video job. encoder commandline:
--pass 1 --bitrate 1605 --stats "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.stats" --bframes 3 --b-pyramid --filter -2,-1 --subme 1 --analyse none --me dia --threads 2 --progress --no-psnr --output NUL "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.avs"
successfully started encoding
Processing ended at 19.53.15
----------------------------------------------------------------------------------------------------------

Log for job job1-1

avis [info]: 640x336 @ 25.00 fps (169725 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:833 Avg QP:14.32 size: 34149
x264 [info]: slice P:61646 Avg QP:16.29 size: 13621
x264 [info]: slice B:107246 Avg QP:18.00 size: 4520
x264 [info]: mb I I16..4: 18.3% 0.0% 81.7%
x264 [info]: mb P I16..4: 18.1% 0.0% 0.0% P16..4: 78.1% 0.0% 0.0% 0.0% 0.0% skip: 3.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 62.8% 0.0% 0.0% direct:19.0% skip:17.0%
x264 [info]: final ratefactor: 17.10
x264 [info]: kb/s:1594.3

Actual bitrate after encoding without container overhead: 1595.30

----------------------------------------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Starting job job1-2 at 19.53.16
Job is a video job. encoder commandline:
--pass 2 --bitrate 1605 --stats "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 7 --trellis 1 --analyse all --8x8dct --me umh --threads 2 --progress --no-psnr --output "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.mkv" "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.avs"
successfully started encoding

[Doom9]

uhh.. that's not the log. You hinted something about audio size being taken into account.. that means auto-encode or one click.. in both cases, the log would contains more information.. lines that mention desired target size, audio size, what the bitrate was set to in function of audio size.. the likes.

Here's an example (that you get even before encoding even starts):

Generating jobs. Desired size: 20971520 bytes
Encoded audio file is present: D:\DVDs\DVDVolume\VIDEO_TS\trailer-audio.aac It has a size of 2240358 bytes.
No audio encoding. Calculating desired video bitrate directly.
Setting video bitrate for the video jobs to 1041 kbit/s
Setting desired size of video to 18731008 bytes

[max-holz]

uhh.. that's not the log. You hinted something about audio size being taken into account.. that means auto-encode or one click.. in both cases, the log would contains more information.. lines that mention desired target size, audio size, what the bitrate was set to in function of audio size.. the likes.

Here's an example (that you get even before encoding even starts):

NO I don't explain myself. I have encoded audio separately then in bitrate calculator I select this audio file to tell to the program to take in account is size in bitrate calculation. Audio is 100 MB so why projected filesize tells 1423839. I don't use auto-encode or one click.

[Doom9]

Audio is 100 MB so why projected filesize tells 1423839.Argh, how on earth would I know without knowing what you set the target size to, what container you're using and what codec, the length of your video source and the framerate.. those are all factors that influence the calculations (I wrote them.. I should know). But if I configure an audio track in MP4/x264 mode, then the target video size changes in function of the size of the audio track.. as it should.

@edit: even in the debugger.. pressing apply writes the bitrate to where it should.

[Inc]

I tried out MeGUI xvid encoding via xvid_encraw (xvid_encraw-build-20-01-2006).

Seems MeGUI does generate a non supported cmd line.

The log:
Starting job job1-1 at 23:14:03
Job is a video job. encoder commandline:
-i "D:\testscript.avs" -single -bitrate 1000000 -custom_par 35 24 -max_key_interval 300 -vhqmode 1 -closed_gop -max_bframes 2 -o "D:\testscript.m4v"
successfully started encoding
Processing ended at 23:14:04
----------------------------------------------------------------------------------------------------------

Log for job job1-1

xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Error: Unrecognized commandline parameter detected.

I did search for the guilty and it seems that:

a) "-closed_gop" seems that it does not exist anymore as its now default? and can be switched off by "-noclosed_gop".
b) "-custom_par xx yy" also seems that it has changed to "-par <integer>" where the integer value stands for:
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
No other custom par supported.



Sorry in advance if maybe this has been already reported before.

[Doom9]

uhh.. as already written in the German forum... megui supports encraw CVS build, not squid's derivation thereof. I'm hoping that eventually the thing will be feature complete and integrated into the CVS..for now I'm sitting that out. As for the par.. seems I forgot to remove some lines in the copy/paste.. the CVS build has no par support (and I really don't get the current fixation on PARs.. it's a cheap hack for our limited SDTVs.. when will all that crap from the analogue world finally die out for good? I have a couple cuban cigars ready for that moment (I'm a non smoker but such an awsome step for video would warrant some celebration).

[Richard Berg]

Even if you're not someone who uses PAR to save bitrate like me, it'll still be necessary if everyone has widescreen TVs. Movies are usually either 1.85:1 or 2.35:1, neither of which is exactly 16:9. And of course all the old 4:3 content should be encoded anamorphically to maximize quality on 16:9 displays, just like we do in reverse today.

[cmw]

Thank you very much for the detailed explanation, that quite clarifies this issue.

However, I'm still experiencing the problem that deinterlace analysis won't work, as well as the non function NAAC.

Tell me whatever additional information you need, expect that I followed the Guide line by line and even tried older version of the dll's, with no effect at all. The sound wouldn't be that important, I can use FAAC, but for the deinterlacing, it would be quite good if that worked somehow.^^

The above mentioned problem with deinterlacing appears on d2v source btw (atm I don't have an interlaced avi source to test with).

best regards cmw

[berrinam]

@cmw: You say the interlacing error appears with a d2v source as well, but earlier you said that it works with DVDs. What is your d2v source, then? Can you tell me exactly what does work and doesn't?

1. What is your OS?
2. What version of AviSynth?

@dimzon: Could you take a look at cmw's NAAC problem? I'm really not aware of audio encoding in MeGUI.

[Doom9]

And of course all the old 4:3 content should be encoded anamorphically to maximize quality on 16:9 displays, just like we do in reverse today.I still recall very well the test bond performed on that issue. The bottom line is that anamorphic encoding only makes sense when you have a 16:9 source that you just crop. If you start to resize (which would be needed for 4:3 content), then you no longer gain anything and upsizing a 4:3 encode, for me that's heresy. Go teach the people that created such content the importance of 16:9. Or just tell them to stop using SDTV and the problem will go away by itself.

[Inc]

Thank you very much for the detailed explanation, that quite clarifies this issue.

So if you go into MeGUI using captures, do capture in 1:1 then, means ...

PAL : 768x576 or 384x288
NTSC: 640x480 or 320x288

[Inc]

The bottom line is that anamorphic encoding only makes sense when you have a 16:9 source that you just crop. If you start to resize (which would be needed for 4:3 content), then you no longer gain anything and upsizing a 4:3 encode, for me that's heresy.

Or ... if upsizing quality doesnt matter, do encode the 4:3 content kept as 4:3 and do apply a zoom on the 16:9 TV Set via its remotecontrol. So its your decision if you want to see the 'whole' 4:3 proportion/content incl black bars on the sides or if you want to zoom via the TV Device hardware.
On letterboxed 16:9 sources fittet into 4:3 there sometimes that cropping/re-anamorphing makes sense if the source is very good (some HighBitrate DVB streams) and if a good detailenhancing via avs is applied (see Didées Voyager examples in the iip thread).

And if not playing back via a HTPC, then for shure you gotta have a mp4 kompatible SAP which ALSO supports PAR/SAR or DAR flags. The well known common Xoro HSD 4000 doesnt support that imho.

[dimzon]

non function NAAC.
I need additional details. Which Dll's are @ neroraw.exe folder. Wich versions? Where does you get them?

[Doom9]

Alright, I did a nero7 test as well and it fails here as well.

Log:
Starting job job4 at 11:20:43
Job is an audio job. Commandline:
-core( -input "D:\DVDs\DVDVolume\VIDEO_TS\residentevil AC3 T01 3_2ch 448Kbps DELAY 0ms.ac3" -output "D:\DVDs\DVDVolume\VIDEO_TS\residentevil AC3 T01 3_2ch 448Kbps DELAY 0ms3.mp4" -logfile "D:\DVDs\DVDVolume\VIDEO_TS\residentevil AC3 T01 3_2ch 448Kbps DELAY 0ms3.besweet.log" ) -azid( -cbr 160 ) -ota( -g max )
successfully started encoding
Processing ended at 11:23:21
----------------------------------------------------------------------------------------------------------

Log for job job4

Channels=2, BitsPerSample=16, SampleRate=48000Hz
C:\temp\neroraw\neroraw.exe -o "D:\DVDs\DVDVolume\VIDEO_TS\residentevil AC3 T01 3_2ch 448Kbps DELAY 0ms3.mp4" -rr 48000 -rb 16 -rc 2 -cbr 160 Error:
System.ApplicationException: Abnormal encoder termination -1
at MeGUI.AviSynthAudioEncoder.encode() in D:\MeGUI\MeGUI-src.CVS\AviSynthAudioEncoder.cs:line 310System.ApplicationException: Error configuring bsn 1
at MeGUI.NeroRawAacEncoder.Main(String[] args)


----------------------------------------------------------------------------------------------------------
The current job contains errors. Skipping chained jobs
Starting job job5 at 11:23:56
Job is an audio job. Commandline:
-core( -input "D:\DVDs\DVDVolume\VIDEO_TS\trailer-audio.ac3" -output "D:\DVDs\DVDVolume\VIDEO_TS\trailer-audio3.mp4" -logfile "D:\DVDs\DVDVolume\VIDEO_TS\trailer-audio3.besweet.log" ) -azid( -cbr 128 ) -ota( -g max )
successfully started encoding
Processing ended at 11:24:00
----------------------------------------------------------------------------------------------------------

Log for job job5

Channels=6, BitsPerSample=16, SampleRate=48000Hz
C:\temp\neroraw\neroraw.exe -o "D:\DVDs\DVDVolume\VIDEO_TS\trailer-audio3.mp4" -rr 48000 -rb 16 -rc 6 -cbr 128 Error:
System.ApplicationException: Abnormal encoder termination -1
at MeGUI.AviSynthAudioEncoder.encode() in D:\MeGUI\MeGUI-src.CVS\AviSynthAudioEncoder.cs:line 310System.ApplicationException: Error configuring bsn 1
at MeGUI.NeroRawAacEncoder.Main(String[] args)


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

Note that the problems start right there.. I'm not sure what the channel report is.. in the first case, as the filename indicates, this is a 5.1 AC3 that I'm downmixing to 2.0. In the second case, the source is reported as 5.1 which is just plain wrong.. this is a 2.0 trailer audio.

Neroraw.exe: latest CVS build (0.0.2.1 - works fine when using the Nero6 dlls (AAC.dll version 2.5.9.97, aacenc32.dll version 2.9.9.998).
DLLs:
AAC.dll version 3.0.0.3 from Nero 7.0.1.2
aacenc32.dll version 4.2.1.0 also from Nero 7.0.1.2
bsn.dll - downloaded from where the guide points to (and as I mentioned, it works with the nero6 dlls).
Needless to say my Nero DLLs come from my own licensed installation and that I unchecked the "I'm using Nero6" checkbox when I did the Nero7 tests.

On letterboxed 16:9 sources fittet into 4:3 there sometimes that cropping/re-anamorphing makes sense if the source is very goodBut this would imply that you're not using the avisynth script creator but loading your own script.. and thus, you'd also be in charge of your own cropping and resizing as well as finding the proper PAR values.

[dimzon]

Note that the problems start right there.. I'm not sure what the channel report is.. in the first case, as the filename indicates, this is a 5.1 AC3 that I'm downmixing to 2.0. In the second case, the source is reported as 5.1 which is just plain wrong.. this is a 2.0 trailer audio.
Don't look @ job command line - I do not touch this code at all, it still produce BeSweet command line, this is a cosmetic bug...

Channels=2, BitsPerSample=16, SampleRate=48000Hz
This is actual information, provided by AviSyhth. Maybe you are checked "Upmix Stereo to 5.1" ?


Neroraw.exe: latest CVS build (0.0.2.1 - works fine when using the Nero6 dlls (AAC.dll version 2.5.9.97, aacenc32.dll version 2.9.9.998).
DLLs:
AAC.dll version 3.0.0.3 from Nero 7.0.1.2
aacenc32.dll version 4.2.1.0 also from Nero 7.0.1.2
bsn.dll - downloaded from where the guide points to (and as I mentioned, it works with the nero6 dlls).

There are error @ installation guide:
You need at least NeroIPP.dll in same folder ;)
AFAIK some concrete Dll version can also reque something like MFC71.dll OR something like libmmd.dll

[Doom9]

This is actual information, provided by AviSyhth. Maybe you are checked "Upmix Stereo to 5.1" ?No, but I'm afraid I misread the info file.. the track is actually 5.1.

You need at least NeroIPP.dll in same folder I'm afraid that's not correct. It required MFC71.dll, and nothing else.

[nurbs]

There are error @ installation guide:
You need at least NeroIPP.dll in same folder ;)
AFAIK some concrete Dll version can also reque something like MFC71.dll OR something like libmmd.dll

I was just about to post a report when I read this. I copied the NeroIPP.dll and the MFC71.dll and it works now. The error message I got before was diffrent form doom9's.

If anyone is still interested:
Log for job job1

Channels=2, BitsPerSample=16, SampleRate=48000Hz
D:\Temp\Video\MeGUI\neroraw.exe -o "C:\FUTURAMA_DISC_2\VIDEO_TS\VTS_01_1 T01 2_0ch 192Kbps DELAY -15ms.mp4" -rr 48000 -rb 16 -rc 2 -cbr 128 Error:
System.IO.IOException: Die Pipe wurde beendet.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
at MeGUI.AviSynthAudioEncoder.encode()System.DllNotFoundException: Unable to load DLL 'bsn.dll': Das angegebene Modul wurde nicht gefunden. (Exception from HRESULT: 0x8007007E)
at MeGUI.NeroRawAacEncoder.BSN_Init(Int32& nSampleRate, Int32 nChannelsCount, String sOutFileName, Int32 nBitsPerSample, Int32 nShowDialog, String path, String[] argv, Int32 argc)
at MeGUI.NeroRawAacEncoder.Main(String[] args)

[berrinam]

I'm afraid that's not correct. It required MFC71.dll, and nothing else.So that I can update the guide, does this mean MFC71.dll in the same directory as neroraw.exe, or what? Where can people get MFC71.dll from?

[dimzon]

I'm afraid that's not correct. It required MFC71.dll, and nothing else.
No, I'm correct ;)
Actually it need NeroIPP.dll (just open aacenc32.dll in hexeditor and search for NeroIPP.dll)
But You have Nero7 installed, it means NeroIPP.dll placed @ folder included in PATH variable OR/AND aacenc32 perform direct LoadLibrary using path obtained via registry information. There are such line in aacenc32.dll
%s\%s NeroIPP.dll %s;%s PATH aacenc32.dll Lib SOFTWARE\Ahead\Shared

[dimzon]

So that I can update the guide, does this mean MFC71.dll in the same directory as neroraw.exe, or what? Where can people get MFC71.dll from?
It must be in neroraw.exe folder OR in folder included in path variable (like Windows\System32)
MFC71.Dll is standart library (it's Microsoft Foundation Classes)
http://www.google.ru/search?q=MFC71.dll
If You have Nero7 installed just serch it on your HDD. If you does not have Nero7 installed try to serch it on your HDD too (another application can install it - it's standart MFC runtime). Or you can download it (use google to find it).

[Doom9]

NeroIPP.dll is not in my path. So perhaps it works via the registry, but then you can safely assume that it will work like that for everybody since you can only use the Nero DLLs if you have a proper installation with registration.
I already updated the guide by the way, it points out the path of the mfc dll and where you must copy it to.

[dimzon]

since you can only use the Nero DLLs if you have a proper installation with registration
This can be illegal, but copyng NeroIPP.dll in neroraw folder allows You to use it without installation/registration at all ;)
In other case You can by Nero7 licence but does not want to intstall it on your encoding machine. In this case, I believe, this approach is legal ;)

ADD:
This approach allows You to use different AAC Encoder versions side by side, I like it!

[Doom9]

This approach allows You to use different AAC Encoder versions side by side, I like it!Actually, all it takes me is copying some dlls (which I could automate via batch file) so switch between Nero 6 and Nero7. You don't need to have both installed (in fact it's not even possible).. and anything that may allow to circumvent the license check has no place in a guide.

[Inc]

uhh.. as already written in the German forum... megui supports encraw CVS build, not squid's derivation thereof. I'm hoping that eventually the thing will be feature complete and integrated into the CVS..for now I'm sitting that out. As for the par.. seems I forgot to remove some lines in the copy/paste.. the CVS build has no par support (and I really don't get the current fixation on PARs.

I did build xvid_encraw.exe using MinGW and VisualStudio C++ out of the CVS 1.1.0 Sources on a G5 Mac under the VirtualPC environment using Win2000. No linking errors so far, I hope it works.

Input options:
-i string : input filename (default=stdin)
-type integer: input data type (yuv=0, pgm=1, avi/avs=2)
-w integer: frame width ([1.2048])
-h integer: frame height ([1.2048])
-frames integer: number of frames to encode

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string: save an Elementary Stream for the complete sequence

BFrames options:
-max_bframes integer: max bframes (default=0)
-bquant_ratio integer: bframe quantizer ratio (default=150)
-bquant_offset integer: bframe quantizer offset (default=100)

Rate control options:
-framerate float : target framerate (>0 | default=25.0)
-bitrate integer : target bitrate
-single : single pass mode
-pass1 filename : twopass mode (first pass)
-pass2 filename : twopass mode (2nd pass)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-max_key_interval integer : maximum keyframe interval

Other options
-noasm : do not use assembly optmized code
-turbo : use turbo presets for higher encoding speed
-quality integer : quality ([0..6])
-vhqmode integer : level of Rate-Distortion optimizations ([0..4]) (default=0)
-bvhq : use Rate-Distortion optimizations for B-frames too
-qpel : use quarter pixel ME
-gmc : use global motion compensation
-qtype integer : quantization type (H263:0, MPEG4:1) (default=0)
-qmatrix filename: use custom MPEG4 quantization matrix
-interlaced : use interlaced encoding (this is NOT a deinterlacer!)
-packed : packed mode
-closed_gop : closed GOP mode
-grey : grey scale coding (chroma is discarded)
-lumimasking : use lumimasking algorithm
-stats : print stats about encoded frames
-debug : activates xvidcore internal debugging output
-vop_debug : print some info directly into encoded frames
-help : prints this help message

NB: You can define 64 zones repeating the -z[qw] option as many times as needed.

So as you said no PAR support in the CVS based compile, and -closed_gop is available, so this one should work well with MeGUI if I understood right.

[max-holz]

Argh, how on earth would I know without knowing what you set the target size to, what container you're using and what codec, the length of your video source and the framerate.. those are all factors that influence the calculations (I wrote them.. I should know). But if I configure an audio track in MP4/x264 mode, then the target video size changes in function of the size of the audio track.. as it should.

@edit: even in the debugger.. pressing apply writes the bitrate to where it should.

Hi Doom9. Finally I have a log for bitrate problem :)


Generating jobs. Desired size: 1468006400 bytes
Encoded audio file is present: C:\Scambio\Elaborazione Video\PortiereDiNotte\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 0ms.AC3 It has a size of 380183552 bytes.
No audio encoding. Calculating desired video bitrate directly.
Setting video bitrate for the video jobs to 1278 kbit/s
Setting desired size of video to 1085119488 bytes
Generating jobs. Desired size: 1468006400 bytes
Setting desired size of video to 1468006400 bytes
Starting job job1-1 at 1.04.50
Job is an audio job. Commandline:
-core( -input "C:\Scambio\Elaborazione Video\PortiereDiNotte\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 0ms.AC3" -output "C:\Scambio\Elaborazione Video\PortiereDiNotte\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 0ms.mp4" -logfile "C:\Scambio\Elaborazione Video\PortiereDiNotte\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 0ms.besweet.log" ) -azid( -s stereo -c normal -L -3db ) -bsn( -2ch -vbr_transcoding -codecquality_high -aacprofile_he ) -ota( -g max )
successfully started encoding
Processing ended at 1.30.00
----------------------------------------------------------------------------------------------------------

Log for job job1-1

BeSweet v1.5b31 by DSPguru.
--------------------------

[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...

[01:53:08:992] |

[01:53:08:992] Finalizing...
[01:53:08:992] Conversion Completed !

Visit DSPguru's Homepage at :
http://DSPguru.doom9.net/
SR: 48000, Table idx: 6 - start 12, stop 9
N_Q: 2, usb 45, lsb 22, num noise: 2
SR: 48000, Table idx: 6 - start 12, stop 9
N_Q: 2, usb 45, lsb 22, num noise: 2

----------------------------------------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
this series of jobs starts with an audio job and is followed by regular twopass video jobs
The audio job is named job1-1 the first pass job1-2 and the second pass job1-3
The second pass job has a desired final output size of 1468006400 bytes and video bitrate of 1605 kbit/s
The size of the first audio track is 100827479 bytes
Desired video size after substracting audio size is 1331608Setting the desired bitrate of the subsequent video jobs to 1606 kbit/s
Starting job job1-2 at 1.30.00
Job is a video job. encoder commandline:
--pass 1 --bitrate 1606 --stats "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.stats" --bframes 3 --b-pyramid --filter -2,-1 --subme 1 --analyse none --me dia --threads 2 --progress --no-psnr --output NUL "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.avs"
successfully started encoding
Processing ended at 23.37.17
----------------------------------------------------------------------------------------------------------

Log for job job1-2

avis [info]: 640x336 @ 25.00 fps (169725 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:832 Avg QP:14.31 size: 34149
x264 [info]: slice P:61644 Avg QP:16.29 size: 13629
x264 [info]: slice B:107249 Avg QP:18.00 size: 4524
x264 [info]: mb I I16..4: 18.3% 0.0% 81.7%
x264 [info]: mb P I16..4: 18.1% 0.0% 0.0% P16..4: 78.1% 0.0% 0.0% 0.0% 0.0% skip: 3.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 62.8% 0.0% 0.0% direct:19.0% skip:17.0%
x264 [info]: final ratefactor: 17.10
x264 [info]: kb/s:1595.2

Actual bitrate after encoding without container overhead: 1596.28

----------------------------------------------------------------------------------------------------------
job job1-2 has been processed. This job is linked to the next job: job1-3
Starting job job1-3 at 23.37.18
Job is a video job. encoder commandline:
--pass 2 --bitrate 1606 --stats "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 7 --trellis 1 --analyse all --8x8dct --me umh --threads 2 --progress --no-psnr --output "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.mkv" "C:\Scambio\Elaborazione Video\PortiereDiNotte\Portiere.avs"
successfully started encoding


I have highlighted in red where there is an error for me; Setting 2 CD size the bitrate is settled to 1605 kbit/s; when the audio size is substracted the bitrate recalculation gives 1606 kbit/s. It's more than before adding audio track. MeGUI version is 2062.

[Doom9]

I have highlighted in red where there is an error for me;Actually.. the log of the entire thing would be interesting.. don't just pick out one little thing and say it's wrong.. it needs context. 1605 kbit/s is the bitrate the autoencocode mode precalculated prior to audio encoding (it shows something very weird at the beginning that warrants investigation, but it looks like it only shows the wrong info but does the right thing.. )

After audio encoding, the app still knows your correct target size. The bitrate shown in your first red line is an approximation, not a calculated value.. it is thus irrelevant for us. The only thing that matters is target size. As you can see, the audio size is properly substracted from the target size, and based on that, and your output target type (which I can't see because I don't have the log for all jobs of this series of jobs), the bitrate is then recalculated and it comes down to 1606 kbit/s.. that's taking desired target size, container and actually encoded audio into account. Forget the 1605.. it has no relevance in this case (in fact I don't even know why I'm putting this into the log).

And by the way, the size difference of 1606 versus 1605 kbit/s is 828 KB ..;)

[max-holz]

Actually.. the log of the entire thing would be interesting.. don't just pick out one little thing and say it's wrong.. it needs context. 1605 kbit/s is the bitrate the autoencocode mode precalculated prior to audio encoding (it shows something very weird at the beginning that warrants investigation, but it looks like it only shows the wrong info but does the right thing.. )

After audio encoding, the app still knows your correct target size. The bitrate shown in your first red line is an approximation, not a calculated value.. it is thus irrelevant for us. The only thing that matters is target size. As you can see, the audio size is properly substracted from the target size, and based on that, and your output target type (which I can't see because I don't have the log for all jobs of this series of jobs), the bitrate is then recalculated and it comes down to 1606 kbit/s.. that's taking desired target size, container and actually encoded audio into account. Forget the 1605.. it has no relevance in this case (in fact I don't even know why I'm putting this into the log).

And by the way, the size difference of 1606 versus 1605 kbit/s is 828 KB ..;)

But I'am actually doing the second pass, it's at 24,6% and the video size is at 354960 KB. By the way of this fact I can presume that the final output probably will not be correct.

[berrinam]

But I'am actually doing the second pass, it's at 24,6% and the video size is at 354960 KB. By the way of this fact I can presume that the final output probably will not be correct.
I don't see what your problem is:
-you are targetting 1400MBs
-you are 1/4 of the way through your encode, and you have roughly 1/4 of 1400MBs already (1400 / 4 = 350MB = 358400KB).

What's the problem?