VirtualDub2

[v0lt]

Originally Posted by Hushpower

@Volt, FYI, the file in this post:

https://forum.videohelp.com/threads/...on#post2753941

won't open in your Vdub 2.1. It throws an error:

"FFMPEG: Unsupported Channel Layout"

FFmpeg 7.1 reports that the audio track has no information about the audio channel layout.

AV_CHANNEL_ORDER_UNSPEC
Only the channel count is specified, without any further information about the channel order

Accordingly, the plugin cannot automatically assign channels (left, right, subwoofer, etc.). If there were 2 channels, then we could assume that this is stereo, but you have 16.

[v0lt]

Question for C++ experts.
Can anyone remove (replace) the obsolete std::allocator from the VirtualDub2 source code?

[Hushpower]

@Volt

FFmpeg 7.1 reports that the audio track has no information about the audio channel layout.

Accordingly, the plugin cannot automatically assign channels (left, right, subwoofer, etc.). If there were 2 channels, then we could assume that this is stereo, but you have 16.

So it must be a bug or recent "shortcoming" in FF 7.1, because the previous avlib plugin opened that file with no issues.

Where would I report this?

[v0lt]

Originally Posted by Hushpower

So it must be a bug or recent "shortcoming" in FF 7.1, because the previous avlib plugin opened that file with no issues.

Older versions of FFmpeg and the avlib plugin opened this file incorrectly.

For regular audio tracks, there is a one-to-one mapping of the audio channel to the audio speaker.
This mapping is done either through a specific channel order and channel mask, or it is described in standards (see Dolby Digital, DTS). You can read more in the article "Surround sound" in Wikipedia.

There is nothing like that in your file. Perhaps all these tracks are obtained from special software for working with sound. Someone made a full export without proper mixing to standard channel layouts (stereo, 5.1, 7.1, etc.).

[Hushpower]

Originally Posted by Volt

Older versions of FFmpeg and the avlib plugin opened this file incorrectly.

As I said in my first post, VDub2.0 44282 opens that file without issue, and it can be exported as two-channel after setting up the audio conversion. How it does it, I don't know. Certainly, with the "original" 40,071kb avlib plugin (without all those DLLs), VDub2 opens it without issue.

The original avlib plugin in VDub2.0 obviously uses a different process to both the new avlib plugin, and the avlib plugin in VDub 2.1.

The old avlib opens it OK, the new one (with it's new DLLs) doesn't. That's all I'm pointing out.

Perhaps all these tracks are obtained from special software for working with sound. Someone made a full export without proper mixing to standard channel layouts (stereo, 5.1, 7.1, etc.).

It came from Latreche/Dellsam:

In an effort to ditch the computer for capturing (a thread is coming) I use the BM HyperDeck Shuttle 2 to record from SDI out of the analog capture device, The files are recorded in lossless quicktime because it's the only format the Hyperdeck 2 accepts, I have trouble working with this format, for one MPC-HC doesn't play it albeit VLC does, It writes 16 audio ch even when there is only two active

[v0lt]

Originally Posted by Hushpower

It came from Latreche/Dellsam:

Obviously you need to reconfigure your capture device or fix the resulting file.

ffmpeg -i "HyperDeckS2.mov" -af "channelmap=0|1:stereo" -c:v copy -c:a pcm_s24le "HyperDeckS2_fix.mov"

[Hushpower]

No need, I'll just use VDub 2.0.

[v0lt]

VirtualDub2_v2.1.2.655 (test build)
various code reworks
added experimental Win32 support

[rgr]

VDub crashes if we put propset("_Matrix") with invalid values ​​(e.g. a string) in AviSynth code.

[v0lt]

Originally Posted by rgr

VDub crashes if we put propset("_Matrix") with invalid values ​​(e.g. a string) in AviSynth code.

There's a lot you haven't said. But I doubt there are people here who would want to guess all the nuances of your problem.

[rgr]

Originally Posted by v0lt

There's a lot you haven't said. But I doubt there are people here who would want to guess all the nuances of your problem.

Now I see that VDub doesn't want to crash. I'll check it again.

[v0lt]

VirtualDub2_v2.1.2.661 (test build)
Fixed a crash when capturing video and saving to ProRes and other similar formats.
avlib-1.vdplugin: Fixed freezing after early interruption of writing to a file when using some codecs.
scripted.vdplugin: The list of keywords, internal functions and internal filters for AviSynth+ has been updated.

[SupermanTV]

v0lt, thanks for this test build with the ProRes (avi) capture fix.

Played around with it and seems to be working ok, at least the way that last vDub2 v44015 did. (yuv4:2:2 working).
Good to have this available again!!

Also, as I mentioned in my original post about this issue,
do you know why these Prores (avi) files trigger 'COM Surrogate' error and crash on Win 10?
I'm thinking it could be related to 'metadata' handling/implementation, thumbnails maybe...?

Another question: I would think you're applying the 'generic' prores implementation..!? (prores, prores_aw, prores_ks)

Keep up the good work!!

PS... For reference, this is my original issue with ProRes avi:
https://forum.doom9.org/showthread.php?t=185848

[v0lt]

Originally Posted by SupermanTV

Another question: I would think you're applying the 'generic' prores implementation..!? (prores, prores_aw, prores_ks)

FFmpeg 7.1.

[nji]

I recently noticed that (some?) HD movies (1920x1080p, YUV4:2:0)
which are not explicitely labeled as bt.709
are shown in VD2 orig pane as if VD2 takes them as bt.609
(esp. this typical small shift red/yellow to green/blue).

If I use alias format filter as first filter and choose bt.609
both panes (orig and result) are the same.
If choosing bt.709 in the filter the result pane is more red/yellow than the orig pane.
==> Conclusion: orig movie is colorspace bt.609.

BUT:
The orig movie actually is the red/yellow one!
At least MPC-HC shows it that way...

So VD2's orig pane view is misleading...

Or is it about the default handling of the case that movie dimensions are HD,
but no color entry (which usually means bt.609)?

[LigH]

It's 601 vs. 709.

And it might indeed be a matter of default values. Some renderers may assume that any resolution larger than SD (e.g. DVD Video resolutions as threshold) is BT.709; other renderers may be set up to assume BT.601 if not explicitly flagged otherwise. Hard to tell, there are different places where that default could be set up (e.g. another YUV - RGB conversion in front of the renderer), there are different renderers which could be used by different methods of playback ...

[nji]

Still it's not just a "cosmetic issue", but an important one:

If the views of the don't show the real thing,
I will be mislead and probably use (incorrectly) a color filter...

[LigH]

So how is your VirtualDub2 set up? Which kind of display does it use: DirectX at all? DirectX 9 or 11? Or OpenGL? Or Hardware Overlay? And how is your graphic driver set up in case of Hardware Overlay?

And which does the media player use you compare VirtualDub2 to? It will probably be a different renderer.

You cannot blame the VirtualDub2 author for things you did (not) set up or VirtualDub2 cannot control from itself. But we can both wait for a reply from a more competent person than me ...

[nji]

Originally Posted by LigH

...
You cannot blame the VirtualDub2 authors ...

No, I do not blame anyone.

I just want to point out that there is a pitfall,
that might result in systematic downgraded movies.
(At least this was the case for me).

And that this pitfall might be avoided...

[v0lt]

In the new avlib-1.vdplugin the logic is as follows:

if (colorspace == AVCOL_SPC_UNSPECIFIED) {
  if (width <= 1024 && height <= 576)
    cs = BT601;
  else
    cs = BT709;
}