[Bug 785011] Sometime between 1.10.4 and 1.12.0 MKV video decode broke when mapping buffers to get pixel data

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=785011

--- Comment #4 from Carsten Haitzler (Rasterman) <raster at rasterman.com> ---
no special allocation of buffers. it's what playbin decides. we just get the
show_frame calls and then ref the gst buffer, send to mainloop to apply to
canvas. the map doesn't fail... so since we don't specially allocate the
memory... it should just keep working as long as buffers are mappable.

the memory the sink gets is forwarded by handle right to the mainloop that then
forwards pointers to that memory to the canvas... and we keep the buffer mapped
as long as the canvas is pointing to this memory. the canvas uses the same
convert/texture upload functions and code regardless of gst version... so
downgrade gst... then it works. so i see correctly decoded data at that point
on screen with 1.10.4 and garbage with 1.12.0

indeed i don't think it's related to matroska. it is just a container format -
as i mentioned in the original. :) it is something deeper, but oddly both mp4
and mkv files use the same size, stride, plane offsets and yuv format ... so
it's something specific to the decoder that is ending up being run with the mkv
as opposed to the mp4. the mkv's have been working for years... until some time
between 1.10.4 and 1.12.0 of gst. could it be that the decoder is re-using the
buffer even though we keep it mapped and filling it with junk before we have a
chance to upload? i haven't checked the buffer at show_Frame time specifically
... i'd have to write myself a little saver and decoder to something i can more
easily see... haven't done that yet.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.