GNOME Bugzilla – Bug 744857
Some decoders need mp4's maximum sample size
Last modified: 2018-11-03 14:57:52 UTC
Created attachment 297396 [details] [review] 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.
I think this is a suplicate of 737599, since the main issue is that we need to agree on how to transmit this information.
This should also be implemented in block for all decoders that need it (I know OMX and V4L2 decoder need that too).
-- 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/gst-plugins-good/issues/160.