general: apply clippy lints (#407)

* general: update crates to 2021 edition.

* general: apply clippy --fix

* general: apply manual clippy lints

* cargo fmt.

Improve Sample Builder padding handling for static streams (#309)

When sending video streams that are fairly static, such as a screen
share of an inactive screen, libWebRTC will insert padding RTP

Improve Sample Builder padding handling for static streams (#309)

When sending video streams that are fairly static, such as a screen
share of an inactive screen, libWebRTC will insert padding RTP packets.
These were not correctly handled by sample builder, because of this
`SampleBuilder` would throw away packets carrying actual media.

## Example

As an example libWebRTC will send streams like this:

```
p1(t=1, start=true)
p2(t=1)
p3(t=1)
p4(t=1, marker=true)
p5(t=1, padding=true)
p6(t=1, padding=true)
p7(t=1, padding=true)
p8(t=2, start=true, marker=true)
p9(t=2, padding=true)
p10(t=2, padding=true)
p11(t=2, padding=true)
```

Prior to this commit `SampleBuilder` would build a sample out of `p1..=p4`
then drop `p4..=p8`. This would mean the bit of media data in `p8` would
be incorrectly dropped.

The reason for dropping `p4..=p8` is that `p4` is not at a partition head
and `p8` is incorrectly identified as the end of the sample, the real
end is `p7`.

With this commit `SampleBuilder` will build sample out of `p1..=p4`,
identify `p4..=p7` as padding and drop these packets, and build a sample
for `p8`.

There was also a bug where dropping packets because the sample head was
not at a partition start would double count the dropped packets(once in
`build_sample` and once in `purge_buffers`.

show more ...

Handle empty RTP packets in Sample Builder (#303)

libWebRTC, among others, will sometime send padding RTP packets to
keep send rates steady. When they do the packets are sent after a
complete se

Handle empty RTP packets in Sample Builder (#303)

libWebRTC, among others, will sometime send padding RTP packets to
keep send rates steady. When they do the packets are sent after a
complete sequence of RTP packets that form a Sample/GOP/Frame. Example:

* P0, Timestamp=1, Start
* P1, T=1
* P2, T=1, End(RTP Marker Bit set)
* P3, T=1, Padding
* P4, T=1, Padding
* P5, T=2, Start
* P6, T=2 End

Here, when building a sample using the packets P5 and P6 we'll have
`prev_dropped_packets = 2`, however these dropped packets are
inconsequential as they don't carry media. The stream of samples is
unbroken, despite having dropped some packets. With the introduction
of `prev_padding_packets` it's possible to distinguish between dropped
packets that are likely to break the sample stream and these
unimportant padding packets.

show more ...

Move all to top level