GNOME Bugzilla – Bug 755885
h264parse: sets incomplete srccaps first
Last modified: 2018-11-03 13:41:02 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
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.
Than you for clarification. So this is expected behaviour and not a bug.
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
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.
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!
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.
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.
> 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
-- 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.