has weston a rtsp video src support?

[Barry Song]

Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月27日周六 下午8:10写道：
>
> On Fri, 26 Jul 2019 13:31:47 +1200
> Barry Song <21cnbao at gmail.com> wrote:
>
> > Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月26日周五 上午3:30写道：
>
> > > Hi,
> > >
> > > I don't think that would work too well, because eglSwapBuffers has
> > > not been called yet at that time, and using glReadPixels would hurt
> > > performance a lot.
> > >
> > > You don't need to use vaapi-recorder per se. You just hook up your
> > > sink exactly like vaapi-recorder does, and pay attention to
> > > synchronization.
> >
> > well. i'd like to continue in this way.
> > another possible solution is using a way like ffpmeg kmsgrab:
> > https://www.ffmpeg.org/ffmpeg-devices.html#Options-10
> >
> > it is using get the DRM framebuffer outside the weston:
> > https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/kmsgrab.c
> > by code like:
> > static int kmsgrab_read_packet(AVFormatContext *avctx, AVPacket *pkt)
> > {
> >     ...
> >     plane = drmModeGetPlane(ctx->hwctx->fd, ctx->plane_id);
> >     ...
> >     fb = drmModeGetFB(ctx->hwctx->fd, plane->fb_id);
> >     ...
> >     err = drmPrimeHandleToFD(ctx->hwctx->fd, fb->handle, O_RDONLY, &fd);
> >     ...
> >     desc = av_mallocz(sizeof(*desc));
> >     ...
> > }
> >
> > do you think if kmsgrab will have some serial synchronization or
> > performance issues?
>
> Hi,
>
> first, I am surprised to hear kmsgrab exists or can even work
> at all. I guess the superuser is allowed to do all kinds of nasty
> things.
>
> I think synchronization issues are unavoidable with kmsgrab.
>
> There is no way to know when Weston flips the FB, right? That means
> you will be polling and randomly sampling the KMS state, so you
> don't know what frames you'll be getting. I imagine that causes
> jerky animation. Or you have to be polling very frequently to
> observe FB changes.
>
> Weston will be using hardware planes. This means that it is not
> enough to sample the primary plane, you have to sample all planes
> and the full KMS state including the active areas of each FB. Then
> you get to composite those various FBs together before you have a
> single picture.
>
> You will probably also have problems with buffer content
> synchronization: you may be reading the content while Weston is
> already flipped to another FB and is half-way repainting the buffer
> you are reading. This will cause artifacts in the image.
>
> So I cannot really recommend that approach at all, based on a
> theoretical analysis.

as said in the other email, independent clone mode has been resolved
by hacking weston damage tracking system.
i am looking for a solution to support remote screen mirroring. the
current idea is making the pipewire display work as a duplicated
display which shows the same content with the physical display.
this will probably resolve the screen mirror issue. would you like to
think it is the right direction?

>
>
> Thanks,
> pq

-barry