From: Edward H. <bi...@gm...> - 2006-02-28 13:46:22
|
SGkgYWxsLAoKR3N0RWxlbWVudEZhY3RvcnkgaGFzIHRoaXMsIHNlYW1pbmdseSwgdmVyeSB1c2Vm dWwgcHJvcGVydHkgY2FsbGVkCmtsYXNzLiBUaGUgb25seSBkb2N1bWVudGF0aW9uIGFib3V0IGl0 IGhvd2V2ZXIgaXMgbG9zdCBzb21ld2hlcmUgaW4KdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBHc3RF bGVtZW50RGV0YWlscyBzdHJ1Y3R1cmU6CiJnY2hhciAqa2xhc3M7IAkgdHlwZSBvZiBlbGVtZW50 LCBhcyBoaWVyYXJjaHkiCgpUaGUgcHJvYmxlbSBpcyB0d28tZm9sZDoKMS8gVGhlcmUgaXNuJ3Qg YW55IGVzdGFibGlzaGVkIHN0YW5kYXJkIG9mIHdoaWNoIGtsYXNzIHlvdSBzaG91bGQgcHV0CmEg RWxlbWVudEZhY3RvcnkgaW4gYW5kIHdoYXQgdGhlIG1lYW5pbmcgb2YgZXZlcnkgY2xhc3MgaGll cmFyY2h5Cm1lYW5zLiBWZXJ5IHByb2JsZW1hdGljIGZvciBhbiBhcHBsaWNhdGlvbiB0byBkbyBh bnkga2luZCBvZiBmaWx0ZXJpbmcKb24gdHlwZXMgb2YgZWxlbWVudHMgaXQgd291bGQgbmVlZCAo bGlrZSBsaXN0aW5nIHZpZGVvIGVmZmVjdHMgKGFuZApub3QgdHJhbnNmb3JtYXRpb25zIGxpa2Ug c2NhbGluZywgY29sb3JzcGFjZSBjb252ZXJzaW9uLC4uLikpLgoKMi8gVGhlcmUgYXJlIGluY29u c2lzdGVuY2llcyBpbiB0aGUgYWxyZWFkeSBhdmFpbGFibGUga2xhc3NlczoKIF8gQ29kZWMvRGVw YXlyIHZzIENvZGVjL1BheWxvYWRlciAuIFNob3VsZCB0aGUgZmlyc3Qgb25lIGJlIENvZGVjL0Rl cGF5bG9hZGVyID8KIF8gU3JjL0F1ZGlvIHZzIFNvdXJjZS9BdWRpbyAoYWxzYXNyYyBpcyBpbiB0 aGUgZmlyc3Qgb25lLCBhbGwgdGhlCm90aGVyIGF1ZGlvIHNvdXJjZXMgaW4gdGhlIHNlY29uZCBv bmUpCiBfIEZpbHRlci9FZmZlY3QvVmlkZW8gdnMgRmlsdGVyL1ZpZGVvIHZzIEZpbHRlci9FZGl0 b3IvVmlkZW8gdnMKRmlsdGVyL0NvbnZlcnRlci9WaWRlbyAoV0hJQ0ggb25lIGRvZXMgd2hhdCA/ Pz8pCgpUaGUgcHJvcG9zaXRpb24gaXMgdG8gZmlyc3QgZG9jdW1lbnQgcHJvcGVybHkgZXZlcnkg Y2xhc3MgaGllcmFyY2h5CnNvbWV3aGVyZSAoV2hhdCBzaG91bGQgZ28gaW4gZXZlcnkgKHN1Yi0p bGV2ZWwsIHdoYXQncyB0aGUgcG9saWN5IG9uCmNyZWF0aW5nIG5ldyAoc3ViLSlsZXZlbHMsIC4u Li4pLiBUaGlzIGlzIHVzZWZ1bCBib3RoIGZvciBhcHBsaWNhdGlvbgphbmQgcGx1Z2luIGRldmVs b3BlcnMsIHNvIEkgZ3Vlc3MgaXQgc2hvdWxkIGdvIGluIHRoZSBBRE0uCgogIEFueSBjb21tZW50 cyA/CgogICAgRWR3YXJkCgotLQpFZHdhcmQgSGVydmV5Ckp1bmlvciBkZXZlbG9wZXIgLyBGbHVl bmRvIFMuTC4KaHR0cDovL3d3dy5waXRpdmkub3JnLwo= |
From: David S. <ds...@sc...> - 2006-02-28 14:25:32
|
On Tue, Feb 28, 2006 at 01:46:13PM +0000, Edward Hervey wrote: > GstElementFactory has this, seamingly, very useful property called > klass. The only documentation about it however is lost somewhere in > the description of the GstElementDetails structure: > "gchar *klass; type of element, as hierarchy" > > The problem is two-fold: > 1/ There isn't any established standard of which klass you should put > a ElementFactory in and what the meaning of every class hierarchy > means. > The proposition is to first document properly every class hierarchy > somewhere (What should go in every (sub-)level, what's the policy on > creating new (sub-)levels, ....). This is useful both for application > and plugin developers, so I guess it should go in the ADM. One of the reasons nothing has ever usefully been done with this field is because discussions get sidetracked into how a heirarchy is not appropriate for this field and that a list of categories would be better. I sidetrack the discussion now. Hopefully it will get somewhere this time. dave... -- David Schleef Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux |
From: Andy W. <wi...@po...> - 2006-02-28 14:32:49
|
Hi Edward, On Tue, 2006-02-28 at 13:46 +0000, Edward Hervey wrote: > GstElementFactory has this, seamingly, very useful property called > klass. The only documentation about it however is lost somewhere in > the description of the GstElementDetails structure: > "gchar *klass; type of element, as hierarchy" Ooh, this is a nice one. http://thread.gmane.org/gmane.comp.video.gstreamer.devel/3609 http://thread.gmane.org/gmane.comp.video.gstreamer.devel/4900 http://thread.gmane.org/gmane.comp.video.gstreamer.devel/5521 > The proposition is to first document properly every class hierarchy > somewhere (What should go in every (sub-)level, what's the policy on > creating new (sub-)levels, ....). This is useful both for application > and plugin developers, so I guess it should go in the ADM. There should not be levels. We should just interpret the class as a slash-separated keyword list. (Slash-separated for backwards compatibility.) Go for it dude, -- Andy Wingo http://wingolog.org/ |
From: Wim T. <wi...@fl...> - 2006-02-28 15:58:33
|
On Tue, 2006-02-28 at 15:32 +0100, Andy Wingo wrote: > Hi Edward, > > On Tue, 2006-02-28 at 13:46 +0000, Edward Hervey wrote: > > GstElementFactory has this, seamingly, very useful property called > > klass. The only documentation about it however is lost somewhere in > > the description of the GstElementDetails structure: > > "gchar *klass; type of element, as hierarchy" > > Ooh, this is a nice one. > > http://thread.gmane.org/gmane.comp.video.gstreamer.devel/3609 > http://thread.gmane.org/gmane.comp.video.gstreamer.devel/4900 > http://thread.gmane.org/gmane.comp.video.gstreamer.devel/5521 > > > The proposition is to first document properly every class hierarchy > > somewhere (What should go in every (sub-)level, what's the policy on > > creating new (sub-)levels, ....). This is useful both for application > > and plugin developers, so I guess it should go in the ADM. > > There should not be levels. We should just interpret the class as a > slash-separated keyword list. (Slash-separated for backwards > compatibility.) Without looking at previous discussions I just checked in docs/design/draft-klass.txt Wim > > Go for it dude, -- Wim Taymans <wi...@fl...> |
From: Stefan K. <en...@ho...> - 2006-02-28 16:38:59
|
Hi all, Wim Taymans wrote: > > > Without looking at previous discussions I just checked in > docs/design/draft-klass.txt > > Wim > > 2) keyword categories > > - functional > * Debug : tee, identity, fakesrc, navseek, ... I see elements like 'tee' and 'adder' as sort of link-adapter (connector) > 4) examples: > adder : Effect/Muxer/Audio adder is not muxing, it is mixing, muxing interleaves. thus the old aggregator would be a muxer. > level : Filter/Analyzer/Audio level does not really transform data, it only analyzes. Anyway, looks good to me. Along with the change it would be useful to get the respective filter into core. Stefan |
From: Edward H. <bi...@gm...> - 2006-02-28 17:23:07
|
Hi, On 2/28/06, Stefan Kost <en...@ho...> wrote: > Hi all, > > Wim Taymans wrote: > > > > > > Without looking at previous discussions I just checked in > > docs/design/draft-klass.txt > > > > Wim > > > > 2) keyword categories > > > > - functional > > * Debug : tee, identity, fakesrc, navseek, ... > I see elements like 'tee' and 'adder' as sort of link-adapter (connector) > > > 4) examples: > > adder : Effect/Muxer/Audio > adder is not muxing, it is mixing, muxing interleaves. thus the old aggre= gator > would be a muxer. Indeed, wim is fixing it right now. > > > level : Filter/Analyzer/Audio > level does not really transform data, it only analyzes. > > Anyway, looks good to me. Along with the change it would be useful to get= the > respective filter into core. I'm creating a file with all (known) ElementFactory, their current klass and the proposed new klass, I will commit it to the list once done. Edward > > Stefan > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > -- Edward Hervey Junior developer / Fluendo S.L. http://www.pitivi.org/ |
From: Wim T. <wi...@fl...> - 2006-02-28 17:26:16
|
On Tue, 2006-02-28 at 17:38 +0100, Stefan Kost wrote: > Hi all, > > Wim Taymans wrote: > > > > > > Without looking at previous discussions I just checked in > > docs/design/draft-klass.txt > > > > Wim > > > > 2) keyword categories > > > > - functional > > * Debug : tee, identity, fakesrc, navseek, ... > I see elements like 'tee' and 'adder' as sort of link-adapter (connector) Adder is clearly a mixer, which is a superclass of a connector. Can't really categorize tee... Updating doc with Connector for tee, it does not really matter, I can't think of a use case where an application wants to filter the registry for elements with tee-like behaviour. Connector is a fine name though for this type of element. > > > 4) examples: > > adder : Effect/Muxer/Audio > adder is not muxing, it is mixing, muxing interleaves. thus the old aggregator > would be a muxer. Mixer added as functional keyword, muxing is reversable with a demuxer, mixing is not. > > > level : Filter/Analyzer/Audio > level does not really transform data, it only analyzes. > That's why it is not an effect. Intended behaviour of level is to analyse the data, since level is not even able to handle different caps on src and sinkpads, the Filter keyword can be removed. Updated the doc in CVS with suggestions. Wim > Anyway, looks good to me. Along with the change it would be useful to get the > respective filter into core. > > Stefan > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel -- Wim Taymans <wi...@fl...> |