Closed Bug 901220 Opened 7 years ago Closed 6 years ago
.264 video playback is not smooth on b2g master
On b2g master, video playback is not smooth. Video playback is almost stopped soon after starting playback.
Sotaro, just to clarify, are you saying that this is a regression from bug 858914, or just that we expect the resolution of gralloc work related to bug 858914 to help us with this bug?
This is a regression of layer refactoring. I am waiting bug 858914 fix, because if it should fix some problem occurred since the layer refactoring.
I tried reproducing this with b2g trunk and the video plays fine: http://people.mozilla.org/~jmuizelaar/AvatarMovieTrailer.mp4 git commit info: 2013-08-02 12:59:25 For some reason my build say Platform Version 22.0a1 but the git commit info looks legit.
Sotaro, which device?
(In reply to Benoit Girard (:BenWa) from comment #3) Tested on the unagi
(In reply to Milan Sreckovic [:milan] from comment #4) > Sotaro, which device? I tested on leo and hamachi. FYI, This week I am at b2g media work week in vancouver.
I also see the same problem on unagi. 1.1 runs at 24 fps or so, master runs at 14fps
Have we tried with videos that are on the SD card as well?
So this may just be discovering the obvious but I see ImageBridge's UpdateImageClientNow taking time alternating between ~50ms and ~78ms which is gives a range of fps of 19 to 12
(In reply to Jeff Muizelaar [:jrmuizel] from comment #9) > So this may just be discovering the obvious but I see ImageBridge's > UpdateImageClientNow > taking time alternating between ~50ms and ~78ms which is gives a range of > fps of 19 to 12 This happening because we do a sync swap and we spend 50-78ms in fEGLImageTargetTexture2D
On B2G 1.1 we don't spend more than 20ms in the same function
Recreating the EGLImage instead of reusing doesn't improve the times.
Here are some of the problems related to this: 1. We don't hold a reference to the Image* while the compositor is compositing it. This causes it to get recycled by the media decoder 2. We don't hold a reference to the Image* that we send to the ImageBridge thread. Instead we hold a reference to the ImageContainer. This means the Image can change before the ImageBridge thread runs.
Another thing that I just noticed is that we get GL_INVALID_OPERATION the first time we try to bind a gralloc video buffer.
This seems to help things be a little bit more sane.
Closed from Bug 902644 comment 12.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.