Closed Bug 766395 Opened 11 years ago Closed 11 years ago

Video decoding using libstagefright on otoro device does not use hardware decoder on B2G


(Core :: Audio/Video, defect, P1)

Gonk (Firefox OS)



blocking-kilimanjaro +
blocking-basecamp +


(Reporter: cajbir, Assigned: cajbir)


(Blocks 1 open bug)



(2 files, 2 obsolete files)

When playing H.264 videos on an otoro device with B2G the software libstagefright decoder is used resulting in poor performance and basic profile support only.
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
Device is missing the following shared libraries to get hardware decoding working:
Assignee: nobody → eflores
h.264 now working on otoro. Very slow, however, and some videos don't work. Will have to investigate further.
Attachment #635154 - Flags: review?(chris.double)
Attachment #635154 - Flags: review?(chris.double) → review+
Had U and V channels backwards. Carry over r=doublec.
Attachment #635154 - Attachment is obsolete: true
Attachment #635167 - Flags: review+
Can we land this so that when the issue in comment 1 is addressed hardware acceleration will work?
Blocks: 767849
Just an update from my perspective. there are some other shared libraries that don't seem to be present. 

E/ExtendedExtractor(  453): Failed to open MM_PARSER_LIB, dlerror = Cannot load library: load_library[1091]: Library '' not found 
E/ExtendedExtractor(  453): Failed to open MM_PARSER_LITE_LIB, dlerror = Cannot load library: load_library[1091]: Library '' not found 

Also the video I am trying to open does not play.  

            //if(!strcmp(mComponentName, "")
            //    && (profile != kAVCProfileBaseline)) {
            //    LOGE("%s does not support profiles > kAVCProfileBaseline", mComponentName);
                // The profile is unsupported by the decoder
            //    return ERROR_UNSUPPORTED;
           // }
This seems to be where the decision is being made.  Uncommented, I get audio playback but the lack of the ".so" files listed above throw an error. 

Without uncommenting I get no audio / video .
Looks like there have been changes to libstagefright, that we don't have... 
as these lines don't show up. is the software decoder. We want the *.qcom.* decoder which those .so files give us. What video doesn't play for you with those .so files included in /system/lib?
Which .so files ? are they checked in ?
See comment 1 or wait for comment 6 to be actioned. Even if comment 6 is done though, if you've already installed b2g you've lost those .so files and need to get them from the original android OS that was on the device.
Chris all otoro devices that went out to QA came pre-flashed to B2G. :( which means those libs are not on my machine.
Attached it the log i received when attempting to play content ||
Obtained original files, applied the pull from comment 6, and tested. 

@Edwin, what is the reference video that you are using. ?
This patch is now obsolete. We should have something proper going in the next couple of days. (sorry!)

Reference video I'm using is
Actually, that's wrong. We'll have something going on maguro, but otoro will require a bit more work yet due to our GB/ICS munge.
So should we rename this bug for maguro, and create a new one for otoro ?
This should stay otoro because we don't have hardware decoding on otoro and that's what it's addressing.
Ok.? Is the above patch obsolete for otoro ? There should be a separate bug for maguro support then.
Edwin, can you give an eta on otoro, and is the b2g demo going to be on a maguro  or an otoro device?
We don't expect that this is device-specific, but rather chipset-specific, right? If it's otoro-only, then we might not need to block on this.
blocking-basecamp: ? → +
blocking-kilimanjaro: ? → +
Depends on: 762697
This is chipset specific, but for all intensive purposes it is device specific.
Otoro is the device we are shipping on.
This particular bug was for the otoro device specific problem of the hardware decoder shared libraries not being installed when doing an otoro config. It also requires the patch which is attached and this allows hardware decoding to work. But it is very very slow - slower than software. The fix for the slowness is being done in bug 759506.

The issue for the shared libraries not being copied was being addressed by Edwin in a pull request to the mozilla-b2g github repository. Once that's done this patch can be landed and the bug closed. 

Edwin, how'd that pull request go?
It is FYI. Platform specific hw codecs is provided by

it is added as OMX plugin in OMXMaster::addVendorPlugin()
How are we doing here?
Priority: -- → P1
Depends on: 759506
It's blocked on 759506 which currently has issues with hardware decoding.
Turns on hardware decoding support on B2G. If the otoro device has the libOmx*.so files for hardware codecs mentioned in comment 1 this enables decoding videos using the hardware decoder.
Assignee: eflores → chris.double
Attachment #635167 - Attachment is obsolete: true
Attachment #654053 - Flags: review?(eflores)
Attachment #654053 - Flags: review?(eflores) → review+
Pull request to get the libraries copied over (updated version of comment 6):
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.