Implement off-main-thread video compositing protocol

RESOLVED DUPLICATE of bug 598868

Status

()

Core
Graphics
--
enhancement
RESOLVED DUPLICATE of bug 598868
6 years ago
4 years ago

People

(Reporter: nical, Assigned: nical)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

6 years ago
Videos are decoded in separate threads. We want to have these decoding threads directly push video frames to the compositor thread/process without using the main thread, so as to avoid laggy video playback when the main thread is too busy with content script.
(Assignee)

Comment 1

6 years ago
I am starting to implement this. 
Since there is going to be new classes and files, I start explaining what's going so that people can give me early feedbacks on the stuff I might be doing wrong from the start (especially naming, folder hierarchy and so on).

So, I am adding a new protocol mozilla::media::PVideoCompositing, that I have placed in content/media/ipc
this protocol has two 'functions' so far: 
on one side (child):
 - RenderVideoFrame
on the other side (parent):
 - DoneRenderingVideoFrame

This small protocol aims at -when omtc is on- replacing the small bit happening in nsBuiltinDecoderStateMachine::RenderVideoFrame (http://dxr.lanedo.com/mozilla-central/content/media/nsBuiltinDecoderStateMachine.cpp.html#l1871) so that the decoding thread pushes frames directly to the compositing thread through ipdl (instead of touching the main thread's VideoFrameContainer.

RenderVideoFrame tells the compositor thread which shared video frame to use (using an id or a pointer or some other kind of reference, I haven't looked at it yet).
DoneRenderingVideoFrame tells the decoding thread that this frame is not useful to the compsoiting thread anymore (most likely when the compositing thread is using the next frame) so that the decoding thread can do whatever it wants with it (like reuse it for a future frame I guess).

I am not yet very familiar with the directory structure, naming and namespacing poilices, etc. so please let me know if this is staring in the wrong direction (or wrong place).
See also bug 598868, and later bug 706172.  Don't have time to chat now but would love to catch up in the near future.
I think this should be done in bug 598868. We already have some work there.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 598868
(Assignee)

Comment 4

6 years ago
> See also bug 598868, and later bug 706172.  
Aw, sorry for the duplicate, I'll use bug 598868 from now on.

> Don't have time to chat now but
> would love to catch up in the near future.
Awesome! you can ping me on irc (nical) or send me an email whenever you have time for it. I'm new here so I definitely can use a little chat to catch up on how things work with video, etc.
Furthermore I see from bug 598868 that romaxa has already done some work there and approached the problem very differently. It looks like I was not going in the right direction.
No longer depends on: 722012
Depends on: 722012
You need to log in before you can comment on or make changes to this bug.