Best strategy to deal with src change / bin

[Frederic Turmel]

Hi, I have a source audio element that can send PCM or iec60958/61937. The src element update its output caps so the downstream will know.

An example case:

When src is PCM:     PCM -> sink

When src is iec60958/:    iec60958 -> parser -> audio decoder -> PCM

Ideally would like this to be totally transparent to my top level application that creates the pipeline. In other words I don't want my top level app updating the pipeline.

Note the IEC60958/61937 I need to build also.

What would be the best options?

1-If I create the parser with proper pads/caps can decodebin leverage it automatically?

2-Should I create a specific bin for my needs?

Any suggestions?

Thanks

FredT

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

[Mathieu Duponchelle]

Hey Frederic,

Unless I'm missing something, you should be able to use decodebin as such:

your_source_element ! decodebin ! sink

When your source element pushes "audio/x-raw" caps, decodebin will simply
pass through the buffers that follow. When it pushes non-raw caps, decodebin
will take care of selecting the appropriate parser / decoder.

Does that answer your question?

On 3/25/20 6:19 PM, Frederic Turmel wrote:

Hi, I have a source audio element that can send PCM or iec60958/61937. The src element update its output caps so the downstream will know.

An example case:

When src is PCM:     PCM -> sink

When src is iec60958/:    iec60958 -> parser -> audio decoder -> PCM

Ideally would like this to be totally transparent to my top level application that creates the pipeline. In other words I don't want my top level app updating the pipeline.

Note the IEC60958/61937 I need to build also.

What would be the best options?

1-If I create the parser with proper pads/caps can decodebin leverage it automatically?

2-Should I create a specific bin for my needs?

Any suggestions?

Thanks

FredT

_______________________________________________
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

[Frederic Turmel]

Sounds good. Is there a way to use a preferred decoder when multiples are available?

Thanks
FredT

On Wed, Mar 25, 2020 at 10:40 AM Mathieu Duponchelle <[hidden email]> wrote:

Hey Frederic,

Unless I'm missing something, you should be able to use decodebin as such:

your_source_element ! decodebin ! sink

When your source element pushes "audio/x-raw" caps, decodebin will simply
pass through the buffers that follow. When it pushes non-raw caps, decodebin
will take care of selecting the appropriate parser / decoder.

Does that answer your question?

On 3/25/20 6:19 PM, Frederic Turmel wrote:

Hi, I have a source audio element that can send PCM or iec60958/61937. The src element update its output caps so the downstream will know.

An example case:

When src is PCM:     PCM -> sink

When src is iec60958/:    iec60958 -> parser -> audio decoder -> PCM

Ideally would like this to be totally transparent to my top level application that creates the pipeline. In other words I don't want my top level app updating the pipeline.

Note the IEC60958/61937 I need to build also.

What would be the best options?

1-If I create the parser with proper pads/caps can decodebin leverage it automatically?

2-Should I create a specific bin for my needs?

Any suggestions?

Thanks

FredT

_______________________________________________
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

[Mathieu Duponchelle]

Yes, a few actually. One is to connect to the autoplug-select signal from the application:
https://gstreamer.freedesktop.org/documentation/playback/decodebin.html?gi-language=c#decodebin::autoplug-select

Another approach is to set the ranks of the potential factories ahead of time,
using gst_plugin_feature_set_rank:

https://gstreamer.freedesktop.org/documentation/gstreamer/gstpluginfeature.html?gi-language=c#gst_plugin_feature_set_rank

On 3/25/20 7:58 PM, Frederic Turmel wrote:

Sounds good. Is there a way to use a preferred decoder when multiples are available?

Thanks
FredT

On Wed, Mar 25, 2020 at 10:40 AM Mathieu Duponchelle <[hidden email]> wrote:

Hey Frederic,

Unless I'm missing something, you should be able to use decodebin as such:

your_source_element ! decodebin ! sink

When your source element pushes "audio/x-raw" caps, decodebin will simply
pass through the buffers that follow. When it pushes non-raw caps, decodebin
will take care of selecting the appropriate parser / decoder.

Does that answer your question?

On 3/25/20 6:19 PM, Frederic Turmel wrote:

Hi, I have a source audio element that can send PCM or iec60958/61937. The src element update its output caps so the downstream will know.

An example case:

When src is PCM:     PCM -> sink

When src is iec60958/:    iec60958 -> parser -> audio decoder -> PCM

Ideally would like this to be totally transparent to my top level application that creates the pipeline. In other words I don't want my top level app updating the pipeline.

Note the IEC60958/61937 I need to build also.

What would be the best options?

1-If I create the parser with proper pads/caps can decodebin leverage it automatically?

2-Should I create a specific bin for my needs?

Any suggestions?

Thanks

FredT

_______________________________________________
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