From: Timo Rothenpieler <timo@rothenpieler.org>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Added support for MB_INFO
Date: Fri, 17 Jun 2022 12:34:33 +0200
Message-ID: <31d55286-6118-0438-62d8-c04fcb6d183d@rothenpieler.org> (raw)
In-Reply-To: <aa3badef857646a993f04013a93657abcc5ff420.camel@amazon.it>
On 17.06.2022 12:15, Carotti, Elias wrote:
> Hi,
> thanks for pointing out the printf. That's a left over which I removed.
>
> I am not clear on the possible leak you are hinting at.
> The new side information only passes two pointers to libx264, the first
> one being a buffer with the flags and a pointer to a deallocator which
> may be NULL.
>
> If the deallocator is not NULL libx264 we're yielding the deallocation
> responsibility to libx264, otherwise the ownership of the buffer and,
> as such, the responsibility for the deallocation remains with the
> caller.
> As such, the only possibility for a leak seems to me due to a
> programming error.
> Is that what you were asking or am I missing something else?
>
> Please find attached the updated patch.
>
> Elias
>
Yes, exactly. It relies on x264 to free it.
What happens if x264 is not involved, but some other encoder, which does
not check for that kind of side data?
How does the caller know that the data was consumed, and the ownership
passed on?
The only sane way would be for the caller to hand over the ownership to
ffmpeg, which then takes care of making sure it gets freed.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2022-06-17 10:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 10:11 Carotti, Elias
2022-06-17 8:41 ` Carotti, Elias
2022-06-17 9:40 ` Timo Rothenpieler
2022-06-17 10:15 ` Carotti, Elias
2022-06-17 10:34 ` Timo Rothenpieler [this message]
2022-06-17 10:59 ` Carotti, Elias
2022-06-17 15:10 ` Timo Rothenpieler
2022-06-17 15:30 ` Carotti, Elias
2022-06-17 23:41 ` Stefano Sabatini
2023-05-03 12:27 ` Carotti, Elias
2023-05-05 8:03 ` Carotti, Elias
2022-06-18 15:06 ` Anton Khirnov
2022-06-21 8:48 ` Carotti, Elias
2022-06-23 13:29 ` Anton Khirnov
2022-06-23 14:21 ` Andreas Rheinhardt
2022-06-23 14:48 ` Anton Khirnov
2022-06-24 9:14 ` Andreas Rheinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31d55286-6118-0438-62d8-c04fcb6d183d@rothenpieler.org \
--to=timo@rothenpieler.org \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git