MeGUI: bug reports and feature requests

[j8ee]

From 24th May 2017: I just discovered that some of my encodes muxed with the mp4 muxer have been stripped of encoder library and encoder settings info, checking with MediaInfo. This seems to happen when I use the muxer manually - files encoded with AutoEncode or One-Click still have this info intact.

Using MeGUI 2743 development server, mp4box 0.7.0 rev3 (gpac)

Have been busy for some weeks, just did an encode and encoder info is still stripped, using autoencode. MeGUI 2766.

log - https://pastebin.com/BPBsTQaE

sample - https://mega.nz/#!K5RzjRjR!r86jH_iA6lRWogiliIMFJIQnL1f7aLArOxXQ3n2yA1M (9 kB)

[Taurus]

mmmh,
here all encoder library and encoder settings in MediaInfo show the correct value.
Tried Autoencode and manual mp4 muxing-
Both show the correct entries in mediainfo.
Latest and greatest MeGui. Fully updated.

[j8ee]

:confused: What?

Encoder settings doesn't show up for me in the older mediainfo in mpc-hc either...

In a hex editor I can see the info is there, but for some reason it doesn't show up in mediainfo.

http://i.imgur.com/yiSHq91.png


This is how it looks for me if I encode to mkv instead:

http://i.imgur.com/1ElnJYz.png

[LigH]

In a hex editor I can see the info is there

So it appears possible that the SEI auxiliary info is not displayed for raw HEVC video streams by MediaInfo (in contrast to multiplexed video streams in an MKV container), despite being present in the raw HEVC video stream; so it is rather an issue of MediaInfo than of MeGUI, correct?

[j8ee]

Well, it's not a raw stream but an mp4 muxed with megui in AutoEncode mode. And seeing that the info is there does not mean much, it could have been put in there the wrong way by the muxer and therefor made it unaccessible.

If I mux it "manually" with the megui mp4 muxer, the encoder settings can be seen in mediainfo.

It could very well be a problem with mediainfo. I have no clue so far but continue to look into it, and I very much appreciate suggestions on what to do and check for...

What version of mediainfo are you using, Taurus? And 64 or 32 bit?

Could some more people please confirm that my sample above _do_ show encoder settings in their setup of medianfo, and also which version of mediainfo they are using? I just don't understand why my system/setup should have problems...

[Taurus]

What version of mediainfo are you using, Taurus?

0.7.97

All relevant settings are shown in mp4, mkv files. Autoencode, OneClick and manual muxing.
But this is for x264 files only.
Just tested x265/hevc, you are right, nothing shown in mp4 files.
Mkv files are allright.

[Zathor]

It might be an XP thing, or something that changed to upset the older version of LSmash, but I discovered I can't index video with LSmash any more either. The progress window opens and shortly after MeGUI decides it encountered an error etc..... Once again the log file isn't very helpful.

Should be fixed?
http://megui.org/test.zip

[Zathor]

Zathor: When will the new stable megui version be available?
No clue, maybe next week, maybe in one year. Between the last two stable builds have been > 15 months, the last stable build has been released in April so there is some time :)

I using DirectShowSource indexer with MEGUI 2764. But Auto crop section is often incorrect. (some Remux Videos, some x264 videos)
File Indexer (FFVideoSource,LWLibavVideoSource) no problem. Which better? Also is there fix for DirectShowSource indexer
I tested Avisyth 2.6 and Avisyth+ 2508.
I cannot and will not support DirectShowSource. Maybe it is time to remove that completly from MeGUI.

[hello_hello]

Should be fixed?
http://megui.org/test.zip

That did the trick. Both audio and video can be indexed again. May I ask what the cause was?

I cannot and will not support DirectShowSource. Maybe it is time to remove that completely from MeGUI.

It is handy sometimes, although I suppose if you really want to use it you can create a DorectShowSource script manually.

[wthreex]

I'm not sure if this is the right thread, But why does the Megui choose the English audio as the main sound while the main sound is something else? (I'm sure Japanese audio is a default track) :

http://uupload.ir/files/bth9_capture.png (http://uupload.ir/)

How can I get the megui to automatically choose/encode the original audio without changing myself ?

[LigH]

For many media formats, MeGUI can't know a "main" audio language because there is no preference defined in the container (even if the container supports it at all, not every author selected one).

And for many people there may be a preference of languages they actually understand, over any other original language the movie was produced in first. So MeGUI offers two "Default languages" in its "Main Configuration"; but it seems there is no choice to "prefer none" and just assume the track with the first number is your preferred one.

[wthreex]

Honestly, I've encode a lot of movies in the form of a folder with OneClick encoder, Most of the films inside the folder contain "English commentary", And if the main audio is the non-English, MeGui Choose the "English commentary" track for the main audio , And since I've automatically encoded a lot of movies, I can not manually select the original audio.
I hope Zathor finds a solution to this problem.

[LigH]

For such cases, you may need a new option to ignore preferred languages from the options and prefer the original order instead...

[Zathor]

Select the languages and the order you want in the OneClick profile settings. If you do not select anything on the left and the option "all" for "Languages to select if selection does not match" it should retain all tracks in the original order. I have never tried that to be honest. Please report back if it does not work and I will change it.

[ratpack]

In the past I've been able to enter a custom sar in the x264 configuration field, and it's generally worked ok.

For a while now, it has no effect. Whatever the 'force sar' setting is will overrule any custom setting.
So having the custom sar in the screenshot attached has absolutely no effect.

It means I'm limited to only being able to use the presets in the force sar drop-down list.

Is this a regression, or has something else changed that I don't know about?


https://i.imgbox.com/XNPD0de3.png

[tebasuna51]

Whatever the 'force sar' setting is will overrule any custom setting.

It means I'm limited to only being able to use the presets in the force sar drop-down list.

Like you can see in command line window there are:

--sar 33:34 --sar 32:27

and always work the last parameter.

Select "Default" in 'Force sar' box when you use a custom sar.

[Zathor]

Thanks for reporting this. The first custom parameter will currently not been detected properly and matched with settings of the GUI.
EDIT: fixed in 2768 (not online yet)

[bilditup1]

I've written some patches to fix various issues with MP4BoxMuxer. Long story short - AppleXML chapters weren't getting written, AppleXML chapters embedded in an mp4/m4v were not getting parsed properly, and due to an apparently undocumented change in mp4box, the par and name options to the '-add' parameter stopped being parsed properly. So, I rewrote the Apple chapters function to work like the other rewritten chapters functions, made a minor change that gets AppleXML chapters to parse the right way, and changed the syntax used to specify par and tracknames for MP4Box. These are IMHO critical so pls take a look soon. Thanks!

https://sourceforge.net/p/megui/patches/70/

[bilditup1]

Like you can see in command line window there are:

--sar 33:34 --sar 32:27

and always work the last parameter.

Select "Default" in 'Force sar' box when you use a custom sar.

Thanks for reporting this. The first custom parameter will currently not been detected properly and matched with settings of the GUI.
EDIT: fixed in 2768 (not online yet)

Actually, what I've found recently when using a custom --sar (in my case, 20:11, for an old 352x480 video from some random camera), is that it got ignored by x264 and mp4box even if "Default" is used in the 'Force sar' box. The latest patch fixes this, however. Thanks zathor!

[olmicx]

Thanks for reporting this. The first custom parameter will currently not been detected properly and matched with settings of the GUI.
EDIT: fixed in 2768 (not online yet)

we are waiting for 2768:)

[bilditup1]

https://sourceforge.net/p/megui/patches/70/

Thanks to fixes to mp4box in response to bug reports I filed at gpac, one of my patches, the one for tracknames and PAR, should no longer be relevant, as long as you update the version of mp4box to the very latest nightly including those fixes (which isn't out yet). I encourage you to make the switch to this nightly if only this once, because of a different bug, which I described in a bug report here (https://github.com/gpac/gpac/issues/874) and which can't really be worked around by MeGUI itself. If you don't switch to this build then my fix for tracknames/par remains relevant, though. More about this in a comment I left at the original patch submission at sourceforge, quoted above.

[olmicx]

Hi Zathor.
I am using Megui 2767 version. When you share a new version of Megui.exe, despite the x264 version of the program does not change there is difference in the quality of the encoded video. I only downloaded a new version of Megui.exe. Do you think the difference in video quality is a normal thing?

[LigH]

@ olmicx: You ... downloaded. Zathor uploads. ;)

