[wpe-2.46] [MSE] GStreamer stream error when EOS without buffers pushed

[filipe-norte-red]

When the End of Stream is signaled before buffers are pushed to the pipeline, the gstreamer pipeline may occasionally throw the following error:

0:00:00.603703707 207 0xf7b520 ERROR webkitcommon GStreamerCommon.cpp:878:operator(): Got message: error message: 0xa9a2aa78, time 99:99:99.999999999, seq-num 302, element 'inner-parser', GstMessageError, gerror=(GError)NULL, debug=(string)"../gst-plugins-base-1.18.5/gst/playback/gstparsebin.c(3495):\ gst_parse_bin_expose\ ():\ /GstPlayBin3:MSE-media-player-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin1/WebKitMediaThunderParser:webkitmediathunderparser1/GstParseBin:inner-parser:\012all\ streams\ without\ buffers";

which leads to the general "GStreamer encountered a general stream error" message. The wpe-2.46 code contains the fix added in wpe-2.38 for this issue, but it still occurs intermittently.

The eos-no-buffer-append.zip file contains a test that reproduces this issue (you may need to run the test a few times to reproduce it)

This happens with gstreamer 1.18.

[emutavchi]

@eocanha could you please take a look?

[eocanha]

I've submitted a fix upstream as https://bugs.webkit.org/show_bug.cgi?id=278726 (reopened) / WebKit/WebKit#51211. The issue was that there was a race condition in which the pipeline error (to be ignored) happened on a different thread while the main thread was ignoring errors, but that error took a bit to propagate as a GstMessage. When the message was handled by handleMessage() it was too late, since we had already stopped ignoring errors.

The solution was to use a delayed block of code to stop ignoring errors. On top of that, when an error has happened, now we call didEnd(), to trigger the same reaction that would happen if a real EOS message had been emitted by the pipeline.

[eocanha]

The fix has landed upstream as WebKit/WebKit@b1ff591 and has been backported to wpe-2.46 as 8774900. Closing issue.