When first_timestamp was stored as-is, its actual time base
wasn't known later in the seek function.

Additionally, the logic (from 795d9594) for scaling it
based on stream_index is flawed - stream_index in the seek
function only specifies which stream the seek timestamp refers
to, but obviously doesn't say anything about which stream
first_timestamp belongs to.

In the cases where stream_index was >= 0 and all streams had the
same time base, this didn't matter in practice.

Seeking taking first_timestamp into account is problematic
when one variant is mpegts (with real timestamps) and one variant
is raw ADTS (with timestamps only being accumulated packet
duration), where the variants start at totally different timestamps.
Signed-off-by: Martin Storsjö <martin@martin.st>