Obscure error messages

Nicolas Dufresne nicolas at ndufresne.ca
Sat Jan 7 15:30:53 UTC 2023


Le mer. 4 janv. 2023, 06 h 01, James Linder via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> a écrit :

>
>
> > On 4 Jan 2023, at 3:54 pm, James Linder via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> wrote:
> >
> >
> >
> >> On 4 Jan 2023, at 1:52 pm, James via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> wrote:
> >>
> >>
> >>
> >>> On 4 Jan 2023, at 7:29 am, Nicolas Dufresne via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> wrote:
> >>>
> >>> Any chance you could share a trace with env GST_DEBUG="*v4l*:7,2" ?
> >>>
> >>> Le mar. 3 janv. 2023, 10 h 46, James via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> a écrit :
> >>> I'm avoiding any reference to the rude rant a few days back.
> >>>
> >>> I tried/tested lots before writing code which has worked somewhere
> (ubuntu 22.04 with gst 18 that stutters audio, SUSE tumbleweed gst
> 20..latest.)
> >>>
> >>> All parcelled up and " Failed to allocate required memory" reared it's
> ugly head.
> >>>
> >>> Either branch runs perfectly on it's own, starting the other fails.
> >>> I run one channel from my code. Take one of my tests
> >>>
> >>> dvr at dvrTW:~> cat gst.try55
> >>> gst-launch-1.0 -v v4l2src device=/dev/video2 !
> image/jpeg,framerate=30/1 \
> >>>        ! jpegdec ! \
> >>>       videoconvert ! \
> >>> queue max-size-buffers=0 max-size-bytes=0 max-size-time=1000000000 ! \
> >>> gdkpixbufoverlay location=rennisons.png alpha=0.5 offset-x=1800
> offset-y=900 ! \
> >>> clockoverlay halignment=left valignment=top draw-outline=true
> font-desc="Sans, 12" time-format="%d %b %Y %H:%M:%S" ! \
> >>> textoverlay text="This is Line 1"               deltay=50
> halignment=left valignment=top font-desc="Sans, 10"      draw-outline=true
> ! \
> >>> textoverlay text="Line 2"               deltay=100 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay text="Look it works" deltax=50 deltay=150 halignment=left
> valignment=top font-desc="Cantarell Oblique Medium 20" draw-outline=true ! \
> >>> textoverlay                             deltay=200 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay text="Line 5"               deltay=250 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay                             deltay=300 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay                             deltay=350 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay                             deltay=400 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay text="Why"                  deltay=450 halignment=left
> valignment=top font-desc="Sans, 10"              draw-outline=true ! \
> >>> textoverlay text="Line 10"              deltay=500 halignment=left
> valignment=top font-desc="AdobeTimes Bold 10"    draw-outline=true ! \
> >>>       tee name=t \
> >>>        t. ! queue ! xvimagesink sync=false \
> >>>       t. ! queue ! \
> >>>        x264enc speed-preset=ultrafast tune=zerolatency
> byte-stream=true bitrate=4000 ! \
> >>>        mpegtsmux name=mux ! \
> >>>        filesink location='try55.mp4'
> >>>
> >>>
> >>> and run it
> >>>
> >>> dvr at dvrTW:~> ./gst.try55
> >>> Setting pipeline to PAUSED ...
> >>> Pipeline is live and does not need PREROLL ...
> >>> Pipeline is PREROLLED ...
> >>> Setting pipeline to PLAYING ...
> >>> New clock: GstSystemClock
> >>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps =
> image/jpeg, framerate=(fraction)30/1, width=(int)1920, height=(int)1080,
> pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
> colorimetry=(string)2:4:5:1
> >>> /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps =
> image/jpeg, framerate=(fraction)30/1, width=(int)1920, height=(int)1080,
> pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
> colorimetry=(string)2:4:5:1
> >>> /GstPipeline:pipeline0/GstJpegDec:jpegdec0.GstPad:sink: caps =
> image/jpeg, framerate=(fraction)30/1, width=(int)1920, height=(int)1080,
> pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
> colorimetry=(string)2:4:5:1
> >>> /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps =
> image/jpeg, framerate=(fraction)30/1, width=(int)1920, height=(int)1080,
> pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
> colorimetry=(string)2:4:5:1
> >>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
> to allocate required memory.
> >>> Additional debug info:
> >>> ../sys/v4l2/gstv4l2src.c(777): gst_v4l2src_decide_allocation ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> >>> Buffer pool activation failed
> >>> Execution ended after 0:00:00.005402443
> >>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Internal data stream error.
> >>> Setting pipeline to NULL ...
> >>> Additional debug info:
> >>> ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> >>> streaming stopped, reason not-negotiated (-4)
> >>> Freeing pipeline ...
> >>>
> >>> Can anybody point me in a direction that solves it please.
> >>>
> >>> I emphasize that somewhere during testing I had 4 channels all
> running, every channel runs it's own copy of gstreamer and AFAICT each copy
> is totally independant. We *must* be looking at some resource
> >>> This is running on i7x4 and htop shows 50% cpu and memory used.
> >>>
> >>> The messing around with jpeg was a suggestion from Nicolas. Each
> capture card is USB3 in a USB3 port, but the system treated them as USB2
> and limited resolution (1280x800 IIRC instead of 1080P)
> >>>
> >>> If it was still a lack of bandwidth, UVC driver should be messaging
> you through dmesg.
> >>
> >> I'll revert and look but the crux is solved!
> >>
> >> The jpeg fiddle was your suggestion to get 1080 on a usb-3 port. The
> error message was caused by having 2 capture cards on (a hub) a single
> usb-3 port even though that is quite legal (in terms of bandwidth).
> >> I will also try 2 cards on a usb-c.
> >> Then to find the culprit gstreamer or UVC driver.
> >>
> >> My m2 adapter is S-L-O-W but on a standard flash disk I can hold
> 500Mb/s on the usb-3 port.
> >> Someone pretends the usb-3 is a usb-2: who?
> >>
> >
> > How do I discover who, does gstreamer ever talk to dmesg?
> >
> > …
> > [16587.796310] usb 3-2.4.4: Found UVC 1.00 device USB Video (534d:2109)
> > [16587.798893] hid-generic 0003:534D:2109.0009: hiddev98,hidraw6: USB
> HID v1.10 Device [MACROSILICON USB Video] on usb-0000:00:14.0-2.4.4/input4
> > [16813.673158] usb 3-2.4.3: Not enough bandwidth for new device state.
> > [16813.673165] usb 3-2.4.3: Not enough bandwidth for altsetting 3
>
> A five year old kernel bug
>
> I know! I know! But still “dmesg saying Not enough bandwidth” would be
> much more enlightning than "Failed to allocate required memory”
>


It's lack of time from all of us, but it should be easy to introduce a
specific error code for this in V4L2 spec, and the implement it in
GStreamer and UVC driver. For now, I think GStreamer is simply not aware of
the difference between lack of bandwidth vs lack of memory. There is a
great plane to move out the logic from the gst pool activation too, as that
would help a lot not confusing allocation from streamon failures, but it
will only work well after Linux has been improved. Time is a decisive
factor for all of this refinement.

Nicolas

p.s. I volunteer my free time to support folks on this ML


> James
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230107/4c993f62/attachment.htm>


More information about the gstreamer-devel mailing list