StaxRip

[burfadel]

Thanks for the links, I made all changes including description for qaac in the applications dialog:

There is however a problem with qaac 64-Bit, the command shell window pops up and StaxRip don't receive any output, I don't think I can do anything here other then report it to the author which I already did, waiting for a reply now.

Hope it isn't too much of an issue to resolve!

Using the same filenames is IMO the best approach, 32-Bit StaxRip using 64-Bit ffmpeg is a bad, look at one of the current defaults:

"%app:ffmpeg%" -i "%avs_file%" -f yuv4mpegpipe -pix_fmt yuv420p - | "%app:NVEncC%" --sar %target_sar% --codec h265 --y4m --cqp 36 --input - --output "%encoder_out_file%"

Most people will use the NVEncC GUI, the nice thing about this profile is it teaches people that piping is possible and simple, ffmpeg interfaces with AviSynth here (loading the AviSynth library via COM+), 64-Bit applications can only load 64-Bit libraries (at least without black magic).

Ah okay! I didn't think of that, I don't use NVEnc, I mainly used ffmpeg for forced audio decoding. I found decoding to .wav first was more reliable for some sources than encoding the audio directly from the source file. For practicality, I just had it enabled by default :).

[stax76]

Hope it isn't too much of an issue to resolve!

I hope it's not but this one could be difficult.

Ah okay! I didn't think of that, I don't use NVEnc, I mainly used ffmpeg for forced audio decoding. I found decoding to .wav first was more reliable for some sources than encoding the audio directly from the source file. For practicality, I just had it enabled by default

Another location where ffmpeg interfaces with AviSynth is the cut feature because for cutting mkvmerge needs a video file so StaxRip creates a 16x16 pixel AVI file with AviSynth and ffmpeg, decoding with ffmpeg isn't necessary in my experience but should be fine doing and has the advantage of most accurate cut points. I have to test if the new FLAC automatic gets in the way here.

[Patman]

I've tested xvid_encraw a bit with quality mode and 2-pass mode. The app worked as it should. In my opinion it's very easy to customize the settings. I made some changes for better quality.

:thanks:

[luigizaninoni]

I spoke too soon about the benefits of multithreaded Avisynth+

The speed benefits are there, but it is hardly stable. With Prefetch=3 or above, it invariably crashes in a few minutes. With prefetch=2 it is usually stable, however last night I launched a long encode and found that after a couple of hours it had crashed.

Maybe I am doing something wrong, or avisynth+ MT is not mature yet, or am using the wrong MT_MODE for some filter.

Anyhow, I am back to Staxrip with avisynth+ single-threaded, doing two encodes at the same time to fill CPU. Rock solid.

[burfadel]

I hope it's not but this one could be difficult.

I am trying out the beta you posted for this, it works well so far! The issue with QAAC64 is of minor annoyance only (having that command window pop up). On the other hand, it starts encoding the video while the audio is still encoding, so you have accidental mutlithreading there!

So there's no way of just outputting just the title bar information, and hiding the window?

[thomy22]

I test the new Version thanks for that.

But why the Files are so big? I have the same options and the File on the Old version are 300-350 MB (for 23min DVD File on X264) now i have 750 MB.

on the Old Version i have this Filters here centrodiperditadipeso.info (http://www.centrodiperditadipeso.info)

FieldDeinterlace
Crop Boarders
DeGrainMedian

now i have the standart Filters:

TDeint
Crop
Remove Grain

Are the Filters not work the same like the Old one or why the Files are so big now?

All other Settings are the Same CRF 19 and B-Frames and R-Frames 16 on Present Slower Tune Film

[burfadel]

I notice that even though tfm is listed in the filter menu, the plugin isn't included. I believe tdecimate is also in the same package as tfm, so there should be an option in the filter menu for inverse telecining and decimation (which can be done with these two filters). Without inverse telecining and decimation, people will be doing a lot of bad encodes of telecined material!

[burfadel]

@Stax
I found out something 'important' regarding the QAAC issue, I'll send a PM :)

[burfadel]

@Stax
(from the private PM, glad the qaac issue was super simple to fix!)

I came across the flash3kyuu deband filter, and am extremely impressed with the results on a poor quality video I had. The compression is good too, I used dither_algo=2 as suggested (it's better for standard bitrates, algo 3 is better for high bitrate outputs).

Anyways, the doom9 page is here:
http://forum.doom9.org/showthread.php?t=161411

Both x64 and x86 versions are available. Help file is inside.

Now, I've come across a more updated version of it, still from the same sources as in the linked doom9 post, just that post hasn't been updated!

Topic here:
https://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=239

The version I used was the 2.0pre+b98d6bc x86/x64, inside which has the x64 and x86 dll's. It's up to date too! 2015-05-02, so only 2 days old.

If anyone is wondering, I see the removing the banding and other issues present in poor quality videos as important. Some say it's pointless because you may introduce banding with encoding anyway, but that is rather an old thought on the manner. If there is banding present in the source, when you encode you are going to encode the banding as well! If you have a debanded source, with a very mild light dither, modern encoders (especially 10-bit versions of x265 etc) will produce markedly better file outputs.

EDIT: Done a few more encodes, not only do I get a better quality output, but the output file size is actually smaller! I guess it makes sense since it's not using bits encoding the banding artifacts. I think it's well worth it going from 8-bit sources to 10-bit x265. It's also fast :), especially the 02 Msy 2015 build. This is using dither_algo=2.

[luigizaninoni]

I made further findings on Avisynth+ MT issues.

I found that problems arise (encode crashes) ONLY when Qtgmc AND SelectEven() are both enabled.

So:
Script with only Qtgmc --> MT works fine, even with Prefetch(4)
Script with only SelectEven() --> MT works fine
Script with Qtgmc AND SelectEven() --> encode crashes

What's going on ? I have no clue. Is this a problem with Avisynth+ or with Staxrip ?

[Reel.Deel]

I made further findings on Avisynth+ MT issues.

I found that problems arise (encode crashes) ONLY when Qtgmc AND SelectEven() are both enabled.

So:
Script with only Qtgmc --> MT works fine, even with Prefetch(4)
Script with only SelectEven() --> MT works fine
Script with Qtgmc AND SelectEven() --> encode crashes

What's going on ? I have no clue. Is this a problem with Avisynth+ or with Staxrip ?

This sounds like an AviSynth+ problem. Have you tried SelectOdd instead? Also you can try SelectEvery (http://avisynth.nl/index.php/Select) as an alternative? If that fails how about QTGMC(FPSDivisor=2) (http://avisynth.nl/index.php/QTGMC#Shutter_Speed_Motion_Blur_.2F_Frame_Rate)?
QTGMC()
SelectEvery(2, 0) # identical to SelectEven()
#SelectEvery(2, 1) # identical to SelectOdd()

[luigizaninoni]

Thanks for the suggestion.

However, SelectOdd, SelectEvery and FpsDivisor all crash after a few hundred frames, just like SelectEven

[stax76]

@luigizaninoni

There is a similar report in the AviSynth+ thread, please post a full script, I want to test it too.

@burfadel

Thanks for the plugin suggestion and the help with qaac, I can add many more plugins, no problem. Regarding TDecimate, there is a crash in Win8/Win10 it seems so I removed the plugin and forgot to remove the filter. Some plugins have some CPU related parameters I need to try, overall there were many issues on Win8/Win10 not happening on Win7 so I decided to migrate to Win10 preview as main OS to investigate all problems.

@thomy22

if the quality looks good then filters cannot make such a big difference in file size, it's most likely related to source complexity and crf.

@Patman

Thanks for the tip about the new DLL.

[burfadel]

I just tried the StaxRip_2015.05.04_20-32 beta, and it errors as a result of AssumeFPS(%fps%) on existing projects. Even completed projects it says invalid argument because of this.

Just noticed that I reclicked the source filter I was using, saved the template, and recreated the projects that were in the queue, and they are encoding fine now. I guess assumefps(%fps) was a change between the last beta and this one :).

[stax76]

I've removed all those macros because they are not needed any longer, instead of always using the frame rate from MediaInfo with macros I add AssumeFPS dynamically now only if correction is needed, the correction logic is following:

if frame rate from AviSynth is approximately 2 times more then frame rate from MediaInfo then StaxRip adds SelectEven().AssumeFPS(fpsFromMediaInfo)

this corrects a bug where ffms2/ffmpeg duplicates interlaced frames

the second correction fixes wrong PAL frame rates, NTSC I leave now which might improve or worsen things, I don't know too much about NTSC.

[luigizaninoni]

Here is the script:
Import("C:\Users\admin\Desktop\Video\Stax beta\Tools\Plugins\QTGMC\QTGMC.avsi")
LoadPlugin("C:\Users\admin\Desktop\Video\Stax beta\Tools\Plugins\masktools2\masktools2.dll")
LoadPlugin("C:\Users\admin\Desktop\Video\Stax beta\Tools\Plugins\mvtools2\mvtools2.dll")
LoadPlugin("C:\Users\admin\Desktop\Video\Stax beta\Tools\Plugins\nnedi3\nnedi3.dll")
LoadPlugin("C:\Users\admin\Desktop\Video\Stax beta\Tools\Plugins\RgTools\RgTools.dll")
LoadPlugin("C:\Users\admin\Desktop\Video\Stax beta\Tools\Plugins\ffms2\ffms2.dll")
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("FFVideoSource",3)


FFVideoSource("C:\Users\admin\Desktop\Interceptor (1979) temp files\Interceptor (1979).m2v", cachefile = "C:\Users\admin\Desktop\Interceptor (1979) temp files\Interceptor (1979).ffindex", fpsnum = 25, fpsden = 1)
QTGMC(Preset="Slow")
SelectEven()
Crop(2, 70, -2, -70)
Prefetch(4)

[stax76]

@luigizaninoni

I might have found something, putting SelectEven and Crop after Prefetch!

edit:

too bad, it's also freezing. :(

[NikosD]

this corrects a bug where ffms2/ffmpeg duplicates interlaced frames



The new method of 1.3.1.1 works fine with interlaced H.264 files and ffms2, just like the previous 1.3.1.0, but the new method is a lot faster I think.

[luigizaninoni]

Where is the new beta? I can't find it

[stax76]

there is a dropbox folder where I often upload bug fixes, it's here:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

[luigizaninoni]

there is a dropbox folder where I often upload bug fixes, it's here:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

:thanks:

[luigizaninoni]

but ... with 1.3.11 now Avisynth+ MT works ! Great job, Stax !

[stax76]

I couldn't get it working with prefetch as last statement but putting SelectEven after prefetch I was mostly successful, I'm still experimenting with filter order and have yet to encode a full movie to prove that it can work.

[luigizaninoni]

I'll try an encode of a full movie, too. P.S. Beta of 05.05 says "AVSmeter not found"

[stax76]

AVSMeter x64 has the original filename AVSMeter64.exe, new StaxRip builds use original names, if you don't want the newest built you can just rename the old.

[burfadel]

Stax, avsmeter has been updated to 2.0.1, the version with Staxrip64 is 2.0.0.

2.0.1 was just released yesterday (well today for most of you), 05 May 2015.

As from the Doom9 thread, versions are here:
https://www.sendspace.com/folder/4vem0i

[stax76]

Locally I have it already updated. :)

[burfadel]

QAAC 2.48 out as well :)

[NikosD]

Rigaya kept his promise he gave me and he started experimenting with HW decoding using QSV besides HW encoding.

He published some benchmark numbers with fully HW accelerated transcoding pipeline which give a big performance boost to least powerful CPUs and a smaller boost for CPUs like 4770K.

One important thing is the extremely low CPU usage in fully HW accelerated scenario in all cases.

After his tests, I believe the testing version will go public.

[AMED]

I seem to get a CAVIStreamSynth: System Exception - Access Violation error or AVISynth returned empty image data message whenever I try and preview the script below
LoadPlugin("D:\StaxRip\Tools\Plugins\mvtools2\mvtools2.dll")
LoadPlugin("D:\StaxRip\Tools\Plugins\ffms2\ffms2.dll")
# SetFilterMTMode("DEFAULT_MT_MODE", 2)
# SetFilterMTMode("FFVideoSource", 3)
FFVideoSource("I:\Star Trek (2009) (1)-003.mkv", cachefile = "I:\Star Trek (2009) (1)-003 temp files\Star Trek (2009) (1)-003.ffindex")
BicubicResize(1280, 720, 0, 0.5)
super = MSuper(pel=2)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

ConvertToRGB(matrix="Rec709")

When i run the script though AVSmeter there is no problems

Staxrip v1.3.1.1

[stax76]

QAAC 2.48 out as well

:thanks:

@AMED

I think some scripts fail only if a application requests random frames, if you would open the script with VirtualDub x64 I would guess you would see the same AviSynth error, only a AviSynth dev could help here.

You could try using LWLibavVideoSource instead of FFVideoSource, by default StaxRip uses FFVideoSource for MKV but the default can be changed in the settings on the filters tab.

