Fórum QT

Platform: Raspberry Pi 3B, Debian Trixie, Qt 5.15, GStreamer 1.24, Wayland compositor, v4l2h264dec Why we built a custom GStreamer item instead of using Qt Multimedia's Video element Before describing the transition problem itself, I want to explain why we're not using Qt Multimedia's Video QML element, since that's the obvious first question. Qt Multimedia's GStreamer backend does use v4l2h264dec — we confirmed this with GST_DEBUG=3. That's not the issue. The issue is what happens at EOS on this specific platform. On Pi3 / kernel 6.6, when GST_EVENT_EOS reaches the V4L2 sink, it triggers a known memory leak in the Pi's V4L2 driver at end-of-playback. For a digital signage player looping content 24/7, this CMA (Contiguous Memory Allocator) leak accumulates until V4L2 buffer allocation fails: v4l2h264dec: Failed to allocate output buffers — Cannot allocate memory The workaround is to intercept and drop GST_EVENT_EOS via a pad probe on the sink pad, before it reaches the driver. End-of-video is detected via GST_MESSAGE_EOS on the bus (which is still emitted normally). Qt Multimedia's Video element doesn't expose any hook to install a pad probe at this level. This is why we built GstVideoItemV2 , a custom QQuickItem that drives the pipeline directly with the raw GStreamer C API. Our pipeline: filesrc → qtdemux → h264parse → v4l2h264dec → queue → waylandsink ↑ pad probe: drop GST_EVENT_EOS Note on Qt6: migrating to Qt6 is not on our roadmap today, but if Qt6 Multimedia's GStreame

On the one hand you are saying that you have restricted the recursion depth to 14 levels, but on the other hand you are saying you have a stack overflow. This does not make sense unless you have really huge stack frames (any arrays on the stack?). Or your actual recursion depths is much deeper than 14 levels. It is quite likely that the stack overflow is the real problem and malloc doesn't have to do anything with it. For now, I would stop looking elsewhere. Setting a larger stack size certainly seems to help. Somebody mentioned that Linux stack size is 8MB, so you could even just go with 8MB (instead of 16MB) if your software works on Linux. However, this is not a permanent fix! Over time people will run larger and larger problems. You'll eventually run out of stack space on all operating systems, not just macOS. The best solution might be to rewrite your recursive algorithm with a loop. (This is technically also not a permanent solution, but the only restriction is not enough RAM and there is nothing you can do about it in software.)

@SimonSchroeder [Before we start: you might like to change what you have written either to swap the true/falses or change isPrime to isComposite :) ] The underlying issue here I am trying to examine is: the simplest way to write the algorithm is just to have a single loop running from 2 to limit, just as you have here. And have each division check done in some thread. Theoretically with 4 threads you get 4 times the speed. However, I presume that --- even if we allow the pre-creation of the 4 threads and re-use --- there is some overhead for running the division on a thread: something for setting up/starting off the division code and something for finishing/returning the result. Right? And that may be considerable, even larger than, the time taken to execute a single division in its body. That indicates to me that I need to write an algorithm which partitions the domain into 4 quarters and just gets each of 4 threads to do a loop over its 1/4th of the numbers, to minimize the thread start/end overheads. Now, it may be that your #pragma omp parallel for shared(limit,dividend,divisor,isPrime) does just that. I don't know because you have not said how it works. That would be a good start. But I am guessing that, even if it does so, it naively partitions the range into the lowest first quarter of numbers, the middle two quarters and the highest quarter, e.g. first quarter would run from 2 to 2 + limit / 4. This would be fine if the body were, say, counting the number of iteration

Decouple Hydra and Qt for independent rendering, share the VkDevice in a synchronized manner, and connect them using VkImage and GPU synchronization (timeline semaphores) instead of blocking the GUI on every frame.

Nice you found a solution. What were you using before Vulcan ?

Hi and welcome to devnet, Sounds like you have encountered the same situation as described in QTCREATORBUG-34905 which is fixed for 20.0.2. If you want you can use the snapshot. @ekkescorner confirmed it works.

Consider the order to be undefined, and something you shouldn't rely on. To be honest, that's the same as if you were to use qmlRegisterSingletonType using the imperative API; there's no instantiation at the point of the registration, that will happen later when the engine actually needs the singleton (and "needs" is intentionally vague here). If you have an order-dependent construction, you should (in that order of preferability) a) consider if you can move away from that pattern, or b) use https://doc-snapshots.qt.io/qt6-dev/qqmlengine.html#setExternalSingletonInstance once 6.12 is released or c) keep using imperative registration.

@Aidener I merged your answer with the original thread. Please keep things together.

@Christian-Ehrlicher Thanks, I will check that out

@DevMattew said in [MSVC/Qt6] Address Space Exhaustion during "Edit and Continue" after migrating from Qt3 to Qt6.8.3: I am not referring to a Qt-specific API or a framework feature. I am talking about the MSVC 'Edit and Continue' feature provided by the Visual Studio debugger. Ah, I see. I have no experience with this functionality, so I'll defer to those who do. If you don't get any clues here, try posting at the Interest mailing list where Qt engineers are active (you'll need to subscribe first): https://lists.qt-project.org/listinfo/interest

@Christian-Ehrlicher I tried to install a program Streamtuner-ng (can be found on github.com/IronWolve). I installed it according his instructions and requirements. It crashed on an illegal instruction. This program is written in python and uses PySide6. He required that PYSide6>=6.6. It installed 6.11 (I think) and apparently also installed qt libraries in a venv. In the end the program worked with PySide 6.9.3 (and thus Qt 6.9.3). Debian 13 uses apparently Qt 6.8.2. This all worries me because a next version of Debian (or an update) may not work at all on my old PC's. I completely accept that certain things go slow or do not run well on my PC's but I would like to be able to run a normal OS (like Debian).

Hi all, I'm using a Qt Creator 20.0.1, with Qt 6.11.2 MinGW 64-bit on Windows 11. Creating a new project following these steps: New Project -> Application (Qt) - > Qt Widgets Application -> Name: test -> Build system: CMake -> Details (no edit) -> Translation file (no edit) -> Kits (no edit) -> Summary: Finish. It creates a project that runs smoothly, but debugging causes a SIGSEGV. I didn't add any line of code on purpose, to make it reproducible: Does this happens to someone else? and how can it be fixed? Thanks in advance for your time