872362 - [unagi weekly build 13.05.08][tara]video apps can't work properly if use kPreferSoftwareCodecs or kSoftwareCodecsOnly

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[James Zhang (Spreadtrum)]

If modify OmxDecoder.cpp, use kPreferSoftwareCodecs or kSoftwareCodecsOnly instead of kHardwareCodecsOnly, video apps can't work properly, for example, unable to generate video thumbnail on unagi, sometime crash on tara.

I don't think all vendor's hardware codec can support all video format, sometimes they may use software codec. 
tara/unagi device works fine on android but can't work fine on FFOS.

Comment 1

[cajbir (:cajbir)]

This is why we don't use software codecs on B2G. We've found them to be unreliable.

Comment 2

[James Zhang (Spreadtrum)]

Hi Chris, I don't think so. 
Because these software codecs work properly on android. And hardware codecs also have some issue, for example , if exist more than one instance of hardware decoder for generating thumbnail, video playback will stuck, see Bug 856542.
And not all vendor will implement hardware codec to support all media formats, sometimes should use software instead of hardware.

Comment 3

[James Zhang (Spreadtrum)]

I think that gecko can support hardware or software codec, by vendor's configure, not hard-code,  will be more flexible.

Comment 4

[cajbir (:cajbir)]

See bug 834150 for why it was disabled. A 'pref' for choosing whether to enable/disable it sounds ok though. There's already one for picking the flags to pass to omx decoder on android - I'm not sure if it's checked on b2g.

The approach of an attribute for deciding whether to use the software or hardware codecs is something that has been considered and I'm not against it. Maybe morph this bug into that to start some discussion.

There's a work week in Taiwan next week with media developers attending so I hope to have some discussion on how to handle the "limited number of hardware decoder instances available" issue.

Comment 5

[James Zhang (Spreadtrum)]

(In reply to Chris Double (:doublec) from comment #4)
> See bug 834150 for why it was disabled. A 'pref' for choosing whether to
> enable/disable it sounds ok though. There's already one for picking the
> flags to pass to omx decoder on android - I'm not sure if it's checked on
> b2g.
> 
> The approach of an attribute for deciding whether to use the software or
> hardware codecs is something that has been considered and I'm not against
> it. Maybe morph this bug into that to start some discussion.
> 
> There's a work week in Taiwan next week with media developers attending so I
> hope to have some discussion on how to handle the "limited number of
> hardware decoder instances available" issue.

Hi Chris, glad to get this information, thank you!

Comment 6

[Sotaro Ikeda [:sotaro]]

I think that gecko should use only hw video codec in v1.0.1 and v1.1.

I recognize following problems related to using sw codec
 
- v1.0.1 and v1.1 expect gecko uses same video codec for thumbnail and video playback. It is a product level design policy. Video app does not show video's thumbnail if it fails to generate thumbnail.

- Requirements to video codec is different from android.
   ex: gecko requires more video out buffers than android(Bug 869443)

- curent gecko does video frame copy when it is sw codec. Because gecko requires more buffers than android and assume sw codec is untouched from android.

- gaia uses same API for thumbnail generation and video playback.

- No mechanism to limit the number of sw codecs in sytem.

- sw codec could starve the memory as in bug 834150.

- android's default H.264 sw video codec does not provide enough capability.

- Firefox OS is a web platform and a web content could consume a lot of cpu power and memory. It conflict with sw video codec.

Comment 7

[BMO Automation]

Firefox OS is not being worked on