h264parse: sets incomplete srccaps first
Submitted by Maroš Ondrášek
Link to original bug (#755885)
Description
Created attachment 312435
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
- 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";
- 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 e8908f5a, 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
Attachment 312435, "h264parse log 1.5.1 and 1.6.0 comparison":
h264parse_151_160.tar.gz