GNOME Bugzilla – Bug 776091
omx - in error state at end of video (before EOS)
Last modified: 2018-11-03 14:01:54 UTC
Created attachment 341953 [details] [review] Deallocate texture in FLUSH_START I've been playing a video, just before it gets to the end it freezes and I get the output below. For now I haven't managed to make some minimal code to reproduce it yet, so just wondering it is known - similar to the OMX bug mentioned earier ? https://lists.freedesktop.org/archives/gstreamer-devel/2016-December/061931.html 0:01:32.395974718 7472 0x2364200 ERROR omx gstomx.c:1955:gst_omx_port_wait_buffers_released_unlocked:<omxh264dec-omxh264dec0> Timeout waiting for egl_render port 221 to release all buffers 0:01:32.396736066 7472 0x2364200 WARN omxvideodec gstomxvideodec.c:1620:gst_omx_video_dec_loop:<omxh264dec-omxh264dec0> error: Unable to reconfigure output port 0:01:32.398866620 7472 0x224f480 ERROR omx gstomx.c:836:gst_omx_component_set_state:<omxh264dec-omxh264dec0> Last operation returned an error. Setting last_error manually. 0:01:32.398946516 7472 0x224f480 ERROR omx gstomx.c:845:gst_omx_component_set_state:<omxh264dec-omxh264dec0> Error setting egl_render state from 4 to 3: Insufficient resources (0x80001000) 0:01:32.399041984 7472 0x224f480 ERROR omx gstomx.c:872:gst_omx_component_get_state:<omxh264dec-omxh264dec0> Component egl_render in error state: Insufficient resources (0x80001000) 0:01:32.399663280 7472 0x224f480 ERROR omx gstomx.c:1467:gst_omx_port_set_flushing:<omxh264dec-omxh264dec0> Component egl_render is in error state: Insufficient resources (0x80001000) 0:01:32.400010725 7472 0x224f480 ERROR omx gstomx.c:1467:gst_omx_port_set_flushing:<omxh264dec-omxh264dec0> Component egl_render is in error state: Insufficient resources (0x80001000) 0:01:32.400604053 7472 0x224f480 WARN omxvideodec gstomxvideodec.c:2146:gst_omx_video_dec_flush:<omxh264dec-omxh264dec0> Failed to populate output port: Incorrect state operation (0x80001018) 0:01:32.402515808 7472 0x2364200 ERROR omx gstomx.c:1257:gst_omx_port_acquire_buffer:<omxh264dec-omxh264dec0> Component egl_render is in error state: Insufficient resources 0:01:32.403512778 7472 0x2364200 WARN omxvideodec gstomxvideodec.c:1527:gst_omx_video_dec_loop:<omxh264dec-omxh264dec0> error: OpenMAX component in error state None (0x00000000) El viernes, 9 de diciembre de 2016 13:41:18 (CET) Stuart Axon escribió: > I'm pretty sure I'm using the one from gst-plugins-bad (I'm using gstreamer > master, last built about 3 days ago). But not 100% sure, is there a way to > tell ? If you're using master, then you're using gst-plugins-bad almost for sure. Anyway, it doesn't really mind, as none of the two versions seem to listen to the FLUSH_START event. > So maybe I could mitigate this by manually calling drain() if in the error > state or hook into the FLUSH_START? My suggestion would be to focus on FLUSH_START instead of reacting in the error state. In my experience, when "Insufficient resources" happens, it's too late to revert to a working state again. So, what I would do would be to touch gst_glimage_sink_event()[1], adding a case for FLUSH_START. There you could do the same as the DRAIN query does[2] (copy-paste or refactor into a common function called from both places). Make sure that you don't return inside the case, so the code flow continues and ends up calling to the ancestor class method to process the event[3]. That last part is important for the right operation of the element. > I haven't seen the error in dispmanx-gst-play, however, my player is a bit > more complex - I update the play state (seek, or try and change file) in > gobject timer, from data I get on the network. S++ I haven't looked in deep how dispmanx-gst-play works, so I can't give an opinion about why things work there. Maybe a different sink is used (one which doesn't hold EGL buffers for itself on flush), I don't know. Another think I forgot: check that your Raspberry has enough graphics memory configured. Assuming you're using raspbian: sudo raspi-config, advanced options, memory split. Use some higher value such as 128. In any case, I hope the suggestions help you to fix the issue. :-) Cheers. [1] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/ gstglimagesink.c?id=1.10.2#n1023 [2] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/ gstglimagesink.c?id=1.10.2#n1118 [3] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/ gstglimagesink.c?id=1.10.2#n1069 -- Enrique Ocaña González _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel Free forum by Nabble Disable Popup Ads | Edit this page
Bikesheddy stuff - I called it dealloc_texture, but I don't know enough about the codebase to know if that is correct. C is not my usual language, so I probably made some mistakes. Does it work ? It helps - the same error happens, but much later. Before the patch, I can play one video and freeze every time. After the patch I can play a video, and then show a png, quite a few times (needs more testing) before hitting the resource error.
OK, pretty sure this works. Other problems I was having seem unrelated (was trying to her RGB pngs L, and that seems to not work) One thing that may be related: To change the location on my filesrc I have to set the pipeline state to NULL causing a flash of black, if I use READY then it doesn't work.
Under what circumstances do you need this? How recent is your RPi userland? kernel? what distribution? Do you have a test case for this problem?
Distro is Raspbian Jessie $ cat /proc/version Linux version 4.4.21-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #911 SMP Thu Sep 15 14:22:38 BST 2016 $ /opt/vc/bin/vcgencmd version Sep 21 2016 13:13:29 Copyright (c) 2012 Broadcom version 2eaf52cc53435b5ce67253af1487f9a4f9f96e2d (clean) (release) Python is 3.5 Gstreamer is gst-uninstalled, built from master - but with the patch on this issue. I'm building a video wall. Users can choose videos or images. Images + videos are downloaded and the pi continually plays a playlist of files it has downloaded. The pis play the videos at the same time, with one pi controlling the others ("play this video", "seek to this time") sort of thing. The screens are small (480x800) ... so instead of using videocrop (which doesn't seem to have hardware acceleration on pis, I'm creating a larger than screen window and moving it - videos we've tested seem to play ok. Short version: I'm aiming for continual playback of a set of images and videos without any user interaction on the pi side. @Enrique's patch seems to fix things when playing a test video, but I need to try with images, as I saw a similar looking message when testing images earlier. I'll try and come up with a small testcase.
*** Bug 776166 has been marked as a duplicate of this bug. ***
I had another play, the patch helps - but you need to set the pipeline state to NULL to change files, as opposed to READY. The code here is a small testcase: https://github.com/stuaxo/gstreamer-dispmanx-demo Code that advances to next file: https://github.com/stuaxo/gstreamer-dispmanx-demo/blob/master/player-multi.py#L102 On a PC on Linux it can iterate through files, by setting pipeline state to READY $ python play-multi.py files.. On a RPI, the screen goes black when attempting to move to the next file. With the patch applied to gst-plugins-bad/ext/gl/gstglimagesink.c it is possible to go to the next file, by setting the state to NULL (pass --use-null), though this means there is either a flash of black or whatever was showing in the background before the player started.
Created attachment 343389 [details] [review] Updated patch to not clear window_id.
Patch updated so that glimage_sink->window_id is not cleared when going from PAUSED to READY. This enables using going from PAUSED to READY with a custom window set with set_window_handle. Tested on Raspberry Pi, probably applies elsewhere, no idea about correctness.
Not clearing window_id is incorrect. However if that fixes your issue, that points to a bug lower in the stack (either in the dispmanx window implementation or in the firmware/userland). You'll have to figure our what exactly it doesn't like about destroying and creating dispmanx window's.
More likely a bug in my understanding of dispmanx + python ctypes or gstreamer :) It fixes my issue enough that I can play things gaplessly, but it unfixes things by seeming to introduce some sort of resource leak [1] (leaking windows?). It makes sense to me that gstreamer may destroy windows it creates, but was surprising that it destroyed one passed in from set_window_handle. I'd try switching to recreating the window each time, but I'm not sure where to do this, since prepare-window-handle only seems to fire once. Currently, I check for a state change from READY to PAUSED and resize my window there [2]. I tried changing this to create a new window and call set_window_handle, but that doesn't seem to work. [1] First items play fine, but eventually this happens (if testing with a video it happens much more quickly, after about the 5th): eglCreateImageKHR: failed to create image for buffer 0x1c target 12465 error 0x300c 0:00:25.641093891 1124 0x977c60 ERROR glbasememory gstglbasememory.c:94:_mem_create_gl: Failed to create GL buffer: Failed to create EGLImage 0:00:25.641261963 1124 0x9846f0 ERROR glbasememory gstglbasememory.c:168:gst_gl_base_memory_init: Could not create GL buffer with context:0x97c0c8 ** (python:1124): CRITICAL **: gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed eglCreateImageKHR: failed to create image for buffer 0x1d target 12465 error 0x300c 0:00:25.642280756 1124 0x977c60 ERROR glbasememory gstglbasememory.c:94:_mem_create_gl: Failed to create GL buffer: Failed to create EGLImage 0:00:25.642371745 1124 0x9846f0 ERROR glbasememory gstglbasememory.c:168:gst_gl_base_memory_init: Could not create GL buffer with context:0x97c0c8 [2] - ### After gst pipeline has been created, setup state change callback def on_state_change(bus, msg): if msg.src != self.sink: return old, new, pending = msg.parse_state_changed() if (old, new) == (Gst.State.READY, Gst.State.PAUSED): # Code to resize window here pass self.bus.connect('message::state-changed', on_state_change) ### later on, when receiving command to play new video/image: def play_next_location(self, next_location): self.pipeline.set_state(Gst.State.READY) self.src.set_property("location", next_location) self.pipeline.set_state(Gst.State.PLAYING)
@ystreet00 I'm up for trying to find out more about how dispmanx behaves, but no idea where to get help + feedback with for the RPI userland though.
Review of attachment 341953 [details] [review]: This looks good. If you add a commit message to this, I can commit it :).
Created attachment 343623 [details] [review] Also deallocate texture in FLUSH_START This is the original patch (does not clear texture) with commit message added.
If this gets landed, I'd like to have a proper solution to be able have this work: filesrc->decodebin->glimagesink - set window handle - window size set during prepare window handle on eos: - set pipeline state to READY - set filesrc.location to new file - set pipeline state to PLAYING pipeline plays new content, using existing in window handle Any idea where I would need to start, or if the premise is even correct ?
There is definitely a memory leak (or something very like it). I've modified my slideshow example to check the memory before trying to play the next file with: $ vcdbg reloc | grep free Starting the big buck bunny clip repeatedly, the relocatable memory runs down until Gstreamer cannot allocate any more memory - $ python slideshow.py --delay=1000 --repeat=10 --enable-bcm /opt/vc/src/hello_pi/hello_video/test.h264 free list at 0x3dbfffe0 204M free memory in 17 free block(s) largest free block is 109M bytes 0x2f240000: free 109M 0x36aecee0: free 15M 0x37a4c7c0: free 61M 0x3b7d9d20: free 3.1M 0x3c709800: free 27K 0x3c710760: free 15M 0x3d690000: free 24K 0x3d796620: free 224 0x3dbf1ec0: free 32 0x3dbffde0: free 544 slideshow.py: play /opt/vc/src/hello_pi/hello_video/test.h264 #0 free list at 0x3dbf1ec0 109M free memory in 8 free block(s) largest free block is 108M bytes 0x2f240000: free 108M 0x36aecee0: free 743K 0x37a4c7c0: free 76K 0x3c709800: free 27K 0x3c710760: free 40K 0x3d573720: free 17K 0x3d68e2e0: free 5.0K 0x3dbf1ec0: free 32 slideshow.py: play /opt/vc/src/hello_pi/hello_video/test.h264 #1 free list at 0x3dbf1ec0 55M free memory in 8 free block(s) largest free block is 54M bytes 0x2f240000: free 54M 0x36aecee0: free 743K 0x36cbd600: free 146K 0x37a4c7c0: free 12K 0x3c709800: free 3.7K 0x3c710760: free 224 0x3d68e2e0: free 32 0x3dbf1ec0: free 32 slideshow.py: play /opt/vc/src/hello_pi/hello_video/test.h264 #2 free list at 0x3dbf1ec0 55M free memory in 8 free block(s) largest free block is 54M bytes 0x2f240000: free 54M 0x36aecee0: free 743K 0x36cbd600: free 146K 0x37a4c7c0: free 12K 0x3c709800: free 3.7K 0x3c710760: free 224 0x3d68e2e0: free 32 0x3dbf1ec0: free 32 slideshow.py: play /opt/vc/src/hello_pi/hello_video/test.h264 #3 free list at 0x3dbf1ec0 2.0M free memory in 8 free block(s) largest free block is 1.2M bytes 0x2f240000: free 1.2M 0x36aecee0: free 743K 0x36cbd600: free 146K 0x37a4c7c0: free 12K 0x3c709800: free 1.3K 0x3c710760: free 224 0x3d68e2e0: free 32 0x3dbf1ec0: free 32 slideshow.py: play /opt/vc/src/hello_pi/hello_video/test.h264 #4 eglCreateImageKHR: failed to create image for buffer 0x16 target 12465 error 0x300c 0:00:05.081096559 3854 0x556cc0 ERROR glbasememory gstglbasememory.c:94:_mem_create_gl: Failed to create GL buffer: Failed to create EGLImage 0:00:05.081374265 3854 0x71401c00 ERROR glbasememory gstglbasememory.c:168:gst_gl_base_memory_init: Could not create GL buffer with context:0x5640c8 ** (python:3854): CRITICAL **: gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed eglCreateImageKHR: failed to create image for buffer 0x17 target 12465 error 0x300c 0:00:05.082734878 3854 0x556cc0 ERROR glbasememory gstglbasememory.c:94:_mem_create_gl: Failed to create GL buffer: Failed to create EGLImage 0:00:05.082874252 3854 0x71401c00 ERROR glbasememory gstglbasememory.c:168:gst_gl_base_memory_init: Could not create GL buffer with context:0x5640c8 ** (python:3854): CRITICAL **: gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed eglCreateImageKHR: failed to create image for buffer 0x18 target 12465 error 0x300c 0:00:05.083950129 3854 0x556cc0 ERROR glbasememory gstglbasememory.c:94:_mem_create_gl: Failed to create GL buffer: Failed to create EGLImage 0:00:05.084057367 3854 0x71401c00 ERROR glbasememory gstglbasememory.c:168:gst_gl_base_memory_init: Could not create GL buffer with context:0x5640c8 ** (python:3854): CRITICAL **: gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed 0:00:05.086943489 3854 0x71401c00 ERROR omx gstomx.c:1682:gst_omx_port_allocate_buffers_unlocked:<omxh264dec-omxh264dec4> Failed to allocate buffer for egl_render port 221: Incorrect state operation (0x80001018) 0:00:05.088915503 3854 0x71401c00 ERROR omx gstomx.c:836:gst_omx_component_set_state:<omxh264dec-omxh264dec4> Last operation returned an error. Setting last_error manually. 0:00:05.088987950 3854 0x71401c00 ERROR omx gstomx.c:845:gst_omx_component_set_state:<omxh264dec-omxh264dec4> Error setting egl_render state from 2 to 1: Insufficient resources (0x80001000) 0:00:05.089822214 3854 0x71401c00 ERROR omx gstomx.c:1167:gst_omx_close_tunnel:<omxh264dec-omxh264dec4> Failed to close tunnel on input side Incorrect state operation (0x80001018) 0:00:05.089907943 3854 0x71401c00 ERROR omx gstomx.c:872:gst_omx_component_get_state:<omxh264dec-omxh264dec4> Component egl_render in error state: Insufficient resources (0x80001000) 0:00:05.285348944 3854 0x71401c00 ERROR omx gstomx.c:1682:gst_omx_port_allocate_buffers_unlocked:<omxh264dec-omxh264dec4> Failed to allocate buffer for video_decode port 131: Insufficient resources (0x80001000) 0:00:05.286817473 3854 0x71401c00 ERROR omxvideodec gstomxvideodec.c:794:gst_omx_video_dec_allocate_output_buffers:<omxh264dec-omxh264dec4> Failed to allocate required number of buffers 4, trying less and copying 0:00:05.286908722 3854 0x71401c00 ERROR omx gstomx.c:1874:gst_omx_port_set_enabled_unlocked:<omxh264dec-omxh264dec4> video_decode port 131 enabled/disabled pending already (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ ): CRITICAL **: gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed bash: syntax error near unexpected token `)' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.086943489 3854 0x71401c00 ERROR omx gstomx.c:1682:gst_omx_port_allocate_buffers_unlocked:<omxh264dec-omxh264dec4> Failed to allocate buffer for egl_render port 221: Incorrect state operation (0x80001018) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.088915503 3854 0x71401c00 ERROR omx gstomx.c:836:gst_omx_component_set_state:<omxh264dec-omxh264dec4> Last operation returned an error. Setting last_error manually. bash: omxh264dec-omxh264dec4: No such file or directory (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.088987950 3854 0x71401c00 ERROR omx gstomx.c:845:gst_omx_component_set_state:<omxh264dec-omxh264dec4> Error setting egl_render state from 2 to 1: Insufficient resources (0x80001000) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.089822214 3854 0x71401c00 ERROR omx gstomx.c:1167:gst_omx_close_tunnel:<omxh264dec-omxh264dec4> Failed to close tunnel on input side Incorrect state operation (0x80001018) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.089907943 3854 0x71401c00 ERROR omx gstomx.c:872:gst_omx_component_get_state:<omxh264dec-omxh264dec4> Component egl_render in error state: Insufficient resources (0x80001000) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.285348944 3854 0x71401c00 ERROR omx gstomx.c:1682:gst_omx_port_allocate_buffers_unlocked:<omxh264dec-omxh264dec4> Failed to allocate buffer for video_decode port 131: Insufficient resources (0x80001000) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.286817473 3854 0x71401c00 ERROR omxvideodec gstomxvideodec.c:794:gst_omx_video_dec_allocate_output_buffers:<omxh264dec-omxh264dec4> Failed to allocate required number of buffers 4, trying less and copying bash: omxh264dec-omxh264dec4: No such file or directory (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.286908722 3854 0x71401c00 ERROR omx gstomx.c:1874:gst_omx_port_set_enabled_unlocked:<omxh264dec-omxh264dec4> video_decode port 131 enabled/disabled pending already bash: omxh264dec-omxh264dec4: No such file or directory (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ ): CRITICAL **: gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed bash: syntax error near unexpected token `)' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.086943489 3854 0x71401c00 ERROR omx gstomx.c:1682:gst_omx_port_allocate_buffers_unlocked:<omxh264dec-omxh264dec4> Failed to allocate buffer for egl_render port 221: Incorrect state operation (0x80001018) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.088915503 3854 0x71401c00 ERROR omx gstomx.c:836:gst_omx_component_set_state:<omxh264dec-omxh264dec4> Last operation returned an error. Setting last_error manually. bash: omxh264dec-omxh264dec4: No such file or directory (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.088987950 3854 0x71401c00 ERROR omx gstomx.c:845:gst_omx_component_set_state:<omxh264dec-omxh264dec4> Error setting egl_render state from 2 to 1: Insufficient resources (0x80001000) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.089822214 3854 0x71401c00 ERROR omx gstomx.c:1167:gst_omx_close_tunnel:<omxh264dec-omxh264dec4> Failed to close tunnel on input side Incorrect state operation (0x80001018) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.089907943 3854 0x71401c00 ERROR omx gstomx.c:872:gst_omx_component_get_state:<omxh264dec-omxh264dec4> Component egl_render in error state: Insufficient resources (0x80001000) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.285348944 3854 0x71401c00 ERROR omx gstomx.c:1682:gst_omx_port_allocate_buffers_unlocked:<omxh264dec-omxh264dec4> Failed to allocate buffer for video_decode port 131: Insufficient resources (0x80001000) bash: syntax error near unexpected token `(' (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.286817473 3854 0x71401c00 ERROR omxvideodec gstomxvideodec.c:794:gst_omx_video_dec_allocate_output_buffers:<omxh264dec-omxh264dec4> Failed to allocate required number of buffers 4, trying less and copying bash: omxh264dec-omxh264dec4: No such file or directory (lumen_client) pi@raspberrypi:~/gstreamer-dispmanx-demo $ 0:00:05.286908722 3854 0x71401c00 ERROR omx gstomx.c:1874:gst_omx_port_set_enabled_unlocked:<omxh264dec-omxh264dec4> video_decode port 131 enabled/disabled pending already
(In reply to Stuart Axon from comment #11) > @ystreet00 I'm up for trying to find out more about how dispmanx behaves, > but no idea where to get help + feedback with for the RPI userland though. The best option would be something around the community at https://github.com/raspberrypi (In reply to Stuart Axon from comment #14) > I'd like to have a proper solution to be able have this work: > > filesrc->decodebin->glimagesink > > - set window handle > - window size set during prepare window handle > > on eos: > > - set pipeline state to READY > - set filesrc.location to new file > - set pipeline state to PLAYING > > pipeline plays new content, using existing in window handle > > Any idea where I would need to start, or if the premise is even correct ? That's exactly what's meant to happen. (In reply to Stuart Axon from comment #15) > There is definitely a memory leak (or something very like it). This seems to be intermittent. Sometimes with: GST_TRACERS=leaks GST_DEBUG=3,*TRACER*:7 gst-play-1.0 /path/to/file The gl bufferpool (and all associated objects aren't freed). However, with the linked slideshow.py script, everything is leaked (when modified to call Gst.deinit() in the appropriate places. I would suggest writing your example in C so you know exactly where and when your references are and are taken/given and so we can rule out reference issues with python/gobject-introspection/etc.
I'll see if I can find a really simple C example to modify as my C experience is almost non-existant.
Not sure if related but worth a try of some patches from https://git.collabora.com/cgit/raspberry-pi/gst-omx.git/log/?h=rpi-1.0.0.1 "omxvideodec: fix deadlock when flush on EOS" "omxvideodec: Do not try to acquire buffer when flushing" You might need also a few commits in between. Also could be related: https://bugzilla.gnome.org/show_bug.cgi?id=759043 https://bugzilla.gnome.org/show_bug.cgi?id=767499
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/496.