Support changing config for avifenc #1450

tongyuantongyu · 2023-06-24T16:28:21Z

Add :u/:update suffix syntax for options that can be changed during encoding. :u suffix instruct the option to only apply to inputs after it.

This feature is mostly useful for progressive encoding. (Which will be implemented in following PR).

tongyuantongyu · 2023-08-19T16:42:47Z

@wantehchang do you think it's time to have this in avifenc?

wantehchang · 2023-08-20T00:34:58Z

Yuan: Thanks for the reminder. We will review this pull request in the next two weeks.

y-guyon

This PR includes refactoring and behavior changes. Consider splitting these into multiple PR or at least multiple commits for a more efficient review process. However to save time I still reviewed most changes in this PR.

y-guyon · 2023-08-21T12:16:24Z

apps/avifenc.c

@@ -135,6 +207,23 @@ static void syntaxLong(void)
    printf("    --imir MODE                       : Add imir property (mirroring). 0=top-to-bottom, 1=left-to-right\n");
    printf("    --clli MaxCLL,MaxPALL             : Add clli property (content light level information).\n");
    printf("    --repetition-count N or infinite  : Number of times an animated image sequence will be repeated. Use 'infinite' for infinite repetitions (Default: infinite)\n");
+    printf("    --                                : Signals the end of options. Everything after this is interpreted as file names.\n");
+    printf("\n");
+    printf("  Frame options apply only to input files appeared after the option:\n");


This is a breaking change. It should be documented in CHANGES.md.

apps/avifenc.c

apps/shared/y4m.h

tests/test_cmd_animation.sh

y-guyon · 2023-08-21T14:32:38Z

tests/test_cmd_animation.sh

@@ -60,14 +61,24 @@ pushd ${TMP_DIR}
  "${ARE_IMAGES_EQUAL}" "${INPUT_Y4M_0}" "${DECODED_FILE}" 0 && exit 1

  # Lossless test.
-  "${AVIFENC}" -s 8 "${INPUT_Y4M_0}" "${INPUT_Y4M_1}" -q 100 -o "${ENCODED_FILE}"
+  "${AVIFENC}" -s 8 -q 100 "${INPUT_Y4M_0}" "${INPUT_Y4M_1}" -o "${ENCODED_FILE}"


I am worried about this change. Will the former order fail or maybe display a warning to the user after this change? Otherwise this is too dangerous to ignore the trailing flags in my opinion.

A solution to this could be "The first occurrence of each frame flag type also applies to all frames appearing before it in the command line". But this is complex so maybe there is a better solution.

The first occurrence of each frame flag type also applies to all frames appearing before it in the command line

This would be too conterintuitive for new users not knowing the history of avifenc.
We may specially apply trailing flags if there's only one input file, but for multiple inputs case, there seems to have no way to be both intuitive and backward compatible. But at least we should print a warning when there are trailing flags. I'll add it.

Luckily we are still at v0.x. @wantehchang I see you are planning v1.0 release in #1509. This change may need to be included in v1.0 as well if we want it, or there probably won't be chance to do it later.

After discussion with @wantehchang we decided to keep backward compatibility as much as possible, and thus this pull request can be merged after the libavif 1.0.0 release.

Instead of positional arguments, @wantehchang suggested frame-specific prefixes similar to the channel-specific prefixes used for the -a flag:

libavif/apps/avifenc.c

Lines 161 to 162 in 5e7a177

printf(" 2. color:<key>=<value> or c:<key>=<value> applies only to the color (YUV) planes.\n");

printf(" 3. alpha:<key>=<value> or a:<key>=<value> applies only to the alpha plane (if present).\n");

Would something like -q 3:75 work? Meaning -q 75 but applied to the frame with index 3 only.

This would in theory work, but will make the command line really messy and complicated to parse:

I'd still place them right before target input so I don't need to count to understand what it does - but I still need to count when writing commands.

The parsing have to be two-pass.

Is "frame with index 3" "output frame index 3" or "input file index 3"? I don't have clear preference, but in case we end up needing both, it will be even more complicated than the --from-index approach I wrote before.

I'd prefer "3" means starting from "3" if we going through this way, so it maps precisely to a programmatic change to one of avifEncoder field.

However, now for the most common single input case, trailing options still have effect; we can also treat the trailing options as applying to the first input for multiple input case. I would say it's a really strange expectation, if someone is putting options in between inputs and expect it to apply to all inputs - even if avifenc actually works in this way.

