MeGUI: bug reports and feature requests

[invy]

I guess I'll wait then. No problem.

[Zathor]

I guess I'll wait then.
It is now available.

2303 [AVS Script Creator] removed cropping limit

[hello_hello]

Would there be a chance the default behaviour could be changed when right clicking on a job in the queue and selecting "run in new temporary worker"?
Currently if the job status is "postponed" or "aborted", MeGUI complains about there being no jobs waiting to be processed, forcing you to change the job's status before you can run it, but given I've right clicked on the job and selected to run it in a new temporary worker, the chances are pretty good that's what I want to do...... regardless of the job's status.

And I've mentioned this before, but I thought of a different way to approach it....
Being forced to add a job to the queue before you can run it drives me a little nutty (I know MeGUI has an auto-start option but I don't want to auto-start jobs based on whether another is already running in the Queue), so could the behaviour of the various Queue buttons be changed a little, so a left click adds the job to the Queue as normal, but Shift+ left click (or something similar) adds the job to the queue AND automatically runs it in a temporary new worker?
As simple example, indexing a video requires adding the indexing job to the Queue, switching to the MeGUI window if need be, then selecting the Queue tab, then clicking on the Start button, whereas the same thing could be achieved with a Shift + left click on the Queue button in the file indexing window.

Thanks.

[Overdrive80]

Hi Zathor, I add this ticket in megui page https://sourceforge.net/p/megui/feature-requests/499/

Thanks in advance.

[AMED]

@Overdrive80,

Is there any particular reason to need Wav output? can you not use FLAC instead?

[Overdrive80]

@Overdrive80,

Is there any particular reason to need Wav output? can you not use FLAC instead?

If I need edit, for example flac file in Premiere, its not supported. My ticket is for wav format but anything lossless format is valid (for example aiff) but supported by more soft in general.

Edit: Flac doesnt support bitdetph of 32 bit.

[tebasuna51]

AviSinth output is already a wav file with bitdepth 6/16/24/32 int or 32 float we need only write the file instead send to a encoder.

The output from some decoders (NicAudio and BassAudio) is 32 float but there are AviSynth functions to select the desired bitdepth output.

Take in mind than big wav files (more than 2 or 4 GB) can't be recognized by some soft, then we need output W64 or RF64 instead WAV.

You can use BeHappy to obtain your desired output.
Of course Zathor can use BeHappy code to add this option to MeGUI.

[Zathor]

2306 [MP4 Muxer] cosmetic - "disable" instead of "disabled" parameter
2305 [AVS Script Creator] fixed "TDeint (with EDI + BOB)"
2304 [AVS Script Creator] fixed recreating the index file during "Analyse" if using FFMS with a non-default index file location

[kalehrl]

This morning I indexed Formula1 race which is 704x576 16:9 MPEG2 capture.
The cropping values are 2 pixels bottom and 2 top.
The script creator offered some strange values when I chose different mod values.
Yoda calculator tells me to resize to 704x402, mod2 with the least aspect error.
The script creator offered 704x394 when I chose mod2 which can't be right.
The MeGUI is the latest development version.
Also, when I pressed save avisynth script, resize values were not saved so I had to do that manually.

[Zathor]

This morning I indexed Formula1 race which is 704x576 16:9 MPEG2 capture.
The cropping values are 2 pixels bottom and 2 top.
The script creator offered some strange values when I chose different mod values.
Yoda calculator tells me to resize to 704x402, mod2 with the least aspect error.
The script creator offered 704x394 when I chose mod2 which can't be right.
704x394 is correct for 16:9 and I just verified that using a AVS file with this resolution and AR.
Are you able to provide at least a screenshot with your "Input DAR" value? Better would be a part of the input file together with steps to reproduce this.

Also, when I pressed save avisynth script, resize values were not saved so I had to do that manually.
Works for me as well. Please also provide the steps.

[kalehrl]

I've been doing the Formula1 captures from the same channel last year and never once did I get vertical resolution below 400:
http://i46.tinypic.com/wti0jp.png
Second screenshot:
http://tinypic.com/view.php?pic=33bl62o&s=6
Yoda and MeGUI don't agree.
I don't use ITU-R.
Here is a sample:
https://mega.co.nz/#!RlpCgC6R!HBQB2RUBjn1yFl1maiGmnyjqPFZZDycIOZvs8CNbDHM

[Shevek]

704x394 is correct for 16:9

Am I missing something?

This is how I calculate: 704 / 16 * 9 = 396

[Zathor]

Am I missing something?
This is how I calculate: 704 / 16 * 9 = 396
Correct! For 704x576 with 16:9 you have 704x396 with 1:1.
But this source uses cropping (2 top, 2 bottom) and therefore it is 704x394.


Yoda and MeGUI don't agree.

They both agree if you choose the same AR on both sides:
http://img221.imageshack.us/img221/6269/yodaz.png

[kalehrl]

They both agree if you choose the same AR on both sides:
If I check the custom dar coefficients they're the same.
But I don't understand why it is not enough to just choose 'pal 16:9'? Why the need for custom dar?

[Zathor]

Pal 16:9 seems to be a different DAR than 16:9. Don't know what is beeing used at all.

[LigH]

The preset "Pal 16:9" in Yoda's calculator is probably not an "irrespective"* DAR, but an SAR instead?!

The reported input SAR is ~1.75:1, which seems to assume that skewed 720 pixels width are deskewed 1024 pixels width (1024:576 = 16:9).
__

"Irrespective" in the meaning of MPEG2 = ISO/IEC 13818-2: No matter which width (352, 480, 544, 704, 720,... : 576 pixels as PAL) is encoded, it has to be deskewed to a DAR of 16:9 for displaying (576 * 16 : 9 = 1024).

[Zathor]

Small update:
2308 [AVS Script Creator] added detailed analysis result to the log
2307 [AVS Script Creator] fixed not applying film when manually choosing "Partially film"

[kalehrl]

The preset "Pal 16:9" in Yoda's calculator is probably not an "irrespective"* DAR, but an SAR instead?!

The reported input SAR is ~1.75:1, which seems to assume that skewed 720 pixels width are deskewed 1024 pixels width (1024:576 = 16:9).
__

"Irrespective" in the meaning of MPEG2 = ISO/IEC 13818-2: No matter which width (352, 480, 544, 704, 720,... : 576 pixels as PAL) is encoded, it has to be deskewed to a DAR of 16:9 for displaying (576 * 16 : 9 = 1024).
I still think Yoda is right and MeGUI is wrong.
My source is 704x576 not 720x576.
If I choose Pal 16:9 (720x576), crop 2 pixels top and 2 bottom, uncheck ITU-R, move the slider to 704 width and use mod2, I get 704x394 - exactly the same as MeGUI.
If I choose Pal 16:9 (but this time choose 704x576), crop 2 pixels top and 2 bottom, uncheck ITU-R, move the slider to 704 width and use mod2, I get 704x402.
I think MeGUI wrongly assumes that all 16:9 PAL recordings are 720x576.

[hello_hello]

Yoda makes the 720x576 assumption, as best as I can tell. Without cropping....

Choose 720x576 and Yoda displays the source aspect ratio as 1.77777 and the resize as 704x396.
Choose 704x576 and Yoda displays the source aspect ratio as 1.73827 and the resize as 704x404.
If you choose 704x576 you have to physically tell it to use a custom aspect ratio of 16:9 in order for it to display the source aspect ratio as 1.77777 and resize it to 704x396.

I couldn't download your sample for some reason (the download kept stopping) but MeGUI works the same way. You could open a video with a resolution of 800x350 and if you physically select 16:9 as the input aspect ratio, the resize will still be 704x396. It sounds like MeGUI might be getting the 704x576 aspect ratio correct at 16:9, but for Yoda you need to tell it you want 704x576 to be 16:9.

[hello_hello]

Another way to look at it....
If you select 720x576 using Yoda, the source aspect ratio is displayed as 1.77777 (non ITU).
704x576 shows a source aspect ratio of 1.73827
Now go back to 720x576 again but crop 16 pixels from a side. The display aspect ratio is once again 1.73827.

Yoda has treated the 720x576 video as 16:9, but to Yoda, 704x576 is exactly the same as 720x576 with 16 pixels cropped from the sides, which obviously isn't 16:9 any more. Therefore if you want Yoda to treat 704x576 as 16:9, you need to use a custom display aspect ratio and tell it to.

[Zathor]

I think MeGUI wrongly assumes that all 16:9 PAL recordings are 720x576.
No, it does not assume that. As you can see your source is detected as plain 16:9.

[kalehrl]

Yoda makes the 720x576 assumption, as best as I can tell. Without cropping....

Choose 720x576 and Yoda displays the source aspect ratio as 1.77777 and the resize as 704x396.
Choose 704x576 and Yoda displays the source aspect ratio as 1.73827 and the resize as 704x404.
If you choose 704x576 you have to physically tell it to use a custom aspect ratio of 16:9 in order for it to display the source aspect ratio as 1.77777 and resize it to 704x396.

I couldn't download your sample for some reason (the download kept stopping) but MeGUI works the same way. You could open a video with a resolution of 800x350 and if you physically select 16:9 as the input aspect ratio, the resize will still be 704x396. It sounds like MeGUI might be getting the 704x576 aspect ratio correct at 16:9, but for Yoda you need to tell it you want 704x576 to be 16:9.
Thank you.
I think I understand it now.

[Overdrive80]

Hi Zathor, I add this ticket in megui page https://sourceforge.net/p/megui/feature-requests/499/

Thanks in advance.

Maybe, this free tool could be helpful for that ticket. http://www.mega-nerd.com/libsndfile/

[tebasuna51]

Maybe, this free tool could be helpful for that ticket. http://www.mega-nerd.com/libsndfile/

Like I say before (http://forum.doom9.org/showthread.php?p=1619940#post1619940) we don't need libsndfile to write WAV files from AviSynth output.

[tfa]

in 2296 it seems that in the AVS script creator, selecting Clever anamorphic, overcrop, no longer copies the correct DAR over into the final settings after the script is created, resulting in an encode without a DAR set. Resize does copy the DAR however.

[Overdrive80]

Like I say before (http://forum.doom9.org/showthread.php?p=1619940#post1619940) we don't need libsndfile to write WAV files from AviSynth output.

Ahhh, ok... I didn read it. I agree that behappy be joined with megui, would be big advance. ^^

[tfa]

Seems that the anamorphic/dar flag does not get set at all regardless of whether resize or crop is selected in 2296 actually. Using x264 and mkv. Works fine in 2287.

[Zathor]

in 2296 it seems that in the AVS script creator, selecting Clever anamorphic, overcrop, no longer copies the correct DAR over into the final settings after the script is created, resulting in an encode without a DAR set. Resize does copy the DAR however.

Please try the recent development build. There were those changes:
2302 [AVS Script Creator] fixed wrong resize values in some cases if using cropping without anamorphic encoding
2300 [MediaInfo] fixed wrong aspect ratio if using anamorphic AVS files
2297 [MediaInfo] fixed wrong aspect ratio in some cases

EDIT: But wait, I will release a new stable. It is about time...

[tfa]

Latest build works with anamorphic, but I notice that if I select overcrop, it says my aspect error is -17.72569 regardless of how much is cropped. If I switch to resize, it shows 0.00518 (for example). In older versions, the value would only change slightly. I'm not sure that the aspect error really applies to anamorphic. The values seem to stay the same from encode to encode, always .00518 or -17.72569

[Zathor]

Thanks - will be fixed in 2309

[Zathor]

2311 [OneClick] not correctly extracted subtitle files will be ignored. Bug #710
2310 [OneClick] fixed AVS audio processing. Bug #711
2309 [AVS Script Creator] fixed missing DAR values in the AVS script if using "Clever (TM) anamorphic encoding"

[invy]

Hi, I found a bug in One Click Encoder mode and although it isn't detrimental as far as I can tell, it tends to give an uneasy feeling. Here's how it goes:

I load a single file, let's say "1.mpg", I check the "and open next", and click "Go". All so far so good.
The problem is when I load the next file and click "Go". Let's say I open "2.mpg", then click "Go". The problem is that the Video Input box now says "1.mpg" back again, instead of "2.mpg".
And let's say I open yet another file, "3.mpg". I click "Go". The Video Input box again says "1.mpg".

I don't see any reason why this would be intentional so I figure it is a bug. I sometimes tend to forget which file I last loaded because it always goes back to showing the first file that was loaded since opening the OCE window, instead of the previous.

[Zathor]

Thanks - changed.

2320 [OneClick] fixed missing subtile tracks if using intermediate MKV files. Bug #710
2319 [MKV Muxer] enhanced projected file size calculation if using intermediate MKV files
2318 [OneClick] enhanced generation of demux file names
2317 [OneClick] the audio track encode selection will not be disabled anymore
2316 [OneClick] fixed audio delay handling if pgcdemux will be used together with an intermediate MKV file
2315 [OneClick] modified "and open next" behavior
2314 [OneClick] improved muxing into intermediate MKV file if necessary
2313 [OneClick] fixed using wrong chapters file if using an intermediate MKV file with VOB input
2312 [OneClick] avoid muxing into intermediate MKV file if this is not necessary

[locotus]

Tested 2320 and 2322, in One click encoder, both are muxing DVDs to mkv.
I'm not sure if this is what 2312 and 2314 are supossed to do, but at least for me
pgdemux and dgindex had been working flawlessly. Back for the moment to 2308.

[Zathor]

Can you please explain in detail what is going to happen now (or post the log) and what is wrong in your opinion?
I tested yesterday especially with DVD structures and after the changes the intermediate MKV is used if you want to copy the video or the chosen indexer is not able to demux the audio tracks. pgcdemux (if pgc count > 1) and dgindex (if D2V has a higher priority than FFMS) are still being used.
EDIT: After some more tests an intermediate MKV is used with DVD source + D2V + video encoding enabled if an internal subtitle track is selected. But it has no impact at all - it is just a MKV file which will not be used after creation. Nevertheless that is wrong and will be fixed. Is that also your problem?

[locotus]

Can you please explain in detail what is going to happen now (or post the log) and what is wrong in your opinion?
I tested yesterday especially with DVD structures and after the changes the intermediate MKV is used if you want to copy the video or the chosen indexer is not able to demux the audio tracks. pgcdemux (if pgc count > 1) and dgindex (if D2V has a higher priority than FFMS) are still being used.
EDIT: After some more tests an intermediate MKV is used with DVD source + D2V + video encoding enabled if an internal subtitle track is selected. But it has no impact at all - it is just a MKV file which will not be used after creation. Nevertheless that is wrong and will be fixed. Is that also your problem?

The problem with this updates is that it generates de intermediate MKV file in any case when using One Click Encoder, without any changes in indexer prioritys, just as they were before the updates. My conversions are mostly DVD to MKV, so I rarely use FFMS. Thanks for your answer anyway.

[Zathor]

Do you have the problem mentioned in my EDIT? if not please post your log otherwise I cannot fix it.

[locotus]

Do you have the problem mentioned in my EDIT? if not please post your log otherwise I cannot fix it.

No Zathor, i didn't have that kind of problem, nor select
any file outside the DVD structure.

[Zathor]

No Zathor, i didn't have that kind of problem, nor select
any file outside the DVD structure.

Sorry, I do not understand your problem. Nevertheless you can try 2325 - and :logfile:

[locotus]

Thanks, no problem, your work is much appreciated.
I'll give a try and report back.

[stacman]

Bug Report/Feature Request: Robustify OneClick Queue Processing with Multiple Workers

Current Behavior: - An idle worker will process any waiting tasks which are not assigned to other workers. This will be triggered when a job is completed (also from other workers!) or new jobs are assigned but not when a worker is shut down or sent to stop after the current jobs.

Requested Behavior: An idle worker will process any waiting tasks which are not assigned to other workers. This will be triggered
1) When a job is completed (also from other workers!) or
2) New jobs are assigned or
3) A job fails with an error or
4) A timed interval (maybe?)
but not when a worker is shut down or sent to stop after the current jobs.

