Opened 15 years ago
Closed 14 years ago
#6219 closed bug (fixed)
mediaplayer playback chokes with a few videos
Reported by: | samui | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/MediaPlayer | Version: | R1/alpha2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
filed a similar bug (#6188) a few days ago but this is on a different build of haiku so im filing it as a new bug
build 37184, 256mb of mem, intel i5 2.6ghz, virtualbox
opening six mp4 videos runs ok. opening a seventh one makes the processor go 100% stopping all playback on all the opened mediaplayer windows. The playerheads keep moving on and sometimes even the sound indicators keep moving, no sound though) but playback wont resume even if you click play or whatever. processor time usage goes down to minimum.
for some reason playback does not survive a peak in processor usage. same thing in hrev1 alpha 2 made player windows elegantly to drop frames (which i think is the preferred thing to do). also hrev1 alpha2 allowed me to open more videos at the same time albeit crashing everything in the end.
closing all media player windows wont work, killing mediaplayer crashes media add on server and then media server. i filed that as different bug though.
Change History (2)
comment:1 by , 15 years ago
comment:2 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The "audio producer thread" locks up problem has been fixed (hrev38498), and appears to be the root cause of your problems.
a bit of experimenting reveals that its the audio that kills mediaserver. the test file has an aac audiotrack that does not play nice when i open many videos.
I tested with the same clip without any audio, mediaplayer was churning out 12 vids happily and let me open many more and started dopping frames. no crash, no flames.
Opening the original clip with its aac track a few times blocked mediaplayer and eventually crashed media server etc.