[MPlayer-dev-eng] [PATCH] silence the overly verbose mov demuxer

[Ivan Kalvachev]

2006/3/8, Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org>:
> On Wednesday, 08 March 2006 at 14:52, Michael Niedermayer wrote:
> > Hi
> >
> > On Wed, Mar 08, 2006 at 03:05:13PM +0200, Ivan Kalvachev wrote:
> > > 2006/3/7, Diego Biurrun <diego at biurrun.de>:
> > > > On Mon, Mar 06, 2006 at 11:24:36PM +0100, Roberto Togni wrote:
> > > > >
> > > > > And i fail to see why users should be annoyed by mplayer console
> > > > > messages.
> > > >
> > > > It's a simple matter of psychology.  If MPlayer prints out a lot of
> > > > gibberish people cannot understand they just ignore all of it.  Nobody
> > > > will bother to read through it to find the interesting pieces.  That's
> > > > why output should be terse by default so that the important and
> > > > interesting pieces get noticed.
> > > >
> > > > I'll give you an example: Do you read licenses and EULAs top to bottom?
> > > > How many people really do?  Most have a look at it, see it is
> > > > unintelligible and uninteresting legalese and skip it completely...
> > >
> > > Even if nobody reads the EULA, it is still displayed.
> > >
> > > I believe that a lot of people spoken that they prefer to have some
> > > output they could ignore than not have it when they need it.
> > >
> > > So, let be more constructive. What info should the demuxer output by default.
> > >
> > > - subtype of file (avi1.0, ODML; MOV, QT etc...)
> > > - info (author, name, copyright etc... text data)
> > > - number of streams
> > >
> > > for each stream:
> > > - type of stream (audio,video,subtitle,unknow).
> > > - length of stream (if available)
> > > - way to access the stream (s/alang, s/a/vid)
> > > - fourcc, long description (e.g. Fourcc: SVQ3  Codec: 'Sorenson Video 3' )
> > >
> > > Do I miss something?
> >
> > which demuxer, codec and vo is being used maybe
>
> What I said earlier, i.e. resolution, bitrate, fps for video streams and
> sampling rate, number of channels and bitrate for audio streams (similarly
> to what it's like now).

I was thinking that this info is redundant because we can later see it
when codecs are started. But in case you have multiple streams with
different quality, it indeed could be handy.