[Help] streaming GoPro Hero 4

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Help] streaming GoPro Hero 4

Gal Nissim
Dear GStrreamers,

I'm trying to stream GoPro Hero 4.
I tried the following pipelines that were suggested by Tim Müller (here) but nothing appears. I did manage to stream using ffplay

Does anyone have an idea why it's not working?

I will appreciate if you can share your thoughts with me.
Thanks,
Gal


Tim's suggestions:

Video only:
gst-launch-1.0 -e -v udpsrc port=8554 ! queue ! decodebin ! videoconvert ! videoscale ! autovideosink

Audio and video:
gst-launch-1.0 -e -v udpsrc port=8554 ! queue ! decodebin name=d d. ! queue ! videoconvert ! videoscale ! autovideosink d. ! queue ! audioconvert ! audioresample ! autoaudiosink

Audio and video (shorter command)
gst-launch-1.0 -e -v playbin uri=udp://127.0.0.1:8554


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Sebastian Dröge-3
On Mo, 2016-06-13 at 23:14 -0400, Gal Nissim wrote:
> Dear GStrreamers,
>
> I'm trying to stream GoPro Hero 4.
> I tried the following pipelines that were suggested by Tim Müller
> (here) but nothing appears. I did manage to stream using ffplay. 
>
> Does anyone have an idea why it's not working?
>
> I will appreciate if you can share your thoughts with me.

How does it not work? You try to receive data on localhost on UDP port
8554, that's probably not what you want, right? Can you check with e.g.
wireshark, where data is arriving and if any is arriving at all?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Gal Nissim
Hi Sebastian,

I checked the udp traffic on the wifi interface with Wireshark as you suggested, and everything seems to be working fine (attached is a print screen):






This is the output I got after restarting the connection in the browser using: http://10.5.5.9:8080/gp/gpControl/execute?p1=gpStream&c1=restart
and running the following command:

$ gst-launch-1.0 -e -v udpsrc port=8554 ! queue ! decodebin ! videoconvert ! videoscale ! autovideosink

Setting pipeline to PAUSED ...

Pipeline is live and does not need PREROLL ...

Got context from element 'autovideosink0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayCocoa\)\ gldisplaycocoa0";

Setting pipeline to PLAYING ...

New clock: GstSystemClock

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = "video/mpegts\,\ systemstream\=\(boolean\)true\,\ packetsize\=\(int\)188"

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTSDemux:tsdemux0.GstPad:sink: caps = "video/mpegts\,\ systemstream\=\(boolean\)true\,\ packetsize\=\(int\)188"

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: max-size-buffers = 5

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: max-size-time = 0

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: max-size-bytes = 2097152


Do you have any idea what can be wrong?

Thanks,

Gal


On Tue, Jun 14, 2016 at 2:02 AM, Sebastian Dröge <[hidden email]> wrote:
On Mo, 2016-06-13 at 23:14 -0400, Gal Nissim wrote:
> Dear GStrreamers,
>
> I'm trying to stream GoPro Hero 4.
> I tried the following pipelines that were suggested by Tim Müller
> (here) but nothing appears. I did manage to stream using ffplay. 
>
> Does anyone have an idea why it's not working?
>
> I will appreciate if you can share your thoughts with me.

How does it not work? You try to receive data on localhost on UDP port
8554, that's probably not what you want, right? Can you check with e.g.
wireshark, where data is arriving and if any is arriving at all?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Gal Nissim-2
In reply to this post by Sebastian Dröge-3
Hi Sebastian,

I checked the udp traffic on the wifi interface with Wireshark as you suggested, and everything seems to be working fine (attached is a print screen):





This is the output I got after restarting the connection in the browser using: http://10.5.5.9:8080/gp/gpControl/execute?p1=gpStream&c1=restart
and running the following command:

$ gst-launch-1.0 -e -v udpsrc port=8554 ! queue ! decodebin ! videoconvert ! videoscale ! autovideosink

Setting pipeline to PAUSED ...

Pipeline is live and does not need PREROLL ...

Got context from element 'autovideosink0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayCocoa\)\ gldisplaycocoa0";

Setting pipeline to PLAYING ...

New clock: GstSystemClock

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = "video/mpegts\,\ systemstream\=\(boolean\)true\,\ packetsize\=\(int\)188"

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTSDemux:tsdemux0.GstPad:sink: caps = "video/mpegts\,\ systemstream\=\(boolean\)true\,\ packetsize\=\(int\)188"

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: max-size-buffers = 5

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: max-size-time = 0

/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: max-size-bytes = 2097152


Do you have any idea what can be wrong?

Thanks,

Gal


On Tue, Jun 14, 2016 at 2:02 AM, Sebastian Dröge <[hidden email]> wrote:
On Mo, 2016-06-13 at 23:14 -0400, Gal Nissim wrote:
> Dear GStrreamers,
>
> I'm trying to stream GoPro Hero 4.
> I tried the following pipelines that were suggested by Tim Müller
> (here) but nothing appears. I did manage to stream using ffplay. 
>
> Does anyone have an idea why it's not working?
>
> I will appreciate if you can share your thoughts with me.

How does it not work? You try to receive data on localhost on UDP port
8554, that's probably not what you want, right? Can you check with e.g.
wireshark, where data is arriving and if any is arriving at all?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Sebastian Dröge-3
In reply to this post by Gal Nissim
On Mi, 2016-06-15 at 21:54 -0400, Gal Nissim wrote:
> Hi Sebastian,
>
> I checked the udp traffic on the wifi interface with Wireshark as you
> suggested, and everything seems to be working fine (attached is a
> print screen):
> [...]

You're running this on the machine with the IP 10.5.5.100? What happens
if you run

  gst-launch-1.0 udpsrc address=10.5.5.100 port=8554 ! fakesink dump=true

It should dump all packets to stdout, if any are received (which they
apparently are according to wireshark).


Your log suggests that packets are actually received and MPEG-TS is
detected and then handled by tsdemux. So the more relevant question in
the end is then probably what goes wrong in tsdemux or afterwards.

Can you get a full debug log with GST_DEBUG=6?

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Gal Nissim
Hi Sebastian,

I'm working with Andres Colubri (cc'ed) in order to develop Processing's video library and to enable streaming from GoPro.
Attached is the URL to the output that we have got from the full debug (https://drive.google.com/file/d/0B6N7AGfVtzMHYlFWZm81VEdIQlU/view?usp=sharing).

We saw this message: tsdemux tsdemux.c:2576:gst_ts_demux_push_pending_data: Not enough information to push buffers yet, storing buffer
that made us think that the video is not fully processed. 

We don't fully understand the output and will appreciate your help,
Thanks,
Andres and Gal

On Fri, Jun 17, 2016 at 7:23 AM, Sebastian Dröge <[hidden email]> wrote:
On Mi, 2016-06-15 at 21:54 -0400, Gal Nissim wrote:
> Hi Sebastian,
>
> I checked the udp traffic on the wifi interface with Wireshark as you
> suggested, and everything seems to be working fine (attached is a
> print screen):
> [...]

You're running this on the machine with the IP 10.5.5.100? What happens
if you run

  gst-launch-1.0 udpsrc address=10.5.5.100 port=8554 ! fakesink dump=true

It should dump all packets to stdout, if any are received (which they
apparently are according to wireshark).


Your log suggests that packets are actually received and MPEG-TS is
detected and then handled by tsdemux. So the more relevant question in
the end is then probably what goes wrong in tsdemux or afterwards.

Can you get a full debug log with GST_DEBUG=6?

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Sebastian Dröge-3
On Fr, 2016-06-17 at 14:19 -0400, Gal Nissim wrote:

> Hi Sebastian,
>
> I'm working with Andres Colubri (cc'ed) in order to develop
> Processing's video library and to enable streaming from GoPro.
> Attached is the URL to the output that we have got from the full
> debug (https://drive.google.com/file/d/0B6N7AGfVtzMHYlFWZm81VEdIQlU/v
> iew?usp=sharing).
>
> We saw this message: tsdemux
> tsdemux.c:2576:gst_ts_demux_push_pending_data: Not enough information
> to push buffers yet, storing buffer
> that made us think that the video is not fully processed. 
>
> We don't fully understand the output and will appreciate your help,
Shortly looking through the log suggests that there is quite some
packet loss, and the MPEG TS demuxer never gets enough packets in a row
to actually start demuxing properly. Search for "lost sync" in the log.

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Gal Nissim
Dear Sebastian,

Since the GoPro Hero 4 is streaming with "ffplay", I guess the problem is not in the GoPro hardware but rather a bug in GStreamer. 

Here is an example of an apirance for "lost sync" in the log file ("lost sync" appeared repetitively):

0:00:02.345848000 48195 0x7f9b01063280 LOG               mpegtsbase mpegtsbase.c:1207:mpegts_base_chain: PID 0x1011 Saw packet on a pid we don't handle
0:00:02.345857000 48195 0x7f9b01063280 DEBUG       mpegtspacketizer mpegtspacketizer.c:841:mpegts_packetizer_next_packet: lost sync
0:00:02.345864000 48195 0x7f9b01063280 LOG         mpegtspacketizer mpegtspacketizer.c:676:mpegts_packetizer_flush_bytes: flushing 3608 bytes from 

Thank you so much,
Gal

On Tue, Jun 21, 2016 at 2:47 AM, Sebastian Dröge <[hidden email]> wrote:
On Fr, 2016-06-17 at 14:19 -0400, Gal Nissim wrote:
> Hi Sebastian,
>
> I'm working with Andres Colubri (cc'ed) in order to develop
> Processing's video library and to enable streaming from GoPro.
> Attached is the URL to the output that we have got from the full
> debug (https://drive.google.com/file/d/0B6N7AGfVtzMHYlFWZm81VEdIQlU/v
> iew?usp=sharing).
>
> We saw this message: tsdemux
> tsdemux.c:2576:gst_ts_demux_push_pending_data: Not enough information
> to push buffers yet, storing buffer
> that made us think that the video is not fully processed. 
>
> We don't fully understand the output and will appreciate your help,

Shortly looking through the log suggests that there is quite some
packet loss, and the MPEG TS demuxer never gets enough packets in a row
to actually start demuxing properly. Search for "lost sync" in the log.

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Sebastian Dröge-3
On Mi, 2016-06-22 at 21:10 -0400, Gal Nissim wrote:

> Dear Sebastian,
>
> Since the GoPro Hero 4 is streaming with "ffplay", I guess the
> problem is not in the GoPro hardware but rather a bug in GStreamer. 
>
> Here is an example of an apirance for "lost sync" in the log file
> ("lost sync" appeared repetitively):
>
> 0:00:02.345848000 48195 0x7f9b01063280 LOG               mpegtsbase
> mpegtsbase.c:1207:mpegts_base_chain: PID 0x1011 Saw packet on a pid
> we don't handle
> 0:00:02.345857000 48195 0x7f9b01063280 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:841:mpegts_packetizer_next_packet: lost sync
> 0:00:02.345864000 48195 0x7f9b01063280 LOG         mpegtspacketizer
> mpegtspacketizer.c:676:mpegts_packetizer_flush_bytes: flushing 3608
> bytes from 
Yes that's exactly what I'm saying ;)


You can try increasing the buffer size of the udpsrc for starters, that
might help with the problem.

In any case, you'll have to check if the problem is really packet loss
(from which ffmpeg might recover better for whatever reason, and we
should improve our demuxer then), or if reading from the UDP socket
happens too slow.

It would also help if you could make a dump of the stream available,
then someone could take a closer look at that. Just connect udpsrc with
a queue and a filesink.

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Help] streaming GoPro Hero 4

Topilski
This post was updated on .
In reply to this post by Gal Nissim
Hi we also have the same message
Gal Nissim wrote
We saw this message: tsdemux tsdemux.c:2576:gst_ts_demux_push_pending_data:
Not enough information to push buffers yet, storing buffer
that made us think that the video is not fully processed.
 , our pipeline looks like: GST_DEBUG=tsdemux:5 gst-launch-1.0 -e -v souphttpsrc location="http://109.104.129.134:8001/1" ! tsdemux name=decode ! queue ! videoconvert ! x264enc ! queue ! flvmux streamable=true name=mux ! filesink location=out.flv decode. ! queue ! audioconvert ! faac ! queue ! mux.

How you can see we use souphttpsrc as sources, in our case we can't lost packages in anyway. Also we think that all incoming data skipped in tsdemux.