Marcia Knous [:marcia] Reporter
	Description • 12 years ago

unagi, while running Mozilla RIL using:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/d467369d1b0c
Gaia   06e0e5ce42bdfb62bdbe38271de6b5b2d9e40e75
BuildID 20130403070204
Version 18.0

STR:
1. Load some MP4 files on the device. In my testing I was adding albums to my music collection to test the search feature
2. Try to play them

Expected: They will play
Actual: They do not play

The content I loaded in this build previously played in other versions. The content shows in the UI (Album name, etc) but nothing will play.

	cajbir (:cajbir)
	Comment 1 • 12 years ago

Can you attach an example MP4 file containing music that does not work please.

	cajbir (:cajbir)
	Comment 2 • 12 years ago

Is there a regression range?

	Marcia Knous [:marcia] Reporter
	Comment 3 • 12 years ago

I have emailed the file to Chris.

I will work on a regression range. The major change recently in music was the landing of the search feature.

	Marcia Knous [:marcia] Reporter
	Comment 4 • 12 years ago

I ran logcat while I was trying to play the track, not sure how useful it will be.

	cajbir (:cajbir)
	Comment 5 • 12 years ago

I can confirm that playback doesn't work for me on an Otoro with the sample mp4 file. I see this in the logcat:

E/GeckoConsole(  470): [JavaScript Warning: "HTTP "Content-Type" of "image/vnd.wap.wbmp" is not supported. Load of media resource blob:7a8e556c-6b6f-44a6-893b-7d8ebc943eeb failed." {file: "app://music.gaiamobile.org/index.html#" line: 0}]

I don't know if it's related.

	cajbir (:cajbir)
	Comment 6 • 12 years ago

If I rename the music file from an .m4a to have a .mp4 extension it plays in the music app. Seems to have lost the association with m4a's for some reason.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 7 • 12 years ago

For what it's worth, this doesn't occur in MC.  It happens in the v1 train.  Not sure about 1.0.1

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 8 • 12 years ago

FWIW, I've added https://github.com/mozilla/gaia-ui-tests/issues/619 so we can help catch this potentially regressing in the future.

	Marcia Knous [:marcia] Reporter
	Comment 9 • 12 years ago

Here is the regression range:

Works:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/406b86b4b515
Gaia   c5a8b6476f0dbc456061227a7801e56634683eb0
BuildID 20130319070203
Version 18.0

Broken:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/778da49486f0
Gaia   2a5ddb6758272227c1877b45984e053989189e36
BuildID 20130319230202
Version 18.0

	cajbir (:cajbir)
	Comment 10 • 12 years ago

(In reply to Marcia Knous [:marcia] from comment #9)
> Here is the regression range:

http://hg.mozilla.org/releases/mozilla-b2g18/pushloghtml?fromchange=406b86b4b515&tochange=778da49486f0

Given the error in comment 5 I'm thinking the WBMP patches:

c8405670d3bd	Shih-Chiang Chien — Bug 847310 - WBMP decoder implementation. r=joe, a=leo+
7bf4db4abef4	Shih-Chiang Chien — Bug 847310 - Test cases for WBMP decoder. r=joe, a=leo+
3b14247eeb6e	Ryan VanderMeulen — Bug 847310 - Fix include - b2g18 still uses imgIDecoderObserver.h. a=bustage
5651355a1499	Ryan VanderMeulen — Bug 847310 - More bustage fixes. a=bustage
778da49486f0	Ryan VanderMeulen — Bug 847310 - Yet another bustage fix. a=bustage

	cajbir (:cajbir)
	Comment 11 • 12 years ago

From http://hg.mozilla.org/releases/mozilla-b2g18/rev/c8405670d3bd:

+  // A well-defined type 0 WBMP file starts with an "0000 0000b" byte followed
+  // by an "0xx0 0000b" byte (x = don't care).
+  else if (aLength >= 2 && (static_cast<unsigned char>(aContents[0]) == 0x00 &&
+                            (static_cast<unsigned char>(aContents[1]) & 0x9F) == 0x00))
+  {
+    aContentType.AssignLiteral(IMAGE_WBMP);
+  }

Won't this catch any file beginning with 0x0000?

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Assignee
	Comment 12 • 12 years ago

The WBMP header is too common for mime type sniffer, I'll remove it from imgLoader::GetMimeTypeFromContent().

	cajbir (:cajbir)
	Comment 13 • 12 years ago

(In reply to Shih-Chiang Chien [:schien] from comment #12)
> The WBMP header is too common for mime type sniffer, I'll remove it from
> imgLoader::GetMimeTypeFromContent().

Thanks, I'll assign this to you.

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Assignee
	Comment 14 • 12 years ago

WBMP header format is 0x0000, which is too common for mime type sniffer. Remove the header detection in imgLoader::GetMimeTypeFromContent().

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Assignee
	Comment 15 • 12 years ago

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #7)
> For what it's worth, this doesn't occur in MC.  It happens in the v1 train. 
> Not sure about 1.0.1
bug 799315 add m4a in extraMimeEntries and that's why m-c can detect mime type for m4a correctly. 1.0.1 should not have this issue since WBMP is not supported in 1.0.1.

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Assignee
	Comment 16 • 12 years ago

Comment on attachment 734526 [details] [diff] [review]
should not detect WBMP in content sniffer

Hi Jeff, could you help review this patch since @joedrew is on PTO?

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Assignee
	Comment 17 • 12 years ago

minor update, remove 1 unnecessary blank line in previous patch.

	Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) Assignee
	Comment 18 • 12 years ago

update reviewer information in hg log. carry r+

https://tbpl.mozilla.org/?tree=Try&rev=2ba7fd323e0a

	Ryan VanderMeulen [:RyanVM]
	Comment 19 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/c6dae4b543df

	Ryan VanderMeulen [:RyanVM]
	Comment 20 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/c6dae4b543df

	Ryan VanderMeulen [:RyanVM]
	Comment 21 • 12 years ago

https://hg.mozilla.org/releases/mozilla-b2g18/rev/698092f2bcff

	Marcia Knous [:marcia] Reporter
	Comment 22 • 12 years ago

Verified fixed, Mozilla RIL, using:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/e0bab06d5d36
Gaia   9f537aa216f3c12725c8d1c5c9603370b6bc1c46
BuildID 20130418230203
Version 18.0

My m4a files now play fine using this build.