Apart from that, this complaint is way too vague. Hard to help without any facts and numbers: Complete logs of both encodes, complete MediaInfo reports, possibly even cut-out video samples of comparable scenes with obvious differences...

In general, with the same encoder version and the same script and the same plugins, there should not be a noticable difference. So if there is any, there must also be a reason. Maybe a change in the handling of the material, anything that changes either the generated script content or the command line calling the encoder.

[sneaker_ger]

In general, with the same encoder version and the same script and the same plugins, there should not be a noticable difference.
There should be no difference at all (unless you force x264 into non-deterministic mode).

So I agree: something must have changed. Best would be to compare the log files.

[Taurus]

Hi Zathor.
I am using Megui 2767 version. When you share a new version of Megui.exe, despite the x264 version of the program does not change there is difference in the quality of the encoded video. I only uploaded a new version of Megui.exe. Do you think the difference in video quality is a normal thing?
Look at the x264 settings tab if there is something changed during a new MeGui install.
I always make a backup of my favourit settings and store it under a new name. Just in case somethings going wrong :p.
But the best you can do, post a log file of a known "good" encode
and one from a "bad" encode.
So we might have a look at them.

[stax76]

@olmicx

To share full logs and find and share full log differences you can use www.pastebin.com and www.diffchecker.com, I recommend to use the option to store it only for one month and not post torrent file paths.

[Zetti]

MKVToolNix v14.0.0 is released.

[Zathor]

MKVToolNix v14.0.0 is released.
Thanks, uploaded

[bilditup1]

(I made a minor update to my patch to MediaInfoWrapper - when you get around to trying the patch out, pls use the newer version.)

[wthreex]

Why does megui sometimes change the video framerate? some of my video is out of sync because of it.

I'd like make it as source , what is the avisynth code?

[LigH]

Please post a complete MeGUI session log of such a case, preferably including a full MediaInfo analysis of the source.

Where does your video source come from? May it have a variable framerate? - AviSynth can only handle constant frame rates. Some source plugins can resample the video to a constant frame rate, with the right parameters. But don't try that if it is not necessary; there are other possible reasons for a change. First we need to know details what you tried so far.

[wthreex]

Source MediaInfo (Frame rate mode: Variable:24.616 FPS)

https://pastebin.com/gDtFQDFG

Full Log:

https://pastebin.com/PJc3MnX0

My Profile:

http://www82.zippyshare.com/v/Tsq80Ji2/file.html

Encode MediaInfo (Frame rate mode: Constant 24.617 FPS

https://pastebin.com/0LDdm5Fq

you right fps has changed to the Constant mode, What are the solutions to this problem?

[LigH]

Two possible solutions:

a) You may manually edit the generated AviSynth script to use the fpsnum/fpsden parameters in LwLibavVideoSource (http://avisynth.nl/index.php/LSMASHSource/LWLibavVideoSource) to resample the video to a constant and convenient frame rate. Disadvantage: Choppy playback due to inserted or skipped frames.

b) You may extract per-frame timecodes before converting, and restore them in your result. Disadvantage: I don't know details about it, and it is only supported for specific target containers. Please try to find more about this technique on your own (or have patience and wait for links provided by other members). This may require more manual labor outside MeGUI.

[Barough]

FFmpeg v3.3.3 binaries is now available @ Zeranoe's FFmpeg site
http://ffmpeg.zeranoe.com/builds/

[hello_hello]

