Fix Mpeg7 inconsistent signature comp result #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jailuthra
approved these changes
May 26, 2021
|
@oscar-davids Mind dropping 1da1787 (a version of this is already included in the |
jailuthra
reviewed
Jun 1, 2021
oscar-davids
force-pushed
the
dev-fixsignbug
branch
3 times, most recently
from
d79afe1
to
1da1787
Compare
|
A few additional minor Git related comments in the interest of maintaining a cleaner + easier to follow commit history:
|
oscar-davids
force-pushed
the
dev-fixsignbug
branch
from
61bd083
to
f2f49a4
Compare
oscar-davids
force-pushed
the
dev-fixsignbug
branch
from
1fdf06e
to
2dc2b11
Compare
jailuthra
pushed a commit
that referenced
this pull request
Jul 2, 2021
ad-astra-video
pushed a commit
to ad-astra-video/FFmpeg
that referenced
this pull request
Feb 25, 2024
In close_output(), a dummy frame is created with format NONE passed to enc_open(), which isn't prepared for it. The NULL pointer dereference happened at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth. When fgt.graph is NULL, skip fg_output_frame() since there is nothing to output. frame #0: 0x0000005555bc34a4 ffmpeg_g`enc_open(opaque=0xb400007efe2db690, frame=0xb400007efe2d9f70) at ffmpeg_enc.c:235:44 frame livepeer#1: 0x0000005555bef250 ffmpeg_g`enc_open(sch=0xb400007dde2d4090, enc=0xb400007e4e2daad0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:1462:11 frame livepeer#2: 0x0000005555bee094 ffmpeg_g`send_to_enc(sch=0xb400007dde2d4090, enc=0xb400007e4e2daad0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:1571:19 frame livepeer#3: 0x0000005555bee01c ffmpeg_g`sch_filter_send(sch=0xb400007dde2d4090, fg_idx=0, out_idx=0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:2154:12 frame livepeer#4: 0x0000005555bcf124 ffmpeg_g`close_output(ofp=0xb400007e4e2d85b0, fgt=0x0000007d1790eb08) at ffmpeg_filter.c:2225:15 frame livepeer#5: 0x0000005555bcb000 ffmpeg_g`fg_output_frame(ofp=0xb400007e4e2d85b0, fgt=0x0000007d1790eb08, frame=0x0000000000000000) at ffmpeg_filter.c:2317:16 frame livepeer#6: 0x0000005555bc7e48 ffmpeg_g`filter_thread(arg=0xb400007eae2ce7a0) at ffmpeg_filter.c:2836:15 frame livepeer#7: 0x0000005555bee568 ffmpeg_g`task_wrapper(arg=0xb400007d8e2db478) at ffmpeg_sched.c:2200:21 Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Sometimes, the detection result of whether two videos match is inconsistent.
Why
I am sure that there was a bug in the calculation of compare two signature values.
In here, 2 * HOUGH_MAX_OFFSET + 1 hspace_elem structure array are created but initialized only HOUGH_MAX_OFFSET elements.
In the calculation of compare, used more array elements than HOUGH_MAX_OFFSET.
Testing
The signature compare result is always the same.
ffmpeg -i test_cpu/test_cpu_P720p30fps16x9_2_0_15.ts -i test_gpu/test_gpu_P720p30fps16x9_2_0_15.ts -filter_complex "[0:v][1:v] signature=nb_inputs=2:detectmode=full" -map :v -f null -