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. |
![]() |
#1 | Link |
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! 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 Code:
ffmpeg -i video.mkv -vf zscale=pin=2:p=2:tin=2:t=2:min=709,format=bgra output.webp |
![]() |
![]() |
![]() |
#3 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
![]() |
|
![]() |
![]() |
![]() |
#5 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,600
|
Quote:
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 |
|
![]() |
![]() |
![]() |
#6 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
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. |
|
![]() |
![]() |
![]() |
#7 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,600
|
Quote:
Quote:
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. |
||
![]() |
![]() |
![]() |
#9 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,600
|
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 |
![]() |
![]() |
![]() |
#10 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
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. |
|
![]() |
![]() |
![]() |
#11 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,600
|
Quote:
"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 |
|
![]() |
![]() |
![]() |
#12 | Link | ||
Registered User
Join Date: Oct 2012
Posts: 8,290
|
Quote:
and now going to use philosophy... is chroma scaled by bilinear actually an image? Quote:
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. |
||
![]() |
![]() |
![]() |
#13 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,600
|
Quote:
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:
|
||
![]() |
![]() |
![]() |
#14 | Link | |
Registered User
Join Date: Apr 2024
Posts: 326
|
Quote:
|
|
![]() |
![]() |
![]() |
#15 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,600
|
Quote:
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 |
|
![]() |
![]() |
![]() |
#16 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
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). |
|
![]() |
![]() |
![]() |
#17 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,600
|
Quote:
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:
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 |
||
![]() |
![]() |
![]() |
#19 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
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? |
|
![]() |
![]() |
![]() |
#20 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,600
|
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] |
![]() |
![]() |
![]() |
Tags |
colorspace, colorspace conversion, ffmpeg |
Thread Tools | Search this Thread |
Display Modes | |
|
|