Internal player stutters on 720p content

[zgeggy2k@…]

Hi,

I recently moved to a new HTPC so I decided to upgrade my Fedora 8 install of mythtv to Fedora 9. I currently have this installed on fedora 9: mythtv-0.21-192.fc9.i386 (along with the rest of the pkgs) from livna (pkgs from atrpms exhibit the same behaviour).

The new HTPC is based on a Gigabyte Mobo GA-73PVM-S2H, which I connect to my receiver via HDMI and SPDIF. I'd get rid of SPDIF (and use solely HDMI) if there was support for Audio over HDMI from nvidia, but since there isn't, I'll stick to 2 cables for now. The box has 2 Gigs of RAM, core2duo E7200... enough to handle HD I think (especially since it's mpeg2, not h264... read below).

Anyway: I am experiencing issues with playback of some content. This content is recorded through an HD Homerun dual tuner box. With some interlaced content, it seems the player tries to set the playback rate at ~30fps and that works.

With progressive content (720p I think), I get lots of "WriteAudio?: buffer underrun" errors, and the content is unwatchable. Video slows to a crawl, sound goes sporadically out to the receiver so I do hear some audio (for half a second or so) randomly during playback. It seems like (from the log) that the player wants to hook to 60fps (well 59.something).

Now, I tried to see if it wasn't a sound config issue (got rid of pulseaudio, just using alsa now), and an nvidia issue (for video sync'ing)... didn't make a difference. What tells me it's mythtv specific is that I can play this file beautifully out of my recordings directory directly with mplayer. No stuttering, low CPU usage... no problem with any recording with mplayer.

I've played around with mythtv options: extra audio buffering, etc... no joy! Even increased alsa buffers from 64 to 1024 in /proc -> nothing.

So I'm stuck, and it seems so is this guy: URL:http://www.gossamer-threads.com/lists/mythtv/users/349458

Will attach cases (logs+samples) for a successful playback (interlaced) and a broken one. Let me know if there's any other tests I can run.

Thanks.

Output of mythfrontend --version:

Please include all output in bug reports. MythTV Version : 0.21-7.lvn9 MythTV Branch : tags/release-0-21 Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in:

linux release using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_opengl_vsync using_opengl_video using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live

[zgeggy2k@…]

Attachments are limited to 256K so the files are available here: ​http://www.mediafire.com/?fm2jigbzhy2 ​http://www.mediafire.com/?ixt4n3bsm9z ​http://www.mediafire.com/?tt1yhmhs7ja ​http://www.mediafire.com/?jruuilzzyjd

[anonymous]

I have what I believe is the same issue. I'm running 0.21-fixes on FC9 on an AMD X2 6000. Pulseaudio is disabled. I can play standard def shows and 1080i but any 720p content stutters the audio. I've tried different playback profiles and enabling/disabling xvmc. Mplayer can play all of these fine.

[bmurphy1976@…]

I believe I have the same problem, recording with a pcHDTV 5500 card and playback with an Nvidia Geforce FX 5200. Major stuttering issues when I play 720p content.

I can provide additional debugging data points if required.

[zgeggy2k@…]

Yesterday I tried svn code to rule out any packaging issues: built from sources from the svn 0.21+fixes branch and also trunk as of yesterday 9/28/08. Same result!

That's another data point - hopefully useful for the devs. This means you should hopefully be able to reproduce the problem on a trunk build + the recordings I provided in my bug submission.

