Pooja Reporter
	Description • 10 years ago

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"

	Pooja Reporter
	Comment 1 • 10 years ago

[Blocking Requested - why for this release]:

	Hema Koka [:hema]
	Comment 2 • 10 years ago

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

	Russ Nicoletti [:russn]
	Comment 3 • 10 years ago

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

	Joshua Mitchell (Inactive)
	Comment 4 • 10 years ago

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

	Pooja Reporter
	Comment 6 • 10 years ago

(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

	Pooja Reporter
	Comment 7 • 10 years ago

(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

	David Flanagan [:djf]
	Comment 8 • 10 years ago

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.

	Russ Nicoletti [:russn]
	Comment 9 • 10 years ago

(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

	Russ Nicoletti [:russn]
	Comment 10 • 10 years ago

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.

	Hema Koka [:hema]
	Comment 11 • 10 years ago

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

	Hema Koka [:hema]
	Comment 12 • 10 years ago

No-Jun,

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

Thanks
Hema

	No-Jun Park [:njpark]
	Comment 13 • 10 years ago

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

	Russ Nicoletti [:russn]
	Comment 14 • 10 years ago

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

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 15 • 10 years ago

mkvinfo -v $file

On Ubuntu, mkvinfo is in the mkvtoolnix package.

	David Flanagan [:djf]
	Comment 16 • 10 years ago

(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

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 17 • 10 years ago

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.

	No-Jun Park [:njpark]
	Comment 18 • 10 years ago

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.

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 19 • 10 years ago

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

	No-Jun Park [:njpark]
	Comment 20 • 10 years ago

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

	No-Jun Park [:njpark]
	Comment 21 • 10 years ago

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

	Pooja Reporter
	Comment 22 • 10 years ago

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

	Pooja Reporter
	Comment 23 • 10 years ago

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.

	No-Jun Park [:njpark]
	Comment 24 • 10 years ago

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

	Hema Koka [:hema]
	Comment 25 • 10 years ago

NI poojas for No-jun's comment 24


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

	David Flanagan [:djf]
	Comment 26 • 10 years ago

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

	Pooja Reporter
	Comment 27 • 10 years ago

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

	No-Jun Park [:njpark]
	Comment 28 • 10 years ago

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

	David Flanagan [:djf]
	Comment 29 • 10 years ago

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.

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 30 • 10 years ago

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

	Pooja Reporter
	Comment 31 • 10 years ago

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

	StevenLee[:slee]
	Comment 32 • 10 years ago

Hi Blake,

Please help this bug. Thanks.

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 33 • 10 years ago

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!

	David Flanagan [:djf]
	Comment 34 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 35 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 36 • 10 years ago

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

	Pooja Reporter
	Comment 37 • 10 years ago

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?

	bhavana bajaj [:bajaj]
	Comment 38 • 10 years ago

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

	bhavana bajaj [:bajaj]
	Comment 39 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 40 • 10 years ago

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!

	Pooja Reporter
	Comment 41 • 10 years ago

Sure Blake. Will update asap.

	Bobby Chien
	Comment 42 • 10 years ago

Assign Blake to follow up.

	Pooja Reporter
	Comment 43 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 44 • 10 years ago

Merge the patches from bug 1059661 to 2.1 code base.

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 45 • 10 years ago

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

	Pooja Reporter
	Comment 46 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 47 • 10 years ago

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.

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 48 • 10 years ago

Carry r+ from sotaro.

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 49 • 10 years ago

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

	Bobby Chien
	Comment 50 • 10 years ago

ni Bhavana for approving patch.

	bhavana bajaj [:bajaj]
	Comment 51 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 52 • 10 years ago

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

	Blake Wu [:bwu][:blakewu] Assignee
	Comment 53 • 10 years ago

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

	Ryan VanderMeulen [:RyanVM]
	Comment 54 • 10 years ago

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

	Carsten Book [:Tomcat]
	Comment 55 • 10 years ago

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

	Ryan VanderMeulen [:RyanVM]
	Comment 56 • 10 years ago

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

	sarsenyev
	Comment 57 • 10 years ago

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"

	Elie
	Comment 58 • 10 years ago

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