Forgetting for the moment the image issues above (as I've restored playback through the HW H264 codec), I'm now hitting another issue... Testing on a "Live" (m3u8) streaming (.m3u8 URLs; which is the reason I'm trying to use ffmpeg SW codecs at all, as HW one failed to playback these), I got this failure: V/ACodec ( 75): onAllocateComponent V/ACodec ( 75): findMatching OMX codecs 'video/avc' (SW only) V/OMXCodec( 75): matchComponentName (null) V/OMXCodec( 75): matchComponentName (null) V/ACodec ( 75): Found matching codec: 'OMX.ffmpeg.h264.decoder' ... V/ACodec ( 75): ComponentName: OMX.ffmpeg.h264.decoder V/ACodec ( 75): nativeWindow creation V/ACodec ( 75): initNativeWindow E/OMXNodeInstance( 75): OMX_GetExtensionIndex (index:'4083345d') failed Probably ACodec need being patched for ffmpeg too? For one, I don't expect it to use native window... Added below check, in ACodec::LoadedState::onConfigureComponent: if (msg->findObject("native-window", &obj) && strncmp("OMX.google.", mCodec->mComponentName.c_str(), 11) && strncmp("OMX.RENESAS.", mCodec->mComponentName.c_str(), 12) #ifdef USES_NAM && strncmp("OMX.ffmpeg.", mCodec->mComponentName.c_str(), 11) #endif Now ACodec doesn't crash anymore and (just like the HW codec!) it goes on in logcat but no image is shown on screen: ... V/ACodec ( 75): [OMX.google.aac.decoder] calling fillBuffer 0x2a0671b8 V/ACodec ( 75): [OMX.google.aac.decoder] Now Executing V/ACodec ( 75): [OMX.google.aac.decoder] onOMXFillBufferDone 0x2a06a998 time 0 us, flags = 0x00000000, dataPtr = 0x42cef000 V/ACodec ( 75): [OMX.google.aac.decoder] calling fillBuffer 0x2a06a998 V/ACodec ( 75): [OMX.google.aac.decoder] onOMXEmptyBufferDone 0x2a0df9c0 V/ACodec ( 75): [OMX.google.aac.decoder] calling emptyBuffer 0x2a0df9c0 w/ time 92877 us ... Could something still be missing in ACodec? Thanks once again in advance for any help! Fabio On Friday, 7 November 2014 07:04:10 UTC-8, Fabio Fumi wrote:
Btw - testing downloaded files (as suggested in https://github.com/omxcodec/stagefright-plugins), playback is fine, at east with respect to image quality. Similar for both the test .mov and .mp4 files.
Playback hangs and locks once in a while, for a few seconds, with logcat showing lots of:
V/AwesomePlayer( 2090): we're late by 125631 us (0.13 secs) V/AwesomePlayer( 2090): we're late by 125631 us (0.13 secs) dropping one after 0 frames V/AwesomePlayer( 2090): we're late by 125382 us (0.13 secs) V/AwesomePlayer( 2090): we're late by 125382 us (0.13 secs) dropping one after 0 frames V/AwesomePlayer( 2090): we're late by 120819 us (0.12 secs) V/AwesomePlayer( 2090): we're late by 120819 us (0.12 secs) dropping one after 0 frames ...
This happens in particular when there's extesive image changing. Less when video is more static.
Seems like a lack of CPU bandwidth... Mediaserver sets CPU above 50% (though never 100%).
PID PR CPU% S #THR VSS RSS PCY UID Name 2090 0 52% S 16 64160K 17060K fg media /system/bin/mediaserver 3175 0 1% R 1 1072K 476K root top 257 0 0% S 73 549956K 38280K fg system system_server 3009 0 0% S 15 492776K 37872K fg u0_a69 com.mxtech.videoplayer.ad ...
Anyway, with respect to image quelity I don't see any significant difference in the video attribute, with repsect to those streamed though YouTube. See also logcat in http://pastebin.com/tnrt9NB6
On Sunday, 11 August 2013 01:25:25 UTC-7, Chih-Wei Huang wrote:
Hello ffmpeg list, I'm planning to integrate the latest ffmpeg as a stagefright OMXPlugin with Android-x86 4.3. I found the stagefright-plugins developed by Michael Chen is a good start. (repo: https://github.com/omxcodec/stagefright-plugins.git) But it's based on android 4.0 (ICS).
My plan is: * Update stagefright-plugins to work with stagefright of android 4.3. * Make it to be a libstagefrighthw.so plugin. * Create Android.mk to build ffmpeg libs.
Before I go ahead, I'd like to know if anyone is doing a similar project to avoid duplicate work. Thanks a lot!
-- Chih-Wei Android-x86 project http://www.android-x86.org