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

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th February 2018, 05:10   #441  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 662
Quote:
Originally Posted by real.finder View Post
since the native 16 bit is slower than lsb, even with this https://forum.doom9.org/showthread.p...23#post1833823 it's little faster but still way slower than the lsb method

can mdegrain has "bits" parameter? so it can be used instead of lsb with avs+
IIRC lsb isn't 16bit processing but 8bit input -> 16bit output
also you can use ie convertbits(10,dither=1) before mdegrain stuff and convertbits(16) after.
also having a rounding option other than truncate/dithering options will be good.
__________________
powered by Google Translator

Last edited by Motenai Yoda; 20th February 2018 at 05:12.
Motenai Yoda is offline   Reply With Quote
Old 20th February 2018, 14:33   #442  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 912
Quote:
Originally Posted by Motenai Yoda View Post
IIRC lsb isn't 16bit processing but 8bit input -> 16bit output
also you can use ie convertbits(10,dither=1) before mdegrain stuff and convertbits(16) after.
also having a rounding option other than truncate/dithering options will be good.
yes in mvtools there are only lsb output, 8 input 16 lsb output

the bits parameter will do same thing with bits=16, and it's should be faster than lsb, and can use another bit setting like 12 for more speed, and can use 10 bit clip (for 10 bit source and output 16 bit or any other depending on the settings) or others, let see what pinterf say
__________________
My Avisynth Stuff

Last edited by real.finder; 20th February 2018 at 14:36.
real.finder is offline   Reply With Quote
Old 20th February 2018, 18:22   #443  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 861
Quote:
Originally Posted by real.finder View Post
since the native 16 bit is slower than lsb, even with this https://forum.doom9.org/showthread.p...23#post1833823 it's little faster but still way slower than the lsb method

can mdegrain has "bits" parameter? so it can be used instead of lsb with avs+
Open doors.

Since I had found the reason of another mysterious crash, namely 64bit x264 exited when a specific Qtgmc + Tivtc script was used. The culprit was an ancient assembler mmx code used in MSuper. This code did not clear mmx state, as the original asm code did not issue emms, and the Microsoft x64 mode lacks _mm_empty() command (unlike the Intel compiler possibly used in the 2.6.0.5 era). The result was a crash, x264_64.exe probably was conflicted with the non-restored FPU/MMX states.

So after having inserted the missing 'emms' instruction it became rock solid. But I was so angry on MSuper's mmx heritage that I started to backport the sse2 intrinsic rewrite from VapourSynth mvtools. Then I added 10-16 bit sse2 versions. So MSuper is much faster now in 16bits (50+%).

As a side-effect MSuper now works in 32bit float (no SSE2 yet).

Having a 32 bit float MSuper, I was wondering what happens in a 32bit float MDegrain? (Primarily to see that the 16bit-mode color shift would be seen in 32bit mode, using the artifical example in the previous posts)

I made MDegrain able to use arbitrary bit-depth Super clip with vectors created in 8-16 bit mode.
For example we can have vectors created in 16 bit mode and use MDegrain2 on a 32bit float clip by simply passing a 32bit Super clip for MDegrain.

I have to clean up the code, there was quite a bit of work with implementing these features.

And I still need to run tests because 8 bit MDegrain with overlaps uses a strange rounding but since it exists in the C code and used in the asm assembler files also (copy paste?), I need to know whether it is intentional on a bug.
There is a 11 bit precision integer arithmetic that is converted back in two steps: lose first 6 bit (,sum up them) then lose 5 bits.

In 16 bits (and stacked) mode: final_pixel = (x + 1024) / 2048
In 8 bit: final_pixel = ((x + 256) >> 6) >> 5
I don't think the latter is correct. It results an 0.125 increase on average in the final pixel values.

Probably it should be: final_pixel = ((x + 32) >> 6) + 16) >> 5 ?
pinterf is offline   Reply With Quote
Reply

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 00:34.


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