libstagefright: Extended media support via FFMPEG
* Original work by Michael Chen - https://github.com/omxcodec * Kitkat port by Chih-Wei Huang / Android X86 project * Additional fixes by Arcee and Cyanogen * High resolution support by Cyanogen * Lollipop port and refactoring by Cyanogen ------ libstagefright: add null checking to addPlugin libstagefright: fix error handling of dlsym() According 'man dlsym', a NULL return from dlsym() doesn't indicate an error. The correct way to test for an error is to call dlerror() to clear any old error conditions, then call dlsym(), and then call dlerror() again to check whether its return value is not NULL. libstagefright: add more media mimetypes This is the first step to add the ffmpeg plugins. libstagefright: add ExtractorPlugin The patch allows to load an ExtractorPlugin to extend the functions of DataSource::sniff and MediaExtractor. A plugin has to implement a C function getExtractorPlugin to fill the MediaExtractor::Plugin struct. The filename of the plugin could be specified by the media.stagefright.extractor-plugin property. Change-Id: I995a37a4f1ab4bba6ca3c24c7001a27a1e3ccb90 FLACExtractor: Add more sample rates support In FLACExtractor.cpp, it has function to check file's sample rate. If the input sample rate is not in its list, it will return "unsupported sample rate" issue. Modify code to make other sample rates (100,1k,42k,46k) pass the check Issue: AXIA-1441 Change-Id: I48f91119275560ec6d00feb0dedc70d10aa55262 Signed-off-by:Xiaobing Feng <xiaobing.feng@windriver.com> Signed-off-by:
Matt Gumbel <matthew.k.gumbel@intel.com> libstagefright: add ffmpeg components libstagefright: add more decoders Add support for wma, wmv, ra, ape, dts decoders. Change-Id: Iaf48a806aa0cef7d9bcb848383fc3d778c8bd248 libstagefright: allow to use the extended extractor in priority If the meta contains the string "extended-extractor-use", use the extended extractor first. add support for rv20, rv30 add ffmpeg heuristic decoder Change-Id: I5eed11b563ca7f15d44bacfb795d6f3da08ab883 add HEVC(H.265) decoder and cleanup Squashed the following commits of branch cm_maguro-10.1 from https://github.com/omxcodec/android_frameworks_av.git by Michael Chen <omxcodec@gmail.com> defb904 remove MEDIA_MIMETYPE_AUDIO_MP2 8036958 add fetchUriFromFd func to get file name 91bc7d5 fix videoCompressionFormatString and audioCodingTypeString funcs f03069f reset FRAME_DROP_FREQ to 0 718b99a add HEVC(H.265) decoder 84f8bf6 cleanup f026c93 cleanup 440614a add debug info Change-Id: Ie75db0778f633357e2280aef6d47a0fa3beb823e AwesomePlayer: use AwesomeLocalRenderer for OMX.ffmpeg.* components stagefright: Remove duplicate types from QC media defs Change-Id: I50ecafe79a2985d0868a1ac82464d6ca448aa2c5 Conflicts: media/libstagefright/ExtendedMediaDefs.cpp media/libstagefright/OMXCodec.cpp libstagefright: Re-introduce a QCOM_HARDWARE ifdef after the FFMPEG commit Fixes a build error on non QCOM hardware. Change-Id: I4a4268b351d0d8bf748dd03ccea0fbab20ed4314 DataSource: Split off ffmpeg sniffer to a second pass, and only if necessary ffmpeg's sniffer is intended as a grab-all-that-doesn't-work-elsewhere extractor. Unfortunately, this causes two issues: - As written, it requires ffmpeg to whitelist any extractors supported by stagefright, or else it will blindly override them. This has codebase sync issues, as shown by the VP9 and WAV accidental overrides - It imposes an in-depth analysis of _all_ media, even that which we want to be processed quickly by shipping stagefright plugins (hardware or not). This is mostly noticeable in network streams and thumbnail generation. This patch moves FFmpegExtractor to an independent sniffer queue, and it only invokes it when the regular MediaExtractor hits 1 of 3 conditions: 1 - The confidence in the identified container type is low 2 - No container is identified at all 3 - A video container was found by other extractors, but only 1 stream (audio or video) was identified. Change-Id: Ib96ff4f6bc06223fe0e819a57560d3c872a79ddd stagefright: OMX.ffmpeg.* are software decoders, ensure they're treated as such Wherever the component name for OMX.google soft decoders is used to identify a software-based component, do the same for ffmpeg. Things like memory management and window buffers care about this. Change-Id: Ib83561936c7383e8726edb073cea9d78f7d1312f libstagefright: Don't invoke FFMPEG for MP3 Change-Id: Ia30d25d1a994328827f14a286661cd2e1eaa1181
Loading
Please register or sign in to comment