Gstreamer 1.4.5 and bcm2835-v4l2 don't get along #849
Comments
|
With Gst 1.2 I'm also seeing kernel errors and freezing of the Gstreamer pipeline: Last message from Gstreamer: |
|
Kernel warning, not error. Already logged as #817 Do you have a latest version of GStreamer? There was a bug with it when handling V4L2 devices https://bugzilla.gnome.org/show_bug.cgi?id=726521 I know gstreamer works as jamesh has been asking me questions about it today. |
|
Yes I'm using the gstreamer workaround. Also tried without the workaround. If you mean latest == 1.4.5 yes I'm using that version. Is Jamesh using 1.4.5 or master git? |
|
I'm using the standard one from the repo, not sure of the version. Running On 24 February 2015 at 18:54, Arnaud Loonstra notifications@github.com
|
|
That's version 1.2. It works for me as well although only for a while. See my comment about 1.2 which shows the logs. Using rpicamsrc is stable. |
|
Hmm, You could try dropping the bitrate, otherwise I haven't got many ideas. I'd need to have a look at changes in v4l2src if I can find the appropriate branch. |
|
Do you mean this branch? http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2?h=1.4 |
|
Btw, how does one set the bit rate on a v4l2src. I tried using v4l2-ctl --set-ctrl video_bitrate=100000 but that doesn't seem to work. |
|
Using up to date raspbian kernel: I get exactly the same problem as before, trying to use a simple v4l2src hangs the pipline at the same stage, with the same kernel entry: The raspberry and camera itself work absolutely fine, for example this pipeline works: It's requesting h-264 through v4l2src that hangs, no matter what caps or parameters I use. Kernel entry each time is: This seems to be a pretty major bug, or am I doing something really wrong? There are quite a few references on the interweb suggesting that lots of other people are doing this successfully. |
|
Tried updating to the 4.4 kernel with rpi-update, same problem: |
|
Just tried Insert H264 parse into the pipeline and things grind to a halt
I haven't studied the source, but what do you believe h264parse is doing for you? v4l2src should already be providing correctly framed H264 packets, so unlike fdsrc there is no need for it to be creating the correct framing. |
|
Load the V4L2 driver with extra debug enabled (sudo modprobe bcm2835-v4l2 debug=1) and I can see we get 3 buffers allocated. There are 4 callbacks with respective lengths of 26 (headers), 1820 (I-frame), 421 (P-frame), and 358 (P-frame) bytes. Only 1 buffer ever gets returned and refilled with the 358 byte frame. On ctrl-C'ing gst-launch I suddenly get 3 buffer-prepare/buffer_queue calls as the buffers finally get returned for filling with something new. |
|
If I try without h264parse I get errors: If I try use x-raw or image/jpeg cap and encode but otherwise the same pipeline then it sends the video correctly to the client: I thought I usually needed h264parse but seems not even after omxh264enc which is good. Interestingly if I pipe v4l2src x-h264 through mpegtsmux to a filesink then it seems to create a good file recording. |
|
h264parse is in gst-plugins-bad - there may be a reason for that. Sorry, but the issue doesn't appear to be in the Pi code unless you can produce some evidence as to why h264parse thinks the first IDR frame is invalid and doesn't apparently consume any more of the data (it has 2 more buffers sitting there waiting). |
|
gstreamer-omx depends on plugins-bad. If you try and connect v4l2src to just decodebin it tries to run it through h264parse and hangs. I'm afraid you've reached the limit of my abilities/knowledge here :) But as it stands the raspberrypi v4l2src is of limited use with gstreamer, would be great to fix it if possible. |
|
I didn't say that plugins-bad was inherently bad, but the reasoning behind the name from the GStreamer project (https://gstreamer.freedesktop.org/modules/gst-plugins-bad.html) is
At least we're not using plugins-ugly. No, I haven't looked into their code as to why it SIGSEGVs - as suggested running "gdb gst-launch-1.0 1620" (or whatever the PID changes to on next run). "thread apply all bt" should dump a backtrace of all threads. Always start with the most basic pipeline and build up. Start with one component and direct it into fakesink. Then two. Then three. etc. That way you can tell which bit is upset at what it has been presented. |
|
Thanks 6by9. Looks like the problem lies with the interaction between using v4l2src capturing h264 and rtph264pay together (which unfortunately is the only way to stream h264 with v4l2 without decoding). I suspect v4l2src is outputting a hokey packet somewhere that both h264parse and rtph264pay aren't very good at coping with (they both fail separately with v4l2src h264 output but work with x264 output) . Using raspivid and piping to the gstreamer fdsrc and through h264parse and rtph264pay is fine, and I've spent a couple of days compiling latest (1.90) gstreamer which works just fine. |
|
GST 1.90 works fine using v4l2src to h264parse or rtph264pay? Most likely it is trying to parse the headers and it doesn't like SPS and PPS being combined into one buffer, or some option in the headers is missing (there are lots of optional fields). Identifying exactly what causes the stall is the bigger task. Leave this as an issue here for now. It is really a GST issue as the stream is valid, but if we can make a stream that it is happier with then that's a kernel or firmware mod. |
|
@fnoop Could you confirm if there is still an issue with GST 1.90? Is there somewhere that I can download GST 1.8 or 1.9 for Pi to test? I did try building GST myself and gave up after wasting a fair chunk of time on it without success. I haven't got to the bottom of why GST 1.4 doesn't like the stream as yet. |
|
@6by9 It seems to work great with 1.9. It's in 'puppet' code so you'll have to extract the command logic yourself, but it should be reasonably straight forward. 1.9 seems to have deprecated h264parse so you go straight from the source to the pay. |
|
Thank you, and that is good news. It sounds like they may have moved the stream parsing logic (which is what h264parse was) into the sink component. That sounds a slightly quirky and possibly backwards step if you're trying to support filesrc from raspivid. |
|
@sphaero has this issue been resolved? If yes, please close this issue. Thanks. |
|
I have no idea. I have no RPI available currently. Perhaps anybody else can confirm? Otherwise I'll close the issue in a few days. |
|
I haven't made any changes to address the issue, but fnoop is reporting GST 1.9.0 as working fine (it drops h264parse as a component). Leave this open for now and if I find a few minutes to dig into h264parse then I will. Memory says it wasn't too pleasant when I looked last time. It may be as simple as throwing an extra couple of buffers into the mix, or GST may be wanting SPS and PPS headers separately. |
|
@6by9 Assign to you, or close? |
|
Assign to me. |
|
@6by9 Did you get a change to look at this? Any ideas what to do with this issue? |
|
No, and not really. It looked to be H264 header parsing, so potentially that we put SPS and PPS into one V4L2 buffer by themselves. I don't suppose you fancy running a quick test, or at least shouting if you have a standard Raspbian build available (mine are all customised in various ways at the moment). |
|
@JamesH65 Please close. This is a GStreamer bug in an old version of GStreamer. Current versions all seem happy. |
|
And as if by magic.... |
rust: bindgen: add `x86_msi_{data,addr_lo}` as opaque types
Using a fdsrc works but talking directly to it through v4l2src does nothing. Not a bit is send out through the network. It seems the pipeline doesn't flow.... Kernel errors at the bottom.
Using latest Raspbian (Linux 2.18.7+) and a compiled Gstreamer 1.4.5
This one works
This one doesn't
Just noticed some kernel errors as well:
Reverting back to the Raspbian provided Gstreamer 1.2 does work!
The text was updated successfully, but these errors were encountered: