Lately there has been some news on R600+ progress - also mentioning XV
It would be very nice to know more about the current status and plans for video.
Does the initial XV implementation have biqubic scaling (or better) ?
Is there any limitations on the supported formats ? (Hopefully everything just works )
Does the V-sync etc. work so there won't be tearing ?
Any thoughts on this live-TV / streaming issue:
Local playback is the easy case where you can fine-tune the playback rate to mach the (primary) display device frame rate (or actually the master clock of GPU).
With live-TV and (continuous) streaming the data rate is dictated by the transmitting end. Hence the receiving end must somehow adapt to this foreign master clock. (In addition there could be some drift and jitter ..) Simply skipping or duplicating frames won't do because they cause motion artefacts (hesitation and judder etc.).
There are some experimental patches which try to synchronize the local frame rate to follow exactly the incoming framerate. (And if there is too much mitchmatch then the target is some integer multiple or simple ratio..)
See: http://linuxtv.org/pipermail/vdr/2008-July/017347.html and http://lowbyte.de/vga-sync-fields/
(and http://www.vdr-portal.de/board/threa...172#post751172 and http://www.vdr-portal.de/board/threa...threadid=80567 etc.)
IMHO: It would be best for all to have one properly thought-out solution.
Any plans for a future roadmap ?:
Motion compensation with shaders was mentioned somewhere.
Is all implemented shader instructions and their special variants documented ?
(Or is there only 3D essentials ?)
Any plans for deblocking / post-processing filters ?
Proper motion adaptive/avare de-interlacing / framerate conversion ?
Any chance for UVD+ .. or is it RE then ?
IMHO: I'm not sure how beneficial the full bitsream HW acceleration actually is. If the HW is not fully programmable processor then there will always be some not-so-standard content which just won't work. Perhaps the high flexibility of (existing) CPU software is more beneficial here.
Finally big thanks to all those contributing to the open drivers !
;-PWMx
It would be very nice to know more about the current status and plans for video.
Does the initial XV implementation have biqubic scaling (or better) ?
Is there any limitations on the supported formats ? (Hopefully everything just works )
Does the V-sync etc. work so there won't be tearing ?
Any thoughts on this live-TV / streaming issue:
Local playback is the easy case where you can fine-tune the playback rate to mach the (primary) display device frame rate (or actually the master clock of GPU).
With live-TV and (continuous) streaming the data rate is dictated by the transmitting end. Hence the receiving end must somehow adapt to this foreign master clock. (In addition there could be some drift and jitter ..) Simply skipping or duplicating frames won't do because they cause motion artefacts (hesitation and judder etc.).
There are some experimental patches which try to synchronize the local frame rate to follow exactly the incoming framerate. (And if there is too much mitchmatch then the target is some integer multiple or simple ratio..)
See: http://linuxtv.org/pipermail/vdr/2008-July/017347.html and http://lowbyte.de/vga-sync-fields/
(and http://www.vdr-portal.de/board/threa...172#post751172 and http://www.vdr-portal.de/board/threa...threadid=80567 etc.)
IMHO: It would be best for all to have one properly thought-out solution.
Any plans for a future roadmap ?:
Motion compensation with shaders was mentioned somewhere.
Is all implemented shader instructions and their special variants documented ?
(Or is there only 3D essentials ?)
Any plans for deblocking / post-processing filters ?
Proper motion adaptive/avare de-interlacing / framerate conversion ?
Any chance for UVD+ .. or is it RE then ?
IMHO: I'm not sure how beneficial the full bitsream HW acceleration actually is. If the HW is not fully programmable processor then there will always be some not-so-standard content which just won't work. Perhaps the high flexibility of (existing) CPU software is more beneficial here.
Finally big thanks to all those contributing to the open drivers !
;-PWMx
Comment