I've shared decoded ktrace with about 56s of mpv video playing to reduce it's size. I've done one more ktrace for mpv and decoded file shows only 164 sched_yield instances for me. It seems treading problem appears only in stutter times and don't related to mpv program?
Martin ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, April 3, 2020 11:06 AM, Martin Pieuchot <[email protected]> wrote: > On 03/04/20(Fri) 09:40, Martin wrote: > > > Hello, Martin. > > [...] > > When I run mpv and try to watch 720p video. In case of stutters after some > > time of watching audio flow desyncronized with video flow and mpv show > > video FPS/2 rate afterwards. > > Each time of stutter mpv increase 'Dropped' like > > A-V: 0.000 Dropped: 58++ Cahce: 1378s+154MB > > Ok so the piece of software is mpv(1). > > > I did ktrace for mpv process. I run and see by 'kdump -H ktrace.out' that > > it has > > one process ID and / mostly one-three thread used. > > But sometimes (assuming in stutter times) it jumping against treads with > > different numbers. > > Could you upload the output of kdump -H somewhere such that I could look > at it or compress it and send it? > > > Yes, IPI increased to 900-1000 when stutter appears. > > I'm going to disable step-by step each 'out of the box' software to > > determine the reason. Am I right doing this way? > > I believe it isn't necessary. From what you are saying it seems that > mpv(1) alone is the piece of software exposing the issue. > > There are multiple possible reasons for IPIs, but if the high rate > you're seeing is exposed by mpv(1), it would suggest they are related > to scheduling. > > By looking at the output of ktrace(1) we should have a better > understanding of what is happening in userland. I'd suggest you also do > the btrace(8) profiling so we can see which code path in the kernel is > responsible for the IPIs. These should allows us to work with facts and > not guesses. > > Thanks for your efforts, > Martin
