[Neo] f3kdb

[mp3dom]

It's perfectly fine that you're getting yv16 output colorbars, since neo_f3kdb is converting the bit depth from 12 to 8, and planar 8bit for yuv422 is yv16. If you're not getting any trouble and you see the colorbars right, then it shouldn't be a neo_f3kdb problem the green video you're getting, or it doesn't fully depends on neo_f3kdb.
You said you're opening the file with LWLibav... how you see the file with just plain LWLibav (no neo_f3kdb) and what's its colorspace inside VDub2?

[GMJCZP]

Originally Posted by mp3dom

It's perfectly fine that you're getting yv16 output colorbars, since neo_f3kdb is converting the bit depth from 12 to 8, and planar 8bit for yuv422 is yv16. If you're not getting any trouble and you see the colorbars right, then it shouldn't be a neo_f3kdb problem the green video you're getting, or it doesn't fully depends on neo_f3kdb.
You said you're opening the file with LWLibav... how you see the file with just plain LWLibav (no neo_f3kdb) and what's its colorspace inside VDub2?

Just using LwLibavVideoSource I get a 1280x480 green image and it says Vdub2 in Decompressor that it is Internal DIB decoder (Yv12).

[mp3dom]

That's the culprit... maybe you can try to update LSMASH (pick one of the latest compile).
12 bpc file on mp4 it sounds a bit weird... what's also telling you MediaInfo?

[GMJCZP]

I have the last version of Lsmash, the 20210423.

Mediainfo data:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Format Range@L3@Main
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 21 min 2 s
Bit rate : 1 384 kb/s
Maximum bit rate : 3 199 kb/s
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 12 bits
Bits/(Pixel*Frame) : 0.180
Stream size : 208 MiB (93%)
Writing library : x265 2.0+4-43ca544799c2:[Windows][MSVC 1900][64 bit] 12bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / lookahead-slices=0 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Encoded date : UTC 2016-07-18 23:03:09
Tagged date : UTC 2016-07-18 23:03:14
Codec configuration box : hvcC

[mp3dom]

Have you tried also LSMASHVideoSource? Same results? Otherwise you can also try to force the output to 16bit:

LWLibavVideoSource(source,format="yuv420p16")

[GMJCZP]

Originally Posted by mp3dom

Have you tried also LSMASHVideoSource? Same results? Otherwise you can also try to force the output to 16bit:

LWLibavVideoSource(source,format="yuv420p16")

Both with LsmahVideoSource and with the script that you propose, I get the same greenish image of 1280 * 480. If I add format = "yuv420p8" I do get the correct image but I would be giving up editing in Hbd and neo_f3kdb.

[mp3dom]

I think the last chance would be to share a trimmed part of your file so everyone can try to solve this.

[GMJCZP]

Sample:

Here

[mp3dom]

I still find no issue whatsoever.
Correctly opened with both LW and LSMASH, and with VDub2 with ffmpeg decoder as well. Unless it's a recent bug of LW/LSMASH (you can try to use an older version just in case) I think you have something wrong somewhere on your system.

[GMJCZP]

Originally Posted by mp3dom

I still find no issue whatsoever.
Correctly opened with both LW and LSMASH, and with VDub2 with ffmpeg decoder as well. Unless it's a recent bug of LW/LSMASH (you can try to use an older version just in case) I think you have something wrong somewhere on your system.

But with neo_f3kdb?
What is your script?

Edit: with Dss2mod and Vdub2 directly i can Open the File without problem.

Edit2: If I can open the file with dss2mod then the following question arises, why then use neo_f3kdb or f3kdb? of course this doesn't solve the problem with l-smash.

[mp3dom]

neo_f3kdb is not the problem here, because you told me that even the plain LWLibav (opening plugin) give you the problem. You can try an older version of Lsmashsource and see if something change (btw I'm using a 07/2020 version of the plugin).
If you open the file with dss2mod I guess you're opening it at 8bit with (good) or without (bad) the dither applied, so you lose hbd processing. F3kdb main use is for debanding, but can be used for dithering.
You have the latest Lsmashsource and latest neo_f3kdb... do you also have latest avs+ 3.7?

[GMJCZP]

Originally Posted by mp3dom

neo_f3kdb is not the problem here, because you told me that even the plain LWLibav (opening plugin) give you the problem. You can try an older version of Lsmashsource and see if something change (btw I'm using a 07/2020 version of the plugin).
If you open the file with dss2mod I guess you're opening it at 8bit with (good) or without (bad) the dither applied, so you lose hbd processing. F3kdb main use is for debanding, but can be used for dithering.
You have the latest Lsmashsource and latest neo_f3kdb... do you also have latest avs+ 3.7?

You were right, the problem was with Lsamsh, I downloaded version 20200111 and everything now works perfectly, including neo_f3kdb, thanks.
In short, at some point in the development of Lsmash a bug was introduced.

PD: recently update to last version of Avs+

[StainlessS]

LWLibavVideoSource(".\Sample_yuv420p12le.mp4")    # LSMASHSource_x86_20200322(HolyWu).dll
info

click to see Info().

EDIT: OK, you got it sorted.

[GMJCZP]

The bug was introduced this year, I tested the 20200728 Lsmash version and works.

[GMJCZP]

Originally Posted by StainlessS

LWLibavVideoSource(".\Sample_yuv420p12le.mp4")    # LSMASHSource_x86_20200322(HolyWu).dll
info

click to see Info().

EDIT: OK, you got it sorted.

TinMan, how did you go about getting the information from the video in yellow letters?

[StainlessS]

already posted, ie

LWLibavVideoSource(".\Sample_yuv420p12le.mp4")    # LSMASHSource_x86_20200322(HolyWu).dll
info    <<<<<<=======  Here !!!

It would be a big help at times, if LSmash (and others) added version resouce to their dll's,
so we knew what ver$ worked, or had problems.

[EDIT: downloading all versions and comparing file size/MD5 is a real pain]

[GMJCZP]

Originally Posted by StainlessS

already posted, ie

LWLibavVideoSource(".\Sample_yuv420p12le.mp4")    # LSMASHSource_x86_20200322(HolyWu).dll
info    <<<<<<=======  Here !!!

It would be a big help at times, if LSmash (and others) added version resouce to their dll's,
so we knew what ver$ worked, or had problems.

[EDIT: downloading all versions and comparing file size/MD5 is a real pain]

Thanks, with a celular maybe difficult see some things.

The problem was introduced from this year, at least the latest version

[StvG]

No issue with latest lsmash version (20210423):

[GMJCZP]

Originally Posted by StvG

No issue with latest lsmash version (20210423):

Thanks StvG, your comment motivated me to take action on the matter...

I was finally able to solve the problem, as follows:

- I downloaded the latest version of Lsmash again

- Then I noticed, by chance, that some videos were played wrong by mpc-hc, I updated it as well as lav filters (when I uninstalled it I had problems reinstalling it but it was solved)

- Finally I tried the video and it worked correctly.

It still seems a mystery to me that the latest version did not work at first, it is possible that there was a conflict with the programs I mentioned before.

Thanks everyone for your help.

[StainlessS]

Some time ago, there was some kind of problem concerning a VDub source plugin, and either ffmpeg or FfmpegSource, dll's.
It was something to do with path search order to find a dll, one softwares change in search order interfered with the other.
No idea if relevant.