MeGUI: bug reports and feature requests [Archive] - Page 90

hello_hello

16th May 2015, 22:52

If we're talking about fdkaac and VBR, I think some of the unsupportedness in respect to VBR is in the process of being fixed.
http://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC#Issues

It's kind of odd that VBR is not officially supported given it seems to take precedence. If you have the encoder configured for CBR encoding (MeGUI configuration) but add a VBR quality to the command line, even though the bitrate is specified first, it's ignored.

I agree there's a huge bitrate jump between some of the quality settings, and while I've only played around with the ones at the higher end of the quality scale, as I explained in a previous post much of the bitrate gap seems to be caused by the default choice of lowpass frequency.
http://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC#Bandwidth
I suppose we should remember this encoder was intended for portable devices and probably configured to be bitrate concious, but adjusting the lowpass frequency seems to close the bitrate gap between the m4 and m5 quality presets. I use -w 18500 in the command line for both and the m4 quality bitrate increases while the m5 quality bitrate decreases. I haven't really experimented with the lower quality settings.

I know fdkaac seems to be all sorts of popular these days, no doubt due to it's free-ness and the fact the Nero encoder disappeared from Nero's site for a bit, but FhGAAC (https://github.com/tmkk/fhgaacenc/) seems like it's more fun. I still haven't played with it extensively but in LC-AAC VBR mode it's up to twice as fast as Nero/QAAC/FDKAAC and the quality seems fine. The files required for encoding need to be manually extracted from the WinAmp installer. Foobar2000 has presets for FhGAAC encoding and the foobar2000 encoder pack contains a modified version of fhgaac (http://www.hydrogenaud.io/forums/index.php?showtopic=106494&st=0&p=870930&#entry870930). Now it's been modified for 32 bit, it leaves fdkaac as the only aac encoder (of the four popular encoders) that doesn't support 32 bit float input (I don't think the foobar2000 encoder pack has been updated with the 32 bit version of FhGAAC quite yet, but it can be downloaded via the thread I linked to). It'd be nice if MeGUI supported FhGAAC. :)

FDK AAC vs FHG AAC (http://www.hydrogenaud.io/forums/index.php?showtopic=100308)Another topic - I plan to remove the aften encoder as ffmpeg can also encode AC3 and to my knowledge the aften developer has implemented the ac3 encoder in ffmpeg a while ago. So I would say aften is outdated and superseeded by ffmpeg. Is that correct? Or any objections?

If ffmpeg's AC3 encoding is the same as AFTEN then I guess it doesn't matter, although I'd like to see a "use what ever encoder you like" audio encoder configuration (ie a custom one). One where you can specify the path to any command line encoder of your choosing along with the appropriate command line. That way you could remove AFTEN but still use MeGUI for AFTEN AC3 encoding.

tebasuna51

17th May 2015, 10:25

Another topic - I plan to remove the aften encoder as ffmpeg can also encode AC3 and to my knowledge the aften developer has implemented the ac3 encoder in ffmpeg a while ago. So I would say aften is outdated and superseeded by ffmpeg. Is that correct? Or any objections?

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.

detmek

17th May 2015, 13:09

Zathor

17th May 2015, 13:39

No objections about removig Aften as I don't use it at all.
The only thing I am missing is ability to download only components that I need (x264, qaac, mkvtoolnix and few avisynth filters) and MeGUI not to disable those I didn't use recently. But, it used to be like that and it was changed.
The way it is currently is that all components which you use (+ some basic ones) are taken care of. If you never use a tool it will not be downloaded. If you use a tool only now and then (currently > 4 weeks), then it will be not updated automatically anymore but in the moment you use it it will be downloaded (if you have internet connection).
EDIT: So I do not see any problems here (except the situation where you do not have internet when a file can be downloaded). Where do you see a problem?

If ffmpeg's AC3 encoding is the same as AFTEN then I guess it doesn't matter, although I'd like to see a "use what ever encoder you like" audio encoder configuration (ie a custom one). One where you can specify the path to any command line encoder of your choosing along with the appropriate command line. That way you could remove AFTEN but still use MeGUI for AFTEN AC3 encoding.
This is already quiet a while on my list (+ custom video encoder). Maybe it is time to implement it now.

hello_hello

17th May 2015, 16:42

Zathor

17th May 2015, 17:10

Zathor, is there a reason when L-Smash is used MeGUI doesn't add the same frame rate conversion stuff to the script it does for ffms2? It's just that you could have fixed the ffms2/avi problem by removing the ffms2 frame rate conversion from the script instead of switching to L-Smash for AVIs (the frame rate conversion causes the problem), but L-Smash treats AVIs with null frames as variable frame rate just as ffms2 does, so if it was a good idea for ffms2, it's a good idea for L-Smash. Probably for all file types.
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.

Zathor

17th May 2015, 17:19

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

17th May 2015, 18:13

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

17th May 2015, 21:23

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

17th May 2015, 22:32

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

17th May 2015, 22:41

Thnx a lot Zathor :)

Looking forward 2 when it hits the update server :)

hello_hello

18th May 2015, 23:04

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

19th May 2015, 07:07

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

19th May 2015, 10:03

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

19th May 2015, 10:06

It appears Wilbert has created a new timestretch plugin that works correctly for multichannel audio. See post #20 here (http://forum.doom9.org/showthread.php?t=171804).

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

19th May 2015, 10:15

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

19th May 2015, 10:26

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

19th May 2015, 13:30

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

20th May 2015, 09:38

It appears Wilbert has created a new timestretch plugin that works correctly for multichannel audio. See post #20 here (http://forum.doom9.org/showthread.php?t=171804).

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

20th May 2015, 16:55

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

22nd May 2015, 13:58

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

23rd May 2015, 09:20

kalehrl

23rd May 2015, 12:38

mini-moose

23rd May 2015, 12:54

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

24th May 2015, 00:17

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.

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

24th May 2015, 01:46

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.

kuchikirukia

24th May 2015, 03:56

E: never mind, I see you were talking about FFMS threads.
What the heck speed are you encoding at where FFMS decoding would be the bottleneck?

FFMS threads=1, x264 8 bit superfast crf=19, 720x368:
encoded 2067 frames, 182.71 fps, 2983.32 kb/s

Threads=4
encoded 2067 frames, 234.97 fps, 2983.32 kb/s

hello_hello

24th May 2015, 08:02

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

I ran four test encodes, 20,000 frames, or about 14 minutes of video. Source 1080p. Output 704x396, default x264 settings. The source wasn't particularly high bitrate for 1080p. Something like 5500kbps. It's just a file I had handy. I used my ageing Q9450 PC.

Frame rate conversion + threads=1:
8 minutes, 4 seconds, 41.40fps, 20000 frames.

Frame rate conversion only:
4 minutes, 54 seconds, 68.23fps, 20000 frames.

Threads=1 only:
8 minutes, 41.75fps, 20000 frames

No frame rate conversion, no threads=1:
4 minutes, 51 seconds, 68.55fps, 20000 frames.

I took the above from MeGUI's log file. I'm going to try again with the previous version of ffms2 to see if the number of threads makes a similar difference, but at the moment it's changed my perspective a little on using threads=1 for HD sources. At least when I'm not using slow filtering.

"Unfortunately" I didn't duplicate the audio sync issue. I encoded the above by adding Trim(10000,29999) to the end of the script. The output was identical in size each time down the the number of bytes. I even cut out the matching section of audio and muxed it with each encode in order to check for audio sync issues, but they're weren't any.

Maybe it's frame rate dependant? My source was h264 in an MKV with a frame rate of 24fps.

Edit: I tried again using the previous ffms2 version and the encoding times above barely changed, so at least the threads=1 speed difference is only due to using less threads for decoding and not a bug.

Zathor

24th May 2015, 08:39

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.
Yes, that is correct. When using CQ mode the zones are not applied. It is that way at least since 2009. Not sure why... also the zones command line does not match with the help. I will have a look.

Zathor

24th May 2015, 08:55

I took the above from MeGUI's log file. I'm going to try again with the previous version of ffms2 to see if the number of threads makes a similar difference, but at the moment it's changed my perspective a little on using threads=1 for HD sources. At least when I'm not using slow filtering.
With more than 1 thread there may be also access violations when quickly seeking/jumping in the avs (e.g. during automatic deinterlacing detection of MeGUI). This was the main reason why I have made threads=1 the default. Not sure if this still applies to 2.21

mini-moose

24th May 2015, 09:19

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?

What I used is: bluray 1920x1080 (video demuxed to mkv with eac3to and indexed with ffms2), resized to 720x404. CRF 25, Preset fast.

Encode 1 with:
LoadPlugin("C:\megui\tools\ffms\ffms2.dll")
FFVideoSource("D:\video.mkv", fpsnum=24000, fpsden=1001, threads=1)
Spline36Resize(720,404)

Encode 2 with:
LoadPlugin("C:\megui\tools\ffms\ffms2.dll")
FFVideoSource("D:\video.mkv")
Spline36Resize(720,404)

(also tried with fpsnum=24000, fpsden=1001, threads=0 and fpsnum=24000, fpsden=1001, threads=16, and results were identical/similar to Encode 2 in speed and sync).

Did those with ffms 2.2.0 and ffms 2.2.1.

Encode done with previous gen i7 6-core. with threads=1 I got around 40fps, without about 160fps.

Encode 1 on both ffms version - in sync
Encode 2 on both ffms version - in synch with 2.2.0, async with 2.2.1.

I checked the frame number on the 2.2.1 one, they are the exact same. However, on the t=1 encode first visible video frame is at frame 51, on t=0 it's at frame 62. Same 11 frames difference for the very last visible frame on the video.

I did the encode itself with batch file but the indexing and avs files created with megui. Was just faster for me to do several test this way.

Honestly, this may be more a topic for FFMS thread, for some reason I didn't find one that seemed active, but I'll look again. But it's relevant for megui users as well.

edit: I found the thread stax76 and I see reports on similar issues with ffms 2.2.1. Dev seem to be already doing RC versions to fix issues.

hello_hello

24th May 2015, 09:42

I looked at the bug report in the ffms2 thread, and as a result I tried to duplicate it again, this time by encoding the video from the very beginning.

This time I was successful. Too successful.
The video in question has a bunch of black frames before a frame with a picture so it was easy to step through the frames using MPC-HC and count them until I hit picture.

Source video, 25 frames
New ffms2, threads=1, 27 frames (I encoded and checked that twice)
New ffms2, no threads specified, 30 frames
L-Smash, no threads or frame conversion, 25 frames,
Old ffms2, threads=1, 25 frames
Old ffms2, no threads or frame rate conversion, 25 frames

%@$%!!!!!!!
Can I be allowed to say that again? %@$%!!!!!!!
How many ffms2 encodes have I made since the last update. One more time. %@$%!!!!!!!

Now I'm preying the problem only effects h264 sources because so far most of my encodes since the last update haven't been h264 sources, I don't think. %@$%!!!!!!!

Oh well..... off to check them all, after a bit of a lie down.

Can we make L-Smash the preferred decoder?

mini-moose

24th May 2015, 10:36

I looked at the bug report in the ffms2 thread, and as a result I tried to duplicate it again, this time by encoding the video from the very beginning.
This time I was successful. Too successful.
The video in question has a bunch of black frames before a frame with a picture so it was easy to step through the frames using MPC-HC and count them until I hit picture.

Source video, 25 frames
New ffms2, threads=1, 27 frames (I encoded and checked that twice)
New ffms2, no threads specified, 30 frames
L-Smash, no threads or frame conversion, 25 frames,
Old ffms2, threads=1, 25 frames
Old ffms2, no threads or frame rate conversion, 25 frames

I didn't have sync issues with threads=1, but maybe I'm not sensitive enough to notice less frames async, not sure :)

