Rare negotiation errors are happening between cefsrc and cefdemux

[pyldin601]

Sometimes pipeline fails to construct because of some strange caps negotiation error between cefsrc and cefdemux.

In our logs we see:

gstpad.c:3235:gst_pad_query_accept_caps_default
cefdemux_overlay:sink
caps: video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, format=(string)BGRA were not compatible with: video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, format=(string)BGRA, interlace-mode=(string)progressive

I have dug a bit into gstpad.c and seen that this happens because gst_caps_can_intersect (caps, allowed) or gst_caps_is_subset (caps, allowed) checks fail.

Unfortunately, I can't provide a simple reproduction case, because it's not reproducible in gst-launch1.0 and rarely happens only in our production.

[MathieuDuponchelle]

I'm not sure what those logs are supposed to show to be honest :)

In any case, did you manage to determine what allowed and caps were set to when the failure occurred ? Also, is it perhaps a case where for some reason cefsrc would have already pushed different caps before ? Not sure how this can happen, but you'll need to gather more info here I reckon.

[pyldin601]

I'll try to collect more info, but for now I'm curious what's wrong with the caps.

Caps was: video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, format=(string)BGRA

When allowed was: video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, format=(string)BGRA, interlace-mode=(string)progressive

The only difference I see is that there is interlace-mode in allowed.

[MathieuDuponchelle]

@pldin601 I'm sorry but you're going to have to post full logs here, the original extract you posted isn't necessarily indicative of an error, I don't doubt you're observing one but what you pasted is just debug-level logging, might not even be related to your actual issue (ie the negotiation error might not even be on that pad in the first place ..).

Closing until either useful logs have been provided, or a reproducing test case (or both really :))

Regarding the interlace-mode field, its absence in caps should be interpreted as progressive fwiw.