GNOME Bugzilla – Bug 408569
new event type for dtmf tone/rtp packet generation
Last modified: 2007-09-05 22:42:24 UTC
We are currently working on adding DTMF (RFC 2833) support in our framework. As the first step we needed an src element that generates DTMF named events when asked by the application. So I wrote an element by the name RTPDTMFSrc which is ready and working. It has temporarily been put into a gst-plugins-farsight branch until it is moved to gst-plugins-good but before I file a bug to move the plugin there, I think it would be better if we first create a special gst event for representing a DTMF event (GST_EVENT_DTMF) so this element use that instead of a custom upstream event. Please refer to the doc-section comments of the element for details on the parameters of such an event. For online view of the source code of the element: http://projects.collabora.co.uk/~daf/monkey/gst-plugins-farsight-dtmf/ For downloading the complete source: `darcs get http://projects.collabora.co.uk/~zeenix/gst-plugins-farsight-dtmf/`
- custom events are fine, we only create core events when they have a useful meaning to core or are part of the core design. - should this not be a custom_downstream event? it seems the event should be inserted at the beginning of the pipeline, at the source.
(In reply to comment #1) > - custom events are fine, we only create core events when they have a useful > meaning to core or are part of the core design. OK! > - should this not be a custom_downstream event? it seems the event should be > inserted at the beginning of the pipeline, at the source. AFAIK, source elements/pads don't get downstream events. It was a downstream event at first and the event handler on the srcpad didn't even catch it.
you need to install an element event function to get the event, then use that to insert stuff in the pipeline.
(In reply to comment #3) > you need to install an element event function to get the event, then use that > to insert stuff in the pipeline. Hmm? I think i need to clarify a little; This *source* element is the receiver of the event and although usually it shall be application that will send the event but it could also be another (downstream) element in the pipeline. Also i forgot to mention in my previous comments that there will be an RTP muxer element (which i am supposed to write next) that is supposed to mux different RTP streams and this element would typically be used with that muxer element, along with an RTP payloader. So the pipeline would look something like this: rtpdtmfsrc -> rtpmuxer -> networksink ^ | audiosrc -> encodoer -> rtppayloader -----
The event will be also handled by other elements e.g. an encoder (ilbc, g729,...) could handle the event and generate audio dtmf.
regardless of who sends what from where, this can and should be done with a custom event. closing.