Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1863 closed defect (fixed)

abnormal stop if "-msglevel demuxer=0" is used when playing an .m4a file

Reported by: pnixte@… Owned by: reimar
Priority: important Component: demuxer
Version: unspecified Severity: major
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no

Description

Hello.

I'm trying to play the file "10ClockLiveEp1.m4a" (size: 26.0 MB)
available from the podcast feed "http://feeds.feedburner.com/10OClockLive"
by downloading it first to the local hard disk.

  • If I try to play the file using mplayer with the base command,

the win32 command window is flooded with messages:

|Too many audio packets in the buffer: (4096 in 1521432 bytes).
|Maybe you are playing a non-interleaved stream/file or the codec failed?
|For AVI files, try to force non-interleaved mode with the -ni option.

The file does play OK, but due to the fact that win32 console is slow,
the CPU load jumps to 100% and I experience major loss of function.

  • If I try to play the file by using the following command:

mplayer 10ClockLiveEp1.m4a -msglevel demuxer=0

the program exits abnormally after 2 seconds in the file.

System specifications


MPlayer Sherpya-SVN-r32735-4.2.5 (C) 2000-2010 MPlayer Team
(minGW)

cpuinfo:
vendor_id : GenuineIntel
cpu family : 6
model : 8
stepping : 6
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
model name : Intel(R) Celeron(R) processor

Change History (3)

comment:1 by reimar, 13 years ago

Resolution: fixed
Status: newclosed

You must have done something strange while testing, for me MPlayer quits "immediately" regardless of msglevel setting.
The problem is that the video stream has only one frame and thus MPlayer quits after showing it.
Using -novideo is a workaround.
And the issue is fixed (somewhat?) properly in SVN r32824.
I can't promise it will stay fixed though, it is a bit ugly and I am not 100% sure it won't cause any issues. If it does it might be reverted.

comment:2 by pnixte@…, 13 years ago

Priority: normalimportant

(In reply to comment #1)

You must have done something strange while testing, for me MPlayer quits
"immediately" regardless of msglevel setting.

I use the win32 binary as found in:
http://oss.netfarm.it/mplayer-win32.php

And my config file is:
double=yes
framedrop=yes
cache-min=25

The problem is that the video stream has only one frame and thus MPlayer quits
after showing it.
Using -novideo is a workaround.

Here's something interested I noticed...

The following command causes a crash:

mplayer -novideo 10ClockLiveEp1.m4a

|Playing 10ClockLiveEp1.m4a.
|libavformat file format detected.
|
|MPlayer interrupted by signal 11 in module: demux_open

MPlayer crashed by bad usage of CPU/FPU/RAM.

| Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
| disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.

MPlayer crashed. This shouldn't happen.

| It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
| gcc version. If you think it's MPlayer's fault, please read
| DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
| won't help unless you provide this information when reporting a possible bug.

But the following command plays flawlessly:

mplayer 10ClockLiveEp1.m4a -novideo

Is this one a bug?

And the issue is fixed (somewhat?) properly in SVN r32824.
I can't promise it will stay fixed though, it is a bit ugly and I am not 100%
sure it won't cause any issues. If it does it might be reverted.

Thanks for the prompt answer!

comment:3 by reimar, 13 years ago

Crashes are always a bug, however I cannot reproduce any.
There might be a bug and you're just unlucky that it is random and only happens for you.
Or it is one of the custom patches that are used for that build (though I do not think so), or it might be because that is a one month old version (though I cannot remember any change that would have fixed that).
Well, of course there is always the possibility of a hardware (e.g. memory) failure, but those almost never result in reproducible crashes.

Note: See TracTickets for help on using tickets.