Created attachment 357364 [details] [review]
vpxenc: negotiate once, from handle_frame.

Review of attachment 357364 [details] [review]:

Why do you need to move that code to handle_frame?

::: ext/vpx/gstvpxenc.c
@@ +1881,3 @@
+    gst_video_codec_state_unref (output_state);
+
+    vpx_enc_class->set_stream_info (encoder, caps, &encoder->input_state->info);

encoder->negotiated = gst_video_encoder_negotiate (GST_VIDEO_ENCODER (encoder)); ?

(In reply to Thibault Saunier from comment #2)
> Review of attachment 357364 [details] [review] [review]:
> 
> Why do you need to move that code to handle_frame?
> 

I don't think it's really necessary, to be honest I just looked at theoraenc, which I knew didn't exhibit the issue, and emulated its negotiation mechanism.

Created attachment 357374 [details] [review]
vpxenc: negotiate once, from handle_frame.

Negotiating the output format whenever set_format was called
was causing not negotiated errors in gst-validate tests:

https://ci.gstreamer.net/job/GStreamer-master-meson-validate/1498/#showFailuresLink

Why was it causing not-negotiated errors and why was set_format() called multiple times? That seems to be the real problem here :)

(In reply to Sebastian Dröge (slomo) from comment #5)
> Why was it causing not-negotiated errors and why was set_format() called
> multiple times? That seems to be the real problem here :)

Valid questions, I'll look into a definite explanation later today, the pipeline that allows reproducing this is pretty large and dynamic so the exact chain of events isn't yet entirely clear to me

The issue I had was actually caused by https://bugzilla.gnome.org/show_bug.cgi?id=786172 . set_format was called multiple times because upstream was led into thinking that it could pick whatever colorimetry / chroma-site it wanted, even though there was a capsfilter downstream with its video caps fully specified (encodebin->outfilter).

Closing as NOTABUG.