monoscope element fails caps re-negotiation with glimagesink
gst-launch-1.0 audiotestsrc ! monoscope ! glimagesink
stops after playing one frame on not-negotiated error.
When debugging the problem I noticed that the initial caps negotiation completes successfully and the pipeline goes to PLAYING.
-
monoscope.src
andgluploadelement.sink
settle onvideo/x-raw, format=(string)BGRx, width=(int)256, height=(int)128, framerate=(fraction)25/1
- From an allocation query,
monoscope
picks an instance ofGstGLBufferPool
for its buffer allocations - When the first buffer generated by
monoscope
gets passed togst_gl_upload_perform_with_buffer()
,gluploadelement
selects "GLMemory" upload method. - The first buffer gets uploaded and displayed.
Later on in gst_monoscope_chain()
monoscope
decides to renegotiate the caps and calls gst_monoscope_src_negotiate()
:
- caps query on the peer pad (
gluploadelement.sink
) now returns only a set ofvideo/x-raw(memory:GLMemory)
caps, based on previously selected "GLMemory" upload method. - However,
monoscope
supports only system memoryvideo/x-raw
caps on its srcpad, so there's an empty intersection between the pads' caps andmonoscope
returnsGST_FLOW_NOT_NEGOTIATED
.
So there's a discrepancy between the supported caps monoscope
advertises for its srcpad and the fact it's actually using GstGLBufferPool
obtained from an allocation query. I'm not sure what would be the best way to fix this issue.