From: "softworkz ." <softworkz-at-hotmail.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface Date: Tue, 6 May 2025 10:45:24 +0000 Message-ID: <DM8P223MB0365C190C632F94F183DB9A7BA892@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw) In-Reply-To: <aBjL6IX8UrX6CWD6@phare.normalesup.org> > -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas > George > Sent: Montag, 5. Mai 2025 16:32 > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface > > Stefano Sabatini (HE12025-05-04): > > I don't understand this claim. There is a root, and each section can > > have several subsections, so it is a tree in my view, although we set > > a maximum depth. Where am I wrong? > > Are we looking at the same thing? In ffprobe's output, we have sections > “packets”, “streams”, “format”, etc., and in each section items, but > that does not go deeper. Please look at those graphs to see that your assumptions are inaccurate: https://softworkz.github.io/ffmpeg_output_apis/ffprobe_schema.html https://softworkz.github.io/ffmpeg_output_apis/graph_schema.html One example in plain text: root frames (1) frame (n) frame_tags (n) frame_side_data_list (1) frame_side_data (n) time_codes (1) time_code (n) frame_side_data_components (1) frame_side_data_component (n) frame_side_data_pieces (1) frame_side_data_piece (n) > Making this API generic is not an easy task, but it is doable. We should > not settle for an inferior API just because the person who proposed it > wrote the code before designing it properly and now is in a hurry to get > it applied. Like I said in my previous response already: I'm not intending to rush things in any way. I don't even have a use case for which the API needs to be located in libavutil. Even when it remains to live in fftools for a year or longer, I'm still good with it. You'll have plenty of time for suggesting improvements or submitting an XML writer the way you want it to be, and - given it would be compatible with the AVTextFormat API - the API could use yours instead of the current one. Doors are open for your suggestions, as long as those will fit in to the AVTextFormat API logic or are improving it in a way that the consumption sites don't need to be rewritten (adjustments are surely acceptable). Best regards, 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-05-06 10:45 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-04-22 4:20 softworkz . 2025-04-24 14:47 ` [FFmpeg-devel] On errors, asserts and crashing (was: Shaping the AVTextFormat API Surface) Nicolas George 2025-04-25 13:05 ` softworkz . 2025-04-25 14:04 ` Nicolas George 2025-04-25 14:37 ` softworkz . 2025-04-25 14:41 ` Nicolas George 2025-04-25 14:53 ` softworkz . 2025-04-25 14:43 ` [FFmpeg-devel] On errors, asserts and crashing James Almer 2025-04-25 14:49 ` softworkz . 2025-04-25 16:04 ` Michael Niedermayer 2025-04-24 17:12 ` [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface Nicolas George 2025-04-25 13:24 ` softworkz . 2025-04-25 13:32 ` softworkz . 2025-04-25 14:05 ` Nicolas George 2025-04-25 14:26 ` softworkz . 2025-04-27 10:07 ` Stefano Sabatini 2025-04-29 8:30 ` Nicolas George 2025-04-29 18:07 ` softworkz . 2025-04-30 2:56 ` softworkz . 2025-05-04 15:32 ` Stefano Sabatini 2025-05-04 20:38 ` softworkz . 2025-05-05 14:32 ` Nicolas George 2025-05-06 10:45 ` softworkz . [this message] 2025-05-07 23:18 ` Stefano Sabatini 2025-04-24 18:34 ` Rémi Denis-Courmont 2025-04-25 13:16 ` softworkz . 2025-04-27 10:42 ` Stefano Sabatini 2025-04-27 17:54 ` softworkz . 2025-04-28 22:26 ` Stefano Sabatini 2025-04-28 23:24 ` softworkz . 2025-05-03 8:55 ` softworkz . 2025-05-07 23:30 ` Stefano Sabatini 2025-05-07 23:42 ` softworkz . 2025-05-08 21:26 ` Stefano Sabatini
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=DM8P223MB0365C190C632F94F183DB9A7BA892@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