has weston a rtsp video src support?

[Barry Song]

Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月26日周五 上午3:30写道：
>
> On Thu, 25 Jul 2019 13:06:02 +1200
> Barry Song <21cnbao at gmail.com> wrote:
>
> > Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月24日周三 下午8:07写道：
> > >
> > > On Wed, 24 Jul 2019 14:02:43 +1200
> > > Barry Song <21cnbao at gmail.com> wrote:
> > >
> > > > Hi Esaki,
> > > >
> > > > Esaki Tomohito <etom at igel.co.jp> 于2019年7月24日周三 下午1:44写道：
> > > > >
> > > > > Hello Barry,
> > > > >
> > > > > The remoting plugin doesn't support mirroring.
> > > > > If the recently merged pipewire plugin doesn't support mirroring,
> > > > > I think that weston doesn't support remote mirroring.
> > > > >
> > > >
> > > > thanks for your reply. it seems pipewire is a good plugin which can
> > > > move gstreamer pipeline out of weston.  so it makes remote-plugin more
> > > > flexible.
> > > > but it is probably another extended screen rather than mirroring.
> > > >
> > > > I am wondering if it is possible to make the "same-as" clone-mode
> > > > support remote screen as well:
> > > > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html
> > > >
> > > > since remote screen has no real crtc, it should be able to simulate a
> > > > sharing-crtc scenerios which "same-as" clone-mode depends on?
> > >
> > > Hi,
> > >
> > > not the "same-as" directive specifically, because it is reserved
> > > for shared-CRTC cloning where the main feature is that the cloned
> > > outputs' timings are guaranteed to be synchronized in hardware.
> > >
> > > We need a new directive, "clone-of", or whatever, to denote
> > > independent outputs (meaning independent timings, pixel format,
> > > etc.) scanning out the same area of the desktop.
> > >
> > > The reason why that still has not been implemented is libweston's
> > > damage tracking framework. It needs to be re-designed, because
> > > currently it simply cannot have overlapping outputs - damage would
> > > be cleared too early when just the random first output repaints,
> > > leaving other overlapping outputs showing randomly old content.
> > >
> > > Another way could be to use the vaapi-recorder code paths and feed
> > > that video stream to a transmitter - or to pipewire, if the buffer
> > > reservation/release convetions allow (a real DRM output probably
> > > has only few buffers available, so the transmitter cannot keep a
> > > hold of very many at the same time). Another disadvantage is that
> > > the buffer domain, pixel format and modifier must be scanout-able,
> > > which may not be optimal or suitable for e.g. hardware video
> > > encoders. However, vaapi-recorder works, so it can obviously work
> > > at least on Intel.
> >
> > if vaapi-recorder is not available for an embedded system, do you
> > think if hacking libweston/screenshooter.c is an option?
> > i mean writing the frame to pipewire in screenshooter_frame_notify()?
>
> 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?

>
>
> Thanks,
> pq

-barry