GNOME Bugzilla – Bug 680091
[0.11] dvbsuboverlay: mangles video timestamps (?), crash on composition unref
Last modified: 2012-07-19 12:40:29 UTC
file: 104857600 Feb 21 2011 /home/tpm/bbcnews.m2t md5sum: 2c47cd5de9793fcc6a894a17d4385886 $ gst-launch-1.0 playbin uri=file:///home/tpm/bbcnews.m2t Shows the dvb subtitles, but subtitles themselves "flicker", and it's like frames always jump back and forth a second. After ca. 47 seconds, it tends to crash, with a GSlice error unrefing an overlay composition. When playing in totem (with deinterlacing enabled via avdeinterlace), the picture and subtitles are smooth, no flickering or jumping back and forth, but still a crash after a while. File can be made available on request.
The flickering / back-and-forth can be reproduced with http://people.freedesktop.org/~tpm/samples/bbcnews2.m2t , not the crash though (but perhaps valgrind shows something).
Created attachment 219066 [details] [review] dvbsuboverlay test patch Not clear what is happening yet, but the following is so far: * timestamps seem to come out fine * no problem in 0.10 * also no problem in a hand-crafted overlay pipeline in 1.0 * the attached patch to dvbsuboverlay essentially disables all (overlay) processing and replaces this with some busy loop, which happens to also reproduce the described playback All in all, very likely this has little to do with dvbsuboverlay or timestamp mangling, but something else happening (in the pipeline) to the buffers as they are kept mapped for some time (as illustrated by this patch).
Created attachment 219122 [details] [review] tests: gstbuffer: extend buffer copy test Looks like we may still be having some problems in coming up with really independent buffer copies and that that is biting here. In particular, adding some debug shows that dvbsuboverlay (occasionally) gets incoming buffers whose object_lock state is 0x20103, which means it is owned/locked EXCLUSIVELY twice but ended up mapped writable (possibly twice). So 2 buffers can still end up playing around with the same memory. Reading code suggests this can indeed happen in the sequence: * locking EXCLUSIVE some fresh memory * mapping it WRITE * then making a buffer copy, adding another EXCLUSIVE lock * mapping it WRITE again Attached patch extends the unit test to illustrate/test this.
I think with the fixes in core this can be closed now. Thanks for tracking this down! The GSlice abort is fixed by: commit ed8504e5906f9420999dc02b31d18e0be47ea557 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Thu Jul 19 13:33:22 2012 +0100 video-overlay-composition: fix GSlice alloc/free size mismatch Fix copy'n'paste bug which made us allocate a slice of the size of a rectangle for the overlay composition, but then free it passing the size of an overlay composition, which is not something GSlice takes to kindly, resulting in scary aborts like: ***MEMORY-ERROR***: GSlice: assertion failed: sinfo->n_allocated > 0 Also, g_slice_new already includes a cast, so remove our own casts, without which the compiler would probably have told us about this ages ago. https://bugzilla.gnome.org/show_bug.cgi?id=680091