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

[Daniel Charles]

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
>
>