[mythtv] SVN 8106 playback pauses for prebuffering often

Jesse Crews jcrews at gridlox.net
Sun Dec 4 18:18:21 UTC 2005

Quoting Daniel Kristjansson <danielk at cuymedia.net>:

> On Sun, 2005-12-04 at 11:15 -0500, Jesse Crews wrote:
>> I just started working with rev 8106, and the first thing I noticed re.
>> playback is that NVP pauses for prebuffering at the drop of a hat.
> I'm looking at this right now. It's a different beast from the old
> prebuffering pause problem.
>> looking at videoout_xv, I see that xvmc code has been unified (no more
>> videoout_xvmc), and that the prebuffering setup is much different.
> Not really that different, mostly it is just better documented.

I think the inline comments are decent.

>> The old way has 8 buffers (one for each surface?) 4 for playback
>> The new way still has 8 buffers (for nv) **3** for playback
>> I set the PRE_NUM to 2 (2 I/P frames before us) <-
>> libs/libmythtv/videoout_xv.cpp, line 147.
>> This got rid of the race condition. Playback is perfect.
>> Was there a reason for not using that 4th surface for buffering?
> Yep, the pause frame and OSD. This should be fairly well documented
> in videoout_xv.cpp. There is a hard reserve of 1 + num OSD surfaces,
> plus a soft reserve that include the PRE, POST and pause frame plus
> the hard reserve. If you turn on the Chromakey OSD you don't need
> to reserve the OSD surfaces; but you do need hardware that supports
> chromakey.

Ok. I understand.

> If you get rid of the reserve playback is better, until you the
> machine locks up and you need to pull the plug for a hard reboot :/

I'm not sure I follow this part. The HARD reserve appears to be 
calculated from num_xvmc_surf + XVMC_SHOW_NUM, right?

The monochrome OSD uses 1 surface, correct?

With this nv, we have 8 surfaces.
1 for OSD
1 for the XVMC_SHOW_NUM
These are hard reserved.
Then, we take that value (2) + PRE_NUM (2) + POST_NUM (1) + SHOW_NUM (1)

soft reserved = 6. Correct?

Now, GetPreBufferGoal returns 2 instead of 3.

So, It looks like we're actually prebuffering _fewer_ frames, but we 
have an extra surface reserved for display. Is this correct, or have I 
misread something? It does seem to work better this way, and the 
machine didn't lock up, although I can't say that I took the time to 
run it for more than about 20 minutes.

Chromakey OSD works like a charm. I'm personally going to use it instead.

> -- Daniel
> !DSPAM:1,43932821316321934319256!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: PGP Digital Signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20051204/cea85092/attachment.pgp

More information about the mythtv-dev mailing list