MeGUI: bug reports and feature requests

[Zathor]

Bugfix release:

2557 [OneClick] fixed missing audio files if using DGIndexNV (regression of 2554)
2556 [XviD] fixed not able to set -masking 2 (regression of 2547)
2555 [Muxer] fixed using 0 as fps value (regression of 2548)
2554 [OneClick] fixed an error when both DGIndex* are disabled (regression of 2551). Bug #801
fixed some problems when using the DGIndexIM indexer (regression of 2551)
2553 [OneClick] reset to indexer defaults to remove DGA
2552 [DGIndexIM Indexer] fixed not able to start job (regression of 2551)

[kalehrl]

Too bad there is no 'thanks' button here.
Many thanks Zathor for your continued work on MeGUI.

[Zathor]

welcome :)

[locotus]

Too bad there is no 'thanks' button here.
Many thanks Zathor for your continued work on MeGUI.

:goodpost:Agree.

[Barough]

Thnx for all the work u have done on MeGUI Zathor :)

Gr8 to see that u changed ur mind on Xvid. My friend will be so happy.

[WorBry]

....
Many thanks Zathor for your continued work on MeGUI.

Hear, hear !! And special thanks for adding DGIndexIM.

[Zathor]

Gr8 to see that u changed ur mind on Xvid. My friend will be so happy.
It was not so much me changing the mind. I noticed that ffmpeg is able to deal with ASP files > 2GB - this was necessary as AVIMuxGUI and MkvMerge are not able to process these files created by xvid_encraw.

[Barough]

It was not so much me changing the mind. I noticed that ffmpeg is able to deal with ASP files > 2GB - this was necessary as AVIMuxGUI and MkvMerge are not able to process these files created by xvid_encraw.

Thnx for the info :)

[LigH]

But based on the numbers I guess that DGIndexNV is on the top.

That may be true for PureVideo V5+ chips; earlier decoder chipsets were a lot more restricted regarding output frame rates. Therefore, users of generation 8/9 cards should not be surprised if a software decoder can be faster.

[hello_hello]

Thanks Zathor!

A question.....
I don't recall L-Smash being all that much slower at indexing than ffms2, but since the switch to L-Smash as the default I've noticed it is. Much slower. I think it's due to L-Smash unnecessarily indexing the audio even when there's no audio selected in the File Indexer. Like ffms2 used to do, until you fixed it.
Only I don't seem to be able to work out how to tell L-Smash not to index the audio, which would be very disappointing because for very large files with multiple audio streams it'd slow things down quite a lot. Do you know of a way to tell it what (not) to index that I'm missing?

When opening the index file with Notepad I see this at the top:

<LibavReaderIndexFile=13>
<InputFilePath>E:\test.mkv</InputFilePath>
<LibavReaderIndex=0x00000000,0,matroska,webm>
<ActiveVideoStreamIndex>+0000000000</ActiveVideoStreamIndex>
<ActiveAudioStreamIndex>+0000000001</ActiveAudioStreamIndex>

I'm certain the audio is being indexed because when I remux a test file with a second audio stream and index it again, the resulting index file is larger.

Thanks.

[bilditup1]

I submitted a patch (https://sourceforge.net/p/megui/patches/68/) that creates utf-8 txts for tracknames when muxing with mp4box, instead of feeding them directly in the command line. Useful for int'l chars as well as using control chars like :, =, or ".

[tuankiet65]

Can you update VSFilter to the latest version currently? (3.0.0.306)

[stax76]

And some benchmarks measured with AVSMeter:

Machine 1:
1: DGIndexNV (377 fps)
2: L-SMASH (146 fps)
3: FFMS2 (125 fps, threads=0)
4: FFMS2 (40 fps, threads=1)
5: DGIndexIM (30 fps, SW engine)

Machine 2:
1: DGIndexIM (273 fps, HW engine)
2: L-SMASH (229 fps)
3: FFMS2 (191 fps, threads=0)
4: FFMS2 (55 fps, threads=1)
5: DGIndexIM (43 fps, SW engine)

Machine & source specs does not matter so much. More important is the order of the indexer plugins. Sadly I do not have currently a machine wich is capable of DGIndexNV + DGIndexIM HW. But based on the numbers I guess that DGIndexNV is on the top.

This doesn't say much about encoding speed, what's important for encoding speed is how efficient the decoder is in regard of CPU time, a hardware decoder could be really fast but at the same time use much CPU time which isn't then available for x264 encoding. If I remember right then DSS/DSS2/DSS2MOD and LAV Filters with one of the 3 HW decoding modes can be extremely efficient, for scripts with complicated field processing DSS might not be usable but for simple scripts DSS and LAV Filters can be fine, PAL users could encode anything (except trim/cut) with just DSS without problems I believe.

[Zathor]

I should never again post benchmarks :D

[Zathor]

Can you update VSFilter to the latest version currently? (3.0.0.306)
Where do I find this?

[Xebika]

https://code.google.com/p/xy-vsfilter/wiki/Downloads?tm=2

[Zathor]

I hope you made tests as I am not using this filter ;)
Update is online

