Best strategy to deal with src change / bin

Frederic Turmel fturmel at netflix.com
Wed Mar 25 18:58:32 UTC 2020


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 <
mathieu at centricular.com> 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 listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200325/65e32fa8/attachment-0001.htm>


More information about the gstreamer-devel mailing list