After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737590 - udpsrc ! tsdemux ! h264parse ! hlssink - keyframes not flagged
udpsrc ! tsdemux ! h264parse ! hlssink - keyframes not flagged
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.1
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-09-29 13:44 UTC by RajuB
Modified: 2018-05-01 07:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description RajuB 2014-09-29 13:44:21 UTC 
Hi,

I am using gstremaer-1.4.1 version. I am experimenting with hlssink plugin. I am receiving mpegts input over udp and passing it to hlssink using below given PIPELINE1.
Here h264parse plugin does not handle 'key unit event' if the incoming stream has byte-stream as the stream format. So I am not able play hls output in case of PIPELINE1. PIPELINE2 works for me because here I am forcing first h264parse to generate avc stream and feeding it back to another h264parse.

PIPELINE1:
gst-launch-1.0 udpsrc port=9999 ! tsdemux ! h264parse ! mpegtsmux ! hlssink location=/var/www/html/test/public/hls/hls2/segment%d.ts playlist-location=/var/www/html/test/public/hls/hls2/chunklist.m3u8

PIPELINE2:
gst-launch-1.0 udpsrc port=9999 ! tsdemux ! h264parse ! video/x-h264,stream-format=avc ! h264parse ! video/x-h264,stream-foramt=byte-stream ! mpegtsmux ! hlssink location=/var/www/html/test/public/hls/hls2/segment%d.ts playlist-location=/var/www/html/test/public/hls/hls2/chunklist.m3u8

Is anybody facing the same problem.?? If there is any patch available for this please let me know. Many thanks in advance.
Comment 1 Tim-Philipp Müller 2014-11-24 17:24:22 UTC 
Does h264parse disable-passthrough=true help?
Comment 2 RajuB 2014-11-26 11:06:32 UTC 
Thank you Tim. I tried with disable-passthrough property. But still I am seeing the same issue.
Comment 3 minfrin 2015-07-27 10:03:30 UTC 
I suspect I might be seeing the same or a similar bug, did you ever get this to work?

Output from omxh264enc doesn't include PSS/SPS for some reason, and I'm trying to work around it with h264parse. If I try PIPELINE2 above it causes hlssink to create a single transport stream without bound, instead of transport stream fragments.

gst-launch-1.0 -v udpsrc port=5004 multicast-group=239.255.1.30 caps="application/x-rtp,media=(string)video,clock-rate=(int)90000" ! rtpbin ! rtpmp2tdepay ! tsdemux name=demux ! mpegvideoparse ! omxmpeg2videodec ! queue ! videoconvert ! deinterlace ! videoscale ! video/x-raw,width=960,height=540 ! omxh264enc target-bitrate=5000000 control-rate=variable inline-header=true periodicty-idr=50 interval-intraframes=50 ! queue ! h264parse config-interval=1 ! video/x-h264,stream-format=avc ! h264parse ! video/x-h264,stream-format=byte-stream ! queue ! mpegtsmux name=mux ! hlssink location=/var/www/stream/segment2%05d.ts playlist-location=/var/www/stream/output2.m3u8 playlist-root=http://192.168.225.2/stream/ target-duration=2  demux. ! mpegaudioparse ! mpg123audiodec ! audioconvert ! audioresample ! voaacenc ! queue ! mux.
Comment 4 Chetan 2016-01-05 10:55:48 UTC 
hi RajuB!,

this could be useful to me. can you also please provide the gst pipeline that sends out the udp messages on server side??

thanks!
Comment 5 Edward Hervey 2018-05-01 07:03:26 UTC 
No real answer in 4 years. Closing. Please re-open if you can reproduce the issue with current stable GStreamer.