Step #4: Run VideoProcessor integration test batch mode on task queue.

webrtc/modules/video_coding/codecs/test/videoprocessor.cc

Index: webrtc/modules/video_coding/codecs/test/videoprocessor.cc
diff --git a/webrtc/modules/video_coding/codecs/test/videoprocessor.cc b/webrtc/modules/video_coding/codecs/test/videoprocessor.cc
index 129f962ba489965919d3f1d81e59370c565d6dfe..e3f0e674b420a76c865b41fb44641d444a721869 100644
--- a/webrtc/modules/video_coding/codecs/test/videoprocessor.cc
+++ b/webrtc/modules/video_coding/codecs/test/videoprocessor.cc
@@ -158,6 +158,8 @@ VideoProcessorImpl::VideoProcessorImpl(webrtc::VideoEncoder* encoder,
   frame_infos_.reserve(num_frames_);
 }
 
+VideoProcessorImpl::~VideoProcessorImpl() = default;
+
 bool VideoProcessorImpl::Init() {
   RTC_DCHECK(!initialized_)
       << "This VideoProcessor has already been initialized.";
@@ -203,7 +205,7 @@ bool VideoProcessorImpl::Init() {
   return true;
 }
 
-VideoProcessorImpl::~VideoProcessorImpl() {
+void VideoProcessorImpl::DeregisterCallbacks() {
   encoder_->RegisterEncodeCompleteCallback(nullptr);

[brandtr, 2017/03/10 09:50:54]

Must be called on the task queue.

[tommi, 2017/03/10 09:57:12]

as a drive by comment, there aren't any thread or sequence checks in this class.
In this case it looks like you found out about it by hitting a check inside
RegisterEncodeCompleteCallback.
There aren't locks either in VideoProcessorImpl, which suggests that the class
is single threaded. I think it would be a good idea to add those checks both for
sake of runtime correctness/expectations and understanding how the class is
supposed to be used.

   decoder_->RegisterDecodeCompleteCallback(nullptr);
 }