reg:non-conventional encoder/decoder plugin development
Locked
 
|
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?
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=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: reg:non-conventional encoder/decoder plugin development
|
|
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=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
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?
Regards
Ambily
hi, ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: reg:non-conventional encoder/decoder plugin development
|
|
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? 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 <[hidden email] > <mailto:[hidden email]>> 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 > > [hidden email] > <mailto:[hidden email]> > > 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 > [hidden email] > <mailto:[hidden email]> > 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |