Running the new GstAggregator-based flvmuxer in our system gave some weird failures.

Turns out it was caused by the flv-timestamps going backwards, and with RTMP generating delta timestamps, these would go negative and cause the timestamps
to overflow, producing timestamps thousands of hours into the future!

With a bit of hassle I was able to produce a test that can be run both with the
old and new flvmuxer, and that will produce a "correct" sequence with the old implmentation, and a "backwards-timestamp" sequence with the new, basing it on
the real data I saw in our tests.

As for possible fixes I think first it would be a good idea to determine if
producing backwards timestamps in the flv-stream is something we want to avoid
at all costs, or if this can be expected to happen.

Anyway, some sort of sanity internally in the flvmuxer to at least notify the
user of backwards timestamps (or perhaps a property to not allow it), would probably be a good idea, as I expect many people upgrading the muxer would experience similar things to what we did.