Discontinuities in source scr/pts/dts break transcoding for dvdread -> mp4
I recently ran into problems trying to transcode dvds to mp4 format. Following any discontinuity in the scr (e.g. layer break, or skip over unreadable sectors), I would lose the audio in the output. What was happening was that the discontinuity was causing the dts timestamps on packets to jump backwards*. As the muxer uses two fifos (audio and video) and pulls in whichever of the packets has the lowest dts, a jump back in time causes problems. Imagine two FIFOs, with packets with the following dts timestamps:
{...,6,4,2,98,96} and {...,5,3,1,99,97}
As values are popped from the right, taking which ever is lower, we will end up with,
{...,6,4,2} and {...,5,3,1,99}
and it can clearly be seen that the second FIFO is now stuck.
The attached patch (against 1.0.2) attempts to fix these issues by detecting discontinuities in the scr, and adjusting the scr and pts and dts timestamps accordingly, to maintain a continuous progression (with the correct gaps between samples) for each. I've tested it, and it fixes my transcoding problem, but I've no idea if it might cause other problems. It's also fairly untidy, and perhaps needs some cleanup by someone more familiar with vlc coding styles.
This is a fairly general problem, and the streams going to the TS muxer certainly suffers in the same way.
Also, whilst it does make some sense to try to deal with discontinuities in a centralised manner, such that all access modules could just pass on packets with timestamps as read without any special handling, it would be significantly more difficult. The code for handling clock discontinuities simply had the effect of making the dts timestamps arriving at the muxer jump forward a large amount, before jumping back (see* in first para). Also, as the clock handling process is potentially in a different thread to the code handling the timestamps, getting predictable behaviour could be hard.