Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface
Date: Tue, 29 Apr 2025 10:30:55 +0200
Message-ID: <aBCOPyA3Bt1aFnbj@phare.normalesup.org> (raw)
In-Reply-To: <aA4B0eruJJhLzfpq@mariano>

Stefano Sabatini (HE12025-04-27):
> Elaborating on this. ffprobe/textformat is based on a notion of
> hierarchical tree-like data

No, this is not true. FFprobe and all its supporting code is based on
one level of hierarchy. Just one level, not a real hierarchical
structure.

> Considering this, there is probably no need to extend the API to cover
> each possible format full semantics - this at least it is my view.

If we add XML-writing code in libavutil, it must be usable for all the
places we are already producing XML. Otherwise it does not make sense.

> As I wrote, this was not the purpose of the ffprobe formats in the
> first place. MOV/DASH requires a specific use of an XML encoder. In
> theory it might be done using the textformat API in the current form,
> but it would be probably pretty awkward. We might want to factorize a
> few generic utilities (e.g. escaping) to avoid code duplication
> though.

You are going at it backwards.

The goal is not to cram this text writers API forcefully into libavutil
and then see if it might serve other purposes, which is what softworkz
is doing.

The API must be able to handle all our use cases from the start. Until
then, it goes back to the design board.

> It might be if we want to make this a generic tool for library users,
> and for purposes outside of the scope for which it was designed. But I
> don't think this should be a real blocker - and we might even keep the
> API private to enable libav* cross-librariers but not
> external-libraries usage.

I can concede making a generic API for external users is not blocking.
Reluctantly.

But I will not budge on internal uses: this API must serve all our
current use cases or it stay outside the libraries.

Regards,

-- 
  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".

  reply	other threads:[~2025-04-29  8:31 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 [this message]
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=aBCOPyA3Bt1aFnbj@phare.normalesup.org \
    --to=george@nsup.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