flash3kyuu_deband 1.5.1 / 2.0pre2 with native VapourSynth support [2012-12-03]

[Keiyakusha]

Thank you! Now that I know everything works, I can think about rendering some of my projects in 16 bits. However I'm still searching of some way to open image sequence directly. Intermediate transcoding to yuv444p16le really eats my time and space. Its like 2.4 size of the source sequence (which is not that small by itself).

[SAPikachu]

Thank you! Now that I know everything works, I can think about rendering some of my projects in 16 bits. However I'm still searching of some way to open image sequence directly. Intermediate transcoding to yuv444p16le really eats my time and space. Its like 2.4 size of the source sequence (which is not that small by itself).

Which format is the image sequence? For regular format like PNG, JPG, BMP etc., I think you can just use ImageSource.

[Keiyakusha]

Which format is the image sequence? For regular format like PNG, JPG, BMP etc., I think you can just use ImageSource.

These are 16bit PNG or 16bit LZW-compresed tif... I think without any custom avisynth plugin they can't be loaded... Of course I want to keep them 16bit.
There is hacked version of ffms2 that can load 16bit stuff into avisynth but it doesn't supports 4:4:4 subsampling and i was able to open only 1 image, not sequence.

[TheFluff]

FFMS2 doesn't support image sequences, no. That hacked version most likely does the upper 8 bits wrong, too.

[SAPikachu]

These are 16bit PNG or 16bit LZW-compresed tif... I think without any custom avisynth plugin they can't be loaded... Of course I want to keep them 16bit.
There is hacked version of ffms2 that can load 16bit stuff into avisynth but it doesn't supports 4:4:4 subsampling and i was able to open only 1 image, not sequence.

Just had some research, DevIL actually supports 16 bits per channel internally, so we can build a hacked ImageSource to read 16 bit image sequence. If no one is interested to code it, I will make it when I get some time. :)

[Keiyakusha]

This would be so awesome to have this kind of plugin! Will look forward to it. In the meantime I'll try to convert my current project into yuv444p16le...
I usually work with image sequences because this is the most convenient format due to various reasons and it is easy to re-render some part of he project where I made some change. There can be some other options, especially on Mac (like Prores4444) but I'm a windows user and so far don't even see a way to render into raw 16bit stream directly... (the only real option is 4:2:2 10bit, but instead of it I better chose 4:4:4 8bit).

[SAPikachu]

Released 1.5.0. This version doesn't have any new feature, just changed some parameters to reduce confusion based on user feedback.

[sneaker_ger]

Thx for the new version. From the readme on dither_algo:
Use mode 1/2 for speed, or mode 3 for quality.

I don't agree with that. If you remember my small test I posted in this thread ordered dithering actually improves quality over Floyd-Steinberg when encoding lossy afterwards (which is probably what most people do with AviSynth), and I remember cretindesalpes posting a comment that says the same.

[SAPikachu]

Thx for the new version. From the readme on dither_algo:


I don't agree with that. If you remember my small test I posted in this thread ordered dithering actually improves quality over Floyd-Steinberg when encoding lossy afterwards (which is probably what most people do with AviSynth), and I remember cretindesalpes posting a comment that says the same.

Well, actually I totally forgot this part when updating the documentation. :P This should indeed be noted in the file. I will update it later today, thanks.

EDIT: Just updated the online documentation.

[sneaker_ger]

Can anyone give me an example of how to correctly pipe 10 bit 4:2:2 to x264-10bit?
I tried
ffvideosource("source.mkv")
ConvertToYUY2() # (or YV16)
f3kdb(output_mode=2, output_depth=10)

then:
avs2pipemod -rawvideo source.avs | x264-10bit - --demuxer raw --input-depth 10 --input-res 1280x720 --input-csp i422 (or YV16) --output-csp i422 -o output.h264

Either the complete picture or just the colors are messed up.

[SAPikachu]

Can anyone give me an example of how to correctly pipe 10 bit 4:2:2 to x264-10bit?
I tried
ffvideosource("source.mkv")
ConvertToYUY2() # (or YV16)
f3kdb(output_mode=2, output_depth=10)

then:
avs2pipemod -rawvideo source.avs | x264-10bit - --demuxer raw --input-depth 10 --input-res 1280x720 --input-csp i422 (or YV16) --output-csp i422 -o output.h264

Either the complete picture or just the colors are messed up.

You can try x264 tMod (http://www.mediafire.com/?118vb9r45qixy), it supports directly loading high bit-depth avs scripts. If only the colors are messed up, use YV16 and place SwapUV() before f3kdb may fix that.

[sneaker_ger]

Thx, swapping U and V in YV16 did the trick.

[Chyrka]

Please, tell me what is the correct way to convert avi with v210 in mov with v210? I've tried this in Premiere CS5, but after import in Avisynth i've got such picture:
http://i35.fastpic.ru/thumb/2012/0419/91/7150d3b01677d46fd967bbf134448e91.jpeg (http://fastpic.ru/view/35/2012/0419/7150d3b01677d46fd967bbf134448e91.png.html)
With my video i've got similar results.
Thank you.

[mp3dom]

You can use FFMBC or FFMPEG. It's probably even faster. Use -vcodec copy to do a direct stream without any re-compression.

[Chyrka]

mp3dom, thank you for the answer, but my problem remains. With correct offset i have good 1st frame (for 16-bit I disabled dithering):
http://i35.fastpic.ru/thumb/2012/0419/68/_579e67ab2809b75714a601a900765268.jpeg (http://fastpic.ru/view/35/2012/0419/_579e67ab2809b75714a601a900765268.png.html)
but other frames (both 8-bit and 16-bit) are messed up and shifted. 2-nd frame:
http://i37.fastpic.ru/thumb/2012/0419/62/_0305ec5071f0eed225bd85122f78f162.jpeg (http://fastpic.ru/view/37/2012/0419/_0305ec5071f0eed225bd85122f78f162.png.html)
:(
Maybe, I'm doing something wrong with readv210, but I cann't realize what. I guess, it's something with offset. :confused:
Script:
ReadV210("I:\Test\v210_720p.mov",36,1280,720)
My mov file: http://www.mediafire.com/?bshu20n0rf8quoj
In addition, I have not problem with coff3.mov from example. Why??? ((((

[mp3dom]

It's the AAC audio that is screwing something. Removing it resolved the issue.
ffbmc -i <file.mov> -vcodec copy -an <out.mov>

[Chyrka]

mp3dom, thank you so much. It works. :cool:

[Keiyakusha]

I have a question regarding readv210 too. What output should i expect see when i use it? For example if I use readv210("coff3.mov", 1103, 176, 144) or different command for opening my own file readv210("comp.mov", 48, 1280, 720) i see perfectly fine YV16 video... but i kind of expected to see stacked image... And mine is probably just MSB part. Any tips?
Edit: wow i found f3kdb_dither(stacked=true) in the script, after commenting it, it seems i'm getting what i expected... probably i need to sleep more...

[AiDz0r]

Why can't I use precision_mode?

[SAPikachu]

Why can't I use precision_mode?

precision_mode is renamed to dither_algo in 1.5.0.

[SAPikachu]

Released 2.0pre.

[sneaker_ger]

I get "Invalid plane requested" even on simple vs scripts:
import vapoursynth as vs
import sys

core = vs.Core()

core.std.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source=r'c:\sample.mkv') #8 bit, YV12

core.std.LoadPlugin(path=r'c:\flash3kyuu_deband.dll')

ret = core.f3kdb.F3kdb(ret, output_depth=10)

ret.output(sys.stdout, y4m=True)

[SAPikachu]

I get "Invalid plane requested" even on simple vs scripts:
import vapoursynth as vs
import sys

core = vs.Core()

core.std.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source=r'c:\sample.mkv') #8 bit, YV12

core.std.LoadPlugin(path=r'c:\flash3kyuu_deband.dll')

ret = core.f3kdb.F3kdb(ret, output_depth=10)

ret.output(sys.stdout, y4m=True)

I just confirmed again, it works in both AvsP and raw output for x264. y4m output also works for 8bit output but broken for 10bit output (shows "y4m [error]: bad header magic", not sure it is VS or x264's fault). Which version of VS and ffms2 are you using? Can you post the full error output?

[qyot27]

This is the commit where x264 gained the extended y4m support that VS and FFmpeg use. (http://git.videolan.org/?p=x264.git;a=commit;h=28ddb0dd533154b58f9147932fb1dec4c74127c8) It corresponds to r2226, but for practical reasons you'd probably be using either r2230 or r2216; r2216 and prior don't have that commit, r2230 does.



Personally, 2.0pre caused errors for me if it was in the autoload folder. AviSynth would fail to play the script - which was just a simple DirectShowSource test (but because of how autoload works, it loaded f3kdb even though I didn't have it in the script). If I tried wavi or FFmpeg, Windows itself actually threw up an error dialog: The procedure entry point FlsAlloc could not be located in the dynamic link library KERNEL32.dll.

Rolling back to 1.5.1, the issues disappear. The script can play, wavi and ffmpeg can open it and convert without issue. Checking what FlsAlloc is, it seems like it's probably not be available on XP. If I compile from git with VS2010 Express, it's fine, though.

Are there any plans to make f3kdb cross-platform like VapourSynth is?

[SAPikachu]

This is the commit where x264 gained the extended y4m support that VS and FFmpeg use. (http://git.videolan.org/?p=x264.git;a=commit;h=28ddb0dd533154b58f9147932fb1dec4c74127c8) It corresponds to r2226, but for practical reasons you'd probably be using either r2230 or r2216; r2216 and prior don't have that commit, r2230 does.


Thanks, I will try r2230 later today.


Personally, 2.0pre caused errors for me if it was in the autoload folder. AviSynth would fail to play the script - which was just a simple DirectShowSource test (but because of how autoload works, it loaded f3kdb even though I didn't have it in the script). If I tried wavi or FFmpeg, Windows itself actually threw up an error dialog: The procedure entry point FlsAlloc could not be located in the dynamic link library KERNEL32.dll.

Rolling back to 1.5.1, the issues disappear. The script can play, wavi and ffmpeg can open it and convert without issue. Checking what FlsAlloc is, it seems like it's probably not be available on XP. If I compile from git with VS2010 Express, it's fine, though.


I just found the culprit of the error, executables compiled by VS2012 does not work on XP by default. Will recompile an XP-compatible version after I installed a big patch for VS.


Are there any plans to make f3kdb cross-platform like VapourSynth is?

Yes, my next plan after finalizing this version is make it GCC-compilable. After that it is just a little more work to make it runnable on Linux.

[sneaker_ger]

I just confirmed again, it works in both AvsP and raw output for x264. y4m output also works for 8bit output but broken for 10bit output (shows "y4m [error]: bad header magic", not sure it is VS or x264's fault). Which version of VS and ffms2 are you using? Can you post the full error output?

I'm using VS R16 and tried the official ffms2-725-icl-4 build and ffms2-r734-libav-e6160bd + ffms2-r734-ffmbc-0.7rc7 from your signature. I don't think they're working incorrectly, as the script works as long as I outcomment the f3kdb line. As qyot implied I was already using x264cli 2230 with 10 bit y4m support. I tried 8 bit output anyways, but to no avail.

I even get the error message when I set y4m=False and redirect to NUL.

How do I get "the full error output"?

I'm on Win 7 x64, core i7-860

[SAPikachu]

I get "Invalid plane requested" even on simple vs scripts:
import vapoursynth as vs
import sys

core = vs.Core()

core.std.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source=r'c:\sample.mkv') #8 bit, YV12

core.std.LoadPlugin(path=r'c:\flash3kyuu_deband.dll')

ret = core.f3kdb.F3kdb(ret, output_depth=10)

ret.output(sys.stdout, y4m=True)

Can you try again with pre2? I just found that I uploaded a buggy build as pre...

[sneaker_ger]

fixed

Btw, maybe you should call the function "Deband" instead of "F3kdb". Kinda redundant with the namespace already being "f3kdb" and would be more in line with the other filters.

[Bloax]

And if don't want to use a base-of-functionality name, then f3Deband would probably do. (And would be much easier to remember than f3kdb, which is kind of semi-random.)

[Keiyakusha]

I support sneaker_ger as there was dither too. (or this functionality wasn't ported?). Will be f3kdb.Deband and f3kdb.Dither.
Not sure what "base-of-functionality" means, but by all means do not change f3kdb to f3Deband or something, it is horrible. The name is "flash3kyuu", this is the only option if f3kdb is not good. Or something like f3k.Deband maybe?(don't think it is easier to remember though)

[06_taro]

+1 for f3k.Deband.

BTW, the f3kdb_dither for avs is already deprecated as it equals to f3kdb(Y=0, Cb=0, Cr=0, grainY=0, grainC=0, output_depth=8).

[SAPikachu]

I think f3kdb.Deband is better, since flash3kyuu has other aviutl plugins, if I used f3k, the namespace may conflict with plugins ported later. Any opinions?

f3kdb_dither will be kept in AviSynth interface for compatibility since the real work can be easily delegated to f3kdb core now. But I am still considering whether I should add a separate function in VS for it. Which one of the following do you like?


# Plan A
core.f3kdb.Deband(clip, preset="depth", output_depth=8)
# "preset=" may be omitted

# Plan B
core.f3kdb.Depth(clip, output_depth=8)



Personally I like plan A better, because plan B seems redundant, all works are done in the same place anyways.

[Keiyakusha]

I'm not sure how it works, but many internal filters use "std" many external "avs". Is it really a problem for different plugins to be "f3k"? For some reason I though this is OK... If not, then leave it f3kdb of course.

As for dither/depth, personally I'm ok with anything as long as it works.

[SAPikachu]

Internal filters and AviSynth compatibility layer are implemented in the core so they can share a same namespace, AFAIK other external plugins must all use different namespaces (correct me if I am wrong).

[sneaker_ger]

The download links appear to be down?

[SAPikachu]

Seems the server is down, please use the mirror in my signature for this moment.

[jackoneill]

Yes, my next plan after finalizing this version is make it GCC-compilable. After that it is just a little more work to make it runnable on Linux.

How is that coming along?

[SAPikachu]

How is that coming along?

I have been very busy recently and haven't touched the code for some time... Will continue on it after my current project is completed.

[Snowknight26]

YUY2 input seems to have an issue when using dither_algo=3.

Using this (http://stfcc.org/pics/i/3643363663c1946a94d5aadf66ff445c.jpg) as the source, the following produces a color shift vertically down the center of the image:
ImageSource("file.jpg")
ConvertToYUY2()
flash3kyuu_deband(dither_algo=3)
Example output: http://stfcc.org/pics/i/b06495640d07168aff65615139dd8064.png

If I change ConvertToYUY2 to ConvertToYV12 or dither_algo to 1/2, it's fine and looks like so:
http://stfcc.org/pics/i/9634210b51335e568a8b2b70be749827.png

Edit:
Seems like I was using the filter incorrectly? Just followed the example doing:
ImageSource("test.jpg",end=0)
ConvertToYV12()
f3kdb(dither_algo=3)
ConvertToRGB()
trim(0,0)
ImageWriter("C:\temp\out",type="png")
and it worked nicely (apart from the terrible chroma conversion).

What's the proper way of doing the color conversion? Using AviSynth 2.6.0 and ConvertToYV24 -> ConvertToRGB?

[SAPikachu]

YUY2 input seems to have an issue when using dither_algo=3.

Using this (http://stfcc.org/pics/i/3643363663c1946a94d5aadf66ff445c.jpg) as the source, the following produces a color shift vertically down the center of the image:
ImageSource("file.jpg")
ConvertToYUY2()
flash3kyuu_deband(dither_algo=3)
Example output: http://stfcc.org/pics/i/b06495640d07168aff65615139dd8064.png

If I change ConvertToYUY2 to ConvertToYV12 or dither_algo to 1/2, it's fine and looks like so:
http://stfcc.org/pics/i/9634210b51335e568a8b2b70be749827.png

Yes the YUY2 implementation may contain bugs since it is cumbersome to code for it and I can't write test case for it for some reasons. Actually I dropped YUY2 support in 2.0pre. You can convert to YV16 before processing, it is well-tested and possibly faster since YUY2 code is non-optimized.


Edit:
Seems like I was using the filter incorrectly? Just followed the example doing:
ImageSource("test.jpg",end=0)
ConvertToYV12()
f3kdb(dither_algo=3)
ConvertToRGB()
trim(0,0)
ImageWriter("C:\temp\out",type="png")
and it worked nicely (apart from the terrible chroma conversion).

What's the proper way of doing the color conversion? Using AviSynth 2.6.0 and ConvertToYV24 -> ConvertToRGB?

Well, if you want to process image you should really use YV24 to prevent chroma loss, and use Dither package (http://forum.doom9.org/showthread.php?p=1386559#post1386559) to do dithered colorspace conversion between YUV/RGB, that will give you better visual result than internal conversion filters.

[ryrynz]

Gave 2.0pre2 a shot today with 2.6MT and had my media player crash a few times and also an a bluescreen, have gone back to 1.5.1.

[SAPikachu]

Gave 2.0pre2 a shot today with 2.6MT and had my media player crash a few times and also an a bluescreen, have gone back to 1.5.1.

2.0 is an experimental version so it may have bugs that will crash the player, but in theory it shouldn't be able to cause BSOD... Anyway the core algorithm is not (yet) changed in 2.0, you can stay at 1.5.1 for now. I have been too busy to touch the code recently so it still needs some time for next version...

[ryrynz]

It doesn't appear that 2.0 is the issue, I've been using 1.5.1 in a script with other filters using MT mode 2 and TBH it's always been a little unstable but generally working fine. I've switched to the MSVC build and while it's early days, I haven't had a BSOD yet.

I wonder if there's a compiler option that will attain that same stability as the MSVC build but keep some performance advantage? I assume many won't experience any instability, I think it may depend a little on the filters being used in conjunction along with it in MT mode.

[SAPikachu]

It doesn't appear that 2.0 is the issue, I've been using 1.5.1 in a script with other filters using MT mode 2 and TBH it's always been a little unstable but generally working fine. I've switched to the MSVC build and while it's early days, I haven't had a BSOD yet.

I wonder if there's a compiler option that will attain that same stability as the MSVC build but keep some performance advantage? I assume many won't experience any instability, I think it may depend a little on the filters being used in conjunction along with it in MT mode.

Well, then it seems that the problem is in your hardware setup. Have you overclocked your CPU? All ICL does is optimize the assembly code so that CPU power can be better utilized. But that will cause your CPU become hotter than when you use the MSVC build. So if your CPU is overclocked it may be the culprit. If not overclocked, can you try limiting your CPU frequency (maybe switch to Power Saver mode) and see if the problem goes away?

[ryrynz]

Everything in the BIOS is stock. No memory errors, ran Lynx for 10 passes all okay, ran Prime95 blend mode with no issues so it's hard to say what's going on but my hardware appears stable.

I'm not fussed anyway, if the MSVC build fixes it then that's fine with me. It could be the smallest of instabilities somewhere in the hardware or maybe it's a conjunction of things that don't like
working together, either way nobody else is having any issues so I won't look into it any further at this point I just wanted to let you know at least it didn't appear to be a code issue with 2.0.

I'll look at it again some months from now when I upgrade to a Haswell based system, that should rule out the hardware at least if it still happens at that point.

[SAPikachu]

OK that's fine. Thanks for reporting anyways. :)

[turbojet]

ryrynz: What other filters are in the chain? No problem here with any of the f3kdb builds with mtmode2 but finesharp crashed quite often and occasional bsod with mtmode2, mtmode5 worked fine however.

SAPikachu: Do you know if f3kdb can be translated into a pixel shader? There isn't any very effective deband pixel shaders and could use some competition. f3kdb is the most effective debanders I've found. This would let me get ffdshow out of the playback chain.

[SAPikachu]

SAPikachu: Do you know if f3kdb can be translated into a pixel shader? There isn't any very effective deband pixel shaders and could use some competition. f3kdb is the most effective debanders I've found. This would let me get ffdshow out of the playback chain.

It may be possible, but I won't have time to do it in a few months. If someone is willing to write it I can provide some algorithm information though.

[ryrynz]

ryrynz: What other filters are in the chain? No problem here with any of the f3kdb builds with mtmode2 but finesharp crashed quite often and occasional bsod with mtmode2, mtmode5 worked fine however.

Psharpen, Hysteria, Vaguedenoiser, Awarpsharp2 and Flash3kyuu.

I'll look at the ICL build after my hardware update and troubleshoot it then. If the MSVC build does indeed fix it for me (for whatever reason) it I'm happy enough with continuing to use it.
I don't want to invest time trying to figure it out and posting further on it when when nobody else has any issues and it's solved by simply running a different compiled version, I can live with that for now.

A pixel shader would be very cool.

[travolter]

@SAPikachu thanks a lot!!!! the filter is really impressive and a daily use one. Perfect for realtime usage.