Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7571 closed defect (invalid)

Mythfrontend 0.22 VDPAU "Sparkle" / Error noise

Reported by: blammo@… Owned by: markk
Priority: minor Milestone: unknown
Component: MythTV - General Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: yes

Description

<reposted from my thread on the MythUsers? list>

long time Myth user, did the 0.22 upgrade this weekend using ATRPMS repo.. everything went smoothly after a little google-foo for QT4.4 on Centos.. Backend (Centos54-64-bit) flawless upgrade, zero issues since. Frontend (Mythdora 10.21) little more pain, but got it upgraded as well.

Backend: Tyan S28xx series, 2xOpteron 285, 8G ram, 3ware 9500 w/lotsa drives, dual GIG-e to switch, 2xHDHR OTA Frontend: MSI AM2, 6400BE@3.2ghz, 9600GT, HDMI to Sony TV

I've been using VDPAU with mplayer SVN + NVIDIA 180 drivers for a few weeks, with zero issues. Picture is beautiful, smooth, crisp, and it's a little spooky to see 10% CPU with 1080p playback active.

However, VDPAU in myth has me less impressed today. Over the weekend watched probably 10+ hours of mixed HD playback, almost all recorded from ATSC-air from HDHR's. Almost all of it had what I can best describe as Horizontal fragments / bands / sparkles that would randomly appear, almost like noise throughout playback. They would stay on the screen less than 1 second each, but at times you could have lots of them on the screen.

If I go back into "playback profiles" and set back to CPU/CPU+/anything non VPDAU, same source, no noise. No change in the "deinterlace profiles" under VDPAU changes the behavior.

Other things I tried:

  • 2 different video cards - 8500GT and 9600GT.
  • 3 different driver revisions, 180, 185, and 190
  • multiple different on-air sources, 480p, 720p, and 1080i
  • liveTV seems to be worse than recorded, but not by much..

Again, non-VDPAU = no noise/artifacts

Playback of non-HDHR sources like H.264, VOB, etc,in mplayer produces ZERO artifacting.

It doesn't appear to affect stability, but it's downright irritating..and obviously a symptom of something broken.

the mythfrontend.log isn't giving up any help either, but perhaps I don't have debug high enough.. I'm getting some NVP: prebuffering, and WriteAudio?: buffer underrun, but only every couple minutes.. nothing to correlate to the constant artifacts.

I'm attaching both the xorg.conf and "-v playback" logs.


[root@frontend1 ~]# mythfrontend --version Please include all output in bug reports. MythTV Version : 22759 MythTV Branch : branches/release-0-22-fixes/mythtv/ Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.3 Options compiled in:

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

02:00.0 VGA compatible controller: nVidia Corporation GeForce? 8500 GT (rev a1) (prog-if 00 [VGA controller])

Subsystem: Giga-byte Technology Device 344c Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f8000000 (32-bit, non-prefetchable) [size=16M] Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f6000000 (64-bit, non-prefetchable) [size=32M] I/O ports at bc00 [size=128] [virtual] Expansion ROM at f9000000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel <?> Capabilities: [128] Power Budgeting <?> Capabilities: [600] Vendor Specific Information <?> Kernel driver in use: nvidia Kernel modules: nvidiafb, nvidia-190_36

[root@frontend1 ~]# uname -r 2.6.27.38-170.2.113.fc10.x86_64

Please let me know if there's any additional information I can provide.

Attachments (8)

myth22-vdpau-xorg-110909.zip (914 bytes) - added by anonymous 14 years ago.
myth22-vdpau-debug-playback-110909.zip (5.5 KB) - added by blammo@… 14 years ago.
mythfrontend -v playback
IMG00254.jpg (396.2 KB) - added by anonymous 14 years ago.
example
IMG00255.jpg (408.0 KB) - added by anonymous 14 years ago.
example
IMG00256.jpg (311.3 KB) - added by anonymous 14 years ago.
example
IMG00257.jpg (402.5 KB) - added by anonymous 14 years ago.
example
vdpau-glitter-1.jpg (205.0 KB) - added by blammo@… 14 years ago.
it shows up under x11vnc too
cpuplusplus-no-glitter-1.jpg (208.2 KB) - added by blammo@… 14 years ago.
same frame with CPU++ set

Download all attachments as: .zip

Change History (27)

Changed 14 years ago by anonymous

Changed 14 years ago by blammo@…

mythfrontend -v playback

comment:1 Changed 14 years ago by markk

Owner: changed from Isaac Richards to markk
Status: newaccepted

comment:2 Changed 14 years ago by markk

  1. Can you confirm whether other video sources have the same issue with Mythtv? or is it just HDHR recordings?
  1. What happens if you disable deinterlacing entirely in the playback profile?
  1. Can you disable xvideo and opengl vsync and see if this affects playback. OpenGL vsync can be disabled from the playback settings and the easiest way to disable xvideo is by running mythtv with:-

NO_XV=1 mythfrontend -v playback

thanks and regards

Mark

comment:3 Changed 14 years ago by blammo@…

Thank you for the quick response - did a bunch of testing tonight, results/answers below:

  1. I went through about 100 files of every type I have tonight. It only appears to happen with MP2 sources. MP4/QT/H-264, all seem fine. Here's the FFMPEG info from a couple that I get the issues with:

Stream #0.0[0x22]: Video: mpeg2video, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 20000 kb/s, 29.97 tb(r)

Stream #0.0[0x31]: Video: mpeg2video, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 19000 kb/s, 59.94 tb(r)

  1. No change
  1. No change

One thing I noticed while working with this, hope this helps... It was using a couple of 1080i HD demos which have high detail still scenes. While the scene was still, I noticed NO artifacts, but after each scene change, I would see artifacts for a few seconds. Again, only MPEG2 sources.

Hope this helps!

comment:4 Changed 14 years ago by markk

Can you upload a short sample of a video that clearly displays the problem?

thanks, Mark

comment:5 in reply to:  4 ; Changed 14 years ago by blammo@…

Replying to markk:

Can you upload a short sample of a video that clearly displays the problem?

First 60 seconds is 119M... not sure that's what you had in mind.. and I don't know if I can attach something that big.. but I'll give it a shot..

comment:6 in reply to:  5 Changed 14 years ago by anonymous

Replying to blammo@…:

Replying to markk:

Can you upload a short sample of a video that clearly displays the problem?

First 60 seconds is 119M... not sure that's what you had in mind.. and I don't know if I can attach something that big.. but I'll give it a shot..

I'm uploading it to somewhere you can get to it.. drop me an email, and I'll reply with location. I'd rather not broadcast it to the world..

comment:7 Changed 14 years ago by anonymous

The provided sample plays back without issue for me on 2 different frontends (one 8400gs, one ION).

The symptoms do however remind me of an issue I use to have when playing back from NFS mounts. Under settings->tv settings->playback, can you enable the checkbox that says 'always stream recordings from backend' - and see if that makes a difference.

rgds

Mark

comment:8 Changed 14 years ago by blammo@…

I'll give that a shot.. curious why it would only affect MPEG2, and only when played back via mythfrontend/vdpau.. mplayer has no problems.

Changed 14 years ago by anonymous

Attachment: IMG00254.jpg added

example

Changed 14 years ago by anonymous

Attachment: IMG00255.jpg added

example

Changed 14 years ago by anonymous

Attachment: IMG00256.jpg added

example

Changed 14 years ago by anonymous

Attachment: IMG00257.jpg added

example

comment:9 Changed 14 years ago by anonymous

Changing to "Stream" didn't change the behavior at all.. same issues.

Discovered something interesting.. I can pause and artifacts remain.. I uploaded a couple of examples.. Switch back to non-VDPAU, no artifacts.

Something rotten.. just not sure what..

comment:10 Changed 14 years ago by markk

Status: acceptedinfoneeded

I finally managed to try playing this back with 0-22-fixes and again I see no visual artifacts using 190.xx and 8400GS, 9500GT, 8800GT and Ion based systems. I'm fairly confident that the underlying problem is not VDPAU but the playback glitches are not handled as well by the hardware decoder. This has been widely reported in the past and I saw it with older versions of the driver.

The only other thing I can suggest is to copy a file to the frontend's own hard drive and test local playback - i.e. bypass the network entirely.

rgds, Mark

comment:11 Changed 14 years ago by blammo@…

The only "odd" portion to me about this is that playback via mplayer-VDPAU doesn't artifact, same source files.. Not sure why that would be..

comment:12 Changed 14 years ago by robertm

Resolution: worksforme
Status: infoneededclosed

No info provided in seven weeks.

Changed 14 years ago by blammo@…

Attachment: vdpau-glitter-1.jpg added

it shows up under x11vnc too

Changed 14 years ago by blammo@…

same frame with CPU++ set

comment:13 Changed 14 years ago by anonymous

Resolution: worksforme
Status: closednew

comment:14 Changed 14 years ago by steve.schulz@…

I have the identical problem, and have tried the same tests w/o success. I am 100% certain that there is something different about the internal mythtv player decoding of MPEG2 streams than when using mplayer / vdpau w/o mythtv. Local or network makes no differenece, BTW.

Please do NOT give up on this very frustrating problem, I'm willing to assist however possible.

comment:15 Changed 14 years ago by Raymond Wagner

The initial problem was reported against 0.22. Are you still experiencing this with 0.23?

comment:16 Changed 14 years ago by blammo@…

I'm currently running the following: MythTV Version : 24265 MythTV Branch : branches/release-0-23-fixes/mythtv/ Network Protocol : 56 Library API : 0.23.20100314-1 QT Version : 4.6.2 Options compiled in:

linux release using_oss using_alsa using_pulse using_jack using_pulseoutput using_backend using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

And yes, the problem is still occurring. I'm not the only one having this issue:

The problem appears to be unique to: -- Motherboard with integrated Nvidia video chipset -- add on video card of newer NV chipset -- MPEG2 playback -- mythTV

See the following thread: http://www.nvnews.net/vbulletin/showthread.php?t=136817

Nvidia has an idea how to fix/work-around the behavior, but their side of the fix isn't in any shipping drivers yet. I'm curious what can be done from the MythTV side, since it only appears to happen in Myth playback. (Mplayer/XINE/etc don't exhibit the behavior)

comment:17 Changed 14 years ago by anonymous

< see page 4 of the thread on NVnews for confirmation of a bug, and special .so file to test against >

http://www.nvnews.net/vbulletin/showthread.php?t=136817

comment:18 Changed 14 years ago by robertm

Resolution: invalid
Status: newclosed

Thank you for the update, closing as the issue needs to be fixed by nVidia. Carl Hoyos from mplayer is able to trigger this there as well.

comment:19 Changed 14 years ago by robertm

Ticket locked: set
Note: See TracTickets for help on using tickets.