Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#9344 closed Bug Report (Unverified)

Playback stuttering under 0.24 when playing h264 material with VDPAU

Reported by: enigma@… Owned by: markk
Priority: minor Milestone:
Component: MythTV - Video Playback Version: 0.24-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

When playing back h264 from an HD-PVR with VDPAU I am experiencing stuttering when the audio pauses to allow the video to catch up. This behavior did not occur under 0.23-fixes. SD and HD MPEG sources are both working properly, I am only seeing the issue with h264 material. I have a clip of source material that exhibits the issue at http://www.thedonnerparty.com/stutter_clip.mpg and have attached a frontend log with -v audio,playback enabled. The machine in question is a Dell desktop with a 8400 GS PCI video card. Other frontends using both VDPAU and software decoding are able to play back the material successfully. Please let me know what other information is necessary to identify the issue.

Attachments (6)

mythfrontend.log (52.6 KB) - added by enigma@… 3 years ago.
frontend log with playback and audio debug enabled
mythfrontend-1.log (71.4 KB) - added by enigma@… 3 years ago.
Playback log showing issue, #1
mythfrontend-2.log (77.6 KB) - added by enigma@… 3 years ago.
Playback log showing issue, #2
mythfrontend-3.log (57.0 KB) - added by enigma@… 3 years ago.
Playback log showing issue, #3
nvidia-settings-dump.txt (24.5 KB) - added by enigma@… 3 years ago.
nvidia settings dump captured during playback
version_info (735 bytes) - added by wagnerrp 3 years ago.
attaching as a file, as the text says to

Download all attachments as: .zip

Change History (40)

Changed 3 years ago by enigma@…

frontend log with playback and audio debug enabled

comment:1 Changed 3 years ago by robertm

Clip plays with no stutter or obvious playback issue here.

comment:2 Changed 3 years ago by markk

The clip you've provided is 1080i@30fps whereas the log is for a 720p@60fps clip. Can you either upload the same clip or update the log.

Do you have closed captioning enabled? Thanks

comment:3 Changed 3 years ago by enigma@…

Doh! I accidentally used a different recording to create the clip, I have updated the clip to be from the same recording as the log. I do not have CC enabled.

comment:4 Changed 3 years ago by stuartm

What CPU are you using?

What do the following commands produce?

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

comment:5 Changed 3 years ago by enigma@…

model name : Intel(R) Celeron(R) CPU 2.53GHz
cpu MHz : 2526.774

I don't think this CPU supports scaling:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor produces cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: No such file or directory and /sys/devices/system/cpu/cpufreq is empty.

comment:6 Changed 3 years ago by markk

  • Owner changed from janne to markk
  • Status changed from new to accepted

comment:7 Changed 3 years ago by markk

Can you confirm what Qt version you are using (mythfrontend --version).

The linked clip plays without a problem here using the same card and driver version. The cpu is more powerful, so I also tested on my ion frontend that has a similar driver version and, again, it plays smoothly.

I'm pretty confident that this isn't a VDPAU issue, not least because the VDPAU video code barely changed between 0.23 and 0.24.

A lot of the other video playback code has however changed in that time, as well as many other mythfrontend and mythbackend behaviours, any of which has probably changed the demands placed on the system.

The most 'interesting' thing in the log is that playback is fine for 20 seconds or so before starting to go wrong. This strongly suggests that either the CPU or GPU is settling down to a lower performance level after the initial 'hit' from starting to play the file. Almost every other problem (audio, decoder performance, network issue etc) would give you playback problems right from the start.

The only other thing that springs to mind is that you have a single core CPU, which may not be handling the threading too well (but I see at least one other person with the same problem who is not running a single core machine)

So, a couple more requests:-

  • can you grab a couple of other playback logs and confirm the same trend - starts fine, then breaks.
  • please double check your system setup and logs and see if there is anything that might indicate what changes 20 seconds into the video.

thanks, Mark

Changed 3 years ago by enigma@…

Playback log showing issue, #1

comment:8 Changed 3 years ago by enigma@…

I have attached logs from playing 3 different recordings that exhibit the problem. The third one seemed to play a little better than the first two but did start to skip after a while. I do not see anything in dmesg/messages/daemon.log/kern.log that seem to happen at the same time as the issue. This machine runs mythfrontend only, I do not see any processes running that should not be. Watching top during playback does not show very much CPU load or iowait. nvidia-settings indicates the performance mode is set to "Maximum Performance". The GPU temperature varies from 45-50 degrees C. I have also attached the output of "nvidia-settings -q all" captured while playing back a problem recording.

