Successive MPEG1/2 B frames (each with a slice #9) could incorrectly
lead to the assumption of a H.264 stream, as sequence or group start
codes were not seen for these frames. So the detection logic
interpreted the slice #9 start codes as H.264 access unit delimiters
and therefore incorrectly switched to H.264 buffer type instead of
MPEG1/2. Extending the detection logic to consider MPEG1/2 picture
start codes as well (which do not appear in H.264 streams), prevents
false positives.

These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.

External FFmpeg has recently gained multithreaded H.264 decoding
and to make use of this feature, it is necessary to inform FFmpeg
about the maximum number of threads it may use for decoding.

When a stream doesn't start with an IDR frame, there will be several
seconds of bad frames and not setting PTS on those frames causes an
unnecessary delay in syncing audio and video.

When a stream doesn't start with an IDR frame, then frame size isn't
known, but all frames up to an IDR frame are reported as bad frames.
In such a case, a frame of size 1x1 will be allocated as xine-lib
cannot handle 0x0 frames properly, i. e. many output drivers simply
crash.