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 752774 - srtpenc: remove unnecessary rtp/rtcp checks to improve performance
srtpenc: remove unnecessary rtp/rtcp checks to improve performance
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.5.2
Other Linux
: Normal enhancement
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-23 12:21 UTC by Miguel París Díaz
Modified: 2015-08-16 13:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
srtpenc: add "check-input-buffers" prop (4.20 KB, patch)
2015-07-23 12:21 UTC, Miguel París Díaz
none Details | Review
srtpenc: do not check input buffers (3.10 KB, patch)
2015-07-24 07:43 UTC, Miguel París Díaz
committed Details | Review

Description Miguel París Díaz 2015-07-23 12:21:25 UTC
Created attachment 307984 [details] [review]
srtpenc: add "check-input-buffers" prop

Now, srtpenc is checking if every input buffer is RTP or RTCP before encryption.
This adds an overhead that can be avoided if the source element ensures that each buffer is RTP or RTCP.
Comment 1 Olivier Crête 2015-07-23 18:19:06 UTC
How much of a difference does it make? rtpsession in rtpbin also does the same thing.
Comment 2 Tim-Philipp Müller 2015-07-23 18:28:42 UTC
These checks seem weird to me, can't we just assume trusted/already-verified RTP/RTCP input here? And if it's not trusted/checked, then we probably shouldn't error out but just drop the buffer?
Comment 3 Miguel París Díaz 2015-07-23 21:20:39 UTC
In my benchmark case, it implies the 7% of the srtpenc processing for doing something unnecessary.
About rtpsession I do not see where this kind of check is done.
Comment 4 Olivier Crête 2015-07-23 21:41:27 UTC
Those checks seem to be legacy, they date from the time where we parsed the ssrc out of the packets. We should probably just remove them entirely.
Comment 5 Miguel París Díaz 2015-07-23 22:02:52 UTC
OK, I will update the patch to remove these checks instead of adding a property.

Moreover, there an overhead allocating and moving memory before/after the encryption. I have seen this into gst_srtp_enc_process_buffer:
  7.5% - gst_buffer_new_allocate
  5.9% - gst_buffer_extract
  2.0% - gst_buffer_set_size
  2.0% - gst_buffer_copy_into
  2.2% - gst_buffer_map

Could be a way of reduce this?
  Can we avoid some of this operations?
  Having a buffer pool or something like that? (for gst_buffer_new_allocate)
  Do you think if this function can be improved?
Comment 6 Olivier Crête 2015-07-23 22:41:36 UTC
To remove that copy, we'd need a way to request padding from the element that allocated the buffer, but we currently don't have that implemented anywhere. We could possibly do that with the allocation params in the reply to the allocation query. That said, I don't think this is implemented by any of the payloaders. They could in turn request a prefix from the encoder, so that the whole thing can be done in place.. But none of this is trivial, and it may not be worth it.

Another option would be to make the srtp library understand scattered memory and just append another buffer for the suffix.
Comment 7 Miguel París Díaz 2015-07-24 07:43:49 UTC
Created attachment 308057 [details] [review]
srtpenc: do not check input buffers
Comment 8 Miguel París Díaz 2015-07-24 07:46:39 UTC
@olivier, thanks for these ideas, I will think about them ;).
For the moment I have uploaded a patch that remove input buffer checks.
Comment 9 Tim-Philipp Müller 2015-07-24 08:28:39 UTC
commit 7db723831ddcc07f506e64e027b504ac16a067f7
Author: Miguel París Díaz <mparisdiaz@gmail.com>
Date:   Fri Jul 24 09:42:53 2015 +0200

    srtpenc: do not check input buffers
    
    With this we avoid an unnecessary and considerable overhead.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=752774