[MPlayer-dev-eng] more NUT questions

[D Richard Felker III]

On Wed, Apr 14, 2004 at 10:31:26PM +0300, Ivan Kalvachev wrote:
> > > 3. In stream_header fixed_fps is useless,
> > its usefull for transcoding to container formats which only support
> fixed fps,
> > and its usefull for error detection
> error detection? HOW do you detect error with this?
> Transcoding _TO_ other formats? Why somebody would do that?
> Moreover, it is INTEGER! How would you code 23.976? This alone is enough
> to crap everything.

No, fixed_fps is a flag.

> > > maybe average (or median) would
> > > have more sane (it may even be in timestamp units) e.g.
> > > time_base=1001/24000, average_frame_time=1; => fps=23,976
> What's wrong with this?

Average frame time is not a useful quantity to have, and probably is
NOT KNOWN. Therefore we can't store it.

> > > 4. That worries me much are the recording issues. The drift of audio
> > > sampling frequency. Audio packets have timestamps so possible
> > > workaround maybe audio to use system time for them, and not the time
> > > calculated from the frequencies. Rich said that audio should be
> > > resampleed to correct sampling frequency, but nor FFMpeg nor MPlayer have
> > > such precise resampler (check af_resample if you don't believe me).
> I think that Rich should comment that.
> The main problem I see is if we do that -^, we will need to rework
> mplayer with audio pts support.

My argument was that the capturing program should resample audio at
_capture_ time, so that sample numbers are correct timestamps.
However, if this is not done, the current MPlayer (G1) would just show
video frames for incorrect duration. A good player would resample the
audio at playback time to keep framerate correct.

(Sampling theory explanation: Audio is properly sampled so you can
freely resample it to whatever you like. Video is grossly undersampled
so you can't resample video and have it look correct,)

> Sorry, but I don't like nut. It tries to be smaller at all cost. And it
> pays too much. It trade simplicity. It trade stability. And then try to
> compensate with huge startcodes.

I agree with Michael that you should try to understand it before you
make judgements. However I too find the whole frame code thing ugly...
IMO it would be much more graceful to use bit fields for the pts and
size lsb's, rather than a huge lookup table, but perhaps it's too
costly.

Also as mentioned in the other email, I'd like it if we could ensure
that no buffering is required by the muxer or demuxer.

Rich