Missing a decoder for a newly developed gstreamer media type

[Eslam Ahmed]

I was right!

When introspecting my plugin via `gst-inspect-1.0
--print-plugin-auto-install-info
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstmytype.so` it only produces
`element-mytypedemux` which means gstreamer doesn't recognize it as a
decoder.
To fix that, You need to set the correct classification for your element
via gst_element_class_set_details_simple(). In my case "Generic" was
written when it should have been "Codec/Decoder/Video". Afterwords
introspecting the plugin yields:
```
element-mytypedemux
decoder-video/x-mytype;
```

And the uridecodebin autoplugger works like a charm now.

Best Regards,
Eslam Ahmed


On Sun, Sep 12, 2021 at 1:47 PM Eslam Ahmed <eslam.ahmed at avidbeam.com>
wrote:

> For reference, I managed to get the `uridecodebin` autoplugger to work by
> telling it when to stop decoding and force-expose the caps by setting the
> caps property of the `uridecodebin` as follows:
> `gst-launch-1.0 uridecodebin uri=rtsp://localhost:8553/test
> caps=video/x-mytype ! mytypedemux ! h264parse ! avdec_h264 ! videoconvert !
> autovideosink`
>
> Then I thought about changing the src caps of `mytypedemux` to:
> ```
> Pad Templates:
>   SRC template: 'src'
>     Availability: Always
>     Capabilities:
>       video/x-h264
>           stream-format: byte-stream
>               alignment: au
>
>   SINK template: 'sink'
>     Availability: Always
>     Capabilities:
>       video/x-mytype
> ```
>
> and ran the following pipeline but it still did not work, still showing
> the same error as mentioned earlier:
> `gst-launch-1.0  uridecodebin uri=rtsp://localhost:8553/test
> caps=video/x-h264 ! h264parse ! avdec_h264 ! videoconvert ! autovideosink`
>
> This is the perfect pipeline since I pointed out earlier that
> `video/x-mytype` is nothing more than `video/x-h264` but with some metadata
> prepended to every key-frame.
>
> I have no idea what else to do other than making `mytypedemux` having a
> primary rank.
>
>
> Best Regards,
> Eslam Ahmed
>
>
> On Sun, Sep 12, 2021 at 10:35 AM Eslam Ahmed <eslam.ahmed at avidbeam.com>
> wrote:
>
>> The current caps look like this:
>> ```
>> Pad Templates:
>>   SINK template: 'sink'
>>     Availability: Always
>>     Capabilities:
>>       video/x-mytype
>>
>>   SRC template: 'src'
>>     Availability: Always
>>     Capabilities:
>>       ANY
>> ```
>>
>> I have also changed it to the following but it didn't work (although it
>> might wrong, I just wanna see the decodebin plugs it int)
>>
>> ```
>> Pad Templates:
>>   SINK template: 'sink'
>>     Availability: Always
>>     Capabilities:
>>       video/x-mytype
>>
>>   SRC template: 'src'
>>     Availability: Always
>>     Capabilities:
>>       video/x-raw
>> ```
>>
>> also when introspect other elements such as this one
>> `gst-inspect-1.0 --print-plugin-auto-install-info
>> /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstisomp4.so` you get results as
>> follows:
>> ```
>> decoder-video/quicktime;
>> decoder-video/mj2;
>> decoder-audio/x-m4a;
>> element-mp4mux;
>> encoder-video/quicktime, variant=(string)3gpp;
>> etc.
>> ```
>> but my element produces `element-mytypedemux`
>>
>> I think this is the reason why it's not working.
>> How do I make sure of  my plugin/caps properly is being registered
>> through all plugins/caps tree, and available during automatic caps
>> selection/testing?
>>
>> Best Regards,
>> Eslam Ahmed
>>
>>
>> On Fri, Sep 10, 2021 at 6:06 PM Anton Pryima <zingfrid at gmail.com> wrote:
>>
>>> Hello Eslam.
>>>
>>> I'm sorry, I was not able to quickly find appropriate links, but overall
>>> idea is: you should check, does your plugin/caps properly registered
>>> through all plugins/caps tree, and available during automatic caps
>>> selection/testing.
>>>
>>> Best regards,
>>> Anton.
>>>
>>> On Thu, Sep 9, 2021 at 6:25 PM Eslam Ahmed via gstreamer-devel <
>>> gstreamer-devel at lists.freedesktop.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have recently developed a new media type called `video/x-mytype`
>>>> which is basically an encoded video stream, say H264, that has some encoded
>>>> metadata prepended on it. To that end, I have written 2 elements mytypemux
>>>> and mytypedemux namely.
>>>>
>>>> Consequently, mytypemux takes 'video/x-h264' and produces
>>>> `video/x-mytype` and mytypedemux takes `video/x-mytype` and produces
>>>> whatever was tagged by mytypemux which is in this case none other than the
>>>> 'video/x-h264'.
>>>>
>>>> I wanted to send `video/x-mytype` over the network, so I used
>>>> `rtpgstpay` to payload what was coming out of mytypemux  into
>>>> `GstRTSPMediaFactory`, mounted it and served as an rtsp stream.
>>>>
>>>> In the receiving pipeline, the following happens which works perfectly:
>>>> `gst-launch-1.0 rtspsrc location=rtsp://localhost:8884/test !
>>>> rtpgstdepay ! mytypedemux ! h264parse ! avdec_h264 ! videoconvert !
>>>> autovideosink`
>>>>
>>>> Now, I am trying to make it work via a `uridecodebin` but I keep
>>>> getting the following error from the `decodebin`:
>>>> `Missing decoder: video/x-mytype (video/x-mytype)`
>>>>
>>>> So the pipeline knows about the type of the media type so there's no
>>>> need for typefinding, it just needs a decoder. I had hoped that it would
>>>> auto-plug `mytypedemux` but it didn't.
>>>>
>>>> So, What do I need to do to make the uridecodebin pick my demuxer?
>>>>
>>>> FYI:
>>>>
>>>>    - `gst-inspect-1.0 --print-plugin-auto-install-info
>>>>    /usr/local/lib/gstreamer-1.0/libmytypedemux.so` produces
>>>>    `element-mytypedemux` so it's an element but not a decoder?
>>>>    - mytypedemux has a primary Rank
>>>>
>>>>
>>>> Best Regards,
>>>> Eslam Ahmed
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210926/e2d772e7/attachment.htm>