[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