Thank you for the detailed analysis.

I'd still place them right before target input so I don't need to count to understand what it does - but I still need to count when writing commands.

-q next:75 syntax is fine with me, next to -q 3:75 syntax (for y4m input).

The parsing have to be two-pass.

I would say that it matters less than backward compatibility and user friendliness, unless it makes the code overly complex.

Is "frame with index 3" "output frame index 3" or "input file index 3"? I don't have clear preference, but in case we end up needing both, it will be even more complicated than the --from-index approach I wrote before.

I would go with "output frame index 3".

I'd prefer "3" means starting from "3" if we going through this way, so it maps precisely to a programmatic change to one of avifEncoder field.

-q 3+:75 syntax is fine with me (or something similar to signal that frames >=3 are targeted). It can coexist with -q 3:75 syntax if the latter is useful.

However, now for the most common single input case, trailing options still have effect; we can also treat the trailing options as applying to the first input for multiple input case. I would say it's a really strange expectation, if someone is putting options in between inputs and expect it to apply to all inputs - even if avifenc actually works in this way.

What about this precedence order, for each frame:

Apply the right-most frame-specific flag that targets at least this frame.

If none, apply the right-most global flag.

If none, apply default value.

Example: frame 3 will have final q75 for flags -q 3:73 -q 3+:74 -q 2+:75 -q 76

The most important part is keeping the current behavior for the currently possible ordered flag combinations. To prove that, it would be good to keep existing sh tests as is in this PR (lines can be added to them of course).

@vigneshvg suggested using lists, for example -q 73,74,75 would set quality to 73 for the first frame, to 74 for the second frame and to 75 for all remaining frames.

I guess this only works if the delimiter , is not already used in a frame-specific flag. I do not see any in this PR, besides --scaling-mode H[,V] that was reduced to --scaling-mode H and removed, and -a,--advanced KEY[=VALUE] maybe. Does anyone know if a codec uses , in VALUE as of today or maybe in the future?

I'd still place them right before target input so I don't need to count to understand what it does

This comment was related to -q 3:75 but it is relevant here. How important is it to keep settings flags close to their corresponding input file path? How important is it to not have to count output frames? For progressive, it was assumed that the number of frames/layers was small enough to not pay attention to these constraints.

Let me know when this PR is ready for review.

using lists, for example -q 73,74,75

That wants options have "set current" semantic, but we're sort of locked to "update" semantic:

