177409 – [GStreamer][MSE] gstreamer critical warning in gst_buffer_pool_acquire_buffer()

Alicia Boya García

Reported 2017-09-23 11:29:43 PDT

How to reproduce: 1. Merge the webm patch https://bugs.webkit.org/show_bug.cgi?id=177355 2. Load the following page: http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?tests=56&command=run After the test completes (passing), a GStreamer warning is printed. http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: Media Source and Encrypted Media Conformance Tests (version 20170922171024-vKiynwyVqklah7cE) http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: Test 56:AppendVP9Video STARTED with timeout 30000 http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: checkEq passed: Source buffer number is (1). http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: checkEq passed: Range start is (0). http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: checkApproxEq passed: Range end is (0.999777). http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: Test 56:AppendVP9Video PASSED. http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: New longest test AppendVP9Video with timeout 30000 takes 1239 (WebKitWebProcess:23826): GStreamer-CRITICAL **: gst_buffer_pool_acquire_buffer: assertion 'GST_IS_BUFFER_POOL (pool)' failed http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: Longest test is AppendVP9Video, it takes 0.0413 of its timeout. http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/js/harness/main-20170922171024.js:123:16: CONSOLE LOG TestExecutor: All tests are completed This is the backtrace, captured by setting a breakpoint in `g_log()`: #0 g_log () at /webkit/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gmessages.c:1394 #1 0x00007fffe27e3c5f in gst_buffer_pool_acquire_buffer () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstbufferpool.c:1251 #2 0x00007fffe1e9649b in gst_video_decoder_allocate_output_frame () at /webkit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.10.5/gst-libs/gst/video/gstvideodecoder.c:3987 #3 0x00007fff4ccf262f in gst_vpx_dec_handle_frame () at /webkit/WebKitBuild/DependenciesGTK/Source/gst-plugins-good-1.10.5/ext/vpx/gstvpxdec.c:712 #4 0x00007fffe1e8be6e in gst_video_decoder_decode_frame () at /webkit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.10.5/gst-libs/gst/video/gstvideodecoder.c:3389 #5 0x00007fffe1e8e7d8 in gst_video_decoder_chain_forward () at /webkit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.10.5/gst-libs/gst/video/gstvideodecoder.c:2131 #6 0x00007fffe1e8ee53 in gst_video_decoder_chain () at /webkit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.10.5/gst-libs/gst/video/gstvideodecoder.c:2443 #7 0x00007fffe2814567 in gst_pad_chain_data_unchecked () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4202 #8 gst_pad_push_data () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4454 #9 0x00007fffe281c483 in gst_pad_push () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4573 #10 0x00007fffe2814567 in gst_pad_chain_data_unchecked () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4202 #11 gst_pad_push_data () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4454 #12 0x00007fffe281c483 in gst_pad_push () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4573 #13 0x00007fffe28043eb in gst_proxy_pad_chain_default () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstghostpad.c:126 #14 0x00007fffe2814567 in gst_pad_chain_data_unchecked () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4202 #15 gst_pad_push_data () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4454 #16 0x00007fffe281c483 in gst_pad_push () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4573 #17 0x00007fffe28043eb in gst_proxy_pad_chain_default () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstghostpad.c:126 #18 0x00007fffe2814567 in gst_pad_chain_data_unchecked () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4202 #19 gst_pad_push_data () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4454 #20 0x00007fffe281c483 in gst_pad_push () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gstpad.c:4573 #21 0x00007fffe2b04775 in gst_base_src_loop () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/libs/gst/base/gstbasesrc.c:2854 #22 0x00007fffe2847249 in gst_task_func () at /webkit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.10.5/gst/gsttask.c:334 #23 0x00007fffe03fe100 in g_thread_pool_thread_proxy () at /webkit/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gthreadpool.c:307 #24 0x00007fffe03fd775 in g_thread_proxy () at /webkit/WebKitBuild/DependenciesGTK/Source/glib-2.52.1/glib/gthread.c:784 #25 0x00007fffdca2836d in start_thread (arg=0x7fff4d6ff700) at pthread_create.c:456 #26 0x00007fffdb670bbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 `pool` variable is null, but it's not clear where it got that value from.

Alicia Boya García

