Skip to content

Video Capture (webcam): [HACK] do synch frame notifications#19

Open
dscherba wants to merge 1 commit into
developfrom
2015-10-08-david.scherba-fix-webcam-capture-quasi-leak
Open

Video Capture (webcam): [HACK] do synch frame notifications#19
dscherba wants to merge 1 commit into
developfrom
2015-10-08-david.scherba-fix-webcam-capture-quasi-leak

Conversation

@dscherba

@dscherba dscherba commented Oct 8, 2015

Copy link
Copy Markdown
Contributor
  • Recent change moved webcam video capture to asynchronous
    signals towards upper layers
  • But some upper layers (e.g. P4C) have heavyweight handlers
    • Heavyweight enough to not service the thread message queue
    • ... which can create a pileup of video frames

- Recent change moved webcam video capture to asynchronous
  signals towards upper layers
- But some upper layers (e.g. P4C) have heavyweight handlers
   - Heavyweight enough to not service the thread message queue
   - ... which can create a pileup of video frames
@dscherba

dscherba commented Oct 8, 2015

Copy link
Copy Markdown
Contributor Author

//cc: @digitalmouse12 ( @willkelleher if he's still looking), @DinhNguyenCat

This sort of reverts timing to what webrtc would do. The issue with the asynchronous implementation is that if you have a slow network, or similar, our video encoding can slow down enough to not service the video frame queue quickly enough. This looks like a really bad (and unsurvivable) memory leak.

@willkelleher

Copy link
Copy Markdown

So is the "OnEncoded" handler blocking for too long when the network is slow, causing the encoder to slow down the capture handler thread, thereby building up a huge queue of frames that can't be handled?

@dscherba

dscherba commented Oct 9, 2015

Copy link
Copy Markdown
Contributor Author

Didn't trace all the way down to onencoded, but the time across the video
encoder definitely increases. May be due to linkage with the onencoded/net
send stuff, could just be long encode time.

Either way, some more work should probably be done there, but until then
this is needed to make sure we don't pile-up/crash (this basically gives us
the old timing/behavior).
On Oct 8, 2015 6:00 PM, "Will Kelleher" notifications@github.com wrote:

So is the "OnEncoded" handler blocking for too long when the network is
slow, causing the encoder to slow down the capture handler thread, thereby
building up a huge queue of frames that can't be handled?


Reply to this email directly or view it on GitHub
#19 (comment).

@longk15t

longk15t commented Oct 9, 2015

Copy link
Copy Markdown

What does the phenomenon look like ? Is it about recording with webcam and video quality really bad/slow ? Just curious if I'm seeing same issue with you.

@dscherba

dscherba commented Oct 9, 2015

Copy link
Copy Markdown
Contributor Author

@longk15t : this was in a call (low/constrained uplink) with a webcam. Video would be really sluggish/delayed and memory would start ramping hard until Personify crashed (out of memory).

@dscherba

Copy link
Copy Markdown
Contributor Author

@DinhNguyenCat , @digitalmouse12 : any thoughts (note: feedback on this is lower priority than chroma stuff--not in critical path)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants