linux-kernel - Re: [PATCH v5 00/39] i.MX Media Driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 19 Mar 2017 17:00:08 +0200
From:   Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
CC:     Steve Longerbeam <steve_longerbeam@...tor.com>,
        Steve Longerbeam <slongerbeam@...il.com>, <robh+dt@...nel.org>,
        <mark.rutland@....com>, <shawnguo@...nel.org>,
        <kernel@...gutronix.de>, <fabio.estevam@....com>,
        <mchehab@...nel.org>, <hverkuil@...all.nl>, <nick@...anahar.org>,
        <markus.heiser@...marIT.de>, <p.zabel@...gutronix.de>,
        <laurent.pinchart+renesas@...asonboard.com>, <bparrot@...com>,
        <geert@...ux-m68k.org>, <arnd@...db.de>,
        <sudipm.mukherjee@...il.com>, <minghsiu.tsai@...iatek.com>,
        <tiffany.lin@...iatek.com>, <jean-christophe.trotin@...com>,
        <horms+renesas@...ge.net.au>,
        <niklas.soderlund+renesas@...natech.se>, <robert.jarzmik@...e.fr>,
        <songjun.wu@...rochip.com>, <andrew-ct.chen@...iatek.com>,
        <gregkh@...uxfoundation.org>, <shuah@...nel.org>,
        <sakari.ailus@...ux.intel.com>, <pavel@....cz>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-media@...r.kernel.org>, <devel@...verdev.osuosl.org>
Subject: Re: [PATCH v5 00/39] i.MX Media Driver

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