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".
next prev parent 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