MeGUI: bug reports and feature requests

[LouieChuckyMerry]

Originally Posted by LigH

Instead, I would prefer the AVSMeter method: Request a list of available functions from the used AviSynth.dll; but I am not one of its programmers.

You could always try to convince Groucho2004 to join the VDubFilterMod team .

[Gser]

Originally Posted by LigH

That surprises me a lot. What does TFM do on its own, beyond helping TIVTC finding the Telecine pattern? And PAL does not have a 3:2 Telecine at all, that's only valid for the NTSC/Film relation.

Would it also help reverting a 25:24 pulldown of a choppy half-second norm conversion? And does it have any meaning for a real PAL interlaced TV recording?

VDubFilterMod has an integrated script editor too. Unfortunately the syntax highlighting appears to be rather basic, not analyzing the available function set of the AviSynth installation. Might be a valid Feature Request to make the highlighting more customizable?!

PAL DVD's, 25fps 1080 blu-ray's and tv is still interlaced, in this case I'm talking about original progressive frames separated into fields, so TFM makes sure the fields are properly combined without combing or heaven forbid using some kind of other deinterlacing. For hybrid material you can specify an externally deinterlaced source which is nice also, so if tfm detects a frame to be interlaced it will use that instead. I haven't seen any material that has added duplicated frames instead of speeding the material up from film speed but technically is is possible so you would want to remove those with tdecimate and tfm can flag those for removal (I'm only guessing the flagging works with PAL material).

Personally if I make more complicated scripts I use AvsPmod.

[Groucho2004]

Originally Posted by LigH

Instead, I would prefer the AVSMeter method: Request a list of available functions from the used AviSynth.dll; but I am not one of its programmers.

The internal functions for syntax highlighting are hard-coded in CAvisynth.cpp in the VDub script editor code. Modifying the code to retrieve the functions dynamically should be rather simple.

[LigH]

@Gser:

That's what I mean ... AFAIR, TFM only flags frames, but it does not alter the clip's frame content. So, to remove duplicate fields, one would need a "TFM flag aware" other filter after TFM. Am I wrong here?

[LeMoi]

Originally Posted by Zathor

It does work for me (using 2800). I select a M2TS file, playlist opens and I click on cancel - m2ts only selected.

I tried today with another BD, and this time it worked fine, I don't know if the problem came from the other BD or anything else...
I'll tell you if it ever happens again with another disc

[Megalith]

Can MeGUI be updated so it remembers window size and positioning?

[LigH]

For me, the main window remembers its size.

Check if it is able to update its settings.xml (one of the reasons why it should not be installed in an UAC protected directory like C:\Program Files...).

[LouieChuckyMerry]

MeGUI 2800 Development Server (Portable Version): My main window remembers its size and position, and once I adjust my Worker 1 window position it remembers every time it's used until I close MeGUI (not that I ever do ). None of my Tool windows (Stream Extractor, Bitrate Calculator, etc.) remembers its position, but this isn't an issue for me.

[Zathor]

Only the main window and the update window will remember size & position between MeGUI sessions

[Zathor]

2804 [OneClick] + [FileIndexer] show playlist selection window for DVD/Blu-ray structures also if only one playlist is found
2803 [HD Streams Extractor] added support for "E-AC3 Surround"
2802 [OneClick]             enhanced suitable container type detection
2801 [OneClick]             fixed video name not written sometimes (regression of 2791). bug #901

[Zathor]

Originally Posted by LeMoi

I have 2800 DEVELOPMENT UPDATE SERVER.
Without clicking on anything, it automatically opened the 00100 mpls file...
Did I do something wrong?

Should be working now with 2804

[hello_hello]

Originally Posted by LigH

@Gser:

That's what I mean ... AFAIR, TFM only flags frames, but it does not alter the clip's frame content. So, to remove duplicate fields, one would need a "TFM flag aware" other filter after TFM. Am I wrong here?

It's not uncommon for the "fields" in a progressive PAL source to be out of alignment, or out of phase, or whatever the description is. Before I discovered that, I'm sure I would have de-interlaced progressive PAL in the past, thinking it was interlaced because it looked interlaced. It wasn't until I started de-interlacing to 50fps and realised the output had repeated frames that I discovered something was wrong.

So TFM definitely gets an occasional look in when encoding PAL, although usually only when it's needed for field matching as I usually disable it's de-interlacing anyway TFM(pp=1).
If the source is interlaced or partially interlaced I prefer to run QTGMC the standard way rather than create an external de-interlaced clip for TFM to use, and TFM won't de-interlace to "double frame rate" anyway.

Actually TFM could use an update in that respect. When it's in VFR mode it'd be nice if it could de-interlace to 50fps/59.940fps rather than 25fps/29.970fps. I should ask about it in the TIVTC thread.

[LigH]

I believe your reply does not answer my question. And I still believe you missed the whole point.

Does TFM on its own (without a following TIVTC or TDecimate) change the number or order of fields or frames, at all?

[hello_hello]

Originally Posted by LigH

I believe your reply does not answer my question. And I still believe you missed the whole point.

Does TFM on its own (without a following TIVTC or TDecimate) change the number or order of fields or frames, at all?

Yes it does. For telecined NTSC, TFM does all the shuffling, dropping and duplication of fields (and de-interlacing if need be), and sends whole frames to TDecimate for duplicate removal. That's easy enough to confirm by adding TFM to a script without TDecimate when the source is telecined, although I think TFM keeps TDecimate fairly well informed to help it decide what's video and what's film etc, because TDecimate removes the duplicates and/or converts from 29.970fps to 23.976fps when the source is hybrid, or from 23.976fps to 29.970fp as the case may be. TDecimate also creates the timecodes file for VFR encoding, if you don't want to be dropping/adding/blending frames for a constant frame rate

There's a sample of the type of PAL source I referred to in my last post, attached to the opening post here.
It looks interlaced and smells interlaced but it's progressive and all that's required to fix it is TFM(pp=0).

For progressive PAL sources with shifted fields it's usually quite safe to disable TFM's de-interlacing as I'd assume they're shifted by the same amount from beginning to end so there shouldn't be any de-interlacing required. When a PAL source appears to be interlaced but I think it should be progressive, I'm in the habit of disabling TFMs de-interlacing for testing anyway, so then if the combing disappears I know it must be the result of field matching and I won't be fooled into thinking it's not interlaced when it is.

[hello_hello]

It must be a while since I've encoded a PAL source with phase shifted fields, but I was reading through the VideoHelp thread I linked to for a memory refresh, and it reminded me I've used jagabo's suggestion from post #7 for outputting progressive frames successfully, no TFM required, because generally the fields will be phase shifted from beginning to end. All you need to do is separate them, remove the first one, then weave them back together again.

SeparateFields()
Trim(1,0)
Weave()

[Zetti]

x264 r2893 is released.

[Barough]

Seems like with the latest x264 release so is there no longer separate builds for 8 & 10 bit EXE's. Now it's just a single multilib EXE

[Barough]

Opus-tools v0.1.10-12-g1a79305 (using libopus 1.2.1) (GCC 7.2.0, 32 & 64-bit Windows Binaries )

https://git.xiph.org/?p=opus.git;a=summary
https://git.xiph.org/?p=opus-tools.git;a=summary

[Zathor]

Originally Posted by Zetti

x264 r2893 is released.

Thanks, waiting for the komisar builds.

Originally Posted by Barough

Opus-tools v0.1.10-12-g1a79305 (using libopus 1.2.1) (GCC 7.2.0, 32 & 64-bit Windows Binaries )

Thanks, is there any reason to update (I am not using opus myself)?

[Barough]

Originally Posted by Zathor

Thanks, is there any reason to update (I am not using opus myself)?

Dont know. I only made it available since it compiled on my last run of 'media autobuild suite'


Sent from my SM-G935F via Tapatalk