Closed Bug 868806 Opened 8 years ago Closed 8 years ago

[Buri][Video]The video can not played when the SD card have a HD-Video.

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
Gonk (Firefox OS)

Tracking

(blocking-b2g:tef+, firefox22 wontfix, firefox23 wontfix, firefox24 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

RESOLVED FIXED
blocking-b2g tef+
Tracking Status
firefox22 --- wontfix
firefox23 --- wontfix
firefox24 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: sync-1, Assigned: sotaro)

Details

(Whiteboard: [target:05.17])

Attachments

(3 files, 3 obsolete files)

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.092
 Firefox os  v1.0.1
 Mozilla build ID:20130430070201
 
 +++ This bug was initially created as a clone of Bug #449489 +++
 
 Created an attachment (id=402945)
 Special video
 
 DEFECT DESCRIPTION:
 The video can not played when the SD card have a Special HD-Video.
 
  REPRODUCING PROCEDURES:
 1.SD card have a Special HD-Videos;
 2.Launch video ,can read the video list;
 3.Choose a video to play ,screen black and can not play the video ,if you deleted the special HD-video, others videos can be played normally.->KO
 
  EXPECTED BEHAVIOUR:
 Can be play video normally whatever have the special video.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 5/5
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #449489 description ++++++++++
blocking-b2g: --- → tef?
Clone from brother
Attached video Special video
Clone from brother
Assignee: nobody → sotaro.ikeda.g
attachment 745627 [details] seems like an abnormal content. Actual playable content is shorter than content duration in mp4 container.
During thumbnail creation, nsBuiltinDecoderReader::DecodeToTarget() falled into infinite loop. During thumbnail creation by video app, video app try to create a thumbnail of 1/4 duration time. But the video does not have data to decode.

https://github.com/sotaroikeda/gaia/blob/master/apps/video/js/video.js#L310
Status: NEW → ASSIGNED
Component: Gaia::Video → General
read() to audio codec return "-1004", but it is not handled in OmxDecoder::ReadAudio() and the function return true even in the error code.
Attached patch patch - handle OMXCodec's error (obsolete) — Splinter Review
By applying the patch, the video is handled as normal. No infinite loop.
Attachment #746632 - Flags: review?(chris.double)
Attachment #746632 - Flags: review?(chris.double) → review+
Severity: normal → major
Without the patch, video an audio app could come into infinite loop by some abnormal contents and freeze untill the apps are killed.
committable patch. Carry "chris.double: review+".
Attachment #746632 - Attachment is obsolete: true
blocking-b2g: tef? → tef+
Whiteboard: [target:05.17]
I am going to confirm if attachment 746988 [details] [diff] [review] regress youtube video playback. I am going to keep how to handle codec timeout error as before for not to regress youtube video playback.
change from v2: handle -ETIMEDOUT (timeout error) same as current gecko for not to regress youtube video playback.
Attachment #746988 - Attachment is obsolete: true
Comment on attachment 749616 [details] [diff] [review]
patch v3 - handle OMXCodec's error

doublec, can you review the patch again?
Attachment #749616 - Flags: review?(chris.double)
Attachment #749616 - Flags: review?(chris.double) → review+
Comittable patch. Carry "chris.double: review+".
Attachment #749616 - Attachment is obsolete: true
Attachment #750025 - Flags: review+
Keywords: checkin-needed
Whiteboard: [target:05.17] → [status: needs uplift][target:05.17]
https://hg.mozilla.org/mozilla-central/rev/ed2c321c9bf6
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [status: needs uplift][target:05.17] → [target:05.17]
Issue reproduces on Unagi 1.1 Build ID: 20130531070205

Environmental  Variables:
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/4f318822e72c
Gaia: e1c59baed29e4665d1da9392f86239272073f07a

The issue did not reproduce on Unagi 1.0.1 Build ID: 20130531070208

The bug was checked on the Inari Build ID: 20130528231041 the video appeared but being able to actually play it was inconsistent. Sometimes it would start 5+ seconds into the video run for 3 seconds then close. Sometimes playing the video would only appear as a gray screen. 

Issue could not be checked on the Leo due to bug#874615
(In reply to Sarah Parsons from comment #18)
> Issue reproduces on Unagi 1.1 Build ID: 20130531070205

I checked it on v1.1 unagi. It seems different bug.
OMXCodec destruct stopped in OMXCodec::stop() at following code.

    while (isIntermediateState(mState)) {
        mAsyncCompletion.wait(mLock);
    }
stack trace of the problem.
I am going to create another bug for it.
(In reply to Sarah Parsons from comment #18)
> Issue could not be checked on the Leo due to bug#874615

On leo device, it works as normal.
(In reply to Sotaro Ikeda [:sotaro] from comment #22)
> I am going to create another bug for it.

Created Bug 878981.
(In reply to Sarah Parsons from comment #18)
> Issue reproduces on Unagi 1.1 Build ID: 20130531070205
> 
> The bug was checked on the Inari Build ID: 20130528231041 the video appeared
> but being able to actually play it was inconsistent. Sometimes it would
> start 5+ seconds into the video run for 3 seconds then close. Sometimes
> playing the video would only appear as a gray screen. 

The problem is in CAF's OMXCodec. Unagi and inari uses ics_chocolate as base platform. It is older qcom's code. New one is ics_strawberry, it is used by hamachi(buri) and leo. As in Bug 878981 comment #7 , ics_chocolate is not supported in v1.1. Need to confirm on hamachi(buri) or leo.
You need to log in before you can comment on or make changes to this bug.