MeGUI: bug reports and feature requests

[Barough]

MKVToolNix v31.0.0 is released.
https://mkvtoolnix.download/windows/releases/31.0.0/

[taz742]

Partially Bug related to this previous one https://forum.doom9.org/showthread.php?p=1722030#post1722030:

Using MeGUI 2908 with AutoEncode button.

Setting:
AudioInput: <filename>.aac
AudioOutput <filename>.m4a
Encoder: FDK-AAC
Extension M4A

Result:
AudioOutput: <filename>.mp4

This time there is no error while encoding audio, neither with final muxing.
It's just a typo error with audio Extension GUI choice not correctly saved when MeGUI generate cmdline job

BTW with the [Queue] audio button, extension choice is correctly passed to cmdline.

[taz742]

Using MeGUI 2908 with [OneClick]

[source]: MP4 1920x1080 AVC, AAC

[project]:[Indexer]: DGDecNV with Audio Demux
[Avisynth]:
DGI Source
Auto Crop&Resize
Use Nvidia Crop&Resize if possible
Max Width: 960
[Video]: x264 [RAWAVC]
[Audio]: FDK-AAC [M4A]
[Muxing]: MP4


[OneClick] don't set the resize to use Nvidia core with DGI Source but set a standard resize using Spline64Resize.
Problem isn't present if I use [Avisynth script creator] then [AutoEncode]
Cheer

[Lyle_JP]

There's definitely a problem with DGIndexNV 2053.0.165 (32-bit). Every blu-ray source has the bottom 8 pixels cropped off and the picture stretched to compensate.

I confirmed it with discs I had ripped before. By using the same avs script I had used months before, I can confirm that the crop no longer matches and the AR is indeed stretched.

[tebasuna51]

There are a new version DGIndexNV 2053.0.167

[pommesmatte]

There are a new version DGIndexNV 2053.0.167

This issue is not fixed however with 167 or 168.

EDIT: Tested further. Cropping/Resizing seems to work now again, when using AVS cropping. When using "NVIDIA Crop & Resize" the resulting video has approx 2px black at top and 6px black at bottom.

[Zathor]

MKVToolNix v31.0.0 is released.
MKVToolNix v31.0.0 is released.
https://mkvtoolnix.download/windows/releases/31.0.0/
Thanks, updated

[Zetti]

FFmpeg v4.1.1 is released.

[Zathor]

Thanks, updated.
Also DGIndexNV which may fix the cropping issue.

[Zetti]

Thanks. :)

[hello_hello]

Zather,
a couple of Bluray encoding issues....

When using Blu-ray as the target playback device, MeGUI won't allow a 720x480 video to be encoded as progressive, even with --fake-interlaced enabled. I tried enabling it via the GUI and adding it to the custom command line. It seems that it should be compliant though.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#fake-interlaced

--[Information] [04/03/19 12:58:28 AM] resolution: 720x480
--[Information] [04/03/19 12:58:28 AM] frame rate: 30000/1001
--[Information] [04/03/19 12:58:28 AM] frames: 1213
--[Information] [04/03/19 12:58:28 AM] length: 00:00:40.474
--[Information] [04/03/19 12:58:28 AM] aspect ratio: 15:11 (1.364)
--[Information] [04/03/19 12:58:28 AM] color space: YV12
--[Information] [04/03/19 12:58:28 AM] target device selected: Blu-ray
--[Information] [04/03/19 12:58:28 AM] custom command line: --fake-interlaced
--[Information] [04/03/19 12:58:28 AM] changing --keyint to 30 as required for the selected device
--[Warning] [04/03/19 12:58:28 AM] the selected device does not support progressive encoding of 30000/1001 fps. changing interlaced mode to tff.
--[Information] [04/03/19 12:58:28 AM] Job command line: "C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --bluray-compat --keyint 30 --open-gop --slices 4 --vbv-bufsize 30000 --vbv-maxrate 40000 --tff --colorprim smpte170m --transfer smpte170m --colormatrix smpte170m --sar 10:11 --frames 1213 --output "D:\sample 1.264" "D:\sample 1.avs"
--[Information] [04/03/19 12:58:28 AM] Process started

