Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Replaces the data pointers with the mapped cuvid ones.
Adds buffer_refs to the frame to ensure the needed contexts stay alive
and the cuvid idx stays allocated.
Adds another buffer_ref to unmap the frame when it's unreferenced itself.
This reverts commit 7d4e1f7cfb.
Accidentially pushed this with a batch of other patches, and it didn't
seem to break anything, so I went with it.
Except it does, so reverting it it is.
This mimics the logic flow in all the other callbacks
(pat_cb, sdt_cb, m4sl_cb), and avoids calling skip_identical()
for non PMT_TID packets.
Since skip_identical modifies internal state like
MpegTSSectionFilter.last_ver, this change prevents unnecessary
reprocessing on some streams which contain multiple tables in
the PMT pid. This can be observed with streams from certain US
cable providers, which include both tid=0x2 and another unspecified
tid=0xc0.
Signed-off-by: Aman Gupta <aman@tmm1.net>
No longer required since 63d875772d. The equivalent hack
for h264 was removed in that commit, but this one was missed.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Removes unnecessary data copies, and partially fixes potential issues
with dangling references held in said lists.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
This helps figuring out where the filter is slow:
70.53% ffmpeg_g ffmpeg_g [.] nlmeans_slice
25.73% ffmpeg_g ffmpeg_g [.] compute_safe_ssd_integral_image_c
1.74% ffmpeg_g ffmpeg_g [.] compute_unsafe_ssd_integral_image
0.82% ffmpeg_g ffmpeg_g [.] ff_mjpeg_decode_sos
0.51% ffmpeg_g [unknown] [k] 0xffffffff91800a80
0.24% ffmpeg_g ffmpeg_g [.] weight_averages
(Tested with a large image that takes several seconds to process)
Since this function is irrelevant speed wise, the file's TODO is
updated.
before: ssd_integral_image_c: 49204.6
after: ssd_integral_image_c: 44272.8
Unrolling by 4 made the biggest difference on odroid-c2 (aarch64);
unrolling by 2 or 8 both raised 46k cycles vs 44k for 4.
Additionally, this is a much better reference when writing SIMD (SIMD
vectorization will just target 16 instead of 4).
SIMD code will not have to deal with padding itself. Overwriting in that
function may have been possible but involve large overreading of the
sources. Instead, we simply make sure the width to process is always a
multiple of 16. Additionally, there must be some actual area to process
so the SIMD code can have its boundary checks after processing the first
pixels.
