I tried implementing it, but it was not trivial as expected as some elements (parsers, muxers) use the codec_data in their setcaps negotiation, so the whole thing can be quite entangled, etc. So implementing it in these elements requires understanding what exactly is going on. And since from the CAPS you can't know if there will be a stream-config event, it means that you have to wait until the first buffer to process the whole thing and possibly fail. Maybe the stream-config should instead be stashed in the GStructure of the CAPS event instead of being a separate event, something like gst_event_caps_set/parse_codec_data().


And in the current API (only having a codec_data buffers, etc), I'm not sure what the benefit is exactly. My use-case was to put profile-level-id in both caps (negotiated) and in the stream-config (declarative), but that requires putting arbitrary things in the GStructure in the event.

commit 00c6fa74f5a0364ad67ddf15301f1d4d73fdad7a
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Tue Sep 11 16:29:12 2012 +0200

    events: remove STREAM_CONFIG
    
    We won't be able to implement this so it's better to move it out of the way.

Thanks! Does it make sense to keep this bug around? It's not really something that we can change with the 1.0 API, is it? Unless we just add it in addition to the in-caps stuff, though I don't know what that would improve.