[AMED]

LoadPlugin("D:\StaxRip\Tools\Plugins\mvtools2\mvtools2.dll")
LoadPlugin("D:\StaxRip\Tools\Plugins\L-SMASH-Works\LSMASHSource.dll")
# SetFilterMTMode("DEFAULT_MT_MODE", 2)
# SetFilterMTMode("LWLibavVideoSource", 3)
LWLibavVideoSource("I:\Star Trek (2009) (1)-003.mkv")
super = MSuper(pel=2)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
Still gives me the same access violation error (different memory address though) with the preview, AVSMeter still processes it ok.

I opened the above script in VDubx64 and it displays the video fine. if i seek to random places on the video it's still fine.

Just checked with FFMSVideoSource and that script also loads correctly in vDubx64.

[stax76]

Does this script utilize nnedi3? There are some unresolved x64 related issues still being investigated, I'm working on it. :)

[NikosD]

New QSVEncC will be implemented keeping frames in GPU, like DXVA native mode, so it could reach HandBrake's performance.

It will accelerate in HW both MPEG2 and H.264 video formats for decoding.

Rigaya told me that he was trying to accelerate HEVC in HW using MSDK but with no success (probably due to MSDK or driver's error) but he will add that too, when it will be more mature.

There will be no SW fall - back, so for every other video format, we will keep on using the other source filters of StaxRip.

[AMED]

Does this script utilize nnedi3? There are some unresolved x64 related issues still being investigated, I'm working on it. :)just using FFMS2VideoSource or LWLibavVideoSource and MVtools2. the only plugins in the AVISynth+ plugin folder are the default plugins from the install.

[stax76]

15 years ago StaxRip was the first .NET application on doom9 and it was a bit difficult, now StaxRip is early adopting AviSynth x64 with .NET and it's again I bit difficult. I made a sample application with MeGUIs interop layer which is completely different then my layer and the problem persists and it's not only managed applications producing the problem, you should also see it with MPC, it's more likely the problem is native code and not managed (.NET) code.

[Groucho2004]

it's more likely the problem is native code and not managed (.NET) code.
No idea what that means. Could you elaborate?

[videoh]

http://en.wikipedia.org/wiki/Managed_code

Native code is the Avisynth DLL, the plugin DLLs, and the avifile DLL. The rest is the managed application that uses .NET (VB .NET?). Apparently stax76 needs some kind of "interop layer" (is that staxrip76's avifile interface stuff?) to access the native code from his application code. But VB .NET can make Avisynth DLL calls directly without any such layer.

It seems to me that stax76's insistence on the avifile interface is misguided, as Groucho2004 pointed out. He should invoke the Avisynth DLL directly. There are a lot of code examples for it. Realistically, nobody is going to debug avifile.dll, so unless staxrip76 wants to do that, he should transition to direct access of the Avisynth DLL. That has little to do with managed versus native code, because he already accesses the avifile.dll natively. staxrip says he ported MeGui's "interop layer", by which I suppose he means the Avisynth interface, but he hasn't shown us this code.

staxrip76 has not yet identified the faulting module. On the other thread I suggested ways to find out. Hopefully, he is interested in that.

[Groucho2004]

The part I don't understand is "it's more likely the problem is native code". Which native code exactly? Blaming the plugins, which work properly with other client programs, is not going to help track down the problem.

[videoh]

It could still be a plugin problem, though unlikely. Blaming other code can be effective if you can motivate the developer to look into it, so I don't fault that (personally, I'm not motivated to debug VB .NET + avifile + "reflection hack"), unless it is used as an excuse to not do what you can to check things in your own code. What I fault is the apparent total lack of any debugging skills whatsoever, and the inability to make germane responses to helpful questions and suggestions.

Most likely, avifile is not compatible with the modern versions of Avisynth. Solution: get rid of avifile. But if the developer cannot run a debugger, can he re-engineer for direct Avisynth access?

[stax76]

@videoh

I don't know your programming background but from all your post it's clear you know absolutely NOTHING about dotnet so it's pretty pointless to argue over it.

[videoh]

That's disappointing that you consider my opinions not worth hearing. Nevertheless, good luck with your {VB .NET + avifile + "reflection hack"} project. Despite any differing perspectives we may hold, surely the video community applauds your efforts.

[NikosD]

Frank, good news!

QSVEncC v2.00β is out in public adding QSV decode for H.264, MPEG2 and HEVC.

Here:http://1drv.ms/1FcV6XN

I told rigaya to use the plugin for HEVC HW decoding and he managed to implement QSV decoding for that format too in this version.

The new commands are:

--avqsv set input to use avcodec + qsv

--audio-file <string> extract audio into file.
could be only used with avqsv reader.

--trim <int>:<int>[,<int>:<int>]...

trim video for the frame range specified.
frame range should not overwrap each other.
could be only used with avqsv reader.

In his blog says that for HEVC needs elementary stream, but for MPEG2 and H.264 uses avcodec to demux .mp4/.mkv etc

http://rigaya34589.blog135.fc2.com/blog-entry-618.html

Not sure how you are going to do your magic and integrate this new version to StaxRip.

Waiting for your feedback!

[stax76]

good news indeed, I think it mostly involves generating the command line with StaxRip's crop and cut values.

[burfadel]

New version of NNEDI3
http://forum.doom9.org/showthread.php?t=170083

10/05/2015 v0.9.4.9

+ Bug correction in x64 ASM file, thanks to jackoneill and HolyWu

Don't forget MKVToolNix 7.9.0. They changed the name of the archive so it is a little lost in their upload folder:
https://www.bunkus.org/videotools/mkvtoolnix/win32/
(just so others know, the 64-bit versions are also under win32).

[burfadel]

Stax, Avsmeter has been updated once again to v2.0.2

[detmek]

Hi Stax. I see that Staxrip requires Apple Application Support (AAS) to be installed in order to use QAAC. The point is - you can use QAAC even if AAS is not installed as long as you have correct files in qtfiles folder alongside qaac. Can you implement checking for those files before Staxrip asks for AAS installation?

P.S. You can run from command line qaac64.exe --check.

[stax76]

@burfadel

thanks for the updates

@detmek

I don't know if the last build already supports it, the next will sure support the folder QTfiles64, I'll also write it to the description so people know it from start.

[detmek]

I don't know if it is the latest but I use 1.3.1.1 beta and it does not support QTFiles64. It asks for AAS.

[stax76]

Hello everybody,

I'm releasing a new pre-release build today, a pre-release isn't tested by me so potentially has more issues then a beta.

pre-releases are now always full bundles, I created a dedicated public folder on MediaFire which can be found here:

https://www.mediafire.com/folder/0jakce45o99kb/StaxRip_pre-releases

If necessary I can provide a download mirror, free cloud drive providers are problematic because the bundle is 81 MB now so I don't know exactly where else I could upload it.

For the next beta release I'll try to use FossHub as mirror and finally release it on StaxRip's github page to complete the migration from sourceforge to github. I'll try to sync the code on github every time I make a release so github has currently the code for 1.3.1.1.

StaxRip x64 1.3.1.1 pre-release (2015-05-15)


Added DGAVCIndex as AVC TS demuxer, dsmux is still available but disabled by default
Added plugin flash3kyuu_deband v1.5.1
Added QSVEncC hardware decoding bypassing AviSynth and using StaxRip's cut/trim and crop values. On my Win10 development OS it don't work however and I didn't test on Win7
Changed DGIndex to demux and output m2v because DGDecode does not work on Win10, this means the old DVD workflow is fully supported again, MakeMKV is still recommended instead
Instead of always adding AssumeFPS it's now only added if necessary
The Applications dialog was renamed to Apps and Version and Description info was improved (only 50% completed)
Improved AviSynth editor and filter profiles
Improved 'Just Mux' feature supporting more formats
Fixed qaac executed with command window, improved qaac description in applications dialog
Fixed crash in preview window caused by AviSynth, StaxRip shows a error message instead now
Fixed crash caused by stream title containing character that are illegal in windows file system
Fixed two bugs in the 'Execute Command Line' command of StaxRip's command engine which powers StaxRip CLI, various menus and event commands
Updated MP4Box to 0.5.2-DEV-rev376 static mingw build, I made some basic tests which succeeded, Selur said -hint don't work but nobody ever requested -hint support in StaxRip.
Updated MKVToolNix 7.9.0 x64
Updated nnedi3 0.9.4.9 x64, nnedi3 and DGDecNV are now working on Win8 and Win10, DGDecNV 2049 has to be re-downloaded
Updated AVSMeter 2.0.2 x64, the main menu can be customized to add custom CLI switches
Updated qaac 2.48 x64 and improved integration
Updated l-Smash-Works 785 x64