Closed Bug 919596 Opened 11 years ago Closed 11 years ago

Duration of mp4 is not correct

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking-b2g:koi+)

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-b2g koi+

People

(Reporter: sotaro, Assigned: sotaro)

References

Details

(Keywords: regression, Whiteboard: [JIRA:1842])

H.264 video seek during video playback failed when user chooses the seek time to ab un-cached time. It happens almost all cases. Confirmed on master/v1.2 hamachi/nexus-4. It seems to happen any Http H.264 videos. Confirmed by using youtube's videos. http://www.youtube.com/ Prerequisite: Bug 911548.
blocking-b2g: --- → koi?
When seek failed, video ui return back to "playback stopped" state.
Is this a hardware decoder issue or a core video/audio issue?
Keywords: regression, regressionwindow-wanted
My current assumption is network or MediaCache related issues, not hw decoder issuse.
Assignee: nobody → sotaro.ikeda.g
QA Contact: laliaga
We are seeing this issue while playing clips from sdcard as well with a 3gp clip This seems to be a regression, wasn't seen in earlier builds
Blocks: 916996
Blocks:916996
blocking-b2g: koi? → koi+
The seek issue first started occurring when videos stopped playing in the video player and started playing in-browser (although not 100% repro, closer to 1/3). The change from video player to in-browser occurred from 7/10 1.2 build to 7/11 1.2 build. - 7/10 Last working build - Device: Buri 1.2 MozBuild Build ID: 20130710030203 Gecko: http://hg.mozilla.org/mozilla-central/rev/04d8c309fe72 Gaia: e7bd3d48fbbeb1d072b16b16cbb63edea47b0c73 Platform Version: 25.0a1 - 7/11 Issue first appeared - Device: Buri 1.2 MozBuild Build ID: 20130711030202 Gecko: http://hg.mozilla.org/mozilla-central/rev/dde4dcd6fa46 Gaia: fd0d621e8c1cfbc9afc9af317edb8bb03dc77ed5 Platform Version: 25.0a1
Keywords: regressionwindow-wanted
Whiteboard: [JIRA:1842]
Severity: normal → critical
Today's master hamachi seems not have this problem. Always succeeded to seek to uncached time. - gecko: e55ebbb92007b838189d067ca398a8f81c5a1436
By debugging the bug, the following things became clear. - H.264 video's duration became incorrect. Typically the duration became longer. - When user try to seek to uncached time, it try to seek to out of video duration.
By applying the patch in Bug 922334 on v1.2 hamachi, the problem was fixed.
In v1.2, mozill::MP3FrameParser is still try to calculate a video's duration even when it is not mp3 file. That update the duration incorrectly.
Depends on: 922334
This bug seems already fixed by Bug 922334. Confirmed today's v1.2 hamachi and v1.2 nexus-4.
Keywords: qawanted
Waiting for a working central (1.3) Buri build to test that. Last working 1.3 build that passed the BVT was 10/4 (before the fix was in place). Latest aurora 1.2 Buri still has seeking problems. When it does seek ahead successfully, the video is frozen but the audio still plays. - Buri Aurora 10/7 1.2 - Gaia 85c4af3f48a91878d565f518ba0eed68f0628e21 SourceStamp f067799dff06 BuildID 20131007004003 Version 26.0a2
(In reply to Lucas A. from comment #13) > Waiting for a working central (1.3) Buri build to test that. Last working > 1.3 build that passed the BVT was 10/4 (before the fix was in place). Latest > aurora 1.2 Buri still has seeking problems. When it does seek ahead > successfully, the video is frozen but the audio still plays. This bug is about seek failure. If it happens, the playback end. 'video free' is a different problem.
(In reply to Sotaro Ikeda [:sotaro] from comment #14) > (In reply to Lucas A. from comment #13) > > Waiting for a working central (1.3) Buri build to test that. Last working > > 1.3 build that passed the BVT was 10/4 (before the fix was in place). Latest > > aurora 1.2 Buri still has seeking problems. When it does seek ahead > > successfully, the video is frozen but the audio still plays. > > This bug is about seek failure. If it happens, the playback end. 'video > free' is a different problem. It does fail to seek about 2/5 times on Buri. When it does succeed, that's when video freezing happens and the audio plays. Sorry for the confusion.
we have been reported another one, looks like a similar one Steps: 1.Play a video. 2.long press of home key. 3.window will pop-up 4.Try resuming the video from that window ,observe that the video doesn't play or sometimes only audio is heard this issue should be seen after trying 1/2 times Can we make sure to check this behavior as well
(In reply to bhargavg1 from comment #16) > we have been reported another one, looks like a similar one > > Steps: > 1.Play a video. > 2.long press of home key. > 3.window will pop-up I never saw such kind of window. Which kind of window popped up? And it seems definitely different from this bug. Can you create another bug for it?
Flags: needinfo?(bhargavg1)
This bug is about seek failure regression caused by mp3 parser implementation. Another seek related bug should be handled as a different bug.
(In reply to Sotaro Ikeda [:sotaro] from comment #17) > (In reply to bhargavg1 from comment #16) > > we have been reported another one, looks like a similar one > > > > Steps: > > 1.Play a video. > > 2.long press of home key. > > 3.window will pop-up > > I never saw such kind of window. Which kind of window popped up? And it > seems definitely different from this bug. Can you create another bug for it? Will raise a separate CR describing steps
Flags: needinfo?(bhargavg1)
Update the summary to make clear about the bug. The seek failure is just a side effect of it.
Summary: H.264 video seek failure during video playback → Duration of mp4 is not correct
(In reply to Lucas A. from comment #15) > > This bug is about seek failure. If it happens, the playback end. 'video > > free' is a different problem. > > It does fail to seek about 2/5 times on Buri. When it does succeed, that's > when video freezing happens and the audio plays. Sorry for the confusion. Lucas, can you create another bug for it? This bug need to be closed. As in Comment 20, this bug is not a bug for handling the general seek failure, but handling incorrect mp4 duration.
Flags: needinfo?(laliaga)
Sotaro, I still see that mp4 clips fail to seek correctly
(In reply to bhargavg1 from comment #22) > Sotaro, I still see that mp4 clips fail to seek correctly bhargavg1, is it happen because of incorrect mp4 duration? If it is not can you create another bug for it?
Flags: needinfo?(bhargavg1)
Sotaro, The issue of general seek failure now seems fixed (as you mentioned in comment 12) on latest 10/10 Buri aurora 1.2 build. I'll keep an eye out if it occurs again, but no need for a new bug anymore. - Doesn't occur on latest 1.2 - Gaia 51f3c79ea93bb91d3b12e50b49d203a049a94a9b SourceStamp 3f16dc100b1f BuildID 20131010004001 Version 26.0a2
Flags: needinfo?(laliaga)
I'll wait for bhargavg1's comment before closing this out.
Keywords: qawanted
following up on bug 925381
Flags: needinfo?(bhargavg1)
Okay, closing this out then.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
As a side effect of this change/Bug 922334 some times see a crash with the following clip, while starting up music app https://docs.google.com/file/d/0B0zTAnPOpx-xR0J0N1d3dDNmV0E/edit?usp=sharing The crash doesn't happen always, only happens when we try to enumerate the DB for the first time. Can we have a quick check on this Sotaro if you confirm the behavior shall re-open this
Flags: needinfo?(sotaro.ikeda.g)
Crash was noticed in the following build, Gaia: 9e21b6bea92fdafcb6787120a8cde0eb25a50495 Gecko: 2476b6aaae1047642646ba5c442b2aa9fd18bf8f
Following it through bug 927242
Flags: needinfo?(sotaro.ikeda.g)
Blocks: 927884
You need to log in before you can comment on or make changes to this bug.