Median() plugin

[ajk]

Hi, should be fairly straightforward, but I haven't been doing much with this recently and haven't got the development environment set up. I may look at this in the future myself, but if anyone can add support in the mean time I'll be happy to include and host the changes.

[pinterf]

Just a note: instead of RGB64 I recommend a generic planar RGB support.

[TomArrow]

Okay, so I managed to open the solution of the Median 0.6 src in VS 2017. Retargeted to v141 toolset (because that's the lowest I can use in VS2017 I think) and it compiled just fine.

Now, I have some very basic coding knowledge, but I've never done any AviSynth plugins, not even worked on one. Can someone point me in the right direction on how to add RGB64 support?

Edit: I have now even managed to update the code to the v6 API (hurray me!), so I'm mildly optimistic I will somehow be able to hack this together. :D

Edit 2: I DID IT! Well, it's not perfect I'm sure, but it works. Got some help from some C++ Discord. Well, technically they wrote half of it, but hey, at least it's done.

Source is attached, compiled x86 DLL is here: https://www.mediafire.com/file/qe56dtuz1ntz5m4/Median-0.6-AVS+-withRGB64support.zip/file

Now, if only I knew how to extend the solution to be able to compile a 64 bit version too ... because my avs-file has become so bloated that it only manages to output 2 frames before getting a memory error. :P

But hey, it's AVS+ headers now, so maybe someone can tune in and add 64 bit support? That'd be splendid. Or tell me how to do it and I'll do it.

[TomArrow]

Damn, I think I found some errors in the code, better don't use the one I posted, it may not be actually doing a real Median. gotta wrap my brain around this...

Edit: Nevermind, false alarm.

[TomArrow]

Alriiight. Finally, here we are. Wasn't so hard doing the x64 after all.

So in summary, these files:
- Support RGB64 (but not the fast processing mode that's supported in the 8-bit color spaces)
- Implement the new AviSynth+ API (V6)
- Have both 32 bit and 64 bit platforms set up for VS 2017 (not sure if backwards compatible for older VS versions, but maybe?)

The way I did it might not be the most elegant way, so feel free to improve on my work, I'm a newbie after all.

Enjoy, and thanks again for the original work on this plugin. :)

[ajk]

Great! I haven't gone through the code in detail but looks fine to me. Should I upload your work in with the other versions so everything is hosted in the same place?

[TomArrow]

Great! I haven't gone through the code in detail but looks fine to me. Should I upload your work in with the other versions so everything is hosted in the same place?

Sounds like a good idea. :)

[ajk]

Done - I added a very short readme which contains a link to your post above :)

[TheGenesis]

Wow!!!

Thats an impressive approach.

I have always tried to cleanup my 30 years old Betamax tapes wich I had recorded using a surveillance camera (b/w tube sensor) but couldn't get rid of the noisy line jitter without loosing sharpness.
Yesterday i captured the same sequence 6 times and used MedianBlend() with cutting the lowest and highest outliners. The results are phenomenal. 80% of the noise are gone without any loss on the edges.

Many thanks to ajk and all you guys for making this happen!

[ajk]

Very nice to hear you have had success with this method! Got any before/after shots you could share?

I finally managed to get all of my own Hi8 tapes captured, it is definitely pretty labor intensive to deal with multiple lossless captures, but worth it in the end for important tapes.

[TheGenesis]

I'm not done yet. Trying to repair some other issues, such as "replacing only dead parts of a frame" and a watermark wich was burned in the camera sensor.
btw... you have made yourself a hard time lining up multiple captures by hand. I stumbled over a great filter to automate this:

https://forum.doom9.org/showthread.php?p=580999#post580999

That allows you to syncronize multiple peaces and the only thing you have to do is cutting them near the same start and end frame.

LoadPlugin("c:\Program Files\AviSynth\plugins.manual\matchclips.dll")

LoadPlugin("c:\Program Files\AviSynth\plugins.manual\Median.dll")

source1=AviSource("Cap0914_002_topO_RAW.avi" , audio=false).ConvertBackToYUY2()
source2=AviSource("Cap0912_003_mainO_RAW.avi", audio=false).ConvertBackToYUY2()
source3=AviSource("Cap0912_002_main_RAW.avi" , audio=false).ConvertBackToYUY2()
source4=AviSource("Cap0912_001_main_RAW.avi" , audio=false).ConvertBackToYUY2()
source5=AviSource("Cap0914_003_topO_RAW.avi" , audio=false).ConvertBackToYUY2()
source6=AviSource("Cap0914_001_top_RAW.avi" , audio=false).ConvertBackToYUY2()

cntSeekPrev=20
cntSeekNext=80

clip1=source1
clip2=mcshowframe(source1,source2,mcanalyse(source1,source2,cntSeekNext,cntSeekPrev))
clip3=mcshowframe(source1,source3,mcanalyse(source1,source3,cntSeekNext,cntSeekPrev))
clip4=mcshowframe(source1,source4,mcanalyse(source1,source4,cntSeekNext,cntSeekPrev))
clip5=mcshowframe(source1,source5,mcanalyse(source1,source5,cntSeekNext,cntSeekPrev))
clip6=mcshowframe(source1,source6,mcanalyse(source1,source6,cntSeekNext,cntSeekPrev))

# Discard highest and lowest value and average the remaining ones
#return( MedianBlend(clip1,clip2,clip3,clip4,clip5,clip6, low=1, high=1) )

StackVertical(
\ StackHorizontal(
\ StackHorizontal(
\ clip1
\ ,clip2)
\ ,clip3)
\ ,
\ StackHorizontal(
\ StackHorizontal(
\ clip4
\ ,clip5)
\ ,clip6)
\)

The last line is only to visualize the synchronisaton on all clips.

[ajk]

Looking forward to seeing your results!

The latest version of my plugin actually has an automatic sync feature. It didn't get discussed much here on Doom9 but there are some samples over at VideoHelp: https://forum.videohelp.com/threads/362361-Median()-plugin-for-Avisynth#post2418590

It's still best used with care, as with static scenes the noise can have a larger effect on the calculated difference than the actual content. I use it semi-manually, first with debug output activated and a large search radius to get the clips aligned, then dialed down to just a radius of 1 or 2 to take care of any remaining drops. This approach worked very well with my Hi8 tapes at least.

[TheGenesis]

Puh! ... that was harder than i thought.

The automatic from MatchClips is not accurate enought ... neither your sync-feature.
But its not your fault ... I have discovered, that the material I'm working with has parity-swaps all over the place ... I had to manually align the hole clip (84min) ... urgs.
Finally I reverted back to Median() because it preserves more details and doesn't fool my deinterlacer to interpolate jumpy fields in between :)

Here the results:

http://genesis-web.de/updown/BEFORE_6444-6823_crf24.mp4

http://genesis-web.de/updown/AFTER_6444-6823_crf14.mp4

each file is about 2MB in size.
I had to squeeze the source material into crf24 ... crf14 produces a 17MB file :)

[johnmeyer]

I first experimented with multiple VHS captures about the time you joined this forum (2002). It works great, but all the field changes ("parity changes") at scene changes are a killer.

When it works, it is one of the greatest noise reduction techniques around, because there are virtually no residual artifacts, and the result looks really natural.

However, after trying it on a few tapes, I gave up because between the time it took to do three captures and the time it took to align everything, I was spending half a day on just one tape.

Your results look impressively good, but was all of the improvement nothing more than averaging multiple captures? It seems like you got rid of time base errors and also a fair amount of vertical jitter.

[TheGenesis]

Indeed this is not only cleaned up by averaging. But aligning and averaging was essential to minimize the jitter. Also it increases about 30% of the details for the final filter.
I have done this with multiple steps:

First I made myself a script for the manual alignment that is very fast (if you have a bunch of cores) and aligned my 6 captures.
Then I separately median() the fields (with sync=0) and store the weaved() result lossless to disk.
After that I corrected the lightning errors by tuning the Y-offset, Gamma and Blacklevel,
I manually created a good noise profile of the material to feed into Neat().
I'll tuned QTGMC(), wrote a script to damp the bouncing() even more and finally ran the folowing Script:

#
# EdiusNX-capture.avs
#

SourceFile="SOURCE\Tape1\Tape1_fields.avi"
NeatDeviceNoiseProfile="SecurityCam_SLF30_ES10_EdiusNX.dnp"
NeatNoiseFilterPreset="SecurityCam_SLF30_ES10_EdiusNX.nfp"

