From: "Wu, Tong1" <tong1.wu-at-intel.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness Date: Fri, 29 Mar 2024 14:49:02 +0000 Message-ID: <CH3PR11MB8659FEFC12389DE83641D22FC03A2@CH3PR11MB8659.namprd11.prod.outlook.com> (raw) In-Reply-To: <GV1P250MB0737AFAF25B23A9D9440C64C8F3A2@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> >From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of >Andreas Rheinhardt >Sent: Friday, March 29, 2024 10:03 PM >To: ffmpeg-devel@ffmpeg.org >Subject: Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of >memcmp losing effectiveness > >Mark Thompson: >> On 28/03/2024 13:15, tong1.wu-at-intel.com@ffmpeg.org wrote: >>> From: Tong Wu <tong1.wu@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@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 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? >> > >remove_vps() also removes any SPS referencing this VPS (and remove_sps() >does the same with PPS). Therefore if you simply repeat a VPS without >also repeating the other parameter sets directly after the new VPS and >before the first video NALU after the VPS, your extradata will have been >discarded. >This is not what the spec says. > > Yes and I observed for hevc decoder with hwaccel, get_format() is called multiple times which initializes the hwaccel context multiple times, as s->ps.sps is unexpectedly removed because of that. Hendrik also observed some playback glitches(see previous email) so it's not really harmless. >_______________________________________________ >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". _______________________________________________ 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:[~2024-03-29 14:49 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-28 13:15 tong1.wu-at-intel.com 2024-03-29 12:45 ` James Almer 2024-03-29 15:15 ` Wu, Tong1 2024-03-29 13:10 ` Mark Thompson 2024-03-29 13:29 ` James Almer 2024-03-29 14:00 ` Andreas Rheinhardt 2024-03-29 15:55 ` Mark Thompson 2024-03-29 15:58 ` Andreas Rheinhardt 2024-03-29 16:33 ` Mark Thompson 2024-04-03 8:56 ` Anton Khirnov 2024-03-29 14:02 ` Andreas Rheinhardt 2024-03-29 14:49 ` Wu, Tong1 [this message] -- strict thread matches above, loose matches on Subject: below -- 2024-03-28 9:11 tong1.wu-at-intel.com 2024-03-28 9:43 ` Hendrik Leppkes 2024-03-28 13:18 ` Wu, Tong1
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=CH3PR11MB8659FEFC12389DE83641D22FC03A2@CH3PR11MB8659.namprd11.prod.outlook.com \ --to=tong1.wu-at-intel.com@ffmpeg.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