Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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: Fri, 25 Apr 2025 13:24:27 +0000
Message-ID: <DM8P223MB0365671B6855905ADDCFBC60BA842@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <aApw6eiupyMBT5mm@phare.normalesup.org>



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Donnerstag, 24. April 2025 19:12
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface
> 
> softworkz . (HE12025-04-22):
> > AVTextFormatter Implementations
> >
> > - print_section_header
> > - print_section_footer
> > - print_integer
> > - print_string
> 
> > TextFormat API
> >
> > - avtext_context_open
> > - avtext_context_close
> > - avtext_print_section_header
> > - avtext_print_section_footer
> 
> You are ignoring one of the main reasons I gave: this API is far from
> acceptable as is in libavutil because it is way too specific to
> ffprobe.

Now it rather seems that you are ignoring that I have explicitly 
acknowledged that, by saying that in this form, it is not yet ready 
for becoming a public API in avutil, so we are kind of on the same
page in this regard, albeit you seem to have some more radical changes
in mind than I do, but that's fine - let's talk about it!


> ffprobe has a concept of sections, and no more. XML does not have a
> concept of sections. JSON does not have a concept of sections. CSV
> does
> not have a concept of sections. Other parts of FFmpeg
> that could benefit from it do not, or they may have subsection,
> subsubsections, etc. Applications that may use this API even more so.

Sure, neither XML, nor JSON nor YML formats have concepts which are
the same like the sections of the text formatting APIs.

But right now, the sections-concept already maps "more-or-less" 


> 
> The proper way to go at it involves two steps. These steps might
> overlap, but not by much. The first one is rather easy but long. The
> second one can be quick but it is much harder.
> 
> 
> The first step is adding each format into libavutil separately, with
> distinct APIs tailored for the specificities of each format. The APIs
> should run parallel whenever possible, i.e. use similar names and
> prototypes for things that make sense in multiple contexts. But other
> parts will be completely unique to certain formats.
> 
> So:
> 
> av_json_enc_…(): adding objects (dictionaries), arrays, strings,
> numbers,
> booleans, null values; controlling the indentation, the kind of
> quotes,
> the encoding.
> 
> av_xml_enc_…(): similar, but: no concept of numbers, booleans, null;
> and: control over attributes / nested elements, CDATA sections,
> comments.
> 
> av_csv_enc_…()…
> 
> For each API, the parts of ffmpeg already do the same should be
> converted to use it. That means the ffprobe writers of course, but not
> only. If the XML writing code is not usable by dashenc, movenc,
> smoothstreamingenc, vf_signature, ttmlenc, etc., back to the design
> step.
> 
> We might skip that for the formats that are entirely invented here. Or
> some of them.
> 
> 
> The second step is designing a common interface for all the formats.
> That means finding an almost-common denominator to all the formats,
> finding a way to express it even in formats that are not powerful
> enough, but also finding ways to tweak the output when the format is
> more powerful.
> 
> This is hard. I have some ideas on what the common API needs to look
> like to encompass XML and JSON, and I think that with those two done
> the
> others could be made to work, bit it is not as clear in my mind as
> other
> plans I have.
> 
> Anyway, the first step is already enough work to occupy somebody for
> some time.
> 
> 
> Also: these APIs can end up being used by things like the showinfo
> filters, and called once per frame. That means they must be fast, and
> in
> particular they should not need dynamic allocations as long as the
> objects are small.
> 
> --
>   Nicolas George
> _______________________________________________
> 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".

  reply	other threads:[~2025-04-25 13:24 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 . [this message]
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 .
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=DM8P223MB0365671B6855905ADDCFBC60BA842@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