I indexed the video I made with ffms 2.2.0 (without threads=) and the first visible video frame there is 49 (with new one it's 51 when threads=1 is used and 62 when not).

hello_hello

24th May 2015, 11:19

I'm not sure I'd necessarily notice a 2 frame async most of the time either (it's only about 40ms), but I'd prefer to know there isn't one. I've checked a few encodes of old AVI sources (that's what I've mostly been doing lately to run some filtering on them and clean them up a bit) and so far there appear not to be any extra frames at the beginning, so maybe it is only a problem with h264 sources. I haven't checked any of those re-encodes yet. That makes me feel a bit better. I've rolled back to the previous ffms2 for the time being, but I think I'll start getting into the habit of using L-Smash.

mini-moose

24th May 2015, 11:32

I'm not sure I'd necessarily notice a 2 frame async most of the time either (it's only about 40ms), but I'd prefer to know there isn't one.
I've rolled back to the previous ffms2 for the time being, but I think I'll start getting into the habit of using L-Smash.

Yeah, I prefer to know there isn't one as well :)

I've rolled back too.

Trying L-Smash now, at least on the speed side it seems to be doing a on better than ffms with threads=1.

Need to read up whether there any possible bugs/issues with using L-Smash.

hello_hello

24th May 2015, 13:32

Thinking about it, a 1 frame async is about 40ms, so 2 frames must be about 80ms. I don't know what I was thinking before, but 80ms is definitely heading into "noticeable audio and video de-sync" territory.

mini-moose

24th May 2015, 13:52

80ms is definitely heading into "noticeable audio and video de-sync" territory.

Indeed, it might be still in a range I might not notice too much unless I sit and watch closely (maybe not even then).

Weird thing though is that my complete encode with all possibilities are the same number of frames in total and yet there are some additional frames at the beginning. 11 on one and 13 on the other.

The speed drop is not relevant to the version though. I see from some results posted it's not just me experiencing it. However, maybe my results are more on the extreme slow side by comparison, than what others get.
Seems bumping up the threads increases the speed quite a bit, but I don't know what I should use. Say for i7 Q-Core, would it be 4,8 or 12? On my test I used what x264 shows with threads auto which is the number of physical cores x3. Threads 0 is maybe similar to Auto function (need to read up on that)? But then Zathor said:

With more than 1 thread there may be also access violations when quickly seeking/jumping in the avs (e.g. during automatic deinterlacing detection of MeGUI). This was the main reason why I have made threads=1 the default. Not sure if this still applies to 2.21

from User Manual:
int threads = -1
The number of decoding threads to request from libavcodec. Setting it to less than or equal to zero means it defaults to the number of logical CPU's reported by Windows. Note that this setting might be completely ignored by libavcodec under a number of conditions; most commonly because a lot of decoders actually do not support multithreading.

kalehrl

24th May 2015, 20:16

Yes, that is correct. When using CQ mode the zones are not applied. It is that way at least since 2009. Not sure why... also the zones command line does not match with the help. I will have a look.
I added -zw 0 1 -zq 2860 14
in the custom command line and encoded just fine using CQ. So, the syntax is the same for both CQ and 2pass xvid encoding but for some reason it is not added in CQ mode.

Zathor

24th May 2015, 20:31

Yes, as written it will not be applied in CQ mode - thx to your test with the custom coommand line I know that it is (now?) supported.
EDIT: Will be changed in the next release

Zathor

25th May 2015, 00:07

2547 [XviD Encoder] adjusted settings for recent Xvid (requires Xvid 1.3.x)
2546 [FFmpeg Muxer] added FFmpeg muxer to support ASP elementary streams > 2GB
[XviD Encoder] MKV and AVI output will always be muxed with FFmpeg
2545 [Settings] merged "Always mux mkv encodings" with "use external muxer"

After nearly 6 years finally an update to Xvid. Please test!

Zathor

25th May 2015, 14:19

2551 [DGAVCIndex Indexer] removed DGAVCIndex
[DGIndexIM Indexer] added DGIndexIM. it has to be enabled in the settings and
the license.txt file has to be placed manually in the directory /tools/dgindexim
[Indexer] new default order: DGIndexNV, DGIndexIM, DGIndex, L-SMASH, FFMS
2550 [Aften Encoder] removed aften encoder. please switch to FFmpeg AC-3.
2549 [XviD Encoder] added additional log information
2548 [Muxer] fixed wrong fps value if fps is changed in AVS. Bug #799

kalehrl

25th May 2015, 14:59

There are no updates available.

Zathor

25th May 2015, 15:16

There are. Your client will only check every 24 hours.

kalehrl

25th May 2015, 19:33

Just updated successfully.
There is a bug with HVS masking selection.
There is no difference in the commandline when choosing Lumi or Variance.
In both cases it shows -masking 1 whereas for Variance it should be -masking 2.

Zathor

25th May 2015, 20:22

Thanks & confirmed. Will be fixed in the next release.
Too many bigger changes these days - and too many bug fix releases :(

Zathor

25th May 2015, 20:34

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.