[Bug 744857] New: Some decoders need mp4's maximum sample size

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 744857
           Summary: Some decoders need mp4's maximum sample size
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: alfonso.sanchez-beato at canonical.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 297396
  --> https://bugzilla.gnome.org/attachment.cgi?id=297396&action=edit
Patch for qtdemux.c

HW decoders re-use input buffers and in some cases the size they use is too
small because they try to minimize the (physical)memory resources employed when
decoding. Therefore, some times it is needed to give them a good estimate of
the maximum sample size to avoid decoding errors that happen when the input
buffer size is smaller than the size of a sample.

This patch reads that information for iso mp4 containers, and complements the
patch in bug #737599 (https://bugzilla.gnome.org/show_bug.cgi?id=737599), which
did the same for avi files.

The size is determined using the sample size field in stsz atom if set or
searching the maximum sample size in the sample size table field (stsz too)
otherwise. This is similar to what is done in the AOSP project:

http://androidxref.com/4.4.2_r1/xref/frameworks/av/media/libstagefright/MPEG4Extractor.cpp#1353

(See http://goo.gl/sp3S8V for information on the mp4 stsz atom.)

We are using "max-input-size" cap in out androidmedia/hybris decoder

http://goo.gl/qoYLkm ,

as we found some videos produce artefacts for some HW decoders in mobile SoCs.

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