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 705030 - h264parse: Only resends SPS/PPS periodically on IDR streams
h264parse: Only resends SPS/PPS periodically on IDR streams
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-28 15:29 UTC by lorddoskias
Modified: 2018-11-03 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GST_DEBUG=h264parse:6 (243.64 KB, application/octet-stream)
2013-07-28 15:29 UTC, lorddoskias
Details

Description lorddoskias 2013-07-28 15:29:16 UTC
Created attachment 250309 [details]
GST_DEBUG=h264parse:6

I have the following pipeline: 

gst-launch-1.0 mpegtsmux name=mux ! tcpserversink host=192.168.1.103 port=5005 filesrc location=./netbeans/mpeg2.ts ! tsdemux name=demux demux. ! queue ! mpegvideoparse ! omxmpeg2videodec ! omxh264enc ! h264parse config-interval=1 ! mux. demux. ! queue ! mpegaudioparse ! mux.


Naturally, I expect that SPS/PPS packets are being sent each second so that when clients are connected they can start rendering video, unfortunately however this is not happening. I've attached a log of h264parse.
Comment 1 lorddoskias 2013-07-28 15:44:18 UTC
Further investigation showed that the reason PPS//SPS not being printed is due to : 

if (h264parse->idr_pos >= 0) check on line 1605 fails, since IDR_POS is -1.
Comment 2 Sebastian Dröge (slomo) 2013-07-29 07:02:19 UTC
Not sure why it only does that in IDR streams. It should probably also do that on other streams, but there only before the next I frame.
Comment 3 minfrin 2015-07-27 09:56:02 UTC
I am seeing the same bug as this one - omxh264enc doesn't generate PPS/SPS packets and so HLS breaks.

Did you ever solve this bug?

Adding h264parse to the stream either causes the stream to hang, or it causes hlssink to break (instead of creating transport stream fragments the first transport stream grows forever without bound).

The following undocumented options to omxh264enc exist but don't seem to have any measurable effect: inline-header=true periodicty-idr=50 interval-intraframes=50
Comment 4 Olivier Crête 2015-07-27 14:19:29 UTC
Afaik, their are no "I-frames" other than IDRs in H.264, only I-slices.
Comment 5 Olivier Crête 2015-07-27 14:20:11 UTC
Anyway, to make valid HLS files, you need each file to start with an IDR, so you need regular IDRs fro your encoder.
Comment 6 minfrin 2015-07-31 18:36:03 UTC
The encoder in use is omxh264enc, does anyone know how to generate regular IDRs from this encoder?

Unfortunately the omxh264enc is insufficiently documented. No examples are provided, and there are no descriptions of the options apart from phrases that give insufficinet information on what to do.

Has anyone successfully got gstreamer to stream to HLS on an RPi?

This bug implies that SPS/PPS should work, but for the life of me I cannot make it work: https://bugzilla.gnome.org/show_bug.cgi?id=720031
Comment 7 minfrin 2015-07-31 20:42:25 UTC
For the record, the patch attached to https://bugzilla.gnome.org/show_bug.cgi?id=736211 fixed omxh264enc sufficiently to successfully stream video to Safari and iOS.
Comment 8 Jan Schmidt 2018-05-04 11:18:38 UTC
I think it makes sense for h264parse to still support sending SPS/PPS for intra-refresh streams with no IDR.

Some suitably simply logic might be to enable output of SPS/PPS before any AU if the time since the last IDR exceeds the insertion interval.
Comment 9 GStreamer system administrator 2018-11-03 13:17:11 UTC
-- 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/104.