gst_buffer_get getting stale data

ht techdev ht.techdev at gmail.com
Wed Sep 14 20:04:24 UTC 2016


Hi

On gstreamer 1.4.5, running on CentOs 7.2, having problem with reading meta
data attached to buffers. The following scenario is the where the problem is
observed:

State 1:

Meta data is conditionally attached to outgoing buffers, i.e., only if there
is valid meta, it would get attached, e.g.:

.

if(userdata){

                    gst_buffer_add_userdata_meta (frame->output_buffer,&
userdata_meta);

.

Intended recipient of meta properly ignores  gst_buffer_get  call:

.

GstUserdataMeta *userdata_meta=gst_buffer_get_userdata_meta
(input_frame->input_buffer);

      if(userdata_meta && userdata_meta->userdatameta){

          // This is not executed

      }

 

State 2:

Meta attachment condition becomes true, proper meta data are attached

Recipient properly extracts meta:

GstUserdataMeta *userdata_meta=gst_buffer_get_userdata_meta
(input_frame->input_buffer);

      if(userdata_meta && userdata_meta->userdatameta){

          // This is  executed

      }

State 3:

Meta data attachment condition becomes false, no meta is attached

Recipient still extracts meta!

 

It is noted that due to buffering, it is expected that there would be a lag
from the time that meta attachment condition become false to the time that
recipient is expected to ignor gst_buffer_get calls. Here is what I am
getting:

 

On State 2, the recipient sees: GST_INFO_OBJECT(xx,"%p %p\n", userdata_meta,
userdata_meta->userdatameta);

.

0:00:52.027950698 27204      0x16e6f20 INFO       xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde757e20 0x7f8c0826ab90 

0:00:52.047961117 27204      0x16e6f20 INFO       xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde864ae0 0x7f8c082683f0 

0:00:52.068356845 27204      0x16e6f20 INFO       xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bdf2e8120 0x7f8c082685b0 

0:00:52.087984535 27204      0x16e6f20 INFO       xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bdf2eeea0 0x7f8c08268db0 

0:00:52.107973286 27204      0x16e6f20 INFO       xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde76d1e0 0x7f8c080b2620 

.

(Note that meta field address changes per call, as the meta server is
allocating new memory for each meta data)

 

On State 3,  the recipient sees: GST_INFO_OBJECT(xx,"%p %p\n",
userdata_meta, userdata_meta->userdatameta);

.

0:00:53.528208158 27204      0x16e6f20 INFO                  xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde8abe20 0x7f8c0bf11a40 

0:00:53.547948573 27204      0x16e6f20 INFO                  xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde845ae0 0x7f8c0bf11a40 

0:00:53.567948574 27204      0x16e6f20 INFO                  xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde74f1e0 0x7f8c0bf11a40 

0:00:53.587983423 27204      0x16e6f20 INFO                  xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde785ae0 0x7f8c0bf11a40 

0:00:53.607985743 27204      0x16e6f20 INFO                  xx
xx.cpp:1547:gst_xx_encode_frame:<xx> 0x7f8bde7681e0 0x7f8c0bf11a40 

.

Note that recipient keeps reading the same stale memory location.

 

Any thoughts?

Cheers,

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160914/5701e578/attachment-0001.html>


More information about the gstreamer-devel mailing list