[PATCH] lavc/libx265: flag as experimental
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now. Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into. --- libavcodec/libx265.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 420d0953af..d4511251a5 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -895,7 +895,8 @@ FFCodec ff_libx265_encoder = { .p.id = AV_CODEC_ID_HEVC, .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE | + AV_CODEC_CAP_EXPERIMENTAL, .p.priv_class = &class, .p.wrapper_name = "libx265", .init = libx265_encode_init, -- 2.39.1
On 3/15/2023 11:45 AM, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
This is a really bad idea. It will break several scripts and command lines that were working perfectly fine and giving the desired results.
--- libavcodec/libx265.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 420d0953af..d4511251a5 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -895,7 +895,8 @@ FFCodec ff_libx265_encoder = { .p.id = AV_CODEC_ID_HEVC, .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE | + AV_CODEC_CAP_EXPERIMENTAL, .p.priv_class = &class, .p.wrapper_name = "libx265", .init = libx265_encode_init,
Quoting James Almer (2023-03-15 15:46:41)
On 3/15/2023 11:45 AM, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
This is a really bad idea. It will break several scripts and command lines that were working perfectly fine and giving the desired results.
I thought we prioritize security and correctness over keeping commandlines working at all cost. Besides, this might motivate someone into actually fixing x265. We have a long-standing reputation for being an endless source of security issues. I think we should take stands like this more often if we want to get rid of it. -- Anton Khirnov
On 15/03/2023 15:45, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into. --- libavcodec/libx265.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 420d0953af..d4511251a5 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -895,7 +895,8 @@ FFCodec ff_libx265_encoder = { .p.id = AV_CODEC_ID_HEVC, .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE | + AV_CODEC_CAP_EXPERIMENTAL, .p.priv_class = &class, .p.wrapper_name = "libx265", .init = libx265_encode_init,
My understanding of this flag for encoders is that it indicates some possible experimental/non-standard bitstream features contained in output data, not that the implementation itself is considered sub-par. Regards, Tobias
Quoting Tobias Rapp (2023-03-15 16:00:04)
On 15/03/2023 15:45, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into. --- libavcodec/libx265.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 420d0953af..d4511251a5 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -895,7 +895,8 @@ FFCodec ff_libx265_encoder = { .p.id = AV_CODEC_ID_HEVC, .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE | + AV_CODEC_CAP_EXPERIMENTAL, .p.priv_class = &class, .p.wrapper_name = "libx265", .init = libx265_encode_init,
My understanding of this flag for encoders is that it indicates some possible experimental/non-standard bitstream features contained in output data, not that the implementation itself is considered sub-par.
Our internal aac encoder used to be marked as experimental. vorbis and opus still are. So it's clearly about the implementation quality rather than standard compliance. -- Anton Khirnov
Tobias Rapp:
On 15/03/2023 15:45, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into. --- libavcodec/libx265.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 420d0953af..d4511251a5 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -895,7 +895,8 @@ FFCodec ff_libx265_encoder = { .p.id = AV_CODEC_ID_HEVC, .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE | + AV_CODEC_CAP_EXPERIMENTAL, .p.priv_class = &class, .p.wrapper_name = "libx265", .init = libx265_encode_init,
My understanding of this flag for encoders is that it indicates some possible experimental/non-standard bitstream features contained in output data, not that the implementation itself is considered sub-par.
You are confusing the AV_CODEC_CAP_EXPERIMENTAL with FF_COMPLIANCE_EXPERIMENTAL. - Andreas
Quoting Anton Khirnov (2023-03-15 15:45:25)
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
Ping. I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage. -- Anton Khirnov
On 17/10/2024 11:22, Anton Khirnov wrote:
Quoting Anton Khirnov (2023-03-15 15:45:25)
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
Ping.
I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage.
I would second this, without something drastic like this, no attention will be brought to the quite serious issues of that encoder.
On 10/17/2024 10:49 AM, Timo Rothenpieler wrote:
On 17/10/2024 11:22, Anton Khirnov wrote:
Quoting Anton Khirnov (2023-03-15 15:45:25)
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
Ping.
I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage.
I would second this, without something drastic like this, no attention will be brought to the quite serious issues of that encoder.
Ok.
在 2024年10月17日，下午10:01，James Almer <jamrial@gmail.com> 写道：
On 10/17/2024 10:49 AM, Timo Rothenpieler wrote:
On 17/10/2024 11:22, Anton Khirnov wrote: Quoting Anton Khirnov (2023-03-15 15:45:25)
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
Ping.
I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage. I would second this, without something drastic like this, no attention will be brought to the quite serious issues of that encoder.
Ok.
+1
_______________________________________________ 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".
<OpenPGP_signature.asc>
Hi all , We understand your concern behind marking x265 as experimental but we wanted to let you know that our x265 development team is actively working on resolving multiple issues that have been brought to our notice so far through bitbucket issue tracker(including issue #482) and are planning to release v4.1 with all the fixes shortly. We are also continuously levelling up our tests to catch the issues beforehand and keep up code hygiene that we have maintained so far. Hence we request this forum to reconsider the decision for the benefit of several x265 users. *Thanks,* *Kirithika* On Thu, Oct 17, 2024 at 9:28 PM Zhao Zhili <quinkblack@foxmail.com> wrote:
在 2024年10月17日，下午10:01，James Almer <jamrial@gmail.com> 写道：
On 10/17/2024 10:49 AM, Timo Rothenpieler wrote:
On 17/10/2024 11:22, Anton Khirnov wrote: Quoting Anton Khirnov (2023-03-15 15:45:25)
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
Ping.
I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage. I would second this, without something drastic like this, no attention will be brought to the quite serious issues of that encoder.
Ok.
+1
_______________________________________________ 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".
<OpenPGP_signature.asc>
_______________________________________________ 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".
Hi all, We would like to update that we have fixed the memory leaks and other issues reported in x265 and will be releasing v4.1 this week. *Thanks,* *Kirithika* On Fri, Oct 18, 2024 at 3:08 PM Kirithika Kalirathnam < kirithika@multicorewareinc.com> wrote:
Hi all ,
We understand your concern behind marking x265 as experimental but we wanted to let you know that our x265 development team is actively working on resolving multiple issues that have been brought to our notice so far through bitbucket issue tracker(including issue #482) and are planning to release v4.1 with all the fixes shortly. We are also continuously levelling up our tests to catch the issues beforehand and keep up code hygiene that we have maintained so far. Hence we request this forum to reconsider the decision for the benefit of several x265 users.
*Thanks,* *Kirithika*
On Thu, Oct 17, 2024 at 9:28 PM Zhao Zhili <quinkblack@foxmail.com> wrote:
在 2024年10月17日，下午10:01，James Almer <jamrial@gmail.com> 写道：
On 10/17/2024 10:49 AM, Timo Rothenpieler wrote:
On 17/10/2024 11:22, Anton Khirnov wrote: Quoting Anton Khirnov (2023-03-15 15:45:25)
This encoder leaks and overreads, as can be seen e.g. by running an encode under valgrind with default encoder parameters. This was known upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed until now.
Since upstream does not seem to practice basic code hygiene, make sure people do not use this encoder without knowing what they are getting into.
Ping.
I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage. I would second this, without something drastic like this, no attention will be brought to the quite serious issues of that encoder.
Ok.
+1
_______________________________________________ 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".
<OpenPGP_signature.asc>
_______________________________________________ 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".
Hi All, x265 v4.1 <https://bitbucket.org/multicoreware/x265_git/branch/master> is released with the fixes addressing memory leak and other reported issues.Please check it out. *Thanks,* *Kirithika* On Mon, Nov 11, 2024 at 9:50 AM Kirithika Kalirathnam < kirithika@multicorewareinc.com> wrote:
Hi all,
We would like to update that we have fixed the memory leaks and other issues reported in x265 and will be releasing v4.1 this week.
*Thanks,* *Kirithika*
On Fri, Oct 18, 2024 at 3:08 PM Kirithika Kalirathnam < kirithika@multicorewareinc.com> wrote:
Hi all ,
We understand your concern behind marking x265 as experimental but we wanted to let you know that our x265 development team is actively working on resolving multiple issues that have been brought to our notice so far through bitbucket issue tracker(including issue #482) and are planning to release v4.1 with all the fixes shortly. We are also continuously levelling up our tests to catch the issues beforehand and keep up code hygiene that we have maintained so far. Hence we request this forum to reconsider the decision for the benefit of several x265 users.
*Thanks,* *Kirithika*
On Thu, Oct 17, 2024 at 9:28 PM Zhao Zhili <quinkblack@foxmail.com> wrote:
在 2024年10月17日，下午10:01，James Almer <jamrial@gmail.com> 写道：
On 10/17/2024 10:49 AM, Timo Rothenpieler wrote:
On 17/10/2024 11:22, Anton Khirnov wrote: Quoting Anton Khirnov (2023-03-15 15:45:25) > This encoder leaks and overreads, as can be seen e.g. by running an > encode under valgrind with default encoder parameters. This was known > upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed > until now. > > Since upstream does not seem to practice basic code hygiene, make sure > people do not use this encoder without knowing what they are getting > into.
Ping.
I still think this should be applied. The issues seem to have gotten worse, if anything, with recent ABI breakage. I would second this, without something drastic like this, no attention will be brought to the quite serious issues of that encoder.
Ok.
+1
_______________________________________________ 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".
<OpenPGP_signature.asc>
_______________________________________________ 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".
On Thu, Nov 28, 2024 at 3:22 AM Kirithika Kalirathnam < kirithika@multicorewareinc.com> wrote:
Hi All,
x265 v4.1 <https://bitbucket.org/multicoreware/x265_git/branch/master> is released with the fixes addressing memory leak and other reported issues.Please check it out.
*Thanks,* *Kirithika*
Hi Kirithika, would you be able to also merge this one https://bitbucket.org/multicoreware/x265_git/pull-requests/25 ? It's triggering security alarms in the company internal checks - I've already updated the PR once as requested, but there are new conflicts now. Any chance you could help? Thank you -- Vittorio
Hi Vittorio, The commits in this PR <https://bitbucket.org/multicoreware/x265_git/pull-requests/25> were picked and pushed to the master branch of x265.(b647da9 <https://bitbucket.org/multicoreware/x265_git/commits/b647da90fb6aeac20cd1228cd02af932b913db23> ,b153007 <https://bitbucket.org/multicoreware/x265_git/commits/b153007d1e10091a0ef38d16f1d8f35bc0437343> ,114af15 <https://bitbucket.org/multicoreware/x265_git/commits/114af1598c43c603a6d9473e5f1102efbebf9e27> ). *Thanks,* *Kirithika* On Thu, Nov 28, 2024 at 10:36 PM Vittorio Giovara < vittorio.giovara@gmail.com> wrote:
On Thu, Nov 28, 2024 at 3:22 AM Kirithika Kalirathnam < kirithika@multicorewareinc.com> wrote:
Hi All,
x265 v4.1 <https://bitbucket.org/multicoreware/x265_git/branch/master> is released with the fixes addressing memory leak and other reported issues.Please check it out.
*Thanks,* *Kirithika*
Hi Kirithika, would you be able to also merge this one https://bitbucket.org/multicoreware/x265_git/pull-requests/25 ? It's triggering security alarms in the company internal checks - I've already updated the PR once as requested, but there are new conflicts now. Any chance you could help? Thank you -- Vittorio _______________________________________________ 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".
On Tue, Dec 3, 2024 at 1:07 AM Kirithika Kalirathnam < kirithika@multicorewareinc.com> wrote:
Hi Vittorio,
The commits in this PR <https://bitbucket.org/multicoreware/x265_git/pull-requests/25> were picked and pushed to the master branch of x265.(b647da9 < https://bitbucket.org/multicoreware/x265_git/commits/b647da90fb6aeac20cd1228...
,b153007 < https://bitbucket.org/multicoreware/x265_git/commits/b153007d1e10091a0ef38d1...
,114af15 < https://bitbucket.org/multicoreware/x265_git/commits/114af1598c43c603a6d9473...
).
*Thanks,* *Kirithika*
Thanks that's perfect, I suppose the PR can be closed then! -- Vittorio
participants (8)
-
Andreas Rheinhardt -
Anton Khirnov -
James Almer -
Kirithika Kalirathnam -
Timo Rothenpieler -
Tobias Rapp -
Vittorio Giovara -
Zhao Zhili