Last edited 3 years ago by wagnerrp (previous) (diff)

Changed 3 years ago by enigma@…

Playback log showing issue, #2

Changed 3 years ago by enigma@…

Playback log showing issue, #3

Changed 3 years ago by enigma@…

nvidia settings dump captured during playback

Changed 3 years ago by wagnerrp

attaching as a file, as the text says to

comment:9 Changed 3 years ago by ignissport@…

I've experienced this when playing Big Buck Bunny in h.264 @ 1080p (plus any other 1080 content)

The file is large (700mb for 10 minutes of video), but it's readily available:
http://www.bigbuckbunny.org/index.php/download/

I'm in the same boat. VDPAU, plays with very low CPU utilisation (~7%, loadavg: 0.6 - 0.9; sometimes exceeds 1.0) and stutters. Played fine under 0.23-fixes. SD content (<= 576p) has always played fine.

Also get jitter on MPEG-2 1080i DVB-PAL content. Mine also jitters immediately. No 20 sec delay.

Basic setup:

Athlon X2 4200+
NVidia G210

Mythbuntu 10.10 (Maverick)
  + ubuntu-x-swat/x-updates ppa
  + mythbuntu/0.24 ppa
  + medibuntu ppa
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
1000000

MythTV Version   : df2d58b
MythTV Branch    : fixes/0.24
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.7.0

comment:10 Changed 3 years ago by stuartm

ignissport, yours is probably a known limitation of vdpau on Athlon systems, try "echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq" as root. Please take further discussion of this problem to the -users mailing list since it's not related to this bug or really even to MythTV.

comment:11 Changed 3 years ago by wagnerrp

The above concern about the clock scaling is for certain IGP chipsets only. Video chipsets that access shared system memory through the CPU memory controller will be starved for bandwidth when the CPU downclocks. A discrete card, and especially a PCI one without the possibility for 'turbocache', should not be suffering from that issue.

comment:12 Changed 3 years ago by markk

  • Status changed from accepted to infoneeded

Can you please update to the very latest fixes/0.24 and see if there is any improvement in playback.

(at least SHA: cfd7b7877b5dc8b25dd2)

comment:13 Changed 3 years ago by markk

  • Milestone changed from unknown to 0.24.1
  • Version changed from 0.24 to 0.24-fixes

comment:14 Changed 3 years ago by jd@…

Since upgrading to 0.24(+fixes), I'm suffering the same problems with stuttering audio on HD PVR recordings.
Before, with 0.23+fixes this material was playing without problems on the same hardware (ION 330+VDPAU).

The recordings itself are fine. I can play them with XBMC via MythTV's UPnP perfectly on the same hardware.

Platform: Intel(R) Atom(TM) CPU 330 @ 1.60GHz

MythTV: 2:0.24.0+fixes.20101223.196943c-0ubuntu2

comment:15 Changed 3 years ago by ignissport@…

