Hi,
On 28 October 2013 15:47, Axel Davy wrote:
> On 28/10/2013, Frederic Plourde wrote :
>> I don't know about current/future driver support for this new GSYNC
>> technology... but you know what, I definitely agree with Pekka as we should
>> get this protocol and basic buffer queuing implementati
On 28/10/2013, Daniel Stone wrote :
For programers having to cope with X and Wayland, and to better support the
Present extension, I reiterate my suggestion
to do something similar to the X Present extension.
Anything in particular? I'm well aware of Present, but am not entirely
sure what you'r
Hi,
On 28 October 2013 21:13, Axel Davy wrote:
> On 28/10/2013, Daniel Stone wrote :
>>> For programers having to cope with X and Wayland, and to better support
>>> the
>>> Present extension, I reiterate my suggestion
>>> to do something similar to the X Present extension.
>>
>> Anything in parti
On 28/10/2013, Frederic Plourde wrote :
I don't know about current/future driver support for this new GSYNC
technology... but you know what, I definitely agree with Pekka as we
should get this protocol and basic buffer queuing implementation
reviewd and working for the general case for now and
On 13-10-28 08:18 AM, Axel Davy wrote:
On Mon, 28 Oct 2013, Pekka Paalanen wrote:
The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe ho
On Mon, 28 Oct 2013, Pekka Paalanen wrote:
The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe how GSYNC affects timings.
I don't under
On Mon, 21 Oct 2013 10:50:05 -0400
Frederic Plourde wrote:
> On 13-10-18 05:59 PM, James Courtier-Dutton wrote:
> > We would also need the API to be compatible with "G-Sync".
> >
> > http://www.pcper.com/news/Graphics-Cards/NVIDIA-Announces-G-Sync-Variable-Refresh-Rate-Monitor-Technology
> >
> >
On 21 October 2013 20:45, Daniel Stone wrote:
> Hi,
>
> On 18 October 2013 11:52, James Courtier-Dutton
> wrote:
>>
>> I think how wayland can help provide the "deterministic" angle is not yet
>> clear to me.
>
> Nothing is deterministic. Is your kernel scheduling your application
> in time? An
Hi,
On 18 October 2013 11:52, James Courtier-Dutton wrote:
> On 18 October 2013 08:30, Pekka Paalanen wrote:
>> On Thu, 17 Oct 2013 21:34:02 +0100
>> James Courtier-Dutton wrote:
>> > All its prediction calculations will be based on a fixed scanout rate.
>>
>> Why only fixed scanout rate? Why c
Hi,
On 16 October 2013 19:40, Jonas Kulla wrote:
> 2013/10/16 Daniel Stone
>> On 16 October 2013 17:09, Jonas Kulla wrote:
>> > it might just be a stupid thought of mine, but it would be kinda cool
>> > if there was wayland protocol for creating an EGLStream [1] backed
>> > surface.
>>
>> It wo
On 13-10-18 05:59 PM, James Courtier-Dutton wrote:
We would also need the API to be compatible with "G-Sync".
http://www.pcper.com/news/Graphics-Cards/NVIDIA-Announces-G-Sync-Variable-Refresh-Rate-Monitor-Technology
From my understanding of GSYNC, the monitor refresh rate will be
completely s
On 13-10-21 10:39 AM, Axel Davy wrote:
I think the simpler is to have a
similar functionalities to the X Present extension:
git://people.freedesktop.org/~keithp/presentproto master
We can ask a buffer to be shown at a speci
I think the simpler is to have a similar functionalities to the X
Present extension:
git://people.freedesktop.org/~keithp/presentproto master
We can ask a buffer to be shown at a specific ust time, and we get the
feedback at which ust
time it has hit the screen. And we could queue buffers.
Hi,
One last thing to consider, regarding the clock used and the timestamps.
The video frames should pause during system suspend, and continue on resume.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mail
We would also need the API to be compatible with "G-Sync".
http://www.pcper.com/news/Graphics-Cards/NVIDIA-Announces-G-Sync-Variable-Refresh-Rate-Monitor-Technology
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedeskt
On 18 October 2013 08:30, Pekka Paalanen wrote:
>
>
> On Thu, 17 Oct 2013 21:34:02 +0100
> James Courtier-Dutton wrote:
>
> > The key point I was trying to make is that the media player needs to be
> > able to predict when frames will be displayed.
>
> Yes, the *player* needs to be able to predi
Hi James,
I'm not a video expert, so excuse me if my view is too simplistic. What
I write is what I'd call common sense, and I'm sure literature would
have specialized algorithms for exactly the things we need, like
prediction.
But, I don't want to tie the protocol into any certain algorithm. The
The key point I was trying to make is that the media player needs to be
able to predict when frames will be displayed.
All its prediction calculations will be based on a fixed scanout rate.
If the scanout rate changes, all bets are off, and we have to start again
from scratch trying to predict the
On 10/17/2013 06:36 AM, Frederic Plourde wrote:
See, at time T=100, for example, if there's this in the queue :
buffer1,T=75
buffer2,T=99
buffer3,T=110
The compositor will drop buffer1 and present buffer2 right away since
buffer2 it's the most recent "past" buffers...
And looking at
Plus of course the same for the next buffer, so you know e.g. how long
a buffer was on screen etc.
How does that sound?
So, the information you propose, with timestamps, gives us timestamps
from events in the past.
Is there any way to deterministically ensure that a particular fra
> > There are various artifacts that appear as a result of frame rate
> adaption.
> > One of these is field dominance. This is where the top field is displayed
> > for longer than the bottom field. This results in the appearance of
> > flickering lines to the viewer.
> > If you could determine how
On Thu, 17 Oct 2013 09:38:41 +0100
James Courtier-Dutton wrote:
> Hi,
>
> I have extensive experience with video streaming and display having worked
> on the xine video player.
> Setting time stamps on a stream of video frames is not the entire solution.
> The biggest problem with displaying vid
Hi,
I have extensive experience with video streaming and display having worked
on the xine video player.
Setting time stamps on a stream of video frames is not the entire solution.
The biggest problem with displaying video on computer displays is "frame
rate adaption".
I.e. The frame rate of the v
2013/10/16 Daniel Stone
> On 16 October 2013 17:09, Jonas Kulla wrote:
> > it might just be a stupid thought of mine, but it would be kinda cool
> > if there was wayland protocol for creating an EGLStream [1] backed
> > surface.
>
> It would be nice, but TTBOMK the only EGLStream implementation
Hi,
On 16 October 2013 17:09, Jonas Kulla wrote:
> it might just be a stupid thought of mine, but it would be kinda cool
> if there was wayland protocol for creating an EGLStream [1] backed
> surface.
It would be nice, but TTBOMK the only EGLStream implementation is in
the Tegra EGL stack, which
2013/10/16 Jonas Kulla
> 2013/10/16 Frederic Plourde
>
>> Hi everybody
>>
>> We're having needs for a streaming_video-capable wl_surface. An extended
>> surface that could "queue buffers up" along with presentation timestamps in
>> the compositor so that videosink clients (like gstreamer's wayla
2013/10/16 Frederic Plourde
> Hi everybody
>
> We're having needs for a streaming_video-capable wl_surface. An extended
> surface that could "queue buffers up" along with presentation timestamps in
> the compositor so that videosink clients (like gstreamer's wayland
> videosink) could more effect
Hi everybody
We're having needs for a streaming_video-capable wl_surface. An extended
surface that could "queue buffers up" along with presentation timestamps
in the compositor so that videosink clients (like gstreamer's wayland
videosink) could more effectively and precisely synchronize audio
28 matches
Mail list logo