A workaround would be very welcome as well (if there's a way to override some of the player behaviour somehow).

Let me know if I can help debug this further.

[dl-mythtv@…]

Same problem here with 720p material 0.21-fixes on FC9 with an Athlon64 X2 4000+ on an Abit AN-M2 HD motherboard using the onboard Nvidia graphics.

It appears the the problem occurs when AvFormatDecoder::GetFrame?() is processing a large number of sequential video packets without any intervening audio packets, and the audio output buffers drain. I don't know if the problem is that the loop that calls vFormatDecoder::GetFrame?() is taking too long, or if it is being blocked by a shortage of video buffer space. In the log file excerpt that I will attach, the last "audio timecode" is processed at 18:52:51.807, the internal audio buffer is empty by 18:52:52.047, and the sound card buffer is empty by 18:52:52.385. The next "audio timecode" does not occur until 18:52:52.776.

$ mythfrontend --version Please include all output in bug reports. MythTV Version : 17961M MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in:

linux release using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_opengl_vsync using_opengl_video using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_glx_proc_addr_arb using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live

[dl-mythtv@…]

mythfrontend --verbose log showing audio buffer underrun

[dl-mythtv@…]

I forgot to mention that an older version of 0.21-fixes did not have this problem with 720p material on the same hardware when it was running Fedora 7. Old recordings from before the upgrade now stutter after the upgrade.

[dl-mythtv@…]

Replying to dl-mythtv@catspoiler.org:

Same problem here with 720p material 0.21-fixes on FC9 with an Athlon64 X2 4000+ on an Abit AN-M2 HD motherboard using the onboard Nvidia graphics.

It appears the the problem occurs when AvFormatDecoder::GetFrame?() is processing a large number of sequential video packets without any intervening audio packets, and the audio output buffers drain. I don't know if the problem is that the loop that calls vFormatDecoder::GetFrame?() is taking too long, or if it is being blocked by a shortage of video buffer space. In the log file excerpt that I will attach, the last "audio timecode" is processed at 18:52:51.807, the internal audio buffer is empty by 18:52:52.047, and the sound card buffer is empty by 18:52:52.385. The next "audio timecode" does not occur until 18:52:52.776.

The problem does appear have something to do with a shortage of video buffering. In this log file, there nearly a one second gap between audio packets, so depending on the phase relationship between the audio and video streams, we might need to buffer up to one second of video to get to the next audio sample before the audio buffer empties. What's different about 720p is that the frame rate is ~60fps instead of ~30fps for 480i and 1080i, so twice as many video frames might need to be buffered for clean playback of 720p material. I dug through the code and found that only 31 buffers are allocated, which is less than 1/2 second after all the overhead is subtracted.

As a quick and dirty hack, I doubled the number of video buffers, which "fixed" 720p playback. This broke SD and 1080i playback, which looked like it was being fast forwarded, and mythfrontend reported massive numbers of "Audio buffer overflow, audio data lost!" errors. I "fixed" this by doubling the audio buffer size and increasing the allowable audio timecode difference.

I have no idea why this problem only seems to affect Fedora 9 ...

My patch for this, "stutter.patch", will be attached momentarily ...

[dl-mythtv@…]

Quick and dirty "fix" for audio stuttering during 720p playback, gzipped so that I could attach it

[anonymous]

This fixes the problem with audio on 720p videos. Also tested to work with 480i videos.

[Janne Grunau]

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?

[zgeggy2k@…]

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

[Andreas <miscdreas@…>]

I have set up a test system with openSUSE 11.1 (Beta2) and I see the same video stutter roughly every 1 to 1.5 seconds with 720p60 content. The patch posted by dl fixed that problem with my version of 0.21.fixes (Revision 17789).

As Janne asked for a test with current trunk and increased video buffers, I updated the test system to 0.22trunk (Revision 18525) and changed just the line with videobuffers in the source code. Now 720p60 content does not show any stutter, and the other recordings I have (plain NTSC SD and 1080i30) are playing without problems, too.

I did not think the stutter was CPU related. When playing 720p60 recordings, I usually see a CPU load of ca. 50% for mythfrontend and 20% for X on my Pentium4. But when I run top with d 0.1 for an update every 1/10th of a second, I see spikes of up to 120% for mythfrontend.

[dl-mythtv@…]

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

[Andreas <miscdreas@…>]

Replying to Andreas <miscdreas@dslextreme.com>: I should add that I run the same mythtv revision, on the same computer, with the same mythconverg database, but without any playback problems when I boot into openSUSE 10.3. The two major differences: the kernel version (2.6.22.18 vs. 2.6.27) and the graphics card driver (ati's fglrx vs. Xorg's radeon).

[Janne Grunau]

An important difference between Fedora 7 and Fedora 9 is pulseaudio. Opensuse 11 introduces pulseaudio too.

Is the stuttering fixed if pulseaudio is disabled?

[gigem]

Replying to janne:

An important difference between Fedora 7 and Fedora 9 is pulseaudio. Opensuse 11 introduces pulseaudio too.

Is the stuttering fixed if pulseaudio is disabled?

I'm not running pulseaudio and you know I have the stuttering problem so that's not it.

[dl-mythtv@…]

Replying to janne:

Is the stuttering fixed if pulseaudio is disabled?

My understanding is that pulseaudio isn't enabled unless and entry for it is added to /etc/asound.conf or ~/.asoundrc, Neither of these files is present on my machine, and no pulseaudio entries are reported by "aplay -L":

$ aplay -L default:CARD=NVidia

HDA NVidia, ALC883 Analog Default Audio Device

front:CARD=NVidia,DEV=0

HDA NVidia, ALC883 Analog Front speakers

surround40:CARD=NVidia,DEV=0

HDA NVidia, ALC883 Analog 4.0 Surround output to Front and Rear speakers

surround41:CARD=NVidia,DEV=0

HDA NVidia, ALC883 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers

surround50:CARD=NVidia,DEV=0

HDA NVidia, ALC883 Analog 5.0 Surround output to Front, Center and Rear speakers

surround51:CARD=NVidia,DEV=0

HDA NVidia, ALC883 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers

surround71:CARD=NVidia,DEV=0

HDA NVidia, ALC883 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers

hdmi:CARD=NVidia,DEV=0

HDA NVidia HDMI Audio Output

null

Discard all samples (playback) or generate zero samples (capture)

I'm also using AC3 passthrough to the S/PDIF output, which I believe should bypass pulseaudio, the external mixer, etc, but I get exactly same result without AC3 passthrough and sending the sound either to the S/PDIF output or to the analog outputs. I detect no difference in behavour if I kill the pulseaudio daemon.

The only thing I haven't tried is actually removing pulseaudio entirely.

[Andreas <miscdreas@…>]

Replying to dl-mythtv@catspoiler.org:

Replying to janne:

Is the stuttering fixed if pulseaudio is disabled?

The only thing I haven't tried is actually removing pulseaudio entirely.

I just did that (completely removing pulseaudio). The buffer underrun and the video stutter are as bad as before.

Let me know if I should attach any log or debug output.

[zgeggy2k@…]

Confirmed here too. I completely removed (i.e. yum remove) and not just disabled pulseaudio to make sure it wasn't interfering. Same symptoms.

[Janne Grunau]

Ok, I'm convinced that PulseAudio? is not to blame.

[dl-mythtv@…]

Replying to janne:

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.

It should be possible to adaptively set the number of buffers. If the decoder thread would block due to a lack of buffers and there is less than a certain threshold amount of buffered audio data, then add another video buffer instead of waiting for an existing buffer to be made available. Tuning the minimum audio buffer threshold would be a bit tricky because it would depend on how quickly the decoder thread could process the stream until it finds more audio data.

[Janne Grunau]

The problem is that the audio data is 600-700 ms delayed in the stream. That's too much for 31 buffers at 60 Hz. Increasing the count of video buffers is not the solution. The number is already quite high in terms of memory usage.

I'll work on fixing the issue. In the meantime increasing the video buffers are a workaround. I guess that 45-50 is a reasonable number.

[Janne Grunau]

please test if t5749_enable_storing_video_pkts.diff fixes the issue.

[dl-mythtv@…]

audio underrun while playing 720p after applying t5749_enable_storing_video_pkts.diff

[dl-mythtv@…]

Replying to janne:

please test if t5749_enable_storing_video_pkts.diff fixes the issue.

I still get stuttering and audio underruns with this patch. See mythfrontend.log.t5749_enable_storing_video_pkts.diff.

[dl-mythtv@…]

audio underrun while playing 720p after applying t5749_enable_storing_video_pkts.diff (second try)

[zgeggy2k@…]

I tried dl's patch in 2 ways:

1) just the video buffers patch (videoout_xv.cpp): This made 720p work well, but 1080i recordings where still exhibiting stuttering issues

