is it possible to add another src pad in GstBaseSrc class?

[caoxi]

I'm trying to rewrite the GstBaseSrc Class to add another src pad for derived class(for now GstBaseSrc only allow one src pad), any good idea about how to do this, guys?

[Dimitrios Katsaros]

A bit more information on what you aim to do with such a base class would help in understanding why you need multiple src pads. Adding additional pads is possible, You can see how the base pad is created in gst_base_src_init.

However, in GStreamer sources are supposed to represent a single data source, thus providing a single output. if that data source contains multiple data types you usually demux it if you want to get the separate data streams. Can you give an example of a source that produces multiple data types that can not be reprisented by this model?

Dimitrios

On Thu, Apr 6, 2017 at 7:58 AM, caoxi <[hidden email]> wrote:

I'm trying to rewrite the GstBaseSrc Class to add another src pad for derived
class(for now GstBaseSrc only allow one src pad), any good idea about how to
do this, guys?



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-it-possible-to-add-another-src-pad-in-GstBaseSrc-class-tp4682539.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Andrew Grace]

Regarding an example of a multiple source element, the Point Grey (now Flir) Ladybug cameras (360 cameras) produce 6 output images every frame.

Sent from my iPhone

On Apr 6, 2017, at 3:14 AM, Dimitrios Katsaros <[hidden email]> wrote:

A bit more information on what you aim to do with such a base class would help in understanding why you need multiple src pads. Adding additional pads is possible, You can see how the base pad is created in gst_base_src_init.

However, in GStreamer sources are supposed to represent a single data source, thus providing a single output. if that data source contains multiple data types you usually demux it if you want to get the separate data streams. Can you give an example of a source that produces multiple data types that can not be reprisented by this model?

Dimitrios

On Thu, Apr 6, 2017 at 7:58 AM, caoxi <[hidden email]> wrote:

I'm trying to rewrite the GstBaseSrc Class to add another src pad for derived
class(for now GstBaseSrc only allow one src pad), any good idea about how to
do this, guys?



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-it-possible-to-add-another-src-pad-in-GstBaseSrc-class-tp4682539.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Dimitrios Katsaros]

The problem with that is the interface being provided by the device. If it is a single file descriptor with its own interface for retrieving frames from all 6 cameras then I can understand needing a single source producing multiple pads. If the device provides 6 fds for every camera then you are better off making a bin that internally creates 6 sources for every fd and then make the bin provide 6 source pads. I am not aware of the design behind the Ladybug cameras though.

On Thu, Apr 6, 2017 at 9:26 AM, Andrew Grace <[hidden email]> wrote:

Regarding an example of a multiple source element, the Point Grey (now Flir) Ladybug cameras (360 cameras) produce 6 output images every frame.

Sent from my iPhone

On Apr 6, 2017, at 3:14 AM, Dimitrios Katsaros <[hidden email]> wrote:

A bit more information on what you aim to do with such a base class would help in understanding why you need multiple src pads. Adding additional pads is possible, You can see how the base pad is created in gst_base_src_init.

However, in GStreamer sources are supposed to represent a single data source, thus providing a single output. if that data source contains multiple data types you usually demux it if you want to get the separate data streams. Can you give an example of a source that produces multiple data types that can not be reprisented by this model?

Dimitrios

On Thu, Apr 6, 2017 at 7:58 AM, caoxi <[hidden email]> wrote:

I'm trying to rewrite the GstBaseSrc Class to add another src pad for derived
class(for now GstBaseSrc only allow one src pad), any good idea about how to
do this, guys?



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-it-possible-to-add-another-src-pad-in-GstBaseSrc-class-tp4682539.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Juergen Sachs]

I am also not aware of the design behind the Ladybug cameras. But if we would have have a single fd produceing images from all six sources, from my point of view the best approach would be:
- create a source element with one single source-pad producing a "multiplex image stream"
- and create a demux element for this multiplex to split into multiple single image streams
/Juergen

[Nicolas Dufresne-5]

Le mercredi 05 avril 2017 à 22:58 -0700, caoxi a écrit :
> I'm trying to rewrite the GstBaseSrc Class to add another src pad for derived
> class(for now GstBaseSrc only allow one src pad), any good idea about how to
> do this, guys?

It is not possible without modifying GstBaseSrc, as you may already
have notice. Some of the aspect:

- You need advance thread management, 1 thread per pad
- You need to modify the stream IDs
- You need to add thread safe iteration of pads
  (For event dispatching, both out-of-band and serialized)
- You need to subclass GstPad, and store all negotiation stuff in there


So to resume, you need to do a major rewrite, as pretty much everything
would move from GstBaseSrc to a GstPad subclass (including virtual
functions). Another approach to this would be to have a GstBin
subclass, that manages internal GstBaseSrc instances. The BaseSrc
instances would use an API on the parent for the shared stuff.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 06 avril 2017 à 09:35 +0200, Dimitrios Katsaros a écrit :
> The problem with that is the interface being provided by the device.
> If it is a single file descriptor with its own interface for
> retrieving frames from all 6 cameras then I can understand needing a
> single source producing multiple pads. If the device provides 6 fds
> for every camera then you are better off making a bin that internally
> creates 6 sources for every fd and then make the bin provide 6 source
> pads. I am not aware of the design behind the Ladybug cameras though.

If we look at uvch264src (c920), it reads a single stream from the
camera and produces 2. It's implementing a bin, with a slave v4l2src
and a demuxer afterward.

My recent abuse of GstBaseSrc, and the reason I concluded that a GstBin
is just a better idea was about wrapping Android Camera HAL 3. We
hacked GstBaseSrc to make it possible, but the end result was a
nightmare.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[caoxi]

I think all I need to do is to modify GstBaseSrc and GstPushSrc class, that these two classes manage the thread and pad control thru Gstreamer APIs(such as gst_pad_create_stream_id), I don't need to worry about creating a new thread, those API will do that for me

[caoxi]

Generally, my purpose is to make my source plugin to have the same function as Tee element, that the source element can have several active pads(whether always pad or request pad), and I've already made a design, all I need is to rewrite GstBaseSrc and GstPushSrc, I'll try if my design works~

[Dimitrios Katsaros]

Again, I would suggest against that. If you want to make a "tee" like source I would go for a bin that contains the source and tee elements and handling request pads on the bin level. It is simple enough to just create a ghost pad and link it to a pad requested from the tee. keep in mind that if you modify the base you will then have to implement the element logic on top of the base you built. And more importantly, why reinvent the wheel when you already have elements that have been built to handle this case, have been rigorously tested and you can get support for when something doesn't work.

Dimitrios

On Fri, Apr 7, 2017 at 6:11 AM, caoxi <[hidden email]> wrote:

Generally, my purpose is to make my source plugin to have the same function
as Tee element, that the source element can have several active pads(whether
always pad or request pad), and I've already made a design, all I need is to
rewrite GstBaseSrc and GstPushSrc, I'll try if my design works~



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-it-possible-to-add-another-src-pad-in-GstBaseSrc-class-tp4682539p4682565.html

Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[caoxi]

But I found out that "tee" element has one defect: all the streams have the same configuration. e.g., tee element can't output stream 0 for NV12/1920x1080 and stream 1 for YUYV/1280x720. and I also tried "videoscale" element, but it will occupies CPU resource to do stream cropping.
For your suggestion that handling on the bin level, I thought about that, but that means I have to use multiple source plugins, which is not what I expect

[Dimitrios Katsaros]

Hmm, I do see why you would want reduce resource consumption in elements like videoscale, but at the same time I do not see how you will get away with not performing the scaling in software with a singular source. Unless you are receiving from different sources you will have to perform the conversions somehow. As for the multiple sources, why is that a problem for you? I think that a more complete description of what you are trying to make would clarify your reservations in using multiple sources or a bin with a tee to solve your problem.

On Mon, Apr 10, 2017 at 12:15 PM, caoxi <[hidden email]> wrote:

But I found out that "tee" element has one defect: all the streams have the
same configuration. e.g., tee element can't output stream 0 for
NV12/1920x1080 and stream 1 for YUYV/1280x720. and I also tried "videoscale"
element, but it will occupies CPU resource to do stream cropping.
For your suggestion that handling on the bin level, I thought about that,
but that means I have to use multiple source plugins, which is not what I
expect



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-it-possible-to-add-another-src-pad-in-GstBaseSrc-class-tp4682539p4682595.html

Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[caoxi]

Thanks, I agree your idea. Actually, this topic is proposed based on one of my project, which requires the source element to output 2 different streams(under certain situations) to do video capture, and these 2 streams must queue buffers at the same time through the same interface. As for your suggestion, I would like to create 2 bufferpools as a solution, it has the same effect with bin or tee.
I've completed my design and I'm writing code to verify that, and the result will come up these few days~