Do you think there should be a gstomx base_mux or base_demux (2 to 1, or 1 to 2)? At least with GStreamer, I assumed there wasn't a base mux and base demux, because the AV synch was so complex.  But if GST OMX pushes this responsibility down to the IL layer, why can't there be a base_mux and base_demux in GSTOMX? <div class="gmail_quote">On Wed, Dec 3, 2008 at 12:24 PM, Felipe Contreras <<a href="mailto:felipe.contreras@gmail.com">felipe.contreras@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Wed, Dec 3, 2008 at 11:28 AM, Topi Hukkanen <<a href="mailto:topi.hukkanen@gmail.com">topi.hukkanen@gmail.com</a>> wrote: > Hi, > > I took a look at the GST OMX code, and it appears that there's only base > components for src, filter, and sink. > > Are there any plans for extending these bases to muxers and demuxers... or > is this responsibility delegated because "N" implies there can be many > ports, and the very nature of muxers and demuxers make them difficult to > control. </div>I don't know of anybody doing that, so no, no plans. <div class="Ih2E3d"> > At least I don't think there's a base mux for GStreamer... doesn't a writer > of a plugin have to start completely from scratch? </div>Yes. <div class="Ih2E3d"> > I guess in the OMX world, the clock synching could be a big problem.  Has > anyone looked at this yet?  Is there any way I can get involved? </div>Well, if properly done GStreamer and OpenMAX IL would communicate properly and GStreamer would take care of the input synchronization. The problems come with tunnelling and omx renderers, there are proposals on how to solve the synch issues, but no one has implemented them yet. The best way to get involved is to ask questions here, or start coding and ask for feedback :) -- Felipe Contreras </blockquote></div>