will

It turns out that I was wrong to say that this isn't an OS dependent issue. It was just a missing driver that was causing the problem with my Win10 pcs. Still doesn't work on Win7 pcs though, even with driver. I think you may be right though. I'm getting a negative stride of -1920 (rather than 3840) for the pcs that still don't work (all Win7). Is it possible for the same camera to need to be read in as bottom up on Win7 and top down on Win10? That still wouln't account for the stride being the wrong...

I think you may be right. I just checked the source stride for one of the laptops that doesn't work and it is negative. The stride is positive on the pcs that do work. Is it possible for the same camera to need to be read in as bottom up on one pc and top down on another then? I didn't think that this was possible.

Thanks for the fast response!! Something else I should mention. On my original PC (one of the ones that works), it was calling TransformImage_YUY2 from VideoFormatHelper (I've been using your example code), however, with the PCs that don't work, it called TransformImage_RGB24 instead. The program then then fell over when trying to access the variable "source" in this function, with an access violation exception - I assume because the source is actually of type YUY2 and not RGB24. I tried to fix this...

Hi, I've built a program using this library to read and display video from USB cameras (I'm using a Logitech C920s). I have managed to get it working fine on my own PC but when I try to run the software on other PCs/Laptops with exactly the same cameras I'm getting some strange errors. OnReadSample is returning MF_SOURCE_READER_FLAG = MF_SOURCE_READERF_ERROR and the size of the sample returned is wrong. I have tested this on multiple devices and on each device I'm getting a different, incorrect sample...