RFC: Xv field order

[Krzysztof Halasa]

Thomas Hilber <xorg at toh.cx> writes:

> finally it does not matter how stable the broadcast itself is. 
> Rather how this stability is realized by the decoder.

No. What is important is maximum shift in time between the broadcast and
playback. It has to stay within buffering capability. It's that simple.

If your playback time base (video card, or sound card, or "metronom"
etc.) is slower than the broadcast, you don't have to buffer in advance.
You will need more buffers as the show goes on but this is hardly a
problem.

If your playback is faster than broadcast, you need some initial buffers
which will be drained as the playback progresses, because you supply
video data a bit slower than you consume it.

True: if you playback is noticeable faster (0.2% is) then you can't
effectively compensate for this because you'd need really big initial
buffers.

OTOH you can artificially make it slower (tried and it worked well with
a live DV cameras) and forget about those problems, especially if you
only need to display it. This is BTW also possible with multiple video
streams.

> Buffering if at all only would help if your graphics card is slower
> than the broadcast. If it's faster you get noticeable disturbances if
> your buffer gets exhausted.

Not "if". When. This is why you need to calculate how much buffering do
you need. Unless you aim for a continuous playback for a really long
time (such as many hours) - this would be problematic (if not slowing
down the card, of course).

> I'm not speaking of my own setup. My algorithm dynamically adjusts with 
> accuracy of +-0.001Hz. I'm speaking of common solutions for video 
> playback using the XV extension.

The above has nothing to do with Xvideo or no Xvideo.
It's simple: frame rate = pixel clock / total h count / total v count.
It was like that for ages. Pixel clock for digital SD video is 13.5 MHz
and i915 can generate it. You divide by 864 pixels and 625 lines and you
get 50 Hz. +- 0.001 Hz is 20 ppm, I wound't be surprised if a fixed
clock generator stays within this limit, in comparison to the broadcast.
Anyway you don't need 20 ppm, I guess 100 ppm is enough, and you can be
slower as much as your TV likes.

Of course your solution may be better for some corner cases. This
doesn't matter at this point as I'm not trying to implement variable
pixel clock but, rather, a synchronized playback using textured overlays
This is simply orthogonal to the "VCO" thing, you can use both.

>> That would be true if you use some player-internal time base. But
>> players can, and do, synchronize to the graphics card. IOW the card
>> becomes the time base, and everything (sound) is adjusted to it.
>
> are these solutions also available for live TV?

Yes, in the "official" packages for a long time.

> can't tell. I don't know these proprietary solutions for matrox cards.

They don't seem to be very "proprietary". Open-source drivers written
by their users I guess. Note it may be unable to drive the "Parhelia"
cards, I don't know. Also, there are drivers for other hw/sw doing the
same.
-- 
Krzysztof Halasa