Comment 1 2018-01-19 14:21:59 PST

I got this crash again and looked at it. At first it seemed very strange: why would the VP9 decoder have not initialized a buffer pool? After looking at the gst log though, it all came clear: this critical happend just after destroying MediaPlayerPrivateGStreamerMSE. At that point no streaming threads should be running. There is a race condition somewhere in the deinitialization code of the MSE player. MediaSource::setReadyState(0x7fff5b8f8d20) : open -> closed MediaSource::removeSourceBuffer() 0x7fff5b8f8d20 0:03:17.235106404 10336 0x4b4b00 DEBUG webkitmse MediaSourceClientGStreamerMSE.cpp:99:abort: MediaSourceClientGStreamerMSE::abort 0:03:17.235231234 10336 0x4b4b00 DEBUG webkitmse AppendPipeline.cpp:215:deinitialize:0x7fff7c0881e0 Deinitializating AppendPipeline (0x7fff7c0881e0) 0:03:17.235243074 10336 0x4b4b00 TRACE webkitmse AppendPipeline.cpp:221:deinitialize:0x7fff7c0881e0 Setting AppendPipeline to GST_STATE_NULL (0x7fff7c0881e0) 0:03:17.235266926 10336 0x4b4b00 DEBUG basesink gstbasesink.c:5153:gst_base_sink_change_state:<appsink84> PLAYING to PAUSED 0:03:17.235272506 10336 0x4b4b00 DEBUG basesink gstbasesink.c:5162:gst_base_sink_change_state:<appsink84> got preroll lock 0:03:17.235275895 10336 0x4b4b00 DEBUG basesink gstbasesink.c:3341:gst_base_sink_needs_preroll:<appsink84> have_preroll: 0, EOS: 0 => needs preroll: 1 0:03:17.235281909 10336 0x4b4b00 DEBUG basesink gstbasesink.c:5184:gst_base_sink_change_state:<appsink84> PLAYING to PAUSED, we are not prerolled 0:03:17.235285351 10336 0x4b4b00 DEBUG basesink gstbasesink.c:5198:gst_base_sink_change_state:<appsink84> rendered: 36, dropped: 0 0:03:17.235327006 10336 0x4b4b00 DEBUG basesink gstbasesink.c:4159:gst_base_sink_set_flushing:<appsink84> flushing out data thread, need preroll to TRUE 0:03:17.235345164 10336 0x4b4b00 TRACE webkitmse AppendPipeline.cpp:1046:appsinkCapsChanged:0x7fff7c0881e0 appsink-caps-changed message posted to bus 0:03:17.235353821 10336 0x4b4b00 DEBUG basesink gstbasesink.c:994:gst_base_sink_set_last_buffer_unlocked:<appsink84> setting last buffer to (nil) 0:03:17.235755204 10336 0x4b4b00 DEBUG webkitmse AppendPipeline.cpp:987:disconnectDemuxerSrcPadFromAppsinkFromAnyThread:0x7fff7c0881e0 Disconnecting appsink 0:03:17.236144897 10336 0x4b4b00 DEBUG webkitmse PlaybackPipeline.cpp:153:removeSourceBuffer:<source> Element removed from MediaSource 0:03:17.236260974 10336 0x4b4b00 DEBUG webkitmse AppendPipeline.cpp:215:deinitialize:0x7fff7c0881e0 Deinitializating AppendPipeline (0x7fff7c0881e0) 0:03:17.236269171 10336 0x4b4b00 TRACE webkitmse AppendPipeline.cpp:208:~AppendPipeline:0x7fff7c0881e0 Destroying AppendPipeline (0x7fff7c0881e0) MediaSource::removeSourceBuffer() 0x7fff5b8f8d20 0:03:17.236334569 10336 0x4b4b00 DEBUG webkitmse AppendPipeline.cpp:215:deinitialize:0x7fff7c0882d0 Deinitializating AppendPipeline (0x7fff7c0882d0) 0:03:17.236341392 10336 0x4b4b00 TRACE webkitmse AppendPipeline.cpp:221:deinitialize:0x7fff7c0882d0 Setting AppendPipeline to GST_STATE_NULL (0x7fff7c0882d0) 0:03:17.236474009 10336 0x4b4b00 DEBUG webkitmse PlaybackPipeline.cpp:153:removeSourceBuffer:<source> Element removed from MediaSource 0:03:17.236485041 10336 0x4b4b00 DEBUG webkitmse AppendPipeline.cpp:215:deinitialize:0x7fff7c0882d0 Deinitializating AppendPipeline (0x7fff7c0882d0) 0:03:17.236490246 10336 0x4b4b00 TRACE webkitmse AppendPipeline.cpp:208:~AppendPipeline:0x7fff7c0882d0 Destroying AppendPipeline (0x7fff7c0882d0) 0:03:17.236533703 10336 0x4b4b00 TRACE webkitmse MediaPlayerPrivateGStreamerMSE.cpp:119:~MediaPlayerPrivateGStreamerMSE: destroying the player (0x7fff8c58f040) 0:03:17.236545856 10336 0x4b4b00 DEBUG webkitmse PlaybackPipeline.cpp:97:setWebKitMediaSrc: webKitMediaSrc=(nil) (WebKitWebProcess:10336): GStreamer-CRITICAL **: gst_buffer_pool_acquire_buffer: assertion 'GST_IS_BUFFER_POOL (pool)' failed

Alicia Boya García

Comment 2 2018-11-28 06:11:55 PST

Despite the initial logs, this bug is more easily reproduced by just running 58. TimestampOffsetVP9Video. The assertion error happens just after the test finishes. Reproducible 100% of the time.

Michael Catanzaro

Comment 3 2019-01-20 12:02:06 PST

imported/w3c/web-platform-tests/media-source/mediasource-changetype.html is regularly crashing on this. I'm adding an expectation; please remove it when fixed.

Philippe Normand

Comment 4 2023-01-05 09:14:10 PST

> 2. Load the following page: http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?tests=56&command=run That's a dead end, I see some XML error message: <Error> <Code>NoSuchKey</Code> <Message>The specified key does not exist.</Message> <Details> No such object: yt-dash-mse-test/unit-tests/2018.html </Details> </Error>

Enrique Ocaña

Comment 5 2023-01-05 10:09:37 PST

The YouTube MSE tests 2018 aren't online anymore. You "might" have some chance of reproducing a similar problem (I haven't tried it myself) on the equivalend test ("62. TimestampOffsetVP9Video") on YT MSE 2019 tests, which are still online: https://ytlr-cert.appspot.com/2019/main.html

Philippe Normand

Comment 6 2023-01-05 10:42:02 PST

(In reply to Alicia Boya García from comment #2) > Despite the initial logs, this bug is more easily reproduced by just running > 58. TimestampOffsetVP9Video. The assertion error happens just after the test > finishes. Reproducible 100% of the time. Test "62. TimestampOffsetVP9Video" of the YT MSE 2019 tests is passing here. (In reply to Michael Catanzaro from comment #3) > imported/w3c/web-platform-tests/media-source/mediasource-changetype.html is > regularly crashing on this. I'm adding an expectation; please remove it when > fixed. This is now flagged as a failure/crash, see https://bugs.webkit.org/show_bug.cgi?id=167108

Michael Catanzaro

Comment 7 2024-09-23 12:09:45 PDT

We received a complaint about this here: https://discourse.gnome.org/t/gnome-web-epiphany-crashes/23455

Philippe Normand

Comment 8 2024-09-24 01:31:00 PDT

(In reply to Michael Catanzaro from comment #7) > We received a complaint about this here: > https://discourse.gnome.org/t/gnome-web-epiphany-crashes/23455 That remains to be confirmed.

John Scott

Comment 9 2024-10-01 20:41:09 PDT

(In reply to Philippe Normand from comment #8) > (In reply to Michael Catanzaro from comment #7) > > We received a complaint about this here: > > https://discourse.gnome.org/t/gnome-web-epiphany-crashes/23455 > > That remains to be confirmed. Hello! I'm a Debian Maintainer using unstable ("sid") who is able to reproduce this. In fact, I found that user's complaint on GNOME Discourse after searching around with my logs. The situation is basically identical: I get the same warnings from Mesa/Vulkan with Intel HD Graphics and reproduce this most often with Facebook, but sometimes with other sites using JavaScript and media extensively. I don't maintain Epiphany (or any relevant packages for that matter) in Debian, but do help with GNOME issues sometimes. If I'm able to get a nice stack trace or other juicy details I'll send those here.

Michael Catanzaro

Comment 10 2025-05-13 11:17:51 PDT

I've just hit this crash twice, on two of these three pages: https://www.msnbc.com/top-stories/latest/alabama-redistricting-congress-voting-rights-rcna206366 https://www.msnbc.com/rachel-maddow-show/maddowblog/librarian-congress-fired-trump-newsletter-rcna206534 https://www.msnbc.com/top-stories/latest/pope-leo-free-speech-free-press-rcna206342 (One of the other pages was an unrelated crash. Not sure which.)

Philippe Normand

Comment 11 2025-06-25 06:54:42 PDT

I had a look at this today, the warning happens because the video decoder fails to negotiate the buffer pool with downstream. The allocation query fails, because the decoder src pad peer is in flushing state. I don't know yet why... And this is a racy behavior... :/

Philippe Normand

Comment 12 2025-06-25 07:45:00 PDT

The flush happens due to some MSE re-enqueue in the SourceBuffer...

Alicia Boya García

Comment 13 2025-06-25 11:53:08 PDT

For better or worse, flushes before the pre-roll completes are a normal thing in MSE. GStreamer elements should be able to handle them, but you can imagine how many of them have bugs under such edge cases.

Philippe Normand

Comment 14 2025-07-21 04:59:01 PDT

Updated bt, triggered by scrolling on instagram timeline with auto-playing videos. (gdb) bt #0 _g_log_abort (breakpoint=<optimized out>) at ../glib/gmessages.c:431 #1 g_logv (log_domain=0x7f5f42288138 "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7f5c537fcd10) at ../glib/gmessages.c:1287 #2 0x00007f5f456f1803 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1329 #3 0x00007f5f422e10db in gst_buffer_pool_acquire_buffer (pool=0x0, buffer=0x7f5ca80a4370, params=0x0) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/gst/gstbufferpool.c:1248 #4 0x00007f5f420a3d4e in gst_video_decoder_allocate_output_frame_with_params (decoder=0x7f5ca809d600, frame=0x7f5ca80a4330, params=0x0) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:4729 #5 0x00007f5f420a3a04 in gst_video_decoder_allocate_output_frame (decoder=0x7f5ca809d600, frame=0x7f5ca80a4330) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:4666 #6 0x00007f5e08068c3c in gst_va_base_dec_prepare_output_frame (base=0x7f5ca809d600, frame=0x7f5ca80a4330) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-bad/sys/va/gstvabasedec.c:1123 #7 0x00007f5e08088b7d in gst_va_h264_dec_new_picture (decoder=0x7f5ca809d600, frame=0x7f5ca80a4330, picture=0x7f5ca80aca30) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-bad/sys/va/gstvah264dec.c:486 #8 0x00007f5e62f0266e in gst_h264_decoder_parse_slice (self=0x7f5ca809d600, nalu=0x7f5ca805cc60) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-bad/gst-libs/gst/codecs/gsth264decoder.c:1323 #9 0x00007f5e62f028a2 in gst_h264_decoder_decode_nal (self=0x7f5ca809d600, nalu=0x7f5ca805cc60) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-bad/gst-libs/gst/codecs/gsth264decoder.c:1372 #10 0x00007f5e62f00075 in gst_h264_decoder_handle_frame (decoder=0x7f5ca809d600, frame=0x7f5ca80a4330) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-bad/gst-libs/gst/codecs/gsth264decoder.c:578 #11 0x00007f5f420a1d81 in gst_video_decoder_decode_frame (decoder=0x7f5ca809d600, frame=0x7f5ca80a4330) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:4006 #12 0x00007f5f4209957e in gst_video_decoder_chain_forward (decoder=0x7f5ca809d600, buf=0x7f5cd0073290, at_eos=0) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:2480 #13 0x00007f5f4209b736 in gst_video_decoder_chain (pad=0x7f5ca805c220, parent=0x7f5ca809d600, buf=0x7f5cd0073290) at ../../local-projects/subprojects/gstreamer-full/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:2822 #14 0x00007f5f4233af14 in gst_pad_chain_data_unchecked (pad=0x7f5ca805c220, type=4112, data=0x7f5cd0073290) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/gst/gstpad.c:4555 #15 0x00007f5f4233c0d0 in gst_pad_push_data (pad=0x7f5cd00cfb00, type=4112, data=0x7f5cd0073290) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/gst/gstpad.c:4848 #16 0x00007f5f4233c81a in gst_pad_push (pad=0x7f5cd00cfb00, buffer=0x7f5cd0073290) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/gst/gstpad.c:4967 #17 0x00007f5e180cc307 in gst_single_queue_push_one (mq=0x7f5e0c0bc080, sq=0x7f5cd0049e70, object=0x7f5cd0073290, allow_drop=0x7f5c537fd57c) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2014 #18 0x00007f5e180cde6e in gst_multi_queue_loop (pad=0x7f5cd00cfb00) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2349 #19 0x00007f5f42382213 in gst_task_func (task=0x7f5cd00ea7e0) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/gst/gsttask.c:399 #20 0x00007f5f423835d4 in default_func (tdata=0x7f5cd00d02b0, pool=0x22726c00) at ../../local-projects/subprojects/gstreamer-full/subprojects/gstreamer/gst/gsttaskpool.c:70 #21 0x00007f5f45722a42 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:336 #22 0x00007f5f45721862 in g_thread_proxy (data=0x7f5ec0004d10) at ../glib/gthread.c:893 #23 0x00007f5f429911d4 in start_thread (arg=<optimized out>) at pthread_create.c:448 #24 0x00007f5f42a13cec in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Philippe Normand

Comment 15 2025-07-21 07:01:37 PDT

Some notes... 1. decoder receives flush-start before any pool negotiation happened (so priv->pool is NULL in gstvideodecoder) 2. vabasedec src_query triggered by a caps query coming from downstream 3. caps negotiation triggered on src pad (not sure how yet) 4. as caps are valid, gst_video_decoder_negotiate_default() calls gst_pad_set_caps() on the src pad, which pushes the caps event downstream, and fails 5. gst_video_decoder_negotiate_default() returns FALSE due to gst_pad_set_caps() failure, so gst_video_decoder_negotiate_pool() isn't called 6. since negotiation fails, gst_va_base_dec_prepare_output_frame() returns GST_FLOW_NOT_NEGOTIATED and gst_video_decoder_allocate_output_frame() isn't called 7. still no buffer pool negotiated 8. decoder receives flush-stop, resets, receives and forwards segment and tags 9. decoder receives a buffer (gst_video_decoder_chain() is called) 10. decoder attempts decoding 11. decoder attempts to allocate an output frame and fails (since there's no buffer pool). I'll attach the compressed log, the faulty decoder is vah264dec20...

Philippe Normand

Comment 16 2025-07-21 07:04:31 PDT

Created attachment 476134 [details] log

Philippe Normand

Comment 17 2025-07-25 04:07:29 PDT

So the decoder receives its first buffer and then before it had a chance to negotiate the pool with downstream, a flush-start is received from upstream... and then while flushing, negotiation is attempted and fails...

Philippe Normand

Comment 18 2025-07-29 03:49:12 PDT

This turned out to be a gstva-specific bug, at least here. MR: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457 Is anyone able to reproduce this issue with the non-vaapi decoders?

Philippe Normand

Comment 19 2025-07-30 01:31:13 PDT

(In reply to Michael Catanzaro from comment #10) > I've just hit this crash twice, on two of these three pages: > > https://www.msnbc.com/top-stories/latest/alabama-redistricting-congress- > voting-rights-rcna206366 > https://www.msnbc.com/rachel-maddow-show/maddowblog/librarian-congress-fired- > trump-newsletter-rcna206534 > https://www.msnbc.com/top-stories/latest/pope-leo-free-speech-free-press- > rcna206342 > > (One of the other pages was an unrelated crash. Not sure which.) First one works here (vah264dec is used for playback). The other two trigger an assert, see https://bugs.webkit.org/show_bug.cgi?id=296683

Philippe Normand

Comment 20 2025-08-10 08:13:52 PDT

No response so I guess let's assume this is fixed. Closing :)

Attachments
log (879.50 KB, application/x-bzip2) 2025-07-21 07:04 PDT, Philippe Normand	no flags	Details
View All Add attachment proposed patch, testcase, etc.