On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote: > On Sun, Mar 19, 2017 at 02:21:10PM +0000, Russell King - ARM Linux wrote: >> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9, >> analysed it for the cause of the failure, and tried several different >> pipelines, including the standard bayer2rgb plugin. >> >> Please don't blame this on random stuff after analysis of the logs _and_ >> reading the appropriate plugin code has shown where the problem is. I >> know gstreamer can be very complex, but it's very possible to analyse >> the cause of problems and pin them down with detailed logs in conjunction >> with the source code. > > Oh, and the proof of correct analysis is that fixing the kernel capture > driver to enumerate the frame sizes and intervals fixes the issue, even > with bayer2rgbneon being used. > > Therefore, there is _no way_ what so ever that it could be caused by that > plugin. > Hey, no blaming of the unknown to me bayer2rgbneon element from my side, I've just asked an innocent question, thanks for reply. I failed to find the source code of the plugin, I was interested to compare its performance and features with mine in-house NEON powered RGGB/BGGR to RGB24 GStreamer conversion element, which is written years ago. My question was offtopic. -- With best wishes, Vladimir _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
