Closed Bug 871018 Opened 12 years ago Closed 12 years ago

handle OMX_StatePause state in OMXNodeInstance::freeNode()

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:leo+, b2g18 fixed)

RESOLVED FIXED
1.1 QE2 (6jun)
blocking-b2g leo+
Tracking Status
b2g18 --- fixed

People

(Reporter: sotaro, Assigned: diego)

References

()

Details

(Whiteboard: MiniWW [POVB])

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #864188 +++ From Firefox OS v1.1, OMX codec is instantiated in mediaserver. When the app that uses OMX codec is killed and OMX codec is in OMX_StatePause state, mediaserver aborts with the log as in Bug 864188 comment #0. It happens because OMXNodeInstance::freeNode() does not handle OMX_StatePause state.
blocking-b2g: leo+ → leo?
Assignee: nobody → sotaro.ikeda.g
Without the fix, Bug 864188 comment #5 happens.
Status: NEW → ASSIGNED
Could this bug could get leo+? It is necessary to fix mediaserver crash. Bug 864188 should be leo- , instead this bug needs to be leo+.
(In reply to Sotaro Ikeda [:sotaro] from comment #2) > Without the fix, Bug 864188 comment #5 happens. Following is a copy from the comment. ---------------------------------------------- On v1.1, mediaserver process handle following things. Some apps use mediaserver concurretly. - audio out, camera hw, video codec, audio codec If mediaserver is killed because of music app, Other apps using mediaserver capability get affected. Example STR - start music app and start mp3 audio - push home button (music continue) - start video app and start to play h.264 video when start to play the video the audio of music app stops. But the music app still uses audio codec. - long push home button and start task manager. kill music app - back to video app. video app can not continue to play video. hw video codec is killed when music app killed.
Blocks: 874165
Target Milestone: --- → 1.1 QE2
Does the patch in bug 864188 solve the problem? We try to avoid patches in gonk because they are expensive to carry forward and every device vendor has to maintain it.
blocking-b2g: leo? → leo+
(In reply to Diego Wilson [:diego] from comment #5) > Does the patch in bug 864188 solve the problem? The patch in bug 864188 does not solve the problem. attachment 748235 [details] [diff] [review] is necessary. We try to avoid patches in > gonk because they are expensive to carry forward and every device vendor has > to maintain it. Yeah, it is going to become a problem :-( But necessary fix.
Diego, can you provide a patch from CAF?
(In reply to Sotaro Ikeda [:sotaro] from comment #7) > Diego, can you provide a patch from CAF? Sure, I will pull in this patch to CAF. IMO this is a workaround the fact that OmxDecoder is not being de-inited. I filed bug 875079. I'm inclined to remove the OMXCodec patch once that bug is fixed to lighten our gonk patch load.
Sotaro, Just so we're clear. Are you saying that the patch in bug 864188 does not ensure OmxDecoder is destroyed or that even if OmxDecoder is destroyed the freeNode() issue happens?
I was saying is that the app process could be killed by some reasons(like low memory killer), in this case the app is killed without de-inited. It happens often in Firefox OS. In android, AwesomePlayer in mediaserver has a responsibility of the deinit in almost all use cases. So, this case is not a normal use case in android. But in Firefox OS, app has a responsibility of it. It could happen more often.
Whiteboard: MiniWW
CAF uplift in progress
Assignee: sotaro.ikeda.g → dwilson
Any updates here?
The wheels are still turning. It'll likely be in CAF in a day or two.
Hi Diego, Can we expect anything landing today?
(In reply to Wayne Chang [:wchang] from comment #14) > Hi Diego, > Can we expect anything landing today? Probably not. There was a major CAF overhaul and there's been many hiccups this week. With any luck it'll make it there over the weekend.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: MiniWW → MiniWW [POVB]
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap?(cschmoeckel)
Added Music Suite Test Case #8937 - Test that ending the Music App's mediaserver process does not affect other mediaserver Apps
Flags: in-moztrap?(cschmoeckel) → in-moztrap+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: