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 |
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 |
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: _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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: _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 |
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: _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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, 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 |
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: _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 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 |
This post was updated on .
In reply to this post by Gal Nissim
Hi we also have the same message
, 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. |
Free forum by Nabble | Edit this page |