Added functions on libjingle API to start and stop the recording of an RtcEventLog.

talk/app/webrtc/peerconnectionfactory.h

 /*
  * libjingle
  * Copyright 2011 Google Inc.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are met:
  *
  *  1. Redistributions of source code must retain the above copyright notice,
  *     this list of conditions and the following disclaimer.
  *  2. Redistributions in binary form must reproduce the above copyright notice,
@@ skipping 61 matching lines @@
 
   rtc::scoped_refptr<VideoTrackInterface>
       CreateVideoTrack(const std::string& id,
                        VideoSourceInterface* video_source) override;
 
   rtc::scoped_refptr<AudioTrackInterface>
       CreateAudioTrack(const std::string& id,
                        AudioSourceInterface* audio_source) override;
 
   bool StartAecDump(rtc::PlatformFile file) override;
+  bool StartRtcEventLog(rtc::PlatformFile file) override;

[Henrik Grunell WebRTC, 2015/10/02 10:23:42]

Although not ideal, this is afaik the most reasonable place to have this
function.

[terelius, 2015/10/02 12:16:26]

So is there a reason for having the ChannelManager in the factory rather than in
the PeerConnection? Wouldn't it make sense to let the PeerConnection manage its
own channels?

[Henrik Grunell WebRTC, 2015/10/02 12:23:40]

I don't know. I'm not the right person to answer that. :) (It seems to be
outside the scope of this CL too.)

[terelius, 2015/10/02 12:46:34]

Acknowledged.

+  void StopRtcEventLog() override;

[terelius, 2015/10/02 10:07:14]

I'm not very familiar with the PeerConnection and related code, but I assume
that PeerConnectionFactory works like a regular factory which produces
PeerConnections with consistent configurations.

If this is correct, then I don't understand why we have methods to start and
stop logging in the PeerConnectionFactory. Shouldn't it be in PeerConnection
and/or PeerConnectionInterface?

[ivoc, 2015/10/05 14:16:32]

I think one of the problems is that there can be multiple PeerConnections that
correspond to a single VoiceEngine. Also, the start function for AECdump is
located here, so it makes sense to keep them together.

[pthatcher1, 2015/10/06 20:49:09]

But why is this logging tied to the voice engine?  Is it audio-specific?  And do
we really want cross-PeerConnection logging?  It seems like it would make more
sense to log per-Call object and per-PeerConnection.

[ivoc, 2015/10/07 14:27:27]

The current place of the logging object is a temporary solution, we have plans
to move it to Call when the refactoring of VoE is further along. The reason why
VoE is involved is that beside RTP headers we're also logging debug events
inside of the audio coding module. I think for now we can accept that logging
multiple peerconnections can lead to strange logs (identical SSRCs etc). Since
VoE outlives Call, it was easier to put the logging object in VoE, so we don't
have to worry about dangling pointers or shared ownership. 

 
   virtual cricket::ChannelManager* channel_manager();
   virtual rtc::Thread* signaling_thread();
   virtual rtc::Thread* worker_thread();
   const Options& options() const { return options_; }
 
  protected:
   PeerConnectionFactory();
   PeerConnectionFactory(
       rtc::Thread* worker_thread,
@@ skipping 23 matching lines @@
   // injected any. In that case, video engine will use the internal SW decoder.
   rtc::scoped_ptr<cricket::WebRtcVideoDecoderFactory>
       video_decoder_factory_;
 
   rtc::scoped_refptr<RefCountedDtlsIdentityStore> dtls_identity_store_;
 };
 
 }  // namespace webrtc
 
 #endif  // TALK_APP_WEBRTC_PEERCONNECTIONFACTORY_H_