Created attachment 371174 [details] [review]
x264enc: Make sure sinkpad caps are never renegotiated

This is not supported and we should NNE if upstream is not able to
handle that restriction.

This currently leads to totally broken behavior where the library
fails and we send EOS downstream without even posting an ERROR.

In bytestream mode this should work just fine, or not? And in avc mode as long as downstream supports it. qtmux could support it but does not, matroskamux can't support it, for others I don't know.

You would basically have to drain and then recreate the encoder.

I like your idea of returning fixed caps to indicate the re-negotiation is not supported. but x264enc should likely supports this. So I'd say, leave this bug open if you decide to merge the disablement.

I indeed am exaggerating the fact that x264enc *can't* renegotiate at all :-)

This works just fine for instance:

    export TMPSCENARIO=$(mktemp)
    echo 'set-property, playback-time=1.0, target-element-name=capsfilter, property-name=caps, property-value=(GstCaps)"video/x-raw,width=16,height=16"' > $TMPSCENARIO
    GST_VALIDATE_SCENARIO=$TMPSCENARIO gst-validate-1.0 videotestsrc num-buffers=60 ! capsfilter name=capsfilter caps=video/x-raw,width=640,height=460 ! videoconvert ! x264enc tune=zerolatency ! decodebin ! autovideosink /test.scenario


(Encode and decode + playback a testsrc at 640x460 for 1 sec then change it to 16x16)


There still is a negotiation issue in the x264enc (and in encoders in general) as I can see totally broken behaviors rendering simple GES timeline (without forcing the incoming video format). I will try to provide scenarios to reproduce outside of it and we should work toward fixing it at the root in each encoder, so I am not closing this bug.

For now I have the impression my best bet is to follow this approach instead: https://bugzilla.gnome.org/show_bug.cgi?id=795464 as it is less controversial and fix my issue just as well.

Changing the caps is also an important behaviour for adaption for video calls, so this bug should be able any bug in this behaviour in x264 that you can reproduce.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/issues/19.