Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 1st September 2016, 18:32   #2381  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,341
Quote:
Originally Posted by Groucho2004 View Post
Should be 434.
Yup, my encoding has 434 frames. Should have checked before recalling from my bad memory
Wilbert is offline  
Old 2nd September 2016, 20:17   #2382  |  Link
gaak
Registered User
 
Join Date: Apr 2016
Posts: 27
Trying MT mode seems to runs same as single thread mode.

Hi,

In trying AVISynth+ r2085 i386 in MT mode with this script on a 1080p source:

Code:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSource", 3)
LoadPlugin("C:\MKVideo Encoder NV\DGDecNV\DGDecodeNV.dll")
DGSource("C:\MKVideo Files\Input_Video_File.dgi")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
src=last
dr=src.RemoveGrain(4, 2)
src.HQDeringmod(dr, drrep=13, sharp=1, thr=14.0, darkthr=0, Y=3, U=3, V=3)
return(last)
Prefetch(8)
I get the same results (about 6 fps on an i7 930) if I run in single thread mode. What am I doing wrong?

Last edited by gaak; 2nd September 2016 at 20:35. Reason: More specific version info.
gaak is offline  
Old 2nd September 2016, 20:56   #2383  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by gaak View Post
Hi,

In trying AVISynth+ r2085 i386 in MT mode with this script on a 1080p source:

Code:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSource", 3)
LoadPlugin("C:\MKVideo Encoder NV\DGDecNV\DGDecodeNV.dll")
DGSource("C:\MKVideo Files\Input_Video_File.dgi")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
src=last
dr=src.RemoveGrain(4, 2)
src.HQDeringmod(dr, drrep=13, sharp=1, thr=14.0, darkthr=0, Y=3, U=3, V=3)
return(last)
Prefetch(8)
I get the same results (about 6 fps on an i7 930) if I run in single thread mode. What am I doing wrong?
Remove "return last" or move it to the end of the script. Prefetch never gets called.
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 2nd September 2016 at 21:28.
Groucho2004 is offline  
Old 2nd September 2016, 22:03   #2384  |  Link
gaak
Registered User
 
Join Date: Apr 2016
Posts: 27
Quote:
Originally Posted by Groucho2004 View Post
Remove "return last" or move it to the end of the script. Prefetch never gets called.
Thanks!
gaak is offline  
Old 3rd September 2016, 13:36   #2385  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by Wilbert View Post
I imported your script in Virtualdub and compressed it to Xvid but it took me 10 hours on my slow laptop (2.2 GHz).
I just tried the same with Xvid 1.22 and it took 30 seconds. Even on my really ancient laptop it takes only 2 or 3 minutes. Your 10 hours are bizarre.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline  
Old 4th September 2016, 10:37   #2386  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline  
Old 4th September 2016, 15:08   #2387  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,341
Quote:
Originally Posted by MasterNobody View Post
Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.
Some news. The layout of this P010 format is planar luma with packed chroma (see description in the link above, i missed that earlier on). It is actually supported in ffmpeg with the flag AV_PIX_FMT_P010LE:

Quote:
P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
See https://patches.libav.org/patch/60979/ and https://github.com/FFmpeg/FFmpeg/blo...ixdesc.c#L2015. There is no 12/14 bit analog of this format. So it makes sense not to use that in AviSynth.

Last edited by Wilbert; 4th September 2016 at 15:13.
Wilbert is offline  
Old 4th September 2016, 18:23   #2388  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,268
Quote:
Originally Posted by Wilbert View Post
Some news. The layout of this P010 format is planar luma with packed chroma (see description in the link above, i missed that earlier on). It is actually supported in ffmpeg with the flag AV_PIX_FMT_P010LE:


See https://patches.libav.org/patch/60979/ and https://github.com/FFmpeg/FFmpeg/blo...ixdesc.c#L2015. There is no 12/14 bit analog of this format. So it makes sense not to use that in AviSynth.
Huh? We're not using P010, so the lack of 12- or 14- bit variants of it doesn't matter. The 10-bit formats we're using are the all-planar ones: YUV(A)***P10, GBR(A)P10. Or YUV(A)***P12/14, GBR(A)P12/14, respectively. To my understanding, P010 is mostly a format used by graphics cards and screen output types of jobs, not one that should be getting used for practically anything else. It's like NV12/NV21.

And the patch to add the new pix_fmts to FFmpeg's AviSynth demuxer was already committed close to a week ago. The planar RGB formats and ConvertTo16bit's 10/12/14 conversions don't quite work yet; you need the pull request that pinterf is currently working on for those to be fixed on our side, plus another patch that's on the FFmpeg-devel mailing list to make sure the Planar RGB formats are output correctly.

Zeranoe's FFmpeg-git builds should work with them just fine now, with the caveats I mentioned above. However, you can get proper 10/12/14 YUV output if you use f3kdb or Dither to scale them up and then ConvertFromDoubleWidth/Stacked. The alpha-enabled formats and Planar RGB were a deeper issue that had to be resolved by exposing them through the C interface first (r2172 doesn't do that yet, that's why the pull request's changes are needed).

Last edited by qyot27; 4th September 2016 at 18:30.
qyot27 is offline  
Old 4th September 2016, 18:45   #2389  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,341
Quote:
Originally Posted by qyot27 View Post
Huh? We're not using P010, so the lack of 12- or 14- bit variants of it doesn't matter. The 10-bit formats we're using are the all-planar ones: YUV(A)***P10, GBR(A)P10. Or YUV(A)***P12/14, GBR(A)P12/14, respectively. To my understanding, P010 is mostly a format used by graphics cards and screen output types of jobs, not one that should be getting used for practically anything else. It's like NV12/NV21.
I know you are not using P010. I was explaining to MasterNobody why it is not used. At first i thought (and i guess MasterNobody too) that the only difference was the location of the zero padding, but as you repeated the chroma is packed too in P010.

Last edited by Wilbert; 4th September 2016 at 19:23.
Wilbert is offline  
Old 4th September 2016, 19:41   #2390  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,850
Hi, just a short project report on the high bit depth part.

Probably you know, that instead of the the original plans (YUV 16 bit/float 4:2:0, 4:2:2 and 4:4:4) we finally decided to support more formats.

Avisynth core got support (at least on my workbench) for
- YUV 10-12-14 bits (and of course the 16 bit and float format)
- RGB48 and 64 (RGB24 and RGB32 16-bit counterparts)
- Planar RGB and Planar RGBA (8-10-12-14-16 bit integers and float)
- YUVA (YUV with a 4th alpha channel) with the same options as YUV.

Most of the filters and functions are ported and support all these new formats.

Not much left
- Invert
- Overlay and Mask filters (all)
- SkewRows (not priority)
- GeneralConvolution for RGB32

And there are planned refinements.
- There should be only one bitdepth converting function, instead of existing ConvertTo8bit/16bit/Float
- Dithering for 8/10 bit conversion
- more functions to use SIMD (SSE2)

Some filters that are working with lookup tables internally (Limits, RGBAdjust) are not available for float video formats.

10-14 bit formats are mainly for export/import, but a few filter can already use them natively (Limits, RGBAdjust, text-overlay, etc)

That's all for now, the work is going on...
pinterf is offline  
Old 4th September 2016, 22:04   #2391  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Different exception behaviour with/without Prefetch

This applies only to AVS+ 64 bit. Test release: r2172

Script:
Code:
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(50, 1)
Dummy()
"Dummy()" is my test plugin that simply triggers a 0xC0000094 / STATUS_INTEGER_DIVIDE_BY_ZERO exception, download here

AVSMeter reports the correct module:
Code:
AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2172, MT, x86_64) (0.1.0.0)

Exception 0xC0000094 [STATUS_INTEGER_DIVIDE_BY_ZERO]
Module:   E:\Apps\VideoTools\AVSPlugins\AutoLoad64\Dummy64.dll
Address:  0x0000000004CE14A5
However, if I put "Prefetch(x)" at the end of the script, this is the result:
Code:
AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2172, MT, x86_64) (0.1.0.0)

Exception 0xC0000094 [STATUS_INTEGER_DIVIDE_BY_ZERO]
Module:   D:\WINNT\system32\kernel32.dll
Address:  0x0000000077D67DDD
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline  
Old 4th September 2016, 22:10   #2392  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,381
May be interesting in which system function. Possibly in a threading management routine? That may require a detailed crash dump with stack trace.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline  
Old 4th September 2016, 22:23   #2393  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by LigH View Post
May be interesting in which system function. Possibly in a threading management routine? That may require a detailed crash dump with stack trace.
Well, AVSMeter catches the exception so there is no crash dump.
I'll try with MPC-HC.