[kalehrl]

Is it expected for avi files to be muxed with avimux_gui instead of ffmpeg?
I encoded a file in xvid and it was automatically muxed into avi using ffmpeg and the original m4v file was deleted.
When I wanted to mux audio with it, avimux_gui was used with a warning that The output file will be splitted every 2GB. If this is not intended select the device type "PC" - but this will reduce compatibility for hardware players.
I wonder if it is designed to work like this or not?

[huhn]

This doesn't say much about encoding speed, what's important for encoding speed is how efficient the decoder is in regard of CPU time, a hardware decoder could be really fast but at the same time use much CPU time which isn't then available for x264 encoding. If I remember right then DSS/DSS2/DSS2MOD and LAV Filters with one of the 3 HW decoding modes can be extremely efficient, for scripts with complicated field processing DSS might not be usable but for simple scripts DSS and LAV Filters can be fine, PAL users could encode anything (except trim/cut) with just DSS without problems I believe.

DSS is frame inaccurate and i have learn this the hard way...

[stax76]

DSS is frame inaccurate and i have learn this the hard way...

Yes, DirectShow by design isn't frame accurate so DDS2 isn't usable for certain scripts, on the plus side is efficient hardware decoding and it's nice it don't need indexing. I think even hardware deinterlacing is possible. It's not as good as DGDecNV but free.

[huhn]

Yes, DirectShow by design isn't frame accurate so DDS2 isn't usable for certain scripts, on the plus side is efficient hardware decoding and it's nice it don't need indexing. I think even hardware deinterlacing is possible. It's not as good as DGDecNV but free.
it is theoretically possible to use DXVA deinterlacing and copyback but i don't know a DS filter that can do it.

and in the end way to risky anyway. if the result isn't frame accurate not sure if any benefit is worth that.
and it should made as clear as possible to new people "don't use DSS/DSS2".

[stax76]

it is theoretically possible to use DXVA deinterlacing and copyback but i don't know a DS filter that can do it.

and in the end way to risky anyway. if the result isn't frame accurate not sure if any benefit is worth that.
and it should made as clear as possible to new people "don't use DSS/DSS2".

Do you know where exactly it fails?

[huhn]

Do you know where exactly it fails?

i haven't used it in years.

but an easy way to see the issue was this.

directshowsource("yoursource")


and a script with

ffmpegsource2("yoursource")

and load it in vdub.

it was totally normal that the first frame was missing in the dss source script and if i'm not mistaken even the total number of frames where different.

adding a textsub makes things even worse.

and the next problem is what directshow decoder and splitter is used. so reproducing an issue with someone using DSS is pretty hard.

dss2 does a way better job but still.

[hello_hello]

Zathor,

Is the updating of the TimeStretch plugin still a work in progress?

I ask as TimeStretch.dll appears to have been added to the "MeGUI\tools\avisynth_plugin" folder but MeGUI is still loading the old plugin from the other plugin folder like this (Win XP):

AddAutoloadDir("C:\Program Files\MeGUI\tools\avs\plugins")

