XvMC playback stutters after PAUSE/UNPAUSE using SVN 8770

[tralph11@…]

Many of my HD recordings (AC3 5.1) seem to suffer a problem when doing a PAUSE/UNPAUSE during playback. A SKIP BACK _always_ clears up the problem and I then have smooth playback. It seems that the problem is much more apparent when I've got ac3 passthru enabled and use audio as timebase.

System Specs

• Athlon XP 2500+

• Nvidia GeForce4 MX 440 (version 7676 drivers)

Configuration (SVN 8770)

• XvMC with Chromakey OSD

• AC3 passthru

• Extra audio buffering

• Audio as timebase

• Opengl vsync (same behaviour on or off)

• Realtime priority

I'm attaching a frontend log created with -v all. The one thing I notice is that it seems to continuously print the following messages until I perform a SKIP BACK:

NVP: Video is 4.67542 frames ahead of audio, skipping A/V wait.

On a side note, when trying the 8178 nvidia drivers (I turned opengl vsync off) a PAUSE/UNPAUSE caused a very large persistent spike in CPU usage for the Xorg process until I did a SKIP BACK. The 7676 drivers don't exhibit this problem. Not sure if this is useful information or not.

I'm not sure what SKIP BACK (or probably any type of seek) is doing exactly but it seems to get playback into a proper state. Atleast I have a work around for now using SKIP BACK.

Daniel, Thanks for all the hard work on XvMC. Using XvMC and the Chromakey OSD has made a tremendous difference on my system. For the first time I was able to playback high bitrate 1080i streams during live-tv with no stuttering at all!

I can also make available a recording that exhibits this problem using the Internal player under mythvideo. Please let me know if you need anything else.

Thanks!

[tralph11@…]

Another weird thing I noticed in the log is between "Changing speed to 0" and "Changing speed to 1" the following output is observed:

WriteAudio?: Preparing 6144 bytes (1536 frames) 54656 bytes free on soundcard

I don't know if it's directly related to the ticket but thought I would point it out since I'm guessing audio shouldn't be written during a pause.

[danielk]

With AC3 passthru you really have to ramp up to full a full bitrate right away to not hear some nastiness. I think this has more to do with the ringbuffer being filled up quickly enough on lower end processors. Not that a AMD 2500+ is really a low end processor, but I've been targetting a 2800 Mhz minimum machine for 1080i, if I can get Chromakey OSD and something similar for newer nVidia cards working in 0.20, I plan to fix this and other issues. (With XvMC + ChromaKey? OSD I can almost play 1080i on my old 1800 Mhz P4...)

This also relates to John Poet's ticket #900.

[tralph11@…]

I don't know if I was clear about the stuttering, but when I said it stutters after unpausing playback I meant that is continuously stutters forever until I perform a seek.

The log file that I've provided shows playback for a 720p recording and not 1080i. I can easily playback this recording using Xv and libmpeg2 (about 65% CPU total). I don't think this problem is related to #900 since the RingBuffer? patch didn't help at all. So it still leaves two questions for me:

1. Why is the audio still being written when the playback speed is set to 0?

2. Why does SKIP BACK (or any other type of seek) clear up the playback for me?

I don't think this is that much performance related. I feel there is something definitely wrong with the way pausing is implemented for XvMC. It just seems the audio or video playback isn't getting restarted correctly. One other reason I believe this is that I can produce a heavy load on my box when playback is running smoothly and cause playback to stutter severely and when the load is removed the playback starts playing smoothly again.

Sorry if I'm way off the mark here. I just wanted to clarify the problem a little more. Thanks for all your help.

[danielk]

Hmm, from your additional description this looks like just a duplicate of #906. A1: audio prebuffering A2: does a seek which frees any frames lost in limbo; hence duplicate of #906.

[tralph11@…]

Ah, thanks for the answers to my questions. I now see the limbo frames in the prebuffering messages. I initially looked through the tickets trying to find a match to my symptoms. I'm guessing that the discussion for ticket #906 went off line since the only symtom I read about is a blank screen with an error message. Sorry about the dupe. I guess SKIP BACK will have to be my friend for a while. :⁾

[tralph11@…]

Daniel, it seems your [8797] changeset for ticket #774 fixed the problem completely for me. Not sure if it was supposed to but I can't reproduce the problem at all.

FYI, I'm also using the patch from ticket #900 and upped the HD ringbuffer size to 14100. These changes may not be necessary now though.