In the default config, audio packets are 40ms long and video is 25/1
frame per seconds, so frames are displayed every 40ms. When changing
framerate to 50/1, everything still works correctly and the DemuxVideo
call will generate two frames for one audio packet, and the sys->clock
accumulator will move forward 40ms too.

However, when using any frame rate value that would make 40ms not
divisible by the video frame duration, eg. 60/1fps which is a period of
16.666ms, then the video would drift apart from the other tracks.
Symmetrically, when using any frame rate value < 25/1 that would not be
divisible by 40ms, the audio would drift apart from the other tracks.

It came from the fact that video and audio were allowed to move forward
the same amount starting from their previous pts value, which is not the
same starting point for each track in case the divisibility condition is
not met.

The following graph represents the situation by drawing the two tracks
with different origins to show how the video makes more progress than
the audio in the case audio has 40ms packet and video is 60/1fps.

        PTS                           video
        ^               audio            *   --+
        |                  *            /      | We go further than the
        |                 /            *       | audio track here. But
        |                /            /        | we'll continue sending
        |               /            *       --+ packets by group of 3.
        |              /            /
        |             *            *
        |            /            /
        |           /            *
        |          /            /
        |         /            *
        |        *            /
        |       /            *      --+
        |      /            /         | This shows we can generate three
        |     /            *          | video packet for each audio
        |    /            /           | packet in the current state.
        |   *            *          --+
        |  /            /
        +---------------------------------------->ts

By keeping the track-specific start point, we don't miss any value, and
by setting the maximum date from sys->clock instead of the
track-specific start point, we ensure we don't send more packets than
wanted.

Fix #29122