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 30th January 2024, 17:38   #2781  |  Link
VoodooFX
Banana User
 
VoodooFX's Avatar
 
Join Date: Sep 2008
Posts: 990
Quote:
Originally Posted by pinterf View Post
I now have the red Assert saying to change the threshold.
That means you successfully reproduced the bug.

Quote:
Originally Posted by pinterf View Post
The 2nd pass would generate the other txt, which would be this one: xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt
But I don't have such file because of the assert?
Yes.

Quote:
Originally Posted by pinterf View Post
How did you visualize the stacked clip? (where there is the stange clip - the second one from the top?)
When you got the assert:
1) Just rename txt file from "Analyze=-2" to "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt".
2) In the script change to "Show=7"
3) Press or trigger refresh in AvsPmod. -> You should see the bugged clip.

NOTE:
If no bug then in txt file should be written frames numbers/ranges with minmax lower than 15 in chroma & lower than 30 in Y. Because of the bug there are no frames written there.

Last edited by VoodooFX; 30th January 2024 at 18:00.
VoodooFX is offline   Reply With Quote
Old 31st January 2024, 13:08   #2782  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,314
That was a nasty bug. I’d rate it 9 out of 10 on the disgusting factor. It gave me an adrenaline rush but made me mentally empty for the rest of the week.

The bug had impact between sessions. When a program loaded Avisynth.DLL once, then run and reload scripts, e.g. AvsPMod editor. "The first takes everything", whatever script was using TurnLeft for RGB all the later TurnLefts were trying to save the results into RGB planes, even if they were of YUV format. Which of course was resulting in garbage.

Thanks for the challenge.

Avisynth+ 3.7.3post test 14 (20240131 - r4066)
Code:
20240131 3.7.3 r4066
---------------------
- Fix corrupt Turn functions when a planar RGB turn would be followed by a YUV Turn.
  Regression since TurnXXXX supports planar RGB (2016.08.23; probably since r2081 commit dba954e2de0c9c6218d17fc5c4974f4c28b627c3)
  See VooDooFX's AvsInPaint problem at https://forum.doom9.org/showthread.p...53#post1996653
EDIT: pls test, and if it's good enough, then I'm gonna commit the fix to the central git repo
pinterf is offline   Reply With Quote
Old 31st January 2024, 15:09   #2783  |  Link
VoodooFX
Banana User
 
VoodooFX's Avatar
 
Join Date: Sep 2008
Posts: 990
Quote:
Originally Posted by pinterf View Post
That was a nasty bug. I’d rate it 9 out of 10 on the disgusting factor. It gave me an adrenaline rush but made me mentally empty for the rest of the week.

The bug had impact between sessions. When a program loaded Avisynth.DLL once, then run and reload scripts, e.g. AvsPMod editor. "The first takes everything", whatever script was using TurnLeft for RGB all the later TurnLefts were trying to save the results into RGB planes, even if they were of YUV format. Which of course was resulting in garbage.

Thanks for the challenge.
You're welcome.
"test14" - works good, no bug.


Btw, I was hopping that the bug will be related to the two bugs I encountered when I was creating gradients in Y8, mentioned there:
https://forum.doom9.org/showthread.p...19#post1987019


Second bug there aka "Another for official avs" - I couldn't remember how to reproduce it, script was somewhat similar to the first bug, I only remember the effect of it, instead of completely broken gradient (the bottom stacked clip in the example) it had a slight smudge of grey at the bottom of a clip.

Last edited by VoodooFX; 31st January 2024 at 15:14.
VoodooFX is offline   Reply With Quote
Old 31st January 2024, 15:23   #2784  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,314
Quote:
Originally Posted by VoodooFX View Post
You're welcome.
"test14" - works good, no bug.
Itís no surprise that it worked, since I deliberately skipped test13.
pinterf is offline   Reply With Quote
Old 31st January 2024, 18:13   #2785  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
3.7.3...??? Shouldn't be 3.7.4 ?
__________________
My github.
jpsdr is offline   Reply With Quote
Old 31st January 2024, 19:51   #2786  |  Link
VoodooFX
Banana User
 
VoodooFX's Avatar
 
Join Date: Sep 2008
Posts: 990
Quote:
Originally Posted by jpsdr View Post
3.7.3...??? Shouldn't be 3.7.4 ?
"3.7.3post" means post 3.7.3 aka 3.7.4.
VoodooFX is offline   Reply With Quote
Old 5th February 2024, 11:44   #2787  |  Link
rgr
Registered User
 
Join Date: Jun 2022
Posts: 53
During conversion ("ffmpeg -i input.avs output.mp4"), it rarely happens that suddenly the conversion simply stops (no error occurs, the line in ffmpeg simply stops refreshing).

I'm rather sure it's a problem with AviSynth, probably with some filter (I use ffms2, QTGMC, ff3dfilter and lsfmod + a few others like Vinverse).

How can I diagnose what is causing it?
rgr is offline   Reply With Quote
Old 5th February 2024, 14:00   #2788  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
Quote:
Originally Posted by rgr View Post
it rarely happens that suddenly the conversion simply stops
I'm pretty sure it's the "frozen as ice" issue with avstp.dll I faced a long time ago and that Ferenc fixed.

See here: https://github.com/pinterf/mvtools/issues/46

Either update to the new avstp.dll https://github.com/pinterf/AVSTP/releases or get rid of the one you have in the plugins folder.
I'm pretty sure that it will solve the issue

Last edited by FranceBB; 5th February 2024 at 14:03.
FranceBB is offline   Reply With Quote
Old 23rd February 2024, 07:55   #2789  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
speaking of cuda did someone note this https://github.com/vosen/ZLUDA ? did nekopanda Neo plugins work with it?

it was work with intel gpu https://github.com/vosen/ZLUDA/tree/...7afe82892a4163 but now it only work with amd gpu
__________________
See My Avisynth Stuff

Last edited by real.finder; 23rd February 2024 at 08:03.
real.finder is offline   Reply With Quote
Old 23rd February 2024, 10:18   #2790  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,582
Quote:
Originally Posted by real.finder View Post
speaking of cuda did someone note this
Nvidia stated a few days ago that reverse engineering of CUDA is illegal and I donít see a very bright future for that project.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 26th February 2024, 23:12   #2791  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,829
I'm not sure if it's ColorBars or the conversion to YUV, but there appears to be an out of range black. I assume it shouldn't be out of range after the conversion, although as ColorBars outputs limited range RGB, maybe there's supposed to be an out of range black. I don't know, so I thought I'd ask.
Cheers.

The first Image is
ColorBars().ConvertToYV24() with the histogram on top.
The second image is just to show where it is.
ColorBars().ConvertToYV24().Levels(0,2.5,255,0,255,coring=false)
Both color bars are half size.




Last edited by hello_hello; 27th February 2024 at 00:45.
hello_hello is offline   Reply With Quote
Old 27th February 2024, 14:11   #2792  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,546
ColorBars called without any parameters will export RGB32 8bpc PLUGE 7,16,25, and IIRC there is no "limited range RGB", so I would expect this.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingŲage..."
Emulgator is offline   Reply With Quote
Old 27th February 2024, 17:52   #2793  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,829
Good to know. Thanks.
hello_hello is offline   Reply With Quote
Old 28th February 2024, 11:18   #2794  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,075
ColorBars()

Outputs narrow RGB. So White is 235 and Black is 16 as expected in lower stripe for levels check/setup. Also RGB data of 75% amplitude for WYCGRBB colour bars are in 180/16 narrow range.

(180-16)/(235-16) = 0.74885

Also
ColorBars()
PropShow()

correctly displays internal metadata marking:
_ColorRange = 1 = limited
_Matrix = 0 = rgb

Last edited by DTL; 28th February 2024 at 11:28.
DTL is offline   Reply With Quote
Old 17th March 2024, 13:49   #2795  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,496
I may have found a bug with PlanarRGB (32-bit float, at least, I haven't tried any other depths yet). I use this code to re-use the src frame as dst, if it's writeable, or to create a new dst frame (I'm going to overwrite the contents anyway, so I do this to avoid the unnecessary copy that MakeWriteable might do):

Code:
	PVideoFrame src = child->GetFrame(n, env);
	PVideoFrame dst = src->IsWritable() ? src : env->NewVideoFrameP(vi, &src);
The result of this code:

Code:
	int planes[3] = { PLANAR_R, PLANAR_G, PLANAR_B };

	for (int p = 0; p < 3; ++p) {
		debug("%p , %p", dst->GetReadPtr(planes[p]), dst->GetWritePtr(planes[p]));
	}
is always similar to the following:

Code:
00000000116E0A40 , 00000000116E0A40
0000000010C94040 , 0000000000000000
00000000111BA540 , 00000000111BA540
In other words, dst->GetReadPtr(PLANAR_G) returns a valid pointer, but dst->GetWritePtr(PLANAR_G) returns null.

Presumably something to do with this in interface.cpp:

Code:
BYTE* VideoFrame::GetWritePtr(int plane) const {
  if (!plane || plane == PLANAR_Y || plane == PLANAR_G) { // planar RGB order GBR
    if (vfb->GetRefcount()>1) {
      _ASSERT(FALSE);
//        throw AvisynthError("Internal Error - refcount was more than one!");
    }
    return (refcount == 1 && vfb->refcount == 1) ? vfb->GetWritePtr() + GetOffset(plane) : 0;
  }
  return vfb->data + GetOffset(plane);
}
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 17th March 2024 at 13:54.
wonkey_monkey is offline   Reply With Quote
Old 17th March 2024, 14:06   #2796  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,075
It looks was same issue as in DecodeYUVtoRGB - I sometime got bad pointers if using PLANAR_R G B defines. I report it to pinterf but there were no detailed check what happen. So I simply use hand-adjusted numbers to get planes pointers -
https://github.com/DTL2020/ConvertYU...toRGB.cpp#L551

auto dstp_R = dst->GetWritePtr(4);
auto dstp_G = dst->GetWritePtr(6);
auto dstp_B = dst->GetWritePtr(2);

auto dstp_BGRA = dst->GetWritePtr(2);
auto dst_pitch_BGRA = dst->GetPitch();

auto dst_pitch_R = dst->GetPitch(PLANAR_R);
auto dst_pitch_G = dst->GetPitch(PLANAR_G);
auto dst_pitch_B = dst->GetPitch(PLANAR_B);

Though GetPitch() with PLANAR_R G B defines is working OK.

Maybe something is wierd with include headers or some other defines required or other C++ magic.

In the current AVS+ repository https://github.com/AviSynth/AviSynth...visynth.h#L163
enum AvsPlane {
DEFAULT_PLANE = 0,
PLANAR_Y = 1 << 0,
PLANAR_U = 1 << 1,
PLANAR_V = 1 << 2,
PLANAR_ALIGNED = 1 << 3,
PLANAR_Y_ALIGNED = PLANAR_Y | PLANAR_ALIGNED,
PLANAR_U_ALIGNED = PLANAR_U | PLANAR_ALIGNED,
PLANAR_V_ALIGNED = PLANAR_V | PLANAR_ALIGNED,
PLANAR_A = 1 << 4,
PLANAR_R = 1 << 5,
PLANAR_G = 1 << 6,
PLANAR_B = 1 << 7,
PLANAR_A_ALIGNED = PLANAR_A | PLANAR_ALIGNED,
PLANAR_R_ALIGNED = PLANAR_R | PLANAR_ALIGNED,
PLANAR_G_ALIGNED = PLANAR_G | PLANAR_ALIGNED,
PLANAR_B_ALIGNED = PLANAR_B | PLANAR_ALIGNED,
};

So PLANAR_R = 1 << 5,
PLANAR_G = 1 << 6,
PLANAR_B = 1 << 7, is much larger than 2,4,6 but may not work at some use cases as expected with GetWritePtr() calls (from some C++ objects ?) ?

From your part of program text:
something to do with this in interface.cpp:
return (refcount == 1 && vfb->refcount == 1) ? vfb->GetWritePtr() + GetOffset(plane) : 0;

If PLANAR_G processed as it should - there are 2 more ways to fail to zero -
refcount == 1 (not 1)
or
vfb->refcount == 1 (not 1)

So maybe you need to prepare somehow 'dst' pointer (around that 'refcount' C++ magic) before calling GetWritePtr() and system will return finally valid G-plane pointer as vfb->GetWritePtr() + GetOffset(plane) ? Can you build debug build of AVS+ and go with debugger inside GetWritePtr() function to check what is happen with (refcount == 1 && vfb->refcount == 1) ? condition and which of 2 (or both ?) internal 'refcount' variables cause condition to fail ? Or it is really vfb->GetWritePtr() returns zero ptr (and GetOffset(plane) returns zero because G is the first plane in planar RGB as comment notes) ?

Though other interesting question is: If 'dst' object is not in the 'right condition' to call GetWritePtr() method - why R and B planes are not fail call (returning failed zero ptr) ?

Last edited by DTL; 17th March 2024 at 16:01.
DTL is offline   Reply With Quote
Old 17th March 2024, 17:55   #2797  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 452
Quote:
Originally Posted by wonkey_monkey View Post
I may have found a bug with PlanarRGB (32-bit float, at least, I haven't tried any other depths yet). I use this code to re-use the src frame as dst, if it's writeable, or to create a new dst frame (I'm going to overwrite the contents anyway, so I do this to avoid the unnecessary copy that MakeWriteable might do):

Code:
	PVideoFrame src = child->GetFrame(n, env);
	PVideoFrame dst = src->IsWritable() ? src : env->NewVideoFrameP(vi, &src);
IsWritable() - "The rule about writability is this: A buffer is writable if and only if there is exactly one PVideoFrame pointing to it." (from here). If src->IsWritable() return true you do PVideoFrame dst = src and dst is not anymore writable because you have two PVideoFrame pointing to child->GetFrame(n, env).
StvG is online now   Reply With Quote
Old 17th March 2024, 19:04   #2798  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,075
So dst must be pointer first and either point to existing src or create new object with env->NewVideoFrameP(vi, &src) ?

Something like
Code:
PVideoFrame *dst;
if (src->IsWritable()
dst = &src;
else 
dst = &(env->NewVideoFrameP(vi, &src));
?
DTL is offline   Reply With Quote
Old 17th March 2024, 19:14   #2799  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,496
Code:
dst = &(env->NewVideoFrameP(vi, &src));
That seems unsafe. Wouldn't there then be zero real references to the newly-created video frame, because there's no PVideoFrame variable? Maybe:

Code:
PVideoFrame dst;
PVideoFrame *dst_p;
if (src->IsWritable() {
  dst_p = &src;
} else {
  dst = env->NewVideoFrameP(vi, &src);
  dst_p = &src;
}

(*dst_p)->GetWritePtr(...
is safer?

I assume there is some logic to the code in interface.cpp which only does the reference count checks for PLANAR_Y and PLANAR_G, but I don't know what it might be. Unless that's the real bug, that it fails to check on the other planes? And should it throw an exception instead of returning null?
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 17th March 2024 at 19:35.
wonkey_monkey is offline   Reply With Quote
Old 17th March 2024, 19:36   #2800  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 452
Quote:
Originally Posted by DTL View Post
So dst must be pointer first and either point to existing src or create new object with env->NewVideoFrameP(vi, &src) ?

Something like
Code:
PVideoFrame *dst;
if (src->IsWritable()
dst = &src;
else 
dst = &(env->NewVideoFrameP(vi, &src));
?
Just:

Code:
PVideoFrame dst;
if (!src->IsWritable())
  dst=env->NewVideoFrameP();

uint8_t* dstp = (dst) ? dst->GetWritePtr() : src->GetWritePtr;
Edit: Or another way:

Code:
if (!src->IsWritable())
  env->MakeWriteable(&src);

uint8_t* dstp = src->GetWritePtr;

Last edited by StvG; 17th March 2024 at 20:32.
StvG is online now   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 06:18.


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