webrtc example: feeding video data from a pipeline

[Guennadi Liakhovetski]

On Sat, 10 Oct 2020, Anton Pryima wrote:

> Hi Guennadi,
>
> In such a case, you do not need a video decoder on the RPi side.
> What is your receiving side?

I plan to use a browser, yes.

> If it is a browser, please, ensure that the
> required H264 profile is supported on the receiving side.
> (profile you can check in SDP you've got from RPI). This can cause video
> freezing or absence at all.

I see on the RPi:

Received SDP:
...
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 96
...
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000

Does that mean that H264 is supported? I compared that with a browser,
where the video is frozen, it also contains the same H264 line, but there
are some differences too, e.g. it also has

a=sendrecv

in addition to

a=recvonly

> To receive just audio at RPi, you need to comment out
> handle_media_stream (pad, pipe, "videoconvert", "autovideosink"); at line
> 167 of sendrecv/gst/webrtc-sendrecv.c.

Yes, I've done that already, that's how I got rid of incoming video on the
RPi.

> Then, at line 383 of the same file, you need to change:
> "videotestsrc is-live=true pattern=ball
> to your:
> "raspivid -t 0 -h 480 -w 640 -fps 25 -hf -b 2000000
> (same change for your audio stream)

Hm, how is this supposed to work? "videotestsrc" is a gstreamer pipeline
element, "raspivid" is a standalone application. You cannot just put it in
the string for gst_parse_launch()? That's why I tried to get them to
stream data via a named pipe, but that didn't work.

Thanks
Guennadi

> Leave everything as is.
>
> Best regards,
> Anton.
>
> On Sat, Oct 10, 2020 at 2:26 PM Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> wrote:
>
> > Hi Anton,
> >
> > On Sat, 10 Oct 2020, Anton Pryima wrote:
> >
> > > Hello Guennadi,
> > >
> > > >From your attachment, it is not clear what are you planning to achieve.
> > Is
> > > RPi the 'send only' side, or you wanna get a stream from the browser at
> > it?
> > > The first log said that you have the wrong SDP (empty one). The second
> > one
> > > has errors in the decoder (but it is not clear why you need a decoder at
> > > the RPi side.).
> > >
> > > Can you describe, what result are you expecting?
> >
> > In your previous email you asked me to verify whether and how well
> > unmodified webrtc examples run on my RPi to check whether all plugins are
> > available etc. So, my previous email contained exactly that - results of
> > running two unmodified (well, the sources are modified, but I ran them in
> > case of sendrecv in the original mode, in case of sendonly modified for
> > videotestsrc) webrtc examples. That means, all the plugins are available,
> > and the result is successful, even if I'm getting errors and the RPi
> > reboots sporadically...
> >
> > The end-goal would be a "telepresence" type of a device: the RPi should
> > send video and audio and should be able to receive and play back audio.
> >
> > Thanks
> > Guennadi
> >
> > > Best regards,
> > > Anton.
> > >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
>