Opened 10 years ago

Closed 9 years ago

#6922 closed defect (Won't Fix)

Prebuffering pauses with VDPAU on HD channels

Reported by: Christian Güdel <cg@…> 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)

vdpau_without_deint.log (23.0 KB) - added by Christian Güdel <cg@…> 10 years ago.
vdpau_with_bob_onefield.log (18.1 KB) - added by Christian Güdel <cg@…> 10 years ago.
xorg.conf (1010 bytes) - added by Christian Güdel <cg@…> 10 years ago.
vdpau_gpu_decode_nodeint.log (25.2 KB) - added by Christian Güdel <cg@…> 10 years ago.
vdpau_gpu_decode_nodeint.2.log (25.2 KB) - added by Christian Güdel <cg@…> 10 years ago.
report.txt (29.4 KB) - added by dmndmn@… 10 years ago.
mythfrontend log - atom-ION-vdpau 720p jitter but not many buffer messages
vdpauh264_stream_check.diff (3.1 KB) - added by markk 10 years ago.
Test patch
h264_stream_check_v2.diff (19.8 KB) - added by markk 10 years ago.
playback.txt (140.0 KB) - added by anonymous 10 years ago.
h264_stream_check_v3.diff (3.1 KB) - added by markk 10 years ago.
Correctly detects and acts upon the stream change but resumed playback is still intermittently broken

Download all attachments as: .zip

Change History (48)

comment:1 Changed 10 years ago by Janne Grunau

Owner: changed from Janne Grunau to markk
Status: newassigned

comment:2 Changed 10 years ago by markk

Status: assignedinfoneeded

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

comment:3 Changed 10 years ago by Christian Güdel <cg@…>

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 10 years ago by Christian Güdel <cg@…>

Attachment: vdpau_without_deint.log added

Changed 10 years ago by Christian Güdel <cg@…>

Attachment: vdpau_with_bob_onefield.log added

Changed 10 years ago by Christian Güdel <cg@…>

Attachment: xorg.conf added

comment:4 Changed 10 years ago by Christian Güdel <cg@…>

Mark

Just saw the (software decode) message in the log, investigated a bit and fixed GLX. Attaching new logs (stuttering still occurs).

Changed 10 years ago by Christian Güdel <cg@…>

Changed 10 years ago by Christian Güdel <cg@…>

comment:5 Changed 10 years ago by markk

Status: infoneededassigned

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 10 years ago by Christian Güdel <cg@…>

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 10 years ago by markk

Milestone: unknown0.22
Status: assignedaccepted

comment:8 Changed 10 years ago by Christian Güdel <cg@…>

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 10 years ago by Christian Güdel <cg@…>

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 10 years ago by simons.philippe@…

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 10 years ago by jlam

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:12 Changed 10 years ago by jlam

Sorry, forgot to mention this is on 64-bit.

comment:13 Changed 10 years ago by anonymous

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 10 years ago by dmndmn@…

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 10 years ago by Christian Güdel <cg@…>

David: Can you try if disabling Hyperthreading on the ION makes any difference for you?

comment:16 Changed 10 years ago by dmndmn@…

I turned off Hyperthreading on the Atom + ION - no difference - sorry - David

Changed 10 years ago by dmndmn@…

Attachment: report.txt added

mythfrontend log - atom-ION-vdpau 720p jitter but not many buffer messages

comment:17 Changed 10 years ago by anonymous

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 Changed 10 years ago by anonymous

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 in reply to:  18 ; Changed 10 years ago by anonymous

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:20 in reply to:  19 Changed 10 years ago by anonymous

Is this problem specific to the 9400?

comment:21 Changed 10 years ago by cm@…

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 10 years ago by sphery

Ticket locked: set

Discussion on the lists, please, not in the bug database.

comment:23 Changed 10 years ago by sphery

Ticket locked: unset

comment:24 Changed 10 years ago by anonymous

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 10 years ago by anonymous

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 10 years ago by anonymous

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 Changed 10 years ago by stuartm

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 10 years ago by anonymous

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 in reply to:  27 Changed 10 years ago by robertm

Ticket locked: set

Replying to stuartm:

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.

Replying to anonymous:

I have got 512 shared memory blah blah

Nice job, anonymous.

comment:30 Changed 10 years ago by markk

Milestone: 0.220.23

Changed 10 years ago by markk

Attachment: vdpauh264_stream_check.diff added

Test patch

comment:31 Changed 10 years ago by markk

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 10 years ago by markk

Attachment: h264_stream_check_v2.diff added

comment:32 Changed 10 years ago by markk

Status: acceptedinfoneeded

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 10 years ago by markk

Ticket locked: unset

comment:34 Changed 10 years ago by cg@…

Unfortunately the problem persists with the above patch. I've attached a log of -v playback.

Changed 10 years ago by anonymous

Attachment: playback.txt added

Changed 10 years ago by markk

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 10 years ago by anonymous

Here's a workaround: Press "P" twice to pause and immediately restart playback. Et voilà, the prebuffering pauses are gone...

comment:36 Changed 10 years ago by markk

Milestone: 0.230.24
Status: infoneededassigned
Version: unknownhead

Pushing back to 0.24

comment:37 Changed 10 years ago by markk

Status: assignedaccepted

comment:38 Changed 9 years ago by markk

Resolution: Won't Fix
Status: acceptedclosed

If this is still a problem in 0.24, please open a new ticket with up to date logs.

Note: See TracTickets for help on using tickets.