This commit introduced a deadlock:

commit c91928f7a2461aba57f64e014f507bcb62d7adc6
Author: Edward Hervey <edward.hervey@collabora.co.uk>
Date:   Mon Jul 25 10:41:04 2011 +0200

    decodebin2: Properly handle multi-stream chains
    
    When we have a multi-stream (i.e. audio and video) input and the demuxer
    adds/removes pads for a new stream (common in a mpeg-ts stream when the
    program stream mapping is updated), the algorithm for EOS handling was
    previously wrong (it would only drop the EOS of the *last* pad but would
    let the EOS on the other pads go through).
    
    The logic has only been changed a tiny bit for EOS handling resulting in:
    * If there is no next group, let the EOS go through
    * If there is a next group, but not all pads are drained in the active
      group, drop the EOS event
    * If there is a next group and all pads are drained, then the ghostpads
      will be removed and the EOS event will be dropped automatically.

All I need to reproduce the deadlock is this <video> test case:

<video src="svt2-44100Hz.ogv" controls></video>
<script>
var v = document.querySelector('video');
v.onsuspend = function() {
  v.currentTime = v.duration;
};
v.preload = "auto";
</script>

What this does is to simply seek to the end of the file once it is has stopped loading. Seeking to somewhere other than the end does not reproduce the issue. You need an Ogg file with both audio and video to reproduce and it helps if it's fairly small. It will deadlock when leaving the page, as Opera is stuck in a gst_element_get_state call that never returns. Full backtrace:

+ Trace 227878