2) the whole patch (including also audio buffer changes): This made 720p and 1080i recordings play well. I haven't had a chance to test a lot of different material but I'll be running this for a while and report if I see any issue.

[dl-mythtv@…]

playback-only log file from start of playback

[gigem]

Replying to janne:

please test if t5749_enable_storing_video_pkts.diff fixes the issue.

This patch doesn't change the stuttering for me either.

[Janne Grunau]

I still can't reproduce the issue. The closest I come to reproduce the issue is AV-Sync messages for the first couple of frames but after that it plays the samples perfectly. with 0.21-fixes, trunk and trunk+ffmpeg sync.

Please test t5749_verbose.diff and attach the log of mythtv $FILE playing for 20-30 seconds.

[gigem]

Replying to janne:

Please test t5749_verbose.diff and attach the log of mythtv $FILE playing for 20-30 seconds.

Here you go.

[Janne Grunau]

Replying to gigem:

Replying to janne:

Please test t5749_verbose.diff and attach the log of mythtv $FILE playing for 20-30 seconds.

Here you go.

Thanks, the stored video pkts get discarded, interesting. I don't see that here.

[Janne Grunau]

the same again please with t5749_storedpackets_verbose.diff applied

[gigem]

Replying to janne:

the same again please with t5749_storedpackets_verbose.diff applied

