Improve setting framenumber

[anotherche]

Minor changes to the calculation of frameNumber to improve the accuracy of the methods setFrameNumber, setVideoFrameNumber, setAudioFrameNumber. Solves #1849

[anotherche]

I don't know if I did it right. It looks like I'm completely confused in all these operations. I apologize...

[anotherche]

The only change I mean is e980ac2

[saudet]

The only change I mean is e980ac2

That sounds like pretty much the same thing as Math.round(). How is it different from what was there before pull #1734 (review) ?

[anotherche]

The only change I mean is e980ac2

That sounds like pretty much the same thing as Math.round(). How is it different from what was there before pull #1734 (review) ?

Absolutely right! Because floor(x+0.5) is equivalent for round(x). Moreover, we can revert to Math.round in all three methods of framenumber setting (however the addition of 500000L should be done anyway).

[saudet]

Could you fix the branch somehow so that we can see only your changes?

[saudet]

It doesn't look like your tests are liking these changes...

[anotherche]

It was because of copy-paste mistake in setAudioFrameNumber. It is fixed now.
Additionally, I removed one unnecessary part of test (not the part that caused the failure!). I removed this part because it was not about checking setTimeStamp code, but about checking that adjacent audio and video frames in the file differ by no more than 1 second. This has nothing to do with setTimeStamp, but with how ffmpeg fills a container with different types of streams.

[saudet]

And you're sure this doesn't cause a regression for issue #1697?

[anotherche]

And you're sure this doesn't cause a regression for issue #1697?

I believe it doesn't due to timestamp shift by 500000/frameRate in setVideoFrameNumber. But to be sure I will add short explicit test for the issue #1697.

[anotherche]

It passes :)