Cerbero GStreamer recipes are now built with Meson

[Nirbheek Chauhan]

Hello everyone!

Just a quick note that after extensive testing and porting, all the
GStreamer recipes in Cerbero git master have been moved over to use
Meson on all platforms. The only exception is gst-libav-1.0 which
still uses Autotools, and it is planned to move that to Meson in the
near future. Some of the major advantages of this move:

1. Faster builds on all platforms and toolchains
2. Massively faster and more reliable builds on Windows since Meson
does not use make or shell
3. The future ability to build and ship binaries for Windows built
with Visual Studio, which will allow easier debugging, deployment,
instrumentation, and so on.

This is the second step in the project dropping Autotools in favour of
Meson, the first being gst-build[1], which I hope everyone has been
trying out! This effort involved changes to the GStreamer meson build
files, bug fixes and features to the Meson project, and of course
changes in Cerbero.

Thanks to everyone who contributed to this, particularly Xavier
Claesse and Matthew Waters!

[1] https://cgit.freedesktop.org/gstreamer/gst-build/

I have opened a tracker bug[2] for this change, so please go forth,
test, and report any issues you find or questions you may have.

[2] https://bugzilla.gnome.org/show_bug.cgi?id=797065

Cheers!
Nirbheek

PS: Here's a complete list of recipes that use Meson:

$ grep -rle BuildType.MESON recipes/
recipes/proxy-libintl.recipe
recipes/zlib.recipe
recipes/glib.recipe
recipes/build-tools/glib-tools.recipe
recipes/glib-networking.recipe
recipes/gstreamer-1.0.recipe
recipes/gst-plugins-base-1.0.recipe
recipes/gst-plugins-good-1.0.recipe
recipes/gst-plugins-bad-1.0.recipe
recipes/gst-plugins-ugly-1.0.recipe
recipes/gst-rtsp-server-1.0.recipe
recipes/gst-editing-services-1.0.recipe
recipes/gst-transcoder.recipe
recipes/gst-omx-1.0.recipe
recipes/gst-validate.recipe

Out of these, proxy-libintl, zlib, glib, and glib-networking are built
with Visual Studio on Windows. The rest still use MinGW, but that will
change in the near future.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Black_13]

does gstreamer build with visual studio?

On Sat, Sep 1, 2018 at 5:22 AM Nirbheek Chauhan <[hidden email]> wrote:

Hello everyone!

Just a quick note that after extensive testing and porting, all the
GStreamer recipes in Cerbero git master have been moved over to use
Meson on all platforms. The only exception is gst-libav-1.0 which
still uses Autotools, and it is planned to move that to Meson in the
near future. Some of the major advantages of this move:

1. Faster builds on all platforms and toolchains
2. Massively faster and more reliable builds on Windows since Meson
does not use make or shell
3. The future ability to build and ship binaries for Windows built
with Visual Studio, which will allow easier debugging, deployment,
instrumentation, and so on.

This is the second step in the project dropping Autotools in favour of
Meson, the first being gst-build[1], which I hope everyone has been
trying out! This effort involved changes to the GStreamer meson build
files, bug fixes and features to the Meson project, and of course
changes in Cerbero.

Thanks to everyone who contributed to this, particularly Xavier
Claesse and Matthew Waters!

[1] https://cgit.freedesktop.org/gstreamer/gst-build/

I have opened a tracker bug[2] for this change, so please go forth,
test, and report any issues you find or questions you may have.

[2] https://bugzilla.gnome.org/show_bug.cgi?id=797065

Cheers!
Nirbheek

PS: Here's a complete list of recipes that use Meson:

$ grep -rle BuildType.MESON recipes/
recipes/proxy-libintl.recipe
recipes/zlib.recipe
recipes/glib.recipe
recipes/build-tools/glib-tools.recipe
recipes/glib-networking.recipe
recipes/gstreamer-1.0.recipe
recipes/gst-plugins-base-1.0.recipe
recipes/gst-plugins-good-1.0.recipe
recipes/gst-plugins-bad-1.0.recipe
recipes/gst-plugins-ugly-1.0.recipe
recipes/gst-rtsp-server-1.0.recipe
recipes/gst-editing-services-1.0.recipe
recipes/gst-transcoder.recipe
recipes/gst-omx-1.0.recipe
recipes/gst-validate.recipe

Out of these, proxy-libintl, zlib, glib, and glib-networking are built
with Visual Studio on Windows. The rest still use MinGW, but that will
change in the near future.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nirbheek Chauhan]

On Sat, Sep 1, 2018 at 7:12 PM blackthirt33n <[hidden email]> wrote:
>
> does gstreamer build with visual studio?
>

Not yet, but that is the plan. I'll quote the relevant part of my
email about that:

>> PS: Here's a complete list of recipes that use Meson:
>>
>> $ grep -rle BuildType.MESON recipes/
>> recipes/proxy-libintl.recipe
>> recipes/zlib.recipe
>> recipes/glib.recipe
>> recipes/build-tools/glib-tools.recipe
>> recipes/glib-networking.recipe
>> recipes/gstreamer-1.0.recipe
>> recipes/gst-plugins-base-1.0.recipe
>> recipes/gst-plugins-good-1.0.recipe
>> recipes/gst-plugins-bad-1.0.recipe
>> recipes/gst-plugins-ugly-1.0.recipe
>> recipes/gst-rtsp-server-1.0.recipe
>> recipes/gst-editing-services-1.0.recipe
>> recipes/gst-transcoder.recipe
>> recipes/gst-omx-1.0.recipe
>> recipes/gst-validate.recipe
>>
>> Out of these, proxy-libintl, zlib, glib, and glib-networking are built
>> with Visual Studio on Windows. The rest still use MinGW, but that will
>> change in the near future.

Cheers,
Nirbheek
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Dinh Nguyen]

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Ing]

I am anxiously awaiting the completion of your work Nirbheek.  (Debug symbols on Windows would be very helpful.)

I was wondering:  When you are finished, will it also be possible to use Cerbero to build Gstreamer with the Clang compiler on Windows and Linux?  Or is this strictly a Visual Studio / Windows thing?

On Sat, Sep 1, 2018 at 7:42 AM Nirbheek Chauhan <[hidden email]> wrote:

On Sat, Sep 1, 2018 at 7:12 PM blackthirt33n <[hidden email]> wrote:
>
> does gstreamer build with visual studio?
>

Not yet, but that is the plan. I'll quote the relevant part of my
email about that:

>> PS: Here's a complete list of recipes that use Meson:
>>
>> $ grep -rle BuildType.MESON recipes/
>> recipes/proxy-libintl.recipe
>> recipes/zlib.recipe
>> recipes/glib.recipe
>> recipes/build-tools/glib-tools.recipe
>> recipes/glib-networking.recipe
>> recipes/gstreamer-1.0.recipe
>> recipes/gst-plugins-base-1.0.recipe
>> recipes/gst-plugins-good-1.0.recipe
>> recipes/gst-plugins-bad-1.0.recipe
>> recipes/gst-plugins-ugly-1.0.recipe
>> recipes/gst-rtsp-server-1.0.recipe
>> recipes/gst-editing-services-1.0.recipe
>> recipes/gst-transcoder.recipe
>> recipes/gst-omx-1.0.recipe
>> recipes/gst-validate.recipe
>>
>> Out of these, proxy-libintl, zlib, glib, and glib-networking are built
>> with Visual Studio on Windows. The rest still use MinGW, but that will
>> change in the near future.

Cheers,
Nirbheek
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nirbheek Chauhan]

On Sun, Sep 2, 2018 at 9:42 PM David Ing <[hidden email]> wrote:
>
> I am anxiously awaiting the completion of your work Nirbheek.  (Debug symbols on Windows would be very helpful.)
>
> I was wondering:  When you are finished, will it also be possible to use Cerbero to build Gstreamer with the Clang compiler on Windows and Linux?  Or is this strictly a Visual Studio / Windows thing?
>

You should be able to build GStreamer with Clang on Linux with Cerbero
already. Try setting `CC` and `CXX` to point to clang and clang++
respectively. This should be correctly picked up by Meson, Autotools,
and CMake inside Cerbero.

For Windows, there's a bunch of different configurations in which you
can use Clang: Clang/MinGW (ld or lld) and Clang/MSVC (link.exe or
lld). None of these are supported right now, but it should be possible
to use them with some work. Foremost, there are some Meson bugs that
need to be fixed[1], and then Cerbero will need a flag to select the
toolchain to use for Meson recipes. Currently on Windows, there is
just one flag that flips whether a Meson recipe is built with the
MinGW toolchain setup by Cerbero or MSVC found on the system. That can
be converted to an enum with a list of valid values.

[1] List of bugs:
https://github.com/mesonbuild/meson/issues/534
https://github.com/mesonbuild/meson/issues/2560
https://github.com/mesonbuild/meson/issues/2622
https://github.com/mesonbuild/meson/issues/3597
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le sam. 1 sept. 2018 23:57, Dinh Nguyen <[hidden email]> a écrit :

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink 

To rtspclientsink you should provide one or more RTP stream. To change h264 into RTP, you need to add rtph264pay.

location=rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Dinh Nguyen]

Hello Nicolas,

Thanks for your response.

I am trying with your suggestion

`gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! rtspclientsink location=rtsp://<a href="http://127.0.0.1:8554/test`">127.0.0.1:8554/test`

however, seems that the pipe itself get error

`WARNING: erroneous pipeline: could not link rtph264pay0 to rtspclientsink0`.

I am not sure I get your suggestion right?

Thanks.

On Mon, Sep 3, 2018 at 2:09 AM Nicolas Dufresne <[hidden email]> wrote:

Le sam. 1 sept. 2018 23:57, Dinh Nguyen <[hidden email]> a écrit :

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink 

To rtspclientsink you should provide one or more RTP stream. To change h264 into RTP, you need to add rtph264pay.

location=rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matthew Waters]

On 3/9/18 3:37 pm, Dinh Nguyen wrote:

Hello Nicolas,

Thanks for your response.

I am trying with your suggestion

`gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! rtspclientsink location=<a class="moz-txt-link-freetext" href="rtsp://">rtsp://<a href="http://127.0.0.1:8554/test`" moz-do-not-send="true">127.0.0.1:8554/test`

however, seems that the pipe itself get error

`WARNING: erroneous pipeline: could not link rtph264pay0 to rtspclientsink0`.

I am not sure I get your suggestion right?

rtspclientsink already includes payloaders so you don't need a rtph264pay there.

What you're missing is that the name of the elements need to match a specific format. i.e. the depayloader in your test-record command line needs to be named 'depay0'.  You also may need to modify the test-record example to send an EOS on shutdown so that mp4 headers are finalized correctly as the resulting fiel will not really be playable as-is.  Another option is to attempt to attempt enable robust-muxing mode.

Cheers
-Matt

Thanks.

On Mon, Sep 3, 2018 at 2:09 AM Nicolas Dufresne <[hidden email]> wrote:

Le sam. 1 sept. 2018 23:57, Dinh Nguyen <[hidden email]> a écrit :

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at <a class="moz-txt-link-freetext" href="rtsp://">rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=<a class="moz-txt-link-freetext" href="rtsp://">rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink 

To rtspclientsink you should provide one or more RTP stream. To change h264 into RTP, you need to add rtph264pay.

location=<a class="moz-txt-link-freetext" href="rtsp://">rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to <a class="moz-txt-link-freetext" href="rtsp://">rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lun. 3 sept. 2018 01:57, Matthew Waters <[hidden email]> a écrit :

On 3/9/18 3:37 pm, Dinh Nguyen wrote:

Hello Nicolas,

Thanks for your response.

I am trying with your suggestion

`gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! rtspclientsink location=rtsp://127.0.0.1:8554/test`

however, seems that the pipe itself get error

`WARNING: erroneous pipeline: could not link rtph264pay0 to rtspclientsink0`.

I am not sure I get your suggestion right?

rtspclientsink already includes payloaders so you don't need a rtph264pay there.

Sorry for the noise, I was expecting that element to be consistent with rtspsrc.

It's quite inconsistent and forces depayloading and payloading again if one wants to implement a relay.

What you're missing is that the name of the elements need to match a specific format. i.e. the depayloader in your test-record command line needs to be named 'depay0'.  You also may need to modify the test-record example to send an EOS on shutdown so that mp4 headers are finalized correctly as the resulting fiel will not really be playable as-is.  Another option is to attempt to attempt enable robust-muxing mode.

Cheers
-Matt

Thanks.

On Mon, Sep 3, 2018 at 2:09 AM Nicolas Dufresne <[hidden email]> wrote:

Le sam. 1 sept. 2018 23:57, Dinh Nguyen <[hidden email]> a écrit :

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink 

To rtspclientsink you should provide one or more RTP stream. To change h264 into RTP, you need to add rtph264pay.

location=rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Dinh Nguyen]

Hello Matthew,

Thanks a lot, it is working for me know.

Well, the pipeline elements are so confusing for me. How could one know that after this element should be that element; is there something like interface?

Thanks again.

On Mon, Sep 3, 2018 at 12:55 PM Matthew Waters <[hidden email]> wrote:

On 3/9/18 3:37 pm, Dinh Nguyen wrote:

Hello Nicolas,

Thanks for your response.

I am trying with your suggestion

`gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! rtspclientsink location=rtsp://127.0.0.1:8554/test`

however, seems that the pipe itself get error

`WARNING: erroneous pipeline: could not link rtph264pay0 to rtspclientsink0`.

I am not sure I get your suggestion right?

rtspclientsink already includes payloaders so you don't need a rtph264pay there.

What you're missing is that the name of the elements need to match a specific format. i.e. the depayloader in your test-record command line needs to be named 'depay0'.  You also may need to modify the test-record example to send an EOS on shutdown so that mp4 headers are finalized correctly as the resulting fiel will not really be playable as-is.  Another option is to attempt to attempt enable robust-muxing mode.

Cheers
-Matt

Thanks.

On Mon, Sep 3, 2018 at 2:09 AM Nicolas Dufresne <[hidden email]> wrote:

Le sam. 1 sept. 2018 23:57, Dinh Nguyen <[hidden email]> a écrit :

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink 

To rtspclientsink you should provide one or more RTP stream. To change h264 into RTP, you need to add rtph264pay.

location=rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matthew Waters]

That is known from experience and looking at various outputs such as 'gst-inspect-1.0 $ELEMENT' or GST_DEBUG=3 or even GST_DEBUG=*PAD*:5,3

For the element naming, the test-record --help output is useful for this.

Cheers
-Matt

On 4/9/18 12:57 am, Dinh Nguyen wrote:

Hello Matthew,

Thanks a lot, it is working for me know.

Well, the pipeline elements are so confusing for me. How could one know that after this element should be that element; is there something like interface?

Thanks again.

On Mon, Sep 3, 2018 at 12:55 PM Matthew Waters <[hidden email]> wrote:

On 3/9/18 3:37 pm, Dinh Nguyen wrote:

Hello Nicolas,

Thanks for your response.

I am trying with your suggestion

`gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! rtspclientsink location=rtsp://127.0.0.1:8554/test`

however, seems that the pipe itself get error

`WARNING: erroneous pipeline: could not link rtph264pay0 to rtspclientsink0`.

I am not sure I get your suggestion right?

rtspclientsink already includes payloaders so you don't need a rtph264pay there.

What you're missing is that the name of the elements need to match a specific format. i.e. the depayloader in your test-record command line needs to be named 'depay0'.  You also may need to modify the test-record example to send an EOS on shutdown so that mp4 headers are finalized correctly as the resulting fiel will not really be playable as-is.  Another option is to attempt to attempt enable robust-muxing mode.

Cheers
-Matt

Thanks.

On Mon, Sep 3, 2018 at 2:09 AM Nicolas Dufresne <[hidden email]> wrote:

Le sam. 1 sept. 2018 23:57, Dinh Nguyen <[hidden email]> a écrit :

Hello,

I am new to GStreamer ecosystem, and nowhere to be good at C; hence, please forgive if I put this silly question here.

I am using gst-rtsp server, with test-record to save a "record" stream from client to a file (mp4), and this is the error.

GST_DEBUG=2 ./build/test-record "( rtph264depay ! h264parse ! mp4mux ! filesink location=result3.mp4 )"
stream ready at rtsp://127.0.0.1:8554/test
On the sender, send a stream with rtspclientsink:
  gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink location=rtsp://127.0.0.1:8554/test
0:00:09.120079875   951       0xd0a190 ERROR              rtspmedia rtsp-media.c:3637:default_handle_sdp: 0x7f93380452b0: Media has more or less streams than SDP (0 /= 1)
0:00:09.120101464   951       0xd0a190 ERROR             rtspclient rtsp-client.c:2946:handle_sdp: client 0xe551a0: could not handle SDP
0:00:09.120110777   951       0xd0a190 ERROR             rtspclient rtsp-client.c:3107:handle_announce_request: client 0xe551a0: can't handle SDP

​

This is the client side:

gst-launch-1.0 videotestsrc ! x264enc ! rtspclientsink 

To rtspclientsink you should provide one or more RTP stream. To change h264 into RTP, you need to add rtph264pay.

location=rtsp://127.0.0.1:8554/test
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://127.0.0.1:8554/test
Redistribute latency...
Progress: (open) Retrieving server options
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending RECORD request
Progress: (record) Sending server stream info
ERROR: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not read from resource.
Additional debug info:
gstrtspclientsink.c(3059): gst_rtsp_client_sink_send (): /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0:
Got error response: 415 (Unsupported Media Type).
Execution ended after 0:00:00.046342782
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

​

Could you please give me a hint for this problems.

Thanks in advanced.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Ing]

Thanks ... this is all very helpful.

On Sun, Sep 2, 2018 at 10:12 AM Nirbheek Chauhan <[hidden email]> wrote:

On Sun, Sep 2, 2018 at 9:42 PM David Ing <[hidden email]> wrote:
>
> I am anxiously awaiting the completion of your work Nirbheek.  (Debug symbols on Windows would be very helpful.)
>
> I was wondering:  When you are finished, will it also be possible to use Cerbero to build Gstreamer with the Clang compiler on Windows and Linux?  Or is this strictly a Visual Studio / Windows thing?
>

You should be able to build GStreamer with Clang on Linux with Cerbero
already. Try setting `CC` and `CXX` to point to clang and clang++
respectively. This should be correctly picked up by Meson, Autotools,
and CMake inside Cerbero.

For Windows, there's a bunch of different configurations in which you
can use Clang: Clang/MinGW (ld or lld) and Clang/MSVC (link.exe or
lld). None of these are supported right now, but it should be possible
to use them with some work. Foremost, there are some Meson bugs that
need to be fixed[1], and then Cerbero will need a flag to select the
toolchain to use for Meson recipes. Currently on Windows, there is
just one flag that flips whether a Meson recipe is built with the
MinGW toolchain setup by Cerbero or MSVC found on the system. That can
be converted to an enum with a list of valid values.

[1] List of bugs:
https://github.com/mesonbuild/meson/issues/534
https://github.com/mesonbuild/meson/issues/2560
https://github.com/mesonbuild/meson/issues/2622
https://github.com/mesonbuild/meson/issues/3597
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Ing]

Nirbheek's suggestion for building with Clang (using Cerbero) on Linux did not work.

The environment variables `CC` and `CXX` are overridden inside of the file `cerbero/config/linux.config`.  Sure, I can hack the file (along with the flags and everything) but it still doesn't work because there are lots of incompatibilities.  For example, this is the first error I see after `./cerbero-uninstalled build gstreamer-1.0`

Building the following recipes: libffi zlib glib gtk-doc-lite gobject-introspection gstreamer-1.0

[(1/6) libffi -> fetch ]

[(1/6) libffi -> extract ]

[(1/6) libffi -> configure ]

Running command 'autoreconf -f -i'

libtoolize: putting auxiliary files in '.'.

libtoolize: copying file './ltmain.sh'

libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.

libtoolize: copying file 'm4/libtool.m4'

libtoolize: copying file 'm4/ltoptions.m4'

libtoolize: copying file 'm4/ltsugar.m4'

libtoolize: copying file 'm4/ltversion.m4'

libtoolize: copying file 'm4/lt~obsolete.m4'

configure.ac:187: error: possibly undefined macro: LT_SYS_SYMBOL_USCORE

      If this token and others are legitimate, please use m4_pattern_allow.

      See the Autoconf documentation.

autoreconf: /usr/bin/autoconf failed with exit status: 1

I assumed it wasn't going to be that easy ... there is another thread where someone got Clang working for a particular cross-compilation but it was a lot of work:  http://gstreamer-devel.966125.n4.nabble.com/Clang-port-of-GStreamer-1-12-4-to-Android-td4687313.html  (He also gradle-ized the build.)

It would be a lot of work to accomplish a similar feat using Cerbero ... I wish I had the time but I don't.

On Mon, Sep 3, 2018 at 8:38 AM David Ing <[hidden email]> wrote:

Thanks ... this is all very helpful.

On Sun, Sep 2, 2018 at 10:12 AM Nirbheek Chauhan <[hidden email]> wrote:

On Sun, Sep 2, 2018 at 9:42 PM David Ing <[hidden email]> wrote:
>
> I am anxiously awaiting the completion of your work Nirbheek.  (Debug symbols on Windows would be very helpful.)
>
> I was wondering:  When you are finished, will it also be possible to use Cerbero to build Gstreamer with the Clang compiler on Windows and Linux?  Or is this strictly a Visual Studio / Windows thing?
>

You should be able to build GStreamer with Clang on Linux with Cerbero
already. Try setting `CC` and `CXX` to point to clang and clang++
respectively. This should be correctly picked up by Meson, Autotools,
and CMake inside Cerbero.

For Windows, there's a bunch of different configurations in which you
can use Clang: Clang/MinGW (ld or lld) and Clang/MSVC (link.exe or
lld). None of these are supported right now, but it should be possible
to use them with some work. Foremost, there are some Meson bugs that
need to be fixed[1], and then Cerbero will need a flag to select the
toolchain to use for Meson recipes. Currently on Windows, there is
just one flag that flips whether a Meson recipe is built with the
MinGW toolchain setup by Cerbero or MSVC found on the system. That can
be converted to an enum with a list of valid values.

[1] List of bugs:
https://github.com/mesonbuild/meson/issues/534
https://github.com/mesonbuild/meson/issues/2560
https://github.com/mesonbuild/meson/issues/2622
https://github.com/mesonbuild/meson/issues/3597
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nirbheek Chauhan]

On Wed, Sep 5, 2018 at 10:12 PM David Ing <[hidden email]> wrote:
> The environment variables `CC` and `CXX` are overridden inside of the file `cerbero/config/linux.config`.  Sure, I can hack the file (along with the flags and everything) but it still doesn't work because there are lots of incompatibilities.  For example, this is the first error I see after `./cerbero-uninstalled build gstreamer-1.0`
>

I think you forgot to run bootstrap? Anyway, bootstrap fails with
clang while building m4, so I built the build-tools with gcc (doesn't
matter what they are built with). Then, the first failure was in
gobject-introspection:

./g-ir-compiler --includedir=. --includedir=./gir --includedir=.
--includedir=. --includedir=./gir --includedir=. gir/cairo-1.0.gir -o
gir/cairo-1.0.typelib
clang-6.0: error: unknown argument: '-fcf-protection'
Traceback (most recent call last):
  File "/usr/lib64/python3.6/distutils/unixccompiler.py", line 127, in _compile
    extra_postargs)
  File "/usr/lib64/python3.6/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/usr/lib64/python3.6/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/usr/lib64/python3.6/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'ccache' failed with exit status 1

So that either needs to be fixed, or introspection needs to be
disabled everywhere as a start. Overall, I think this is probably
doable. The main issues will be autotools recipes, but any meson
recipes should be fine.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Ing]

Ahh... I had deleted my `cerbero/build` folder without re-running `bootstrap`.

I did not have g-ir error because I had installed `libgirepository1.0-dev` on my system (this also overcomes an error via in gst-build).

I got a different error when running bootstrap.  (

clang    -I../lib -I../lib    -g -gcodeview -O2 -m64  -g -gcodeview -O2 -m64   -Wno-error=cast-align -MT symtab.o -MD -MP -MF $depbase.Tpo -c -o symtab.o symtab.c &&\

mv -f $depbase.Tpo $depbase.Po

clang   -g -gcodeview -O2 -m64  -g -gcodeview -O2 -m64   -Wno-error=cast-align  -L/home/ding/github/gstreamer/cerbero/build/build-tools/lib  -m64  -m64  -o m4 m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o symtab.o ../lib/libm4.a    

clang: warning: argument unused during compilation: '-gcodeview' [-Wunused-command-line-argument]

clang: warning: argument unused during compilation: '-gcodeview' [-Wunused-command-line-argument]

symtab.o: In function `symtab_init':

symtab.c:(.text+0x27): undefined reference to `__muloti4'

../lib/libm4.a(clean-temp.o): In function `create_temp_dir':

clean-temp.c:(.text+0xa3): undefined reference to `__muloti4'

../lib/libm4.a(fatal-signal.o): In function `at_fatal_signal':

fatal-signal.c:(.text+0x1a2): undefined reference to `__muloti4'

../lib/libm4.a(xmalloc.o): In function `xnmalloc':

xmalloc.c:(.text+0x1d): undefined reference to `__muloti4'

../lib/libm4.a(xmalloc.o): In function `xnrealloc':

xmalloc.c:(.text+0xb8): undefined reference to `__muloti4'

../lib/libm4.a(xmalloc.o):xmalloc.c:(.text+0x29d): more undefined references to `__muloti4' follow

clang: error: linker command failed with exit code 1 (use -v to see invocation)

Makefile:1554: recipe for target 'm4' failed

make[2]: *** [m4] Error 1

make[2]: Leaving directory '/home/ding/github/gstreamer/cerbero/build/sources/build-tools/m4-1.4.18/src'

Makefile:1572: recipe for target 'all-recursive' failed

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory '/home/ding/github/gstreamer/cerbero/build/sources/build-tools/m4-1.4.18'

Makefile:1528: recipe for target 'all' failed

make: *** [all] Error 2

Recipe 'm4' failed at the build step 'compile'

Select an action to proceed:

[0] Enter the shell

[1] Rebuild the recipe from scratch

[2] Rebuild starting from the failed step

[3] Skip recipe

[4] Abort

4

***** Error running 'bootstrap' command:

For reference, I have attached my hacked version of the `config/linux.config` file.

While doable, I think it would take a long time to brute-force your way through all the bugs.

On Wed, Sep 5, 2018 at 10:57 AM Nirbheek Chauhan <[hidden email]> wrote:

On Wed, Sep 5, 2018 at 10:12 PM David Ing <[hidden email]> wrote:
> The environment variables `CC` and `CXX` are overridden inside of the file `cerbero/config/linux.config`.  Sure, I can hack the file (along with the flags and everything) but it still doesn't work because there are lots of incompatibilities.  For example, this is the first error I see after `./cerbero-uninstalled build gstreamer-1.0`
>

I think you forgot to run bootstrap? Anyway, bootstrap fails with
clang while building m4, so I built the build-tools with gcc (doesn't
matter what they are built with). Then, the first failure was in
gobject-introspection:

./g-ir-compiler --includedir=. --includedir=./gir --includedir=.
--includedir=. --includedir=./gir --includedir=. gir/cairo-1.0.gir -o
gir/cairo-1.0.typelib
clang-6.0: error: unknown argument: '-fcf-protection'
Traceback (most recent call last):
  File "/usr/lib64/python3.6/distutils/unixccompiler.py", line 127, in _compile
    extra_postargs)
  File "/usr/lib64/python3.6/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/usr/lib64/python3.6/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/usr/lib64/python3.6/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'ccache' failed with exit status 1

So that either needs to be fixed, or introspection needs to be
disabled everywhere as a start. Overall, I think this is probably
doable. The main issues will be autotools recipes, but any meson
recipes should be fine.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nirbheek Chauhan]

On Thu, Sep 6, 2018 at 12:44 AM David Ing <[hidden email]> wrote:
>
> Ahh... I had deleted my `cerbero/build` folder without re-running `bootstrap`.
>
> I did not have g-ir error because I had installed `libgirepository1.0-dev` on my system (this also overcomes an error via in gst-build).
>
> I got a different error when running bootstrap.  (
>

Well, like I said, I did not run bootstrap with clang. I ran that with
gcc precisely because of this error. Of course, for a proper port that
would also need to be fixed.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel