[MPlayer-users] Bug 2 of 2: -framedrop gives lots of errormessages with h264

[RC]

On Sun, 02 Apr 2006 23:56:43 -0400
"John Brown" <johnbrown105 at hotmail.com> wrote:

> RC wrote:
> >
> >I don't understand why posting a full bugreport is so difficult for
> >you.
> >  It's not exactly torture to go through all the steps.
> >
> Because the information that they are asking for is usually
> unnecessary. 

No, as a matter of fact, it's usually not.  You can often hazard a guess
with very little info (eg. non-verbose output, truncated output, etc)
but that's still just wasting a lot of time guessing, when a full
bugreport would answer just about every question anyone could need
to ask.

> If  the developers are as busy as that, why do they want
> to read all of that  irrelevant information? 

It's not like anyone goes through it, line-by-line, and memorize it.  I
usually just glance at gcc version, kernel version, etc.  Then look at
the end of the mplayer output to see what the crash is, the beginning
to make sure the options make sense, and then usually scroll-up through
the filters, output, or whatever else seems the likely cause.

> 1)If you compiled MPlayer successfully, why do your gcc, ld, and as
> versions  matter? What was the last bug that was caused because the
> user compiled with  gcc a.b.c when he should have used gcc d.e.f? when
> was that?

I recall reporting two myself, around 6 months ago, IIRC, and,
actually, I have one probably with binary DLLs I'm trying to trace
down, which looks very much like a compiler bug.  3.3.x is buggy, and
yet it's very common in current Linux distros.  gcc2 will show bugs that
gcc3 will not (c++, unintialized variables, etc).  Now gcc4 is getting
popular...

> 2) If you have a problem with some files but not others, and other
> players  can play the problem files, why isn't it sufficient to send a
> sample file  and a description of the problem?

That often works, and is sometimes better than just a bugreport, but it
may also be the case that a developer can't reproduce the problem with
your sample.  There are at least a couple that, don't seem to have
access to x86 machines to begin with.

Then again, maybe it'll be a problem with certain instructions failing
on your (overheating/marginal) CPU or RAM (I see that often on this
list).  

> If they can't, *then* the verbose output,  backtrace, etc. would help
> them to come up with a hypothesis.

Most of the devs know mplayer very well, and can tell what the problem
is very quickly after looking through the backtrace and output.  

> 3) Similarly, I really do not believe that it is generally useful to
> know  about the CPU, video card, sound card, etc. if your system is
> working well  otherwise. The operating system, certainly.

CPU:  I recall multiple times people have reported bugs, saying that
their system is playing a video too slowly, only to find out (after
multiple hours and emails) that they were trying to play something like
a hidef h.264 video on their 800MHz machine, or whatnot.

Videocard:  Very common to see complaints that xv or gl isn't working,
only to find out they have an 8mb videocard, or something else very old,
having only lowsy drivers, etc., which simply couldn't work for video
playback.

> 4) They say that you should not truncate the output, but do they
> really need  to see *all* the status lines? Unless there is a warning
> or error message,  one status line looks very much like another,
> except possibly the last line  which may be incomplete because MPlayer
> crashed.

It's very, very rarely just plain status lines.  There's important
information inter-mingled in there, and people trying to remove
unimportant info will almost always remove important info with it.
 Besides, crashes usually happen at the very beginning, so it's not
common to see many status lines in the output, anyhow.  

Sometimes, video/audio changes at different times in the file can cause
crashes, as well.

> If the developers ned more information, they can ask.

Yes they can.  They can babysit and take you through the steps, one by
one, it just takes a lot of time.  Usually, pointing you to
bugreports.html *is* them asking for (much) more info.

> I do not see the point  of drowning them in useless information by
> following the steps in the manual  like a robot.

They're hardly drowing.  It's just a few kilobytes, which they can
stroll-through as needed.

> Notwithstanding  all of the above, if they think that they need all of
> that verbiage, they  will get it.

That's always the safest route.  However, as I said, if you know mplayer
well-enough to be very sure where the actual problem lies, you can
pick-and-choose what info needs to be reported.  If you don't, or
aren't sure, it's much better to just provide everything.  A sample
always helps, as well.