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: | 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)
Change History (27)
Changed 14 years ago by
Attachment: | myth22-vdpau-xorg-110909.zip added |
---|
Changed 14 years ago by
Attachment: | myth22-vdpau-debug-playback-110909.zip added |
---|
comment:1 Changed 14 years ago by
Owner: | changed from Isaac Richards to markk |
---|---|
Status: | new → accepted |
comment:2 Changed 14 years ago by
- Can you confirm whether other video sources have the same issue with Mythtv? or is it just HDHR recordings?
- What happens if you disable deinterlacing entirely in the playback profile?
- 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
Thank you for the quick response - did a bunch of testing tonight, results/answers below:
- 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)
- No change
- 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 follow-up: 5 Changed 14 years ago by
Can you upload a short sample of a video that clearly displays the problem?
thanks, Mark
comment:5 follow-up: 6 Changed 14 years ago by
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 Changed 14 years ago by
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
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
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.
comment:9 Changed 14 years ago by
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
Status: | accepted → infoneeded |
---|
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
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
Resolution: | → worksforme |
---|---|
Status: | infoneeded → closed |
No info provided in seven weeks.
comment:13 Changed 14 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → new |
comment:14 Changed 14 years ago by
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
The initial problem was reported against 0.22. Are you still experiencing this with 0.23?
comment:16 Changed 14 years ago by
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
< see page 4 of the thread on NVnews for confirmation of a bug, and special .so file to test against >
comment:18 Changed 14 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
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
Ticket locked: | set |
---|
mythfrontend -v playback