[Gstreamer-openmax] GSTOMX and N-1 / 1-N IL components
dcharlesm at gmail.com
Wed Dec 3 06:53:49 PST 2008
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> 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>
>> > 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?
>> > 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
> Grand prize is a trip for two to an Open Source event anywhere in the world
> Gstreamer-openmax mailing list
> Gstreamer-openmax at lists.sourceforge.net
More information about the Gstreamer-openmax