DirectShow 过滤器中的静态用法

发布于 2024-12-16 01:21:40 字数 631 浏览 0 评论 0原文

当我们创建一个 directshow 过滤器并注册它时,静态变量/函数在同一过滤器的多个实例中共享。我相信这也适用于其他 ActiveX 控件。例如,如果我尝试使用类似的东西;

static int counter = 0;

void someFunction() {
    counter++;
    // trace result here
}

如果我启动同一过滤器的另一个实例,第二个实例不会从 0 开始,而是从第一个实例计数器剩下的位置开始。然后他们开始异步增加同一个计数器。

我的问题是,是否有任何聪明的方法可以阻止 DirectShow 过滤器的静态变量之间的共享?这可能听起来很愚蠢,但如果我们使用不同的 GUID 注册相同的过滤器(通过使用不同的 GUID 和文件输出重新编译同一项目),静态变量将不再共享,因为它们是两个不同的过滤器,对吗?那么,有什么方法可以使用相同的过滤器来模拟这个,但保持静态呢?

我想做的是使用一个包含许多静态用法的库。摆脱所有静态变量/函数非常困难。我尝试使用的库使用 Ansi C 等旧标准,并且没有真正的面向对象设计。所以,封装并不是一件容易的事。大多数函数都在全局空间中,而不是在类中。请记住这一点。如果我保持静态不变,过滤器的单个实例工作正常,但其他实例由于共享(静态)变量而开始变得混乱。

When we create a directshow filter and register it, static variables/functions are shared in multiple instances of the same filter. I believe this also applies to other ActiveX controls. For instance if I try to use something like;

static int counter = 0;

void someFunction() {
    counter++;
    // trace result here
}

If I start another instance of the same filter, second instance doesn't start from 0 but where first instance counter left. And then they start to increase the same counter asynchronously.

My question is, is there any smart way to block sharing between static variables for DirectShow filters? It may sound silly but if we register the same filter with different GUID (by recompiling the same project with a different GUID and file output), static variables are not shared anymore because they are two different filters, right? So, is there any way I can simulate this using the same filter but keeping the statics?

What am I trying to do is to use a library with many static usage in it. Getting rid of all the static variables/functions is very hard. the library i'm trying to use uses old standards like Ansi C and doesn't have a real object oriented design. So, encapsulation is not very easy. Most of the functions are in the global space, not in classes. Please keep that in mind. If I leave the statics as they are, single instance of the filter works fine but other instances start getting messed up because of shared (static) variables.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

↙厌世 2024-12-23 01:21:40

它实际上并不是 DirectShow 特有的,问题是一个典型的问题:我应该在类的多个实例中使用静态变量吗?

明智的答案:如果您不想使用静态变量,那就不要使用。过滤器的每个实例都是一个类的单独实例。使用它的成员变量,不要使用全局变量。

我想做的是使用一个具有许多静态用法的库
它。摆脱所有静态变量/函数非常困难。

将所有静态数据放入一个大类中,例如“状态”,并为每个过滤器提供该“状态”的单独实例。这确实是首选方式。

另一种解决方案是将所有静态数据移至子 DLL 中并将其加载到进程外,以便每个实例都由单独的进程托管。虽然从技术上讲,这可以直接解决您的问题 - 也就是说,在子进程中,所有静态都保持静态,同时每个所有者过滤器都拥有一个单独的副本,但实现进程外 DLL 和进程间通信所需的知识基本上假设您可以设法成功实施上一段提到的第一个“状态”解决方案。

It is not actually specific to DirectShow, the question is a typical one: should I use static variables in multiple instances of my class.

Smart answer: if you don't want to use static variables - don't. Every instance of your filter is a separate instance of a class. Use it's member variables and don't use globals.

What am I trying to do is to use a library with many static usage in
it. Getting rid of all the static variables/functions is very hard.

Put all your statics into one big class, e.g. "state" and have a separate instance of this "state" per filter. This is really preferred way.

Another solution is to move all statics into child DLL and load it out-of-process, so that each instance is hosted by a separate process. While technically this sovles your problem directly - that is, in a child process all statics remain static and in the same time each owner filter owns a separate copy, the knowledge required to implement out-of-process DLL and interprocess communication basically assumes you can manage to successfully implement the first "state" solution mentioned in the previous paragraph.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文