From: "softworkz ." <softworkz-at-hotmail.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 01/11] fftools/graph/graphprint: Fix races when initializing graphprint Date: Sun, 1 Jun 2025 21:41:47 +0000 Message-ID: <DM8P223MB03657F0F1B84247C209D43F7BA63A@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw) In-Reply-To: <GV1P250MB0737060CAFC7C58F92867B668F63A@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> > -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Andreas > Rheinhardt > Sent: Sonntag, 1. Juni 2025 12:40 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 01/11] fftools/graph/graphprint: Fix races > when initializing graphprint Hi Andreas, thanks for v2. > > - Why do you want to remove the ResourceManager AVClass? > > Because I think callers should provide their own logcontext Do we have any precedent cases for this? What would be the parameter type for passing it - AVClass* ? > > It wasn't unused. Now the prefix is gone for log entries in > > decompress_gzip() > > True, this patch is just wrong (in case of decompression errors, > av_log() will treat ResourceManagerContext as a logging context, > although it is no more; this would lead to segfaults if AVDictionary is > already set, i.e. when initializing the second resource). Yes, I had seen it crashing once as well when moving debugger execution to an av_log line during the second execution. All good now! > > Actually, all av_log() calls should include the resman_ctx > > Seems this has been forgotten (well..by me) Thanks for fixing! > > - For the registered_formatters initialization: > > I used to have initialization order issues when I had tried > > with static initialization. That's the reason for those functions > > Probably you've done it differently as it seems to work so far > > What issues? Here's my comment from an earlier review: ---- > > +static const AVTextFormatter *registered_formatters[7+1]; > > maybe use a const here, also I'd be more happy if we had a more > dynamic registration system to avoid the hardcoded bits While trying this, I remembered that I had tried this before already, but it causes trouble with static initialization order. Probably that's the reason why it has been like this before already, I'm not sure? ---- What I had seen: The registered_formatters array was initialized before static initialization of all its members had been done. It happened at a rather early stage, so it is well possible that it is resolved by changes that were made meanwhile. FATE tests are passing, so it's probably fine, now. Here's my full review: v2-0001-fftools-graph-graphprint-Fix-races-when-initializ LGTM, I wasn't aware that av_strtok() is destructive, maybe the doc text should mention it. s param being non-const might give a hint, but it's still a bit unexpected for anybody who doesn't know all the APIs by heart. Now that it's no longer updated, should print_graphs_format be made const? Same for print_graphs_file? Could also be in a future patch, though. v2-0002-fftools-textformat-avtextformat-Separate-mutable- I am aware of the mixed mutability in the section definitions. The general idea of separation and making the section definitions immutable is right of course. Yet, the general goal is to build a versatile API for other use cases, so we should not make changes based on "x is currently used by a only, not by b, so make it local to a". The ability to limit the fields that should be output for each section is an essential feature that should be generally available for all usages, that's why it should rather go in the opposite direction - i.e. from FFprobe (where it's specific atm) to the API. I haven't come to do that yet. We should also hear what Stefano will say about it, as far as I understood he sees it similar, but I might be wrong. v2-0003-fftools-textformat-avtextformat-Avoid-relocations LGTM v2-0004-fftools-resources-resman-Don-t-alloc-ResourceMana LGTM v2-0005-fftools-resources-resman-Use-assert-for-always-fa LGTM v2-0006-fftools-resources-resman-Use-proper-logcontext LGTM, thanks! v2-0007-fftools-textformat-avtextformat-Fix-races-when-in LGTM v2-0008-fftools-ffprobe-Factor-writing-common-side-data-t LGTM v2-0009-fftools-ffprobe-Fix-indentation LGTM v2-0010-fftools-textformat-avtextformat-Move-avtext_print avtext_print_integers() allows to print binary data in a tabular layout and various formats. It is generally useful and not specific to FFprobe's usage. AFAIR, Stefano had seen it the same way. v2-0011-fftools-graph-graphprint-Remove-redundant-avio_fl LGTM In summary v2-0002-fftools-textformat-avtextformat-Separate-mutable- v2-0010-fftools-textformat-avtextformat-Move-avtext_print Should wait for Stefano to comment. All others are good to go. Thanks sw _______________________________________________ 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:[~2025-06-01 21:42 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-06-01 3:27 Andreas Rheinhardt 2025-06-01 4:19 ` softworkz . 2025-06-01 10:39 ` Andreas Rheinhardt 2025-06-01 21:41 ` softworkz . [this message] 2025-06-01 22:07 ` Andreas Rheinhardt 2025-06-01 23:14 ` softworkz . 2025-06-01 11:25 ` 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=DM8P223MB03657F0F1B84247C209D43F7BA63A@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \ --to=softworkz-at-hotmail.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