Closed Bug 866028 Opened 11 years ago Closed 6 years ago

[unagi weekly build 13.05.16]tara video playback will be stuck, if repeat play short video

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: james.zhang, Unassigned)

References

Details

Attachments

(3 files)

tara device use softcodec when generate video thumbnail
2.59 KB, patch
Details | Diff | Splinter Review
Video player is stuck when switch quickly
6.55 KB, patch
Details | Diff | Splinter Review
repeat play this video will stuck
69.65 KB, application/octet-stream
Details 
tara device(spreadtrum's sp8810ea) can't support multi-instance hardware video codec. 
Video app will easily crash when generate video thumbnail and video playback at the same time.
We add preSoftCodecs interface, and use softcodec to generate video thumbnail and hardware codec to video playback, avoid video app crash. 
Can you help us to support this WEBAPI or another way to fix this bug.
This bug seems to be like Bug 859650. If you agree this, you may set this as a duplicate with Bug 859650. Thanks.
(In reply to Marco Chen [:mchen] from comment #1)
> This bug seems to be like Bug 859650. If you agree this, you may set this as
> a duplicate with Bug 859650. Thanks.

Hi Marco,
These two bug maybe the same reason.
But video app will crash on tara, not crash on leo. This issue block our smoke test now.
Video playback use hardware codec, if switch to next quickly,  video player is stuck.
Hi Sotaro, can you review this patch ? Maybe it's another way to resolve Bug 856542.
Attachment #742265 - Flags: review?(mchen)
Attachment #742284 - Flags: review?(mchen)
Hi James,

I would give you the feedback first then after all general issues are clear then they will be passed to suitable reviewer.

First of all, Thanks for your contribution here. Then some issues here.

  1. Please refer to the link as below for coding style and naming convention. I think patches here should do some change for this requirement.
     https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style

  2. nsIDOMHTMLVideoElement.idl is modified and it means this is a change on Web API level. A super review will be needed for this and normally it should be discussed in Mozilla's dev-webapi mail list or W3C forum first. After we make sure it is worth to do then start to review it's implementation.
Hi Sotaro and Macro, 
Please play the attachment video repeat, unagi and tara will stuck about 1~2 seconds.
Because qcom hw codec is not support multi-instance and google native code is not support 'pause' interface.
After applied the patch, it will be ok.

E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Video O/P format.eColorFormat 0x7fa30c01
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Timed out waiting for output buffers: 0/5
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.TI.DUCATI1.VIDEO.DECODER'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.Nvidia.mp4.decode'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.qcom.7x30.video.decoder.mpeg4'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.qcom.video.decoder.mpeg4'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.qcom.video.decoder.mpeg4'
E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Video O/P format.eColorFormat 0x7fa30c01
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.TI.DUCATI1.VIDEO.DECODER'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.Nvidia.mp4.decode'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.qcom.7x30.video.decoder.mpeg4'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.qcom.video.decoder.mpeg4'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.qcom.video.decoder.mpeg4'
E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Video O/P format.eColorFormat 0x7fa30c01
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Timed out waiting for output buffers: 0/5
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.TI.DUCATI1.VIDEO.DECODER'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.Nvidia.mp4.decode'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.qcom.7x30.video.decoder.mpeg4'
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.qcom.video.decoder.mpeg4'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.qcom.video.decoder.mpeg4'
E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Video O/P format.eColorFormat 0x7fa30c01
E/OMXCodec(  906): Attempting to allocate OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): Successfully allocated OMX node 'OMX.google.amrnb.decoder'
E/OMXCodec(  906): [OMX.qcom.video.decoder.mpeg4] Timed out waiting for output buffers: 0/5
Summary: [tara]tara device can't support multi-instance hardware video codec → [unagi weekly build 13.05.16]uangi and tara device can't support multi-instance hardware video codec
(In reply to Marco Chen [:mchen] from comment #5)
> Hi James,
> 
> I would give you the feedback first then after all general issues are clear
> then they will be passed to suitable reviewer.
> 
> First of all, Thanks for your contribution here. Then some issues here.
> 
>   1. Please refer to the link as below for coding style and naming
> convention. I think patches here should do some change for this requirement.
>      https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style
> 
>   2. nsIDOMHTMLVideoElement.idl is modified and it means this is a change on
> Web API level. A super review will be needed for this and normally it should
> be discussed in Mozilla's dev-webapi mail list or W3C forum first. After we
> make sure it is worth to do then start to review it's implementation.

Hi Macro,
The code is just an example, I suggest that we can find a better way to fix this issue without change the WEBAPI.
Summary: [unagi weekly build 13.05.16]uangi and tara device can't support multi-instance hardware video codec → [unagi weekly build 13.05.16]uangi and tara video playback will be stuck, if repeat play short video
Hi Macro and Sotaro,
   Can you help me how to distinguish between thumbnail generate and video playback without changing WEBAPI , then I can fix this issue in tara.
Because tara has some limitations, some video can play but can't generate thumbnails by hw codec.
If use hw codec only, many video can't be shown in video thumbnail list.
Summary: [unagi weekly build 13.05.16]uangi and tara video playback will be stuck, if repeat play short video → [unagi weekly build 13.05.16]tara video playback will be stuck, if repeat play short video
Getting bug 869289 fixed would at least show the video in the list, but with a black thumbnail. Nexus S has similar issue.
(In reply to James Zhang from comment #10)
> Because tara has some limitations, some video can play but can't generate
> thumbnails by hw codec.
> If use hw codec only, many video can't be shown in video thumbnail list.

Why hw codec can't generate some video's thumbnails? From this explanation, it seems spreadtrum's parts defect. Why doesn't spreadturm fix this problem?

From v1.1, any apps and web contents can use video tag for video playback generation and drawing video to canvas. Video codec need to be capable of them. Otherwise, the apps ans web contents failed to handle video.
Hi Sotaro,

   As Chris said, can we discuss this issue, maybe gecko can use "ro.moz.omx.thumbnail = software" to resolve tara and nexus-s black thumbnail issue, just like "ro.moz.omx.hw.max_width/max_height".
   Because this is hardware issue, we can't modify the chipset rom code anymore, we can only use software method to avoid it, and this method works fine on android.
(In reply to James Zhang from comment #13)
>    Because this is hardware issue, we can't modify the chipset rom code
> anymore, we can only use software method to avoid it, and this method works
> fine on android.

We're discussing an API for providing a thumbnail directly. The implementation would then use hardware or software as needed and be optimized to get a good thumbnail efficiently instead of having to seek in video element, etc. Would that suit your needs?
(In reply to Chris Double (:doublec) from comment #14)
> (In reply to James Zhang from comment #13)
> >    Because this is hardware issue, we can't modify the chipset rom code
> > anymore, we can only use software method to avoid it, and this method works
> > fine on android.
> 
> We're discussing an API for providing a thumbnail directly. The
> implementation would then use hardware or software as needed and be
> optimized to get a good thumbnail efficiently instead of having to seek in
> video element, etc. Would that suit your needs?

Yes!
followings are summarize of the discussions with :doublec and :cpearce.

- When a codec is used under video tag, the codec needs capability for video playback and drawing to canvas. On web platform, video tag can be used for any way. We can not restrict how the video tag is used. It is different things from android. Android provides dedicate ways.
- v1.01 and v1.1 products' hardware do not have the problem.
- Though, some hw codecs can not be used for thumbnail generation.
- Add a way to specify "use hw codec"/"use sw codec" to video tag is not a good thing. It does not slove a problem for general web applications, but adds problems. 
- In fure Firefox OS(1.2?/2.0?), we could add a dedicated way for thumbnail generation. It is neessary from performance point of view. It could be used also for workaround of the problem.
(In reply to Sotaro Ikeda [:sotaro] from comment #16)
> followings are summarize of the discussions with :doublec and :cpearce.
> 
> - When a codec is used under video tag, the codec needs capability for video
> playback and drawing to canvas. On web platform, video tag can be used for
> any way. We can not restrict how the video tag is used. It is different
> things from android. Android provides dedicate ways.
> - v1.01 and v1.1 products' hardware do not have the problem.
> - Though, some hw codecs can not be used for thumbnail generation.
> - Add a way to specify "use hw codec"/"use sw codec" to video tag is not a
> good thing. It does not slove a problem for general web applications, but
> adds problems. 
> - In fure Firefox OS(1.2?/2.0?), we could add a dedicated way for thumbnail
> generation. It is neessary from performance point of view. It could be used
> also for workaround of the problem.

Sotaro, can you file a new bug and let me track this feature, thank you.
:doublec created Bug 873959.
Comment on attachment 742284 [details] [diff] [review]
Video player is stuck when switch quickly

This is solved by Bug 873371 with a patch landed to CAF.
Attachment #742284 - Flags: review?(mchen)
Comment on attachment 742265 [details] [diff] [review]
tara device use softcodec when generate video thumbnail

This would depends on new Web API introduced from Bug 873959
Attachment #742265 - Flags: review?(mchen)
Depends on: 873959
Blocks: 883051
Firefox OS is not being worked on
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: