Closed Bug 1082545 Opened 5 years ago Closed 5 years ago

Momentary pause during seek operation on video playback of Video app

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36
blocking-b2g 2.1+
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- fixed
b2g-v2.1 --- verified
b2g-v2.2 --- fixed

People

(Reporter: poojas, Assigned: bwu)

References

()

Details

(Whiteboard: [caf priority: p2][CR 735038])

Attachments

(6 files, 1 obsolete file)

STR:
1. Open Video app with some videos on sdcard
2. Play any video.
3. Perform seek operation on playback

Actual behavior:
  There is s momentary pause while in video playback while seek operation

Expected Behavior:
  Play back should be smooth with seek operation.

Target details:
Target: QRD 8926 KK build
Gaia and Gecko info:
Gaia "f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1"
Gecko "db7fce920e7d782d9f601384dc95924abcdaeeb8"
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Is this a regression from 2.0? Video would help to make a blocking decision.
Keywords: qawanted
Is this happening with the slider or with the forward/reverse buttons or both? Attaching the video being played would also help.
Flags: needinfo?(poojas)
QA-Wanted can NOT reproduce this issue on 2.1

Video of what I'M seeing is here: http://youtu.be/FL9ovlZPcFU

there is no significant delay / lag when using forward / reverse buttons or manually moving the slider.


Please re-tag if the reporter provides more information that will help with a repro
(Video of Repro, Description of Video being tested (size, file type, codecs, source), Original Video, Build ID, REPRO rate, additional STR, etc.)

