Opened 3 years ago

Closed 18 hours ago

#13622 closed bug (fixed)

[MediaPlayer] media extractor thread uses 100% cpu

Reported by: diver Owned by: leavengood
Priority: normal Milestone: R1/beta3
Component: Audio & Video/Codecs Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking: #13928, #14681
Platform: x86-64


hrev51305 x86_64

Playing this file is either makes MediaPlayer (media extractor thread) use 100% cpu or quits with:

pure virtual method called
terminate called without an active exception

Change History (23)

comment:1 by korli, 3 years ago

What about hrev51306?

comment:2 by diver, 3 years ago

CPU usage is still high. Can't trigger the crash tho.

comment:3 by korli, 3 years ago seems to also be affected. MediaPlayer (or something it calls) seems to insist on extracting video frames which are not present.

comment:4 by vidrep, 3 years ago

Note that the the slider of the progress bar never moves while playing that ogg sample clip. I also see that problem with one of my m2ts trailers.

Last edited 3 years ago by vidrep (previous) (diff)

comment:5 by diver, 3 years ago

Blocking: 13928 added

comment:6 by waddlesplash, 2 years ago

High CPU usage fixed in hrev52358; however, the time indicator still does not increment on these files.

comment:7 by pulkomandy, 20 months ago

Still getting high CPU usage on some files here. In media player, "event queue runner", "playback manager", "media extractor thread" and "frame generator" threads are busy, as well as the main window thread.

How did we end up with so many threads just to play a media file anyway?

comment:8 by korli, 18 months ago

Owner: changed from korli to nobody
Status: newassigned

comment:9 by leavengood, 13 months ago

Component: Kits/Media KitApplications/MediaPlayer
Owner: changed from nobody to leavengood

Probably more of a MediaPlayer bug than Media Kit, though I don't know for sure yet. Probably the same issue as #15220.

comment:10 by vidrep, 5 months ago

Milestone: UnscheduledR1/beta2

Moving to Beta 2 milestone as discussed on IRC.

comment:11 by pulkomandy, 5 months ago

Component: Applications/MediaPlayerAudio & Video/Codecs

comment:12 by waddlesplash, 5 months ago

Resolution: fixed
Status: assignedclosed

Fix merged in hrev54121.

comment:13 by vidrep, 5 months ago

Tested with hrev54121x86_64. Problem is still there. One CPU core at 100% and no progress bar movement or time count.

comment:14 by vidrep, 5 months ago

Resolution: fixed
Status: closedreopened

comment:16 by vidrep, 5 months ago

I applied the patch on both 32 and 64 bit. There is a definite difference in behaviour between the two. As a side note, the patch seems to fix a streaming issue that has existed for some time

comment:17 by pulkomandy, 4 months ago

Blocking: 14681 added

comment:18 by waddlesplash, 3 months ago

Milestone: R1/beta2

Ticket retargeted after milestone closed

comment:19 by waddlesplash, 3 months ago

Milestone: R1/beta3

comment:20 by ttcoder, 3 months ago

Congrats on a solid second beta release! Something I've been wondering: there's been talk of releasing updates in the beta2 update channel in the future. For instance, let's say pulkomandy's patchset 2562 above is applied to trunk, then backported to beta2 branch. I guess this ticket's milestone will remain at "beta3" since there is no "b2.1" milestone, we should still leave it to the haiku core Haiku devs to set milestones, right? And requests for backports to the beta2 branch should be made as polite messages rather than tweaking ticket fields then. 8-)

comment:21 by ttcoder, 3 months ago

Cc: ttcoder added

comment:22 by waddlesplash, 3 months ago

Yes, we did backport patches to beta1 for a few months last time, and we will probably do the same again this time.

comment:23 by pulkomandy, 18 hours ago

Resolution: fixed
Status: reopenedclosed

Patch applied in hrev54577. There are still problems (the cover art is not displayed now, we get a black window instead) but no 100% CPU usage anymore, at least.

Note: See TracTickets for help on using tickets.