Closed Bug 1169840 Opened 9 years ago Closed 9 years ago

[Aries][Video] Video preview does not appear for 3-10 seconds depending on the length of the video

Categories

(Firefox OS Graveyard :: Gaia::Camera, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-master affected)

RESOLVED INVALID
Tracking Status
b2g-master --- affected

People

(Reporter: dharris, Unassigned)

References

()

Details

(Whiteboard: [3.0-Daily-Testing][spark])

Attachments

(2 files)

Attached file Video Logcat
Description:
The video preview icon takes a long tiem to update. The length it takes to update seems to depend on how long the video is


Repro Steps:
1) Update a Xperia Z3 Compact (B2G) to 20150528210322
2) Open Camera app
3) Switch to video mode
4) Record a video then watch the preview icon next to the capture button


Actual:
THe preview takes around 3-10 seconds to update, depending on the length of the video


Expected:
The video preview takes around 500 miliseconds to update


Environmental Variables:
Device: Xperia Z3 Compact (B2G) 3.0
Build ID: 20150528210322
Gaia: 18f7c340f970991a10c288310bbfd4d105a1430c
Gecko: b7aed25b94251ea192021885323f15e87fc39321
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: 6/10
See attached: Logcat, Video - https://youtu.be/Za-QGsi7ga4
This issue does NOT occur on Flame 3.0

The video preview takes around 500 miliseconds to update no matter what the video lngth is. (tested with a 15 min video)

Environmental Variables:
Device: Flame 3.0 ()()()
Build ID: 20150529010201
Gaia: e7d268074ee3c9eeb191c2205c0e35992fb3915d
Gecko: f986e55c4e0b
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
minor performance regression.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Not-so-minor Performance regression from Flame

My mistake, I thought the second example in the video was immediate, I see now that it was the previous preview and it takes a very long time to update with the expected preview.
blocking-b2g: --- → spark?
Which SD card was the video put on? Was it on the internal or external SD card?

This might be related to bug 1170244.
Keywords: qawanted
When using the SD Card this issue occurs but when i use the internal storage option, the preview shows up almost instantly. It looks like 1170244 is a dupe of this issue.
Keywords: qawanted
Flags: needinfo?(drs)
Dave, this seems strange based on your explanation of UMS vs. MTP earlier. What's your assessment here?
Flags: needinfo?(drs) → needinfo?(dhylands)
I don't see how UMS or MTP are even relevant in this particular issue.

To summarize: when storing the video on the internal sdcard the preview generation is fast. WHen storing the video on the external sdcard, the preview generatiom is slow.

I think this just means that reading/writing to the external sdcard is much slower than reading/writing to internal sdcard.

The preview is generated by reading the video and grabbing a frame, and the preview image is stored in the same place as the video.
Flags: needinfo?(dhylands)
Is this issue occurring when playing a video off the internal storage or an external SD card? If it was an external SD card, what speed/class was your card?

Also, is this issue occurring with hosted content as well?
Keywords: qawanted
On today's build, the issue is only reproducible using external SD card. The problem is not 'playing a video' per se, it's that it takes a long time for it to create the little preview screenshot (see original STR or video demonstrating the issue) after recording a vieo in Camera app.

It took ~29 seconds for the app to create a preview for a 1 minute video. The SD card we used is a class 4 SD card (see attached photo).

Not sure what hosted content you want us to test. I tested Cut The Rope and it seems to run without issue. Tried to run Candy Crush but the screen resolution isn't even right on Aries.

Also, don't know if it's related, but if I go to Settings > Media Storage, and attempt to change Default Media Location, aside from internal storage, the dialog also gives me two SD Card options, but the device only supports one external SD Card so I don't know what's going on there. I chose the first SD Card option for external SD card testing.

Tested on:
Device: Aries
BuildID: 20150611131651
Gaia: 68269e7b6510930eb2f644f69d27d456c1bdec75
Gecko: 9ebd530c5843
Gonk: 75c7e6ca80d0c7a53f346ecfcde2343be95808c9
Version: 41.0a1 (3.0 Master) 
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Bug 1164200 may help alleviate this condition due to changing how the poster creation works, i.e. it is more or less instant loading for me on flame now rather than taking a period of time correlated with the video size. We should retest after that lands.
See Also: → 1164200
blocking-b2g: spark? → 2.5?
Putting qawanted to verify once Bug 1164200 lands
Depends on: 1164200
No longer depends on: 1164200
Depends on: 1164200
Keywords: qawanted
Changes in bug 1164200 seems to have made no change for this bug. I recorded a 60-second-video, and it took ~30 seconds to create the preview image, the same as comment 9 result. Same SD card was used as comment 9 as well.

Tested on:
Device: Aries (RC4 > OTA'ed to dogfood-latest)
BuildID: 20150730145424
Gaia: 1d3595836bd55b70478923d771051268a5dabf91
Gecko: 305ba37a62f8
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5 Master) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
(In reply to Pi Wei Cheng [:piwei] from comment #12)
> Changes in bug 1164200 seems to have made no change for this bug. I recorded
> a 60-second-video, and it took ~30 seconds to create the preview image, the
> same as comment 9 result. Same SD card was used as comment 9 as well.
> 
> Tested on:
> Device: Aries (RC4 > OTA'ed to dogfood-latest)
> BuildID: 20150730145424
> Gaia: 1d3595836bd55b70478923d771051268a5dabf91
> Gecko: 305ba37a62f8
> Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
> Version: 42.0a1 (2.5 Master) 
> Firmware Version: D5803_23.1.A.1.28_NCB.ftf
> User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

That Gaia version doesn't contain my change.
I wasn't aware that bug 1164200 has just landed today since qawanted was tagged on 7/22. Adding qawanted to retest on next nightly.
QA Whiteboard: [QAnalyst-Triage?]
Keywords: qawanted
Flags: needinfo?(ktucker)
On the latest Aries build the preview does show up immediately, but the phone now takes progressively longer to actually stop recording (pressing stop at 30 seconds takes around 7 seconds to stop, pressing stop at 60 took as long as 20 to stop).  This delayed stop does NOT occur on Flame.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150731163020
Gaia: 8502d07cd7e68da79303471acf64eea48b3dce24
Gecko: ca53d4297f02
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20150731030207
Gaia: 8502d07cd7e68da79303471acf64eea48b3dce24
Gecko: ca53d4297f02
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
Doug is the issue we are seeing in Comment 15 most likely bug 1170244 or do we need to write up a new separate issue?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(drs)
The poster creation was changed to the beginning which is why its faster. I think comment 15 and the earlir probem are caused by the external sd card being too slow.

I'd recommend trying a class 10 card and seeing how that performs.

My guess is that he delays we're seeing are just the delays caused by writingin out the fil system caches to the slow sd card.
Please re-test using guidance in comment 17 and post results. thanks!
Keywords: qawanted
This issue or the issue described at comment 15 does NOT occur for a class 10 sd card. Video stops recording immediately when tapping to stop and preview is generated immediately. Tested twice with recording a 60 seconds video.

Device: Aries 2.5
BuildID: 20150826051728
Gaia: c1ae9f02f2a9cfb89bf67aeea97e467c41c3362c
Gecko: f61c3cc0eb8b7533818e7379ccc063b611015d9d
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
Per above comment, closing this bug, since it seems like the limitation of the sd card caused the bug
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
Flags: needinfo?(drs)
blocking-b2g: 2.5? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: