Closed birdie-github closed 2 years ago
We'll look into that. Looks like a bug on the encoder, might also be associated with some VVC level constraints, but this will require some more in-depth investigation. Hopefully there'll be a resolution next week.
We'll look into that. Looks like a bug on the encoder, might also be associated with some VVC level constraints, but this will require some more in-depth investigation. Hopefully there'll be a resolution next week.
The H.266 spec must have some constraints I guess, so I don't think it's worth going above and beyond. Unfortunately it's a very long document I've no idea how to read, so would be great if you found it out.
And if there are indeed certain constraints, it's worth adding them to your codebase directly and instead of showing a weird error your could output something like:
Error: the H.266 spec only allows at most X@Y videos. Bailing out.
or something like this.
Thanks!
vvenc
also doesn't show a pretty error message for a e.g. 333x333 source.
Instead would be nice to see something like:
Error: input dimensions must be multiples of 4
(or 8?)
Thanks!
Since VVenC only supports YUV 4:2:0 as input, it requires the input to be a multiple of 2. I don't think VVenC has any special requirements for input size beyond that.
Well, internally the input source has to be a multiple of 8. In case your source is not a multiple of 8, the encoder will perform an automatic padding of the input pictures (expert option --ConformanceWindowMode 1, which is enabled by default in expert and easy app). There are additional expert padding options, if you like to control the padding by yourself, but in that case you should be sure what you are doing.
Using an odd size parameter will fail as explained above, due to the YUV 4:2:0 source format:
vvencapp --size 177x144 Parameter Check Error: Error: picture width is not an integer multiple of the specified chroma subsampling
Concerning your source format 14552x8416, l agree, this should give you a more explanatory error message. But, as explained before, this looks more like a bug or a VVC level constraint. And even if it is a level constraint, this should be checked at the input parameter side and not produce this error message. We will have a look into this issue.
So I debugged your issue, and it seems indeed that the problem is level constraints. We will add more appropriate error message, but for now you could use:
--fps 1
: this will reduce the samples per second, which is irrelevant for still picture encoding either way--profile main_10_still_picture
: there are different limits if you encode still picture profileTodos for us:
--fps 1
and --profile main_10_still_picture
if --frames 1
is set
What are the maximum dimensions for the codec?
I'm trying to compress a very large image, 14552x8416 pixels, and the encoder exits with an error:
The source file was prepared this way:
where
source.bmp
is a simple 24bit RGB file.Would be great if you documented it. Thanks!