WebRTC native (C++) with custom VideoCapturer fails main_thread_.CalledOnValidThread() check

[Eran]

Full disclosure: Cross-posted from http://stackoverflow.com/questions/31503793/webrtc-native-c-with-custom-videocapturer-fails-main-thread-calledonvalidth

I compiled the WebRTC native code (C++) and I'm playing with peerconnection server and client examples (under `src\talk\examples\peerconnection`).  In particular I am trying to change the client sample to stream a custom sequence of images rather than the webcam video.  I used something similar to

http://sourcey.com/webrtc-custom-opencv-video-capture/

as a starting point, where a custom `VideoCapturerFactory` returns a custom `VideoCapturer` that I can use to generate custom image frames.  Every time I have a new image to stream, I call `SignalFrameCaptured(this, &frame)` on the `VideoCapturer`.

My problem is that, in debug mode, I get this crash:

    #

    # Fatal error in e:\webrtc\webrtc checkout\src\webrtc\modules\video_coding\main\source\video_sender.cc, line 90

    # Check failed: main_thread_.CalledOnValidThread()

    #

And my understanding is that it has something to do with an inconsistency between the thread which started the video stream and the thread which is pushing these individual frames.  It seems as though the former is an internal WebRTC thread, while the latter is currently the main thread of the application.

Things work in Release mode because this thread check is disabled.

Any idea how to properly fix this?

Thank you.

[Peter Boström]

talk/ has the concept of a worker thread (and a signal thread) and the way we've implemented things we require frames to be delivered on the worker thread. These thread checks permit reading stats without grabbing a lock inside VideoSender that used to be contended, causing GetStats to occasionally span across encoding of multiple(!) frames.

This has the downside of things having to be posted over to the worker thread, from browsing a bit I'm guessing that that's what's done in webrtcvideocapturer.cc:

https://chromium.googlesource.com/external/webrtc/+/324d9c9a86e2fa331234eb0fa227845fde9f0317/talk/media/webrtc/webrtcvideocapturer.cc#386

I'm not sure how to get a hold of the worker thread in your part of code, but hopefully this gets you on the right track/gives you some keywords to grep for. It might be the thread calling ::Start, but I'm not 100%.

- Peter

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/a47ccaac-d7ed-4340-a075-ddfe0b0ac864%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eran]

Thanks Peter, that helped a lot.  I mimicked the use of AsyncInvoke as in the file you linked below, and it seems to have fixed my problem.

[Peter Boström]

Glad you got it working! :)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ccba9229-794e-46fe-aa9e-3d38fd631d12%40googlegroups.com.

[Alvaro Gil]

I am experiencing the same issue using Cocoapods libjingle Debug revision, it doesn't happen with Release. I've double check that all delegates are re-dispatched into the main thread, do you know what could be causing it?

[Alvaro Gil]

So now that I've learn what DCHECK mean: https://code.google.com/p/webrtc/source/browse/trunk/webrtc/base/checks.h?spec=svn7003&r=7003

I released that it should be something wrong in my code, what is still not clear to me is what is causing it to not run on the same thread since I've debugged and ensured all rtc stuff is dispatched into main queue.

[Alvaro Gil]

[SOLVED] I figured out that you cannot use an instance of PeerConnectionFactory to access local stream and then use that local stream with another PeerConnectionFactory.