[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