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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Jul 17 06:43:11 UTC 2017


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

            Bug ID: 785011
           Summary: Sometime between 1.10.4 and 1.12.0 MKV video decode
                    broke when mapping buffers to get pixel data
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: don't know
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: raster at rasterman.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 355731
  --> https://bugzilla.gnome.org/attachment.cgi?id=355731&action=edit
tarball of log files of 1.10.4 vs 1.12.0

So I tracked it down as far as between 1.10.04 (worked) and 1.12.0 (doesn't
work) ... playback of my MKV files has the video all junk. like this:

http://www.enlightenment.org/ss/e-596c574b7ef3f0.39995477.png

it only seems to happen with MKV. MP4 files with the exact same YUV format
(GST_VIDEO_FORMAT_I420 + GST_VIDEO_COLOR_MATRIX_BT709) of the exact same
resolution are fine, but MKV are not. The plane offsets, stride values per
frame are the exact same between a working MP4 video source and non-working MKV
video source. I know MKV is just a container... but basically the metadata
(plane offsets, stride, video buffer format) are constant between 1.10.4 and
1.12.0. i've attached xz zipped tarball of logs for, 1.10.4 and 1.12.0 playing
the exact same file.

FYI - we have our own video sink. we map the gst buffers, then use offset and
stride values to supply yuv etc. data to a canvas buffer. the mapping succeeds.
the querying of metadata works. just the data in the buffer seems to be junk in
1.12 (or of a completely different layout/format) vs 1.10.4 even though all the
format/layout data is the same.

this is not using vaapi at all. no vdpau either.

FYI there is another bug with vaapi where the strides and plane offsets are
also wrong when vaapi is decoding. but that's a separate matter.

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


More information about the gstreamer-bugs mailing list