[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 dl-mythtv at catspoiler.org):

 Replying to [comment:9 janne]:
 > The patch just increases the buffer size. it's very unlikely that it
 fixes a problem itself.

 Agreed, there is something else going on here.  This patch does work
 around the problem so that 720p material is now watchable again.

 > 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.

 I don't think it's a CPU usage problem.  I did not see this problem when I
 was running 0.21-fixes on Fedora 7 on the same hardware.  The problem only
 occurred after I upgraded to Fedora 9.  Recordings made before the upgrade
 are now unwatchable after the upgrade without this patch.  Idle time in
 top is 70% to 80% during playback.  Mythfrontend averages about 50% CPU
 time and Xorg averages about 35% CPU time.  With a 0.1 second update time,
 I only see rare spikes above 70% CPU usage for mythfrontend.  CPU usage is
 actually higher when playing 1080i material, with only about 50% idle
 time,

 In my case, it looked a lot like the speed of decoding was limited by the
 availability of available video buffers.  Take a look at the log file that
 I previously attached.  It's possible to determine from the log how many
 video frames are buffered, but the amount of buffered audio data is
 captured in the log.  The thing that caught my attention is that video
 frames were being decoded at about the right rate to match 60 fps
 playback.

 > 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.

 Possibly, though it really depends on how bursty the audio data is in the
 data stream.  Is there any specification that says that transmitting
 video-only for 10 seconds followed by the matching audio is illegal?  If
 this is a valid stream, then a lot more buffering would be required for
 clean playback.

 My suspicion is that the problem has something to do with video vs. audio
 sync.  The buffered audio data is drained at a constant rate by the
 soundcard.  The buffered video data is drained at the frame rate, with
 some adjustments that are intended to maintain synchronization between the
 video being displayed and the audio data being played.  If the player
 thinks there is too much delay in the audio path, then it will slow down
 the video playback, causing decoded video data to back up in the buffers
 and slowing down the decoding thread.  That being said, it looks like sync
 would have to be off by ~500ms in the log file that I attached, but the
 playback sync looks a lot better than that.

 > Does the increasing the number of video buffers alone fixes the problem,
 i.e. only applying the libs/libmythtv/videoout_xv.cpp hunk?

 It fixes 720p playback for me, but breaks 480i and 1080i playback.
 Without the extra audio buffering, I get audio buffer overruns and the
 video looks like it is being fast forwarded.  The decoding thread will
 wait for video buffer space to become available, but if there isn't
 sufficient audio buffer space it just tosses the audio data away.

 The AUDBUFSIZE change is not sufficient on it's own.  I had to also make
 the audbuf_timecode change as well to fix the audio overrun problem.  I
 did not try the audbuf_timecode change without the AUDBUFSIZE change.

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