[mythtv-commits] Ticket #5749: Internal player stutters on 720p content

[MythTV]

#5749: Internal player stutters on 720p content
--------------------------------+-------------------------------------------
 Reporter:  zgeggy2k at yahoo.com  |        Owner:  janne     
     Type:  defect              |       Status:  assigned  
 Priority:  major               |    Milestone:  unknown   
Component:  Video Playback      |      Version:  0.21-fixes
 Severity:  medium              |   Resolution:            
  Mlocked:  0                   |  
--------------------------------+-------------------------------------------

Comment(by zgeggy2k at yahoo.com):

 Replying to [comment:9 janne]:
 > The patch just increases the buffer size. it's very unlikely that it
 fixes a problem itself.
 >
 > I can't reproduce the stuttering with unpatched trunk. both good.mpg and
 bad.mpg play perfectly fine here.
 >
 > So I suspect that your processor is not fast enough to handle spikes of
 cpu usage during decoding. More buffered frames give obviously more time
 to catch up and fixes the problem.
 >
 > Increasing the buffer size for everyone is obviously not the right
 solution. Since this seems to be a common problem with 720p (60 real
 frames per second) video it might make sense to make buffer time constant
 and not frame constant.
 >
 > Does the increasing the number of video buffers alone fixes the problem,
 i.e. only applying the libs/libmythtv/videoout_xv.cpp hunk?

 I know you're replying to dl, but I'll give my 2 cents: I think that if it
 was a CPU-constrained issue, I'd see CPU usage being maxed out via either
 ntop or vmstat. In my case, the stuttering happens and I am nowhere near
 100% CPU usage (of course, that could be a side effect of the stuttering:
 stutter -> skip -> don't decode -> don't use CPU).

 2 other things that make me think it's not CPU related:
 - it (the 720p recording) plays without a glitch in mplayer (and still has
 plenty of CPU left)
 - 1080i content _with_ a deinterlacer (bob 2x) enabled plays fine as well
 (and again, still plenty of CPU left)

 When you tried to reproduce the problem did you use Fedora 9? (I'm
 wondering if libs/kernel that the frontend relies on have a specific
 behaviour).
 Maybe a scheduler issue (they may have introduced the "Completely Fair
 Scheduler"), but again, without CPU maxed out, it shouldn't be an issue,
 unless there's added latency when switching tasks that would make the
 frontend miss its deadlines.

 One thing I haven't tried is running it as root _with_real_time_priority_
 settings (which hopefully even CFS would honor). I'll give it a try.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/5749#comment:10>
MythTV <http://www.mythtv.org/>
MythTV