Device: Flame 2.1
Build ID: 20141013001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Version: 34.0a2 (2.1)
Firmware Version: V184
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Keywords: qawanted
Whiteboard: [CR 735038] → [caf priority: p2][CR 735038]
No longer depends on: CAF-v2.1-FC-metabug
Flags: needinfo?(poojas)
Attached file Link to test video
Attached file Steps to reproduce
(In reply to Russ Nicoletti [:russn] from comment #3)
> Is this happening with the slider or with the forward/reverse buttons or
> both?
Both
> Attaching the video being played would also help.
Attaching video (same , the one shared by mozilla in its test_media/)
Also attaching video when issue is reproduced. You can see a pause after seek.

Also This pause duration is more for higher resolution clip like for 10Mbps clip pause duration is at-least 1 sec
(In reply to Pooja from comment #6)
> Created attachment 8505318 [details]
> Steps to reproduce
> 
> (In reply to Russ Nicoletti [:russn] from comment #3)
> > Is this happening with the slider or with the forward/reverse buttons or
> > both?
> Both
  Sorry Only with slider and not with forward and reverse button
If this is slider only, it is presumably because we have to set currentTime and can't do an approximate fastseek() like we do for the buttons. IIRC, that elephant's dream sample video is a very weird one that doesn't have many key frames, so accurate seeks take a long time. (If pushing the forward/back buttons causes particularly long skips, then it indicates that the video has long gaps between key frames.)

I'm pretty sure we used that elephant's dream webm video in an earlier bug as an example of a really horribly encoded video and used it to justify using fastseek for the forward and back buttons.  If this bug only appears for that video, then I don't think there is really anything we can do to fix it. And I also think that it isn't very urgent to fix.

Though to prevent this bug from being filed again, we should put a different .webm sample in the test_media/Movies/ directory, and move elephants-dream.webm to test_media/Movies/pathalogical/ along with a README file that explains what is weird about the file and how it can be used for testing.
(In reply to David Flanagan [:djf] from comment #8)
> I'm pretty sure we used that elephant's dream webm video in an earlier bug
> as an example of a really horribly encoded video and used it to justify
> using fastseek for the forward and back buttons.  If this bug only appears
> for that video, then I don't think there is really anything we can do to fix
> it. And I also think that it isn't very urgent to fix.

See https://bugzilla.mozilla.org/show_bug.cgi?id=996398#c28
The most relevant information from the comment I referenced in comment 9 is this:

"So you can see there's no keyframes between 43.168s and 61.853s." (referring to the elephants-dream video).

Therefore, when using the forward/rewind buttons or the time slider while the video position is between 43.168s and 61.853s, there will be a noticeable seeking delay due to the lack of keyframes. This is a known issue with this video.
Russ and David, Thanks for investigating! Removing from blocking nom
blocking-b2g: 2.1? → ---
No longer blocks: CAF-v2.1-FC-metabug
No-Jun,

could you please help try this out with another webm video to make sure this is not an issue there.

Thanks
Hema
Flags: needinfo?(npark)
I checked with a number of webm videos, and one thing i noticed is that when playing a large file, I cannot use the slider to go to the position I want.  

For example, when playing the video in http://www.ioncannon.net/examples/vp8-webm/demo.html (by saving it to the sd card), when I move the slider to 7 minute mark, and resume playing, the video actually plays in the wrong location even though the timer initially displayed 7:00 before playing.  
After a few seconds of pause, it jumps back to the previous position + 10 seconds or so, and resumes playing there.

Is it due to the bad encoding as well?  ni?ing djf for confirmation.  If it's an issue, I'll raise the bug.

Version Info:
Gaia-Rev        1ea74943cfe525c76a074ca1d7de8e51a70f6b98
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/2befa902ff5c
Build-ID        20141017001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141017.050039
FW-Date         Fri Oct 17 05:00:50 EDT 2014
Bootloader      L1TC00011840
Flags: needinfo?(npark) → needinfo?(dflanagan)
(In reply to No-Jun Park [:njpark] from comment #13)

> For example, when playing the video in
> http://www.ioncannon.net/examples/vp8-webm/demo.html (by saving it to the sd
> card), when I move the slider to 7 minute mark, and resume playing, the
> video actually plays in the wrong location even though the timer initially
> displayed 7:00 before playing.  
> After a few seconds of pause, it jumps back to the previous position + 10
> seconds or so, and resumes playing there.
> 
> Is it due to the bad encoding as well?  ni?ing djf for confirmation.  If
> it's an issue, I'll raise the bug.

My guess is it is due to the lack of keyframes (as is the case for elephants-dream.web). Perhaps Chris can share the mkvinfo tool he uses to find the keyframes in a video so we don't have to bother him in these situations :)
Flags: needinfo?(cpearce)
Attachment #8505317 - Attachment mime type: text/plain → video/mp4
Flags: needinfo?(cpearce)
Attachment #8505317 - Attachment mime type: video/mp4 → video/webm
Attachment #8505317 - Attachment description: Test video → Link to test video
Attachment #8505317 - Attachment mime type: video/webm → text/plain
mkvinfo -v $file

On Ubuntu, mkvinfo is in the mkvtoolnix package.
(In reply to No-Jun Park [:njpark] from comment #13)
> I checked with a number of webm videos, and one thing i noticed is that when
> playing a large file, I cannot use the slider to go to the position I want.  
> 
> For example, when playing the video in
> http://www.ioncannon.net/examples/vp8-webm/demo.html (by saving it to the sd
> card), when I move the slider to 7 minute mark, and resume playing, the
> video actually plays in the wrong location even though the timer initially
> displayed 7:00 before playing.  
> After a few seconds of pause, it jumps back to the previous position + 10
> seconds or so, and resumes playing there.
> 

That particular video is at http://www.ioncannon.net/examples/vp8-webm/big_buck_bunny_480p.webm

If I download it to my hard drive and then load it into firefox, it starts playing. But when I try to use the native player controls (in desktop Aurora) to seek, I see "video can't be played because the file is corrupt".  So either this file is bad, or Gecko has broken webm support.

Chris: I think this is a pretty well-known webm demo file. Can you tell if it is actually corrupt, or if we've got a gecko bug?

No-Jun: maybe that file is just corrupt. Are there other webm videos that you had trouble with?


When I try playing that video at that link in desktop firefox, the seek controls do not work at all. But that may just be bad javascript on the ioncannon.net site.  I don't see anyway to download the raw .webm
Flags: needinfo?(npark)
Flags: needinfo?(dflanagan)
Flags: needinfo?(cpearce)
The file contains no Cues, which is the keyframe index. You can tell this because
`mkvinfo -v big_buck_bunny_480p.webm | grep Cues` outputs no data.

We can't seek in WebM files that don't contain a keyframe index. We've had a long standing bug on fixing that, bug 657791, but I can't see us prioritizing that any time soon.

This bug should probably dupe bug 657791, or at least be blocked by it.
Flags: needinfo?(cpearce)
Other files I did not have problem with, but the file I had trouble with play well with mac os x vlc player (it seeks to the correct position when I do seek operation with the slider) so I'm guessing maybe file isn't corrupt?

But I do get the same error on Desktop Aurora, so it *could* be a gecko bug.
Flags: needinfo?(npark)
(In reply to No-Jun Park [:njpark] from comment #18)
> Other files I did not have problem with, but the file I had trouble with
> play well with mac os x vlc player (it seeks to the correct position when I
> do seek operation with the slider) so I'm guessing maybe file isn't corrupt?

The file does not contain the information that we require in order to be able to seek it.

VLC is smart enough to figure out that information when it is not applied. Our code is not.

> But I do get the same error on Desktop Aurora, so it *could* be a gecko bug.

Not being able to seek in files which don't contain this information is a long standing known issue with Gecko.

This is a Gecko bug.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 657791
(In reply to Chris Pearce (:cpearce) from comment #19)
Thanks for the input (I wrote above comment before I saw yours), since the original issue of pause is no longer reproducible, and Comment 17 explains the issue that I'm seeing, (and bug 657791 already tracks it)  I think we can close this issue?


> (In reply to No-Jun Park [:njpark] from comment #18)
> > Other files I did not have problem with, but the file I had trouble with
> > play well with mac os x vlc player (it seeks to the correct position when I
> > do seek operation with the slider) so I'm guessing maybe file isn't corrupt?
> 
> The file does not contain the information that we require in order to be
> able to seek it.
> 
> VLC is smart enough to figure out that information when it is not applied.
> Our code is not.
> 
> > But I do get the same error on Desktop Aurora, so it *could* be a gecko bug.
> 
> Not being able to seek in files which don't contain this information is a
> long standing known issue with Gecko.
> 
> This is a Gecko bug.
> 
> *** This bug has been marked as a duplicate of bug 657791 ***
Changing it to WORKSFORME since the original bug was about the pause during seek IMO.
Resolution: DUPLICATE → WORKSFORME
(In reply to David Flanagan [:djf OOO until Oct. 27] from comment #8)
>  If this bug only appears
> for that video, then I don't think there is really anything we can do to fix
> it. And I also think that it isn't very urgent to fix.
> 


Hi David,
Firstly I am sorry for jumping in so late. Was on leave so could not follow-up on time.

I can see this issue on other formats too like .mp4 . And as i mentioned in my previous comment #6 for high resolution clips this pause duration is very high around 3-4 secs. I will share the video as soon as possible.
I am seeing huge pause while seeking in .mp4 clip (video attached)
But it happens only on some specific points so wanted to double confirm where issue is exactly. Is it on our code or in clip it self?

I am also emailing the exact video on which issue is observed.

Kindly share your opinion.
Status: RESOLVED → REOPENED
Flags: needinfo?(npark)
Flags: needinfo?(dflanagan)
Resolution: WORKSFORME → ---
Flags: needinfo?(hkoka)
HI Pooja, I copied the file you sent me into the SD card using the USB storage method, but the flame video app does not seem to recognize the video file.  Was there anything else that you have to do to play this on device?  Or, can you actually load the video file with the latest v2.1 build?

(In reply to Pooja from comment #23)
> Created attachment 8512546 [details]
> clip on reproduced issue
> 
> I am seeing huge pause while seeking in .mp4 clip (video attached)
> But it happens only on some specific points so wanted to double confirm
> where issue is exactly. Is it on our code or in clip it self?
> 
> I am also emailing the exact video on which issue is observed.
> 
> Kindly share your opinion.

Hi, I copied the .mp4 file into
Flags: needinfo?(npark)
NI poojas for No-jun's comment 24


CC'ing Steven Lee so he in the loop for media playback issue with particular mp4
Flags: needinfo?(hkoka) → needinfo?(poojas)
(In reply to Pooja from comment #22)
> 
> I can see this issue on other formats too like .mp4 . And as i mentioned in
> my previous comment #6 for high resolution clips this pause duration is very
> high around 3-4 secs. I will share the video as soon as possible.

We could switch to using the fastSeek() API, but that would mean that the slider was no longer accurate and wouldn't actually seek to the desired point. 

Would it be enough to display a spinner while the seek was in progress?  Maybe if the seek did not complete within 300ms, then we show a spinner until the seek does complete? IIRC, the video element fires "seeking" and "seeked" events and it might be pretty easy to use those to display the spinner.
Flags: needinfo?(dflanagan)
(In reply to No-Jun Park [:njpark] from comment #24)
> HI Pooja, I copied the file you sent me into the SD card using the USB
> storage method, but the flame video app does not seem to recognize the video
> file. 


I tried on flame with latest  build and got same observation as yours i.e clip doesn't showed up in thumbnail.

In logcat I found below logs .

Error logs:
I/Gecko   ( 9311): Failed to get video size, or it was too large for HW decoder (<w=1920, h=1080> but <maxW=1280, maxH=720>)


E/GeckoConsole( 9311): Content JS ERROR at app://video.gaiamobile.org/js/metadata.js:184 in getMetadata/offscreenVideo.onerror: Can't play video /sdcard/H264_1080p_HP_10Mbps_30fps_AAC.mp4 [object XrayWrapper [object Event]]

In flame the max height and max width is restricted  720 and 1280 respectively  so it can't play the video of higher size .
Could you please check once after modifying the property OR try on 8x26 target.

Reg No cues Element:

Got below output for mkvinfo commands:
$ mkvinfo -v  H264_1080p_HP_10Mbps_30fps_AAC.mp4 | grep Cues
 - No output
$ mkvinfo -v  H264_1080p_HP_10Mbps_30fps_AAC.mp4           
- O/P - (MKVInfo) No EBML head found.

Is there any other way to find out Cues Element?
Flags: needinfo?(poojas) → needinfo?(npark)
(In reply to Pooja from comment #27)
> (In reply to No-Jun Park [:njpark] from comment #24)
> > HI Pooja, I copied the file you sent me into the SD card using the USB
> > storage method, but the flame video app does not seem to recognize the video
> > file. 
> 
> 
> I tried on flame with latest  build and got same observation as yours i.e
> clip doesn't showed up in thumbnail.
> 
> In logcat I found below logs .
> 
> Error logs:
> I/Gecko   ( 9311): Failed to get video size, or it was too large for HW
> decoder (<w=1920, h=1080> but <maxW=1280, maxH=720>)
> 
> 
> E/GeckoConsole( 9311): Content JS ERROR at
> app://video.gaiamobile.org/js/metadata.js:184 in
> getMetadata/offscreenVideo.onerror: Can't play video
> /sdcard/H264_1080p_HP_10Mbps_30fps_AAC.mp4 [object XrayWrapper [object
> Event]]
> 
> In flame the max height and max width is restricted  720 and 1280
> respectively  so it can't play the video of higher size .
> Could you please check once after modifying the property OR try on 8x26
> target.
> 
> Reg No cues Element:
> 
> Got below output for mkvinfo commands:
> $ mkvinfo -v  H264_1080p_HP_10Mbps_30fps_AAC.mp4 | grep Cues
>  - No output
> $ mkvinfo -v  H264_1080p_HP_10Mbps_30fps_AAC.mp4           
> - O/P - (MKVInfo) No EBML head found.
> 
> Is there any other way to find out Cues Element?

I downsampled it to 720p and played it on the flame device. I do see the half second pause as well, and sometime it skips to the point that I did not set the slider to.  I mentioned this in above comment, and according to Comment 19, in case of webm files, it is because it is missing the keyframes.  

I tested other mp4 files, and this does not happen, so I'm thinking this is specific to this video file.

ni?ing cpearce to double check whether bug 657791 applies to mp4 (H264 + TS) files as well.
Flags: needinfo?(npark) → needinfo?(cpearce)
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core
Pooja,

Please see comment #26. If we just display a spinner when seeking is taking a long time is that an acceptable fix for the problem? If so, then we can probably fix this fairly quickly in gaia. If not, we'll have to treat it as a platform issue, I think.
Flags: needinfo?(poojas)
(In reply to No-Jun Park [:njpark] from comment #28)
> ni?ing cpearce to double check whether bug 657791 applies to mp4 (H264 + TS)
> files as well.

All valid MP4 files contain keyframe indexes. bug 657791 does not apply to MP4.
Flags: needinfo?(cpearce)
HI David,

Your suggested way looks good but still do we know why we are seeing this huge pause while seeking?
What is causing it?

Would like to mention here again that this pause varies with clip resolution. SO you might not see same behavior on low resolution clip.

Also for same clip Seek is very smooth in Linux Android device which uses same decoder. Then what is causing this issue on FFOS
Flags: needinfo?(poojas) → needinfo?(dflanagan)
Hi Blake,

Please help this bug. Thanks.
Flags: needinfo?(bwu)
More info for you. 
Flame can only support to play video up to 720P. 

Hi Pooja, 
Could you email me your test content and what FFOS version you are using now, 2.0? 
Thanks!
Flags: needinfo?(bwu) → needinfo?(poojas)
(In reply to Pooja from comment #31)
> HI David,
> 
> Your suggested way looks good but still do we know why we are seeing this
> huge pause while seeking?
> What is causing it?
> 

I've got no idea. I only know the video app at the JavaScript level. It could be that your test video triggers a gecko bug in the seeking code, but I'm completely unqualified to comment on that. cpearce might be able to.

> Would like to mention here again that this pause varies with clip
> resolution. SO you might not see same behavior on low resolution clip.

Right. And since we don't have devices that can play your high resolution clip, we're still not able to reproduce the bug, so we probably can't get gecko engineers to investigate.  If you can find a video sample that plays on the flame and displays the same bug, that would be very helpful.  Also, in the video it appears that you are seeking pretty much at random. I'd like to know if the bug occurs at random or if it occurs predicatably when you seek to some specific location within the video. Also, it might be helpful to know if the same bug appears when you tap the forward and back buttons, or if it only happens when you tap or drag on the slider.

> Also for same clip Seek is very smooth in Linux Android device which uses
> same decoder. Then what is causing this issue on FFOS

I assume that seeking is handled by Gecko, not by the decoder, right?  So maybe Gecko's seek algorithm is different than Android's.

When I try out the video app on the downsampled version of your clip that No-Jun produced, I see fairly quick seek times, occasionally taking .5s or so. But I also see the slider jump when playback resumes, making me think that we've switched the app to use fastSeek() instead of seeking precisely by setting currentTime. I can't remember why we made that change, but maybe if we added a spinner we could switch back to precise seeks. If your video clip is showing a bug in fastSeek then maybe it would go away if we didn't use fastSeek anymore.
Flags: needinfo?(dflanagan)
(In reply to Blake Wu [:bwu][:blakewu] from comment #33)
> More info for you. 
> Flame can only support to play video up to 720P. 
> 
> Hi Pooja, 
> Could you email me your test content and what FFOS version you are using
> now, 2.0? 
> Thanks!
I got the test content from my colleague. But still would like to know which version you use.
(In reply to David Flanagan [:djf] from comment #34)
> (In reply to Pooja from comment #31)
> > HI David,
> > 
> > Your suggested way looks good but still do we know why we are seeing this
> > huge pause while seeking?
> > What is causing it?
> > 
> 
> I've got no idea. I only know the video app at the JavaScript level. It
> could be that your test video triggers a gecko bug in the seeking code, but
> I'm completely unqualified to comment on that. cpearce might be able to.
> 
> > Would like to mention here again that this pause varies with clip
> > resolution. SO you might not see same behavior on low resolution clip.
> 
> Right. And since we don't have devices that can play your high resolution
> clip, we're still not able to reproduce the bug, so we probably can't get
> gecko engineers to investigate.  If you can find a video sample that plays
> on the flame and displays the same bug, that would be very helpful.  Also,
I am trying to get Nexus 5 to have a comparison between Android and FFOS. 
> in the video it appears that you are seeking pretty much at random. I'd like
> to know if the bug occurs at random or if it occurs predicatably when you
> seek to some specific location within the video. Also, it might be helpful
> to know if the same bug appears when you tap the forward and back buttons,
> or if it only happens when you tap or drag on the slider.
> 
> > Also for same clip Seek is very smooth in Linux Android device which uses
> > same decoder. Then what is causing this issue on FFOS
> 
> I assume that seeking is handled by Gecko, not by the decoder, right?  So
> maybe Gecko's seek algorithm is different than Android's.
> 
> When I try out the video app on the downsampled version of your clip that
> No-Jun produced, I see fairly quick seek times, occasionally taking .5s or
> so. But I also see the slider jump when playback resumes, making me think
> that we've switched the app to use fastSeek() instead of seeking precisely
> by setting currentTime. I can't remember why we made that change, but maybe
> if we added a spinner we could switch back to precise seeks. If your video
> clip is showing a bug in fastSeek then maybe it would go away if we didn't
> use fastSeek anymore.
From my understanding about seeking on MP4 file, 
The latest FFOS 2.0 can support fastseek well unless user seeks to the position after the last keyframe. See bug Bug 1059661. 
For FFOS 2.1, fastseek is not always fast (see bug 1022913). I think Pooja should use 2.1 since some of your seekings are fast, but some are not and pause for a while.
HI Blake,

Sorry for being late.
Yes you are correct. I am using V2.1
And some of the fast seek are fast and few are slower.
@David cannot see similar long pause while seeking because he downsampled the clip to 720p. SO here the resolution matters.

Gaia and Gecko we using:
gaia ="c97463d61f45513a2123b19610386ddbfc916819"
gecko ="9d2ff8f6528e1bf1e18252a479e2c3ccf06201df"

And i see  bug 1022913 is resolved for mozilla33 not sure if mozilla33 is for FFOSv2.1?
Flags: needinfo?(poojas)
(In reply to Pooja from comment #37)
> HI Blake,
> 
> Sorry for being late.
> Yes you are correct. I am using V2.1
> And some of the fast seek are fast and few are slower.
> @David cannot see similar long pause while seeking because he downsampled
> the clip to 720p. SO here the resolution matters.
> 
> Gaia and Gecko we using:
> gaia ="c97463d61f45513a2123b19610386ddbfc916819"
> gecko ="9d2ff8f6528e1bf1e18252a479e2c3ccf06201df"
> 
> And i see  bug 1022913 is resolved for mozilla33 not sure if mozilla33 is
> for FFOSv2.1?

Yea, the base gecko for 2.1 is 34 so the patch in bug 1022913 will be in the B2G 2.1 code-base.
(In reply to Blake Wu [:bwu][:blakewu] from comment #36)
> (In reply to David Flanagan [:djf] from comment #34)
> > (In reply to Pooja from comment #31)
> > > HI David,
> > > 
> > > Your suggested way looks good but still do we know why we are seeing this
> > > huge pause while seeking?
> > > What is causing it?
> > > 
> > 
> > I've got no idea. I only know the video app at the JavaScript level. It
> > could be that your test video triggers a gecko bug in the seeking code, but
> > I'm completely unqualified to comment on that. cpearce might be able to.
> > 
> > > Would like to mention here again that this pause varies with clip
> > > resolution. SO you might not see same behavior on low resolution clip.
> > 
> > Right. And since we don't have devices that can play your high resolution
> > clip, we're still not able to reproduce the bug, so we probably can't get
> > gecko engineers to investigate.  If you can find a video sample that plays
> > on the flame and displays the same bug, that would be very helpful.  Also,
> I am trying to get Nexus 5 to have a comparison between Android and FFOS. 
> > in the video it appears that you are seeking pretty much at random. I'd like
> > to know if the bug occurs at random or if it occurs predicatably when you
> > seek to some specific location within the video. Also, it might be helpful
> > to know if the same bug appears when you tap the forward and back buttons,
> > or if it only happens when you tap or drag on the slider.
> > 
> > > Also for same clip Seek is very smooth in Linux Android device which uses
> > > same decoder. Then what is causing this issue on FFOS
> > 
> > I assume that seeking is handled by Gecko, not by the decoder, right?  So
> > maybe Gecko's seek algorithm is different than Android's.
> > 
> > When I try out the video app on the downsampled version of your clip that
> > No-Jun produced, I see fairly quick seek times, occasionally taking .5s or
> > so. But I also see the slider jump when playback resumes, making me think
> > that we've switched the app to use fastSeek() instead of seeking precisely
> > by setting currentTime. I can't remember why we made that change, but maybe
> > if we added a spinner we could switch back to precise seeks. If your video
> > clip is showing a bug in fastSeek then maybe it would go away if we didn't
> > use fastSeek anymore.
> From my understanding about seeking on MP4 file, 
> The latest FFOS 2.0 can support fastseek well unless user seeks to the
> position after the last keyframe. See bug Bug 1059661. 
> For FFOS 2.1, fastseek is not always fast (see bug 1022913). I think Pooja
> should use 2.1 since some of your seekings are fast, but some are not and
> pause for a while.

Blake, CAF is using the latest 2.1 which includes patch in 1022913. Given we do not have devices what are our alternatives here, waiting to see if you can reproduce this on Nexus 5. If you have any speculative patches here, feel free to NI CAF to try these out as we do not have the devices and they may be able to provide feedback faster. Since CAF is using 8x26(1080p) which is the shipping device for Madai, this is a functional blocker for them.
blocking-b2g: --- → 2.1+
I think patches in Bug 1059661 attachment 8505358 [details] [diff] [review] and attachment 8509330 [details] [diff] [review] should fix the problem.
Hi Pooja,
As bhavana mentioned in comment 39, could you help test if those patches can fix the problem  or not?
Thanks!
Flags: needinfo?(poojas)
Sure Blake. Will update asap.
Assign Blake to follow up.
Assignee: nobody → bwu
HI Blake,
Cannot apply changes mentioned in comment #40.
Those changes are for v2.0.
I tried to made changes locally but found that "FindStartTime" is removed from MediaDecoderStateMachine.cpp

Can we please have same changes for v2.1
Flags: needinfo?(poojas) → needinfo?(bwu)
Merge the patches from bug 1059661 to 2.1 code base.
Flags: needinfo?(bwu)
(In reply to Pooja from comment #43)
> HI Blake,
> Cannot apply changes mentioned in comment #40.
> Those changes are for v2.0.
> I tried to made changes locally but found that "FindStartTime" is removed
> from MediaDecoderStateMachine.cpp
> 
> Can we please have same changes for v2.1
Yes. Please help test with attachment 8517893 [details] [diff] [review].
Thanks!
Flags: needinfo?(poojas)
Hi Blake,
Fix worked.  Seek is smooth and we don't see any pause while seeking.
Flags: needinfo?(poojas)
Comment on attachment 8517893 [details] [diff] [review]
0001-Bug-1082545-Make-fastSeek-always-fast-except-the-see.patch

Hi Sotaro, 
This patch is the merge of bug 1059661's patches related to OmxDecoder to v2.1 code base.  
May need your review again.
Attachment #8517893 - Flags: review?(sotaro.ikeda.g)
Attachment #8517893 - Flags: review?(sotaro.ikeda.g) → review+
Carry r+ from sotaro.
Attachment #8517893 - Attachment is obsolete: true
Attachment #8518611 - Flags: review+
Comment on attachment 8518611 [details] [diff] [review]
mozilla‑b2g34-Bug-1082545-Make-fastSeek-always-fast.patch

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
Bug 778077 and Bug 1022913
User impact if declined:
A functional blocker to partner as comment 39.
Testing completed: 
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=b8293b6226a1
Risk to taking this patch (and alternatives if risky): 
Low. It just changed the behavior of seek according to WHATWG spec. 
String or UUID changes made by this patch:
None
Attachment #8518611 - Flags: approval-mozilla-b2g34?
ni Bhavana for approving patch.
Flags: needinfo?(bbajaj)
BLake, can you please help land this on inbound first?
Flags: needinfo?(bbajaj) → needinfo?(bwu)
Attachment #8518611 - Attachment description: Checkin-Bug-1082545-Make-fastSeek-always-fast.patch → mozilla‑b2g34-Bug-1082545-Make-fastSeek-always-fast.patch
Flags: needinfo?(bwu)
https://hg.mozilla.org/mozilla-central/rev/74d6705fe4e7
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Attachment #8518611 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
The issue still repros on 2.2 and 2.1 Flame

A few second pause while video playback seek operation

"Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141114040205
Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f
Gecko: bbb68df450c2
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0"

"Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141114001204
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 551326425826
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0"
QA Whiteboard: [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Attached video VIDEO0057.mp4
This issue has been successfully verified on Flame 2.1:
Gaia-Rev        1b231b87aad384842dfc79614b2a9ca68a4b4ff3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/95fbd7635152
Build-ID        20141119001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2
You need to log in before you can comment on or make changes to this bug.