treat it as an unsigned integer (as one would expect) or with a fixed in-memory
order.
Von: Jason H
Gesendet: Freitag, 15. November 2019 00:42
An: Stefan Fabian
Cc: interest@qt-project.org
Betreff: Re: [Interest] QVideoFrame 32 bit formats byte order
Maybe you shoul
. Note though in openCV, this is an issue. (Blue and Red are swapped in the memory)
Sent: Thursday, November 14, 2019 at 1:54 PM
From: "Stefan Fabian"
To: "interest@qt-project.org"
Subject: [Interest] QVideoFrame 32 bit formats byte order
Hey guys,
I'm interfac
On Thursday, 14 November 2019 21:37:09 CET Allan Sandfeld Jensen wrote:
> On Thursday, 14 November 2019 21:17:38 CET Stefan Fabian wrote:
> > That may be explained by the endianness, though, since ARGB as 32bit uint
> > on little-endian (what most if not all consumer pcs use) would be BGRA in
> > m
On Thursday, 14 November 2019 21:17:38 CET Stefan Fabian wrote:
> That may be explained by the endianness, though, since ARGB as 32bit uint on
> little-endian (what most if not all consumer pcs use) would be BGRA in
> memory. In the case of BGRA32, endianness could change it to ARGB but not
> ABGR
memory is interpreted (consecutive
bytes [big-endian] or one 4 byte word per pixel [cpu dependent]).
Von: David M. Cotter
Gesendet: Donnerstag, 14. November 2019 21:04
An: interest@qt-project.org
Cc: Stefan Fabian
Betreff: Re: [Interest] QVideoFrame 32 bit formats
I had a similar finding.
i find that QImage::Format_ARGB32 is always 0xBBGGRRAA on both mac and windows
unrelated to video, but just allocating a QImage
> On Nov 14, 2019, at 11:54 AM, Stefan Fabian
> wrote:
>
> Hey guys,
>
> I'm interfacing external camera input to Qt/QML (version 5.9.5 on
Hey guys,
I'm interfacing external camera input to Qt/QML (version 5.9.5 on Ubuntu 18.04).
For this, I'm using a custom video source and present the frames using
QVideoFrame and QAbstractVideoBuffer.
The image is displayed in QML using a VideoOutput.
Since not all formats can be mapped directly,
