Zend certified PHP/Magento developer

Why does ffmpeg alter timestamps when “-codec copy” is given, and how to prevent this?

I am currently trying to remove certain audio tracks from a bunch of m2ts files (mainly to save space), using ffmpeg. In doing so, I would like the removal of those tracks to be the only action that is applied to the files. Therefore, I use the following command line pattern:

ffmpeg -i input.m2ts -map 0:0 -map 0:2 -codec copy output.m2ts

Here, track 0 is a video track, and track 2 is the audio track that I want to keep. The input file also contains track 1, which is an audio track that I want to discard and which therefore is not mapped.

Since I am using -codec copy, I would expect that every mapped track is copied exactly as-is and that nothing is altered, including the various timestamps. But like a lot of other people, I am running into problems when executing this command. There is a lot of error messages like the following:

Non-monotonic DTS in output stream 0:7; previous: 12978089, current: 12978087; changing to 12978090. This may result in incorrect timestamps in the output file.

That message clearly says that timestamps are altered in a way that may lead to problems.

There are many questions and answers about how to cope with that message. The usual advice, as far as I have understood, is to give options to ffmpeg that make it ignore those errors and make it compute the DTS from the PTS. In other words, the common solutions also make ffmpeg alter the DTS time stamps.

I now have the following questions:

Why does ffmpeg care about wrong timestamps at all when -codec copy is given? The timestamps are part of the tracks, aren’t they? If yes, they should be copied unaltered from the source file(s) into the destination file, regardless of whether or not they are correct, right?

What options can I give to ffmpeg to achieve this (that is, to prevent it from altering the time stamps in any way)?