has weston a rtsp video src support?

[Pekka Paalanen]

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190725/afaf51c9/attachment.sig>