Better handling of "non-monotonically increasing dts to muxer" errors

Nobody has claimed this yet.

Transcoding fails semi-frequently with:
```
[mpegts @ 0x7f277c4fb880] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 181812 >= 181812
ERROR: transcoder.c:267] Error encoding : Invalid argument
```

**TODO:**
- [x] Find root-cause

This is caused by bad source video with messed up timestamps, causing the MPEGTS muxer to fail https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L602 and return `EINVAL` ("Invalid argument")

- [ ] Improve logs around it

The logging around this is confusing and not very descriptive. EINVAL could come from various sources.

- [ ] Fix it/handle it better

Dig deeper if we can handle the frame[n].pts == frame[n+1].pts case better to avoid these failures.

Start at transcoder.c:267 and compare its error handling with FFmpeg's mux.c around line 602, where the non-monotonic DTS error is returned. Reproduce the failure with the malformed timestamps described in the issue, then determine what clearer logging and handling are possible for equal consecutive PTS values. Done means the failure is more diagnosable and the feasible timestamp case is handled without the current muxer error.

Written by the indexing model from the issue text.