Closed Bug 859650 Opened 11 years ago Closed 11 years ago

[A/V] Video player is stuck

Categories

(Firefox OS Graveyard :: General, defect)

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

Tracking

(blocking-b2g:leo+)

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-b2g leo+

People

(Reporter: leo.bugzilla.gecko, Assigned: sotaro)

Details

(Keywords: regression, Whiteboard: c=) 

Video application -> play some video clip that uses H/W codec -> back button -> play another video clip that uses H/W codec

I'm not sure but here is the process
1. Application calls load() without source to close it self at the first play
2. MediaElement clean up all of its resrouces, after that, at last OMX decoder is destructed. (Becuase MediaElement uses smart pointer to keep OMXDecoder object)
3. In destructor of OMX decoder, it call stop() function and try to close OMX component and parser.

Sometimes, 1 -> 3 takes more than 700ms as I tested.
If second play comes between 1 and 3, video player is stuck.
In this case,
1. First play cannot be closed.
2. Second play cannot work because first one hold H/W codec (H/W codec support only one instance)
3. Video player doesn't consider error from gecko, so the screen freezes
blocking-b2g: --- → leo?
Summary: [A/V] Invalid operation of Video player → [A/V] Video player is stuck
Assignee: nobody → sotaro.ikeda.g
blocking-b2g: leo? → leo+
Keywords: regression
Does it uses leo device? Does it happen also on unagi device?
I tested this problem using leo device.

And I think unagi device doesn't have this problem.
I'll check more.
This problem also happens while retrieving thumbnail.

Sometimes, another thumbnail request comes from app before previous one doesn't finished yet.

Then, you can see the log like below.
01-09 04:25:38.589 E       145      omx_vdec                     Video decoder instance already exists.

When this occur, the video clip is not listed up even though it can be played well.
comment #3 seems a problem of Bug 856542.
Does the problem happens also on another devices?
Flags: needinfo?(leo.bugzilla.gecko)
I ordered leo device 2 weeks ago. But I still do not receive the device...
I fill like this problem is hard to reproduce after patch for Bug 837051.
I'm not sure it's affected by that patch or not.
Flags: needinfo?(leo.bugzilla.gecko)
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> comment #3 seems a problem of Bug 856542.

The main reason is same but it's different case.

Bug 856542 occur when user try to play something before video application finishes thumbnail loading.
But this case is not related to thumbnail.

Just try to play video file continously.
I flashed MozBuild ROM to leo device. Leo device with MozBuild ROM failed to create mpeg4 hw codec.
By using partner build ROM(leo BuildID 20130425170448), I can not reproduce the problem. Are there a tip to reproduce the problem? How often is the problem happens now?
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> By using partner build ROM(leo BuildID 20130425170448), I can not reproduce
> the problem. Are there a tip to reproduce the problem? How often is the
> problem happens now?

What I requested here, is hard to reproduce after patching Bug 837051.

Is it possibly affect by the patch?
I'm not sure that it happen when first play is always MPEG4 or not.
By Bug 837051, gecko reduces the number of video frames holing within gecko as few as possible. There are no way to reduce from there.
(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> By Bug 837051, gecko reduces the number of video frames holing within gecko
> as few as possible. There are no way to reduce from there.

Sorry, it was for Bug 864230.
(In reply to leo.bugzilla.gecko from comment #11)
> Is it possibly affect by the patch?
> I'm not sure that it happen when first play is always MPEG4 or not.

Yes, Bug 837051 was to increase the number of buffer that hw video codec can use. If hw codec is in buffer starvation, the codec's shut down is going to take longer time than normal condition.
Whiteboard: c=performance
Status: NEW → ASSIGNED
(In reply to Sotaro Ikeda [:sotaro] from comment #14)
> (In reply to leo.bugzilla.gecko from comment #11)
> > Is it possibly affect by the patch?
> > I'm not sure that it happen when first play is always MPEG4 or not.
> 
> Yes, Bug 837051 was to increase the number of buffer that hw video codec can
> use. If hw codec is in buffer starvation, the codec's shut down is going to
> take longer time than normal condition.

I'll check thils issue on previous version (before Bug 837051) and inform you again.
I think it's affected by Bug 837051.

I can see this problem so easily on previous version.
But after patching it (But 807051), I cannot reproduce this issue.
Hi all,

see Bug 866028, tara also has this issue.
I suggest that use software codec to generate video thumbnail and use hardware codec to playback, to avoid stuck.
(In reply to James Zhang from comment #17)
> Hi all,
> 
> see Bug 866028, tara also has this issue.
> I suggest that use software codec to generate video thumbnail and use
> hardware codec to playback, to avoid stuck.

Hw resource contention between playback and thumbnail is handled in Bug 856542.
Component: Gaia::Video → General
Whiteboard: c=performance → c=
Sotaro - is this bug fixed by the work in bug 856542?  If not, is the work remaining still enough to be considered a blocker?
Flags: needinfo?(sotaro.ikeda.g)
(In reply to leo.bugzilla.gecko from comment #16)
> I think it's affected by Bug 837051.
> 
> I can see this problem so easily on previous version.
> But after patching it (But 807051), I cannot reproduce this issue.

If you cannot reproduce anymore, please close this bug.
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #19)
> Sotaro - is this bug fixed by the work in bug 856542?  If not, is the work
> remaining still enough to be considered a blocker?

This bug is fixed bug 856542 and Bug 864230, I think.
Flags: needinfo?(sotaro.ikeda.g)
leo, can you reproduce the bug?
Flags: needinfo?(leo.bugzilla.gecko)
No, i cannot reproduce this bug after Bug 837051.
I'm closing this
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(leo.bugzilla.gecko)
Resolution: --- → INVALID
Works for me as we can no longer reproduce
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.