On 11/02/2019 22:47, Andreas Rheinhardt wrote: > This is in preparation for another patch that will stop needless > reallocations of the unit array. > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@googlemail.com> > --- > libavcodec/filter_units_bsf.c | 8 ++++---- > libavcodec/trace_headers_bsf.c | 13 +++++++------ > 2 files changed, 11 insertions(+), 10 deletions(-)
On 11/02/2019 22:47, Andreas Rheinhardt wrote:> Currently, a fragment's unit array is constantly reallocated during > splitting of a packet. This commit changes this: One can keep the units > array by distinguishing between the number of allocated and the number > of valid units in the units array. > > The more units a packet is split into, the bigger the benefit. > So MPEG-2 benefits the most; for a video coming from an NTSC-DVD > (usually 32 units per frame) the average cost of cbs_insert_unit (for a > single unit) went down from 6717 decicycles to 450 decicycles (based > upon 10 runs with 4194304 runs each); if each packet consists of only > one unit, it went down from 2425 to 448; for a H.264 video where most > packets contain nine units, it went from 4431 to 450. > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@googlemail.com> > --- > This time I have also changed VAAPI to stop reallocating the units > array. Keep in mind that I couldn't test this at all. > libavcodec/av1_metadata_bsf.c | 6 ++- > libavcodec/av1_parser.c | 5 ++- > libavcodec/cbs.c | 62 +++++++++++++++++------------ > libavcodec/cbs.h | 33 +++++++++++++-- > libavcodec/filter_units_bsf.c | 7 ++-- > libavcodec/h264_metadata_bsf.c | 6 ++- > libavcodec/h264_redundant_pps_bsf.c | 6 ++- > libavcodec/h265_metadata_bsf.c | 6 ++- > libavcodec/mpeg2_metadata_bsf.c | 6 ++- > libavcodec/trace_headers_bsf.c | 5 ++- > libavcodec/vaapi_encode_h264.c | 9 +++-- > libavcodec/vaapi_encode_h265.c | 9 +++-- > libavcodec/vaapi_encode_mjpeg.c | 3 +- > libavcodec/vaapi_encode_mpeg2.c | 5 ++- > libavcodec/vp9_metadata_bsf.c | 4 +- > 15 files changed, 113 insertions(+), 59 deletions(-) LGTM, applied. Thank you! - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel