All,
I believe that XBMC is failing to use the hardware H264 decoder on my device. I think that this is because a call to CBitstreamConverter::Open returns false inside the DVDVideoCodecAndroidMediaCodec.cpp file. I have put in some debug prints as follows:
Code:
case AV_CODEC_ID_H264:
CLog::Log(LOGDEBUG, "*** CDVDVideoCodecAndroidMediaCodec:: inside AV_CODEC_ID_H264 case." );
m_mime = "video/avc";
m_formatname = "amc-h264";
m_bitstream = new CBitstreamConverter;
if (!m_bitstream->Open(m_hints.codec, (uint8_t*)m_hints.extradata, m_hints.extrasize, true))
{
CLog::Log(LOGDEBUG, "*** CDVDVideoCodecAndroidMediaCodec:: m_bitstream::Open failed about to return false." );
CLog::Log(LOGDEBUG, "*** CDVDVideoCodecAndroidMediaCodec:: extra data %d extrasize %d.",
*(uint8_t*)m_hints.extradata, m_hints.extrasize );
SAFE_DELETE(m_bitstream);
return false;
}
Can someone give me some more insight into why CBitstreamConvert::Open fails? What I notice in my case is that the first element of extra data that is passed to Open is 0. It seems like this leads to the failure. What is the extra data?
12-23 10:37:09.867: V/XBMC(30197): 10:37:09 T:1711984216 DEBUG: *** CDVDVideoCodecAndroidMediaCodec:: m_bitstream::Open failed about to return false.
12-23 10:37:09.867: V/XBMC(30197): 10:37:09 T:1711984216 DEBUG: *** CDVDVideoCodecAndroidMediaCodec:: extra data 0 extrasize 45.
12-23 10:37:09.867: V/XBMC(30197): 10:37:09 T:1711984216 DEBUG: FactoryCodec - Video: amc-h264 - Faile
dump the contents of extra data with Clog::MemDump
davilla,
Here is what MemDump reports. I notice that the value 1 is 4 bytes into the memory buffer.
Code:
12-26 08:02:41.609: V/XBMC(3494): 08:02:41 T:1733239992 DEBUG: *** CDVDVideoCodecAndroidMediaCodec:: extra data 0 extrasize 45.
12-26 08:02:41.609: V/XBMC(3494): 08:02:41 T:1733239992 DEBUG: MEM_DUMP: Dumping from 0x67559ba0
12-26 08:02:41.609: V/XBMC(3494): 08:02:41 T:1733239992 DEBUG: MEM_DUMP: 0000 00 00 00 01 09 10 00 00 00 01 27 64 00 28 ad 00 ..........'d.(�.
12-26 08:02:41.609: V/XBMC(3494): 08:02:41 T:1733239992 DEBUG: MEM_DUMP: 0010 34 c5 01 40 16 ec 05 08 08 08 0a 00 00 07 d2 00 4�.@.�........�.
12-26 08:02:41.609: V/XBMC(3494): 08:02:41 T:1733239992 DEBUG: MEM_DUMP: 0020 03 a9 81 28 00 00 00 01 28 ee 3c c0 30 .��(....(�<�0
Here is the code I added.
Code:
CLog::MemDump((char *)m_hints.extradata, m_hints.extrasize);
Here is the full log I captured.
http://pastebin.com/000QiNC8
davilla,
I was able to play back the stream by hacking up the code to advance the extra data ptr by 3 bytes as follows.
Code:
tmpPtr = (char *)m_hints.extradata;
tmpPtr +=3;
m_hints.extradata = tmpPtr;
m_hints.extrasize -=3;
XBMC then finds the hw decoder as indicated by the following print out. (full log capture
http://pastebin.com/DahAMgsw)
Code:
12-26 08:48:15.343: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.MARVELL.VIDEO.HW.CODA7542DECODER), colorFormat(19)
There are a couple of issues. One is that the video play back is not smooth. I see a lot of prints like the following.
Code:
12-26 08:44:21.468: V/XBMC(13417): 08:44:21 T:1708190912 INFO: CDVDPlayerVideo - Stillframe detected, switching to forced 59.940060 fps
12-26 08:44:21.507: V/XBMC(13417): 08:44:21 T:1708190912 INFO: CDVDPlayerVideo - Stillframe left, switching to normal playback
12-26 08:44:22.289: V/XBMC(13417): 08:44:22 T:1708190912 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available
12-26 08:44:25.796: V/XBMC(13417): 08:44:25 T:1708190912 INFO: CDVDPlayerVideo - Stillframe detected, switching to forced 59.940060 fps
12-26 08:44:25.812: V/XBMC(13417): 08:44:25 T:1708190912 INFO: CDVDPlayerVideo - Stillframe left, switching to normal playback
12-26 08:44:25.890: V/XBMC(13417): 08:44:25 T:1708190912 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available
12-26 08:44:26.218: D/XBMCBroadcastReceiver(13417): Received Intent
12-26 08:44:26.218: V/XBMC(13417): CXBMCApp::onReceive Got intent. Action: android.intent.action.BATTERY_CHANGED
12-26 08:44:27.117: V/XBMC(13417): 08:44:27 T:1708190912 INFO: CDVDPlayerVideo - Stillframe detected, switching to forced 59.940060 fps
12-26 08:44:27.132: V/XBMC(13417): 08:44:27 T:1708190912 INFO: CDVDPlayerVideo - Stillframe left, switching to normal playback
Two is that the audio is out of sync. It looks like XBMC just opens an FFMPEG sw audio decoder. The device does also have a hw audio decoder. As far as I can tell though, XBMC just opens FFMPEG without searching through the audio decoders. Does XBMC try to use hw support for the audio play back?
Code:
-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: FactoryCodec - Audio: passthrough - Opening
12-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: FactoryCodec - Audio: passthrough - Failed
12-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: FactoryCodec - Audio: FFmpeg - Opening
12-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: SECTION:LoadDLL(libswresample-0-arm.so)
12-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: Loading: /data/data/org.xbmc.xbmc/lib/libswresample-0-arm.so
12-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1708115048 DEBUG: CDVDPlayerVideo - CDVDMsg::GENERAL_SYNCHRONIZE
12-26 08:48:15.390: V/XBMC(14950): 08:48:15 T:1705003752 DEBUG: FactoryCodec - Audio: FFmpeg - Opened
"00 00 00 01" is a 4 byte NAL. It means the video is byte stream, not bit stream. Bit stream starts with 01. There is more to it besides the extra data format. Cut me 50 to 100 MB sample from the start and stick it some place where I can download it for testing. There's something wrong with handling it and I need to figure out what.
fixed, thx for the sample.
davilla,
Thanks for looking into this.
Can you tell me what operation to use in git to obtain your fix?
I did a git clone a few weeks back. (I am a relative newbie to git).
davilla,
Thanks for your help on this. I was able to pull down the latest XBMC and recompile it after running configure again.
I can see that XBMC is now using the hw decoder for the H264 stream. (From the source code it looks like you just skip the call to bitstream open if the value 1 is not at byte 0)
BTW, I noticed that it appears that someone fixed the CPU utilization code since the last time I cloned the XBMC source.
Thanks again.