It's definitely not the AMD cpu clock issue for me. I've tried that, along with everything else listed in the troubleshooting on the wiki (http://www.mythtv.org/wiki/VDPAU)

After a lot of playing around, I can confirm that this stutter only occurs when I have TwinView? enabled. I have two TVs; one on DVI running 1080p@60Hz, and the one on HDMI running 1080i@60Hz. The TV OSD tells me 60Hz, but xrandr tells me 50Hz, regardless of whether twinview is enabled or not. I don't think that's the problem though, at it still happens with TwinView? enabled.

Section "Device"
        Identifier      "Configured Video Device"
        Driver          "nvidia"
        Option "TwinView"       
        Option "TwinViewOrientation"    "Clone"
        Option "UseDisplayDevice"       "DFP-0,DFP-1"
        Option "NoLogo"                 "True"
	Option "UseEDIDDpi" 		"False"
	Option "TripleBuffer"		"True"
	Option "UseEvents"		"True"
EndSection

Section "Monitor"
	Identifier	"Configured Monitor"
	Option		"DPMS"
EndSection

Section "Extensions"
	Option "Composite" "Disable"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	Device		"Configured Video Device"
	DefaultDepth    24
	SubSection "Display"
		Depth   24
		Modes   "1920x1080" "1280x720" "640x480"
	EndSubSection
EndSection
$ xrandr -d :0 | head -n 3
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 175, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 0mm x 0mm
   1920x1080      50.0*    53.0     54.0     55.0     56.0     57.0     58.0     59.0     60.0  

comment:16 Changed 3 years ago by ignissport@…

Forgot to mention, I've updated to include the prior fix:

MythTV Version   : 21b99f1
MythTV Branch    : fixes/0.24
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.7.0

comment:17 Changed 3 years ago by markk

When using the nvidia proprietary driver, xrandr will not give you the actual refresh rate.

The most reliable way I've found to check what is actually happening is to use glxgears (ensuring first that you have opengl sync to vblank enabled in nvidia settings) and ensure it shows roughly 50 or 60fps (or at least something reasonable).

Then use nvidia settings to switch the rate to something else, exit nvidia settings and try glxgears again.

If the actual rate isn't changing, then go back into nvidia settings and ensure 'Force Full GPU scaling' is NOT enabled.

I'm betting that it is and once you've turned it off, all we be good again.

comment:18 Changed 3 years ago by ignissport@…

markk,

I think you're onto something there, but the GPU scaling is turning itself on (without being asked) because my secondary panel only supports 1080i input, and the primary is running 1080p. The GPU must interlace the second screen, otherwise the second screen would not cope with the signal. Perhaps I need a better TV.

OP might want to confirm if this is also his problem.

comment:19 follow-up: Changed 3 years ago by enigma@…

ignissport, I don't think that is what is causing my problem, since you state that you only see the issue when you have TwinView? enabled and I don't use that feature. I am seeing the issue on 2 different displays, a 720p plasma set and a 1080p monitor.

comment:20 in reply to: ↑ 19 Changed 3 years ago by markk

Replying to enigma@…:

ignissport, I don't think that is what is causing my problem, since you state that you only see the issue when you have TwinView? enabled and I don't use that feature. I am seeing the issue on 2 different displays, a 720p plasma set and a 1080p monitor.

Did you actually try it out? Forget everyone else's problems and setups, this is your ticket and I'd like know if the proposed fix worked for you.

comment:21 Changed 3 years ago by qeldroma@…

Just to be sure: Everyone is talking about using the internal videoplayer, right? Not mplayer.

comment:22 Changed 3 years ago by ignissport@…

I was using the internal player, although my problem is most likely the nVidia driver.

comment:23 follow-up: Changed 3 years ago by enigma@…

Yes, I am using the internal player. I have upgraded the frontend in question (as well as the other 6 Myth machines that needed to be upgraded alongside it) to v0.24-204-g7a6eab8. I am still seeing the issue with h264 recordings. I do not have a 'Force Full GPU scaling' option in nvidia-settings, is this something that was added in later versions or perhaps an option my card does not support?

comment:24 in reply to: ↑ 23 ; follow-up: Changed 3 years ago by markk

Replying to enigma@…:

Yes, I am using the internal player. I have upgraded the frontend in question (as well as the other 6 Myth machines that needed to be upgraded alongside it) to v0.24-204-g7a6eab8. I am still seeing the issue with h264 recordings. I do not have a 'Force Full GPU scaling' option in nvidia-settings, is this something that was added in later versions or perhaps an option my card does not support?

According to your earlier logs, you are running exactly the same card and driver as I am using now. In nvidia-settings, there should be a section titled something like GPU 0 - (GeForce? 8400GS) and in that section there should be a section with details on your monitor/panel - mine is called DFP-0 (Samsung SyncMaster?). In that section is an option called 'Force Full GPU scaling'.

That section may however only be available for digitally (i.e. dvi/hdmi) connected monitors - are you using VGA?

comment:25 in reply to: ↑ 24 ; follow-up: Changed 3 years ago by enigma@…

Replying to markk:

That section may however only be available for digitally (i.e. dvi/hdmi) connected monitors - are you using VGA?

Yes, both the TV and my test monitor are using VGA. I notice NVidia has a "scaling" property in FlatPanelProperties?, I can set that to "native" in xorg.conf but I don't know if it having an effect.

comment:26 Changed 3 years ago by robertm

  • Status changed from infoneeded to assigned

comment:27 Changed 3 years ago by mo.ucina@…

Hello Guys ,

My bug 9694 has been classified as the duplicate of this one . So I will attach to this case my observations , to keep all information in the same place .

27/03/2011
I have just upgraded to v0.24-231-gc2baf1b via ATRPMS package to find that on fc14 32bit and my Live Tv playback was really bad . The picture kept freezing or slowing in short intervals and audio was repeating over and over again . I did fall back to original version v0.24-199-g5367795 and everything was fine again . I tried to upgrade a few times with different methods and every time when on the newer software it would happen , sometimes straight away , other time on the next channel change . At the moment I am on v0.24-199-g5367795 and all is well .

17/04/2011
I have upgraded my installation to rev v0.24-238-g2a9d9f5 . After upgrading I rebooted the pc , then using LiveTv?? tuned into a channel . Almost immediately the problem started where video would slow down in bursts the speed back up to normal speed every 10 to 20 seconds , while during these slowdown periods audio would loop and last few words would be repeated a couple of times over , while audio is repeating video would go on and the two would go out of sync , then audio and video would re-sync and play back normally for another 10 to 20 seconds .

My normal playback settings are using "VDPAU High Quality" profile . I changed the profile to "High Quality" which uses full software decoding only , and the problem went away and the playback is perfect . However my CPU loading increased dramatically . I tried to set the playback profile to "VDPAU Normal" , but as soon as I did this problem started immediately . So at the moment I still have rev 270 installed and running with no VDPAU , playback is perfect , but CPU is running hard .

I am using Axel's latest Nvidia Drivers 260.19.44 with my GTX-450 card , using the HDMI output for both audio and video .

In my case staying on v0.24-199-g5367795 or there about works perfectly on VDPAU , any newer versions are bad . Any suggestions on how to proceed further greatly appreciated .

Best Regards Milorad

comment:28 Changed 3 years ago by mo.ucina@…

Hello Guys,

I have updated my fc14 32 bit installation of myth .24 to rev v0.24-250-g56c54fa to see if the situation with VDPAU was better . Unfortunately it is still broken . However I have been doing more testing to narrow down the circumstances under which the fault manifests itself . What I have found is that when using the VDPAU high quality profile if I set de-interlacer to any choice that has 1x in it everything plays perfectly . Once I set it to anything with 2x in it , then I get the audio looping-video pausing effect . So at the moment I have selected VDPAU high quality profile , using Advanced 1x de-interlacer , and playback is perfect . There must be something in the 2x processing that is broken . I have a nvidia gts450 by the way .

Best Regards
Milorad

comment:29 in reply to: ↑ 25 Changed 3 years ago by markk

Replying to enigma@…:

Yes, both the TV and my test monitor are using VGA. I notice NVidia has a "scaling" property in FlatPanelProperties?, I can set that to "native" in xorg.conf but I don't know if it having an effect.

enigma - are you still seeing this issue? If so, have you tried borrowing/stealing something with a DVI or HDMI connection and seeing if that helps.

To everyone else, please stop commenting/adding to this ticket. It is now a complete mess of probably unrelated issues and comments irrelevant to the OPs issue. If it gets any harder to read, I'll just close the ticket and lock it - life is too short.

comment:30 Changed 3 years ago by markk

  • Status changed from assigned to infoneeded

Something else to bear in mind which I've noticed with the nvidia drivers and VDPAU recently. I need to ensure OPenGL vsync is enabled in nvidia-settings or I get playback issues with 60fps material; and those nvidia settings needs to be setup after re-start, either by manually opening nvidia-settings or adding 'nvidia-settings -l' to a startup script post x initialisation.

I can't currently see anything else I can add to or fix for this ticket. If there is no additional info, I will close it in a few weeks.

comment:31 Changed 3 years ago by markk

  • Milestone changed from 0.24.1 to 0.24.2

comment:32 Changed 3 years ago by ignissport@…

I just installed new nVidia drivers v280.13 from x-swat PPA (released 2008-08-01):
https://launchpad.net/~ubuntu-x-swat/+archive/x-updates

It has completely fixed this*. Playback is perfect again.

*your mileage may vary.

comment:33 Changed 3 years ago by markk

  • Resolution set to Unverified
  • Status changed from infoneeded to closed

Any new (or old) VDPAU playback issues need to go in a new ticket. Please don't add anything else to this one - it's a complete mess.

comment:34 Changed 2 years ago by stuartm

  • Milestone 0.24.2 deleted

Milestone 0.24.2 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.