Re: Transport / encoder coupling (Re: Use cases / requirements for raw data access functions)

On 22/05/2018 23:21, Peter Thatcher wrote:
> I made a diagram of my thinking of the different possible API layers.  
> Here it is:
>
> RTP object stack.png
>

IMHO jitter buffer should not be coupled with the decoder as it is an 
RTP thing, if you are going to feed full frames to the decoder, it has 
to be on the RTPFrameTransport (why  "frame" ?), or better, split it in 
two different components.


> This highlights the question: what happens to RtpParameters?  Some are 
> per-transport, some are per-stream, some are per-encoder (which is 
> different than per-stream), and some don't make sense any more.
>
> Per-transport:
> - Payload type <-> codec mapping
> - RTCP reduced size
> - Header extension ID <-> URI mapping
>
> Per-stream:
> - PTs used for PT-based demux
> - priority
> - mid
> - cname
> - ssrcs
>
How about simulcast and rids?

> Per-encoder:
> - dtx
> - ptime
> - codec parameters
> - bitrate
> - maxFramerate
> - scaleResolutionDownBy
>
> Don't make sense:
> - active (just stop the encoder)
> - degradation preference (just change the encoder directly)
>
Not sure if I want to get rid of the degradation preference, as 
currently the encoder is affected by both bandwidth reported by the 
transport layer + cpu utilization. Would it make sense to extend the 
degradation preference to also cover that scenario? Also, I am not sure 
if i want to get rid of a backchannel between the encoder and the 
transport and have to do it manually.

Best regards
sergio