[Gstreamer-openmax] GSTOMX and N-1 / 1-N IL components
topi.hukkanen at gmail.com
Wed Dec 3 07:05:10 PST 2008
As far as I know, there's already a demuxer in the Bellagio
It includes a:
"3gp parser component. Parses input file/stream for audio and video output,
which is then fed to audio and video decoder component for decoding"
On Wed, Dec 3, 2008 at 4:53 PM, Daniel Charles <dcharlesm at gmail.com> wrote:
> How would we create a demuxer or muxer with omx in it. I have used
> the gst-openmax plugins with the already existing demuxer (qtdemux,
> ffmpeg, etc) and they seem to work fine.
> If there's an intention to create a omx demuxer, how would it work?
> Should I pass all the information trough the omx's state machine and
> expect to get a callback function with the information processed from
> the file? I would like to understand how this will be a benefit
> comparing this to the existing demuxers. I'm assuming an omx element
> should process the information coming in the input port somehow before
> bringing it to the output port. In a demuxer scenario the information
> will only be extracted from a file but not processed as a regular omx
> I would like to write a demuxer if I can get this question sorted out.
> On Wed, Dec 3, 2008 at 4:59 AM, Topi Hukkanen <topi.hukkanen at gmail.com>
> > Do you think there should be a gstomx base_mux or base_demux (2 to 1, or
> > to 2)?
> > At least with GStreamer, I assumed there wasn't a base mux and base
> > 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?
> > On Wed, Dec 3, 2008 at 12:24 PM, Felipe Contreras
> > <felipe.contreras at gmail.com> wrote:
> >> On Wed, Dec 3, 2008 at 11:28 AM, Topi Hukkanen <topi.hukkanen at gmail.com
> >> wrote:
> >> > Hi,
> >> >
> >> > I took a look at the GST OMX code, and it appears that there's only
> >> > components for src, filter, and sink.
> >> >
> >> > Are there any plans for extending these bases to muxers and
> >> > or
> >> > is this responsibility delegated because "N" implies there can be many
> >> > ports, and the very nature of muxers and demuxers make them difficult
> >> > control.
> >> I don't know of anybody doing that, so no, no plans.
> >> > 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?
> >> Yes.
> >> > 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?
> >> 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
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Gstreamer-openmax mailing list
> > Gstreamer-openmax at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gstreamer-openmax