In order to bypass that, I added all the necessary Blu-ray stuff to the custom command line section instead (which worked and stopped MeGUI from forcing interlaced encoding), but I noticed adding --bluray-compat to the custom command line sets --weightp 2 in the GUI, and also adds it to the command line. MeGUI allows it to be changed back to 1, although I doubt it should be setting --weightp 2 in the first place

Cheers.

[sneaker_ger]

--bluray-compat --weightp 2 is only a cosmetic issue because --bluray-compat enforces it to not be higher than 1.

[hello_hello]

sneaker_ger,
I didn't realise --weightp 2 is illegal for Bluray. At least adding it to the command line isn't breaking compliance.

Another possible issue (I'm not sure).
For a 720x480 video at 23.976fps, both these guides say --fake-interlaced is required along with --pulldown 32.
http://www.x264bluray.com/home/480p-ntsc
https://forum.doom9.org/showthread.php?t=154533
MeGUI adds --pulldown 32 when Bluray is selected as the target playback device, but not --fake-interlaced.

And a question....
My recollection was for Bluray encoding to be complaint, the encoder has to write a raw .264 stream and not write directly to MKV. I can't remember why, but is that correct, and if so, should it be something MeGUI enforces when Bluray is selected as the target device?

Cheers.

[Shuichiyagami]

Did Latest Megui Dev Server can read unicode now?
Well since i am doing project with star symbol in its name. When i use version 2828, i keep renaming or delete the symbol if i want to encode it

[pommesmatte]

Thanks, updated.
Also DGIndexNV which may fix the cropping issue.

Cropping is fixed, however the resize bug not.
https://forum.doom9.org/showthread.php?p=1864410#post1864410

NVIDIA Crop&Resize is still not usable.

EDIT: See next post for details, resizing bug seems fixed though.

[pommesmatte]

Details on the remaining bug with Nvidia Crop&Resize (DGindex version 169).

It seems that its a different bug again, no problem with resizing, but again a move in the cropped area.

I used cropping of 134 pix top and bottom (slightly undercropped on purpose, so you can see the black bars.)

Original stream shows approx 2px remaining black on top and bottom

Cropped with Avisynth shows the same 2px on top and bottom.

Cropped with Nvidia Crop the above black border doubles to approx 4px and the bottom one vanishes.

EDIT: The strange thing is: This only happens on some files, other are fine.

[taz742]

@pommesmatte: Is it possible to have a sample video source that causing your cropping issue?

[tebasuna51]

...
I used cropping of 134 pix top and bottom (slightly undercropped on purpose, so you can see the black bars.)
...

From DGDecodeNVManual.html

Important note: The nVidia driver is currently broken such that mod-2 cropping of the top and left sides is broken, and so the values of ct and cl must be mod-4. Right and bottom cropping may be mod-2. DGDecNV allows you to specify mod-2 values for top and left, however, looking forward to a fix from nVidia.

The problem is the top crop 134, it is not mod-4.

[taz742]

When you say "The nVidia driver is currently broken", you talk about the last relaese of it.
I use an old version of the Nvidia driver without this issue.
So the question is since which version the bug appear to know which old driver version is it safe to use ?

[pommesmatte]

From DGDecodeNVManual.html

The problem is the top crop 134, it is not mod-4.

Thanks for pointing that out! You are correct, with 132 or 136 top cropping, the problem does not occur.

[tebasuna51]

So the question is since which version the bug appear to know which old driver version is it safe to use ?

I don't know. I always see in DGDecodeNVManual the recomendation of use crops and resizes in mod-4.

BTW I can't recommend use a old driver only to crop in mod-2.
The standard AviSynth Crop can do the job.

[Zetti]

MKVToolNix v32.0.0 is released.

[Zetti]

x264 r2969 is released.

[Zathor]

Thanks, both have been updated

[Zetti]

MKVToolNix v33.0.0 is released.

[imsrk48]

Please add a feature for add Logo using MeGUI[emoji4]

[Zetti]

MKVToolNix v33.1.0 is released.

[Zetti]

MediaInfo v19.04 is released.

[imsrk48]

I'm facing problem with Encoding x265 to x264

https://mega.nz/#!EqpUAQAA!JOIFRxZzX3fJdKHHZXrml-Ku9hqcoHY96eQewAkJGNE

Please Give Fix AOSP [emoji120]

[sneaker_ger]

For some reason the source is opened as RGB32 while an Y4M pipe (from AviSynth via ffmpeg to x264) can not handle RGB. The MediaInfo doesn't show if the source is RGB to begin with or you have your DirectShow decoder set up to decode to RGB32.

Try:
Open source via ffms2/ffvideosource() instead of DirectShowSource()

If that does not work add as last line:
ConvertToYV12()

[imsrk48]

For some reason the source is opened as RGB32 while an Y4M pipe (from AviSynth via ffmpeg to x264) can not handle RGB. The MediaInfo doesn't show if the source is RGB to begin with or you have your DirectShow decoder set up to decode to RGB32.



Try:

Open source via ffms2/ffvideosource() instead of DirectShowSource()



If that does not work add as last line:

ConvertToYV12()Already Tried ConvertToYV12()

After this MeGUI Says what is ConvertToYV12 () I can't understand something.

[imsrk48]

For some reason the source is opened as RGB32 while an Y4M pipe (from AviSynth via ffmpeg to x264) can not handle RGB. The MediaInfo doesn't show if the source is RGB to begin with or you have your DirectShow decoder set up to decode to RGB32.



Try:

Open source via ffms2/ffvideosource() instead of DirectShowSource()



If that does not work add as last line:

ConvertToYV12()How can i use your first method please explain Sir.

I really need to fix this. My Work Stopped because of this Issue.

[imsrk48]

@Zathor Sir Please

Add FFmpegSource Selection Option in MeGUI In-built.

Add Option For Auto Download Required Avisynth Plugins that Needed in Scripts.

[imsrk48]

For some reason the source is opened as RGB32 while an Y4M pipe (from AviSynth via ffmpeg to x264) can not handle RGB. The MediaInfo doesn't show if the source is RGB to begin with or you have your DirectShow decoder set up to decode to RGB32.



Try:

Open source via ffms2/ffvideosource() instead of DirectShowSource()



If that does not work add as last line:

ConvertToYV12()I'm re-seted megui & Tried ConvertToYV12()

Now Video Encoding but Encoding Speed Is Very Slow.

[Zetti]

FFmpeg v4.1.3 is released.

[bowlingbeeg]

I've noticed that ever since the VFR support was added last year that when I encode North American DVDs to mkv and play them back on Plex or Kodi the refresh rate of my projector switches from 24p to 60p. It appears that the FrameRateMode is set to Variable in MediaInfo for North American DVDs and that causes the new support to create the timestamp file which ffmpeg uses. Now I'm not exactly sure where things go wrong from there but the result is that the Kodi and Plex seem to think they should be switching to 60p whereas older DVD rips will stay at 24p. Looking at Plex, it seems to think the actual file is 20FPS and when I look at the track info in MKVToolNix I do see a "default duration" of 20FPS. MediaInfo does say the framerate is 23.976 but that the frame rate mode is variable instead of constant like I see on older rips. I'm not entirely sure if this is a bug or not but it's certainly different behavior than what it used to do.

My work flow is that I use makeMKV to rip to a mkv with the MPEG2 video track. Then I use OneClick in MeGUI(2896) to select that mkv file. That encodes it to an h264 and re-muxes it back into an mkv with the original audio.

I've attached the log file if that's needed.

[LigH]

It often takes a while to get attachments approved here. Can you upload the log to a pastebin as well?

[bowlingbeeg]

@LigH - Here you go

https://pastebin.com/3eeMh3td

[tebasuna51]

The attached file is already approved.

The video input (from makemkv) and the video output (from MeGUI) have the same parameters:

FrameCount: 130288
FrameRate: 23.976
FrameRateMode: VFR
Duration: 01:30:34.095
Correct duration for 130288 frames at a CFR of 23.976

The audio extracted and merged have a coherent duration of 01:30:34.080

We need the timestamps file:
"G:\MainMovie\HOLMES_AND_WATSON\h2fkrskg.e0p\HOLMES_AND_WATSON_t00.mkv.timestamps.txt"
to see if there are some strange info to force a FPS of 20.

The MKVToolNix Header editor "default duration" show the "number of nanoseconds per frame"
For a 24000/1001 must show 41708333
For a 20 FPS must show 50000000 ns, is that correct?

[bowlingbeeg]

Here is the info from the MKVToolNix info:

| + Track size 126 data size 124
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0) size 3 data size 1
| + Track UID: 1557705884751226684 size 11 data size 8
| + Track type: video size 3 data size 1
| + Lacing flag: 0 size 3 data size 1
| + Codec ID: V_MPEG4/ISO/AVC size 17 data size 15
| + Default duration: 00:00:00.050000000 (20.000 frames/fields per second for a video track) size 8 data size 4
| + Language: und size 7 data size 3
| + Video track size 24 data size 22
| + Pixel width: 720 size 4 data size 2
| + Pixel height: 360 size 4 data size 2
| + Display width: 875 size 7 data size 4
| + Display height: 360 size 7 data size 4
| + Codec's private data: size 45 (h.264 profile: High @L3.0) size 48 data size 45

I attached the timestamp file

[tebasuna51]

Yes is a VFR timestamp:
# timestamp format v2
0
33 (33 ms)
83 (50 ms)
117 (34 ms)
167 (50 ms)
200 (33 ms)
250 (50 ms)
284 (34 ms)
334 (50 ms)
367 (33 ms)
417 (50 ms)
450 (33 ms)
501 (51 ms)
...


Delay initial: 0
Frame: 0, Duration min: 33 ms
Frame: 11, Duration max: 51 ms
Duration: 5434095 ms (01:30:34.095)
Frames : 130288
Fps min : 19.6078431372549
Fps max : 30.3030303030303
Fps avg : 23.9760254467395

But the average is the correct 23.97602, I don't know how mkvmerge can create a mkv with the "Default duration" 50 ms when there are frames with 33 and 51 ms of duration:

mkvmerge ... --timestamps 0:"G:\MainMovie\HOLMES_AND_WATSON\h2fkrskg.e0p\HOLMES_AND_WATSON_t00.mkv.timestamps.txt" ...

Of course I don't know the sense of put these frame durations.
The workaround is forget the VFR and use a CFR of 24000/1001

[sneaker_ger]

See:
With variable frame rate (e.g. if an external timecode file is used) video the default duration is calculated in a totally different way. mkvmerge calculates the duration for all frames according to the timecode file, counts how often each duration occurs and then uses the duration that occurs the most as the new default duration. This may be a value that doesn't even reverse to any of the often-used frame rates that people are used to.
https://gitlab.com/mbunkus/mkvtoolnix/wikis/Wrong-frame-rate-displayed

