Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Announcements and Chat > General Discussion

Reply
 
Thread Tools Search this Thread Display Modes
Old 10th December 2024, 13:53   #1  |  Link
jay123210599
Registered User
 
Join Date: Apr 2024
Posts: 326
zscale WEBP Error

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

Code:
[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:
Code:
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:
Code:
ffmpeg -i video.mkv -vf zscale=pin=2:p=2:tin=2:t=2:min=709,format=bgra output.webp
jay123210599 is offline   Reply With Quote
Old 10th December 2024, 13:58   #2  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Oh no, not again!
Z2697 is offline   Reply With Quote
Old 10th December 2024, 14:00   #3  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Quote:
Originally Posted by jay123210599 View Post
By the way, why not use rgb24 instead of gbrp?
Quote:
Originally Posted by poisondeathray View Post
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

Z2697 is offline   Reply With Quote
Old 10th December 2024, 14:27   #4  |  Link
jay123210599
Registered User
 
Join Date: Apr 2024
Posts: 326
Quote:
Originally Posted by Z2697 View Post
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?
jay123210599 is offline   Reply With Quote
Old 10th December 2024, 14:33   #5  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by jay123210599 View Post
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
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 14:45   #6  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Quote:
Originally Posted by poisondeathray View Post
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.

Last edited by Z2697; 10th December 2024 at 14:56.
Z2697 is offline   Reply With Quote
Old 10th December 2024, 15:10   #7  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by Z2697 View Post
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


Quote:
Originally Posted by Z2697 View Post

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 ?

Last edited by poisondeathray; 10th December 2024 at 16:05.
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 15:39   #8  |  Link
jay123210599
Registered User
 
Join Date: Apr 2024
Posts: 326
So should I use APNG instead to avoid rounding errors?
jay123210599 is offline   Reply With Quote
Old 10th December 2024, 15:44   #9  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by jay123210599 View Post
So should I use APNG instead to avoid rounding errors?
The rounding errors being referred to do not pertain to the compression step. APNG, PNG, and webp in lossless mode - all use lossless RGB compression , no additional rounding errors are introduced. ie. If you use the same preprocessing steps, all 3 formats should produce the same results (assuming there are no other display problems like PNG chunks)

The additional rounding errors discussed were from suboptimal YUV to RGB conversions, which can cause slight color and brightness shifts
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 16:33   #10  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Quote:
Originally Posted by poisondeathray View Post
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
I'm not talking about lossless to original RGB, I'm talking about lossless to original YUV which originated from RGB, after the conversion to and from RGB.

The "+2 bits" rule of thumb also applies to "native YUV to RGB", or maybe even worse, I don't know. Since there's no real "native YUV", we just ignore this fact.
Z2697 is offline   Reply With Quote
Old 10th December 2024, 16:55   #11  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by Z2697 View Post
I'm not talking about lossless to original RGB, I'm talking about lossless to original YUV which originated from RGB, after the conversion to and from RGB.

The "+2 bits" rule of thumb also applies to "native YUV to RGB", or maybe even worse, I don't know. Since there's no real "native YUV", we just ignore this fact.

"losslessness" depends on what you define as the "original"

If you consider his source the "original" (regardless of what came before that) 8bit 4:2:0 YUV => RGB => 8bit 4:2:0 YUV is only reversible if you use float RGB, and nearest neighbor up/downsampling . You can't just ignore the out of gamut values, and clipping to 8bit RGB 0 and 255, otherwise it's not "lossless". Many values map to negative RGB, and values greater than 255, which would be clipped, and therefore not lossless

10bit YUV is required for exact 8bit RGB values, also because of the precision. Many 8bit YUV "map" to the same 8bit RGB values
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 16:55   #12  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,290
Quote:
Originally Posted by poisondeathray View Post
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




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 ?
while bilinear scaling is only adding an error of up to 0.25 so 2 bits does this still count when chroma subsample positions are fixed?

and now going to use philosophy...
is chroma scaled by bilinear actually an image?

Quote:
Originally Posted by Z2697 View Post
I'm not talking about lossless to original RGB, I'm talking about lossless to original YUV which originated from RGB, after the conversion to and from RGB.

The "+2 bits" rule of thumb also applies to "native YUV to RGB", or maybe even worse, I don't know. Since there's no real "native YUV", we just ignore this fact.
for a round trip you can do it lossless with an intermediates that is high bit deep.

RGB red 255 0 0 is 62.56 102.34 240 . they don't fit in 10 bit that doesn't mean the rounded version of this in a round trip that is also rounded will not be lossless but the RGB wanted here will never be lossless.
huhn is offline   Reply With Quote
Old 10th December 2024, 17:01   #13  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by huhn View Post
while bilinear scaling is only adding an error of up to 0.25 so 2 bits does this still count when chroma subsample positions are fixed?
You can still measure the error

But for nearest neighbor : Duplicating and discarding the exact samples you just duplicated results in the same thing you started with = lossless . (And this is with powers of 2, such as those used in the chroma sampling context)

Quote:
and now going to use philosophy...
is chroma scaled by bilinear actually an image?
Yes, in the respect that it's just a resampled image
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 17:11   #14  |  Link
jay123210599
Registered User
 
Join Date: Apr 2024
Posts: 326
Quote:
Originally Posted by poisondeathray View Post
The rounding errors being referred to do not pertain to the compression step. APNG, PNG, and webp in lossless mode - all use lossless RGB compression , no additional rounding errors are introduced. ie. If you use the same preprocessing steps, all 3 formats should produce the same results (assuming there are no other display problems like PNG chunks)

The additional rounding errors discussed were from suboptimal YUV to RGB conversions, which can cause slight color and brightness shifts
So the already present rounding errors are inevitable no matter what I do or there aren't any rounding errors at all?
jay123210599 is offline   Reply With Quote
Old 10th December 2024, 17:24   #15  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by jay123210599 View Post
So the already present rounding errors are inevitable no matter what I do or there aren't any rounding errors at all?
Yes , there are expected errors for converting 8bit YUV to 8bit RGB.

8bit YUV to 8bit RGB is a mathematically lossy conversion (going to 16bit RGB is lossy too, just less lossy) - you can never get back the original YUV values. There are rounding, clipping and precision errors, but some of them are expected errors . The point was you want to avoid adding extra errors on top of that, especially the avoidable errors due to poor workflow choices

It doesn't really matter for a viewing format like PNG/webp, because you are viewing on a 8bit RGB or 10bit RGB display anyways . Those are lossy RGB representations of the 8bit YUV data . Even if you viewed your original video source - it's not being displayed as YUV - What you see is a RGB converted representation of the YUV source on the display. So don't worry about it
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 17:38   #16  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Quote:
Originally Posted by poisondeathray View Post
"losslessness" depends on what you define as the "original"

If you consider his source the "original" (regardless of what came before that) 8bit 4:2:0 YUV => RGB => 8bit 4:2:0 YUV is only reversible if you use float RGB, and nearest neighbor up/downsampling . You can't just ignore the out of gamut values, and clipping to 8bit RGB 0 and 255, otherwise it's not "lossless". Many values map to negative RGB, and values greater than 255, which would be clipped, and therefore not lossless

10bit YUV is required for exact 8bit RGB values, also because of the precision. Many 8bit YUV "map" to the same 8bit RGB values
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.
If you accept 8bit RGB to 10bit YUV is "lossless", then this is "lossless" as well. Apart from the distortions introduced by editing and encoding in YUV space (let's not discuss that for a sec).
Z2697 is offline   Reply With Quote
Old 10th December 2024, 17:53   #17  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by Z2697 View Post
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

Quote:
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
poisondeathray is offline   Reply With Quote
Old 10th December 2024, 18:15   #18  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Quote:
Originally Posted by poisondeathray View Post
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?
Z2697 is offline   Reply With Quote
Old 10th December 2024, 18:19   #19  |  Link
Z2697
Registered User
 
Join Date: Aug 2024
Posts: 370
Quote:
Originally Posted by poisondeathray View Post
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?
Z2697 is offline   Reply With Quote
Old 10th December 2024, 18:24   #20  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,600
Quote:
Originally Posted by Z2697 View Post
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]
poisondeathray is offline   Reply With Quote
Reply

Tags
colorspace, colorspace conversion, ffmpeg

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.