Mac OS X 10.7 AVCaptureScreenInput setCropRect: 函数中的内存泄漏
我正在为 Lion 开发一个屏幕录制应用程序，它主要使用 Lion 的新 AVCaptureScreenInput 类来获取屏幕上指定矩形的屏幕视频流。一切看起来都很好，但是：
根据活动监视器，每次我调用setCropRect：，内存使用量会增加10-20Mb。由于我提供了在录制过程中可以更改矩形大小的功能，当用户多次更改矩形时，内存使用量可能会增加到 1-2Gb，这是一个灾难:(
我严重怀疑这是否是 Apple SDK 中的错误，因此Apple的示例代码AVScreenShack示例也有这个问题
我的代码是这样的：
[m_AVCaptureSession beginConfiguration];
[m_AVScreenInput setCropRect:CGRectMake((int)grabRect.origin.x, (int)grabRect.origin.y,(int)grabRect.size.width, (int)grabRect.size.height)];
[m_AVCaptureSession commitConfiguration];
谁能告诉我，如果这是SDK中的错误，或者我以错误的方式使用它，或者我应该使用另一个类来做到这一点？谢谢
I'm working on a screen record app for Lion, which mainly use the Lion's new AVCaptureScreenInput class to get a screen video stream for a specified rect on the screen.Everything seems alright but:
According to the activity monitor, every time I call setCropRect:, the memory usage will increase by 10-20Mb. As I provide a feature that the rect size can be changed during recording, The memory usage could increase to 1-2Gb as user changes the rect a lot, which is a desaster:(
I seriously doubt if it is a bug in Apple's SDK, hence Apple's sample code AVScreenShack example has this problem either.
My code is just like this:
[m_AVCaptureSession beginConfiguration];
[m_AVScreenInput setCropRect:CGRectMake((int)grabRect.origin.x, (int)grabRect.origin.y,(int)grabRect.size.width, (int)grabRect.size.height)];
[m_AVCaptureSession commitConfiguration];
Could anyone tell me, if it's a bug in the SDK, or I used it in the wrong way, or should I use another class to do this? THX
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
既然您要打开一个配置事务，进行更改，然后立即提交更改，为什么不忽略该事务呢？库可能会延迟清理事务内存，直到记录会话完成。我认为没有必要使用配置事务，除非您需要一组配置更新是原子的。
或者这可能是真正的泄漏。
Since you're opening a configuration transaction, making the change, and then immediately committing the change, why not omit the transaction? It's possible that the library delays cleaning up transaction memory until the recording session is complete. I don't think it's necessary to use configuration transactions unless you need a group of configuration updates to be atomic.
Or it could be a genuine leak.