Re: [Development] Qt 5.12 branch is broken for Android
On Wed, Jan 02, 2019 at 07:35:45PM +0200, Aleksey Kontsevich wrote: > Should I assign this regression to You as well: > https://bugreports.qt.io/browse/QTBUG-72687? > what makes you think that i introduced it? > 02.01.2019, 18:47, "Oswald Buddenhagen" : > > that applies to any _recent_ regressions introduced by me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12 branch is broken for Android
Hi Oswald, Should I assign this regression to You as well: https://bugreports.qt.io/browse/QTBUG-72687? -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 02.01.2019, 18:47, "Oswald Buddenhagen" : > On Wed, Jan 02, 2019 at 02:35:42PM +0200, Bogdan Vatra via Development wrote: >> I'm trying to compile Qt for Android and 5.12 branch received quite a lot >> configure changes which broke Android builds > >> (though I thought that 5.12 branch is for bug fixes only). > > the series did fix quite some bugs, at the cost of being somewhat > invasive. ok, massively invasive. 5.12 is at the beginning of an LTS > lifecycle, so i took some liberties. ^^ > >> Now configure mixes host libs with the target (android) ones, which IMHO is >> very wrong when cross-compiling :). >> Can some qmake master take a look and fix the problem? > > if you're sure you have the latest revision and a completely clean build > tree (including no stray .qmake.cache/.stash/.super files there or > up-tree), make a _proper_ bug report on jira and make sure it's assigned > to me. > that applies to any _recent_ regressions introduced by me. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QAbstractVideoFilter, the pipeline and QImage
Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have
if (flags & QVideoFilterRunnable::LastInChain) {
... generate the frame for the backend per the surfaceFormat
}
As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:
VideoOutput {
filters: [sobel, houghLines]
}
VideoOutput {
filters: [sobel, houghLines, final]
}
Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion. Maybe there's a way to register a conversion from a custom type to a QVideoFrame?
Also, if the VideoOutput is not needed* the final filter need not be invoked.
By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.
I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would be really nice if it could be 1:N. I experimented with this, and the first VideoOutput is the only one to receive a frame from a source, and the only one with an active filter pipeline. How could I have 3 VideoOutputs, each with it's own filter pipeline and visualize them simulatneously?
Camera { id: camera }
VideoOutput { // only this one works. If I move this after the next one, then that one works.
filters: [sobel, houghLines]
source: camera
}
VideoOutput {
filters: [sobel, houghLines, final]
source: camera
}
So to sum this up:
- Qt should provide automatic frame reconstruction for the final frame (that big if(){} block) (it should be boilerplate)
- A way to register custom format to QVideoFrame reconstruction function
- Allow for multiple VideoOutputs (and filter pipelines) from the same source
-- Maybe an element for no video output pipeline?
Am wrong in thinking any of that doesn't already exist or is a good idea?
Sent: Saturday, December 22, 2018 at 5:10 AM
From: "Pierre-Yves Siret"
To: "Jason H"
Cc: "Qt development mailing list"
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
The filter pipeline starts with a file or camera device, and various filters are applied sequentially to frames. However I spend a lot of time converting frames to QImages for analysis and painting. I'm hoping there's a faster way to do this. Some of the filters alter the frame, some just provide information about the frame.
But each time, I have to unpack a QVideoFrame's pixels and make sure the filter can process that pixel format, or convert it to one format that it expects. I'm getting processing times of 55msec on my mackbook pro, which give me 18FPS from a 25FPS video, so I'm dropping frames. I am starting to think the ideal would be to have some "Box of Pixels" data structure that both QImage and QVideoFrame can use. But for now, I convert each frame to a QImage at each stage of the pipeline.
I'm not that versed in image manipulation but isn't that the point of the QVideoFilterRunnable::LastInChain flag ?
Quoting the doc:
"flags contains additional information about the filter's invocation. For example the LastInChain flag indicates that the filter is the last in a VideoOutput's associated filter list. This can be very useful in cases where multiple filters are chained together and the work is performed on image data in some custom format (for example a format specific to some computer vision framework). To avoid conversion on every filter in the chain, all intermediate filters can return a QVideoFrame hosting data in the custom format. Only the last, where the flag is set, returns a QVideoFrame in a format compatible with Qt."
You could try using just one pixel format and use that in all your filters without reconverting it at each step.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12 branch is broken for Android
On Wed, Jan 02, 2019 at 02:35:42PM +0200, Bogdan Vatra via Development wrote: > I'm trying to compile Qt for Android and 5.12 branch received quite a lot > configure changes which broke Android builds > (though I thought that 5.12 branch is for bug fixes only). > the series did fix quite some bugs, at the cost of being somewhat invasive. ok, massively invasive. 5.12 is at the beginning of an LTS lifecycle, so i took some liberties. ^^ > Now configure mixes host libs with the target (android) ones, which IMHO is > very wrong when cross-compiling :). > Can some qmake master take a look and fix the problem? > if you're sure you have the latest revision and a completely clean build tree (including no stray .qmake.cache/.stash/.super files there or up-tree), make a _proper_ bug report on jira and make sure it's assigned to me. that applies to any _recent_ regressions introduced by me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Use QMetaEnum::keyCount() to initialise array
On Wednesday, 2 January 2019 09:45:29 -02 Thiago Macieira wrote: > Because the information is not known to the compiler at compile time. To be stricter: it *is* know to the compiler, but without a constexpr reflection API, we can't get the information out of the compiler and into code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 5.12 branch is broken for Android
Hi, I'm trying to compile Qt for Android and 5.12 branch received quite a lot configure changes which broke Android builds (though I thought that 5.12 branch is for bug fixes only). Now configure mixes host libs with the target (android) ones, which IMHO is very wrong when cross-compiling :). Can some qmake master take a look and fix the problem? Cheers, BogDan. P.S. 5.12.0 branch compiles with no problems ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Use QMetaEnum::keyCount() to initialise array
On Monday, December 31, 2018 2:56:29 PM CET Marco Bubke wrote: > Is it because the meta type information could be created later? What about adding > a constexpr version like: QMetaEnum::compileTimeFromType? Or do we wait for > static reflections? Yes, sometimes, but the fact that the output changes is more problematic. This would break if an enum form a dynamically linked library is used, for example: const QMetaEnum metaEnum = QMetaEnum::fromType(); int MyArray[metaEnum.keyCount()]; metaEnum.keyCount() value would be inlined in an app and then a Qt update, which adds a new enum value, would break the app. Technically you could have something like that: QVarLengthArray.keyCount> MyArray(metaEnum.keyCount()); but that would require new API convention and some research, because it looks like a nice source of bugs. Dropping BC would also help. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Use QMetaEnum::keyCount() to initialise array
On Monday, 31 December 2018 11:56:29 -02 Marco Bubke wrote: > Is it not nice to share your knowledge why it is not possible? Is it > because the meta type information could be created later? What about adding > a constexpr version like: QMetaEnum::compileTimeFromType? Or do we wait for > static reflections? Because the information is not known to the compiler at compile time. You need moc's parsing of the header in order for it to count how many enumerators are there in the enumeration. Like you said, if we had static reflections, we could do this entirely in the compiler -- we would do possibly ALL of moc as part of reflections. But until that happens, moc needs to run and will produce a .cpp with the count. If you did have access to moc's output, you could access the enumeration count in constexpr time. After all, QMetaEnum::keyCount is simply: const int offset = priv(mobj->d.data)->revision >= 8 ? 3 : 2; return mobj->d.data[handle + offset]; Note that moc produces those arrays as "static const", not "constexpr", so it may not be accessible *today* at constexpr evaluation time. Or it could. I don't remember if "static const" counts as constant expression... The problem is that you have to #include the moc's output in the TU that wants to create the OP's array. And it must be #include'd or built by the build- system exactly *once*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CI upgrade
On Wednesday, 2 January 2019 04:34:43 -02 Tony Sarajärvi wrote: > agent:2019/01/01 20:15:26 build.go:193: Config: Using QtTest library 5.12.0, > Qt 5.12.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC > 5.3.1 20160406 (Red Hat 5.3.1-6)) This is a native x86-64 build and run. I don't see how it could be related to QEMU. The other one you said is Windows 10, so I don't see how it would be QEMU either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