Will od so tonight unless someone else beats me to it.

[gigem]

Replying to janne:

the same again please with t5749_storedpackets_verbose.diff applied

Done.

[Janne Grunau]

and again, it looks like the audio is to blame. It stores compressed video frames until AV-sync is should be ok. but fails then to decode/play the audio properly.

[gigem]

Replying to janne:

and again, it looks like the audio is to blame. It stores compressed video frames until AV-sync is should be ok. but fails then to decode/play the audio properly.

As soon as we get the audio 100ms ahead of the video, we start consuming the stored video packets. The problem is that we then continue consuming the stored video packets until they are exhausted. In the mean time, we run out of audio data and get the underruns. We need to detect when we are running out of audio data and start storing video packets again until we get more audio data.

[wstewart@…]

I seem to have the same problem. The picture flickers and audio is unintelligle. The bottom half of the screen seems to flicker repeated on the top half. Similar messages in the log to everyone else.

What I have found, if I go to playback settings, turn off "Use opengl for vertical sync", the picture is then fine. If I then go back and turn on "Use opengl for vertical sync", the picture is again fine. Restart mythtv with this option on or off and the flicker is back. Perhaps it is an initialization issue.

For me, nothing of the linux distribution changed nor the Nvidia driver. My only change is upgrading from 0.21-fixes (before ffmpeg update for H264) to SVN. Could it have something to do with the recent ffmpeg update?

[Andreas <miscdreas@…>]

playback with patch t5749_proposed_fix.diff applied

[Janne Grunau]

(In [18661]) use a epsilon when comparing floating point aspect ratios. Refs #5749

[Janne Grunau]

(In [18664]) Limit the number of queued video frames explicitly and not by audio video pts difference

fixes playback of streams with high AV offset Fixes #5749 debugged by David Engel

[Janne Grunau]

(In [18665]) Merges revision [18661] from trunk: use a epsilon when comparing floating point aspect ratios. Refs #5749

[Janne Grunau]

(In [18666]) Merges revision [18664] from trunk: Limit the number of queued video frames explicitly and not by audio video pts difference

fixes playback of streams with high AV offset Fixes #5749 debugged by David Engel