MeGUI: bug reports and feature requests

[Zathor]

Originally Posted by tebasuna51

No problem for me, but remember than ffmpeg (AFAIK) don't have a parameter like the -readtoeof (aften) or -ignorelength (other encoders) and big PCM data (like movie audio multichannel tracks) must be sended with a W64 header instead standard WAV header.

Thanks for the hint. I just tried it and the ffmpeg encoders included are failing already.

[detmek]

Damn. I should checked that. I remember that in one period of time MeGUI wouldn't run unless all of the tools are installed. Good. No problem. I can delete encoders I don't need.
Thanks Zathor.

[hello_hello]

Originally Posted by Zathor

The conversion has been added in L-SMASH lateron. But I also never encountered there myself the problem ffms has (had?), that without this parameter frame rates are sometimes slightly off. AssumeFPS does also fix this, but this caused for me problems with some sources. Is there an AVI source file which I can try? I remember someone has uploaded a file but I cannot find it.

Here you go. This is an AVI where I assume some frames were dropped when it was captured. There's only one missing/null frame in the sample as it's very small. Open it with AviSource first and check the frame count, duration and frame rate. AviSource should get it right (or maybe it's the splitter getting it right). You'll see frames 413 and 414 are the same. Repeat the process using ffms2, L-Smash or DirectShowSource and the frame count will drop by one unless the appropriate frame rate conversion is used. The duration stays the same though, which means the frame rate will change a little. If anything Assumefps(25,1) would probably make things worse because it changes the duration, not the frame count.

You should be able to remux the AVI as an MKV and the result will be exactly the same, aside from no longer being able to open it with AviSource.

http://ge.tt/6dhdMf42/v/0?c

I just noticed something odd with that sample. For me AviSource (or the decoder) seems to be having problems with the first couple of frames, which may be the cause, but whatever it is something's throwing the frame count off by one. It doesn't change anything in respect to needing the frame rate conversion, except that AviSource is consistently one frame behind the other decoding methods and doesn't display the very last frame. I just thought I'd mention it......

[Zathor]

Thanks, file downloaded. I will have a look at it.

Meanwhile:

2544 [FFmpeg Encoder]       fixed missing W64 header for large PCM data
2543 [FDK-AAC Encoder]      fixed VBR mode
2542 [Nero AAC Encoder]     fixed not able to start encodes (regression of 2536). Bug #800

[Barough]

Thnx a lot Zathor

Looking forward 2 when it hits the update server

[hello_hello]

Originally Posted by Zathor

This is already quiet a while on my list (+ custom video encoder). Maybe it is time to implement it now.

While you're at it, could we have a custom script section in the script creator and a way to tell MeGUI where to put it in the script? Similar to the method for specifying the order of the other filters such as

<custom>

I know there's this whole script tab but the biggest problem there is manual changes are lost whenever you change something in the script creator GUI and it'd be nice to be able to add something to a script that "sticks".
I know there's the template function but for some things that's not practical. It'd be nice to have a section where you could simply type in something that's included in a script along with everything else, or even to copy and paste something MeGUI added to a script so you can modify it and then disable it in the GUI.

[kalehrl]

Possible bug report.
When using a custom command entry in xvid dialog, custom command line, credits cannot be set.
Encoding starts but without the credits part of the encoding command line.

[mini-moose]

FFVideoSource("E:\movie.mkv", fpsnum=24000, fpsden=1001, threads=1)

is fpsnum=24000, fpsden=1001, threads=1 really needed?
I noticed that on 2-pass encodes those arguments causes the 1st pass to be about 1/5 the speed of what I would get if I don't use
that part.

[hello_hello]

It appears Wilbert has created a new timestretch plugin that works correctly for multichannel audio. See post #20 here.

That should be fine for Avisynth+ but I'm not sure how you'd use it with Avisynth 2.5 or 2.6 because the way I understand it the same time stretch function is "built in" to those versions of Avisynth. Is there a way to force Avisynth to use an external plugin instead if it's internal functions?

Anyway, I just thought I'd mention it. Even if it can only be loaded and the "phasing problem" warning removed from the log file when Avisynth+ is being used, at least it's a step in the right direction, I suppose.

[hello_hello]

Originally Posted by mini-moose

is fpsnum=24000, fpsden=1001, threads=1 really needed?
I noticed that on 2-pass encodes those arguments causes the 1st pass to be about 1/5 the speed of what I would get if I don't use
that part.

The idea is if the video has null (missing) frames it won't be treated as variable frame rate, or if it's variable frame rate it'll be converted to a constant frame rate. The latter mightn't necessarily be pretty, but at least you get an encode with synced audio. If the frame rate is already the same constant frame rate as what's added to the script, in theory the frame rate conversion should have no effect. If the source is constant frame rate and it's slowing the 1st pass speed (I never use 2 pass encoding myself so it's not something I'd have noticed) it's perfectly safe to remove it. The rule of thumb for checking would be to make note of the total number of frames in MeGUI's preview, remove the frame rate conversion stuff, and then refresh the preview. If the total frame count doesn't change, you're fine without it (which you will be 99% of the time).

Adding frame rate conversion to the script that way is something most other encoder GUI's don't do. I thought it was a good idea, and in theory I still do, but I guess on the odd occasion it can cause problems.

What type of files are your source? Don't use the frame rate conversion with AVIs as it doesn't work correctly. The latest version of MeGUI doesn't use ffms2 for indexing AVIs any more. For other file types, it should be fine.

I think Zathor said a future version of MeGUI's script creator will have an option for not adding the frame rate conversion to the script

[mini-moose]

Originally Posted by hello_hello

The idea is if the video has null (missing) frames it won't be treated as variable frame rate, or if it's variable frame rate it'll be converted to a constant frame rate. The latter mightn't necessarily be pretty, but at least you get an encode with synced audio.

Thanks a lot for the detailed reply hello_hello.
I don't do 2-pass much but I have a friend who sometimes wants something on a disc (old school!) so I had to.

Wouldn't adding something like "AssumeFPS(24000,1001)" (or whatever the source fps is) give the same result?
That doesn't cause any sort of slowdowns I know of.

I don't use it for AVI, it's mostly for stuff like blu-ray.

[hello_hello]

Originally Posted by mini-moose

Wouldn't adding something like "AssumeFPS(24000,1001)" (or whatever the source fps is) give the same result?
That doesn't cause any sort of slowdowns I know of.

When the video is variable frame rate, ffms2 and l-smash output a constant frame rate using the average frame rate.
If for example you have a video with a constant 24fps frame rate but just one of those frames has a duration of double the rest, ffms2 & l-smash would both output the same number of frames as the source, the duration would be the same but the frame rate might be something like 23.996fps because it's the average frame rate. When the frame rate conversion is included, both decoders output a constant 24fps by dropping or duplicating frames where necessary. For the previous example that frame with twice the duration would have the same duration as the rest but it'd be repeated, the total duration would be correct & the frame count would increase by one.

That's a very basic example but the decoders convert to a constant frame rate by duplicating and/or dropping frames. Assume(FPS) would take the 23.996 frame rate and speed it up to 24fps, but that "missing" frame wasn't duplicated, so the frame rate would be 24fps but the duration would be slightly less. Once again it's a fairly simple example but that'd be the difference.

If you scroll up to post 4544 there's a link to an little AVI with one "null" frame I uploaded as an example.

[tebasuna51]

Originally Posted by hello_hello

It appears Wilbert has created a new timestretch plugin that works correctly for multichannel audio. See post #20 here.

That should be fine for Avisynth+ but I'm not sure how you'd use it with Avisynth 2.5 or 2.6 because the way I understand it the same time stretch function is "built in" to those versions of Avisynth. Is there a way to force Avisynth to use an external plugin instead if it's internal functions?

No problem because you can call the external plugin with other function name:

TimeStretchPlugin()

[hello_hello]

Originally Posted by tebasuna51

No problem because you can call the external plugin with other function name:

TimeStretchPlugin()

Excellent. I learn something new about Avisynth every day. Maybe that's because I don't know much......

Now if Zathor could replace the old plugin with the new one.

[kalehrl]

Originally Posted by kalehrl

Possible bug report.
When using a custom command entry in xvid dialog, custom command line, credits cannot be set.
Encoding starts but without the credits part of the encoding command line.

Hi Zathor
Did you have time to look into this?

[Zathor]

Originally Posted by kalehrl

Possible bug report.
When using a custom command entry in xvid dialog, custom command line, credits cannot be set.
Encoding starts but without the credits part of the encoding command line.

It works for me. Please provide more details how to reproduce this.

[kalehrl]

It works as expected when using 2pass xvid encoding.
If you use 1pass encoding - CQ, the credits are not set using 'Credit' button in 'video preview'.
I looked at xvid_encraw encoding options to make sure different credits quantiser can be used in CQ mode and it can.
It doesn't have anything to do with using a custom command line but with 2pass or 1pass encoding.

[mini-moose]

Originally Posted by hello_hello

When the video is variable frame rate, ffms2 and l-smash output a constant frame rate using the average frame rate.

Thanks again for all the detailed responses.

I've been playing around with it. The encode speeds I get with threads=1 (that seems to be the main speed bottleneck) are really a lot slower than without. I tried it both ways with very low crf settings (like crf 25-26 and preset fast) and low resolution (1920x1080-->720x404), just to compare. Roughly 1/5 the speed (might be less depending on cpu).

Another thing I did, is try the new ffms 2.2.1 on 2 movies (neither seem to have null frames following the test you suggested) and both came out out of sync when I didn't use threads=1. Then switched back to 2.2.0, no issues there.

Maybe I'm doing something wrong, I don't know..

[hello_hello]

Originally Posted by mini-moose

I've been playing around with it. The encode speeds I get with threads=1 (that seems to be the main speed bottleneck) are really a lot slower than without. I tried it both ways with very low crf settings (like crf 25-26 and preset fast) and low resolution (1920x1080-->720x404), just to compare. Roughly 1/5 the speed (might be less depending on cpu).

That's interesting. I've used threads=1 for a long time because I had an issue decoding a couple of videos without it, so I just went back to a single thread and haven't had a problem since (with decoding).
I'd always assumed it wouldn't make much of a difference to encoding speed because the Avisynth filtering and encoding takes up most of the CPU cycles, but maybe that was a bad assumption. I'll run some tests later out of curiosity and report back.

Originally Posted by mini-moose

Another thing I did, is try the new ffms 2.2.1 on 2 movies (neither seem to have null frames following the test you suggested) and both came out out of sync when I didn't use threads=1. Then switched back to 2.2.0, no issues there.

That sounds bad. Did the out of sync encode have the same number of frames as the source?
I'll try a few test encodes without threads=1 later on today to see what happens, but what sort of video were you encoding (resolution and codec)? Was that with or without the frame rate conversion and do you know if that also makes a difference?

[stax76]

Originally Posted by hello_hello

That sounds bad. Did the out of sync encode have the same number of frames as the source?
I'll try a few test encodes without frames=1 later on today to see what happens, but what sort of video were you encoding (resolution and codec)? Was that with or without the frame rate conversion and do you know if that also makes a difference?

Should be very easy to reproduce, it happened to many people including myself, I reported it in the ffms2 thread.