This is similar to the situation where we receive packets with lower dts
than we previously output, except in this case we have no pts at all.
An alternative may be to skip such packets all together, but let's try
fixing them first.
This is related to #5.
In #1 we changed to manually set it if it is less than the last we
output. Apparently there are streams where it can be equal as well.
If we don't do this, then we see errors such as "Application provided
invalid, non monotonically increasing dts to muxer"
This fixes issue #1.
It appears there are inputs where the dts fluctuates. This is apparently
inputs that are not well formed. However, I discovered that ffmpeg
itself allows for this. If it detects this happening, it updates the
pts/dts of the packet. To do this, it tracks the last output dts. This
ensures the output dts is monotonic even if the input is not.
I use essentially the same approach as in ffmpeg.
If an input has multiple streams, then the packet's stream index for the
video stream we are reading may not match our output's stream index.
This can lead to errors such as:
[mp4 @ 0x5631c5836000] Invalid packet stream index: 1
Update the packet's stream index, prior to writing it, to match what it
is in our output.
I also update a comment (around line 294) to clarify that while we're
skipping a packet, it's not because it's not video.
