使用directdraw显示YUV数据时的线程数量

[chen43030]

分只有这么多了，希望能得到各位的指导，谢谢！
我将一个视频解码的sdk封装为一个OCX控件，在OCX控件中将解码得到的YUV420数据用directdraw显示，然后另外写了一个MFC程序来调这个OCX控件，发现在显示的时候，除了主线程和我自己创建的一个线程，自己创建的线程用来从队列里取数据，然后调用封装的directdraw函数来显示，通过任务管理器看该进程，发现有3个线程，为什么会有3个线程呢？将该程序拿到一个笔记本电脑上试，发现竟然有5个线程；为了查找问题，我专门写了一个win32程序，在win32程序中起一个子线程读取YUV文件然后交给directdraw显示，显示部分的代码和OCX中的一样，运行该win32程序，出现了更奇怪的问题，测试了5台机器，有两台(win7 x64和xp x86)的线程数为2个，有两台(win7 x86和win7 x64)的线程数为3个，而另一个笔记本(win7 x86)的线程数竟然为5个，因为OCX空间要给另外的程序调用，有可能会开二三十个窗口，这样的线程数就太多了，线程间的切换就会耗费CPU太多的时间，必须要优化，是不是和显卡的驱动有关系呢？谁能告诉我这是为什么呢？

[www_adintr_com]

你的解码库里面的代码会不会开了线程... 在调试器里面对 CreateThread 这个 API 下断点, 看看谁在调用它开线程吧.

[chen43030]

引用 3 楼 turingo 的回复:

应该是视频解码本身产生的线程，需要跟踪到最底层的实现。

问题后面写的win32程序专门直接读取yuv文件，根本不需要解码的，用directdraw做显示，不同的机器，线程数任然不一样！

[图灵狗]

可以先把所有的可能性列举出来，然后一一讨论。

引用 4 楼 chen43030 的回复:

[quote=引用 3 楼 turingo 的回复:] 应该是视频解码本身产生的线程，需要跟踪到最底层的实现。

问题后面写的win32程序专门直接读取yuv文件，根本不需要解码的，用directdraw做显示，不同的机器，线程数任然不一样！[/quote]

[chen43030]

引用 1 楼 adlay 的回复:

你的解码库里面的代码会不会开了线程... 在调试器里面对 CreateThread 这个 API 下断点, 看看谁在调用它开线程吧.

已经排除了解码库中的线程，所以为了验证，特地的写了win3程序，另外在线程里设断点后，从调试--线程里看到另外三个线程都无法跟踪的，应该是系统的线程。

[图灵狗]

应该是视频解码本身产生的线程，需要跟踪到最底层的实现。