(Edit: What's the reason for the two plugin folders anyway?)

When the new TimeStretch plugin is eventually being used, the warning about destroying the phase relationship probably should be removed from the log file.

The above applies to MeGUI using the portable version of Avisynth or Avisynth+. When it's using Avisynth 2.5.8 or 2.6 etc, MeGUI still seems to be using the "built in" TimeStretch function rather than the new plugin. It would need to be loaded differently, I think.
http://forum.doom9.org/showthread.php?p=1723059#post1723059

Cheers.

[kalehrl]

I encoded a couple of files from mkv and mp4 format to xvid avi and the resulting files all had this strange entry in the mediainfo:
Frame rate : 47.952 fps
Original frame rate : 23.976 fps
The frame rate is 2x the normal frame rate of the source.
lsmash was used which seems to be the default of late.

[hello_hello]

kalehrl,
I think "original frame rate" is the frame rate written to the video stream. The other one is the frame rate written to the container. I guess for the moment you could fix it by muxing the video and audio manually as it seems it's a muxing problem.

[kalehrl]

I did mux audio and video manually using avi muxer in megui and it produced this.
I don't think it's avimux-gui's problem but rather ffmpeg's or lsmash's one.

[Zathor]

Is it expected for avi files to be muxed with avimux_gui instead of ffmpeg?
I encoded a file in xvid and it was automatically muxed into avi using ffmpeg and the original m4v file was deleted.
When I wanted to mux audio with it, avimux_gui was used with a warning that
Yes, this is correct. FFmpeg is only used to create proper files for reuse in AViMuxGUI or MkvMerge.

Is the updating of the TimeStretch plugin still a work in progress?
I haven't even started to work on that topic :-) I have only updated already the package as I had to update vsfilter.
Two plugin folders are there btw because of standalone AviSynth+ and general plugins.

I encoded a couple of files from mkv and mp4 format to xvid avi and the resulting files all had this strange entry in the mediainfo:
Frame rate : 47.952 fps
Original frame rate : 23.976 fps
The frame rate is 2x the normal frame rate of the source.
lsmash was used which seems to be the default of late.
Post the log and if possible a sample file.

[hello_hello]

I haven't even started to work on that topic :-) I have only updated already the package as I had to update vsfilter.
Two plugin folders are there btw because of standalone AviSynth+ and general plugins.

I guess I just assumed, as TimeStretch.dll in the MeGUI\tools\avisynth_plugin folder is dated 17th may 2015 so I assumed it was a recent addition. The version I have in the MeGUI\tools\avs\plugins folder is January 2014.

Sorry, I wasn't meaning to hassle you..... :)

[kalehrl]

Post the log and if possible a sample file.
Logs sent via pm.
Sample shouldn't be necessary because every single file with frame rate of 23.976 exhibits this.

[Zathor]

Thanks. FFmpeg does not set the frame rate in the correct way when it is not forced with -r.

2561 [AVI Muxer] improved logging
2560 [FFmpeg Muxer] force source frame rate (regression of 2546)
2559 [MP4 Muxer] support UTF-8 for track names. Patch by Eli Bildirici #68

[Zathor]

I guess I just assumed, as TimeStretch.dll in the MeGUI\tools\avisynth_plugin folder is dated 17th may 2015 so I assumed it was a recent addition. The version I have in the MeGUI\tools\avs\plugins folder is January 2014.
It is a recent addition (together with the vsfilter plugin). But in order to use it also MeGUI itself has to be modified.
Btw. does this new plugin really fix the destroying of the phase relationship?

[hello_hello]

Btw. does this new plugin really fix the destroying of the phase relationship?

I've only briefly tested it but the old plugin resulted in obvious phasing after encoding and then downmixing the encoded audio to stereo on playback, whereas the new plugin did not.
I think that was the whole point of the new version. To update SoundTouch to something more recent.

http://www.surina.net/soundtouch/README.html
Change history.
1.8.0:
Added support for multi-channel audio processing

[hello_hello]

Given Avisynth+ development isn't moving at a hectic pace, could I suggest updating the version MeGUI uses (r1576?) to r1825 (http://www.mediafire.com/download/g69w83ya6kl3i1d/avisynth+_r1825-20150323.7z)?
According to the info here (http://avisynth.nl/index.php/AviSynth%2B#Latest_Release) it's considered to be more stable than the official stable version.

I'm suggesting updating it as I found an issue with r1576 that's apparently not an issue with r1825.
InpaintFunc.avs - Different result depending on Avisynth version (http://forum.doom9.org/showthread.php?t=172208)
I haven't tested the newer Avisynth+ myself yet, but from what I understand after reading Groucho2004's posts in the above thread, Avisynth+ r1576 produces a different result to Avisynth 2.6.0.6, whereas Avisynth+ r1825 and Avisynth 2.6.0.6 produce the same result with the InpaintFunc script.

[stax76]

Another problem with r1576 is it's not compatible with recent ffmpeg versions.

[hello_hello]

Another problem with r1576 is it's not compatible with recent ffmpeg versions.

I didn't know that. Thanks for the info.

I have Avisynth 2.6 installed but unfortunately there's still some sort of memory issue when using MeGUI/ffms2 with MKV source files and the "installed" Avisynth. It causes the Script Creator to produce errors when cropping or resizing if you don't do it very slowly and it's fairly annoying. Unfortunately that's a combination I use quite a bit so I'm forced to stick with the portable version of Avisynth that comes with MeGUI.

[Barough]

I manually updated to AviSynth+ r1825 like a month and a half ago and it works really well with MeGUI. I also update ffmpeg like once a week or so. Haven't stumbled over any issues so far........

[stax76]

I didn't know that. Thanks for the info.

I have Avisynth 2.6 installed but unfortunately there's still some sort of memory issue when using MeGUI/ffms2 with MKV source files and the "installed" Avisynth. It causes the Script Creator to produce errors when cropping or resizing if you don't do it very slowly and it's fairly annoying. Unfortunately that's a combination I use quite a bit so I'm forced to stick with the portable version of Avisynth that comes with MeGUI.

There is a memory leak in ffms2 C plugin but MeGUI probably don't use the C plugin. StaxRip isn't effected by any ffms2 problem but it's different in that it uses VFW avifile for both AviSynth+ x64 and VapourSynth x64.

[hello_hello]

I manually updated to AviSynth+ r1825 like a month and a half ago and it works really well with MeGUI. I also update ffmpeg like once a week or so. Haven't stumbled over any issues so far........

MeGUI puts Avisynth.dll in lots of it's own folders (each encoder folder, the avs folder etc). Is it safe to replace each one with the new file or will MeGUI just over-write them all with the old version again when it runs?

I'm assuming you're referring to using the portable Avisynth+ as opposed to installing it?

[Barough]

MeGUI puts Avisynth.dll in lots of it's own folders (each encoder folder, the avs folder etc). Is it safe to replace each one with the new file or will MeGUI just over-write them all with the old version again when it runs?

I'm assuming you're referring to using the portable Avisynth+ as opposed to installing it?

I just replaced the files in the avs folder and that was it. Haven't seen the Avisynth.dll file in any other folders.

The portable version is what i use.

[hello_hello]

I just replaced the files in the avs folder and that was it. Haven't seen the Avisynth.dll file in any other folders.

The portable version is what i use.

I found seven copies of Avisynth.dll in the following folders:

MeGUI
avs
ffmpeg
x264
x264_10b
x265
xvid_encraw

Along with copies of DeviL.dll.

So I told MeGUI to switch to the "installed" Avisynth and restarted it. That gets MeGUI to delete all the avisynth.dll and DeviL.dll copies.
Then I replaced all the files in the avs folder, told MeGUI to use the portable Avisynth and restarted it again. When it restarted it copied the new files back to the appropriate locations.

I don't know if switching between Avisynth versions was necessary. Chances are MeGUI would replace the copies with the newer files when it starts anyway, but it might be worth checking they're all the same.

So far so good (not that I've done much testing yet).

[Barough]

I have never enabled the option to always use the included Avisynth (nor installed the stand alone version) but when i did enable it so did avisynth.dll and DeviL.dll copies pop up here and there. So it seems like if u dont have AviSynth installed so do MeGUI use the portable one that comes with it, without any questions.......

[hello_hello]

I guess it must, but I've always had Avisynth "installed" so I don't know for sure.

[LigH]

Report in the German doom9/Gleitz board (http://forum.gleitz.info/showthread.php?47346-Erneut-Fehler-nach-Update-bei-MeGui):

When MeGUI creates an Xvid AVI "immediately" (e.g. in the Main window, loading an AVS, selecting Xvid as encoder, and queuing a job), it is now split into 2 jobs, so that xvid_encraw creates a raw ASP stream (*.m4v), and ffmpeg multiplexes it to an AVI. This multiplex uses the FourCCs "FMP4" as VfW and DShow flags, instead of "xvid" (VfW, right after "vids" chunk) and "XVID" (DShow). Especially consumer players supporting Xvid may not recognize the FourCC "FMP4".

I hope it will be possible to enforce the Xvid FourCCs during the ffmpeg multiplex.

[Kurtnoise]

ffmpeg -i input.avi -c:v mpeg4 -vtag XVID output.avi

[Zathor]

Fixed already several weeks ago in build 2558:
2558 [XviD Encoder] changed FourCC to XVID when muxing with FFmpeg (regression of 2546)

[Zathor]

Also I have now updated AviSynth+ to r1825, qaac to 2.50 and FFMS to 2.22 RC2. I have tested none of them myself. If you have problems write it down here please.

[LigH]

@ Kurtnoise:

MeGUI executes xvid_encraw to encode raw MPEG4-ASP first (*.m4v), then calls ffmpeg only to multiplex it:

"ProgramFiles\MeGUI\tools\ffmpeg\ffmpeg.exe" -y -i "*.m4v" -vcodec copy -vtag XVID -r fps "*.avi"

This call appears to ignore the FourCC tag.
__

People in ffmpeg related IRC channels recommend filing an issue on trac.

[Zathor]

As written in the german forum this is a bug of FFmpeg 2.7+
FFmpeg 2.5.2 wrote the tag correctly. 2.7 and above seems to ignore the vtag option for AVI containers (not for MKV).

If anyone has the time to report this bug (feature?) in the FFmpeg ticket tool please feel free to do so.

[LigH]

Ticket #4682 (https://trac.ffmpeg.org/ticket/4682)