Design of media.Sample

[at-wat]

https://github.com/pion/webrtc/wiki/PlanningV3#api-should-deal-in-timeduration-and-abstract-away-samplerate

API should deal in time/duration and abstract away SampleRate

media.Sample is confusing. Users shouldn't have to understand the sample-rates of Video vs Audio.

[at-wat]

I'd like to suggest to drop media.Sample from v3 API because of the following reasons:

1. Transformation rtp.Packet -> Sample is lossy.
   As reported in Always set Marker bit to false? rtp#69, roundtrip transformation rtp.Packet -> Sample -> rtp.Packet loose some RTP header flags.
2. Supporting all of rtp.Packet, media.Sample, binary makes the API complex.
   On v2, Track implemented all of Read/ReadSample/ReadRTP and Write/WriteSample/WriteRTP. They are functionally duplicated and will make Track implementation complicated. (A processor of the data should have all of Read/ReadSample/ReadRTP and Write/WriteSample/WriteRTP, and should support all input/output combinations.)

[at-wat]

Sample based Tracks can be defined using #24 independent from RTPTrack.

[Sean-Der]

I feel good about this, closing!

Internally we just deal with RTP, and give a public API that can do samples.