realtime data streaming between matlab and opencv, visual c++

Question

newbie 2012-6-22

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/41797-realtime-data-streaming-between-matlab-and-opencv-visual-c

My C program tracks any particular colour in a video and prints the coordinates of that point. I want to write a matlab program which can take these coordinates as input and analyse them.I am doing all this in windows XP. I have read about mex files and also about the memory mapping but, nothing is working.

When I build my mex file, it shows many errors with the core.hpp file like:

"ptrdiff does not belong to the class std"

can anyone help?

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Geoff 2012-6-24

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/41797-realtime-data-streaming-between-matlab-and-opencv-visual-c#answer_51652

How "realtime" do you need? If you were polling a file multiple times a second, would that be sufficient? Can you do your analysis in blocks, or must it be live? After analysis in MatLab, do you need to deliver a result back to the C++ program? How complicated is your analysis - ie is there any reason not to do it in C++?

The best option in my opinion would be to try and get UDP communication going. Have your tracking application simply fire off the coordinates to localhost using UDP on some port. If your MatLab script is listening, it will start receiving the data and can do something with it. If it needs to communicate back, have it fire off UDP packets on a different port, which your tracker is listening on.

Presumably you are comfortable with threading, synchronisation and network communications?

A quick Google search pulled up something vaguely promising:

http://webscripts.softpedia.com/script/Scientific-Engineering-Ruby/TCP-UDP-IP-Toolbox-36497.html

Or there is TCP/IP code if you feel like bashing your head against a wall:

http://www.mathworks.com/matlabcentral/fileexchange/21131

But if polling a little file is responsive enough, do that. I would just use binary so I could be sure I had read the entire co-ordinate. I'd know how many bytes to expect and, if I appended to the file (preferable to avoid syncronisation issues or data corruption) it would contain a complete record for post-analysis if necessary.

9 个评论
显示 7更早的评论隐藏 7更早的评论

Geoff 2012-6-26

I anticipate the problem would be file buffering on the write side. I would first attempt to write the file using functions from stdio, and try fflush(). If that didn't reliably flush to disk, I'd try something lower-level. This involves opening the file with no caching or buffering. See MSDN for CreateFile(). You have to write a whole sector at once, so you need to be comfortable with data manipulation in C and probably have some insight into data protocols -- This is because your MatLab program can no longer read to the end of the file (since a lot of it will be padded to fill the sector) and you would need to include some basic control signals in the file. Something as simple as a stop-byte to terminate the co-ordinate should be fine... Your packet would look like this: [X_8bytes][Y_8bytes][CTL_1byte]. Therefore 17 bytes per co-ordinate. I would zero-pad the file and make the stop-byte anything non-zero. 0xff would be fine. I don't know how well MatLab would cope with reading this file, as I'm not familiar with its buffering scheme.

Geoff 2012-6-27

Walter, I didn't believe you about having file locking problems, and I expect this is to be run on a local machine and local disk. So I decided to benchmark it. I made a simple source/sink console application using stdio functions, and had it output packets containing the performance counter value at the source. The sink would read these immediately after querying the performance counter and output the packet lag. Source and sink ran as two separate processes. At 30fps, including a 1ms Sleep in the read loop, the lag peaked at 3% of a frame. I ran it at 500fps with no Sleep and the peak was about 7% lag (with the Sleep it was around 60%, which is to be expected). In short: communication via file is perfectly viable. At least, in C. I did not test this using MatLab as the reader, but I don't see why it would be a problem. Just make sure you call fflush() after writing. You can have the file open for write on the source and read on the sink simultaneously with no problems.

Geoff 2012-6-27

Okay, had some more fun with this. I ported my Sink code to MatLab and confirmed this method works fine - average lag was 0.05% of a frame with very occasional peaks up to about 2%. No frame dropping observed. Caveat is that you need to busy-wait (ie poll the file stupidly fast) or MEX a better pause() function. I would take the simplest route and poll very fast, because this at worst is only going to max out one core. Anyway, that core is going to spend the rest of its time processing co-ordinates, so getting hold of a co-ordinate ASAP means you have about 30ms to process it.

请先登录，再进行评论。

realtime data streaming between matlab and opencv, visual c++

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

回答（1 个）

9 个评论
显示 7更早的评论隐藏 7更早的评论

另请参阅

类别

标签

Community Treasure Hunt

realtime data streaming between matlab and opencv, visual c++

0 个评论 显示 -2更早的评论隐藏 -2更早的评论

回答（1 个）

9 个评论 显示 7更早的评论隐藏 7更早的评论

另请参阅

类别

标签

Community Treasure Hunt

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

9 个评论
显示 7更早的评论隐藏 7更早的评论