[MPlayer-dev-eng] Nut sample_rate_mul

[D Richard Felker III]

Another nut issue. I realized that the way sample_rate_mul works
forces time_base_nom to be a factor of the samplerate for audio
streams. Do we really want this? Think of idiotic cases where someone
wants to use 88200/1 time base for 44100 Hz audio, OR (and I'm not
sure whether we want to allow this or not) the case of live recording
with imprecise sample clock, where the user wants to use realtime
usecs from the system clock as the time unit for both audio and video.

Recommended solution: replace sample_rate_mul with a rational number.
Could be in units of time_base, or units of 1/seconds... (Which do you
like better??)

BTW, should we allow time units/timestamps for audio that don't match
sample counts? It could make slight trouble for players (more
difficult for primitive player apps to sync A/V), but it's very useful
for the first phase of live recording, before you resample audio to
compensate for bad-quality soundcard clock. Of course, personally I
recommend doing the resampling _during_ recording, so you never write
a file with bad timestamps, but some users might want to do
high-quality resampling and not have cpu time to do it live. Ivan and
I were arguing about this on irc...

Rich