[gst-devel] [gst-cvs] wtaygst-plugins-good: gst-plugins-good/gst-plugins-good/gst/rtp/
Wai-Ming Ho
waiming at ailuropoda.net
Wed Dec 12 18:02:02 CET 2007
On Wed, 2007-12-12 at 16:46 +0100, Peter Kjellerstedt wrote:
> > Subject: Re: [gst-devel] [gst-cvs] wtaygst-plugins-good:
> > gst-plugins-good/gst-plugins-good/gst/rtp/
> >
> > Hi,
> >
> > On Wed, 2007-12-12 at 10:28 +0100, Peter Kjellerstedt wrote:
> >
> > > > Patch by: Wai-Ming Ho <webregbox at yahoo dot co dot uk>
> > > > * gst/rtp/gstrtph264pay.c: (gst_rtp_h264_pay_init),
> > > > (gst_rtp_h264_pay_finalize), (gst_rtp_h264_pay_setcaps),
> > > > (next_start_code), (is_nal_equal), (gst_rtp_h264_pay_decode_nal),
> > > > (encode_base64), (gst_rtp_h264_pay_parse_sps_pps),
> > > > (gst_rtp_h264_pay_handle_buffer):
> > > > * gst/rtp/gstrtph264pay.h:
> > > > Use higher performance start-code searching.
> > > > Parse NALs and store SPS, PPS and profile in the caps so
> > > > that they can be used in the SDP. Fixes #502814.
> > > >
> > > > Modified files:
> > > > . : ChangeLog
> > > > gst/rtp : gstrtph264pay.c gstrtph264pay.h
> > > >
> > > > Links:
> > > >
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins-good/Ch
> angeLog.diff?r1=1.3212&r2=1.3213
> > > >
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins-good/gs
> t/rtp/gstrtph264pay.c.diff?r1=1.3&r2=1.4
> > > >
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins-good/gs
> t/rtp/gstrtph264pay.h.diff?r1=1.1&r2=1.2
> > >
> > > * Why whould is_nal_equal() be faster than memcmp()?
> > > On what architectures?
> > > Oh, and the comment preceding it mentions memcpy rather
> > > than memcmp()...
> >
> > fingers typing error :-) it's suppose to read memcmp()
> >
> > I tested it on Ubuntu 7.04 /Intel Genuine Intel(R) CPU 2140 @ 1.60GHz
> > stepping 02. when I proposed the patch, is_nal_equal() is either the
> > patched implementation or a simple call to memcmp().
> >
> > As for why, I would have to look at the gcc generated code but a
> > quick guess would be the 32-bit XOR's instead of byte-wise CMP
> > (since memcmp() needs to return either equal, less or greater).
>
> I very much doubt memcmp() is implemented as a simple byte-wise
> compare. I know that uClibc (which we use) use a much more
> elaborate memcmp() comparing two unsigned long at a time, and
> since the memcmp code seems to be taken from glibc, glibc would
> too.
>
> > Other than that, if the code is not critical performance hit,
> > I would be pretty happy if it was a simple call to memcmp().
> > The gain of 20% is observed only when both blocks are identical
> > most (or all in the case os single SPS/PPS H264 bitstreams) of
> > the time.
>
> I am not sure the potential performance increase is worth all
> the extra complexity compared to a simple memcmp(). After all
> the GStreamer code does a lot of memory allocations and memory
> copying all over the place. It is not really optimised at this
> level...
>
I agree. I can't commit on CVS. Perhaps one of the maintainer could step
in and take the necessary actions to clean this up?
waiming
More information about the gstreamer-devel
mailing list