zscale WEBP Error

[jay123210599]

But when I tried to used zscale when converting a video to lossless animated WEBP, I got this error:

[Parsed_zscale_0 @ 0000020b7458bd80] code 3074: no path between colorspaces
    Last message repeated 25 times
[vf#0:0 @ 0000020b74005240] Error while filtering: Generic error in an external library
[vf#0:0 @ 0000020b74005240] Task finished with error code: -542398533 (Generic error in an external library)
[vf#0:0 @ 0000020b74005240] Terminating thread with return code -542398533 (Generic error in an external library)
[vost#0:0/libwebp_anim @ 0000020b74004700] Could not open encoder before EOF
[vost#0:0/libwebp_anim @ 0000020b74004700] Task finished with error code: -22 (Invalid argument)
[vost#0:0/libwebp_anim @ 0000020b74004700] Terminating thread with return code -22 (Invalid argument)
[out#0/webp @ 0000020b74004380] Nothing was written into output file, because at least one of its streams received no packets.
frame=    0 fps=0.0 q=0.0 Lsize=       0KiB time=N/A bitrate=N/A speed=N/A
Conversion failed!

How do I fix that?

Here is the information for the video:

Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4 frames
Format settings, Slice count             : 4 slices per frame
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 10 s 886 ms
Bit rate mode                            : Variable
Maximum bit rate                         : 40.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Time code of first frame                 : 01:37:05:07
Default                                  : Yes
Forced                                   : No

Here is the command I used:

ffmpeg -i video.mkv -vf zscale=pin=2:p=2:tin=2:t=2:min=709,format=bgra output.webp

[Z2697]

Oh no, not again!

[Z2697]

Originally Posted by jay123210599

By the way, why not use rgb24 instead of gbrp?

Originally Posted by poisondeathray

zscale works with planar formats, gbrp is the pixel format identifier for planar rgb. If you use rgb24, it will go through a different path and introduce rounding errors - the values will be slightly off from expected or proper conversion

[jay123210599]

Originally Posted by Z2697

I replaced bgra with gbrp and now it works. It looks like use bgra as the format was the problem. But will using gbrp have rounding errors?

[poisondeathray]

Originally Posted by jay123210599

I replaced bgra with gbrp and now it works. It looks like use bgra as the format was the problem. But will using gbrp have rounding errors?

Only the expected rounding errors. Not the additional errors on top of the expected ones like default swscale without accurate flags

You expect some accuracy and rounding issues with 8bit YUV to 8bit RGB. This is discussed in other threads in detail. The only way it's completely lossless is if you use RGB float and use nearest neighbor for chroma scaling. This preserves negative RGB values, and values over 1 on a 0 to 1 scale. This can be "reversed" as a lossless round trip so you get the original 8bit YUV data

[Z2697]

Originally Posted by poisondeathray

Only the expected rounding errors. Not the additional errors on top of the expected ones like default swscale without accurate flags

You expect some accuracy and rounding issues with 8bit YUV to 8bit RGB. This is discussed in other threads in detail. The only way it's completely lossless is if you use RGB float and use nearest neighbor for chroma scaling. This preserves negative RGB values, and values over 1 on a 0 to 1 scale. This can be "reversed" as a lossless round trip so you get the original 8bit YUV data

If that YUV originates from RGB (which is the most likely case), the YUV-RGB-YUV conversion is reversible as well... because the "in-between" YUV code values are just not used, but if some editing is done in YUV space, and the encoding, distortion might cause slight error.

I don't think rounding errors disqualify the point of lossless encoding though, I mean of course no rounding error is much more optimal but lossless encoding prevents generational loss and other stuff as well.

[poisondeathray]

Originally Posted by Z2697

If that YUV originates from RGB (which is the most likely case), the YUV-RGB-YUV conversion is reversible as well... because the "in-between" YUV code values are just not used, but if some editing is done in YUV space, and the encoding, distortion might cause slight error.

Not in his case, because the YUV is chroma downsampled 4:2:0. If you started with RGB source before his, it would still be lossy - You can't discard information and be "lossless" . The exception for chroma up/down/up sampling would be if the RGB source was 1 color . Also, the YUV step would need +2 bits to be lossless. If you start from 8bit RGB master source, the YUV step would need to be YUV444P10

Originally Posted by Z2697

I don't think rounding errors disqualify the point of lossless encoding though, I mean of course no rounding error is much more optimal but lossless encoding prevents generational loss and other stuff as well.

Yes, the point was not about lossless compression - it was about the pre processing steps

The encoding itself is lossless, but if the operations used to convert to RGB cause a color shift compared to the expected values, it's incorrect .

=>The incorrect values and color shifts are preserved losslessly

My point was if you're going to jump through the hoops for a lossless workflow, why introduce other avoidable errors and color shifts and preserver them ?

[poisondeathray]

Originally Posted by Z2697

My point is that there's no real native YUV material. The out of gamut, negative and > 1.0 values are just non-existence in the first place when the source is converted from RGB.

Yes, no native YUV material. That's irrelevant

Do you have the same values or not ? That' s one definition of losslessness

You can argue some values "shouldn't be there", but your feelings do not define whether or not something is lossless

If you accept 8bit RGB to 10bit YUV is "lossless", then this is "lossless" as well.

No.

8bit RGB to 10bit YUV can be a lossless conversion if done properly, because you can get back the original 8bit RGB values

But 8bit YUV to 8bit RGB - you cannot get back the original 8bit YUV values, so it's not lossless conversion

The other point you probably missed is many 8bit YUV map to the same 8bit RGB value irrespective of the out of gamut values. The precision is not high enough. 10bit YUV is required for the original, original 8bit RGB source if that was your reference point

[Z2697]

Originally Posted by poisondeathray

The other point you probably missed is many 8bit YUV map to the same 8bit RGB value irrespective of the out of gamut values.

What is out of gamut value in this case?

[poisondeathray]

Originally Posted by Z2697

What is out of gamut value in this case?

Out of gamut errors are the YUV values that map outside of the RGB defined color cube. eg. 8bit YUV value maps to something less than RGB 0 or greater than RGB 255

You can argue that YUV value shouldn't have been there in the first place - and I agree with you - but that has no bearing on whether something is "lossless" or not


The 8bit YUV precision errors are different category than out of gamut . You can have several YUV values that map to the same RGB value which are in gamut , in the range [0-255]

[Z2697]

Originally Posted by poisondeathray

8bit RGB to 10bit YUV can be a lossless conversion if done properly, because you can get back the original 8bit RGB values

So, this implies that the 10 bit YUV (originated from 8 bit RGB) to 8 bit RGB is "lossless" as well.
How does 8 bit YUV (originated from 8 bit RGB, but of course not full 8 bit RGB values are represented) to 8 bit RGB is not "lossless", even when there's less precision in the source?

[poisondeathray]

Originally Posted by Z2697

So, this implies that the 10 bit YUV (originated from 8 bit RGB) to 8 bit RGB is "lossless" as well.

Yes it can be if done properly.

eg. Your point of reference is is 8bit RGB. If you convert to 10bit YUV, you can get back the original 8bit RGB values

8bit RGB => 10bit YUV => 8bit RGB can be lossless if done properly

How does 8 bit YUV (originated from 8 bit RGB, but of course not full 8 bit RGB values are represented) to 8 bit RGB is not "lossless", even when there's less precision in the source?

It' s just math and what you are comparing

If the 8bit YUV is considered the "source" or starting point - after you do a conversion, can you get back the same values or not ?

That's what "lossless" means - you have the same values.

8bit YUV => 8bit RGB is not lossless because you cannot get back the 8bit YUV values



Similarly, all these steps are lossy and not reversible, you cannot get back any of the original values from a preceding step

8bit RGB original, original source => 8bit YUV (already lossy compared to previous step) => 8bit RGB (2 generation lossy steps)

[Z2697]

Originally Posted by poisondeathray

Yes it can be if done properly.

eg. Your point of reference is is 8bit RGB. If you convert to 10bit YUV, you can get back the original 8bit RGB values

8bit RGB => 10bit YUV => 8bit RGB can be lossless if done properly



It' s just math and what you are comparing

If the 8bit YUV is considered the "source" or starting point - after you do a conversion, can you get back the same values or not ?

That's what "lossless" means - you have the same values.

8bit YUV => 8bit RGB is not lossless because you cannot get back the 8bit YUV values



Similarly, all these steps are lossy and not reversible, you cannot get back any of the original values from a preceding step

8bit RGB original, original source => 8bit YUV (already lossy compared to previous step) => 8bit RGB (2 generation lossy steps)

I keep saying my reference point is YUV (originated from RGB, but the loss is done, doesn't matter at all now), and you just keep saying my reference point is RGB.
What can I say.
You have your "if done properly", I have mine. Let's not bother it too much.

[poisondeathray]

Originally Posted by Z2697

I keep saying my reference point is YUV (originated from RGB, but the loss is done, doesn't matter at all now), and you just keep saying my reference point is RGB.

It doesn't matter - because each of those steps is lossy with respect to the one directly before, and the generations before that

ie. 8bit YUV (from a 8bit RGB source) to 8bit RGB is still lossy, when using 8bit YUV as the reference point - for the reasons already mentioned.

If you want definitive proof, you can test with all 16777216 8bit RGB color combinations as a pre starting point (A) - all "out of gamut values" are culled by definition

Make your 8bit YUV444 starting point (B), and convert to 8bit RGB (C) -

There is no way you can get back the YUV444 (B) , (or original RGB colors (A) ), from (C)

You can generate the pattern see this thread , or use ffmpeg allrgb
https://forum.doom9.org/showthread.php?t=183816
https://ffmpeg.org/ffmpeg-filters.ht...02c-yuvtestsrc


For (C) - the attempt to convert back to YUV444P8 to achieve (B) "your" original values, the PSNR is about 86db. It would have been infinity if it was lossless for ffmpeg psnr. Now slightly different methods will give slightly higher or lower, but it's always expected to be lossy (unless you have some weird source with 1 color that just happens to map correctly)

[FranceBB]

Yes but the scenario you're describing has more to do with the fact that you have out of range values than it has to do with RGB in general, but I understand your logic.
One however could therefore argue that scaling YUV to Studio RGB (that is, RGB in limited TV range) is therefore lossy 'cause both of them are limited. In other words:

YUV Limited TV range to Studio RGB limited TV range = lossless
YUV Full PC range to RGB full PC range = lossless
YUV Limited TV range to RGB Full PC Range = lossless as long as the original YUV stays within 0.0-0.7V, as it should.

In general, even when you're receiving a feed from your favourite TV station, letting anything get to out of range values, so above 0.7V (i.e 700 mV) or 235 for those who prefer the 8bit value reference is a sin 'cause all customer's TV are RGB anyway, so they would lose whatever is above 235 as that value is expanded to 255 and you run out of room. One of the things that is generally done is the soft highlights rollback to basically dim down the highlights of the elements going out of range to make them get back within the limited TV range. Even during live events, where you have potentially fast and unpredictable movement compared to interviews, you generally regulate the thing and then you put hardware clipping on the signal in anyway.

This is checked using real time hardware waveform monitors like the ones from Tektronix https://imgur.com/HRLItw3 and is what led me to create VideoTek() in Avisynth https://forum.doom9.org/showthread.php?p=1832846 - https://github.com/FranceBB/VideoTek

[poisondeathray]

Originally Posted by FranceBB

Yes but the scenario you're describing has more to do with the fact that you have out of range values than it has to do with RGB in general, but I understand your logic.

No - it has everything to do with RGB color model, and the relationship with YUV in general, not out of range values. "Legal range YUV/RGB", "full range YUV/RGB" , all combinations are lossy with 8bit conversions

"out of gamut" is a separate topic than "legal range" , "full range" . You can produce out of gamut values, even when you have legal range YUV values

One however could therefore argue that scaling YUV to Studio RGB (that is, RGB in limited TV range) is therefore lossy 'cause both of them are limited. In other words:

YUV Limited TV range to Studio RGB limited TV range = lossless
YUV Full PC range to RGB full PC range = lossless
YUV Limited TV range to RGB Full PC Range = lossless as long as the original YUV stays within 0.0-0.7V, as it should.

These statements are incorrect in 8bit . You can demonstrate that with avisynth or ffmpeg or matlab

Prove it to yourself. Start with that RGB image in the post above and run through these 3 scenarios . Make sure you use YUV444P8 so we avoid discussing subsampling issues for now


Even if you remove out of gamut values - 8bit YUV => 8bit RGB does not have enough precision to map to a specific RGB value - there are multiple YUV values that map to a single RGB value that is within gamut. You end up with +/- 3 errors , and rounding errors. This is one of the contributing reasons behind 8bit "banding" . With 10bit YUV, there is enough precision to map exactly to each 8bit RGB 16777216 values

[huhn]

ycbcr to limited range RGB is lossless for a grey scale.
it is a well known edge case you can ignore it.

it only has Y values the other do not "matter" wrong word but the best i have.
and Y only also exists.

[Z2697]

Originally Posted by poisondeathray

No - it has everything to do with RGB color model, and the relationship with YUV in general, not out of range values. "Legal range YUV/RGB", "full range YUV/RGB" , all combinations are lossy with 8bit conversions

"out of gamut" is a separate topic than "legal range" , "full range" . You can produce out of gamut values, even when you have legal range YUV values



These statements are incorrect in 8bit . You can demonstrate that with avisynth or ffmpeg or matlab

Prove it to yourself. Start with that RGB image in the post above and run through these 3 scenarios . Make sure you use YUV444P8 so we avoid discussing subsampling issues for now


Even if you remove out of gamut values - 8bit YUV => 8bit RGB does not have enough precision to map to a specific RGB value - there are multiple YUV values that map to a single RGB value that is within gamut. You end up with +/- 3 errors , and rounding errors. This is one of the contributing reasons behind 8bit "banding" . With 10bit YUV, there is enough precision to map exactly to each 8bit RGB 16777216 values

The "multiple mapping" problem which causes banding is irrelevant in my argument, I use the result YUV as reference, the banding is a distortion only when you use RGB as reference in this case.

The real problem is rounding. Take 8bit RGB value (210,87,0) as example. When converted to full range 8bit YUV using BT.709 matrix you get (107,70,193), the "floting point" result is (0.419092,-0.225852,0.256818).
When this 8bit YUV value takes a roundtrip, the 8bit RGB value is (209,87,0), the 8bit YUV value is (107,71,193), fp result is (0.418258,-0.225403,0.254858) (which if +0.5*255 is (106.65579,70.022235,192.48624) I don't know why zimg (vapoursynth core.resize) rounds the 8bit value this way, or I'm doing the math wrong, but you get the point, I guess)

There's only a small fraction of this kind of values, most of them in "extreme values" like the Blue being 0 in the example, so if the image does not contain such pixels or some special treatment is done to the image, the 8bit YUV to RGB converion can be lossless. You don't need very special "1 color" image to achieve that.

10bit YUV lossless"ness" is much easier to achieve. But if any postprocessing including encoding is done to the image the lossless"ability" will likely be ruined even for 10bit.

[poisondeathray]

Originally Posted by Z2697

The "multiple mapping" problem which causes banding is irrelevant in my argument, I use the result YUV as reference, the banding is a distortion only when you use RGB as reference in this case.

It's relevant in general for YUV as starting reference - because the converted 8bit RGB values become the "incorrect ones" . The "distortion" means that it's lossy. ie. You can no longer derive the original YUV number , from the converted 8bit RGB - therefore it's a lossy conversion.

The analogy would be like a 3 different YUV pixel "mail delivery addresses" to 3 different RGB pixel "house numbers" 101,102,103 (simplified example, consider just 1 channel for now, not a RGB triplet). Because 8bit YUV precision isn't high enough you end up getting something like RGB 101,101,103 - which is one of the reasons you get 8bit "banding " - multiple YUV values can map to the same RGB number. From that RGB 101,101,103 , there is no way you can go back to 3 different original YUV numbers using standard methods from 2 duplicate, 1 unique RGB pixels (maybe using "AI" or guessing)

The real problem is rounding.

Yes - and the 10bit YUV precision overcomes the rounding issue when coming from an 8bit RGB source ("when done properly" - I have to include that because there are many ways, in many software, where it can go wrong )

There's only a small fraction of this kind of values, most of them in "extreme values" like the Blue being 0 in the example, so if the image does not contain such pixels or some special treatment is done to the image, the 8bit YUV to RGB converion can be lossless. You don't need very special "1 color" image to achieve that.

Starting from RGB is a "best-case" scenario - You're starting with "perfect" numbers that have already culled "bad" RGB values to produce lossless YUV444 values for starting point (B) . This does not happen often in real life

The fact is 99.99% of of type "regular" YUV sources for a YUV starting point will not be lossless for 8bit YUV to 8bit RGB conversion , and have many pixel values that become "lossy", changing from the original values

Because in real life , many more "problematic" YUV values occur naturally :
- chroma resampling . Chroma resampling to generate the YUV 4:2:0 "source" can produce millions of values that were "good" YUV values that will become "bad" YUV values and lossy in the round trip when tested against the YUV 4:2:0 source. (I'm not referring to duplicating and discarding using nearest neighbor for the RGB step, I'm referring to generating different YUV values due to resampling a pre non subsampled source to the 420 source by resampling say, a 4x4 grid of pixels using bicubic ). Most "sources" will be 4:2:0, and that is hardly considered "special treatment"

- lossy compression (most sources you start with are going to have lossy compression), multiple generations. Even if a value is slightly off due to lossy compression in a channel from "good" YUV triplet from a prior lossless conversion, that can cause next RGB conversion step to go out of gamut , which makes it irreversible

Millions of "bad" YUV values occur within "legal range" Y 16-235 CbCr 16-240 that can produce out of gamut RGB and clip (and therefore not reversible, not lossless) . There are fewer that occur in a full range conversion but they still potentially in the number of millions.

10bit YUV lossless"ness" is much easier to achieve. But if any postprocessing including encoding is done to the image the lossless"ability" will likely be ruined even for 10bit.

Yes - lossy encoding, chroma subsampling . Lossy compressed 8bit4:2:0 YUV are very common source materials . Like the OP's. As already mentioned, 8bit YUV to 8bit RGB is lossy. It's only the edge cases that can be lossless. Float RGB is required to be lossless for YUV to RGB - because this preserves the out of gamut, negative RGB, that are required for the lossless round trip

To be clear - 10bit YUV "losslessness" refers to 8bit RGB => 10bit YUV. By definition , all the "illegal" , out of gamut such as negative RGB values are already "culled" from 8bit RGB source. ie. all 8bit RGB 16777216 values can be properly and precisely coded for with 10bit YUV. It should be always lossless for all 8bit RGB values (when done properly )

[Gavino]

Originally Posted by poisondeathray

Millions of "bad" YUV values occur within "legal range" Y 16-235 CbCr 16-240 that can produce out of gamut RGB and clip (and therefore not reversible, not lossless) . There are fewer that occur in a full range conversion but they still potentially in the number of millions.

This was demonstrated dramatically in this (classic?) thread: U and V ranges for valid RGB