VirtualDub2

[shekh]

I recommend using option "Use Direct3D (requires DirectX 9)" - it is most feature complete. Also uncheck "Disable accelerated display when inactive" - this only makes pointless flickering.

[Emulgator]

Beautiful. Just did that.

Just for confirmation: back to a different long unused WinXP32SP3 system, VD 1.10.4 and 1.10.5:
Ticking OpenGL (was unticked before there) brought the skewing in there as well with non-mod4-widths.
So this is a long-standing bug and has nothing to do with newly introduced faults by your builds.

[LigH]

Feature request:

Could you imagine creating a kind of AviSynth.vdf which is able to process a filtering script via AviSynth(+) internally, using the source loaded in VirtualDub (analog to ffdshow_source() (http://ffdshow-tryout.sourceforge.net/wiki/video:avisynth))? Some people may enjoy not to think as much about trying different source plugins when your ffmpeg input plugin can handle most of them as well...

(idea of user H264x in the German doom9/Gleitz board)

[shekh]

I imagine how it should work, but not where to get time for everything :)

Btw, about Full processing/Normal recompress/Fast recompress: there is no straightforward difference. I saw variation in some hidden details which are difficult to observe/explain.
"Fast recompress" tries to set decoding and encoding formats automatically (not very helpful unless at least source or destination is VFW codec).
Normal recompress does not let you setup filters, but also does not disable them. I can't explain this.
IMO only Full processing should remain of these 3 modes.

[LigH]

Well, now that there are YUV filters, you may. Before, VirtualDub could handle YUV conversions, but only supported RGB filters. In these times it may have made more sense.

[StainlessS]

Tried update from a few weeks ago, VDFM, build 40501, failed on load simple script (XP32)

Version

Error, "FFMPEG Could not open file" [or words very similar].

Update to build 40639 (current), problem gone.
Dont know what you did but we are fine now. Thanx. :)

[shekh]

I did nothing, but you are welcome :)

Very long ago FFMPEG was taking over some scripts detecting them as mpegts.

[StainlessS]

One comment on very short play with current ver$ [a few minutes only], its a bit annoying having to pause scrolling to have display update,
think that there must have been some mod to that since the earlier version I was using (from several months ago).
Guess I could learn to live with it.

EDIT: Scroll via mouse/timeline.

EDIT: Sorry Shekh, false alarm, the script I was using was quite heavy, and caused delay in display,
bypassed heavy processing and is very responsive, just ignore me :stupid:

EDIT: Although Vdubmod does not cause unresponsive display using same heavy processing script, and I think neither did
the previous version VDFM that I was using. As I said, I can live with it. Thanx again.
EDIT: Just scrolled 20 minutes through clip before update occurred, probably paused because my mouse pad is quite small
and ran out of space. (20 mins of 34 minute duration clip, so 2/3 the way through)

[shekh]

I think you want to disable "Options->Drop frames when seeking".
After initial fix in this story, another user complained about poor seeking performance so I restored default behavior and made this option.
(turns out there is different use case involving very long GOP sources and fcchandler mkv)

[StainlessS]

Disabled "Drop frame when seeking", no change.
The script I'm using does quite a lot of processing including Autocrop, AutoContrast, MCDegrain, FFT3DFilter, Resize and more.
I just find it a little disconcerting to not know where in the clip I am, will have to get used to using keyboard I guess.
EDIT: Or perfect my Scroll - Stop - Scroll - Stop, technique :)

[AKBabel]

Hi to all,
I have noticed, that the FFV1 encoder configuration window doesn’t show all possible settings for this codec. You can actually also define an interframe compression by using the GOP argument of ffmpeg:
https://trac.ffmpeg.org/wiki/Encode/FFV1
Why Golomb Rice coding could just be applied to 8Bit Video?

[shekh]

Hi, to set GOP argument you can use VirtualDub`s "Force keyframes every ... frames" option. It also overrides maximum gop for x264, x265 etc.

Why Golomb Rice coding could just be applied to 8Bit Video
It is limitation of the FFV1 codec itself.

[AKBabel]

Thank you.
I have tried, now and it works.
But it doesn’t affect file size that much in this case.
So maybe I’ll stay with every frame as keyframe.

[shekh]

Yes, it does not help with photographic sources. Maybe works better with something like cartoon, I don't know.

[AKBabel]

Is there any chance to include a flac audio encoder in the VirtualDub modification?

[shekh]

Is there any chance to include a flac audio encoder in the VirtualDub modification?

Chance is good
I already experimented with it and the good news flac is supported in wav/avi formats. The main difficulty is VirtualDub's AVI interleaving algorithm (there was something missing in it).

[sneaker_ger]

AVI isn't really build for variable frame length formats. So for FLAC in AVI you should at least use constant frame lengths. (Or better yet: don't implement it at all. Let old containers die ... )

[LigH]

But VDubFilterMod does not only save AVI. It can also save more modern and flexible containers. — Now I wonder whether it is possible to restrict the content format selection to output containers.

[shekh]

Now I wonder whether it is possible to restrict the content format selection to output containers.

I'm thinking about this. It is possible (not easy) to find which formats are compatible. Making the UI right is more difficult. There should be single "compression dialog" with file format, video and audio.

[SeeMoreDigital]

But VDubFilterMod does not only save AVI. It can also save more modern and flexible containers...Is there any particular reason why the default output container is still .AVI. Could it not be say, .MKV?

[StainlessS]

Is there any particular reason why the default output container is still .AVI. Could it not be say, .MKV?

Should not be changed unless user sets some preference, default should always be AVI.

[SeeMoreDigital]

Should not be changed unless user sets some preference, default should always be AVI.Any particular or technical reason "why" this has to be the case?

The AVI container is so last millennium. It should have been phased out years ago. :scared:

[shekh]

The AVI container is so last millennium. It should have been phased out years ago. :scared:

Many things work perfectly in AVI. It is as good as TGA which is also simple and old.
There is long list of very legacy features.
Who will benefit from this changed default?

Things which do not work in MKV now:
Uncompressed video: not tested at all.
Audio offset: not applied (maybe will fix soon).
File comments: maybe not important at all.

Also, technically you can delete any plugin and live without it.
And since MKV output is in the plugin, how can it be the default? :)

[AKBabel]

Any particular or technical reason "why" this has to be the case?

The AVI container is so last millennium. It should have been phased out years ago. :scared:
Every format has its advantages and disadvantages.
AVI is still alive and it is supported and used, also for archiving.
Things which do not work in MKV now:
Uncompressed video: not tested at all.
Audio offset: not applied (maybe will fix soon).
File comments: maybe not important at all.
Well, mkv is seen as a new free solution for archiving, exactly because of the file comments, its easy editable header structure and its ability to perform a content check via CRC (https://kieranjol.wordpress.com/2016/10/07/introduction-to-ffv1-and-matroska-for-film-scans/).
I saw it also at this year’s IASA conference and that is the reason why I am here, because I consider it as a possible solution beside IMF for our archive.

So, it also would be ideal if there could be a menu inside VirtualDub to edit the metadata of the mkv header (aspect ratio, cropping etc.)

[LigH]

VDubFilterMod has already come a long way since Avery Lee's original VirtualDub, easily passed VirtualDubMod; and its possible future sounds promising with such an inspiration.

[SeeMoreDigital]

Things which do not work in MKV now:
Uncompressed video: not tested at all.
Audio offset: not applied (maybe will fix soon).
File comments: maybe not important at all.

Also, technically you can delete any plugin and live without it.
And since MKV output is in the plugin, how can it be the default? :)In the course of my encoding work I receive A/V sources in many different formats. For many years I've been re-encoding them to 4.2.0 8-bit AVC Lossless and muxing them within the .mkv container.

Personally, I've never had a problem with them...

[jpsdr]

Well, i'm still using a lot AVI, because in my video processing, i have several steps, and i save each steps in lossless avi file (UT Video actualy), which is the easiest way. And it's the final AVI lossless file i feed to my encoder at the end. I absolutely don't want AVI to die, as said, each format as its benefit.

[AKBabel]

Today have tried to load 6K DPX files (roughly 205MB per file) in VirtualDub.
And it could open the sequence, even 16Bit per channel and with alpha. Seeking failed (that could also be a problem of the low access speed of the workstation).
But as I tried to encode it, VirtualDub crashed because it could’t allocate enough memory (for one frame I guess). I have tried to lower the resolution per resize and the encoding started, but it also ran out of memory after a few frames.

[shekh]

Today have tried to load 6K DPX files (roughly 205MB per file) in VirtualDub.
And it could open the sequence, even 16Bit per channel and with alpha. Seeking failed (that could also be a problem of the low access speed of the workstation).
But as I tried to encode it, VirtualDub crashed because it could’t allocate enough memory (for one frame I guess). I have tried to lower the resolution per resize and the encoding started, but it also ran out of memory after a few frames.

Encoding to what?
I experimented with 5000*2500@rgb48 converting to FFV1, and it used around 2GB for encoding. Are you trying with 32-bit version?

[lansing]

I encountered a bug, when I loaded in a 32 bit png, adjust the color using colormill, and then export it as single image out as png, the resulting image became all white.

[wonkey_monkey]

One comment on very short play with current ver$ [a few minutes only], its a bit annoying having to pause scrolling to have display update,
think that there must have been some mod to that since the earlier version I was using (from several months ago).


This is one of three annoying things that led me to alter and recompile VirtualDub myself (my instructions are still a sticky thread although it's out of date now).

Somewhere there is a condition that causes VirtualDub to give up on displaying a frame if it takes over 100ms, and you have scrolled onward in the meantime.

On the subject of AVI vs. MKV, doesn't MKV lack a frame index?

[lansing]

I found another bug with image export. When I loaded in a video and export a frame as single image, in the saving location window, the last output format was used as TIFF with its 2 setting "zip compressed" and "lzw compressed" enabled, and then when I clicked on a png file in the directory, the output format auto changed to png, but the settings didn't change.

[AKBabel]

Encoding to what?
FFV1

I experimented with 5000*2500@rgb48 converting to FFV1, and it used around 2GB for encoding. Are you trying with 32-bit version?
Yes, it was a 32bit version, also a 32bit system, as I found out now.
I’ll later try it with 64bit.

[shekh]

I found another bug with image export. When I loaded in a video and export a frame as single image, in the saving location window, the last output format was used as TIFF with its 2 setting "zip compressed" and "lzw compressed" enabled, and then when I clicked on a png file in the directory, the output format auto changed to png, but the settings didn't change.

Thanks, this is simple.


I encountered a bug, when I loaded in a 32 bit png, adjust the color using colormill, and then export it as single image out as png, the resulting image became all white.

This is interesting. In fact the image becomes transparent (not white) but you need to select dx9 display driver to be able to see it.

There are at least 3 problems:
1. the filter wipes alpha for no reason.
2. switching decode format to rgb24 does no help (this I will fix).
3. there is still no way to enable/disable alpha (will make something).

[shekh]

This is one of three annoying things that led me to alter and recompile VirtualDub myself (my instructions are still a sticky thread although it's out of date now).

Somewhere there is a condition that causes VirtualDub to give up on displaying a frame if it takes over 100ms, and you have scrolled onward in the meantime.


As I understand this problem, VD should display the frame when it is 100% decoded anyway as in the case with avisynth.
Display is not that slow to skip it.

[wonkey_monkey]

If you are on frame x, and use arrow keys or drag the slider to select frame y, it will start to decode frame y - but if, before it has finished, you arrow-key or drag to frame z, VirtualDub won't display frame y at all if the 100ms threshold is exceeded. Which is sort of reasonable, but makes it hard to scrub through the result of an intensive script, as you can't see where you are until stop dragging.

I forget the details, and the VirtualDub forum is now gone so I won't be able to find the post from Phaeron which told me which bit of the source code to change, but I do remember it was a 100ms threshold.

My other bugbear was that during encoding it displayed Time Elapsed, but not Time Remaining, which is by far the more useful number.

[poisondeathray]

A) (vdfm 40716 x64 and x86) - Video => Decode format for pixel format isn't respected for 10bit 422

e.g
1) load a prores 10bit422 source
2) file => file information will say yuv422p10le using caching input driver (so far so good)
3) video => fast recompress will say using conversion yuv422p16-709 ; so you cannot encode yuv422p10le directly (e.g. you won't be able to export v210 or cineform 10bit422 without other conversions with normal or full recompress ). Video compression menu will also report yuv422p16-709 . This is unexpected because yuv422p10le should be direct from decode => encode . If you select video=> compression => uncompressed I would expect v210 out, but you dont get v210.
4) forcing video=>decode format to v210 doesn't "stick"


B) slight color shift when using cineform . Not a 601/709 issue, but a Cr shift, very slight move away from teal to red. Not sure if it's related to conversion, but it affects both native and gopro implementation when using vdfm . I'll do some more tests and report back.
EDIT: color shift was user error. Inconsistent decoder / viewing method / some dithering differences .

[shekh]

A) (vdfm 40716 x64 and x86) - Video => Decode format for pixel format isn't respected for 10bit 422

e.g
1) load a prores 10bit422 source
2) file => file information will say yuv422p10le using caching input driver (so far so good)
3) video => fast recompress will say using conversion yuv422p16-709 ; so you cannot encode yuv422p10le directly (e.g. you won't be able to export v210 or cineform 10bit422 without other conversions with normal or full recompress ). Video compression menu will also report yuv422p16-709 . This is unexpected because yuv422p10le should be direct from decode => encode . If you select video=> compression => uncompressed I would expect v210 out, but you dont get v210.
4) forcing video=>decode format to v210 doesn't "stick"


I do not implement formats exactly as in FFMpeg. yuv422p16 in VDFM is perfect match format for everything from yuv422p9le to yuv422p16le with one caveat: instead of locking bitdepth I keep it as a per-frame metadata. If you feed yuv422p10le in and take yuv422p10le out of the pipeline, there is no scaling applied to pixel values. Except when this is needed for some filter. It is also possible to see the YUV values in filter preview through color picker so you can make sure it looks like 10-bit data (crop filter is good to access this feature because crop itself does not change pixels).
yuv422p10le -> yuv422p16 -> yuv422p10le is as direct as possible, there is nothing to worry about in this conversion.

yuv422p10le to uncompressed as v210: if you mean it should be auto-selected/default I agree. Uncompressed output setup needs some improvement. But you can select "v210" manually.

> forcing video=>decode format to v210 doesn't "stick"

This menu only triggers something when the option actually exists in the decoder.
Same if you open png image and select v210 as decoding format: this is not supported.
v210 decoding is implemented by VFW codecs and also by CineForm sdk.

[WorBry]

@Shekh,

I've been running some tests with VDFM (40716), transcoding native 4K 10-bit 422 clips (from a Panasonic GH5 camera) to various 10-bit 422 formats, including Grass Valley HQX using the GV codecs pack:

https://www.edius.net/hqx.html

Although the codec per se supports 10-bit and 8-bit, 8-bit appears to be the only option with the HQX codec as it presents in the VDFM Compression listing.

https://i.imgur.com/KpARGQq.png

https://i.imgur.com/cPBCFx0.png

Is this a limitation of the VFW codec, as accessible by third-party applications, or is there any possibility of accessing the 10-bit variant ?

[shekh]

HQX vfw codec does not support 10-bit mode. Don't know why they advertise it. I also tried to get an answer from their support with no luck.

[WorBry]

OK thanks. No big deal. It's not my preferred intermediate format anyway.

[WorBry]

Something else I've observed with VDFM (40716 32bit & 40717 64bit) ; when transcoding native 4K and HD AVC (8-bit YV12, Rec709) clips to any YUV format, specular highlights get encoded black. Here's an example:

Source clip: UHD/60p AVC (8-bit, Rec709).mp4 clip shot on a GH5. VDFM frame grabs (resized to 1280x720) - click + cursor to enlarge

Original clip (Decode format YUV420-709):

http://i.imgur.com/jyHc6a7m.png (https://imgur.com/jyHc6a7)

MagicYUV (YUV 420) transcode (Normal Recompress, using conversion YUV420-709 > YUV420, no change in the component range):

http://i.imgur.com/fXlh9CQm.png (https://imgur.com/fXlh9CQ)

Cineform Filmscan 1 transcode (Normal Recompress, using conversion YUV420-709 > YUYV (YUY2), no change in the component range.

http://i.imgur.com/8ujiIVHm.png (https://imgur.com/8ujiIVH)


See how the blown/specular highlights on the light bulbs and coming through the roof skylights are black.

And again, showing the respective AVISynth Histograms:

Original clip (DGDecodeNV > YV12):

http://i.imgur.com/3UnKbL2m.png (https://imgur.com/3UnKbL2)

MagicYUV (YUV 420) transcode:

http://i.imgur.com/qMzRZJ1m.png (https://imgur.com/qMzRZJ1)

Cineform Filmscan1 transcode (ConvertToYV12, interlaced=false):

http://i.imgur.com/MHMuF9qm.png (https://imgur.com/MHMuF9q)

I don't see this aberration (with VDFM 32bit) when the AVS decode script (Decode Format YUV420) is used as the input source for the transcodes. And it doesn't occur with 4K/HD-AVC (8bit) clips recorded with full luma range i.e. decode format YUV420-709-FS.

Sample (2sec) of above clip to test:
http://www21.zippyshare.com/v/77EZFJQ6/file.html

[shekh]

Now I'm on mobile, will see this in few days.

[kolak]

HQX vfw codec does not support 10-bit mode. Don't know why they advertise it. I also tried to get an answer from their support with no luck.

It does support 10bit, but it's not exposed in VFW module.
You would need codec SDK which is not publicly available.

[dipje]

I have a Vapoursynth script outputting RGB48. If I open it in 40716 (x64) it seems to open fine as B64a (as it should IIRC).

Now, I want to try the Cineform encoder, so I set compression to Cineform RGB 12bit (also tried with RGBA 12bit), with the 'input delivery' set to 16bit. The output format selection seems to be RGB64, which is fine.
When I try to save (either to .avi or to .mov) VDFD crashes directly at the start.

Am I doing something wrong or is this a known problem?

[poisondeathray]

I have a Vapoursynth script outputting RGB48. If I open it in 40716 (x64) it seems to open fine as B64a (as it should IIRC).

Now, I want to try the Cineform encoder, so I set compression to Cineform RGB 12bit (also tried with RGBA 12bit), with the 'input delivery' set to 16bit. The output format selection seems to be RGB64, which is fine.
When I try to save (either to .avi or to .mov) VDFD crashes directly at the start.

Am I doing something wrong or is this a known problem?

This works for me in either MOV, AVI container

I don't have 'input delivery' in my cineform dialog box (I'm using Go Pro Cineform (native) . It says "intermediate bit depth" and it's set to 16

Re-importing the export is correctly identified correctly as rgb 12bit

[poisondeathray]

Sample (2sec) of above clip to test:
http://www21.zippyshare.com/v/77EZFJQ6/file.html


For me, it just crashes, regardless of export codec. Both x86, x64 versions

But works ok (without highlight issue) when fed through vapoursynth or avisynth

I think it has to do with the caching input driver

[dipje]

This works for me in either MOV, AVI container

I don't have 'input delivery' in my cineform dialog box (I'm using Go Pro Cineform (native) . It says "intermediate bit depth" and it's set to 16

Re-importing the export is correctly identified correctly as rgb 12bit

Ah crap, so what is broken on my system..
With input delivery I mean the same setting as you, intermediate bitdepth.

Do you have / use an alpha channel in all of this ? I'm feeding it 'dry' non-alpha rgb48 which vapoursynth wraps in b64a for VfW. Maybe I should try with a dummy alpha channel.

Another (very minor) thing. Opening a .vpy file now requires me to explicitly select the avisource reader. Just opening the .vpy gives an ffmpeg error, so I guess the ffmpeg input driver tries to open vapoursynth scripts now. This wasn't always the case.

edit might it even that there is an avx(2) codepath or something enabled in the cineform RGB mode that my old i7 doesn't support?

[kolak]

This works for me in either MOV, AVI container

I don't have 'input delivery' in my cineform dialog box (I'm using Go Pro Cineform (native) . It says "intermediate bit depth" and it's set to 16

Re-importing the export is correctly identified correctly as rgb 12bit

Cineform requires 16bit data input, but data is stored at 12bit precision. It doesn't support as far as I understand 12bit RGB data, like e.g. ffmpeg. It uses common b64a format. This is most likely why you are seeing 16bit.

[dipje]

Cineform requires 16bit data input, but data is stored at 12bit precision. It doesn't support as far as I understand 12bit RGB data, like e.g. ffmpeg. It uses common b64a format. This is most likely why you are seeing 16bit.

The problem isn't the 16bit input (which I get, and I am delivering it 16bit RGB).

My problem is VDFM crashing on my system when I render / save it to a file :)