Thanks for the clarification and the link to the docs. I understand now it’s normal for some pads not to have caps until they’re activated and that current caps / caps property are different from the allowed caps. In any case, I can verify it’s not hanging at the link stage, rather at requesting the pad, so I am pretty sure it’s not related at this point.
The C gets generated in …/build/src/nvalhalla@exe/
To view app specific g_debug messages, set G_MESSAGES_DEBUG=all
Example launch to replicate issue is in the readme (requires pip3 install youtube-dl). I don’t have enough good rtsp sources to stress test with, but you might. That’s why I’m testing with youtube direct video uris.
We don’t see the rectangle mask on human faces. Seems like detection is not running, is this normal or we miss something?
Following https://github.com/mdegans/nvalhalla/tree/dev#requirements steps and run multiple youtube streams.
Thanks!
Aha. That’s the behavior from the master branch, before I added the redaction bin. Sorry I wasn’t clear. The instructions for building the dev branch has one extra step (in bold):
git clone https://github.com/mdegans/nvalhalla.git
cd nvalhalla
<b>git checkout dev</b>
mkdir build
cd build
meson ..
ninja
sudo ninja install
Hi,
Looks like it sets batch-size for multiple times:
// this needs to be updated on pad added or flickering occurs with the osd
debug(@"setting muxer batch-size to $(self._muxer.numsinkpads + 1)")
self._muxer.set_property("batch-size", self._muxer.numsinkpads + 1)
In deepstream-test3, it is configured one time only, after all sources are created. Please modify it to run as test3 and see if it helps.
Thanks. DaneLLL. I was trying to increment batch size in the playing state to match the number of connected sources. I noticed after looking closely at some pdfs that while the properties were set on the elements sucessfully, the stream itself still had batch-size of 1. I will try to set the batch size the same way it’s set in deepstream test 3 and see if that fixes it.
So, setting the “async-handling” property on my uridecodebin sources stopped the issue from re-occuring:
src.set_property("async-handling", true)
It was an accident while I was fixing some other things. I am not convinced the problem is entirely gone, but it’s probably much less likely to happen now since the pads are now being created at wildly different times (I can’t replicate, despite trying many times).
I did try setting “batch-size” in the constructor and everything reports a batch-size of 4, however the osd seems to not be drawing on the right frames:
If I had to guess, i’d say the source ids are somehow getting mixed up. Not sure what’s up with that exactly. Here is a branch with the flickering issue if you are interested in taking a look. I will probably start a new thread for it if I can’t figure out the cause since it appears to be a separate issue. Attached is a pdf of the flickering pipeline.
Anyway. Thank you, DaneLLL and carolyuu for helping me troubleshoot! One problem down, at least one to go. 0.00.56.182628798-pipeline0.quit.pdf (50.8 KB)
So, It ended up the flickering was definately caused by the position of the osd element. It worked with batch size set to 1, but anything above that, the source ids would get mixed up (i assume). If anybody runs into it, attached is a working pipeline pdf compared with the above. The osd works fine when placed after the tiler, and I would assume is more effecient that way. 0.00.34.610304446-pipeline0.quit.pdf (50.6 KB)