The reason i'm requesting these enhancement is that when I add a directory of files to MeGUI with OneClick and jobs fail to complete, the workers will eventually go idle before the entire directory has been processed and I'll have to manually "Start Worker" from the "WorkerSummary" panel. I believe this is happening because without a successful job completion, some sort of signaling event is missing.

Thanks for all your good work!

[locotus]

Zathor, 2325 seems to be working fine. Thanks again.

[hello_hello]

I have a request to change the behaviour of the file indexer when renaming the index file, if possible.

If you have MeGUI set to save the output files to a specific location, when you open a video file for indexing, the index file is automatically listed as being saved to the specified output location, as it should be. For example the input file might be located on folder "A" while MeGUI is set to save output files to folder "B", so when the video is opened for indexing the index file might default to "B\vts_01_1.d2v".

I'm in the habit of renaming the index file however, as then the extracted audio and the AVS file which MeGUI creates are all automatically re-named the same way, but clicking on the output file location box in order to do so causes the location of the index file to default back to the same folder as the source video (ie "A\vts_0_1.d2v"), which means it's then necessary to manually navigate back to folder B in order to save the renamed index file to the specified output folder.

So when renaming the index file, is it possible for the file indexer to default to the "current" or "default" output location, rather than automatically open at the source video's location? Hopefully that makes sense. It's only a little thing, but it would save a bit of navigating back and forth.

