Opened 12 years ago

Closed 11 years ago

#1017 closed defect (invalid)

Play certain older MPG files with -aid 0, crash on alt-tab or fullscreen toggling

Reported by: igetspam@… Owned by: reimar
Priority: normal Component: ao
Version: 1.0rc2 Severity: major
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


Compiled the current latest mplayer in portage of ~x86, 1.0rc2-p24929-r3 (the bug has been around for at least 5 years though) for a P4 Celeron.

  1. Play "older" MPEG video (according to file, one such a file is an "MPEG sequence, v1, system multiplex") _AND_ -aid 0 (needed to get sound).
  2. Toggle between windows via alt-tab or toggle fullscreen repeatedly
  3. Crash in mpeg2_set_buf (decode.c) after at the most 3-4 toggles

Only happens with sound output for the mpeg file turned on (without -aid 0 => no sound and no crash either).

CPU: P4, AKA, Intel(R) Celeron(R) CPU 2.40GHz (fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts sync_rdtsc cid xtpr)
VO: sdl (on nvidia gf4ti4200 with proprietory nvidia drivers)
AO: sdl (on alsa, oss, with and without dmix, doesn't matter)

See attached gdb log.

Most probably unrelated to eg. (completely different asm part), but who knows. Adding it for good measure.

Attachments (1)

NOWN-4.2.2-_gentoo_1.0_rc2_p24929-r3___-aid_0_crash__toggling_fullscreen_or_alt-tab_toggling-bug.log (15.8 KB) - added by igetspam@… 12 years ago.
gdb log for -aid 0 and alt-tab/fullscreen toggling - crash

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by igetspam@…

gdb log for -aid 0 and alt-tab/fullscreen toggling - crash

comment:1 Changed 12 years ago by igetspam@…

comment:2 Changed 12 years ago by reimar

I guess you are using -framedrop or even -hardframedrop.
If so use the ffmpeg decoder (-vc ffmpeg12,), otherwise this is a well known and very low priority bug.

comment:3 Changed 12 years ago by igetspam@…

  • Resolution set to wontfix
  • Status changed from new to closed

Well yeah, as stated above as well this thing is _at least_ 5 years (more likely 7+ years old).

The suggested workaround (no fix) does work.

Makes you wonder why:
a) there is no hint on the workaround anywhere (online or mplayer docs)
b) this particular piece of code is still in use after 5+ years of it being well known and still not fixed
c) noone fixed it

At least one of the three choices should be implemented, especially when it's a bug really well known for the frigging long time 5+ years are. ;)

But then, I can't force my personal QA standards on this project's QA standards.

It's just a really bad habit to not do anything at all (besides maybe removing the surely earlier bugreports in bugzilla without even resolving anything).

Thanks for the quick and helpful response (and one more bugzilla to put on my "dont even bother" list :)).

comment:4 Changed 12 years ago by reimar

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Did you use only -framedrop or -hardframedrop?
I actually know only of problems with -hardframedrop currently (H.264 had major problems with just -framedrop, but I think those were fixed).
And there have not been any previous bugreports on this bugzilla.
Also, it is not a WONTFIX, it is just low priority, even more so since most ways of fixing it would slow down libmpeg2 and speed is the only reason why we still have libmpeg2 at all.
Probably this will be "fixed" by making ffmpeg12 the default decoder sooner or later.

comment:5 Changed 11 years ago by compn

  • Resolution set to invalid
  • Status changed from reopened to closed

this has been 'fixed', as the above comment says

ffmpeg12 is now default over libmpeg2.

Note: See TracTickets for help on using tickets.