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 719530 - encoder: use GAsyncQueue wherever possible
encoder: use GAsyncQueue wherever possible
Status: RESOLVED FIXED
Product: gstreamer-vaapi
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks: 719412
 
 
Reported: 2013-11-29 05:31 UTC by Gwenole Beauchesne
Modified: 2013-12-04 18:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Gwenole Beauchesne 2013-11-29 05:31:53 UTC 
A standard GAsyncQueue needs to be used instead of the various GMutex, GCond and GQueue. Some locking conditions could probably be lifted along the way, as well. It seems that the plug-in elements already call into GstVaapiEncoder through the base GstVideoEncoder stream lock held.
Comment 1 Gwenole Beauchesne 2013-12-04 18:17:00 UTC 
I finally decided to work on this one. Now fixed in git master branch.
Comment 2 Gwenole Beauchesne 2013-12-04 18:17:10 UTC 
commit 26726b18fcdf3f4fac1cce7420c8a9715295cfb2
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Wed Dec 4 17:05:17 2013 +0100

    encoder: avoid extra allocations of GstVaapiEncoderSyncPic objects.
    
    Kill GstVaapiEncoderSyncPic objects that are internally and temporarily
    allocated. Rather, associate a GstVaapiEncPicture to a coded buffer
    through GstVaapiCodedBufferProxy user-data facility.
    
    Besides, use a GAsyncQueue to maintain a thread-safe queue object of
    coded buffers.
    
    Partial fix for the following report:
    https://bugzilla.gnome.org/show_bug.cgi?id=719530