On Thu, 29 Jun 2006, Timothy Miller wrote:
On 6/29/06, Jussi Vainionpää <[EMAIL PROTECTED]> wrote:
Do you mean adjust the pixel clock at the start of the next frame? Or
adjust the delay between frames without changing the pixel clock?
No. I mean to insert or delete clock cycles out of the blanking time
at the end of a frame to compensate for drift between captured frame
timing and output frame timing.
Monitors will generally tolerate some variation as to when the frame
starts. TVs in particular need to be very tolerant, because of how
video tape has considerable variance in timing.
Blanking time adjustment might be a good way for monitors that can handle
it as it's probably the easies to implement. But that's definitely not a
clean way. On TVs there is also a colour subcarrier phase and stuff to
worry about so it's getting a bit complicated. Because of that phase
jitter video tape makes we see the colour artifacts etc. Also it seems
quite funny to count for analog error tolerance for our clean digital
output.
What I'm worried about is will the display device be able to keep its
input
and its internal updates to its LCD / DLP / whatever in sync without
duplicating or dropping frames.
Isn't that a matter of how quickly you can get data into the framebuffer?
The problem of losing sync come only then when the change is too fast. Is
there any way to implement just variable main clock to the raster
generator? Meaning a runtime access to the pixel clock pll registers.
Naturally there has to be small enough increments available and means to
temporally switch between the two for fractional values. The needed
adjustment is going to be really small, of the order of one permille or so
and updating relatively slow, because it's just correcting the clock
differences and drift between the stream source and our pixel clock. So
efectively a slow phase locked loop, where the reference is the stream
clock. Set top box output chips data sheets may provide more information
about solutions, if we aren't going to impelent frame resampling or
something alike for really independent input-output frame rates.
TI STB reference design and links to device data sheets:
http://focus.ti.com/docs/solution/folders/print/262.html
Some of these features woud be nice for free world too ;)
http://www.nvidia.com/object/TB_purevideo.html
My wild guess is that if Open-graphics can get as good and
standard compliant video out of pc on Linux as hw players (HD/SD), it's
going to bring a lot of happy customers. Count me in.
-Vesa
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
