GNOME Bugzilla – Bug 622412
[rtpmp4vpay] remove send-config parameter; obsoleted by config-interval
Last modified: 2011-06-15 22:43:36 UTC
With adding config-interval; the send-config parameter is the same as config-interval <=0 removing the config-interval parameter allows merging the apparent behaviour between rtph264pay and rtpmp4vpay
We can't really *remove* the send-config property, but we could mark it as obsolete in the description and/or add a gtk-doc chunk that says so.
Would it be fine to alias the send-config=True to config-interval=1 or something? The net effect would be better; while not requiring to set send-config AND config-interval to have the functionality. for rtph24pay; we need config-interval to have the same effect on rtpmp4vpay; we need config-interval *and* send-config; since config-interval does not have any effect without send-config being set. This way, it would not break current code; while it would bring the h264 and mpeg4video code one step closer.
> Would it be fine to alias the send-config=True to config-interval=1 or > something? > ... > The net effect would be better; while not requiring to set send-config AND > config-interval to have the functionality. > ... > to have the same effect on rtpmp4vpay; we need config-interval *and* > send-config; since config-interval does not have any effect without send-config > being set. I think it'd be fine to change the behaviour of these properties so that the config is re-sent if only one of the two is set. I thought you wanted to remove the property entirely.
Euhm, that's the patch; but I'll create a new one that aliases send-config=True to config-interval=1 or so.
Patch? Did you mean to attach one? Is 1 second a 'sane' default interval?
[nitpick] send-config=TRUE would send the config only once, whereas config-interval=1 would send it regularly. That may (or may not) make more sense, but it is a tiny API break ... [which perhaps we need not particularly care about].
Ah, Mark picked up the difference between the two. I though that would be adding to much information. Well, we can do both. If the behaviour of send-config=True is kept; but config-interval=X does no longer depend on the value of send-config; rtpmp4vpay would mimic the behaviour of rtph264pay while keeping the old "send once" behaviour when selecting send-config. Yeah, I noticed my patch was gone yesterday evening. Since I was off to bed; I didn't see if so deleted it. 1s being a sane interval? Guess that depends on your point of view. Since remuxing the config doesn't cost much and AFAIK only has benefits; I would think sending it fast so decoders can quickly pick in on the stream would be good.
Created attachment 164792 [details] [review] replace send-config internal behaviour by config-interval bringing mpeg4video payloader in line with h264 payloader 1/ config-interval >0 does not depend on setting send-config to work 2/ setting send-config results in config-interval=60 when config-interval was not set previously 3/ ->send_config is not used in the code, but config_interval is.
commit ff1c05d8768ff4041890ccc1df2350a5611a97b4 Author: Marc Leeman <marc.leeman@gmail.com> Date: Thu May 26 12:22:52 2011 +0200 rtpmp4vpay: Deprecated send-config property and replace by config-interval Fixes bug #622412.