-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Property intra-refresh-type
set to cyclic
or both
#22
Comments
Both cyclic and both are working OK for me. Have you tried rpi-update and a reboot? |
Any update for me? |
Sorry, missed your previous comment. I’m using Archlinux ARM on Rpi B 2. Firmware is
Will rebuild gst-rpicam from make distclean now. Dunno if that’s gonna make a difference. |
Rebuilt the module. Even with simple pipeline it errors out with same error.
|
Your test pipeline above failed for me this morning too. While I was trying to strip it down to compare against the pipeline that worked before, it suddenly started working. Now the full pipeline works again. I think the initialisation is racy. I'll try and see if it's in gst-rpicamsrc, or if it's a race inside the DSP init. The latter seems likely, since it's linked to intra-refresh-cyclic - which is just another property as far as gst-rpicamsrc is concerned. Try running this and see if it ever eventually works for you: while true; do gst-launch-1.0 rpicamsrc bitrate=5000000 inline-headers=true intra-refresh-type=cyclic-rows metering-mode=matrix annotation-mode=0x00000300 preview=false ! 'video/x-h264,profile=baseline,width=1024,height=768,framerate=30/1' ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink host=10.0.0.9 port=9000 sync=false async=true; done |
Well, I ran your loop with This is on Rpi 2. Could it be a multi-core/threading issue? |
Ah, oops - I pasted the wrong line. Yes - I'm testing on an RPi1 - so not an RPi2 specific issue. I wonder if it's an uninitialised-memory use issue - if it happens to be zero or so it works. I can't install valgrind (seems to be a raspbian repo issue) without compiling it first to see if there's an uninited access anywhere in userspace. |
Aha. That’s why I was trying the other one. Because this one didn’t seem to have any effect.
Arch has valgrind. Do you want me to run something and paste the output?
|
Oh, yes please - G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-resolution=high --leak-check=yes --num-callers=20 --alignment=16 gst-launch-1.0 rpicamsrc intra-refresh-type=both num-buffers=5 ! fakesink might do the trick. |
It’s sitting there spinning CPU3. Gotto go to garden center to buy some plants. Will update if it finishes by the time I get back.
|
Thanks for that. I don't see anything obvious in there, although there's clearly a lot of incompletely initialised memory usage inside mmal and friends. I did just notice that if I turn on some GStreamer debug levels, I can make it work reliably. Either debug level slow things down enough that it seems to init reliably, or it changes the memory around in some way. Even when not printing anything, just skipping ignored internal debug lines is enough: GST_DEBUG=identity:6 gst-launch-1.0 rpicamsrc intra-refresh-type=both num-buffers=5 ! fakesink works reliably, where gst-launch-1.0 rpicamsrc intra-refresh-type=both num-buffers=5 ! fakesink doesn't. It's also interesting that I can reproduce it reliably now, where I couldn't when you first reported the bug. I wonder if something in the firmware changed. |
Just came home, it was still spinning the CPU. When I canceled it printed this
|
From my PoV you don’t need to dive too deep into this, if it takes too much time. I merely wanted to try these flags to see if they help with live streaming error resilience and/or latency. |
if you could test with GST_DEBUG=identity:5 and see if that makes it work for you too, that'd be cool |
On Mon, Apr 20, 2015 at 6:15 PM, Jan Schmidt notifications@github.com
Yes, prepending that, it works. Funny. |
I think I found it - that commit makes it work for me. Please re-open if it's still broken for you. |
Can confirm. Thank you very much. |
Use memset on the stack allocated MMAL_PARAMETER_VIDEO_INTRA_REFRESH_T struct. Apparently mmal_port_parameter_get() doesn't retrieve all parameters, causing random failures when we set the intra-refresh param on the encoder. Fixes thaytan/gst-rpicamsrc#22 for me.
Use memset on the stack allocated MMAL_PARAMETER_VIDEO_INTRA_REFRESH_T struct. Apparently mmal_port_parameter_get() doesn't retrieve all parameters, causing random failures when we set the intra-refresh param on the encoder. Fixes thaytan/gst-rpicamsrc#22 for me.
I’m kinda sure this worked before. But now when I set
intra-refresh-type=cyclic
orintra-refresh-type=both
it bombs out.The text was updated successfully, but these errors were encountered: