Opened 10 years ago

Closed 4 years ago

Last modified 4 years ago

#11527 closed bug (fixed)

MediaPlayer unable to keep up with 4K video

Reported by: kallisti5 Owned by: nobody
Priority: low Milestone: R1/beta3
Component: Servers/media_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

MediaPlayer isn't able to keep up with 4k video.

Example:

Video updates around once every 10 seconds. I have a feeling this isn't due to the lack of video acceleration as shrinking the video window down doesn't result in any performance improvements. All of the CPU time is in the "frame generator" thread. (maxed out, one core)

MediaPlayer memory utilization is ~1GB

Attachments (3)

BBB_4K_UHD (101.9 KB ) - added by vidrep 10 years ago.
Interstellar_4K_UHD (131.6 KB ) - added by vidrep 10 years ago.
screenshot1.png (135.7 KB ) - added by vidrep 10 years ago.

Download all attachments as: .zip

Change History (29)

comment:1 by vidrep, 10 years ago

Some of the sites that provide 4K UHD video clips for download recommend a minimum quad core i7 for proper playback. My experience from testing AVCHD, was that you need a minimum of a core 2 duo E8500 for playback without stuttering (both CPU's at nearly 100%). I'm willing to bet an i5 is barely adequate for 4K video.

comment:2 by vidrep, 10 years ago

I downloaded a pair of 4K UHD video clips to test on my quad core i5. MediaPlayer will not play the video - there is either a black or a white screen. However, audio plays normally. I have attached a screenshot of each clip playing in MediaPlayer with latest build (hrev48404 x86_gcc2).

by vidrep, 10 years ago

Attachment: BBB_4K_UHD added

by vidrep, 10 years ago

Attachment: Interstellar_4K_UHD added

comment:3 by vidrep, 10 years ago

I finally got Haiku to pkay 4K UHD video, but I had to use an 8 core Opteron, and even with that there was not smooth playback. All 8 cores were nearly maxed out. It doesn't look like 4K is in Haiku's future until we get some hardware GPU acceleration.

comment:4 by forart.eu, 10 years ago

BBB 4K 60fps plays smootly on my i5 / Windows 8.1 + VLC 2.1.5 x64 with onchip GPU.

I believe that the Haiku "problem" is due of lacking of GPU accelleration.

comment:5 by vidrep, 10 years ago

Until we get GPU accelleration, or 12 core CPU's are the norm, I'm afraid 4K UHD is not in Haiku's future. This ticket may as well be closed, because I don't see either scenario anytime soon.

comment:6 by diver, 10 years ago

Would be interesting to try these files wikth mplayer. Hopefully, it should be available in HaikuDepot in a few days.

comment:7 by vidrep, 10 years ago

Personally, I don't think it will make a difference. As stated earlier, I did get 4K UHD playing in Haiku, using an 8 core Opteron, but even then it wasn't smooth playback. My system is upgradable to 12 core "Istanbul", and I have thought about doing this upgrade just for such experiments.

comment:8 by diver, 10 years ago

Could you please check with mplayer which is available in HaikuDepot starting from hrev49207?

comment:9 by vidrep, 10 years ago

Updated to hrev49207 x86_gcc2 Test system is an Intel Core i5 3.33GHZ with 2GB of RAM Mplayer plays the video, but the video is freezing, audio dropout and a warning "Your system is too SLOW to play this!" (see attached screenshot1) I upgraded my other test system to a 12 core Opteron. I'm willing to bet the same file will play on that system, as it did before using Haiku MediaPlayer. The issue here is not the video player, but the lack of GPU hardware acceleration and/or CPU processing power.

by vidrep, 10 years ago

Attachment: screenshot1.png added

comment:10 by diver, 10 years ago

I wonder if Unsupported PixelFormat has anything to do with the warning you are getting.

Out of curiosity, could you try QMPlay2, which uses ffmpeg 2.6 and doesn't use mplayer.

comment:11 by vidrep, 10 years ago

I'll test MPlayer and QMPlay2 this weekend and report back. Ticket #12065 is possibly related to this ticket. Is there any possibility of getting ffmpeg to 2.6 to work with the Haiku MediaPlayer? When its working, I definitely have a preference for Haiku MediaPlayer over any of the ported apps. Currently ffmpeg is broken (#11272). I have read "stippi's" article, and understand that it is not a trivial matter to update ffmpeg, and may also break compatibility with Web+.

comment:12 by vidrep, 10 years ago

hrev49244 x86_gcc2 Intel Core i5 3.33GHz 2GB RAM Interstellar-TLR_1b-5.1ch-4K-HDTN.mp4 QMPlay2 - stuttering video, good audio Mplayer - stuttering video, audio noisy and dropouts

comment:13 by vidrep, 9 years ago

Apparently there is something lacking in the ffmpeg version currently used by Haiku. Both QMPlay2 and Mplayer are using the current ffmpeg revision, and will produce video output (stuttering) when playing 4K UHD files, wheras the Haiku MediaPlayer only shows a black screen. Is this an issue with ffmpeg itself, the MediaPlayer, or something in the Haiku configuration?

comment:14 by vidrep, 9 years ago

Can somebody give a quick explanation of what may be affected by the update to ffmpeg 2.8? How does Haiku gcc2 use ffmpeg vs the gcc4 builds?

comment:15 by pulkomandy, 9 years ago

Hi,

Only the gcc4 version of ffmpeg was updated. This means only gcc4 apps get to use it. This means at least WebPositive (on youtube and other HTML5 video/audio elements), and possibly mplayer_x86? (I'm not sure if they use it).

On gcc2h, the MediaPlayer and all gcc2 apps will still use the 0.10 version. On gcc4/gcc4h/x86_64, the package has not been updated yet, but once it is, all gcc4 apps can use the 2.8 version of ffmpeg there as well.

comment:16 by diver, 9 years ago

mplayer uses built-in version of ffmpeg which is statically linked into mplayer binary, so that won't change anything for it.

comment:17 by axeld, 8 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:18 by vidrep, 7 years ago

Tested a variety of 4K UHD video clips and movie trailers using hrev51307 x86_64.

Most of these clips render reasonably well with the Haiku MediaPlayer, and in some cases better than mplayer (which has audio playback issues with these samples). I have provided links to some of the samples I tested.

wget (download) http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_native_60fps_normal.mp4

http://videos.hd-trailers.net/AFTER-EARTH_TLR-D_GEN_EN-XX_INTL_51-4K-HDTN.mp4

http://videos.hd-trailers.net/Interstellar-TLR-3-51ch-4K-HDTN.mp4

comment:19 by cocobean, 7 years ago

hrev 52012 x86_64 test. I've run some test videos for awhile and 4K videos as well. Mediaplayer displays 4K videos, but not a memory issue...moreso buffering issue at this level. Can do 1080p well, but get missing frames around 3840× 2160 and 4096 × 2160 video resolution playback - with minimal CPU/memory overhead (on my end).

Version 0, edited 7 years ago by cocobean (next)

comment:20 by waddlesplash, 6 years ago

Resolution: fixed
Status: assignedclosed

This is pretty well improved now thanks to the FFmpeg upgrade, and could only be improved further through GPU acceleration, which there is already a separate ticket about.

comment:21 by diver, 6 years ago

3dEyes just tested this again on his core i5 4400 under x86_64 Haiku hrev52958 with radeon_hd driver http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_2160p_60fps_normal.mp4

Results: QMPlay2 opens it instantly and plays the video smoothly and uses 300MB. MediaPlayer drops a lot of frames and uses 1GB of memory.

See comparison here: MediaPlayer vs mplayer vs MPV vs QMPlay2 https://www.youtube.com/watch?v=v_bLDU8z19E&feature=youtu.be

QMPlay2 is clearly a winner here.

comment:22 by diver, 6 years ago

Resolution: fixed
Status: closedreopened

comment:23 by vidrep, 4 years ago

Tested several 4K UHD video trailers with hrev54387 x86_64, then updated to hrev54389 x86_64. All now run smoothly on Intel Core i7-3770 with 16GB ram.

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

comment:24 by kallisti5, 4 years ago

Thanks for confirming vidrep! :-)

Pulkomandy pointed out a minor potential bug around audio playback... this one is definitely resolved.

comment:25 by kallisti5, 4 years ago

Milestone: R1R1/beta3
Resolution: fixed
Status: reopenedclosed

comment:26 by kallisti5, 4 years ago

(also, the fix was in hrev54839) ;-)

Note: See TracTickets for help on using tickets.