There's the --advanced option, which in general we can't (or don't know how to) unset. Set for current frame means we need to unset it (revert to default) for the next frame, but we don't know what's the default so we can't do it. Therefore for --advanced we are restricted to do "update", and we'd better be consistent and make every option do "update" then.

I had noticed this restriction while adding the support for the library, but forgot the exact reason why we'd do "update" for the command as well, so I was talking about being consistent with using library.

I guess this only works if the delimiter , is not already used in a frame-specific flag.

Not likely to happen, but if someone decide to use comma in their filename: --advanced film-grain-table=file,name.tbl (maybe with a more reasonable name).

How important is it to keep settings flags close to their corresponding input file path? How important is it to not have to count output frames?

It's more about being able to copypaste / reusing part of the options.

Say you come up with some adaptive logic to generate progressive images:

For all images we have a quick preview layer and a full layer.

If the image is large, insert one more layer in between.

With the current approach, you can have a command segment for each layer, and just join the parts of layers that you decide to have. With explicit index or comma/somewhat separated list, you can't to this and have to assemble whole command for each case separately.

Also during experiment, that will need more modifications / more scattered modifications to the command to add / remove layers (that is not the last one, which is the usual case).

Let me know when this PR is ready for review.

Oh It's ready now. Sorry for this.

It's more about being able to copypaste / reusing part of the options.

Say you come up with some adaptive logic to generate progressive images:

For all images we have a quick preview layer and a full layer.

If the image is large, insert one more layer in between.

With the current approach, you can have a command segment for each layer, and just join the parts of layers that you decide to have. With explicit index or comma/somewhat separated list, you can't to this and have to assemble whole command for each case separately.

In this case i don't think there is a big difference between the "list" syntax and a "positional" syntax. Either way you have to assemble the arguments and combine them into one string. Whether you assemble them as "-q 1,2,3 file1 file2 file3" or "-q 1 file1 -q 2 file2 -q 3 file3" does not really matter.

Also during experiment, that will need more modifications / more scattered modifications to the command to add / remove layers (that is not the last one, which is the usual case).

For the progressive images case, since the number of inputs is limited (if i understand correctly, there can only be a maximum of 4 inputs for 4 layers), i really think the list syntax is the simplest way to go rather than introducing positional arguments and creating backwards incompatibility for the more general use-case (single layer non-progressive avif images).

I guess this only works if the delimiter , is not already used in a frame-specific flag.

I am not sure what you mean by a "frame-specific flag", but we already use comma as a delimiter for --crop, --clap and --pasp flags.

Also, the only other positional argument that i see in avifenc is the --duration flag which can be specified multiple times when creating animated AVIF images. The same flag can be repeated multiple times and it applies to all the following frames unless a new value is specified with another --duration flag.

We can consider doing the same thing with -q as well. But that still introduces backwards incompatibility for the wider use-case. So i am not in favor of it unless others feel strongly so.

"-q 1 file1 -q 2 file2 -q 3 file3"

introducing positional arguments and creating backwards incompatibility for the more general use-case (single layer non-progressive avif images).

But that still introduces backwards incompatibility for the wider use-case.

"positional" behavior is enabled with the :u (or :update) suffix on the flag, so there's no compatibility issue now. That means -q:u 1 file1 -q:u 2 file2 -q:u 3 file3. -q 1 file1 -q 2 file2 -q 3 file3 would behave exactly the same as the current: only -q 3 is effective. (This PR add a warning message in this case).

In this case i don't think there is a big difference between the "list" syntax and a "positional" syntax.

Let's consider some cases:

With "positional" syntax, tweak each layer separately is easy:

LAYER1="-q:u 50 --scaling-mode:u 1/8 $INPUT_FILE" LAYER2="-q:u 30 --scaling-mode:u 1/2 $INPUT_FILE" LAYER3="-q:u 80 --scaling-mode:u 1 $INPUT_FILE" if [ $INPUT_WIDTH -gt 1024 ]; do avifenc -j 8 $LAYER1 $LAYER2 $LAYER3 -o $OUTPUT_FILE else avifenc -j 8 $LAYER1 $LAYER3 -o $OUTPUT_FILE fi

With "list" syntax, you have to spell (and modify) some option values twice:

if [ $INPUT_WIDTH -gt 1024 ]; do avifenc -j 8 -q 50,30,80 --scaling-mode 1/8,1/2,1 $INPUT_FILE $INPUT_FILE $INPUT_FILE -o $OUTPUT_FILE else avifenc -j 8 -q 50,80 --scaling-mode 1/8,1 $INPUT_FILE $INPUT_FILE -o $OUTPUT_FILE fi

Otherwise you need to make 3 variables for each option, or 6 in total for this case.

And there's also boolean flag:

# Don't tile for the 1/8 size first layer avifenc --some-global-options \ -q:u 50 --scaling-mode:u 1/8 input.png \ -q:u 80 --scaling-mode:u 1 --autotiling:u input.png \ -o output.avif

For list syntax, that'll need --autotiling false,true. (or --no-autotiling,autotiling?)

And for --advanced, list syntax can be confusing:

# Looks like setting two options at once, # but is actually setting denoise-noise-level=50 at first input, and c:sharpness=7 at second. avifenc -a denoise-noise-level=50,sharpness=7 input.png input.png output.avif

Whereas in positional syntax, it's always clear:

avifenc --some-global-options \ -a denoise-noise-level=50 input.png \ -a:update sharpness=7 input.png \ output.avif

tests/test_cmd_progressive.sh

tongyuantongyu

I'm still working on the split, and I'll update CHANGES.md after the PR is in good shape.

apps/avifenc.c

tongyuantongyu · 2023-08-22T16:43:53Z

tests/test_cmd_animation.sh

@@ -60,14 +61,24 @@ pushd ${TMP_DIR}
  "${ARE_IMAGES_EQUAL}" "${INPUT_Y4M_0}" "${DECODED_FILE}" 0 && exit 1

  # Lossless test.
-  "${AVIFENC}" -s 8 "${INPUT_Y4M_0}" "${INPUT_Y4M_1}" -q 100 -o "${ENCODED_FILE}"
+  "${AVIFENC}" -s 8 -q 100 "${INPUT_Y4M_0}" "${INPUT_Y4M_1}" -o "${ENCODED_FILE}"


The first occurrence of each frame flag type also applies to all frames appearing before it in the command line

This would be too conterintuitive for new users not knowing the history of avifenc.
We may specially apply trailing flags if there's only one input file, but for multiple inputs case, there seems to have no way to be both intuitive and backward compatible. But at least we should print a warning when there are trailing flags. I'll add it.

Luckily we are still at v0.x. @wantehchang I see you are planning v1.0 release in #1509. This change may need to be included in v1.0 as well if we want it, or there probably won't be chance to do it later.

It indeed "applies only to input files appearing after the option".

tongyuantongyu

Still WIP.

apps/avifenc.c

tongyuantongyu · 2023-08-25T16:13:27Z

tests/test_cmd_animation.sh

@@ -60,14 +61,24 @@ pushd ${TMP_DIR}
  "${ARE_IMAGES_EQUAL}" "${INPUT_Y4M_0}" "${DECODED_FILE}" 0 && exit 1

  # Lossless test.
-  "${AVIFENC}" -s 8 "${INPUT_Y4M_0}" "${INPUT_Y4M_1}" -q 100 -o "${ENCODED_FILE}"
+  "${AVIFENC}" -s 8 -q 100 "${INPUT_Y4M_0}" "${INPUT_Y4M_1}" -o "${ENCODED_FILE}"


This would in theory work, but will make the command line really messy and complicated to parse:

I'd still place them right before target input so I don't need to count to understand what it does - but I still need to count when writing commands.

The parsing have to be two-pass.

Is "frame with index 3" "output frame index 3" or "input file index 3"? I don't have clear preference, but in case we end up needing both, it will be even more complicated than the --from-index approach I wrote before.

I'd prefer "3" means starting from "3" if we going through this way, so it maps precisely to a programmatic change to one of avifEncoder field.

However, now for the most common single input case, trailing options still have effect; we can also treat the trailing options as applying to the first input for multiple input case. I would say it's a really strange expectation, if someone is putting options in between inputs and expect it to apply to all inputs - even if avifenc actually works in this way.

apps/avifenc.c

y-guyon

Getting there!

tests/test_cmd.sh

apps/avifenc.c

y-guyon · 2023-09-01T14:42:06Z

apps/avifenc.c

+    printf("    --                                : Signals the end of options. Everything after this is interpreted as file names.\n");
+    printf("\n");
+    printf("  The following options can optionally have a :u (or :update) suffix like -q:u, to apply only to input files appearing after the option:\n");
+    printf("    -q,--qcolor Q                     : Set quality for color (%d-%d, where %d is lossless)\n",


I am wondering if it should be -q[:u],--qcolor[:update] Q. It is definitely heavier, but I would not be surprised if most users missed the sentence above without a reminder in each option syntax description.

A clearer but lengthy alternative would be another line such as

printf(" -q:u,--qcolor:update Q : Same as -q Q but only applies to input files appearing after the option\n");

for every frame-specific options.

What do you think? We can also consider :u to be so niche that more than a sentence is not worth it.

We all accept :u will mostly be used for progressive AVIF encoding. Progressive in AVIF is quite different from other formats and what users familiar with, so it well deserves an "AVIF Progressive" Wiki page, and we can have the :u explained in detail there.

apps/avifenc.c

y-guyon · 2023-09-01T16:30:39Z

apps/avifenc.c

+
+        if (fileSettings->tileColsLog2.set || fileSettings->tileRowsLog2.set) {
+            // If this file has manual tile config set, disable autotiling;
+            fileSettings->autoTiling = boolSettingsEntryOf(AVIF_FALSE);


This is already handled as an error at line 1856

This is solving a rather weird situation if someone was using autotiling for the first input and decided to switch to manual tiling later.

Please fix. Unless I missed something, using --autotiling will set fileSettings->tileRowsLog2 at line 1873, so the condition (fileSettings->tileColsLog2.set || fileSettings->tileRowsLog2.set) at line 1910 is true, so fileSettings->autoTiling is set to boolSettingsEntryOf(AVIF_FALSE).

Maybe there should be some test_cmd_autotiling.sh in another PR.

apps/avifenc.c

y-guyon · 2023-09-01T16:34:28Z

apps/avifenc.c

+                fileSettings->autoTiling = boolSettingsEntryOf(AVIF_FALSE);
+            }
+            if (!fileSettings->tileRowsLog2.set) {
+                fileSettings->tileRowsLog2 = intSettingsEntryOf(0);


pendingSettings is memset() to 0 so this should be unnecessary?

Yes this is more for a peace of mind that later code reading settings of first input won't see the entry's set field is AVIF_FALSE. It may appears confusing during debugging.

apps/avifenc.c

# Conflicts: # apps/avifenc.c

y-guyon

This looks good overall, thanks for your patience.

apps/avifenc.c

y-guyon · 2023-09-04T15:11:44Z

apps/avifenc.c

+
+        if (fileSettings->tileColsLog2.set || fileSettings->tileRowsLog2.set) {
+            // If this file has manual tile config set, disable autotiling;
+            fileSettings->autoTiling = boolSettingsEntryOf(AVIF_FALSE);


Please fix. Unless I missed something, using --autotiling will set fileSettings->tileRowsLog2 at line 1873, so the condition (fileSettings->tileColsLog2.set || fileSettings->tileRowsLog2.set) at line 1910 is true, so fileSettings->autoTiling is set to boolSettingsEntryOf(AVIF_FALSE).

Maybe there should be some test_cmd_autotiling.sh in another PR.

y-guyon · 2023-09-04T15:26:16Z

apps/avifenc.c

+                returnCode = 1;
+                goto cleanup;
+            }
+            // At here this entry can only be set by command line, so its value have to be AVIF_TRUE.


I had a hard time understanding this sentence, maybe make it extra verbose?

assert(fileSettings->autoTiling.value); // There is no --noautotiling flag. // Disable manual tiling (possibly set by previous input).

Put checks on tiling paramters together (should be from the beginning but was somewhat missed), and added some comments. Hope this explains it better.

In general this (switching between auto and manual tiling during encoding) should be a very rare case.

tongyuantongyu

Just realized replies from last round of review was still in pending state. @y-guyon sorry for the confusion.

tongyuantongyu · 2023-09-02T06:40:04Z

apps/avifenc.c

+    printf("    --                                : Signals the end of options. Everything after this is interpreted as file names.\n");
+    printf("\n");
+    printf("  The following options can optionally have a :u (or :update) suffix like -q:u, to apply only to input files appearing after the option:\n");
+    printf("    -q,--qcolor Q                     : Set quality for color (%d-%d, where %d is lossless)\n",


We all accept :u will mostly be used for progressive AVIF encoding. Progressive in AVIF is quite different from other formats and what users familiar with, so it well deserves an "AVIF Progressive" Wiki page, and we can have the :u explained in detail there.

tongyuantongyu · 2023-09-02T06:47:30Z

apps/avifenc.c

+
+static avifBool strpre(const char * str, const char * prefix)
+{
+    return strncmp(str, prefix, strlen(prefix)) == 0;


The third parameter is the "maximum number of characters to compare", and "Characters following the null character are not compared": https://en.cppreference.com/w/c/string/byte/strncmp, so this should be fine.

tests/test_cmd.sh

apps/avifenc.c

tongyuantongyu · 2023-09-02T08:01:11Z

apps/avifenc.c

+
+        if (fileSettings->tileColsLog2.set || fileSettings->tileRowsLog2.set) {
+            // If this file has manual tile config set, disable autotiling;
+            fileSettings->autoTiling = boolSettingsEntryOf(AVIF_FALSE);


This is solving a rather weird situation if someone was using autotiling for the first input and decided to switch to manual tiling later.

tongyuantongyu · 2023-09-02T08:12:40Z

apps/avifenc.c

+                fileSettings->autoTiling = boolSettingsEntryOf(AVIF_FALSE);
+            }
+            if (!fileSettings->tileRowsLog2.set) {
+                fileSettings->tileRowsLog2 = intSettingsEntryOf(0);


Yes this is more for a peace of mind that later code reading settings of first input won't see the entry's set field is AVIF_FALSE. It may appears confusing during debugging.

apps/avifenc.c

tongyuantongyu · 2023-09-05T14:03:00Z

apps/avifenc.c

+                returnCode = 1;
+                goto cleanup;
+            }
+            // At here this entry can only be set by command line, so its value have to be AVIF_TRUE.


Put checks on tiling paramters together (should be from the beginning but was somewhat missed), and added some comments. Hope this explains it better.

In general this (switching between auto and manual tiling during encoding) should be a very rare case.

y-guyon

I forgot: could you add an entry to CHANGELOG.md? The following should be enough:

### Added
...
+* Add avifenc flag suffixes ":update" and ":u". Quality-relative,
+  tiling-relative and codec-specific flags can now be positional, relative to
+  input files.

tongyuantongyu force-pushed the avifenc_change_config branch from ad4a24f to cfc268c Compare August 19, 2023 14:19

Support changing config for avifenc

e9aeb93

tongyuantongyu force-pushed the avifenc_change_config branch from cfc268c to e9aeb93 Compare August 19, 2023 14:27

tongyuantongyu mentioned this pull request Aug 20, 2023

Support Progressive AVIF GoogleChromeLabs/squoosh#1377

Open

y-guyon reviewed Aug 21, 2023

View reviewed changes

tongyuantongyu commented Aug 22, 2023

View reviewed changes

Remove progressive related code, handle trailing options

f20cea5

tongyuantongyu force-pushed the avifenc_change_config branch from 33a1d35 to f20cea5 Compare August 25, 2023 15:31

tongyuantongyu added 5 commits August 25, 2023 23:41

Move -- to frame options

3edfa80

It indeed "applies only to input files appearing after the option".

Fix some assertions

b7ef63f

Fix typo in assertion

33e709e

Sync with main

9f5e4ac

Fix command line test

193c73c

tongyuantongyu force-pushed the avifenc_change_config branch from 03a4991 to 193c73c Compare August 25, 2023 16:49

Correct test

010944d

tongyuantongyu force-pushed the avifenc_change_config branch from 2457f52 to 010944d Compare August 25, 2023 16:57

Fix file setting handling

cf66135

tongyuantongyu force-pushed the avifenc_change_config branch from 9b44f40 to cf66135 Compare August 25, 2023 17:55

tongyuantongyu commented Aug 25, 2023

View reviewed changes

Clean up frame settings verify

37b75f2

tongyuantongyu force-pushed the avifenc_change_config branch from 63a67b7 to 37b75f2 Compare August 26, 2023 03:04

Remove macro usage

a95748f

tongyuantongyu force-pushed the avifenc_change_config branch from 0ace52d to 47d3365 Compare August 29, 2023 15:16

Do change only with suffixed flags

fe34476

tongyuantongyu force-pushed the avifenc_change_config branch from 47d3365 to fe34476 Compare August 29, 2023 15:27

Fix progressive

4fb8314

tongyuantongyu requested a review from y-guyon August 31, 2023 17:21

y-guyon requested changes Sep 1, 2023

View reviewed changes

Review changes

56a9101

tongyuantongyu force-pushed the avifenc_change_config branch from 87c2a86 to 56a9101 Compare September 2, 2023 07:37

tongyuantongyu added 2 commits September 2, 2023 15:40

Merge remote-tracking branch 'upstream/main' into avifenc_change_config

8b39286

# Conflicts: # apps/avifenc.c

Review changes 2

750350e

tongyuantongyu requested a review from y-guyon September 4, 2023 14:05

y-guyon requested changes Sep 4, 2023

View reviewed changes

Review changes 3

0b5652e

tongyuantongyu force-pushed the avifenc_change_config branch from beb5c1a to 0b5652e Compare September 5, 2023 14:04

tongyuantongyu commented Sep 5, 2023

View reviewed changes

tongyuantongyu requested a review from y-guyon September 5, 2023 14:15

y-guyon approved these changes Sep 5, 2023

View reviewed changes

y-guyon reviewed Sep 5, 2023

View reviewed changes

Add changelog entry

96d5a1c

y-guyon approved these changes Sep 5, 2023

View reviewed changes

y-guyon merged commit 4efa658 into AOMediaCodec:main Sep 5, 2023
14 checks passed

tongyuantongyu deleted the avifenc_change_config branch September 13, 2023 12:34

	printf(" 2. color:<key>=<value> or c:<key>=<value> applies only to the color (YUV) planes.\n");
	printf(" 3. alpha:<key>=<value> or a:<key>=<value> applies only to the alpha plane (if present).\n");

Support changing config for avifenc #1450

Support changing config for avifenc #1450

Conversation

tongyuantongyu commented Jun 24, 2023 • edited Loading

tongyuantongyu commented Aug 19, 2023

wantehchang commented Aug 20, 2023

y-guyon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tongyuantongyu Aug 22, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tongyuantongyu left a comment

Choose a reason for hiding this comment

tongyuantongyu Aug 22, 2023 • edited Loading

Choose a reason for hiding this comment

tongyuantongyu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

y-guyon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

y-guyon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tongyuantongyu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

y-guyon left a comment

Choose a reason for hiding this comment

tongyuantongyu commented Jun 24, 2023 •

edited

Loading

tongyuantongyu Aug 22, 2023 •

edited

Loading

tongyuantongyu Aug 22, 2023 •

edited

Loading