[gst-devel] Advice on plugin/pipeline design

[Brijesh Singh]

>One of the things that i noticed is threads being spawned from within the decoder
>plugins, which does not fit well with me.

Well threads are used for parallelizing  ARM and DSP execution to meet
the real-time performance on some platforms. But you can remove thread
and call decoder directly from the chain() functions. Or use queue
element to put the decoder element in different threads.

> I also noticed quite a lot of bugs in the code, which kept me from using it or hacking on it.
Can you please submit BUGs on gstreamer.ti.com ?


Thanks
Brijesh

On Sun, Nov 22, 2009 at 11:07 AM, Sameer Naik
<sameer.subscriptions at damagehead.com> wrote:
> Hello,
> I had taken a look at the gstreamer-ti plugins some time back. One of the
> things that i noticed is threads being spawned from within the decoder
> plugins, which does not fit well with me. I also noticed quite a lot of bugs
> in the code, which kept me from using it or hacking on it. Besides i already
> have most of the functionality implemented and just need to tweak my
> code/design a bit, hence the mail.
>
> Thanks and Regards
> ~Sameer
>
> On Sun, Nov 22, 2009 at 9:27 PM, Brijesh Singh <brijesh.ksingh at gmail.com>
> wrote:
>>
>> Hello,
>>
>> Have you looked at gstreamer.ti.com ?  gst_ti has all the elements you
>> need. It support wide varity of TI platforms. (DM6446, DM355, DM365,
>> DM357, DM6467, OMAP3530 and more...).
>>
>> To understand design detail you can watch 25-min of video presentation.
>>
>>
>> https://gstreamer.ti.com/gf/project/gstreamer_ti/wiki/?pagename=OverviewPresentation
>>
>> We do not have pad-allocation method yet (may be you can contribute on
>> project). We use hw accelerated framecopy to copy the data from video
>> decoder -> sink element. Depending on the platform, this hw
>> accelerator may be resizer/dma/vdce/sdma etc...
>>
>>
>> Thanks
>> Brijesh
>>
>> On Sun, Nov 22, 2009 at 4:18 AM, Sameer Naik
>> <sameer.subscriptions at damagehead.com> wrote:
>> > Hi,
>> > I am developing a multimedia application for an embedded system based on
>> > TI's DM6446 platform. The decoding of the audio and video frames will be
>> > done using the HW decoders. The platform also includes a hardware
>> > resizer,
>> > that allows resizing of the video frames in hardware, thereby making the
>> > resizing operations pretty quick.
>> >
>> > I need some advice on the architecture that i should base by application
>> > on.
>> > Following are the architectures that i have come up with
>> >
>> > 1.
>> > - audio decoder plugins
>> > - video decoder plugins
>> > - resizer plugin
>> > - frame buffer output plugin
>> > Here i can build a seperate plugin to do the resizing of video frames.
>> > This
>> > would conform more with gstreamer's idea that "every element does one
>> > thing", providing better reusability. To reduce to number of memcpy's, i
>> > could equip the frame buffer plugin with pad allocation capabilities and
>> > accordingly add pad_alloc calls in the resizer plugin. The only this is,
>> > in
>> > this case the frames will always be resized, regardless of whether the
>> > frame
>> > is going to be displayed or dropped. I am not really sure whether this
>> > is
>> > that big of a problem considering that the number of frames that could
>> > be
>> > dropped is very less.
>> >
>> > 2.
>> > - audio decoder plugins
>> > - video decoder plugins
>> > - frame buffer plugin with resizing capabilities using the hw resizer.
>> > Here i can build the frame buffer plugin with the built in capability to
>> > resize video frames. In this case i could resize the frame only if it is
>> > going to be displayed (i.e. just before it would be displayed on
>> > screen).
>> > Now in this case i loose the reusability advantage, which i can live
>> > with if
>> > i am able to achieve smooth video playback with av sync. In this case, I
>> > am
>> > not sure whether the last minute resizing of the frame would introduce a
>> > lot
>> > of latency while displaying the frame. Given that it is a hardware
>> > resizer i
>> > am assuming it would be quick.
>> >
>> > P.S. I would be employing the pad allocation method in other parts of
>> > the
>> > pipeline as well, so as to reduce the number of memcpy's going on in the
>> > pipeline.
>> >
>> > Please Advice.
>> >
>> > Regards
>> > ~Sameer
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> > 30-Day
>> > trial. Simplify your report design, integration and deployment - and
>> > focus
>> > on
>> > what you do best, core application coding. Discover what's new with
>> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>> >
>> >
>>
>>
>>
>> --
>> Confusion is always the most honest response.
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>



-- 
Confusion is always the most honest response.