Does GstMeta always flow in all branches of pipeline?

Application Development
1

Hello,

I have a pipeline with two branches, I’d like to tag GstBuffer frames with GstMeta and have GstMeta flow in both branches of the pipeline. I am able to get GstMeta in one of the branches (fakesink2) but not in the second branch (fakesink1). The branch that seems to be missing GstMeta is the one that contains a video encoder. I add the GstMeta to GstBuffer in a probe on clockoverlay sink. How can this problem be solved with GstMeta (or an alternate solution)?

Sample pipeline with two branches:

pipeline
pipeline5204×389 117 KB

Thank you in advanced.

2

So you implemented a GstMeta subclass? Show us the code? The transform function should copy the data if the passed type is GST_META_TRANSFORM_IS_COPY(type).

3

Hi @philn, thanks for your reply. here is a link. Please see MyExampleMeta.h and MyExampleMeta.cpp. I don’t know what needs updating such that GST_META_TRANSFORM_IS_COPY(type) would return true.

The meta_transform callback registered in gst_meta_register() is never called - if that helps debugging the issue.

Thanks again.

4

Add GST_META_TAG_VIDEO_STR in the meta tags?
The base class for video encoders will not copy metas in some certain conditions, see gst_video_encoder_transform_meta_default().

The mfh264enc and its base class don’t override the transform_meta vfunc, so the default one is used.

5

It works. It works if I use static const gchar* tags[] = { GST_META_TAG_VIDEO_STR, NULL}; but it doesn’t work if I have multiple tags static const gchar* tags[] = { GST_META_TAG_VIDEO_STR, "foo", "bar", NULL};. I’ll take this as a solution, thank you so very much.

6

@philn , I am running into another problem: I cannot read my metadata from GstBuffer from within a plugin DLL I created? I can only read the metadata from within the main() app.

This seems to be related to GType not being the same within the main() app and the plugin DLL. How is this problem generally solved with Gstreamer? Here is the method that should in theory return same GType for my application/DLLs but it doesn’t:

GType my_example_meta_api_get_type(void)
{
    static GType my_example_meta_type = 0;   // THIS GETS DIFFERENT VALUES
    static const gchar* tags[] = { GST_META_TAG_VIDEO_STR, NULL };

    if (g_once_init_enter(&my_example_meta_type)) {
        GType _type = gst_meta_api_type_register("MyExampleMetaAPI", tags);
        g_once_init_leave(&my_example_meta_type, _type);
    }
    return my_example_meta_type;
}
7

This looks correct… what about the get_info() function?

8

@philn, thanks for the quick reply. Shouldn’t GType _type be the same value for each
gst_meta_api_type_register() call?

get_info() ends up calling get_type() and on the 2nd call it returns _type = 0 (with the errors below) and on the thrid call get_type() just locks up I believe. The 2nd/3rd calls are done in my case from a probe callback trying to read the metadata MyExampleMeta* meta = MY_EXAMPLE_META_GET(buffer);

Errors in terminal:

(GstRecordTest.exe:18308): GLib-GObject-CRITICAL **: 10:19:46.597: g_pointer_type_register_static: assertion 'g_type_from_name (name) == 0' failed

(GstTest.exe:18308): GLib-GObject-CRITICAL **: 10:19:46.597: g_type_set_qdata: assertion 'node != NULL' failed

(GstTest.exe:18308): GLib-CRITICAL **: 10:19:52.213: g_once_init_leave: assertion 'result != 0' failed

(GstTest.exe:18308): GStreamer-CRITICAL **: 10:19:54.751: gst_buffer_get_meta: assertion 'api != 0' failed
9

run your app in gdb with this env var set G_DEBUG=fatal_criticals and share the backtrace.

10

@philn , Thanks for the help! It turns out that the MS debugger was loading two instances of the DLL from different paths and as soon as I deleted one DLL the problem went away. Thanks again!

gstmeta
gstmeta1296×261 6.64 KB