[Gstreamer-openmax] GSTOMX and N-1 / 1-N IL components

[Topi Hukkanen]

As far as I know, there's already a demuxer in the Bellagio
implementation....

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"

-Topi



On Wed, Dec 3, 2008 at 4:53 PM, Daniel Charles <dcharlesm at gmail.com> wrote:

> Hello,
>
> 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
> component.
>
> I would like to write a demuxer if I can get this question sorted out.
>
> Thanks,
>
> Daniel.
>
> On Wed, Dec 3, 2008 at 4:59 AM, Topi Hukkanen <topi.hukkanen at gmail.com>
> wrote:
> > 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?
> >
> > 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
> 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.
> >>
> >> 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
> challenge
> > 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
> world
> > 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...
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20081203/df78f4b8/attachment.htm>