has weston a rtsp video src support?

[Barry Song]

Pekka Paalanen <ppaalanen at gmail.com> 于2019年8月3日周六 上午12:06写道：
>
> On Wed, 31 Jul 2019 10:20:22 +1200
> Barry Song <21cnbao at gmail.com> wrote:
>
> > 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?
>
> Hi,
>
> yes, that can work, and it is nicely orthogonal in implementation to
> the real outputs.
>
> It will have the same problem as the remoting plugin already worked
> around with the concept of DRM virtual outputs. Libweston currently
> supports only one backend at a time, but we would really need to able to
> have multiple input and output backends in use at the same time to
> improve the internal architecture and make remoting independent of the
> actual backends.
Hi Pekka,

it seems the memcpy(spa_buffer->datas[0].data, ptr, size) is a big
problem to limit the usage of pipewire.
i am wondering if there is a zero-copy solution to share the drm_fb to
pipewiresrc then to encoder?


static void
pipewire_output_handle_frame(struct pipewire_output *output, int fd,
                             int stride, struct drm_fb *drm_buffer)
{
        ...

        if (pw_stream_get_state(output->stream, NULL) !=
            PW_STREAM_STATE_STREAMING)
                goto out;

        buffer = pw_stream_dequeue_buffer(output->stream);
        if (!buffer) {
                weston_log("Failed to dequeue a pipewire buffer\n");
                goto out;
        }

        spa_buffer = buffer->buffer;

       ...
        ptr = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
        memcpy(spa_buffer->datas[0].data, ptr, size);
        munmap(ptr, size);

       ...

        pw_stream_queue_buffer(output->stream, buffer);
}

>
> An alternative approach would be to hook up to a real existing output
> and copy frames from it when the remote video pipeline is ready to
> consume them. That could also side-step the issue of the video encoder
> wanting to keep a hold of too many old frames for reference, that would
> otherwise cause gbm_surface to run out of buffers.
>
> The screen-share plugin does the copying already through glReadPixels
> from an existing output. That would be fine for a software video
> encoder, but sub-optimal for a hardware video encoder.
>
> FWIW, I wrote down some ramblings here:
> https://gitlab.freedesktop.org/wayland/weston/issues/268
>
>
> Thanks,
> pq


-barry