After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748922 - vtdec: duplicating input frame's metas (inc. source H264 sample buffer)
vtdec: duplicating input frame's metas (inc. source H264 sample buffer)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal normal
: 1.5.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: corevideomemory
 
 
Reported: 2015-05-05 02:47 UTC by Ilya Konstantinov
Modified: 2015-06-09 14:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ilya Konstantinov 2015-05-05 02:47:41 UTC
In 854645861790588d7bca72b79a56c1b1d5d7689f, Alessandro Decina introduced:

-  buf = gst_core_video_buffer_new (self->ctx, cvbuf);
-  gst_buffer_copy_metadata (buf, self->cur_inbuf,
-      GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS);
+  buf = gst_core_video_buffer_new (self->ctx, cvbuf, &self->vinfo);
+  gst_buffer_copy_into (buf, self->cur_inbuf, GST_BUFFER_COPY_METADATA, 0, -1);

In b1a756fda730d5edde0d6d83df723d8923008f98, Alessandro Decina added:

-  gst_buffer_copy_into (buf, src_buf, GST_BUFFER_COPY_METADATA, 0, -1);
...
+  gst_buffer_copy_into (buf, frame->input_buffer,
+      GST_BUFFER_COPY_METADATA | GST_BUFFER_COPY_FLAGS, 0, -1);

Since I've implemented copying for Core Media Meta (see bug 747216) -- which in itself is required e.g. to pass intervideo* boundaries -- we begun retaining the input CMSampleBuffer (i.e. the H.264 data) in the output frame, which is certainly not something we want.

What is the rationale behind these changes?

GST_BUFFER_COPY_FLAGS - I'd assume GstVideoDecoder does all the needed flags work.
GST_BUFFER_COPY_TIMESTAMPS - The timestamps are already copied as part of gst_video_decoder_finish_frame.
GST_BUFFER_COPY_METADATA - Any metas we should actually copy? (I see no other decoder doing that)
Comment 1 Ilya Konstantinov 2015-05-29 12:47:28 UTC
My commit removes it with no ill side effects:
https://github.com/ikonst/gst-plugins-bad/commit/466232c73818b253b775194dcf52758ed0d45156

In short, any reason why we should keep (indiscriminately) copying meta from input to output frame?
Comment 2 Sebastian Dröge (slomo) 2015-06-09 14:21:08 UTC
commit faf903720a6ab6d99b2567cd6af8195b07ff5fab
Author: Ilya Konstantinov <ilya.konstantinov@gmail.com>
Date:   Mon May 11 16:44:33 2015 +0200

    vtenc: no need for queue_length with try_pop

commit 1f7681dd0ab9e2548a4dc7b35926183c972b32e6
Author: Ilya Konstantinov <ilya.konstantinov@gmail.com>
Date:   Tue May 5 15:07:53 2015 +0200

    vtdec: don't copy meta from input to output
    
    Copying arbitrary metas is going to cause problems and this should really be
    handled by the base class. It overrides most other things already anyway,
    including timestamp and duration. Those are just set here now so we can
    insert the frame sorted into the queue.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=748922