[bowlingbeeg]

Yes is a VFR timestamp:



Delay initial: 0
Frame: 0, Duration min: 33 ms
Frame: 11, Duration max: 51 ms
Duration: 5434095 ms (01:30:34.095)
Frames : 130288
Fps min : 19.6078431372549
Fps max : 30.3030303030303
Fps avg : 23.9760254467395

But the average is the correct 23.97602, I don't know how mkvmerge can create a mkv with the "Default duration" 50 ms when there are frames with 33 and 51 ms of duration:

mkvmerge ... --timestamps 0:"G:\MainMovie\HOLMES_AND_WATSON\h2fkrskg.e0p\HOLMES_AND_WATSON_t00.mkv.timestamps.txt" ...

Of course I don't know the sense of put these frame durations.
The workaround is forget the VFR and use a CFR of 24000/1001Is there a way to specify in MeGUI that I don't want the VFR? Looked to me like that was hardcoded if mediaInfo said it was VFR.

Sent from my Pixel using Tapatalk

[tebasuna51]

@sneaker_ger
Thanks for the info, that explain the wrong mkvmerge behaviour.
Instead the duration that occurs the most the default duration must be the average.

@bowlingbeeg
I don't know if you can disable the VFR, I don't use OneClick.

[hello_hello]

The VFR thing was actually my suggestion, so sorry about that, although Zathor implemented it for just the OneClick encoder so far, which I don't use myself, but I suspect it relies completely on the source being an MKV. If you remux the MKV as a TS file with TSMuxer and use that as the source, the problem will probably go away.

Should this be a cause for concern?

0
33 (33 ms)
83 (50 ms)
117 (34 ms)
167 (50 ms)
200 (33 ms)
250 (50 ms)
284 (34 ms)
334 (50 ms)
367 (33 ms)
417 (50 ms)
450 (33 ms)
501 (51 ms)

