1082545 - Momentary pause during seek operation on video playback of Video app

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Pooja]

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"

Comment 1

[Pooja]

[Blocking Requested - why for this release]:

Comment 2

[Hema Koka [:hema]]

Is this a regression from 2.0? Video would help to make a blocking decision.

Comment 3

[Russ Nicoletti [:russn]]

Is this happening with the slider or with the forward/reverse buttons or both? Attaching the video being played would also help.

Comment 4

[Joshua Mitchell (Inactive)]

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

Comment 5

[Pooja]

Attachment: Link to test video

Comment 6

[Pooja]

Attachment: 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

Comment 7

[Pooja]

(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

Comment 8

[David Flanagan [:djf]]

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.

Comment 9

[Russ Nicoletti [:russn]]

(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

Comment 10

[Russ Nicoletti [:russn]]

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.

Comment 11

[Hema Koka [:hema]]

Russ and David, Thanks for investigating! Removing from blocking nom

Comment 12

[Hema Koka [:hema]]

No-Jun,

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

Thanks
Hema

Comment 13

[No-Jun Park [:njpark]]

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

Comment 14

[Russ Nicoletti [:russn]]

(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 :)

Comment 15

[Chris Pearce [:cpearce (Not reading bugmail)]]

mkvinfo -v $file

On Ubuntu, mkvinfo is in the mkvtoolnix package.

Comment 16

[David Flanagan [:djf]]

(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

Comment 17

[Chris Pearce [:cpearce (Not reading bugmail)]]

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.

Comment 18

[No-Jun Park [:njpark]]

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.

Comment 19

[Chris Pearce [:cpearce (Not reading bugmail)]]

(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.

Comment 20

[No-Jun Park [:njpark]]

(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 ***

Comment 21

[No-Jun Park [:njpark]]

Changing it to WORKSFORME since the original bug was about the pause during seek IMO.

Comment 22

[Pooja]

(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.

Comment 23

[Pooja]

Attachment: 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.

Comment 24

[No-Jun Park [:njpark]]

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

Comment 25

[Hema Koka [:hema]]

NI poojas for No-jun's comment 24


CC'ing Steven Lee so he in the loop for media playback issue with particular mp4

Comment 26

[David Flanagan [:djf]]

(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.

Comment 27

[Pooja]

(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?

Comment 28

[No-Jun Park [:njpark]]

(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.

Comment 29

[David Flanagan [:djf]]

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.

Comment 30

[Chris Pearce [:cpearce (Not reading bugmail)]]

(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.

Comment 31

[Pooja]

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

Comment 32

[StevenLee[:slee]]

Hi Blake,

Please help this bug. Thanks.

Comment 33

[Blake Wu [:bwu][:blakewu]]

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!

Comment 34

[David Flanagan [:djf]]

(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.

Comment 35

[Blake Wu [:bwu][:blakewu]]

(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.

Comment 36

[Blake Wu [:bwu][:blakewu]]

(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.

Comment 37

[Pooja]

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?

Comment 38

[bhavana bajaj [:bajaj]]

(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.

Comment 39

[bhavana bajaj [:bajaj]]

(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.

Comment 40

[Blake Wu [:bwu][:blakewu]]

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!

Comment 41

[Pooja]

Sure Blake. Will update asap.

Comment 42

[Bobby Chien]

Assign Blake to follow up.

Comment 43

[Pooja]

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

Comment 44

[Blake Wu [:bwu][:blakewu]]

Attachment: 0001-Bug-1082545-Make-fastSeek-always-fast-except-the-see.patch

Merge the patches from bug 1059661 to 2.1 code base.

Comment 45

[Blake Wu [:bwu][:blakewu]]

(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!

Comment 46

[Pooja]

Hi Blake,
Fix worked.  Seek is smooth and we don't see any pause while seeking.

Comment 47

[Blake Wu [:bwu][:blakewu]]

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.

Comment 48

[Blake Wu [:bwu][:blakewu]]

Attachment: mozilla‑b2g34-Bug-1082545-Make-fastSeek-always-fast.patch

Carry r+ from sotaro.

Comment 49

[Blake Wu [:bwu][:blakewu]]

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

Comment 50

[Bobby Chien]

ni Bhavana for approving patch.

Comment 51

[bhavana bajaj [:bajaj]]

BLake, can you please help land this on inbound first?

Comment 52

[Blake Wu [:bwu][:blakewu]]

Attachment: Master-Bug-1082545-Make-fastSeek-always-fast.patch

Rebase attachment 8518611 [details] [diff] [review] to master branch

Comment 53

[Blake Wu [:bwu][:blakewu]]

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a9e478c2a5ca 
Testing results looks good. 
Please help check in attachment 8519688 [details] [diff] [review]. 
Thanks!

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/74d6705fe4e7

Comment 55

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/74d6705fe4e7

Comment 56

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a36258ea8ffc

Comment 57

[sarsenyev]

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"

Comment 58

[Elie]

Attachment: 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