Closed Bug 781024 Opened 12 years ago Closed 12 years ago

Video sometimes doesn't play in gaia video app, although audio does

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17
blocking-basecamp +

People

(Reporter: cjones, Assigned: cjones)

References

Details

Attachments

(1 file, 1 obsolete file)

STR
 (-1) Load video app in gaia (likely is just blank screen; that's not *this* bug)
 (0) Hold down HOME, close video app (work around bug)
 (1) Open video app
 (2) Tap first video in list to play

Intermittently, the app window is blank white, but audio plays back just fine.  I see the following in logcat

E/GeckoConsole(  672): [JavaScript Warning: "Invalid URI. Load of media resource  failed." {file: "app://video.thisdomaindoesnotexist.org/index.html" line: 0}]
E/GeckoConsole(  672): [JavaScript Warning: "Invalid URI. Load of media resource  failed." {file: "app://video.thisdomaindoesnotexist.org/index.html" line: 0}]
E/GeckoConsole(  672): [JavaScript Error: "content is null" {file: "chrome://global/content/BrowserElementChild.js" line: 185}]

Not clear whether
 - gaia is buggy here
 - mediastorage is handing out something wonky
 - BEC is causing problems somehow

or combination thereof.
With some logging in gaia at where we set the video source, I see

E/GeckoConsole(  403): [JavaScript Warning: "Invalid URI. Load of media resource  failed." {file: "app://video.thisdomaindoesnotexist.org/index.html" line: 0}]
E/GeckoConsole(  403): [JavaScript Warning: "Invalid URI. Load of media resource  failed." {file: "app://video.thisdomaindoesnotexist.org/index.html" line: 0}]
E/GeckoConsole(  403): [JavaScript Error: "content is null" {file: "chrome://global/content/BrowserElementChild.js" line: 185}]
[snip]
E/GeckoConsole(  403): Content JS LOG at app://video.thisdomaindoesnotexist.org/js/video.js:263 in anonymous: VIDEO FILE: [object File]
E/GeckoConsole(  403): Content JS LOG at app://video.thisdomaindoesnotexist.org/js/video.js:269 in anonymous: VIDEO URL: blob:83c6cf36-b151-4ab5-843b-22df086a3c36

The video src URL looks correct, but something is apparently going wrong before that.
Maybe this is causing problems?

      <video src="about:blank" id="player"></video>
Indeed it is.  Will PR in gaia.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
That wasn't the problem: this is intermittent and I had a lucky run.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
With a little more logging

I/Gecko   (   77): 0x10797d8 Trying load from src=
E/GeckoConsole(   77): [JavaScript Warning: "Invalid URI. Load of media resource  failed." {file: "app://video.thisdomaindoesnotexist.org/index.html" line: 0}]
I/Gecko   (   77): 0x15135d0 Trying load from src=
E/GeckoConsole(   77): [JavaScript Warning: "Invalid URI. Load of media resource  failed." {file: "app://video.thisdomaindoesnotexist.org/index.html" line: 0}]
(SNIP)
E/GeckoConsole(   77): [JavaScript Error: "content is null" {file: "chrome://global/content/BrowserElementChild.js" line: 185}]

It appears that the BEC error is the root cause here.  Digging a bit more.
From a run when video actually plays

E/GeckoConsole(  204): [JavaScript Error: "content is null" {file: "chrome://global/content/BrowserElementChild.js" line: 185}]
I/Gecko   (  204): 0x2504b50 Trying load from src=blob:0ccd184b-4ac4-4ec3-aed8-31a506a22203

and from a run when video doesn't play

E/GeckoConsole(   78): [JavaScript Error: "content is null" {file: "chrome://global/content/BrowserElementChild.js" line: 185}]
I/Gecko   (   78): 0x17beed0 Trying load from src=blob:1a0812b9-f1f5-4f19-9e77-b538badac6ba

so the BEC error isn't the problem, and it looks like the video app is behaving as expected (setting the video src properly).

So apparently something is going wrong either in the video-frame decoder, or somewhere in the composition pipeline.
Indeed, when the video plays, the fps counter behaves as expected.

When it doesn't play, the fps counter doesn't move.
Component: General → Video/Audio
Product: Boot2Gecko → Core
I/Gecko   (   78): ###!!! ABORT: Sizes must match to copy image data.: 'size == mSize', file /home/cjones/mozilla/inbound/gfx/layers/ipc/ImageContainerChild.cpp, line 135
I/Gecko - SYDNEY_AUDIO(   78): 0x1826aa8 - Wrote 4096
F/libc    (   78): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
Blocks: 598868
So in this code

(gdb) p size
$1 = {
  <mozilla::gfx::BaseSize<int, nsIntSize>> = {
    width = 640, 
    height = 368
  }, <No data fields>}
(gdb) p mSize
$2 = {
  <mozilla::gfx::BaseSize<int, nsIntSize>> = {
    width = 640, 
    height = 360
  }, <No data fields>}

where |size| is the size of the Y component of the target SharedImage and mSize is a member of ImageContainerChild.

I'm not 100% sure what's supposed to happen here but this feels like an overzealous assertion.
Assignee: nobody → jones.chris.g
Attachment #649956 - Flags: review?(roc)
Your reorg of the code is good, but I think YUVImage is a bit wrong. It has "nsIntRect picture;" but it should also have nsIntSizes for each of its Y/U/V planes because they might be bigger than the picture rect (and might be different ... we're not guaranteed that U and V are half the dimensions of Y), and we should be checking all of those sizes when we pull an image out of the pool.
https://hg.mozilla.org/mozilla-central/rev/b60c2eedc759
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: