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 755885 - h264parse: sets incomplete srccaps first
h264parse: sets incomplete srccaps first
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-30 15:13 UTC by Maroš Ondrášek
Modified: 2018-11-03 13:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
h264parse log 1.5.1 and 1.6.0 comparison (5.14 KB, application/x-targz)
2015-09-30 15:13 UTC, Maroš Ondrášek
Details

Description Maroš Ondrášek 2015-09-30 15:13:50 UTC
Created attachment 312435 [details]
h264parse log 1.5.1 and 1.6.0 comparison

I noticed changed behaviour of h264parse from 1.5.1 to 1.6.0:

testing pipeline:

GST_DEBUG_NO_COLOR=1 GST_DEBUG=basesink:5,h264parse:5 gst-launch-1.0 souphttpsrc location='http://f24hls-i.akamaihd.net/hls/live/221192/F24_FR_LO_HLS/master_900.m3u8' ! hlsdemux ! queue ! tsdemux ! h264parse ! fakesink

1.5.1:
received one caps event with complete caps, before rendering starts

gstbasesink.c:3170:gst_base_sink_event:<fakesink0> received event 0x7f2b54014c00 caps event: 0x7f2b54014c00, time 99:99:99.999999999, seq-num 69, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ width\=\(int\)1024\,\ height\=\(int\)576\,\ framerate\=\(fraction\)25/1\,\ parsed\=\(boolean\)true\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ profile\=\(string\)main\,\ level\=\(string\)3.1";

1.6.0:
recieved two caps events

1. incomplete caps in caps event before rendering starts:

gstbasesink.c:3232:gst_base_sink_event:<fakesink0> received event 0x7f090c014dc0 caps event: 0x7f090c014dc0, time 99:99:99.999999999, seq-num 68, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ parsed\=\(boolean\)true";

2. complete caps in caps event after rendering starts:

gstbasesink.c:3232:gst_base_sink_event:<fakesink0> received event 0x7f090c015010 caps event: 0x7f090c015010, time 99:99:99.999999999, seq-num 86, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ width\=\(int\)1024\,\ height\=\(int\)576\,\ framerate\=\(fraction\)25/1\,\ parsed\=\(boolean\)true\,\ profile\=\(string\)main\,\ level\=\(string\)3.1";


If I revert these two commits, then I have same behaviour as in 1.5.1:
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=e8908f5aeef952566f6bccde743c7735d3f8c6ef
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=48a1f2792316d01c4ea4c6baa27188ffae73c543

In e8908f5aeef952566f6bccde743c7735d3f8c6ef, I can see that we are updating src caps even if sps is not yet available.

Is this correct behaviour to update src caps with incomplete caps, first?

Thank you
Comment 1 Jan Schmidt 2015-10-01 11:54:23 UTC
The problem here is that the AU delimiter appears in MPEG-TS streams before any SPS/PPS, and needs to be forwarded. h264parse has no code to hold back the NALU until caps have been determined (and implementing that right might be problematic) - so it needs to set some caps and push the AU before it knows anything more specific about the stream.

The caps might get updated again later if there are SEI packets that provide more information again.
Comment 2 Maroš Ondrášek 2015-10-02 05:52:07 UTC
Than you for clarification. So this is expected behaviour and not a bug.
Comment 3 Athanasios Oikonomou 2015-12-06 08:52:50 UTC
The problem is that our sink accepts the following caps:

video/x-h264 width: [ 16, 4096 ] height: [ 16, 4096 ]

Now we are receiving caps without width and height, so the only way to make our sink happy again is to add additionaly the following cap:

video/x-h264 parsed: true

Is this the correct way to solve problem? 

Here is our sink for embedded STB's: https://github.com/OpenPLi/gst-plugin-dvbmediasink/tree/gst-1.0
Comment 4 Edward Hervey 2015-12-06 10:03:19 UTC
Would having the profile/level help in your use-case ?

The stream you provided has a AVC descriptor at the mpeg-ts level which contains such information and which we could propagate in the caps.
Comment 5 Athanasios Oikonomou 2015-12-06 13:03:50 UTC
I am testing against latest HEAD and it seems that something was changed lately. 

0:00:41.211736067   511 0x74252030 INFO            dvbvideosink gstdvbvideosink.c:1372:gst_dvbvideosink_set_caps:<dvbvideosink0> caps = video/x-h264, width=(int)16, height=(int)16, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)nal

0:00:41.411449808   511 0x74252030 INFO            dvbvideosink gstdvbvideosink.c:1372:gst_dvbvideosink_set_caps:<dvbvideosink0> caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal, pixel-aspect-ratio=(fraction)1/1, width=(int)640, height=(int)360, framerate=(fraction)0/1, parsed=(boolean)true, profile=(string)constrained-baseline, level=(string)3

Now we are receiving width and height also nal, that does the trick without adding the extra caps!
Comment 6 Athanasios Oikonomou 2015-12-06 13:14:23 UTC
Opps I was wrong, we are still receiving nal with no width and height.

<   797.690812> [eServiceMP3] m_errorInfo.missing_codec = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal, parsed=(boolean)true

Just adding the extra video/x-h264 parsed: true seems enough for the sink.
Comment 7 Sebastian Dröge (slomo) 2015-12-07 11:41:49 UTC
This seems like a separate bug, can you create a new one for it? Also if you sink has width/height fields on the sinkpad template in the caps, you will never get caps without width/height (or you found a bug in the pad code!). Please put a debug log in the new bug.
Comment 8 Athanasios Oikonomou 2015-12-07 20:34:35 UTC
> This seems like a separate bug, can you create a new one for it? Also if you sink has width/height fields on the sinkpad template in the caps, you will never get caps without width/height (or you found a bug in the pad code!). Please put a debug log in the new bug.

New bug created here: https://bugzilla.gnome.org/show_bug.cgi?id=759139
Comment 9 GStreamer system administrator 2018-11-03 13:41:02 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/307.