# Audio has to be delayed by 120ms when using an ES10 for stabilizing Video (and passing the Audio direct to the capture device)
CompensateForAudioDelay=120

ColorMatrix="Rec601" # Rec709
IsInterlaced=true

NeatTemporalRadius=5

# begin script ...

SetMemoryMax(900) # VD
SetMTMode(3,4)


LoadPlugin("c:\Program Files\AviSynth\plugins.manual\ThreadRequest.dll")

LoadVirtualDubPlugin("C:\Tools\Windows\VirtualDUB\plugins32\NeatVideo4.vdf", "NeatVideo", 5)

LoadPlugin("c:\Program Files\AviSynth\plugins.manual\masktools-v2.2.18\masktools2.dll")

LoadPlugin("c:\Program Files\AviSynth\plugins.manual\depanestimate110\DePanEstimate.dll")
LoadPlugin("c:\Program Files\AviSynth\plugins.manual\depan1131\DePan.dll")

Import("c:\Program Files\AviSynth\plugins.manual\QTGMC.avsi")
Import("c:\Program Files\AviSynth\plugins.manual\SMDegrain.avsi")
LoadPlugin("c:\Program Files\AviSynth\plugins.manual\RemoveGrain-1.0\RemoveGrainSSE3.dll") # ???old???
LoadPlugin("c:\Program Files\AviSynth\plugins.manual\mvtools-2.7.41-with-depans\mvtools2.dll")
LoadPlugin("c:\Program Files\AviSynth\plugins.manual\nnedi3\nnedi3.dll")
LoadPlugin("c:\Program Files\AviSynth\plugins.manual\RgTools-0.98\RgTools.dll")

Import("c:\Program Files\AviSynth\plugins.manual\CaptureTools.avsi")


AviSource(SourceFile, audio=false)
AssumeFrameBased
SetMTMode(2)
VideoFPS=last.FrameRate

last + BlankClip(last, length=(NeatTemporalRadius+1) ) # append blank frames for neat-prefetch

#Trim(3000,0)

AssumeTFF()

# Correct Luma-Errors
ThreadRequest()
ColorYUV(off_y=-14, gamma_y=-40) # Reduce overshooten brightness and enhance contrast (to preserve details in further processing)
Levels(16, 1.0, 255, 0, 235) # compensate for blackness
#return(last)

# Convert to RGB
ThreadRequest()
ConvertToRGB(matrix=ColorMatrix, interlaced=IsInterlaced)
#return(last)

# Denoise and Sharpen
ThreadRequest()
SetMTMode(6)
NeatVideo(NeatDeviceNoiseProfile, NeatNoiseFilterPreset)
SetMTMode(2)
#return(last)

ThreadRequest()
ConvertBackToYUY2()
ConvertToYV12()
#return(last)

# Deinterlace (high quality)
ThreadRequest()
QTGMC( Preset="Slow", EdiThreads=3, TR2=1, EZDenoise=0, NoiseProcess=0, Sharpness=0.4, FPSDivisor=1) # FPSDivisor=1 for double fps # ,Lossless=1 preserves original fields and also their mosquito noise on edges
#return(last)

# Stabilize Frame-Bouncing
ThreadRequest()
StabHomeCorner(dxmax=0, dymax=3)
#return(last)

# Crop off capture defects
ThreadRequest()
Crop(12,6,-12,-6)
#return(last)

# uphold A/V sync
trimFrames = int(last.FrameRate/VideoFPS) * (NeatTemporalRadius+1) # Remove neat-buffer-frames
trimFrames = trimFrames + int(last.FrameRate*CompensateForAudioDelay/1000)
trimFrames > 0 ? last.Trim(trimFrames, 0) : \
trimFrames < 0 ? BlankClip(last, length=(trimFrames*-1) )+last : last

########################################
# force SYNC (if M1 crashed, try M2) #
#SetMTMode(6) # Method1 -> Switch MT #
Distributor() # Method2 -> Insert Task #
return(last) # RETURN #
########################################

[johnmeyer]

OK, so you've done a huge amount of additional noise filtering. Since you ran both Neat and QTMGC, probably very little of the change between the original and final actually came from the median averaging of the six captures.

[TheGenesis]

As I said ... about 30% more Details/sharp edges (reduces mosquito noise) and without averaging I also couldn't get rid of the jitter.

I'll tried all sorts of combination ... I'd like to use alternates to Median(), but because of the parity switches (wich are still present in my first stage) this filter is the only one who can deliver frames wich will not end up in jerkiness when running through the deinterlacer.

For reference ... here is the apples to apples comparision without any postprocessing:

http://genesis-web.de/updown/BEFORE_6444-6823_unfolded_crf18.mp4
http://genesis-web.de/updown/AVERAGED_6444-6823_unfolded_crf18.mp4

I could write a script where every single frame from the master will be temporal syncronized in the slave, but this is overkill compared to the expected gains.

What I really would like is getting rid of the burned-in "watermark" from the camera but this is even not a trivial task :)

[Spongology]

I hardly work using windows desktop programming and is not so familiar about all these.

[TheGenesis]

In theory this "should" be not as hard.
You have a source and one frame with the watermark.
Then you have to subtract that watermark from the source.

lol ... actually there are a few rules to deal with or else you ruin you source.

One attempt I made was this:

WatermarkRAW = AviSource("Burn-In Watermark.avi").Trim(0,-1)
Black = WatermarkRAW.BlankClip(length=1)
Watermark = WatermarkRAW.Levels(136, 1, 255,0, 255) # mask -> only bright areas of watermark must be used to opage the black frame over the source
Overlay(last, Black, mask=Watermark, mode="multiply")

The problem is, that this is not dynamic enough. The watermark in the source clip only shows up in areas below a certain luminance threshold and only this areas have to be subtracted.
The approach above does this everywhere thus creating invers watermarks where they weren't in the first place :)

[pinterf]

Hi, could you tell me which license is used for the source? I was kindly asked to make it work under linux but since I'm using github I have to specify a license mode. Should I use the same licencing as Avisynth or MIT or what? Thanks.
(And let me know if all this port is done by someone else, let's not work twice :) )

[ChaosKing]

See filter.cpp
//////////////////////////////////////////////////////////////////////////////
// Median filter for AviSynth
//
// This filter will take in a number of clips and calculate a pixel-by-pixel
// median out of them. This is useful for reducing noise and glitches in
// analog tape captures, but may have other uses as well.
//
// Author: <email removed>
//
// License: Public domain. Credit would be nice, but do with this what you will.
//
// Forum thread: http://forum.doom9.org/showthread.php?t=170216
//
// History:
// 12-Feb-2014, 0.1: Initial release. YUY2 support only
// 13-Feb-2014, 0.2: Added support for RGB and planar formats
// 13-Feb-2014, 0.3: Fixed output frame buffer issue
// 14-Feb-2014, 0.4: Added MedianBlend functionality
// 15-Mar-2014, 0.5: Added TemporalMedian functionality

Btw there is also a Vapoursynth port https://github.com/dubhater/vapoursynth-median
and another filter written in rust here https://github.com/End-of-Eternity/vs-average

[kedautinh12]

I seen had a ported but not too much
https://forum.doom9.org/showpost.php?p=1864406&postcount=55

[Reel.Deel]

(And let me know if all this port is done by someone else, let's not work twice :) )

Aside from the VS ports posted above, TomArrow added RGB48/64 (post #55) but there was another version (also from TomArrow) that had an additional parameter. I just cannot find it at the moment, I believe it was over at Fanres forums.

Maybe TomArrow can chime in.

[real.finder]

name change also necessary since there are http://www.avisynth.nl/users/vcmohan/manyPlus/Median.html

[ajk]

@pinterf

Yes, public domain so use as you wish. If it is necessary to apply a license, feel free to choose the same model as Avisynth.

@ChaosKing

Could you please edit your post to remove my email address, I don't want to attract any more spam than already comes in :)

[Orikson]

First of all, thank you ajk and everyone involved in developing and testing this great plugin! I'm currently capuring my old Video8 tapes to the PC and have great results with it!

I just came over one improvement, that might be great to be done.

I'm capureing my analog signal with 10 Bit color depth so I can deal with any rounding error that might occur during capture and processing. This works fine, but unfortunatelly the median()-plugin only works with 8-bit color depth. I guess so, because the processed video shows a lot of "artefacts". I could explain this due to the 10 bit values stored in a too small variable (e.g. 8 bit) by the median()-plugin which will then cause an overflow. Calling the command ConvertBits(clip, 8) before the median()-command will fix this issue, but of course will get rid of the 10-bit color depth, which might already be handy during the mean calculation done by median().

Am I right with my assumption? I'm not too new to programming and took a look into the source code of your plugin. But I'm more into programming embedded electronics, so it's still hard for me to improve the code. Could you give me a hint about this problem?

[ChaosKing]

Both VapourSynth median plugins support 10 bit https://forum.doom9.org/showthread.php?p=1953377#post1953377
It is possible to use VS inside avisynth with http://avisynth.nl/index.php/VapourSource

[kedautinh12]

You can try:
Convertbits(16)
converttorgb64()

Before use this ver
https://forum.doom9.org/showpost.php?p=1864406&postcount=55

[Orikson]

Ok thank you, I will try that :thanks:

[ajk]

@Orikson

Yeah, indeed no 10-bit support in the original plugin, but please have a look at those options mentioned by others. Report back if you have success, I'm sure others might benefit from the information in the future :)

[pinterf]

https://github.com/pinterf/AjkMedian
No windows zip release (didn't have 20 more minutes), just a quick and minimal mod in order to build it under Linux/gcc as well.
The file name of DLL was renamed to AjkMedian and DLL has version info (v0.7)
And a single addition: plugin is able to let through frame properties.

[Orikson]

Report back if you have success, I'm sure others might benefit from the information in the future :)

Sure I will, but until now I could not figure out how to get this working :eek:

I gave up on VapourSynth after one day of trying. I guess I could get it working when switching completelly to VS. But now I'm already more into AviSynth and also are afraid of the "documentation" of VS :rolleyes:

So I tried the solution kedautinh12 suggested, even though I do not like the fact that I might need to do two color format conversations (YUV to RGB and back to YUV for output)...
You can try:
Convertbits(16)
converttorgb64()
Before use this ver
https://forum.doom9.org/showpost.php?p=1864406&postcount=55

The first format conversion seem to work and only causes some rounding errors. So I continued to use the median-Plugin on the converted clips but did not get a good result. The debug information was missing and the video was blury, especially during camera movements, see attatched file.

Am I doing something wrong here or is the RGB64 median plugin still buggy somehow? :confused:

clip1 = AVISource("video1.avi")
clip2 = AVISource("video2.avi")
clip3 = AVISource("video3.avi")
clip4 = AVISource("video4.avi")

/*
# - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Include this section to align the frames of all clips
clip1 = ShowFrameNumber(clip1, scroll=true)
clip2 = ShowFrameNumber(clip2, scroll=true)
clip3 = ShowFrameNumber(clip3, scroll=true)
clip4 = ShowFrameNumber(clip4, scroll=true)
*/

# - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Actually set the correct start and end frame of all clips
clip1 = Trim(clip1, 482, 0, pad=true)
clip2 = Trim(clip2, 190, 0, pad=true)
clip3 = Trim(clip3, 459, 0, pad=true)
clip4 = Trim(clip4, 378, 0, pad=true)

# - - - - - - - - - - - - - - - - - - - - - - - - - - - -
clip1_8bit = ConvertBits(clip1, 8)
clip2_8bit = ConvertBits(clip2, 8)
clip3_8bit = ConvertBits(clip3, 8)
clip4_8bit = ConvertBits(clip4, 8)

median_result_8bit = MedianBlend(clip1_8bit,clip2_8bit,clip3_8bit,clip4_8bit, chroma=true, low=1, high=1, sync=5, debug=true)

# - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Converted to RGB for comparison

clip1_RGB64 = ConvertBits(clip1, 16)
clip1_RGB64 = ConvertToRGB64(clip1_RGB64, matrix="Rec601", interlaced=true)

clip2_RGB64 = ConvertBits(clip2, 16)
clip2_RGB64 = ConvertToRGB64(clip2_RGB64, matrix="Rec601", interlaced=true)

clip3_RGB64 = ConvertBits(clip3, 16)
clip3_RGB64 = ConvertToRGB64(clip3_RGB64, matrix="Rec601", interlaced=true)

clip4_RGB64 = ConvertBits(clip4, 16)
clip4_RGB64 = ConvertToRGB64(clip4_RGB64, matrix="Rec601", interlaced=true)

median_result_RGB64 = MedianBlend(clip1_RGB64,clip2_RGB64,clip3_RGB64,clip4_RGB64, chroma=true, low=1, high=1, sync=5, debug=true)

# - - - - - - - - - - - - - - - - - - - - - - - - - - - -
return median_result_8bit # result is ok, debug working, but only 8-bit
return median_result_RGB64 # blury/jumping result, debug not working

[Reel.Deel]

There are some inconsistencies in your script:

median_result_8bit = MedianBlend(clip1_8bit,clip2_8bit,clip3_8bit,clip4_8bit, chroma=true, low=1, high=1, sync=5, debug=true)

median_result_RGB64 = Median(clip1_RGB64,clip2_RGB64,clip3_RGB64,clip4_RGB64, chroma=true, low=1, high=1, sync=5, debug=true)

Median does not have the low and high parameters, you should of gotten an error if that is how you're actually using the script.

Also, please host the picture elsewhere, sometimes it takes forever and a day for the attachments to get approved here.

[StainlessS]

Also, please host the picture elsewhere, sometimes it takes forever and a day for the attachments to get approved here.

How To post an image that appears in forum post, does not depend upon moderator approval of image (attachments sometimes never get moderator attention).
https://forum.doom9.org/showthread.php?p=1959414&highlight=postimage#post1959414

[poisondeathray]

Likely not related to those overflow artifacts , but don't forget interlaced=true when performing ConvertToRGB64

[Orikson]

Likely not related to those overflow artifacts , but don't forget interlaced=true when performing ConvertToRGB64
Thank you for that reminder, but adding this does not change anything in my case

Median does not have the low and high parameters, you should of gotten an error if that is how you're actually using the script.
You are totally right, the Median (without Blend) happened while I was playing around and of course causes an error. I updated the code in my post above. Also I uploaded the image here:

https://i.postimg.cc/06KWtzCW/RGB64-median-blur.png (https://postimg.cc/06KWtzCW)

[Reel.Deel]

@Orikson

I'm not sure why it's not working for you but I made a synthetic test and the output is correct:

LSMASHVideoSource("YUV420P8.mp4")

a = AddGrainC(var=1.0, seed=1).Trim(1,0).ConvertToRGB64(matrix="PC.601")
b = AddGrainC(var=7.5, seed=2).Trim(2,0).ConvertToRGB64(matrix="PC.601")
c = AddGrainC(var=15.0, seed=3).Trim(3,0).ConvertToRGB64(matrix="PC.601")
d = AddGrainC(var=30.0, seed=4).Trim(4,0).ConvertToRGB64(matrix="PC.601")

MedianBlend(a,b,c,d, chroma=false, low=1, high=1, sync=5, debug=true)

Don't mind matrix="PC.601", I only used it because it's probably a good idea not to do a range conversion since the output is probably going back to YUV and can avoid multiple limited to full range conversions.
Oh and I set chroma parameter to false because when it's true it also processes the alpha channel which is not needed in this case.

[poisondeathray]

I can reproduce the issue on a 10bit422 prores source with motion , and trimmed like RD's example above. Native 10bit has overflow errors. The 8 bit down conversion has no blended/ghosted images and works well. The 16bit RGB upconversion has an issue with alignment and sync that the 8bit422 down version does not - motion is "jerky" in 16bit RGB with the plugin and different from the 8bit version, with some ghosted/blended frames. Unlikely to be source filter/seek issues, as Prores is I-frame. I think there is some issue with "sync" parameter in that "Median-0.6-RGB64-32+64bit" version .

EDIT: it had something to do with AddGrainC - If I remove that, it becomes aligned in RGB64 and works ok (but still without debug overlay)

[Reel.Deel]

EDIT: it had something to do with AddGrainC - If I remove that, it becomes aligned in RGB64 and works ok (but still without debug overlay)

That's odd. I have not tried with anything other than 8-bit YUV sources that I have. I'll try to find a 10-bit 422 prores sample somewhere and see if I can reproduce it. I looked at the source code and from what I can tell, debug is not implemented for RGB64.

Edit: ok I found a 4k 10bit prores sample, little bit of motion but I was able to see the that the video is jerky and has blended frames. I used the same script from earlier. I'm with you PDR, something might be off with the align parameter. It should not matter what the format was before converting to RGB64.

[poisondeathray]

That's odd. I have not tried with anything other than 8-bit YUV sources that I have. I'll try to find a 10-bit 422 prores sample somewhere and see if I can reproduce it. I looked at the source code and from what I can tell, debug is not implemented for RGB64.

I used this (and ConvertToRGB64(matrix="Rec709"), because it was "HD", but it shouldn't matter)
https://drive.google.com/file/d/1ObKwhduXJnyFVIipeouS_VI6NIF7Q9Ai/view?usp=sharing

Basically I cannot reproduce either; the issue was inserting AddGrain for me . His script had ShowFrameNumber inserted, but that doesn't cause the blending for me (works ok too)

I used LSmashVideoSource , so not indexed. LWLibavVideoSource (indexed) does not change the problem with AddGrainC for me

[Orikson]

Thank you for your replys! :thanks:

I uploaded a sample onto my google drive. You should be able to download it
https://drive.google.com/drive/folders/1Ao3wxKPeIpYlPFp8EOvSbgPUjrikIW5p?usp=sharing

One strange thing I recognized is, that my source files seem to be a bit missread by VirtualDub or AviSynth?! :confused: I don't think it has anything to do with the faulty median()-result, has it?

The video file has been captured with "Blackmagic Media Express" and a "Blackmagic DeckLink Studio 4K"
I can open and play the original captured video file with Media Player Classic BE (MPC-BE). It is recognized as Codec "AJA Video Systems Xena v210" and YUV 4:2:2 with 10-Bits
When I open this file in VirtualDub and export it again without any processing, it will use the setting "Pixel format P210".
I cannot view this exported file anymore with MPC-BE, but still with VirtualDub


Basically I cannot reproduce either; the issue was inserting AddGrain for me . His script had ShowFrameNumber inserted, but that doesn't cause the blending for me (works ok too)
In the post with your script, you did not convert the bitrate to 16-bit before converting to RGB64. I tested it but also with direct convertion to RGB64 without 16-bit conversion I had the same effect. The ShowFrameNumber() should be commented out most of the time. I use it only one in the very beginning to align the video clips so that the Median-Sync is good

I'm with you PDR, something might be off with the align parameter. It should not matter what the format was before converting to RGB64.
This reads like there is an actual issue with the median() function using RGB64 and not about my usage, right? I also tried to convert to RGB32 instead of RGB64, and with this the median()-function works as intended.

[poisondeathray]

One strange thing I recognized is, that my source files seem to be a bit missread by VirtualDub or AviSynth?! :confused: I don't think it has anything to do with the faulty median()-result, has it?

The video file has been captured with "Blackmagic Media Express" and a "Blackmagic DeckLink Studio 4K"
I can open and play the original captured video file with Media Player Classic BE (MPC-BE). It is recognized as Codec "AJA Video Systems Xena v210" and YUV 4:2:2 with 10-Bits
When I open this file in VirtualDub and export it again without any processing, it will use the setting "Pixel format P210".
I cannot view this exported file anymore with MPC-BE, but still with VirtualDub



The difference is "v210" is packed 10bit422 , "p210" is planar 10bit422 .

You can export v210 out of vdub2 (vdub2, not vdub classic) by selected video=>compression=>uncompressed=> (pixel format button)=> 4:2:2 YCbCr v210 . There is also MOV container export support



In the post with your script, you did not convert the bitrate to 16-bit before converting to RGB64. I tested it but also with direct convertion to RGB64 without 16-bit conversion I had the same effect. The ShowFrameNumber() should be commented out most of the time. I use it only one in the very beginning to align the video clips so that the Median-Sync is good


It did not make much of a difference. The 1st 2 frames were bad, but the rest ok (but 8bit down conversion also had problems with 1st 2 frames) . Compared to AddGrain result, where almost every frame was bad and it was jerky