Source MediaInfo (Frame rate mode: Variable:24.616 FPS)
Encode MediaInfo (Frame rate mode: Constant 24.617 FPS

you right fps has changed to the Constant mode, What are the solutions to this problem?

I'd try converting to a better constant frame rate. On it's own LSmash will just use the average frame rate. It might be worth going back to 29.970fps (replacing all the missing frames with duplicates) and then decimating as required.

LWLibavVideoSource("D:\video.mkv.lwi", fpsnum=30000, fpsden=1001)
TFM().TDecimate()

Alternatively, extract the timecodes from the source MKV with gMKVExtractGUI or MKVCleaver, then use the timecodes file to encode in variable frame rate mode..
If the timecodes file you extracted is called "timecodes.txt" (for example) you'd add it to the x264 custom command line section like this:

--tcfile-in "D:\timecodes.txt"

Save the encoder configuration and add the job to the queue as usual. The frame rate of the video as it's being decoded by LSMash is then irrelevant.

[Zetti]

MKVToolNix v15.0.0 is released.

[wthreex]

Add an option automatically remove subtitles from a video file. Sometimes there are a lot of subtitles attached to the video and manually erasing them with a bored amount. (OneClick Enocder):

http://uupload.ir/files/tmnb_capture.png (http://uupload.ir/)

[sneaker_ger]

Try to config OneClick profile, in languages tab move "[none]" to the left box (as only item) of the subtitle languages. I think that should do the trick.

[wthreex]

Yes, It's worked! thanks..

[Zathor]

MKVToolNix v15.0.0 is released.

FFmpeg v3.3.3 binaries is now available @ Zeranoe's FFmpeg site
http://ffmpeg.zeranoe.com/builds/

Thanks, both have been updated

[GRKNGLR]

Hey guys,

I have a problem. Where is DirectShowSource on Avisynth SC? I want to use Lavfilters.

https://i.imgbox.com/AML0xjnj.png

https://i.imgbox.com/4uKBONjT.png
2761 [OneClick] + [AVS SC] select AviSource() or DirectShowSource() only if suitable

I saw it, I know. Is there a setting? How can I choose?

PS: Sorry, my english is very bad.

[LigH]

This change seems to make this choice only relevant if you select the One Click Encoder.

AviSource is only suitable if the source is an AVI (and possibly only necessary if it doesn't use a codec LibAV decoders can't handle reliably). And DirectShowSource will probably be offered only if nothing else is obviously more suitable (I guess...).

[hello_hello]

Hey guys,

I have a problem. Where is DirectShowSource on Avisynth SC? I want to use Lavfilters.

I have the DirectShowSource option when opening m2ts files that way (MeGUI 2768 on XP). Is this one of those instances where the Haali Media Splitter needs to be installed? If those screenshots are taken from two versions of MeGUI running on the same PC, then I've no idea what's happening. When are AviSource() & DirectShowSource() deemed to be suitable?
That change seems to have the potential to be annoying.

Other than that, you can create your own DirectShowSource script to open the file in question, and use the script as the input video for the script creator.

[dissory]

@Zathor

When transcoding audio using OneClick, it shifts the audio tracks to the wrong position in the output file (even though tracks were in the right order while in the OneClick GUI).

I've included a sample file + steps to reproduce: https://mega.nz/#!ZHpjWIBI!VRLZnCWDyQU4Z1Aufmre_KwR4ERdRxGVYaedT9rRY1Q

[Barough]

@ Zathor
New DGDecNV is out....

DGDecNV 2053 slipstream 111 (2017-08-28)
- Added an error popup for cases of filenames containing illegal characters
(or other cases of file open failure). Previously, it would fail silently.

[Zathor]

2761 [OneClick] + [AVS SC] select AviSource() or DirectShowSource() only if suitable
MeGUI tries to open the source with these two options (AviSource for AVIs, rest with DS). If it fails (silently) then you do not have the option.

[Zathor]

@ Zathor
New DGDecNV is out....

DGDecNV 2053 slipstream 111 (2017-08-28)
- Added an error popup for cases of filenames containing illegal characters
(or other cases of file open failure). Previously, it would fail silently.

Thanks, updated

[j8ee]

There's an issue with the generated .avs file for audio when indexing a video with 6 channel aac audio. In the scripts it says

# detected channels: 2 channels
# detected channel positions: 3/2/0.1

regardless of ffmsindex or l-smash being used. MeGUI throw warnings when encoding:

--[Warning] [2017-09-08 17:00:32] Channel count mismatch! The input file is reporting 2 channels and the AviSynth script is reporting 6 channels
--[Warning] [2017-09-08 17:00:32] Ignoring downmix because of the channel count mismatch

and the resulting encode ends up being multi-channel. Trying to encode an mp3 fails with the error message "Unsupported number of channels: 6"

Manually changing the .avs files to

# detected channels: 6 channels

makes everything work fine.

Using MeGUI 2768 development server

(By the way, is there an easy way of verifying that video/audio files actually are multi-channel without having any matching hardware for playback? A longer-than-normal google session only came up with tools and ways for checking playback and hardware, nothing for verifying the files.

Maybe not on topic, but I'm also curious of the big difference in bitrate for the resulting audio file, depending of the l-smash or ffms indexer being used, and other decoding methods. With the l-smash indexer the encoded 2-channel audio had 51 kbps, and with ffms it had 40 kbps. Just encoding the extracted aac file directly in MeGUI resulted in a 2-channel file with 66 kbps, and encoding in foobar2000 with it's downmix filter produced a file with 42 kbps. Encoding settings being the same of course. Is this all good and perfectly normal, especially the difference between l-smash and ffms indexers?)

[Morku]

Feature request:

1. Is it possible to support Hybrid shutdown for Windows 8 (and newer)? It should look like that:
shutdown.exe /s /hybrid /t 0
2. Is a more detailed GUI for x265 planed?

Thanks a lot!

[hello_hello]

There's an issue with the generated .avs file for audio when indexing a video with 6 channel aac audio. In the scripts it says

# detected channels: 2 channels
# detected channel positions: 3/2/0.1

regardless of ffmsindex or l-smash being used. MeGUI throw warnings when encoding:

--[Warning] [2017-09-08 17:00:32] Channel count mismatch! The input file is reporting 2 channels and the AviSynth script is reporting 6 channels
--[Warning] [2017-09-08 17:00:32] Ignoring downmix because of the channel count mismatch

You might have to wait for Zathor to weigh in on that one, but what was the container? MKA, MP4, or raw AAC etc?
Some AAC encoders save 2 channel info to the MP4 header (or something along those lines) for backwards compatibility as MP4 originally only supported 2 channels, so maybe that's confusing MeGUI.

As a workaround, you could re-encode as flac, as based on your MP3 test the flac output would have 6 channels, and then you could downmix and re-encode the flac file.

(By the way, is there an easy way of verifying that video/audio files actually are multi-channel without having any matching hardware for playback? A longer-than-normal google session only came up with tools and ways for checking playback and hardware, nothing for verifying the files.

As you're already using it, foobar2000's "peak meter" displays the number of output channels according to the source.
It's under "Playback Visualisations" in the list of UI Elements. You don't have to let it take up much space if it's at a premium as it has a full screen mode (right click on it).
Keep in mind it's an output meter so if you have a DSP in the playback chain downmixing etc, it'll display the DSP's output, but that aside, I tend to trust what it's displaying.

https://files.videohelp.com/u/210984/foobar2000.gif

Maybe not on topic, but I'm also curious of the big difference in bitrate for the resulting audio file, depending of the l-smash or ffms indexer being used, and other decoding methods. With the l-smash indexer the encoded 2-channel audio had 51 kbps, and with ffms it had 40 kbps. Just encoding the extracted aac file directly in MeGUI resulted in a 2-channel file with 66 kbps, and encoding in foobar2000 with it's downmix filter produced a file with 42 kbps. Encoding settings being the same of course. Is this all good and perfectly normal, especially the difference between l-smash and ffms indexers?)

I extracted a stereo HE-AAC stream (is the source HE-AAC from an MKV and encoded it with QAAC's V91 quality settinge, comparing foobar2000 to ffms2/MeGUI and the bitrate was the same.
I'm using an older LSmash and it seemed to be confused by raw HE-AAC and was getting the sample rate wrong. For comparing decoders I'd convert to flac or wave first, or at least mux the raw AAC into an MKA or M4A. Re-encoding raw HE-AAC streams is probably something to avoid.