[FFmpeg-devel] [PATCH] miscelleneous NUT fixes

[Rich Felker]

On Sun, Feb 03, 2008 at 08:16:39PM +0100, Michael Niedermayer wrote:
> > > > I stand by Oded's patch to remove the incorrect interpretation and
> > > 
> > > We have files which need this interpretation, we do not have ones which
> > > break due to it. Feel free to add a big comment to the code saying its
> > > not spec compliant if you like.
> > 
> > We have invalid files which should be patched or deleted.
> 
> Its ffmpegs philosophy to play as many files as possible, broken or not.

Please note that libnut never even bumped the version number in the
header, so these files are already bogus in that sense. If you want,
you could make this nasty hack dependent on having the old version
number... But i'm still somewhat against it.

An essential part of NUT has always been providing well-defined
semantics, albeit sometimes strange ones, to the possible idiotic
things people could put in broken files. At times this means treating
invalid data as corruption (which in principle improves error
detection capability); at other times it means presenting frames in an
unusual order (for example if a stream with B frames was muxed using
dts instead of pts). It is absolutely irresponsible for us to violate
our own principle and have the lavf demuxer interpret valid-but-weird
data as having some meaning other than the specified meaning, simply
because a historical, pre-specification implementation contained a
stupid bug.

If you can detect and work around old-libnut-muxed files WITHOUT
misinterpreting the header in valid NUT files, I will not strongly
object. However, I still see it as useless code clutter and contrary
to the goal of keeping NUT clean.

> > Um, all that's required for noninteger samplerates is converting the
> > samplerate field to a rational type instead of an integer type. This
> > is hardly comparable to implementing major high-complexity features.
> 
> No, you have to at least add a flag to indicate which muxers support
> non integer samplerates, and deal with the additional case in the user

I was just thinking the muxer could give an error if the samplerate
denominator is not 1, when it doesn't support noninteger samplerates..

> applications, which with near certainity will not support non integer
> samplerates. And audio in/out hardware which again with near certainity
> wont support it, nor will even have +-1 sample/second accuracy.

Then applications can just perform the integer division and round.. :)
Or they can resample. Rounding the rate is probably fine for most
basic uses, but with NUT the point is to meet a wide spectrum of needs
in a common format, and surely one can envision cases where an exact
samplerate would be desirable (especially for long recordings made
with hardware where the audio and video clocks do not perfectly match
and a correction factor needs to be applied).

Rich