Good effort by the OP , cliff_622 to set the stage. Unfortunately the first reply to his/her post is exactly where this thread should not go, but probably inevitably will do SO anyway.

But in good faith to the thrust of the OP, this has been discussed with some of the top programming team over the years with SCS in not too distant past. You may be able to do deep DATA thread mining search of this forum to see some of those responses. What DOES remain true is that this remains a difficult subject to be literally dissected. Over the years the stretch for compatiblity across all versions of the Windows OS platform has indeed become "too" much of a stretch.

One example of a stretch for a single infrastructure module in software design - is the number of iterations or versions that the software is released forward. Sure, we have a good stable version 13 build at the present time - BU literally there are many consumers using earlier version builds on earlier forms of an OS and maybe very happy with what they have. If you release a post 13 version with no infrastructure renewal, you are in a sense competing with all previous versions that have been released - and this will severely decimate potential revenue forward.

AND on other hand think of the tremendous up front investment to go forward with a new infrastructure- high risk and no guarantee of any potential revenue at all.

Something to think about.

videoITguy said, "Unfortunately the first reply to his/her post is exactly where this thread should not go,..."

Why not?

" they own the rights to the interface, why not? " sounds like just changing the GUI, they way I want it will fill the bill?

> "As many of us know, the core playback engine of Vegas today is an ancient Microsoft technology called "Video for Windows" (VFW). VFW is something that Microsoft has abandoned way over a decade ago and is no longer supported by them. However, Vegas is still heavily dependent on it."

Whenever I read this, I wonder is there any official document or confirmed fact that proves this statement? Where did you get it?

Note these discussions about codecs serviced by VegasPro

http://www.sonycreativesoftware.com/forums/showmessage.asp?forumid=4&messageid=920274


http://www.sonycreativesoftware.com/forums/showmessage.asp?forumid=4&messageid=921969

most important discussion of one particular codec as mentioned in above threads...

MagicYUV runs on Windows XP/Vista/7/8, Mac OS X and Linux platforms (32/64 bit - x86/x64 architectures).

MagicYUV requires a CPU which supports the SSE2 instruction set. Most modern 32 bit CPUs manufactured since 2005 (Intel CPUs since Pentium 4 and Pentium M, and AMD CPUs since Athlon 64) and all 64 bit CPUs support this. To see if your CPU is compatible, check the processor’s specification or use a utility like <CPU-Z>. Look for the word “SSE2” in the features list.

Supported software

On Microsoft Windows platforms MagicYUV is implemented as a 32/64 bit VFW (Video For Windows) codec, QuickTime component and a VLC decoder plugin (32/64 bit). As such, any program supporting the VFW (AVI file) API interface will be able to utilize MagicYUV for video compression and display. This practically means nearly all NLE and post-production software in use today. This also includes all DirectShow-based media players. The QuickTime component also allows the codec to be wrapped in the MOV file format, and the VLC plugin allows both AVIs and MOVs to be played back.

On Mac OS X MagicYUV is available as a QuickTime component and a VLC decoder plugin (64 bit). and..On Linux MagicYUV is available as a VLC decoder plugin (32/64 bit) for various versions of VLC.

Good question. Not wanting to go over my head, but hasn't Vegas been using Net Framework for some time which should allow compatibility with DirectX, etc. What about x64 versions? Can't imagine Vegas building on that without having the ability to tap future technology?

-- tom

We are not in the business of designing the internals of Vegas and we do not have access to its structures, let alone the raw code, so I see no point agonizing over this question. It can remain a black box with its familiar interface for all I care. We pay the developers through upgrades to do this work for us.

Learn to delegate!

Why keep a dog and do your own barking?

No, I cannot confirm that Vegas uses VFW. I have only read this 10,000 million times in all the years I have used Vegas.

I am certainly open to anybody that can officially debunk this!

I'm looking for an open discussion about the TECHNICAL problems of VFW and Vegas moving forward with or without it. I'd love for somebody with strong knowledge of this topic to weigh in here.

CT

"No, I cannot confirm that Vegas uses VFW. I have only read this 10,000 million times in all the years I have used Vegas."

The internet sure is full of...

Talk is cheap. Anyone making such a claim needs to provide details.
VfW is well known. By that what is does and does not do. Vegas features are well known. Vegas actual internals are not known.

The differences of Vegas capabilities and this supposed VfW dependence must be resolved and explained.

Vegas certainly does use VfW to decode an AVI file with a codec other than Cineform and Sony YUV 10-bit. VfW bypassed for those. Same for encode to AVI. For other stuff, excluding Quicktime, Vegas primarily uses Mainconcept decoders and encoders. Resolve Mainconcept and VfW. Resolve Quicktime and VfW.

NLE's composite/overlay multiple tracks/streams. This is beyond VfW. Is the internet Vegas/VfW claim that for some reason Vegas transforms its multi-track results into a VfW stream just to playback. Why? Why do all that extra work when you can just simply draw the frame to the screen, or send to a file encoder (e.g. AVC/H.264) or both. How does this setup deal with the need to re-sync video/audio when the video cannot be done a realtime framerate?

I don't claim to know the Vegas setup but since this is the internet I will add my speculation to the fun.

Vegas certainly does have its own internal dataflow structure. This defines the rules of how and when the order of operations work. The Matrix it is not. The dataflow may have not changed much since the beginning and Vegas is a very long lived and mature app. Vegas has lived through some big changes in the video world from primitive to the myriad of things going on these days. 32-bit float components, GPU, OpenFX and so on. You can keep adding features but some may just not fit the existing dataflow very well so the implementation can be ugly and maybe not as efficient as it can be. The developers can bitch to the bean counters and the bean counters can say yes, we will let you re-structure in the next version but "next" keeps becoming the next version again and again and again.

I would surmise that GPU is a possible critical point here. Quickly people think GPUs are faster than CPUs. Actually they are much slower than CPUs at doing a computation. What a GPU can do better than a CPU is massively parallel computations. Only massively parallel applications are good targets for GPUs. Image processing, still or video, does fit this mold. By this I mostly mean effects, compositing and such. Not video decode or video encode. To get the best performance you gotta keep the pipeline moving in the GPU to get full benefit. An application dataflow model might be fighting you in this regard.

It seems obvious that SCS did not want to be in the NLE marketplace that Vegas sells best into. Do you rework Vegas, internals and GUI (aka Mac), to try and compete better in areas it does not or do you take a different track.

I thought part of the "pain" of moving from v8.1 to ~V11 was conversion from VFW to more modern architecture? I didn't think VFW was ever ported to 64bit?

So can we safely that VFW components are used only for "some" playback functions but not others in Vegas?

Nobody loves Vegas more than I do but if there is only one complaint I have with it is that it's playback is nowhere near the level of Premiere's "Mercury" engine. I'm using a GTX 970 on my desktop and a 770 on a laptop. Premiere plays back .mp4 wrapped UHD XAVC-S and .mxf wrapped XAVC-L at a MUCH smoother rate than Vegas does. The difference is pretty dramatic.

What is the key to this? What is Vegas lacking that Premiere has? I'm talking about big playback/decoding differences with the exact same PC hardware.

If MAGIX can figure this out, I really think that with the right marketing, Vegas can catch Premiere and overtake it in the years to come. Vegas' UI is just so much better.

Vegas' simple ability to insert a plugin (or a chain of them) at the CLIP level, then the entire TRACK level and then entire PROJECT level is brilliant. Premiere cant even do that simple thing in this way that Vegas easily does it..

More thoughts of VFW technology? Is it "partially" there is it not? Is it negatively affecting Vegas at all?

new technology does not need to exclude past technology. they can coexist peacefully. or at least an option to select wich to use. for my use, the way it is are already great.

To summarize: Vegas uses VfW only to work with AVI format.

I found this on Microsoft's MSDN forum dated September, 2012:

Media Foundation is intended, over time, to replace all previous multimedia playback technologies. It is first a successor to DirectShow, but certainly is intended to replace much older multimedia technologies like Video for Windows

It is also mentioned here in wikipedia: https://en.wikipedia.org/wiki/Media_Foundation

Jerry
http://www.takeonesolutions.com
Photography • Video