[FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option

Thilo Borgmann thilo.borgmann at mail.de
Wed Sep 7 19:05:28 EEST 2022


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


More information about the ffmpeg-devel mailing list