VirtualDub2

[shekh]

Yes, but I am not fast at updating ffmpeg (still at 2016-04-28). Maybe will pull it before declaring this preview version done.

[shekh]

New version.
Among other fixes, ffmpeg-based input driver can now work with direct stream copy and smart rendering, but only with I-frame formats.
It is hard to tell generic rule, but I expect anything you can put in AVI with all keyframes should work. Actually tried direct copy with utvideo, x264, mjpeg, ffv1, huffyuv, and smart rendering with x264 and maybe something else.

[StainlessS]

We love this project, thank you Shekh. :thanks:

[kolak]

Yep!
Latest ffmepg got finally MOV edit list support which is very useful. No more unwanted frames in MOVs with edit list.
I hope this will come to plugin also at some point.

[shekh]

Yep!
Latest ffmepg got finally MOV edit list support which is very useful. No more unwanted frames in MOVs with edit list.
I hope this will come to plugin also at some point.

Give me a clue (and sample files) how to approach this, I will see if it is easy :)

[kolak]

I can prepare something.
Simplest way to do is to take any some MOV file open in QT7 on Mac or Qt7 Pro on PC, select some segment at the start and delete it. Then save this MOV (not Save As). This will add some edit metadata. If you open such a file in Qt7 you should see your adjusted start point. If you open in Vdub than it will show original start.
New ffmpeg will respect edited in point.

[shekh]

Then I think it already works? I saw some code int ffmpeg adjusting index etc. for edit lists.

[kolak]

Yes, ffmpeg has support for edit list in MOV now, so I hope this will come to Vdub source plugin also.

[shekh]

Can you make a timecoded video with some edits?
Btw how do you know it was added recently?

[kolak]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/ca6cae73db207f17a0d5507609de12842d8f0ca3

I tested it and it does work.

I will prepare something soon.

[kolak]

Sorry, but I was bit busy.

Here are some files:

https://drive.google.com/file/d/0B5SgcxshyxbKT0t0U0NFd0RhVlU/view?usp=sharing

they have descriptions in the name. Main file is 10 seconds as is. Then there is one which has first 2 sec edited out, last 2 seconds edited out and 2-5sec edited out. If you open them in QT player you will see everything as they have TC and frames burned in.
Latest ffmpeg respects editing, few weeks old won't.

[shekh]

Everything looks fine
I built last version with 2016-09-22 FFMPEG

[kolak]

Great, with new ffmpeg it should.
Try old one and you will see that all edits are ignored.

[v0lt]

MKV(H.264+AC3). Direct copy not worked.
http://imgur.com/a/KqkSr

[shekh]

MKV(H.264+AC3). Direct copy not worked.
http://imgur.com/a/KqkSr

I was on vacation and could not reply, but you probably already know only I-frame video is currently supported. Btw I put all relevant info here: https://sourceforge.net/p/vdfiltermod/wiki/direct_copy/

Implementing universal support for direct copy mode is of extra low priority for me but with I-frame formats it is really simple so this is why I made it.

[v0lt]

I figured out after.

Do you plan to support other formats for writing? For example a plug-in that could be mixed strems to MKV with an external ffmpeg.exe.

[shekh]

Version 14 (https://sourceforge.net/projects/vdfiltermod/files/VirtualDub%20pack/version%2014/)

Quick summary: completed YUV 16-bit pixel formats (supported by input and output).
https://sourceforge.net/p/vdfiltermod/wiki/format_changes/attachment/decode_format.png

Display of those formats is now faster, for example:
CFHD decoded as v210 - compared on same fragment and same pc
official VD: throughput about 32fps
FilterMod 14: throughput about 100fps
FilterMod 14, decoding as rgb24: throughput about 135fps (for reference)
(v210 is expanded to friendly YUV422P16)

[StainlessS]

Lovely, thanx Shekh :)

[Reel.Deel]

Thanks for the update shekh. Any plans on adding high bit depth support for AviSynth+ scripts?

[shekh]

Thanks for the update shekh. Any plans on adding high bit depth support for AviSynth+ scripts?

I dont have any todo list about it.
But there is a chance it might already work to some extent, currently accepted bitmap formats:
b64a = packed rgba 4*16-bit
BRA[64] (AV_PIX_FMT_BGRA64) = packed rgba 4*16-bit
P210 = interleaved YUV 422*10-bit
P216 = interleaved YUV 422*16-bit
Y3[10][10] (AV_PIX_FMT_YUV422P10) = planar YUV 422*10-bit
Y3[10][16] (AV_PIX_FMT_YUV422P16) = planar YUV 422*16-bit

BRA[64], P210 and Y3[10][10] actually work with MagicYUV decoder.

[dipje]

the AVFS utility to create virtual-avi files was changed to support the high bitdepth-support from avs+ and Vapoursynth (and it's the same utility to read .vpy or .avs files to create virtual avi files).

From what I understand from Myrsloik is that he basically merged the VFW module / support or something. So a good chance it might be working or it is a very small change.

[shekh]

Checked avs+ source, as far as I understand it does not support any high bitdepth with VFW output. AVFS is different piece, can`t be used to open .avs directly.

[dipje]

True. But if it mounts Avi files with high bitdepth formats and your vdub opens those formats, it can't be a big step I guess to make it directly so I'm guessing.
Or is there no VFW interface at all anymore in AVS+?

[shekh]

True. But if it mounts Avi files with high bitdepth formats and your vdub opens those formats, it can't be a big step I guess to make it directly so I'm guessing.
Or is there no VFW interface at all anymore in AVS+?

Maybe better to ask this in avs+ thread.
My best understanding:
AVS+ has VFW and native output
AVFS is using native output from AVS
VD is using VFW output from AVS

Meanwhile, it seems VapourSynth can output some compatible formats:
b64a = rgba 4*16-bit (confirmed long ago)
v210 = YUV 422*10-bit
P210 = YUV 422*10-bit
P216 = YUV 422*16-bit

[Myrsloik]

Maybe better to ask this in avs+ thread.
My best understanding:
AVS+ has VFW and native output
AVFS is using native output from AVS
VD is using VFW output from AVS

Meanwhile, it seems VapourSynth can output some compatible formats:
b64a = rgba 4*16-bit (confirmed long ago)
v210 = YUV 422*10-bit
P210 = YUV 422*10-bit
P216 = YUV 422*16-bit

The output formats I support in both vsvfw and avfs (if you use avs+ with the vapoursynth version of avfs you can also output most of these formats):
b64a
YUY2
YV12
Y800
YV24
YV16
Y41B (may be buggy, still investigating)
YVU9 (not really tested either)
P010
P016
v210
P210
P216
Y416 (in a debate with madvr author and nevcairiel about the actual component order, I think I'm right though)

Which ones do you support for input?

[shekh]

for input:
I am not sure about old 8-bit formats, have to look in source.
If in doubt it is here: https://github.com/shekh/VirtualDub2/blob/master/src/Riza/source/bitmap.cpp

fourcc formats:
YUVY
YUYV
YUY2
YV24
YV16
YV12
I420
IYUV
YVU9
Y8[32][32] (same as Y800)
Y800
v210
P216
P210
Y3[10][10] (AV_PIX_FMT_YUV422P10)
Y3[10][16] (AV_PIX_FMT_YUV422P16)
Y416
HDYC
NV12
b64a
BRA[64] (AV_PIX_FMT_BGRA64)

those in bold intersect with your list

most of it also works for output, with exception of P210,P216

[Myrsloik]

Then I request Y416 support for input. That could come in handy later when I test things.

[shekh]

Then I request Y416 support for input. That could come in handy later when I test things.

Yes, I was thinking of it.

[shekh]

Then I request Y416 support for input. That could come in handy later when I test things.


in a debate with madvr author and nevcairiel about the actual component order, I think I'm right though

I implemented as in MS spec, and the picture looks correct :)
Current implementation does some not very optimized repacking to convert it to YUV444P16 and drops alpha completely. I assume you don`t expect alpha anyway?

[Myrsloik]

I implemented as in MS spec, and the picture looks correct :)
Current implementation does some not very optimized repacking to convert it to YUV444P16 and drops alpha completely. I assume you don`t expect alpha anyway?

I never return alpha. Mostly because nobody's requested it.

[dipje]

@Myrsloik: But in the b64a data I get back from Vapoursynth / AVFS I have to tell After Effects to ignore the alpha channel, otherwise everything is 100% transparent. Is this just random what it's filled with or do you write some filler data somewhere? If you write alpha data, is it you returning 'full transparent' or is After Effects at fault by interpreting everything as transparent? (Like I said, I can tell AE to ignore alpha, so no big issue at all!)

[Myrsloik]

I think I always write 0 to the alpha. This should probably be changed for some output formats like b64a...

[jpsdr]

Out of curiosity, is there somewhere an update of the last SDK v1.2 (an 1.2a or even more an 1.3) with this new colors formats and property ? I think i may begin to take an interest with these extended color formats for my plugins.
I was thinking is there at least a new vplugin.h with the new VDXPixmapFormat value for new color formats ?
Maybe some changes are made to the VDXPixmap ?
Otherwise, can we just assume for 10-16bits data, that all the informations on the VDXPixmap for exemple are still the same, except that it's 16 bits data pointers instead of 8 bits ?
Is RGB64 top/bottom memory reversed like the RGB32 is ? (Where first line in memory is bottom of picture, when for all others planar mode first line of memory is top of picture.)

[shekh]

There is no update for sdk, but since you indicate interest I will prepare something.
Right now the best I can offer is rgb_levels source code, as it implements RGB64 mode https://sourceforge.net/projects/vdfiltermod/files/plugins/rgb%20levels/version%202/

Quick summary
Unfortunately there was no chance to modify VDXPixmap without breaking compatibility (or I was not smart enough) so I had to do some workarounds to access new fields.
Basically yes, for RGB64
format = 57
pitch is doubled
data points to uint16 elements

The rules for memory layout (top or bottom) are valid only for input/output, not for filters.
In a filter you always use data+pitch*y (pitch may be positive or negative)

Also there are some metadata:
alpha_type: alpha may be flagged as present or absent per picture.
value range (ref_r etc): may be 0xFFFF for normalized 16-bit data, or something else.
For example it is 0xFF00 for P210,P216,Y416 sources and 0x03FF for Y3[10][10] sources.
These values are also variable per frame.
A filter may request normalized input for simplicity, to always deal with 0xFFFF.

[jpsdr]

There is no update for sdk, but since you indicate interest I will prepare something.

Thanks, but take your time, absolutely no rush.
The first and "only" thing i may need in the begining are just the new several values for the new colors format.
As there is 5 new color formats, it means there is 20 new VDXPixmapFormat values (5 x (Rec.709/601 + Full/Limited).

No, error...
RGBA64 has only one value.
4:2:2-10, 4:2:2-16 and 4:4:4-16 have 4 values (Rec.709/601 + Full/Limited).
4:2:0-16 has 16 values (Rec.709/601 + Full/Limited)x("nothing"/i/it/ib)
Resulting in 1+3x4+16=29 new values.

Edit :
I take a more deep look, it seems that you've added even more color data format (like NV12, I8, etc...). So, finaly, the first thing needed may be the list of all these new values. But again, take time, no rush.
It's something i'm just begining to thought about, so taking thinks quietly.
And not touching VDXPixmap may indeed be a good safe thing.

[shekh]

It is easy to find by yourself, look here https://github.com/shekh/VirtualDub2/tree/master/src/h/vd2/plugin


kPixFormat_XRGB64 = 57,
kPixFormat_YUV444_Planar16 = 58,
kPixFormat_YUV422_Planar16 = 59,
kPixFormat_YUV420_Planar16 = 60,
kPixFormat_Y16 = 61,
kPixFormat_XYUV64 = 62,


I wanted to stop format explosion, so only 1 format for all colorspaces. Colorspace matrix/range identifiers are attached as metadata to Pixmap.
These are not expected to vary per-frame, and I have no clear plan how to communicate with filter about them. Open for ideas.

edit:
not all formats are meant for filter processing.
Currently only
kPixFormat_XRGB64
kPixFormat_YUV444_Planar16
kPixFormat_YUV422_Planar16
kPixFormat_YUV420_Planar16

edit:
NV12, I8, etc were set before me.

[jpsdr]

Unfortunately it seems you can provide this only with VDXPixmapFormat, so you can't avoid the format explosion for a simple solution.
Otherwise, it seems it involves complex and high risk modifications in VDXFilterActivation or others things like this to be able to provide your FilterModPixmapInfo data to the filter.

It's the easy, and mosf of it, the 100% safe way.

[shekh]

Yes as you can see in rgb_levels it has additional dll exports: VirtualdubFilterModuleInit2, FilterModModuleInit
Details of activation are hidden by c++ wrapper (VDXFrame), with plain C interface it is a bit complex. In no case it has any risk in it.

But this interface was designed with side-by-side development of official VD in mind, now as official VD RIP I think I can drop unnecessary complexity.
Even format id for kPixFormat_XRGB64 was exposed with a function (not constant), now I dropped that idea (too much trouble for nothing).

[shekh]

To clarify, I made extra effort to solve this problem:
possible to make single plugin binary which works
1) with all versions of FilterMod (with features enabled based on availability)
2) with backwards compatible versions of official VD (with FM features disabled)
3) with future/imaginary versions of official VD (with FM features disabled)

now (3) seems useless, and it is what creates most interface trouble.

[jpsdr]

I agree for now for leaving (3).
When i work on updating my plugins, i'll take a look at the code of your plugin, and probably asked you again at this time. Don't need to bother you anymore right now.

[jpsdr]

enum ColorSpaceMode {
kColorSpaceMode_None,
kColorSpaceMode_601,
kColorSpaceMode_709,
kColorSpaceModeCount
};

With all the UHD and bit depth stuff, i would like to suggest to add kColorSpaceMode_2020.

[shekh]

This can be implemented at 2 levels:
1) just a tag to carry through with conversions disabled
2) and all the conversions too

I need help where to borrow conversions to/from rgb and other spaces. Afaik 2020 is not just matrix, but also non-linear transfer which makes it important (and computationally expensive)?

[dipje]

As far as I see it, there is a '2020' that is possible as a regular color matrix, and another one that requires special coding that it can't be easily implemented in the same conversion routines (fmtconv in vapoursynth has a special function for it for instance).
'non constant luminance mode' (ncl) is the simpler one, and you'll encounter it more often. 'constant luminance mode' (cl) is the 'special' one.

The thing is, it's not just the colormatrix. Most 2020 stuff uses different color primaries then bt709 (although 2020ncl with bt709 does exist.. it's not _that_ weird, just not the only stuff out there).
So the correct way to change / convert color primaries is to go to RGB, then to linear RGB (gamma 1.0), convert the color primaries (from bt709 to 2020, or from bt709 to dci-p3 for example).
Then go to gamma-correct 'normal' RGB again then convert to the YUV with the colormatrix you want (or leave it RGB if that suites you).

This all is to convert the colormatrix and/or colorprimaries. The thing to remember is, this does NOT convert HDR to SDR or something. What you end up with is still all the HDR information but in a colorspace-configuration that you know from SDR times. To make the stuff watchable on SDR displays you would still have to do some kind of dynamic-range compression and / or clip some stuff out to get it watchable. I could get stuff looking pretty OK by tweaking the gamma correction but there are better ways (for example, what MadVR does to display HDR content on SDR displays).

So, colorspace conversion is one thing. HDR to SDR conversion is another. And of course stuff like the 2020 colormatrix and 2020 colorprimaries (or dci-p3 color primaries or something else) has a much wider gamut of colors available, so you will be loosing color precision / data somewhere (colors _should_ end up over saturated here and there in bt709, unless you use some smart 'desaturation' filter during the conversion.. again, like MadVR does).

[jpsdr]

Afaik 2020 is not just matrix, but also non-linear transfer
Hum... It seems that i read thing too quickly and not deep enough, didn't realise it wasn't a simple matrix like the other formats. Non linear is not a real issue with 8 bits using look-up table, but maybe in that case lookup-tables even of... 64k maximum may still be interesting.

[shekh]

But who needs it in 8 bit? Anyway, it seems the only real way is to connect code which already works (zimg?)

[jpsdr]

Pinterf added Rec2020 support in avs+, maybe it's also a code which can be checked.

[pinterf]

Pinterf added Rec2020 support in avs+, maybe it's also a code which can be checked.
Color matrix only.

[shekh]

So is matrix-only Rec2020 useful in practice? I am confused with transfer functions. They are defined for rec601/rec709 too, but in reality are ignored (so that rgb-yuv conversions are linear and fast).
If the same still works for ldr 2020 then it is basically a matter of adding some new constants (as in avs+)

[jpsdr]

I've noticed some issue with the last 64bits release.

First, video in output right part is cropped/shifted.
Is it intended ?
VirtualDub :
http://jpsdr.free.fr/XBMC/PB_VDM-3.jpg
VirtualDubMod :
http://jpsdr.free.fr/XBMC/PB_VDM-4.jpg

After, there is issues with a third-party plugin i'm using for a long time :
VirtualDub :
http://jpsdr.free.fr/XBMC/PB_VDM-1.jpg
VirtualDubMod :
http://jpsdr.free.fr/XBMC/PB_VDM-2.jpg
One issue is at least that the slider is no more... :(.
The filter is NeatVideo.

Edit : You can eventualy get the demo version here (https://www.neatvideo.com/download) on their site to check/test.

[shekh]

> First, video in output right part is cropped/shifted

Yes, you can pan it with mouse (by default centered).

> After, there is issues with a third-party plugin i'm using for a long time

what is the issue?
Time slider is active at the bottom.