therain7
commented
3 years ago "Unoptimized" 1.1.2 actually uses less cpu (100-160%)
Open therain7 opened 3 years ago
therain7
commented
3 years ago "Unoptimized" 1.1.2 actually uses less cpu (100-160%)
therain7
commented
3 years ago 
here it is. temp jumps up to 80° Celsius.
heyitsarpit
commented
3 years ago I just ran VLC, IINA and QuickTime on a mp4 video to see the cpu consumption in the activity monitor.
| IINA | VLC | Quicktime |
|------|------|-----------|
| ~20% | ~15% | ~7% |Device is MacBook Air M1 (16 GB Ram | 7 Core GPU | 512 SSD)
therain7
commented
3 years ago I have an 8/256 version, I don't think it matters tho. I don't know about 1080p mp4 video. I get these high numbers when I play 4k mkv file. Vlc works fine in the same scenario loading processor only to about 20%.
therain7
commented
3 years ago Maybe there's something wrong with my file. I ran Elmedia on this file and it was also loading the processor to 150%
EugBtnr
commented
3 years ago 8/256 M1 air and with a 1080p MKV file i got 132% on the activity monitor..also 82 temp..with VLC on the same video i got 33% CPU and 42 temp.
HarukaMa
commented
3 years ago A process sample could be helpful when pinpointing the issue (Activity Monitor - Sample Process)
dima-xo
commented
3 years ago Attached Process Sample. In VLC the same video consumes 4 times less CPU. In QuickTime it is almost 10 times less.
dcervenkov
commented
3 years ago I just ran VLC, IINA and QuickTime on a mp4 video to see the cpu consumption in the activity monitor.
| IINA | VLC | Quicktime | |------|------|-----------| | ~20% | ~15% | ~7% |Device is MacBook Air M1 (16 GB Ram | 7 Core GPU | 512 SSD)
I'm seeing pretty much the same results on M1 Air with a H264 MPEG-4 AVC file. I'm attaching my sample of IINA. Sample of IINA.txt
HarukaMa
commented
3 years ago @dcervenkov Looks like the main CPU consumer is the progress bar drawing and MPV demux thread reading the file. Could you try to see if MPV also uses higher CPU?
dcervenkov
commented
3 years ago @HarukaMa Yes, MPV uses about the same CPU as IINA (maybe a bit higher, even). Sample of mpv.txt
low-batt
commented
2 years ago I have a Mac with a M1 chip on order, so I may soon experience this issue as well.
With respects to the time spent drawing the progress bar. From a quick glance at the spindump posted by dima-xo it feels like the drawing of the slider is a significant issue. Looking closely shows 197 samples out of 1678 in the main thread run loop:
197 __CFRunLoopRun (in CoreFoundation) + 845 [0x7fff2043dd94]Whereas 1518 of the 1547 samples in the mpvgl thread are in the ViewLayer.draw method:
1518 @objc ViewLayer.draw(inCGLContext:pixelFormat:forLayerTime:displayTime:) (in IINA) + 33 [0x1025101e1]So the drawing of the slider is secondary to the issue at hand. Still, it is important because this is happening while the onscreen controller is hidden, so 100% of the time drawing the slider is wasted energy.
The proposed changes I have submitted for issue #548 include a custom slider whose draw method checks to see if the slider is hidden and if it is, then it does not draw the slider.
From a quick imperfect test on an Intel MacBook Air before the change:
Thread 0x47f5db DispatchQueue "com.apple.main-thread"(1) 821 samples (1-821)
cpu time 0.354s (478.8M cycles, 194.5M instructions, 2.46c/i)The main thread after the change:
Thread 0x47dc08 DispatchQueue "com.apple.main-thread"(1) 747 samples (1-747)
cpu time 0.147s (207.4M cycles, 52.1M instructions, 3.98c/i)Full traces for the main thread below. There is still time being spent in the main thread because other portions of the onscreen controller are still being updated. It should be possible to improve the performance a little more with changes that directly address the updating of the onscreen controller while hidden. The changes for #548 were not intended to address this, it just made sense for the custom slider to not draw if the slider is not visible.
System and IINA version:
Actual behavior: IINA loads my m1 cpu up to 300% while playing 4k video. I don't think that's normal.