Edit: MPC-HC crash dump
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 4th September 2016 at 22:33.
Groucho2004 is offline  
Old 5th September 2016, 00:41   #2394  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,381
You might add the *.pdb file for access to symbols ... but the appearance of "ntdll!NtWaitForMultipleObjects" and "kernel32!ReleaseSemaphore" in the stack trace seem to support my suspicion that the thread scheduling gets disturbed by the exception. Yet, I am no expert, so no warranties...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline  
Old 11th September 2016, 04:22   #2395  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,268
A couple previous posts of mine getting clarified:
Quote:
Originally Posted by qyot27 View Post
I have some weird results with the MinGW builds. None of them - a cross-compiled AviSynth+ built under Ubuntu with MinGW-w64 4.0.6 and GCC 6.1.0, one built under msys2 with GCC 5.4.0 (I don't know which MinGW-w64 version), or the build ultim provided above - works with FFmpeg. However, the msys2 build and ultim's do at least have FFmpeg error out the same way it does if the proper MSVC runtime can't be found, while the one built on 6.1.0 just up and crashes.

I think part of it might have to do with function decorations. Or compiler optimizations that I tried enabling on the 6.1.0 build. It'll get worked out eventually.
This was almost certainly the capi.h issue MasterNobody brought up.

I attempted it from a different angle, and that's if the ifdef was changed to accept MSVC OR MINGW, then the MinGW-GCC build of AviSynth+ with that change and the build of Libav depending on that header were suddenly okay (so long as I kept the autoload folders empty of .dlls).

Unfortunately, the MinGW-GCC build of FFMS2's C plugin did not work, likely because it was using a much older version of the header. So C plugins will probably need to update against it to work right as well. Whether they'll remain backward compatible with AviSynth 2.6 in that case, I don't know. I also didn't test MSVC builds against the expanded ifdef, so those might still fail to work.

All that to say, it's encouraging that a program that uses the C interface to talk to AviSynth can indeed use MinGW-GCC builds of AviSynth+. It's still early in fleshing out the support there (since there's bound to be conflicts to hammer out), but at least there's confirmation that one configuration of it actually works.

Quote:
Originally Posted by qyot27 View Post
Also, it would appear that VS2015 builds work with Wine 1.9.17 now, if msvcp140.dll is specifically overridden to native,builtin in winecfg and the VS2015 redist is installed. The only issue is, that version of Wine is still -devel, so it may not be a good idea yet to rely on (and if we want a 'just works' solution there before dropping VS2013, it probably shouldn't require overrides or installing the redist package).
I spoke a bit too soon on this. 32-bit builds work as I described there, but Wine 1.9.x is still not compatible with the 64-bit builds, even if you've installed the 64-bit VS2015 redist.
qyot27 is offline  
Old 13th September 2016, 14:07   #2396  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
mergechroma and rgbadjust are bugged only for me?
__________________
powered by Google Translator
Motenai Yoda is offline  
Old 14th September 2016, 13:14   #2397  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,850
Quote:
Originally Posted by Motenai Yoda View Post
mergechroma and rgbadjust are bugged only for me?
Last week I was working on porting RgbAdjust to RGB48/64 and planar RGB 8-16 bit formats and found a bug, that would cause buffer overflow when creating the lookup table.
If you specify dither=true, it should not occur.

What is the problem with MergeChroma?
pinterf is offline  
Old 14th September 2016, 22:31   #2398  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
Quote:
Originally Posted by pinterf View Post
Last week I was working on porting RgbAdjust to RGB48/64 and planar RGB 8-16 bit formats and found a bug, that would cause buffer overflow when creating the lookup table.
If you specify dither=true, it should not occur.
thanks
Quote:
Originally Posted by pinterf View Post
What is the problem with MergeChroma?
the weight part on yv12
__________________
powered by Google Translator

Last edited by Motenai Yoda; 14th September 2016 at 23:11.
Motenai Yoda is offline  
Old 14th September 2016, 23:05   #2399  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,001
Possibly connected to AVS Standard MergeChroma problem, here:- http://forum.doom9.org/showthread.ph...31#post1504231
Was originally
Code:
MergeChroma (clip1, clip2, float Chromaweight=1.0)
IanB Added Alias
Code:
MergeChroma (clip1, clip2, float weight=1.0)
Perhaps it did not make it into AVS+

EDIT: And MergeLuma used LumaWeight, also added the Weight alias. [EDIT: About v2.6 Alpha 3, period].

EDIT: @ Motenai Yoda Below post:
OK, I think you just added the stuff in blue,
Quote:
the weight part on yv12.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 19th September 2016 at 12:18.
StainlessS is offline  
Old 14th September 2016, 23:18   #2400  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
@StainlessS doesn't seems the same issue
__________________
powered by Google Translator
Motenai Yoda is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:25.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.