has weston a rtsp video src support?

[Barry Song]

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()?

>
>
> Thanks,
> pq

-barry