[Video] Video's made on the Spark/Aries device do not work on Flame device

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: AdamA, Assigned: aosmond)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:-, b2g-v2.2 unaffected, b2g-master affected)

Details

(Whiteboard: [3.0-Daily-Testing], URL)

Attachments

(4 attachments, 1 obsolete attachment)

Created attachment 8625939 [details]
logcat

Description:
If the user Makes a video on the Spark device and then transfer it to the Flame Device they will not play. If the file is transferred through Bluetooth or NFC there is a message that says that it is the wrong filetype or was a network error. if the file is placed on the memory card of the Flame the video app does not recognize it.

Repro Steps:
1) Update a Flame to 20150622160206
2) Record a video using the spark device 
3) Transfer the video to a Flame using NFC or bluetooth
4) Open notification center on flame
5) Select the notification for the transferred file
6) Observe Error message

Actual:
Videos made on spark do not play on Flame

Expected:
It is expected that all supported videos on the flame device are playable

Environmental Variables:
Device: Flame 3.0 (Full Flash)
Build ID: 20150622160206
Gaia: 311c4e59936a407e64509f54fecb440d8a78e3c8
Gecko: be81b8d6fae9
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Environmental Variables:
Device: Aries 3.0 (Full Flash)
BuildID: 20150624143841
Gaia: eb0d4aefa62b20420d6fa0642515a110daca5d97
Gecko: 4cdc1a95a672
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Repro frequency: 10/10
See attached: video clip(http://youtu.be/yVyEGaoY9m0), logcat
(Reporter)

Comment 1

4 years ago
This issue DOES NOT occur on Flame 2.2.

Environmental Variables:
Device: Flame 2.2 (Full Flash)
BuildID: 20150624002503
Gaia: 1f8981d7872e3c0053571c26fb3edaf401844d75
Gecko: 3268ab642b70
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Result:
The video plays after it is transferred.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.2: --- → unaffected
status-b2g-master: --- → affected
Flags: needinfo?(onelson)
Keywords: regression
Whiteboard: [3.0-Daily-Testing]
[Blocking Requested - why for this release]:
Blocking concern for potential codec error landing on 3.0. Not sure why the same video would not be able to be played on a 3.0 if it's acceptable on 2.2.

Adding regressionwindow-wanted
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(onelson) → needinfo?(npark)
Keywords: regressionwindow-wanted
QA Contact: pcheng
I know this is a known issue, and currently :djf is working on it, but i can't seem to find the bug # for it.  David, could you point us to the original bug?
Flags: needinfo?(npark) → needinfo?(dflanagan)
This is the first I've heard of this. I've got no clue.

Am I reading this bug correctly that the same spark 3.0 video does play correctly on a flame 2.2 device? That's weird.

Also, since comment #0 says that the bug reproduces by just putting the video on an sdcard (or copying from one device to the other via adb) then let's focus on that since it is the simpler case to start with. Transferring via NFC adds extra complication.

I've got no clue what might be going on here. It would be helpful to know if there are any error messages form the video app in the logcat. How big (pixel size) is the video that the Aries device records? It might simply be too big for Flame to play. It would be interesting to try the same test with the front-facing selfie camera on the Aries. A video from that camera is probably smaller. Can it be played?

Is this memory related? How much memory are the 3.0 and 2.2 Flame devices that this was tested with?

Needinfo Andrew to ask if he knows of any codec differences between Flame and Aries.

If this seems to be related to the size of the video or the memory on the device, then we'll want to contact the gecko media people to see if there have been relevant gecko changes between releases.
Flags: needinfo?(dflanagan) → needinfo?(aosmond)
mozilla-inbound regression window:

Last Working
Device: Flame
Build ID: 20150427015253
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: fe832ef6cc60
Version: 40.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

First Broken:
Device: Flame
Build ID: 20150427020457
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 5fa88d413c4f
Version: 40.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Last Working Gaia & First Broken Gecko - issue DOES reproduce:
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 5fa88d413c4f

Last Working Gecko & First Broken Gaia - issue does NOT reproduce:
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: fe832ef6cc60

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fe832ef6cc60&tochange=5fa88d413c4f

Possibly caused by changes made in bug 1146729.
Blocks: 1146729
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Blake, can you take a look at this please? This might have been caused by the landing for bug 1146729.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(bwu)
Adam,
Could you attach your testing content?
Thanks!
Flags: needinfo?(bwu) → needinfo?(aalldredge)
(Reporter)

Comment 8

4 years ago
Created attachment 8627330 [details]
Spark video.3gp

I have attached a video that I was able to use to reproduce this issue.
Flags: needinfo?(aalldredge)
(In reply to Adam Alldredge [:AdamA] from comment #8)
> Created attachment 8627330 [details]
> Spark video.3gp
> 
> I have attached a video that I was able to use to reproduce this issue.
Thanks! I can repro this problem and it looks it is a bug related to Gecko.
Assignee: nobody → bwu
Flags: needinfo?(aosmond)
I push the attached video file to my Flame and it cannot be seen in Video APP. 
The rootcause is the resolution that Spark record is 3840x2160 which is too high to be supported by Flame. 

Djf, 
Maybe we still need to add an warning icon to show user that this file cannot be supported. IIRC, previously there is a bug to discuss it, but no conclusion is reached.
Status: NEW → ASSIGNED
Flags: needinfo?(dflanagan)
(In reply to Blake Wu [:bwu][:blakewu] from comment #10)
> I push the attached video file to my Flame and it cannot be seen in Video
> APP. 
> The rootcause is the resolution that Spark record is 3840x2160 which is too
> high to be supported by Flame. 

Wow. That is UHD resolution, almost 4x as large as 1080p. That should not be the default in our camera app.  If iMovie in MacOS tells me I should downsample my 1080p video to 720p, I can't imagine why anyone thinks it would be a good idea to record UHD video from a handheld mobile device. 

Our camera app defaults to recording at the highest resolution possible. I don't think anyone anticipated that resolutions this high would become possible. I'd suggest that we fix this in the camera app.

Needinfo Andrew, Justin and Wilson: are you willing to change the default resolution here? Or enable the resolution menu maybe?  Or at least disable this UHD mode?

> 
> Djf, 
> Maybe we still need to add an warning icon to show user that this file
> cannot be supported. IIRC, previously there is a bug to discuss it, but no
> conclusion is reached.

If we can distinguish a video that is valid but too large from a video that is just invalid or a corrupt file, then I agree we should do something like that.  But let's use a separate bug for that and use this one for fixing the more immediate foxfooding issue.
Flags: needinfo?(wilsonpage)
Flags: needinfo?(jdarcangelo)
Flags: needinfo?(dflanagan)
Flags: needinfo?(aosmond)
Created attachment 8627730 [details] [review]
pull-request (master)
Flags: needinfo?(wilsonpage)
Attachment #8627730 - Flags: review?(jdarcangelo)
(In reply to David Flanagan [:djf] from comment #11)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #10)
> > 
> > Djf, 
> > Maybe we still need to add an warning icon to show user that this file
> > cannot be supported. IIRC, previously there is a bug to discuss it, but no
> > conclusion is reached.
> 
> If we can distinguish a video that is valid but too large from a video that
> is just invalid or a corrupt file, then I agree we should do something like
As long as any errors happens, IMHO we should show a warning icon no matter what is the error. QA or users can easily know something is wrong and report a bug instead of seeing nothing. 
> that.  But let's use a separate bug for that and use this one for fixing the
> more immediate foxfooding issue.
(Assignee)

Comment 14

4 years ago
Reducing the default makes sense to me. I'll set it to prefer 1080p over 4kuhd as the default in Gecko.
Flags: needinfo?(jdarcangelo)
Flags: needinfo?(aosmond)
(Assignee)

Updated

4 years ago
See Also: → bug 1179726
Comment on attachment 8627730 [details] [review]
pull-request (master)

Thanks Wilson. This should work around the issue.
Attachment #8627730 - Flags: review?(jdarcangelo) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
I'm very sad of this change. We have no way to let the user record 4K videos and we are explicitely blocking this just because we cannot play it on Flame. What about dogfooders that want to record in 4K magic instants of their life?
Flags: needinfo?(drs)
(In reply to Andrew Osmond [:aosmond] from comment #14)
> Reducing the default makes sense to me. I'll set it to prefer 1080p over
> 4kuhd as the default in Gecko.

Then please stop hiding this setting to the user and we should let the configuration menu available for setting pictures and videos resolutions.
Bug 1132176 was explicitely worked on to allow 4K to work.
(In reply to Adam Alldredge [:AdamA] from comment #0)

[...]

> 
> Actual:
> Videos made on spark do not play on Flame
> 
> Expected:
> It is expected that all supported videos on the flame device are playable

That's not a regression, you are stating it by yourself: 4K is not something that is supposed to work on Flame.
Hence it's not a supported video format.
Hence, not a regression.
> 
> Wow. That is UHD resolution, almost 4x as large as 1080p. That should not be
> the default in our camera app.  If iMovie in MacOS tells me I should
> downsample my 1080p video to 720p, I can't imagine why anyone thinks it
> would be a good idea to record UHD video from a handheld mobile device. 
> 
Actually, there are a number of smartphones that support 4K recording: http://heavy.com/tech/2015/05/best-4k-video-recording-smartphone-camera-review/ including IPhone 6 and Galaxy 6 (and other newer models), and most of them also can handle on-device editing.  Perhaps as Alexandre says, it would be better to create a bug for having a UI to select the resolution instead (since I can't find such bug) in the Camera app, rather than cripple the feature indefinitely.  

It is odd to force the video file backwards compatible though- A SD TV won't play 1080p, but that's expected.  Or, do we have a rule that we should play all fxos-derived videos in all fxos device?  Djf, what do you think?
Flags: needinfo?(dflanagan)
Sorry, there is a feature bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1183705
No-Jun: I think we should offer high resolution options, but they shouldn't be the default.
Flags: needinfo?(dflanagan)
Flags: needinfo?(drs)

Updated

3 years ago
blocking-b2g: 2.5? → 2.5+
I was able to reproduce this bug under the following steps:
1) Take video on Aries device
2) Copy video to computer (both Mac and Windows 7)
3) Put video onto SD card of Flame device
4) Reboot Flame device and launch video application

Result
5) Video was not present in the video or gallery application

Aries Build:
Build ID               20151016122951
Gaia Revision          8999f0ba6326d815c8366e3c1155b7e4e9763b40
Gaia Date              2015-10-15 21:38:55
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/ccf288f658211b6cfab33c458aaf033baed2375b
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150619.224059
Firmware Date          Fri Jun 19 22:41:08 UTC 2015
Bootloader             s1

Flame Build:
Build ID               20151019030208
Gaia Revision          f75bd584aca0a751a5bed115800250faa8412927
Gaia Date              2015-10-19 06:39:58
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1a157155a4fe0074b3d03b54fe9e466472c2cd56
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  65
Firmware Date          Mon Dec 15 18:51:29 CST 2014
Bootloader             L1TC000118D0
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Michael, could you let us know what was the resolution of the video image that you copied over?  If it is a UHD resolution (3840x2160), then I agree this could be reopened, but otherwise we should open a new one.
Flags: needinfo?(mbryant)
From the yesterday's build, the resolution of the aries video that I created is in 1280x720, so I suspect this is a different issue exhibiting the same symptom.  if so, could you close this bug and raise a new one?  Thanks!
And *if* you create a new bug, could you link it to https://bugzilla.mozilla.org/show_bug.cgi?id=1217220 as well? it seems that they might be related, since both cases involve external videos not playing on the device.
No-Jun, the video I copied over was 2160x3840.
Flags: needinfo?(mbryant)
talked to :uber on irc, and he's retesting with the latest build since yesterday's build for me only gave 1280 * 720 (upgraded via OTA)
Marking as resolved and opening a new bug due to the fact that videos on Aries are now 1280x720 making the problem different from this bug.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 years ago
Resolution: --- → FIXED
Reopening, it looks like the bug was not fixed, the recording was still being done in 4K but it was unnoticed due to the Gallery bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ni?ing punam since she is currently investigating the issue.
Flags: needinfo?(pdahiya)
As per comment #11 and comment #14, we should be reducing the default resolution at which Aries camera record video. 
Andrew, I see a patch attached to Bug 1179726. Looks like we need that fix to resolve the issue in this bug.  Unassigning myself and setting NI flag for you to help with next steps. Thanks!
Flags: needinfo?(pdahiya) → needinfo?(aosmond)
Component: Gaia::Video → Gaia::Camera
Updating bug to reflect correct component
Un-assign myself.
Assignee: bwu → nobody
Taking this to see what's going on.
Assignee: nobody → jdarcangelo
(Assignee)

Comment 37

3 years ago
Note that the recording is actually 1080p (as expected) but gallery reports 720p because it gets the size from the poster data (gecko posters strike again!). This explains that discrepancy but not why the video fails to play on flame. Can flame play 1080p in general?
Flags: needinfo?(aosmond)
(Assignee)

Comment 38

3 years ago
(In reply to Andrew Osmond [:aosmond] from comment #37)
> Note that the recording is actually 1080p (as expected) but gallery reports
> 720p because it gets the size from the poster data (gecko posters strike
> again!). This explains that discrepancy but not why the video fails to play
> on flame. Can flame play 1080p in general?

Hm now that I've done the local build myself instead of pulling off taskcluster (release not debug) I see it uses UHD. The PR attached to this bug should have fixed that... I'll update the patches attached to bug 1179726 to get this working as expected.
(Assignee)

Comment 39

3 years ago
I see what the original PR failed now. There is an additional profile "default" which should have been filtered but was not. However I don't think we should be refusing to record at 1080p on aries (only on flame) so I will enhance the patches from bug 1179726 to reflect this.
Re-assigning to Andrew since he seems to know what's going on here :-)
Assignee: jdarcangelo → aosmond
(Assignee)

Updated

3 years ago
Depends on: 1179726
(Assignee)

Comment 41

3 years ago
I should have tried actually playing the video on flame/1GB before closing off bug 1179726. It cannot playback 1080p either. Reducing it to 720p worked. njpark, I think reducing the default to 720p with no way to increase it is unreasonable...?

Maybe we should just expose the setting -- turns out turning it on is a bad idea as it stands because 1) you see duplicated options in the menu, 2) they have bits that would need to be translated (i.e. default, low, high) and 3) there is a bug on the title it displays when changing the resolution (i.e. Video Resolution undefined).
Flags: needinfo?(npark)
Created attachment 8680996 [details] [review]
[gaia] aosmond:bug1177250 > mozilla-b2g:master
(Assignee)

Updated

3 years ago
Attachment #8627730 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Attachment #8680996 - Flags: review?(jdarcangelo)
(Assignee)

Comment 43

3 years ago
(In reply to Andrew Osmond [:aosmond] from comment #41)
> Maybe we should just expose the setting -- turns out turning it on is a bad
> idea as it stands because 1) you see duplicated options in the menu, 2) they
> have bits that would need to be translated (i.e. default, low, high) and 3)
> there is a bug on the title it displays when changing the resolution (i.e.
> Video Resolution undefined).

Err turns out *just* turning it on is a bad idea, hence my pull request being more complicated than it ought to be :).
Oh and about exposing settings, hema told me that a bug is scheduled for the next release which lets you select the resolution.
Flags: needinfo?(npark)
(Assignee)

Comment 45

3 years ago
Created attachment 8681332 [details] [diff] [review]
[gecko] prefer 720p over 1080p as default

Very minor tweak to the gecko config to prefer 720p over 1080p as the default recording resolution.
Can anyone here explain why this is a blocker? The Flame cannot play 1080p video. Period.

Why should we limit the Aries from recording 1080p video just because the Flame can't play it back? That is kind of ridiculous when you think about it. The Flame can't play a random 1080p video found on the web either, so why should we block Aries from recording 1080p?
Flags: needinfo?(npark)
Flags: needinfo?(hkoka)
Flags: needinfo?(aalldredge)
(In reply to Justin D'Arcangelo [:justindarc] from comment #46)
> Can anyone here explain why this is a blocker? The Flame cannot play 1080p
> video. Period.
> 
> Why should we limit the Aries from recording 1080p video just because the
> Flame can't play it back? That is kind of ridiculous when you think about
> it. The Flame can't play a random 1080p video found on the web either, so
> why should we block Aries from recording 1080p?

And actually, it looks like this exact same concern was already raised here by :gerard-majax in Comment 17 through Comment 20. Not sure how this ever reached blocker status. I can semi-agree with the decision to eliminate the UHD/4K recording resolution because support for that is not yet widespread, even on desktops. But, 1080p is supported nearly everywhere, with the exception of Flame because of its under-powered hardware.

IMO, this should not block and for v2.6/v3.0 (whatever it will be), we can look into enabling a user-configurable option in the in-app menu.
(In reply to Justin D'Arcangelo [:justindarc] from comment #47)
> (In reply to Justin D'Arcangelo [:justindarc] from comment #46)
> > Can anyone here explain why this is a blocker? The Flame cannot play 1080p
> > video. Period.
> > 
> > Why should we limit the Aries from recording 1080p video just because the
> > Flame can't play it back? That is kind of ridiculous when you think about
> > it. The Flame can't play a random 1080p video found on the web either, so
> > why should we block Aries from recording 1080p?
> 
> And actually, it looks like this exact same concern was already raised here
> by :gerard-majax in Comment 17 through Comment 20. Not sure how this ever
> reached blocker status. I can semi-agree with the decision to eliminate the
> UHD/4K recording resolution because support for that is not yet widespread,
> even on desktops. But, 1080p is supported nearly everywhere, with the
> exception of Flame because of its under-powered hardware.
> 
> IMO, this should not block and for v2.6/v3.0 (whatever it will be), we can
> look into enabling a user-configurable option in the in-app menu.

+1
(In reply to Justin D'Arcangelo [:justindarc] from comment #46)
> Can anyone here explain why this is a blocker? The Flame cannot play 1080p
> video. Period.
> 
> Why should we limit the Aries from recording 1080p video just because the
> Flame can't play it back? That is kind of ridiculous when you think about
> it. The Flame can't play a random 1080p video found on the web either, so
> why should we block Aries from recording 1080p?

This bug started out with 4K videos not being able to play on Flame. The solution to limit to a lower resolution while the device is capable of recording at higher resolutions is not right to me. Enabling higher resolutions as a user setting this late in the 2.5 cycle is risky based on implementation discussions on this. Hence the decision in the triage was to block on this for removing 4K resolution as a default temporarily for 2.5 because it is not a very commonly supported resolution across devices. This temporary workaround was added by Wilson and reviewed by Justin (see comment 12 and 15).


Coming to the current state of this bug...It looks like this bug was reopened a few times because it seemed like the "removing 4k as default" fix was not working (see comment 31). But that suspicion was removed later on. 

It does not make sense to lower the resolution further down from 1080p as a default because of inability of Flame device. And we definitely *should not* block Aries from recording at 1080p. I would suggest marking this particular new issue -- "unable to play 1080p (previously 4k) videos on Flame"  as wont fix.

And focus our attention to giving user a choice and implementing a UI menu that will list all available resolution options that the device is capable of, in the next release. (I remember we talked about this when we originally implemented these camera features for Madai. But there was push back from folks and instead implement picking the highest resolution that can be recorded on the device automatically. I think we have a bug on this, I will find that and add it to this)

THanks
Hema
Flags: needinfo?(hkoka)
(Assignee)

Updated

3 years ago
Attachment #8680996 - Flags: review?(jdarcangelo)
Here is the bug for post 2.5 for tracking picture and video settings menu implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=844920
Flame does not support 1080p. Marking as won't fix and removing from blocker. Please use meta bug: 844920 for further discussions on implementation of recording profile/picture settings menu and exposing "preferred recording resolution" parameter. 

tHanks!
Status: REOPENED → RESOLVED
blocking-b2g: 2.5+ → -
Last Resolved: 3 years ago3 years ago
Flags: needinfo?(npark)
Flags: needinfo?(aalldredge)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.