Created attachment 8613142 [details] 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
minor performance regression.
[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.
Which SD card was the video put on? Was it on the internal or external SD card? This might be related to bug 1170244.
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.
Dave, this seems strange based on your explanation of UMS vs. MTP earlier. What's your assessment here?
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.
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?
Created attachment 8621171 [details] Photo of SD card that we use 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
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.
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
(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.
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
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?
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!
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
Per above comment, closing this bug, since it seems like the limitation of the sd card caused the bug