GNOME Bugzilla – Bug 752843
tsdemux: doesn't handle streams without PCR
Last modified: 2018-11-03 13:38:30 UTC
Hi, I'm trying to make GoPro 4 live preview (mpegts stream) to work with GStreamer and faced with an issue, that tsdemux doesn't push packet further, because it expects PTS/DTS timestamps. On iOS. The problem is, GoPro 4 doesn't set those in PES header. I'm not quite sure why or whether it is correct behaviour for mpeg ts stream broadcaster. But the thing is, I was able to play this stream with ffplay. I dind't go further in comparing ffmpeg mpegts demux with tsdemux. Maybe there's some well know limitation in GStreamer. I would really appriciate any help on this. I'll attach everything I have: 1. gopro.pcap - mpegts UDP steam from GoPro Hero 4 Silver 2. gopro_stream_conf - mpegst stream config (from ffprobe) https://www.dropbox.com/s/vjrsiapwq4goyqk/gopro_stream_conf?dl=0 3. gopro_gst_log - filtered debug log for tsdemux and mpegtsbase https://www.dropbox.com/s/4e9r5hiziim4sb5/gopro_gst_log?dl=0 As for Pipeline, it doesn't really matter, I was testing the simpliest: udpsrc port=8554 buffer-size=5000 ! tsdemux name=demux demux.video_1011 ! queue ! decodebin ! autovideosink demux.video_0200 ! fakesink demux.audio_1100 ! fakesink How to simulate GoPro mpegts: 1. Install http://tcpreplay.synfin.net/ 2. Download gopro.pcap 3. Get sMAC of source (machine which is going to stream) and destination dMAC (who's going to receive stream). For test purpose it is going to be the same machine (loopback test): > tcprewrite --enet-smac=e4:ce:8f:3c:63:b2 --enet-dmac=e4:ce:8f:3c:63:b2 --infile=gopro.pcap --outfile=output.pcap --enet-smac our sMAC --enet-dmac our dMAC 4. Generate cache: > tcpprep --auto=bridge --pcap=output.pcap --cachefile=input.cache 5. Replays IPs. Again we need sIP (machine which is going to stream) and dIP who's going to receive stream. For test purpose it is going to be the same machine (loopback test): > tcprewrite --endpoints=192.168.14.137:192.168.14.137 --cachefile=input.cache --infile=output.pcap --outfile=output2.pcap --skipbroadcast formats for IPs: sIP:dIP 6. Now we have output2.pcap which is ready to playback 7. sudo tcpreplay --intf1=en1 output2.pcap en1 - network interface 8. Finaly. You could verify the stream with: ffplay udp://:8554
Failed to attach .pcap Here's a link https://www.dropbox.com/s/fskjgnuxx496ako/gopro.pcap?dl=0
There's already a discussion about this at the end of bug #608148. I've posted a small patch that at least allows the file to be read, at the wrong rate though.
See also streaming information at the streaming section of https://github.com/KonradIT/goprowifihack/blob/master/HERO4.md
Is this a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=608148?
Keeping alive the udp with the python script and using avplay -fflags nobuffer -f:v mpegts -probesize 8192 udp://:8554 works for me.
Created attachment 310500 [details] Playbin log level 6 for Gopro 4 Hero
*** Bug 765800 has been marked as a duplicate of this bug. ***
I was able to get this working with 1.8.3 plus the following SHAs cherry picked from master: abc1c4fc9a8f02ff775bf7f76e19cfe5df59cf37 e3f5ccb3333f3b22c41e59cf78e4343c99187009 48c5cc1b1b5096ccff4a25c98e14117c6e5e4d25 35a1720de17b0cd6a902898336a0946692dc9e63 7a3d1892503370113938b60fee58efe99cde4cde 36e6590335ba0551f0e1882d58cf24429b2ec066 e2b98a7721c7c81fd08813d1c575fc4ad81df38e 51c5ff45de81e96dbace2a872505274d7de0341c They may not all be needed. It would be really nice to get these SHAs into the 1.8 branch.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/282.