850542 - Video tag does not accept 3gp files which are passed via web activity

Status: RESOLVED DUPLICATE of bug 850941

(Core :: Audio/Video, defect, P1)

Description

[[e-mail], [e-mail]]

Repro Steps:(device id, step)
A.B 0) Pair two devices by Settings-->Bluetooth (device Unagi A and Unagi B)
A.1) Record a video by Camera app
A.2) Share the video from A to B by Gallery app
B.3) Confirm receiving file request and wait the transferring task completely
B.4) Tap the received video on notification when the file transferred successfully
B.5) It will playback the video with a 

Expected:
It should playback the video normally.

Actual:
It cannot playback the video with a black screen.

Note:
According the reproduced stepes, we browse the file from Device Storage when the file transferring completely. Then, we pass the file by WebActivity 'open' in Video-->View.
The received file is contained mimetype video/3gpp. And it can be scanned and playback normally in Gallery app.

The issue needs to wait Bug 838027, Bug 838655 landed.

Log:
E/GeckoConsole(  562): [JavaScript Warning: "HTTP "Content-Type" of "application/octet-stream" is not supported. Load of media resource blob:18eb0a5a-98ef-48eb-905e-d2966b1c5765 failed." {file: "app://video.gaiamobile.org/view.html" line: 0}]

Comment 1

[Dominic Kuo [:dkuo]]

I think this is a general issue for video tag, not "Bluetooth" specific, changing the title.

1. For the 3gp files that we directly retrieve from the deviceStorage(using deviceStorage.get()), we can just play the 3gp without any error. This is how video app did in its logic.

2. But if we pass a 3gp file from bluetooth app to video app via web activity, after video app received it and try to play it, the video tag is unable to play and logs:

[JavaScript Warning: "HTTP "Content-Type" of "application/octet-stream" is not supported. Load of media resource blob:18eb0a5a-98ef-48eb-905e-d2966b1c5765 failed.]

Both scenarios use code like:
  var url = URL.createObjectURL(file);
  player.src = url;
to play the files

So looks like the only difference between 1 and 2 is the 3gp files are directly from the deviceStorage or not, and 1 can be accepted by video tag, 2 cannot.

And I don't think this issue blocks bug 838027 because the open activity of video app will still be triggered by bluetooth app without this fixed. Currently this issue only happens on 3gp files, I have tested mp4 and seems work fine.

Comment 2

[Dominic Kuo [:dkuo]]

Our Camera app save the recorded files to 3gp format, and if this issue is not fixed, I believe when a ffos user transfer his recorded 3gp to another ffos user, can be via bluetooth or email, the open activity of video app will be broken for sure, so I think we better fix this before v1.1 since we are going to support lots of scenarios like this, nominating.

Comment 3

[cajbir (:cajbir)]

According to comment 0 the mime type of the video is "application/octet-stream". It should be "video/3gpp" (or whatever 3gp files are). octet-stream results in file sniffing to occur to identify the mime type and our sniffer probably doesn't know about the format of 3gp files.

See toolkit/components/mediasniffer for that code.

Comment 4

[Paul Adenot (:padenot)]

If the lack of media sniffer support for 3gp is found to be the root issue, adding it would be straightforward, the algorithm to sniff regular mp4 files being already implemented. Simply searching for "3gp" here [1] along with "mp4" and assigning the right mime type will do the job. 

[1]: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/mediasniffer/nsMediaSniffer.cpp#62

Comment 5

[[:fabrice] Fabrice Desré]

Attachment: wip: 3gp streams sniffing support

With this patch the mime type is changes on 3gp streams, but the video app is crashing. I'll post a backtrace as soon as I get one.

Comment 6

[[:fabrice] Fabrice Desré]

And I got this useless stacktrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 491.604]
0x40efc7c4 in ?? ()
(gdb) bt
#0  0x40efc7c4 in ?? ()
#1  0x40085434 in ?? ()
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Comment 7

[David Flanagan [:djf]]

Bug 850941 might be related....

If photo blobs from the system app to the gallery app have no type property and and incorrect size property, I'd guess that video blobs have the same issue.

The workaround might be to use the filename that bluetooth_transfer.js passes along with device storage to read a non-corrupted copy of the blob.

Comment 8

[[:fabrice] Fabrice Desré]

David, I added some log and the blob size looks ok up to the video app (I added the first two lines in ObjectWrapper to see if something was going wrong there):
I/Gecko   ( 3668): Wrapping file, name=downloads/bluetooth/VID_0001-13.3gp type=video/3gpp size=1134789
I/Gecko   ( 3668): Wrapped file, name=downloads/bluetooth/VID_0001-13.3gp type=video/3gpp size=1134789
E/GeckoConsole( 3668): Content JS LOG at app://video.gaiamobile.org/js/view.js:30 in viewVideo: We have a blob downloads/bluetooth/VID_0001-13.3gp video/3gpp 1134789
E/GeckoConsole( 3668): Content JS LOG at app://video.gaiamobile.org/js/view.js:33 in viewVideo: URL=blob:d7d67e6a-a790-4609-bd2c-152a663645ac

Setting the video element .src to the blob url makes us crash, but I don't see anything wrong with the blobs themselves. Also note that the 3gp video files transfered are not listed in the video app when launched on its own.

Comment 9

[Paul Adenot (:padenot)]

Comment on attachment 726411 [details] [diff] [review]
wip: 3gp streams sniffing support

Review of attachment 726411 [details] [diff] [review]:
-----------------------------------------------------------------

This looks like it would work. Not sure why it crashes.

Comment 10

[[:fabrice] Fabrice Desré]

(In reply to Paul Adenot (:padenot) from comment #9)
> Comment on attachment 726411 [details] [diff] [review]
> wip: 3gp streams sniffing support
> 
> Review of attachment 726411 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This looks like it would work. Not sure why it crashes.

The sniffer works fine. We crash when playing the blob url.

Comment 12

[leo.bugzilla.gecko]

Is it working well? I still have problem after adapting attached patch.

Comment 13

[[:fabrice] Fabrice Desré]

(In reply to leo.bugzilla.gecko from comment #12)
> Is it working well? I still have problem after adapting attached patch.

As I said in comment 10, we need this patch to get the right mime type, but it's not enough yet.

Comment 14

[Dylan Oliver [:doliver]]

Andrea said he could take a look at this one.

Comment 15

[Dylan Oliver [:doliver]]

Andrea, have you had a chance to look into this one yet?

Comment 16

[Andrea Marchesini [:baku]]

Yes. I'm working on it. The problem seems to be that when a Blob is moved from process to process by a MozActivity, the Blob forgets its mimetype and its size.

Comment 17

[Andrea Marchesini [:baku]]

I wrote a patch for Bug 850941 and it fixes this bug too. I don't want to mark it as duplicate because probably the fabrice's patch is needed.

Comment 18

[Andrea Marchesini [:baku]]

Can someone check if this bug is fixed with bug 850941 ?

Comment 19

[Eric Chou [:ericchou] [:echou]]

Hi,

Just tested with the latest b2g18(debug build)/v1-train. Most of the time when I tapped on the notification item, I could see the video app is launched and the video is played. However, the video seemed unable to be played for about 2 or 3 times among more than 10 tries. I have retrived the log (http://www.pastebin.mozilla.org/2422430). Hope it helps.

Comment 20

[Eric Chou [:ericchou] [:echou]]

Forgot to mention that, for those times that the video couldn't be played, I launched Settings app right after tapping the notification.

Comment 21

[Andrea Marchesini [:baku]]

> Just tested with the latest b2g18(debug build)/v1-train. Most of the time
> when I tapped on the notification item, I could see the video app is
> launched and the video is played. However, the video seemed unable to be
> played for about 2 or 3 times among more than 10 tries. I have retrived the
> log (http://www.pastebin.mozilla.org/2422430). Hope it helps.

Ok. It seems that this particular bug is fixed (videos + webactivities) but there are other issues playing videos. Can you tell me if you can see the 'broken' video from gallery or from the video app? Maybe the problem is with the video itself or with the decoder. Thanks.

Comment 22

[Eric Chou [:ericchou] [:echou]]

(In reply to Andrea Marchesini (:baku) from comment #21)
> > Just tested with the latest b2g18(debug build)/v1-train. Most of the time
> > when I tapped on the notification item, I could see the video app is
> > launched and the video is played. However, the video seemed unable to be
> > played for about 2 or 3 times among more than 10 tries. I have retrived the
> > log (http://www.pastebin.mozilla.org/2422430). Hope it helps.
> 
> Ok. It seems that this particular bug is fixed (videos + webactivities) but
> there are other issues playing videos. Can you tell me if you can see the
> 'broken' video from gallery or from the video app? Maybe the problem is with
> the video itself or with the decoder. Thanks.

Hi Andrea,

I can see the video in video app, and it could be played very well. The failure seems only happened when I tried to launch another app.

Below is the video link, you can see how I operated:

https://www.dropbox.com/s/duijcxuqcbh4kti/Bug-850542.mp4

Comment 23

[[e-mail], [e-mail]]

Eric,
Thanks for your verification. According your recorder video, I guess window_manager do stopInlineActivity() when launch or switch to other apps. It may need Alive to confirm the behavior in system app. We should make sure that the issue is fixed in general case stably.

Comment 24

[(inactive after 6/18) Alive Kuo [:alive]]

I totally don't understand why comment 0 is relative to comment 23.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

StopAllInlineActivity occurs when:

1) Device locked,
2) Switch to another app.
3) One of the inline activities chain(yes, inline activities could call another inline activity) crashes.

Comment 26

[Andrea Marchesini [:baku]]

> 1) Device locked,
> 2) Switch to another app.

I have to debug it better, but in the short attach, seems this is the case. The user opens the settings app, so probably we call StopInlineActivity() here.

Comment 27

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Andrea Marchesini (:baku) from comment #26)
> > 1) Device locked,
> > 2) Switch to another app.
> 
> I have to debug it better, but in the short attach, seems this is the case.
> The user opens the settings app, so probably we call StopInlineActivity()
> here.

Why the user needs to go to Settings app before inline activity is finished?
Currently it's not recommended to keep the inline activities.

I'm working on move the inline activities to appWindow instead of parallel to all appWindow elements but this may take time to land.

Comment 28

[(inactive after 6/18) Alive Kuo [:alive]]

Another way is using disposition:window activity instead of disposition:inline activity.  Then the request is treated as a normally opened app, which won't be killed by switching app.

Comment 29

[(inactive after 6/18) Alive Kuo [:alive]]

After reading all comments again, my understanding:
1. Gecko bug of blob size/type error within mozActivity is fixed at bug 850491.
2. :echou raised another problem in comment 19,
   which seems an invalid bug for me IFF the activity is invoked but the user action destroys it because of comment 25.

I propose to close this bug as dup of 850491 and open another bug for comment 19,
but I don't think it is a blocking one.

Comment 30

[Andrea Marchesini [:baku]]

If we want we can file a bug about this, but I don't think this is related to this bug. So maybe we can just close this bug as duplicate of Bug 850941