[gst-devel] reg:non-conventional encoder/decoder plugin development

Stefan Kost ensonic at hora-obscura.de
Mon Oct 6 10:56:52 CEST 2008


hi,

Ambily N schrieb:
> Thanks stefan.
> There is one issue at the sink side in this case.
>  
> For determining late packets and dropping, for a normal sink like SDL
> ideo sink, the dropping can be done at the raw frame level.
>  
> In our case, we dont have any control over the data after the decode
> call and dropping and all need to be done in the compressed video,
> before being fed to the decoder.
> This could be a problem when P and B frames are present in video right?
>  
> Could you please guide to how to handle the late packets in the sink
> in this case?
Yep, that is an issue then and I don't see how it can be handled on the
gstreamer side, as it happens outside of it. You can only try to improve
your decoder it possible, so that it can switch to faster code path's to
catch up. Frame dropping is not the only way to handle QOS. If you can
instruct your decoder to decoder a quarter resolution image, that could
help too.

Stefan

>  
> Regards
> Ambily
>  
>  
>
> On Sun, Oct 5, 2008 at 1:28 AM, Stefan Kost <ensonic at hora-obscura.de
> <mailto:ensonic at hora-obscura.de>> wrote:
>
>     hi,
>
>     Ambily N schrieb:
>     > Hi
>     >
>     > We are trying to develop gstreamer plugins for one hardware H.264
>     > encoder and decoder.
>     > One issue we are facing is, the encoder library doesnt provide an
>     > interface for providing an input buffer for accepting
>     uncompressed video.
>     > Instead it captures from HDMI/Component video/DVI interface,for
>     which
>     > there exists an option for selection.
>     >
>     > Similary, the decoder doesnt provide a decoded output buffer.
>     > Instead it sends output to HDMI/DVI.
>     >
>     > So our understanding is , due to these restrictions,the plugins
>     cant be
>     > developed as normal trasnsform plugins.
>     >
>     > Instead the encoder plugin need to be developed as a source
>     plugin which
>     > generates encoded data and the decoder plugin can be developed
>     as sink
>     > plugin which handles both decoding and rendering.
>     >
>     > Is this understanding correct and is this a right approach? could
>     > experts please comment on this?
>
>     Yes, thats correct. Have a look into src/sink baseclasses to reuse
>     as much as
>     possible form there. Especially the sink is important as it is
>     resposible for
>     A/V sync.
>
>     Stefan
>
>     >
>     > Regards
>     > Ambily
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     -------------------------------------------------------------------------
>     > 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=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > gstreamer-devel mailing list
>     > gstreamer-devel at lists.sourceforge.net
>     <mailto:gstreamer-devel at lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>     -------------------------------------------------------------------------
>     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=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     gstreamer-devel mailing list
>     gstreamer-devel at lists.sourceforge.net
>     <mailto:gstreamer-devel at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>   





More information about the gstreamer-devel mailing list