[FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
James Almer
jamrial at gmail.com
Fri Mar 29 15:29:39 EET 2024
On 3/29/2024 10:10 AM, Mark Thompson wrote:
> On 28/03/2024 13:15, tong1.wu-at-intel.com at ffmpeg.org wrote:
>> From: Tong Wu <tong1.wu at intel.com>
>>
>> HEVCHdrParams* receives a pointer which points to a dynamically
>> allocated memory block. It causes the memcmp always returning 1.
>> Add a function to do the comparision. A condition is also added to
>> avoid malloc(0).
>>
>> Signed-off-by: Tong Wu <tong1.wu at intel.com>
>> ---
>> libavcodec/hevc_ps.c | 20 ++++++++++++++++----
>> libavcodec/hevc_ps.h | 4 +++-
>> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> It doesn't seem like this method works at all, even before the recent
> change with the pointer.
>
> Structs can contain arbitrary padding, and any write to the struct makes
> the padding unspecified. memcmp() is therefore never valid as a method
> of comparing after writing some fields, as done here. (It could only be
> valid if the structs compared were made by memcpy() with no fields
> written directly.)
The struct is zero allocated, so shouldn't the padding be exactly the
same for two equal VPSs after parsing?
>
> The problem is mostly harmless because the nondeterministic replacement
> of structs which we were expecting to be equivalent doesn't actually
> change anything, so why don't we just remove the comparison and always
> replace?
>
> Thanks,
>
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-devel
mailing list