Closed
Bug 901220
Opened 11 years ago
Closed 11 years ago
H.264 video playback is not smooth on b2g master
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: sotaro, Assigned: sotaro)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
On b2g master, video playback is not smooth. Video playback is almost stopped soon after starting playback.
Assignee | ||
Updated•11 years ago
|
blocking-b2g: --- → koi?
Comment 1•11 years ago
|
||
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?
Assignee | ||
Comment 2•11 years ago
|
||
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.
Comment 3•11 years ago
|
||
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.
Comment 5•11 years ago
|
||
(In reply to Benoit Girard (:BenWa) from comment #3)
Tested on the unagi
Assignee | ||
Comment 6•11 years ago
|
||
(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.
Flags: needinfo?(sotaro.ikeda.g)
Comment 7•11 years ago
|
||
I also see the same problem on unagi. 1.1 runs at 24 fps or so, master runs at 14fps
Comment 8•11 years ago
|
||
Have we tried with videos that are on the SD card as well?
Comment 9•11 years ago
|
||
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
Comment 10•11 years ago
|
||
(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
Comment 11•11 years ago
|
||
On B2G 1.1 we don't spend more than 20ms in the same function
Comment 12•11 years ago
|
||
Recreating the EGLImage instead of reusing doesn't improve the times.
Comment 13•11 years ago
|
||
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.
Comment 14•11 years ago
|
||
Another thing that I just noticed is that we get GL_INVALID_OPERATION the first time we try to bind a gralloc video buffer.
Comment 15•11 years ago
|
||
This seems to help things be a little bit more sane.
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → sotaro.ikeda.g
Assignee | ||
Comment 17•11 years ago
|
||
Closed from Bug 902644 comment 12.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Updated•11 years ago
|
blocking-b2g: koi? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•