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 764347 - baseparse: Fix generated caps for GAP event
baseparse: Fix generated caps for GAP event
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-30 03:24 UTC by Seungha Yang
Modified: 2017-07-19 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
baseparse: Fix generated caps for GAP event (2.52 KB, patch)
2016-03-30 03:25 UTC, Seungha Yang
reviewed Details | Review

Description Seungha Yang 2016-03-30 03:24:43 UTC
Before forwarding GAP event, src caps will be ensured in order to be accepted by downstream elements. In this context, it is possible that non-specified caps fields (by src pad templete) can be needed by downstream elements. 

So, to ensure src caps, this patch will not discard caps fields (from sink pad), but just passing it.
Comment 1 Seungha Yang 2016-03-30 03:25:36 UTC
Created attachment 324984 [details] [review]
baseparse: Fix generated caps for GAP event
Comment 2 Sebastian Dröge (slomo) 2016-04-03 08:34:54 UTC
Comment on attachment 324984 [details] [review]
baseparse: Fix generated caps for GAP event

Can you provide an example sinkpad caps and downstream caps where you see this problem, and which caps are then generated for the GAP event?
Comment 3 Seungha Yang 2016-04-05 00:12:03 UTC
(In reply to Sebastian Dröge (slomo) from comment #2)
> Comment on attachment 324984 [details] [review] [review]
> baseparse: Fix generated caps for GAP event
> 
> Can you provide an example sinkpad caps and downstream caps where you see
> this problem, and which caps are then generated for the GAP event?

Followings are example log for problem happen case.
- NG case
As we can see, some fields in src CAPS are removed compared to sink caps

51 0:00:00.476524417  5827 0x72411490 DEBUG              GST_EVENT gstpad.c:5497:gst_pad_send_event_unchecked:<mpeg4vparse0:sink> have event type gap event: 0x72e19570, time 99:99:99.999999999, seq-num 1515, GstEventGap, timestamp=(guint64)0, duration=(guint64)7000000;
52 0:00:00.476561375  5827 0x72411490 DEBUG              baseparse gstbaseparse.c:1182:gst_base_parse_sink_event_default:<mpeg4vparse0> handling event 40966, gap
53 0:00:00.476577875  5827 0x72411490 DEBUG              baseparse gstbaseparse.c:1420:gst_base_parse_sink_event_default:<mpeg4vparse0> draining current data due to gap event
54 0:00:00.478419083  5827 0x72411490 LOG                baseparse gstbaseparse.c:1104:gst_base_parse_negotiate_default_caps:<mpeg4vparse0> peer caps  video/mpeg, mpegversion=(int)4, width=(int)[ 0, 2147483647 ], height=(int)[ 0, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], parsed=(boolean)true, systemstream=(boolean)false
 55 0:00:00.478489167  5827 0x72411490 LOG                baseparse gstbaseparse.c:1111:gst_base_parse_negotiate_default_caps:<mpeg4vparse0> current caps video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, container=(string)"ISO\     MP4/M4A", format=(string)mp4v, timestamptype=(boolean)true, profile=(string)simple, level=(string)1, codec_data=(buffer)000001b001000001b58913000001000000012000c48d8800f50f04281463000001b24c61766335312e34302e34, width=(int)480, heigh    t=(int)320, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1 for sinkpad
56 0:00:00.478590083  5827 0x72411490 INFO               baseparse gstbaseparse.c:1126:gst_base_parse_negotiate_default_caps:<mpeg4vparse0> Chose default caps video/mpeg, mpegversion=(int)4, width=(int)480, height=(int)320, framerate=(fraction)30/1, parsed=(boolean)true, systemstream=(boolean)false for initial gap

And, with this proposed patch, all fields are reserved
52 0:00:00.548830042  5346 0x72411490 DEBUG              baseparse gstbaseparse.c:1160:gst_base_parse_sink_event_default:<mpeg4vparse0> handling event 40966, gap
53 0:00:00.548846958  5346 0x72411490 DEBUG              baseparse gstbaseparse.c:1398:gst_base_parse_sink_event_default:<mpeg4vparse0> draining current data due to gap event
54 0:00:00.549786750  5346 0x72411490 LOG                baseparse gstbaseparse.c:1085:gst_base_parse_negotiate_default_caps:<mpeg4vparse0> peer caps  video/mpeg, mpegversion=(int)4, width=(int)[ 0, 2147483647 ], height=(int)[ 0, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], parsed=(boolean)true, systemstream=(boolean)false
55 0:00:00.550151375  5346 0x72411490 LOG                baseparse gstbaseparse.c:1091:gst_base_parse_negotiate_default_caps:<mpeg4vparse0> current caps video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, container=(string)"ISO \ MP4/M4A", format=(string)mp4v, timestamptype=(boolean)true, profile=(string)simple, level=(string)1, codec_data=(buffer)000001b001000001b58913000001000000012000c48d8800f50f04281463000001b24c61766335312e34302e34, width=(int)480, hei     ght=(int)320, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1 for sinkpad
56 0:00:00.550328292  5346 0x72411490 INFO               baseparse gstbaseparse.c:1104:gst_base_parse_negotiate_default_caps:<mpeg4vparse0> Chose default caps video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, container=(string)"ISO\ MP4/M4A", format=(string)mp4v, timestamptype=(boolean)true, profile=(string)simple, level=(string)1, codec_data=(buffer)000001b001000001b58913000001000000012000c48d8800f50f04281463000001b24c61766335312e34302e34, width=(int)480, height=(int)320, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, parsed=(boolean)true for initial gap

- From my understanding, other parse elements works like this, that is, some caps fields are modified or fixated based on src caps template and, other caps seems like passed to src caps.
Comment 4 Sebastian Dröge (slomo) 2016-04-05 11:43:30 UTC
The problem here is that codec_data is not taken over? Just having that one additionally would already solve it? Maybe that field needs to be handled separately then.

The reason for only taking the fields from the template caps is that the parser might not pass through any of the other fields in normal operation either. Only codec_data is a bit special here because you can't put it into the template caps.
Comment 5 Edward Hervey 2017-01-31 14:53:15 UTC
Seungha, do you have an update based on Sebastian's last comment ?
Comment 6 Seungha Yang 2017-02-01 12:10:17 UTC
(In reply to Edward Hervey from comment #5)
> Seungha, do you have an update based on Sebastian's last comment ?

Sorry for late update.
Originally, the problem was my custom decoder element refers to specific caps field. In above case log, the decoder checked to container=(string)"ISO \ MP4/M4A". But it does not make sense.
Since this problem does not reproduced in master, please ignore this bug.