Many corner cases would cause samplebuilder to fail and return invalid
results. This refactoring is more reliable in all cases.
Fixed bug in H264 writer by reusing the packet object in H264 writer.
media.SampleBuilder would round time and was breaking audio samples that
required higher precision. This was seen only with alaw/ulaw that needed
microsecond precision. v3 had only been used with Opus so far.
Resolves#1640
Let's pull off the bandaid!
* Reduces studdering: webrtc.RTCTrack -> webrtc.Track
* Makes it easier to find types by editor autocomplete
* Makes code read more fluently (less repetition)
Since we're breaking the API in 2.0, our only chance to
do this is now.
Relates to #408
When constructing a SampleBuilder the caller now passes in a
Depacketizer. This allows the SampleBuilder to take a RTP packet
to a sample. This wasn't possible before because RTP payloads may carry
codec specific metadata in the payloads that need to be stripped
Relates to #63
SampleBuilder provides a simple API to build an
RTCSample from RTP packets. This is useful when proxying
audio/video data to multiple peers. This is the alternative
to allowing users to push RTP Packets directly. This would be
confusing as we would throw away some of the information that users
give us and could lead to weird edge cases
Resolves#112
