Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Thilo Borgmann <thilo.borgmann@mail.de>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
Date: Wed, 7 Sep 2022 18:05:28 +0200
Message-ID: <4ab779bb-12de-ea11-3ad8-e4d4aecf5baa@mail.de> (raw)
In-Reply-To: <YwN254KiPyYuVLua@phare.normalesup.org>

Am 22.08.22 um 14:30 schrieb Nicolas George:
> Thilo Borgman (12022-08-20):
>> My two cents about it that the a=b:c=d syntax from AVDict is at least
>> known and used in filters already.
>> The function style a(b,c,d) thing from SVG would be completely new.
>> Instead of the AVDict overhead, it adds a simplistic parser overhead.
>> Also, maybe I'm just unaware, these style of options appears not to be
>> often used in the command line world.
> 
> These are good points. On the other hand:

> - The "a=b:c=d" syntax needs documentation and is misleading with regard
>    the order and interaction of suboptions.

Yes needs documentation. I don't see a misleading point in terms of the syntax, just in the mathematical sense - which gets resolved by documenting it.
Syntax-wise, it aligns more to the dont-care order of options to filters (where this syntax is taken from). The only two exceptions are -vf / -filter_complex where the order is relevant. All other options to filters are not respecting order, AFAICT and this would be a new exception to respect the order of a=b:c=d options.


> - The SVG syntax is more powerful, it allows to compose several
>    transforms.

Then we'd have to do two things, add a completely new syntax (which comes with new overhead) and a new scheme of math and order-respecting composition of the final matrix, which can then be many many simple transformations (which in our use case will rarely be needed). Where instead we would reuse known syntax and could get away with the relatively simple decomposition into three sequentially applied filters.

However, I can see that our optimal solution should actually involve a new filter that applies pixel disposition by a 3x3 matrix (which we don't have yet, do we?) and an order respecting syntax (of either kind, though even more overhead with SVG syntax) so that we can skip matrix decomposition and apply just one (hopefully efficient) filter for any transformation that comes via input or cmd line. That would be much more work to ask for IMHO and I'm not a total fan for that just fixing #8329, #6370.

I don't want to override your opinion just because others argued to be happy with a (technically better) version of the proposed. Give me more reason and/or a matrix transform filter and my internal barrier (and real-world limitations) to go that full length in one step might drop. Until then I'll work on v3 which has to be done either way.

Thanks!
-Thilo
_______________________________________________
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:[~2022-09-07 16:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15 19:58 [FFmpeg-devel] [PATCH v2 1/4] fftools: Add support for dictionary options Thilo Borgmann
2022-08-15 20:02 ` [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option Thilo Borgmann
2022-08-16  4:03   ` Gyan Doshi
2022-08-16 14:10   ` Anton Khirnov
2022-08-16 18:48     ` Thilo Borgmann
2022-08-17  8:18       ` Anton Khirnov
2022-08-17  8:50         ` Gyan Doshi
2022-08-17  8:59           ` Nicolas George
2022-08-17  9:05           ` Anton Khirnov
2022-08-17 10:53             ` Gyan Doshi
2022-08-17 12:25               ` Anton Khirnov
2022-08-18 10:58                 ` Gyan Doshi
2022-08-20 13:32                   ` Thilo Borgmann
2022-08-20 13:39                     ` Nicolas George
2022-08-20 13:48                       ` Thilo Borgmann
2022-08-22 12:30                         ` Nicolas George
2022-09-07 16:05                           ` Thilo Borgmann [this message]
2022-08-18  7:11           ` Anton Khirnov
2022-08-17  6:26   ` Marton Balint
2022-08-15 20:02 ` [FFmpeg-devel] [PATCH v2 3/4] ffmpeg: Deprecate display rotation override with a metadata key Thilo Borgmann
2022-08-15 20:02 ` [FFmpeg-devel] [PATCH v2 4/4] ffmpeg: Allow printing of option arguments in help output Thilo Borgmann

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=4ab779bb-12de-ea11-3ad8-e4d4aecf5baa@mail.de \
    --to=thilo.borgmann@mail.de \
    --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