Alternatively would it be possible to enable the renaming of the index file simply by highlighting it and typing a new name, rather than needing to use the Windows "browse" function in order to do so?

Cheers.

[Zathor]

So when renaming the index file, is it possible for the file indexer to default to the "current" or "default" output location, rather than automatically open at the source video's location?
Thanks - implemented in 2326.

[Zathor]

Requested Behavior: An idle worker will process any waiting tasks which are not assigned to other workers. This will be triggered
1) When a job is completed (also from other workers!) or
2) New jobs are assigned or
3) A job fails with an error or
4) A timed interval (maybe?)
but not when a worker is shut down or sent to stop after the current jobs.
Thanks for your request. 1,2 and 3 are already implemented. I do not see a reason to implement 4.

[cengizhan]

when adding multiple files to one click encoder one by one, if first files have chapters and last one doesnt, megui throws an error saying that 'chapter file not found'.

[Zathor]

Thanks. Please explain that a little bit with more details. Are you dropping two files at once? Are you using the recent (2325) build? Are you using the "close after GO!" option? ...

[Zathor]

- The "Tuning" dropdown list lacks entries for --tune stillimage and --tune zerolatency
- The "Tuning" drop down list alone does not allow for the combination of psy tunings and normal tunings. Moving --tune fastdecode and --tune zerolatency out of the dropdown list and adding them as two separate checkboxes would allow it.
Implemented in 2327


- The "AVC Profile" dropdown list lacks entries for --high10, --high422 and --high444
But this requires a different x264 with 10bit support, correct? What happens if you use those values with a 8bit exe? In that case I will not implement it.

- The "AVC Level" dropdown list lacks entries for --level 1b and --level 5.2
Implementing now - may take a a few days as the levels are tied in several classes.

- The "AVC Profile" and "AVC Level" dropdown lists are greyed out when the "Show Advanced Settings" checkbox is not checked
Desired behavior = will not change that

- The P-frame Weighted Prediction tooltip says "B-frame Weighted Prediction". There is a B instead of a P.
Changed

Unfortunately though, the x264 --level option currently does not apply VBV restrictions but only DPB restrictions.

So, can you please make MeGUI automatically apply the correct VBV restrictions according to the selected Profile @ Level
Will implement that after/together with the level changes mentioned above.

[Poutnik]

But this requires a different x264 with 10bit support, correct? What happens if you use those values with a 8bit exe? In that case I will not implement it.

Aside of mentioned profile support, he can use input/output-csp parameters, just in case not being aware.
At least I have successfully tried i444 in X264 encoding of YV24.

[Zathor]

2330 [OneClick] fixed not removing chapter option if selected input file has no internal chapters
2329 [x264] added vbv restrictions based on the selected AVC level
2328 [x264] added AVC levels 1b and 5.2
2327 [x264] added "stillimage" to the psy tunings and moved "zerolatency" and "fastdecode" to the misc tab
2326 [File Indexer] enhanced index file selection behavior
2325 [MKV Muxer] improved playback performance with some players (requires MkvMerge 5.9.0+)
2324 [OneClick] avoid muxing into intermediate MKV file in some cases if using a DVD source
2323 [OneClick] set "Force using Key-Frames for chapters marks" even if "Don't encode video" is checked
2322 [OneClick] fixed a problem when aborting during automatic deinterlacing
2321 [OneClick] fixed a problem with multiple subtitle extraction caused by 2318