Is the frame rate uneven because the source was telecined (pulldown flags), so instead of each frame having the same 41 point something ms duration, there's a 23.976fps frame followed by one with a 23.976fps and a half duration, or something similar....

I'm not sure if Zathor intended the VFR encoding to apply to DVD video, and I'm not sure it'd work correctly as it is anyway, as by default ffms2 and Lsmash don't honour pulldown flags, so unless OneClick instructs them otherwise......
TS files should be indexed with DGIndex and pulldown flags honoured as expected. If the repeat field argument isn't added to the script for ffms2/Lsmash by MeGUI, there's a good chance NTSC DVDs won't be handled correctly.
It probably explains the source detector thingy bitching about not being able to determine the source type in the log file. I assume it only understands 29.97fps or a constant frame rate, or something like that.

Maybe it'd be better if the indexer/decoder created the timecodes file rather than extracting with MKVExtract. I don't know about Lsmash, but ffms2 can write timecodes while indexing. I wonder if ffms2 would've written a timecodes file with more evenly spaced frames? It'd be silly if it didn't.

Edit1: I checked a few VFR MKVs and they have no default duration. For me, x264 usually writes the output to MKV and I remux with MKVToolNixGUI without specifying anything, and none of my VFR MKVs have a default duration. Maybe you should remove it.

Edit2: I just read sneaker_ger's link. Removing it might be a bad idea (and now I've thought about it, I doubt it's the problem).

Edit3: I searched old log files for "timebase", and for standard "hybrid" VFR NTSC, x264 is quite partial to a timebase of 1/1000000000. It also chose 1001/360000 on occasion. I didn't go nuts searching, but for normal VFR NTSC, I didn't see any other timebase.

While we're on this subject.....
I still don't completely understand how the timebase effects the way media players interpret the frame rate. I encode DVDs as VFR now and then (using TIVTC) and I always let x264 set the timebase. It set 1/1000 for bowlingbeeg's video, probably because the frame rate isn't a normal type of variable (combinations of 23.976fps and 29.97fps).

Here's a VFR example. If someone could help me understand what's happening it'd be appreciated. Normally for combinations of film and video, x264 sets a timebase and I'm pretty sure ReClock knows when the frame rate is film or when it's video. The example below is not a standard thing. It's a combination of 25fps and 59.94fps. x264 chose 1/199900 as the timebase. This was the timecodes file:

# timecode format v1
Assume 59.940060
0, 1213, 25
2646, 2894, 25
3020, 3155, 25
3268, 5984, 25
9604, 9668, 25
9744, 9861, 25
16850, 17178, 25
35429, 38675, 25
44475, 44889, 25
51266, 52322, 25
61777, 63079, 25

So my question is, why do MPC-HC, Reclock and ffdshow all report the video to be 25fps from start to finish? It's probably a good thing, because I recall the few times I set a timebase myself it caused ReClock to do odd things, so I'm sure x264 knows best (normally). I'd just like to understand it a bit more. MPC-HC and ffdshow count the frames at 25fps, so for the 59.94fps sections, ffdshow gives two or three frames in a row the same number. The screenshot below is from a 59.94fps section.

https://i.postimg.cc/RJBP4V7y/DW.jpg (https://postimg.cc/RJBP4V7y)

[hello_hello]

Nobody understands how the encoder timebase works?? Anyone?? (see the question in my previous post).

[imsrk48]

#bug

Packages are auto disabling after closed MeGUI

[LigH]

This "bug" was an attempt to save bandwidth for the update servers: Only keep packages enabled which are regularly used, it doesn't make sense to update packages more regularly than using them.

[tebasuna51]

...it doesn't make sense to update packages more regularly than using them.
Unless the packages are used out of MeGUI... with command line bat's.

I use MeGUI to keep updated my system, and I need enable the packages I use each time, no problem.

[imsrk48]

This "bug" was an attempt to save bandwidth for the update servers: Only keep packages enabled which are regularly used, it doesn't make sense to update packages more regularly than using them.I'm facing issues when all packages are not enabled my encoding speed goes slow and take too much time in Encoding so please add option for keep all packages enabled [emoji120]

I bag you Sir. Try to understand i don't care about Bandwidth