Enable passing receive stream ID to the decoder factory.

webrtc/media/engine/webrtcvideodecoderfactory.h

Index: webrtc/media/engine/webrtcvideodecoderfactory.h
diff --git a/webrtc/media/engine/webrtcvideodecoderfactory.h b/webrtc/media/engine/webrtcvideodecoderfactory.h
index c739096ac5c190671432b3259033ceff11489455..3b54bdec8e911d26638b3f80e695a457fc3bc3b3 100644
--- a/webrtc/media/engine/webrtcvideodecoderfactory.h
+++ b/webrtc/media/engine/webrtcvideodecoderfactory.h
@@ -26,6 +26,11 @@ class WebRtcVideoDecoderFactory {
   // by calling DestroyVideoDecoder().
   virtual webrtc::VideoDecoder* CreateVideoDecoder(
       webrtc::VideoCodecType type) = 0;
+  virtual webrtc::VideoDecoder* CreateVideoDecoderForSsrc(

[pthatcher1, 2016/06/14 18:06:32]

This doesn't seem right to me.  Why would a video decoder need to know about
SSRCs?  SSRCs are an RTP/transport thing, and decoders really just take an
EncodedImage and give a VideoFrame.  That don't know anything about how the
frame was packetized, transmitted, etc.  

If you need some kind of metadata about the frames that will be decoded, it
should be abstracted away from being and SSRC.  

[noahric, 2016/06/14 18:26:21]

That's specifically the problem on android. The optimal way to decode video on
android MediaCodec decoders is for them to be directly given the rendering
surface (in the app, if possible) to render to. Having intermediate buffers or
textures increases latency, battery usage, and heat.

Feel free to stop by if you want some more background on it.

I think there are cleaner long term plans, but this is a short term unblocker of
some better rendering on android.
We could do that, provided that we can connect the dots between the renderer and
the decoder. Roughly speaking, on Android, the decoder wants to consume
information that the renderer produces (the surface). ssrcs are just the
simplest way of doing that, since they identify the stream.

And to be clear, it's not about frames. It's about the stream, or at least the
renderer/decoder relationship.

[pthatcher1, 2016/06/14 18:59:15]

I still don't see why it needs to know SSRCs.

This whole thing seems very hacky.  Perhaps will have to chat in person to
understand what you're trying to do.  
Using SSRCs as stream identifiers is very ugly thing that we're trying to remove
from the code base, not expand.  

The more I think about it, the more I think that if you need metadata about an
EncodedImage, (because you're trying to hack a decoder into looking like an
EncodedImage sink), then I think it makes the most sense to put that metadata on
the EncodedImage.  That might be generally useful anyway.

+      uint32_t ssrc,

[pthatcher1, 2016/06/14 18:06:32]

And if we do pass in metadata about the frames that will be decoded, I think we
should have one method (CreateVideoDecoder) that gets a struct of metadata, and
not two methods.  And the metadata should be the last argument, not the first. 
Since CreateVideoDecoder is only called in one place and implemented in one
place, it shouldn't be that hard to add an argument.

[noahric, 2016/06/14 18:26:21]

There isn't only one implementation. This is a publicly implementable API, so
you can't just add an argument.

As for it being a struct, it could be a struct that just contains an ssrc now,
if that's preferable. Or it could be some opaque identifier, as long as
renderers can use the same identifier.

[pthatcher1, 2016/06/14 18:59:15]

Sure you can.  You might have to have a little transition period where you have
two methods with the same name and different args, but long-term target having
one method.  We do this all the time.

But I agree that it would be nicer to not change this method and instead add the
metadata elsewhere (such as on the EncodedImage)
We don't really have renderers any more.  We have VideoFrame sinks.  But
regardless of what we call them, all they get are VideoFrames, and those don't
have SSRCs either.  So I don't see why you would want to use SSRCs to try and
correlate EncodedImages to VideoFrames.  

When would a renderer/sink be given an SSRC?  That doesn't make sense.

+      webrtc::VideoCodecType type) {
+    return CreateVideoDecoder(type);
+  }
   virtual ~WebRtcVideoDecoderFactory() {}
 
   virtual void DestroyVideoDecoder(webrtc::VideoDecoder* decoder) = 0;