GNOME Bugzilla – Bug 681642
basesink: drops or duplicates buffers when dumping oggdemux output
Last modified: 2018-11-03 12:15:54 UTC
So ... no idea if this is in fact a basesink issue, but here goes: when dumping oggdemux buffers to stdout in gst-launch with queue ! fakesink silent=false, it seems that (a) not all buffers are shown and, (b) sometimes buffers are shown multiple times. Not 100% sure what the trigger is, at first I thought it was queue related, but seems not. Reproduce with: $ for i in `seq 1 5`; do gst-launch-1.0 filesrc location=video.ogg ! oggdemux name=d d. ! queue ! fakesink async=false silent=false d. ! queue ! fakesink async=false silent=false -v 2>&1 | grep chain | grep 'offset_end: -1' ; echo =========; done Each iteration should show 6 header buffers, 3 for the vorbis stream and 3 for the theora stream. There should be 4 small packets and 2 larger packets. $ for i in `seq 1 5`; do gst-launch-1.0 filesrc location=video.ogg ! oggdemux name=d d. ! queue ! fakesink silent=false d. ! queue ! fakesink silent=false -v 2>&1 | grep chain | grep 'offset_end: -1' ; echo =========; done chain fakesink1 30 bytes flags: 00000040 discont ) 0x7f67bc0079d0 chain fakesink1 30 bytes flags: 00000040 discont ) 0x7f67bc0079d0 chain fakesink1 30 bytes flags: 00000040 discont ) 0x7f67bc0079d0 chain fakesink1 30 bytes flags: 00000040 discont ) 0x7f67bc0079d0 ========= chain fakesink1 30 bytes flags: 00000040 discont ) 0x16e8a10 chain fakesink1 95 bytes flags: 00000000 ) 0x16e8b20 chain fakesink1 3484 bytes flags: 00000000 ) 0x16e8c30 chain fakesink0 97 bytes flags: 00000000 ) 0x16e87f0 chain fakesink0 97 bytes flags: 00000000 ) 0x16e87f0 chain fakesink0 97 bytes flags: 00000000 ) 0x16e87f0 ========= chain fakesink0 42 bytes flags: 00000040 discont ) 0xc206e0 chain fakesink0 42 bytes flags: 00000040 discont ) 0xc206e0 chain fakesink0 42 bytes flags: 00000040 discont ) 0xc206e0 chain fakesink0 42 bytes flags: 00000040 discont ) 0xc206e0 ========= chain fakesink0 42 bytes flags: 00000040 discont ) 0x1f8c6a0 chain fakesink0 42 bytes flags: 00000040 discont ) 0x1f8c6a0 chain fakesink0 42 bytes flags: 00000040 discont ) 0x1f8c6a0 chain fakesink0 42 bytes flags: 00000040 discont ) 0x1f8c6a0 chain fakesink0 42 bytes flags: 00000040 discont ) 0x1f8c6a0 chain fakesink0 42 bytes flags: 00000040 discont ) 0x1f8c6a0 ========= chain fakesink1 30 bytes flags: 00000040 discont ) 0x172da10 chain fakesink1 30 bytes flags: 00000040 discont ) 0x172da10 chain fakesink1 30 bytes flags: 00000040 discont ) 0x172da10 =========
I have seen this too and traced it back to racyness in getting the message property of the fakesink.
I debugged and let me to the same as Wim. g_object_notify is async. I guess the fakesink prints are relevant to debugging, I'd propose: 1) Add a signal to fakesink 'new-message', this would be sync. 'new-last-message' is weird because new and last doesn't make sense on the same sentence, but new-message can be confusing as there is also GstMessage on the gstreamer context. This allows applications to integrate this into their debugging needs in a sync manner. 2) Add an extra property to fakesink to make it print directly to stdout to allow gst-launch to have sync output of those messages. Or make it handle fakesink case specially to handle the last-message signal, but then it could be mixed with the default _notify handling and we would have even more duplicated outputs.
g_object_notify() actually is sync unless there's freezing/thawing of that happening between multiple threads (don't do that!). The problem is that multiple threads are changing last-message, so once you got the notify::last-message in your callback, last-message might've changed by another thread already before you get the message. Solution for that really would be only a new signal that includes the message itself. Not sure how important that is
I can't reproduce this any longer, so let's close it.
*** Bug 750454 has been marked as a duplicate of this bug. ***
To preproduce reliably. gst-launch-1.0 -v videotestsrc ! tee name=t t. ! queue ! fakesink silent=0 t. ! queue ! fakesink silent=0
Related to deep-notify it seems (but it could just be generally dispatch of property changes from two threads on the same object): commit 0c80c41ade1e3a12ec8218cdffd0392edb881c5c Author: Tim-Philipp Müller <tim@centricular.com> Date: Fri Jun 5 19:35:29 2015 +0100 tests: fakesink: test notify::last-message and deep-notify::last-message deep-notify::last-message seems to cause some problems, so disable for now. https://bugzilla.gnome.org/show_bug.cgi?id=681642
Automated removal of (bad) usage of the "NONE" target milestone.
-- 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/gstreamer/issues/28.