GNOME Bugzilla – Bug 776672
urisourcebin: Reuse slot if new pad's caps is compatible with previous one
Last modified: 2017-01-11 08:17:15 UTC
Although values of caps field (e.g., rate, resolution, etc) might be slightly different, reuse existing compatible slot, if new caps has same name and fields with previous caps.
Created attachment 342684 [details] [review] urisourcebin: Reuse slot if new pad's caps is compatible with previous one
When adaptivedemux is used, new pad (may be caused by period change) can have different value on caps. Note that caps fields are same. In that case, urisourcebin exposes/removes srcpads. It seems to be unnecessary operation in my opinion.
Can you paste some examples?
(In reply to Jan Schmidt from comment #3) > Can you paste some examples? It tested on my private mpd content. Although I'd like to share the content, it's restricted due to my company's policy, sorry. So, I can share log, dot graph, and just mpd.
Created attachment 342687 [details] log file
Created attachment 342688 [details] 1st period
Created attachment 342689 [details] 2nd period
Created attachment 342690 [details] mpd file
In attached mpd, the 2nd period's audioSamplingRate is different from 1st period's one. So, urisourcebin exposed new srcpad, and new parsebin also configured.
Sorry - I just meant examples of the different caps that it should consider as compatible :) In general, having the same caps name doesn't guarantee compatibility (for example both MPEG-PS system stream and MPEG video elementary stream have 'video/mpeg' caps), but urisourcebin could instead check if the existing pad can accept the new caps.
(In reply to Jan Schmidt from comment #10) Firstly, because link_pending_pad_to_output() is called with "pad-removed" or adaptivedemux's srcpad event probe, please note that what I intended modification is only applicable on adaptivedemux in current generic usecase :) > In general, having the same caps name doesn't guarantee compatibility (for > example both MPEG-PS system stream and MPEG video elementary stream have > 'video/mpeg' caps), but urisourcebin could instead check if the existing pad > can accept the new caps. As an example, followings are compatible based on my intention, since mime-type, #field, and field names are same. "audio/x-m4a, rate=(int)48000" and "audio/x-m4a, rate=(int)11025" But below caps are not compatible, because although both have same mime-type, field configuration is different. Mostly, the first one is for DASH subtitle mp4, and the other is for actual video mp4 stream. "video/quicktime" and "video/quicktime, width=(int)352, height=(int)288, framerate=(fraction)25/1"
Hello Jan Schmidt Please remove this issue. I'd like to solve this on bug #775132 by using GstStream API