Skip to content

Conversation

@softworkz
Copy link
Collaborator

5

@softworkz softworkz closed this Dec 16, 2021
softworkz pushed a commit that referenced this pull request Jul 4, 2022
davs2_decoder_close doesn't free those on the fly frames which
don't get output yet. It's a design bug, but easy to workaround.

Before the patch:
Direct leak of 1198606 byte(s) in 2 object(s) allocated from:
    #0 0x563af5e1e5f0 in malloc (ffmpeg+0x6675f0)
    #1 0x563af9765ef3 in davs2_malloc davs2/source/common/common.h:1240
    #2 0x563af9765ef3 in davs2_alloc_picture davs2/source/common/header.cc:815

Indirect leak of 3595818 byte(s) in 6 object(s) allocated from:
    #0 0x563af5e1e5f0 in malloc (ffmpeg+0x6675f0)
    #1 0x563af9765ef3 in davs2_malloc davs2/source/common/common.h:1240
    #2 0x563af9765ef3 in davs2_alloc_picture davs2/source/common/header.cc:815

Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
@softworkz softworkz deleted the test1 branch October 11, 2022 12:56
softworkz pushed a commit that referenced this pull request Dec 21, 2023
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 #1: 0x0000005555bef250 ffmpeg_g`enc_open(sch=0xb400007dde2d4090, enc=0xb400007e4e2daad0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:1462:11
frame #2: 0x0000005555bee094 ffmpeg_g`send_to_enc(sch=0xb400007dde2d4090, enc=0xb400007e4e2daad0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:1571:19
frame #3: 0x0000005555bee01c ffmpeg_g`sch_filter_send(sch=0xb400007dde2d4090, fg_idx=0, out_idx=0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:2154:12
frame #4: 0x0000005555bcf124 ffmpeg_g`close_output(ofp=0xb400007e4e2d85b0, fgt=0x0000007d1790eb08) at ffmpeg_filter.c:2225:15
frame #5: 0x0000005555bcb000 ffmpeg_g`fg_output_frame(ofp=0xb400007e4e2d85b0, fgt=0x0000007d1790eb08, frame=0x0000000000000000) at ffmpeg_filter.c:2317:16
frame #6: 0x0000005555bc7e48 ffmpeg_g`filter_thread(arg=0xb400007eae2ce7a0) at ffmpeg_filter.c:2836:15
frame #7: 0x0000005555bee568 ffmpeg_g`task_wrapper(arg=0xb400007d8e2db478) at ffmpeg_sched.c:2200:21

Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
softworkz pushed a commit that referenced this pull request Mar 12, 2024
The formal title of the muxer according to the specification
is "RCWT (Raw Captions With Time)", so canonize this
in the long name of the codec and docs.

In the documentation section, point #2 was wrong: ccextractor
extracts the Closed Captions data and stores normalized bits
similarly to this muxer.

Signed-off-by: Marth64 <marth64@proxyid.net>
softworkz pushed a commit that referenced this pull request Jan 17, 2025
Explicitly use ldur for unaligned offsets; newer versions of
armasm64 implicitly convert ldr to ldur as necessary, but older
versions require it explicitly written out.

This fixes these build errors:

    ffmpeg\libavcodec\aarch64\vvc\inter.o.asm(2039) :
     error A2518: operand 2: Memory offset must be aligned
            ldr             s5, [x1, #1]
    ffmpeg\libavcodec\aarch64\vvc\inter.o.asm(2250) :
     error A2518: operand 2: Memory offset must be aligned
            ldr             d7, [x1, #2]

Signed-off-by: Martin Storsjö <martin@martin.st>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant