Opened 16 years ago
Closed 15 years ago
#6922 closed defect (Won't Fix)
Prebuffering pauses with VDPAU on HD channels
Reported by: | Owned by: | markk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.24 |
Component: | MythTV - Video Playback | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
I'm using an Nvidia GeForce? 9400GT on a AMD64 X2 4200+ cpu. I created a video profile to use VDPAU accelerated playback for anything that has a higher or equal resolution of 1280x720.
The problem I see now is stuttering of the video, a log with -v playback,important,general (on the frontend) output lots of these messages:
NVP(0): prebuffering pause
This happens on BBC HD, ZDF HD, HD suisse and arte HD. The 720p channels (all except BBC HD) are OK after a few minutes, BBC HD isn't recovering.
I tried to enable OpenGL vsync, disabled real time priority, disabled CPUFreq, disabled all deinterlacers, nothing did help.
If I can help with something (logs, samples, configuration settings) let me know.
Attachments (10)
Change History (48)
comment:1 Changed 16 years ago by
Owner: | changed from Janne Grunau to markk |
---|---|
Status: | new → assigned |
comment:2 Changed 16 years ago by
Status: | assigned → infoneeded |
---|
comment:3 Changed 16 years ago by
Mark
Attached are the following log files:
- vdpau_without_deint.log: MythFrontend playing back BBC HD using VDPAU with no deinterlacers enabled
- vdpau_with_bob_onefield.log: MythFrontend playing back BBC HD using VDPAU with Bob (2x) as primary and One Field (1x) deinterlacer as fallback
- xorg.conf: My xorg.conf
CPU usage is at nearly 0% when playing back with both configurations.
Hopefully you'll see something out of these logs..
Changed 16 years ago by
Attachment: | vdpau_without_deint.log added |
---|
Changed 16 years ago by
Attachment: | vdpau_with_bob_onefield.log added |
---|
comment:4 Changed 16 years ago by
Mark
Just saw the (software decode) message in the log, investigated a bit and fixed GLX. Attaching new logs (stuttering still occurs).
Changed 16 years ago by
Attachment: | vdpau_gpu_decode_nodeint.log added |
---|
Changed 16 years ago by
Attachment: | vdpau_gpu_decode_nodeint.2.log added |
---|
comment:5 Changed 16 years ago by
Status: | infoneeded → assigned |
---|
Christian
The software decode message is quite normal as live tv transitions from the dummy recorder to the actual playback - so nothing to worry about there.
As a quick test, can you see if increasing the number of vdpau buffers on line 18 of videoout_vdpau.cpp produces any benefit?
comment:6 Changed 16 years ago by
Just for the record, I already discussed this on IRC.
- Both samples from http://www.dmesg.ch/mythtv/samples/ play fine using the 'mythtv file.mpg' command.
- Stuttering only occurs in LiveTV mode, playing back the same LiveTV-recordings from the Watch Recordings page works perfectly.
Maybe this helps to track down the problem a bit...
comment:7 Changed 16 years ago by
Milestone: | unknown → 0.22 |
---|---|
Status: | assigned → accepted |
comment:8 Changed 16 years ago by
Mark, you asked me to add my hardware setups (this is happening on multiple machines) to this ticket:
I tested this with both a remote and a local backend. The remote backend was the same across all frontends, the local backend obviously was the same as the frontend.
Remote backend:
- Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
- 2x 2048 MB DDR2-800 RAM
- Recordings partition is on a sw-raid5 spread across five 400 GB drives on an onboard ICH10 controller
- Capture card is a Hauppauge Nova-S2 (Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder, 14f1:8800)
- This machine also runs Cacti, BackupPC, a Samba-Daemon, MySQLd, cups and some other smaller services
- Connected via Gbit copper ethernet
- Runs Gentoo Linux, Kernel 2.6.30-gentoo-r4, gcc version 4.3.2, glibc 2.8_p20080602-r1, 64bit
First frontend
- AMD Athlon64 4200+
- 1x 2048 MB DDR2-667 RAM
- NVidia GeForce? 9400 GT with 512 MB dedicated video ram
- Capture card when used as a local backend was a KNC1 TV Station (Multimedia controller: Philips Semiconductors SAA7146, 1131:7146)
- Storage for recordings was on a 250GB SATA 2.5" drive
- Connected via 100Mbit copper ethernet
Second frontend
- Intel Atom N330 2x 1.6GHz
- 1x 2048 MB DDR2-800 RAM
- NVidia ION chipset with 512 MB shared memory
- Capture card when used as a local backend was a KNC1 TV Station (Multimedia controller: Philips Semiconductors SAA7146, 1131:7146)
- Storage for recordings was on a 250GB SATA 2.5" drive
- Connected via 100Mbit copper ethernet
Both frontends run from a read-only squashfs-image stacked with a tmpfs, both a running 2.6.30-gentoo-r7, glibc glibc-2.9_p20081201-r2, nvidia-drivers-190.36
If you need more info, let me know
comment:9 Changed 16 years ago by
Sorry for the noise, but I forgot to say two things.
- Both frontends are running 64bit kernels
- I tested a recent trunk checkout on both frontends on an Ubuntu install with the same results
comment:10 Changed 16 years ago by
i'm having a similar issue also using vdpau on a X2@2Ghz whith a local back-end but for SD livetv (using a pvr-150) alot of random NVP(0): prebuffering pause with a very small pause on the frontend
comment:11 Changed 16 years ago by
I'm also seeing this very regularly on an AMD X2 2Ghz with an Nvidia 9400 card using VDPAU. Slight pauses on livetv with the prebuffering message in the logs. This never happens when watching recordings. I only receive SD content so the card should be powerful enough to handle this.
comment:13 Changed 16 years ago by
SVT HD here in sweden also suffers from stuttering playback, cpu is nearly 0%, it seems they have changed something in the codec since i have some old recordings that work perfectly but now live tv and recorded shows show stuttering/tearing. they are transmitting in 720p50 h264 18-21 mbit.
I have an MSI Nvidia 8600GTS with latest drivers, i have tested with lot's of different versions but nothing seems to resolv the issue.
it's to hard to decode on software as well altough i have a quad core 3ghz but it will only use one core. with the old recordings it uses all 4..
comment:14 Changed 16 years ago by
I also have a similar judder problem. It started after a recent update. OpenSuse? 11.2 Milestone 7 to 8. But also moving to the latest mythtv trunk version. Sorry - don't know which change broke it. I have a NVidia ION chipset with 512 MB shared memory with Intel Atom N330 2x 1.6GHzprocessors - running at about 10% when playing HD,
I can play Arte HD, ARD HD, ZDF HD using VDR and xine-vdpau OK but judder with mythtv. ANIXE HD works sometimes. The mthtv ts file also play perfectly using mplayer with vdpau. I have turned off all deinterlacing in the mythtv frontend. I have tried out various vdpau buffer sizes. For SD - it all work great. Are there any files/logs I can collect to help. I like the product. Thanks David
comment:15 Changed 16 years ago by
David: Can you try if disabling Hyperthreading on the ION makes any difference for you?
comment:16 Changed 16 years ago by
I turned off Hyperthreading on the Atom + ION - no difference - sorry - David
Changed 16 years ago by
Attachment: | report.txt added |
---|
mythfrontend log - atom-ION-vdpau 720p jitter but not many buffer messages
comment:17 Changed 16 years ago by
I have the same Problem 720p like Das Erste HD like ZDF HD video and audio Stuttering. 1080i Streams like BBC HD or Astra HD works very nice. I have trunk 22606 on a 64 bit Gentoo machine AMD Dualcore with 2,2Ghz and MSI 9400GT I need help....
comment:18 follow-up: 19 Changed 16 years ago by
I is possible that we have 2 different things here:
- One thing is the judder when playing HD channels with Life TV (for me with Anixe HD and Astra HD). I have no judder when playing a recording of these HD channels. For me it is not so important (who is looking LiveTV ;-)).
- The other thing is the problem with current (german) 720 p channels Arte HD, Das Erste HD, ZDF HD and EinsFestivalHD. What I can see here that I get to little frames. When starting mythfrontend with -v playback I can see only 42 fps and not 50 fps (720p@50). So the video must jump to follow audio? I have recordings from EinsFestivalHD with same content from 09/17/2009 (OK with 50 fps) and 01/11/2009 (not OK, 42 fps not constant). I am sure that "they" have changed anything on the codec-parameters. This problem is important because I cant watch the recordings. But I can watch it with mplayer.
Last weekend I have checked all my satellite stuff (cut the trees, change the LNB, update direction ...). But the problem is still there. Until that I have found this ticket which partly described my important problem.
Note:
- In my test-system I use MythTV 0.22 with the effects described here.
- In my "production"-system I use MythTV 0.21 and since some weeks the frontend hangs on playing content of the HD-channels like Arte HD, Das Erste HD and ZDF HD. Anixe HD and Astra HD works fine. I have seen this effect by the testloop of EinsFestivalHD before. But at the time of last showcasts (WM and IFA) all works well.
Hope it helps. LAASA
comment:19 follow-up: 20 Changed 16 years ago by
I am having serious stuttering / tearing issues on 7 HD:
While watching I get this in my frontend log
2009-11-02 08:02:20.226 NVP(0): prebuffering pause
2009-11-02 08:02:22.251 NVP(0): prebuffering pause
2009-11-02 08:02:23.789 NVP(0): prebuffering pause
2009-11-02 08:02:24.296 NVP(0): prebuffering pause
2009-11-02 08:02:28.441 NVP(0): prebuffering pause
2009-11-02 08:02:29.942 NVP(0): prebuffering pause
2009-11-02 08:02:44.068 NVP(0): prebuffering pause
2009-11-02 08:02:50.457 NVP(0): prebuffering pause
2009-11-02 08:02:54.808 NVP(0): prebuffering pause
2009-11-02 08:02:55.552 NVP(0): prebuffering pause
2009-11-02 08:03:02.736 NVP(0): prebuffering pause
2009-11-02 08:03:04.557 NVP(0): prebuffering pause
I am using VPDAU profile (the medium one).
It is an onboard 9400 with 512mb shared memory.
System is Quad Core Q9400 + 4Gb DDR2 ram.
comment:21 Changed 16 years ago by
I'm also having problems with a jittering playback of Arte HD, ARD HD, ZDF HD, and Eins festival HD (live and playback) even without VDPAU. I've read in a forum that some settop-boxes have the same problems, because of "Dynamic GOP-Sizes" in the stream. Maybe this info is useful for someone...
comment:22 Changed 16 years ago by
Ticket locked: | set |
---|
Discussion on the lists, please, not in the bug database.
comment:23 Changed 16 years ago by
Ticket locked: | unset |
---|
comment:24 Changed 16 years ago by
I experience the same problem. I don't know whether this hint may help or not, but LyngBox? users suffered the same problem, too, and in the following link might be some information regarding to this problem ("Maybe the problems is created because of "ReFrames?: 5 frames"). It doesn't seem like a setup/hardware/configuration problem, something has changed in the HD streams a few weeks ago which causes the stuttering.
http://www.lyngbox.com/support/forum/discussion/240/picture-problems-german-hd/#Item_0
comment:25 Changed 16 years ago by
Got the same problem I have described it here: http://www.mythtvtalk.com/forum/general/12226-mythtv-0-22-dvb-s2-ubuntu-9-04-hdtv-lagging.html
Im using GF9400m witch is integrated on me motherbord
comment:26 Changed 16 years ago by
I have changed videoout_vdpau.cpp vdpau buffers on line 18 TO: 10--> Didn't help 23--> Didn't help 32--> Didn't help 64--> Didn't help
im using mythtv 0.22 from the 0.22 fixes branch
comment:27 follow-up: 29 Changed 16 years ago by
can we keep discussion on the mailing list, the 'me too's aren't helping they are just causing confusion because not everyone will be seeing the same problem.
Some of you just need to allocate more memory to the IGP in the bios, just because it can use UPTO 512MB doesn't mean it's configured to by default, you really need at least 256MB allocated and it's recommended to use whatever is the maximum for your system.
Mark, I'm thinking that we need to refuse vdpau on systems reporting insufficient video ram with a loud warning to the logs.
comment:28 Changed 16 years ago by
I have got 512 shared memory. I set it up in the BIOS I have testet this on 2 diffrent hardware setups: ASUS AT3N7A-I ION 2xAtom 1.6 AND GIGABYTE GA-E7AUM-DS2H both have 512 shared memory enabled in BIOS
Kind Regards
comment:29 Changed 16 years ago by
Ticket locked: | set |
---|
comment:30 Changed 15 years ago by
Milestone: | 0.22 → 0.23 |
---|
comment:31 Changed 15 years ago by
Following some further feedback and testing via irc, the ORIGINAL problem appears to be slightly different h264 stream types.
When changing channel on the same source, the player code does not recognise the streams as having changed as both are flagged as 1920x1080, 16:9 and h.264. One, however, uses MBAFF. I've attached a patch that attempts to spot the change and recreate the decoder. Hopefully this will be sufficient.
Changed 15 years ago by
Attachment: | h264_stream_check_v2.diff added |
---|
comment:32 Changed 15 years ago by
Status: | accepted → infoneeded |
---|
Christian
I've attached a revised patch that tries to detect the stream changes at a low level and re-initialise the VDPAU device. I've tried testing using the IPTV recorder and the 2 test clips you've sent me but the recorder behavior is different and the existing code works.
I'd be grateful if you could post the full output of mythfrontend -v playback - regardless of whether it works or not.
thnks, Mark
comment:33 Changed 15 years ago by
Ticket locked: | unset |
---|
comment:34 Changed 15 years ago by
Unfortunately the problem persists with the above patch. I've attached a log of -v playback.
Changed 15 years ago by
Attachment: | playback.txt added |
---|
Changed 15 years ago by
Attachment: | h264_stream_check_v3.diff added |
---|
Correctly detects and acts upon the stream change but resumed playback is still intermittently broken
comment:35 Changed 15 years ago by
Here's a workaround: Press "P" twice to pause and immediately restart playback. Et voilà, the prebuffering pauses are gone...
comment:36 Changed 15 years ago by
Milestone: | 0.23 → 0.24 |
---|---|
Status: | infoneeded → assigned |
Version: | unknown → head |
Pushing back to 0.24
comment:37 Changed 15 years ago by
Status: | assigned → accepted |
---|
comment:38 Changed 15 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | accepted → closed |
If this is still a problem in 0.24, please open a new ticket with up to date logs.
Christian
Can you please attach the output from mythfrontend -v playback for a session where you play an HD file.
The 9400GT is not a particularly 'fast' GPU by vdpau standards so my best bet would be that you are trying to use a deinterlacer that is too GPU intensive - such as advanced 2x. Try disabling deinterlacing or just use Bob for vdpau and see how you fare. The log will hopefully confirm one way or the other.
rgds
Mark