Virtually or Visually Lossless Number

[Jay123210599]

I know by now that encoding will always result in quality loss, but tell me, in any video editing program like ffmpeg, Shutter Encoder, etc, what is the golden number for visually and/or virtually lossless results for crf, cq, qp, etc?

[Swedaniel]

I know by now that encoding will always result in quality loss, but tell me, in any video editing program like ffmpeg, Shutter Encoder, etc, what is the golden number for visually and/or virtually lossless results for crf, cq, qp, etc?

if you set the crf value to 0 or as close to it, it seem to give "lossless" effect, seem like progressive output provide some sort of lossless visual quality together with low crf values, same combo seem to function with upscaling to for example 1920x1080p that give no pixelation and an better visual to text on the video, allmost feel like putting an small magnifying glass over the video!

Edit: Allso i think if you look for programs with the name "Q" in it (Quantizer) which they seem to be oriented/provide lossless conversions (ie. Q-Encoder, MystiQ Video Converter). Allso for example the DivX Codec provide settings interface to where you can just select rate control>quality based and here simply set quantizer to as close to 0 as possible! Can allso set progressive and such things there!

[Jay123210599]

Do any of these codecs (mainly ProRes and DHxHR) produce better results than CRF and CQ with H265 and H264?

[Attachment 75777 - Click to enlarge]

[poisondeathray]

There is no golden number because each person is different. What looks like garbage to someone, might look great to someone else .

You decide on the acceptable tradeoff between quality and filesize. Do some short tests. eg. if CRF 16 isn't good enough , use something lower like CRF 12

Those other codecs (prores, cineform , dnxhr) have limited control and are meant for editing, fast decoding - they are I-frame codecs . At the same bitrate (thus filesize) , they will always be significantly lower in quality than x264, x265 when using temporal compression . Even using I-frame only (all keyframes) x264, x265, the quality will almost always be higher than those other codecs . The tradeoff for higher compression is usually encoding and decoding speed

[Jay123210599]

There is no golden number because each person is different. What looks like garbage to someone, might look great to someone else .

You decide on the acceptable tradeoff between quality and filesize. Do some short tests. eg. if CRF 16 isn't good enough , use something lower like CRF 12

Those other codecs (prores, cineform , dnxhr) have limited control and are meant for editing, fast decoding - they are I-frame codecs . At the same bitrate (thus filesize) , they will always be significantly lower in quality than x264, x265 when using temporal compression . Even using I-frame only (all keyframes) x264, x265, the quality will almost always be higher than those other codecs . The tradeoff for higher compression is usually encoding and decoding speed

What about this?
https://www.reddit.com/r/VideoEditing/comments/18r0dws/virtually_or_visually_lossless_number/

[poisondeathray]

There is no golden number because each person is different. What looks like garbage to someone, might look great to someone else .

You decide on the acceptable tradeoff between quality and filesize. Do some short tests. eg. if CRF 16 isn't good enough , use something lower like CRF 12

Those other codecs (prores, cineform , dnxhr) have limited control and are meant for editing, fast decoding - they are I-frame codecs . At the same bitrate (thus filesize) , they will always be significantly lower in quality than x264, x265 when using temporal compression . Even using I-frame only (all keyframes) x264, x265, the quality will almost always be higher than those other codecs . The tradeoff for higher compression is usually encoding and decoding speed

What about this?
https://www.reddit.com/r/VideoEditing/comments/18r0dws/virtually_or_visually_lossless_number/

What about it ?

It depends on your eyes and your usage scenario , and what you "think" is "visually lossless" because it's 100% definitely going to be different than someone else's number

[Cornucopia]

Read what pdr said again. And then reread it a few more times. It is not inconsistent with what was said on that reddit thread (which appears to be you asking the same question again).

Btw, you are wrong in your initial supposition: Encoding does NOT always result in quality loss. We've (& I've specifically) already discussed this.
Encoding to LOSSY compression codecs always results in quality loss (hence the name).
Encoding while changing color space always results in quality loss.
Requantizing (analog to digital) always results in quality loss.
All those losses can vary in terms of how much might be acceptable or unacceptable, and this is often personal preference/sensitivity.

Other forms of encoding do not result in quality loss.


Scott

[Jay123210599]

Read what pdr said again. And then reread it a few more times. It is not inconsistent with what was said on that reddit thread (which appears to be you asking the same question again).

Btw, you are wrong in your initial supposition: Encoding does NOT always result in quality loss. We've (& I've specifically) already discussed this.
Encoding to LOSSY compression codecs always results in quality loss (hence the name).
Encoding while changing color space always results in quality loss.
Requantizing (analog to digital) always results in quality loss.
All those losses can vary in terms of how much might be acceptable or unacceptable, and this is often personal preference/sensitivity.

Other forms of encoding do not result in quality loss.


Scott

Ok, say my videos are H264 or H265. What or how should I encode them to that will not result in quality loss (besides using lossless codecs like FFV1)? Will deinterlacing videos using QTGMC or Topaz Video AI result in quality loss?

[Cornucopia]

Re-encoding to h264 or h265, as mentioned before, you can keep it lossless by using cfr=0. Which will make the filesize much larger. And if you intend to edit exactly on any frame without requiring further reencoding, you can make the structure I frame only as well, but that will make the file size larger still. But if you are using crf=0, that last part may not be as important since you won't lose quality with another reencode, just time spent


Processing, like deinterlacing or noise reduction and/or sharpening (whether AI assisted or not) involves interpolation & generation of different pixels, which results in what is considered "loss", even though perceptually you may consider it to be of improved quality.


Scott

[Jay123210599]

Re-encoding to h264 or h265, as mentioned before, you can keep it lossless by using cfr=0. Which will make the filesize much larger. And if you intend to edit exactly on any frame without requiring further reencoding, you can make the structure I frame only as well, but that will make the file size larger still. But if you are using crf=0, that last part may not be as important since you won't lose quality with another reencode, just time spent


Processing, like deinterlacing or noise reduction and/or sharpening (whether AI assisted or not) involves interpolation & generation of different pixels, which results in what is considered "loss", even though perceptually you may consider it to be of improved quality.


Scott

What about h265 to h264? And tools make video structures I-frames only?

[Cornucopia]

Asked and answered


Scott

[Jay123210599]

Asked and answered


Scott

Where

[poisondeathray]

What about h265 to h264? And tools make video structures I-frames only?

Check your previous threads. Everything has been answered

ffmpeg -g 1

 -c:v libx264 -g 1

It requires re-encoding.

Quality loss if you use lossy encoding . No quality loss if you use lossless . You decide on the amount of quality loss tradeoff vs. filesize . Lossless encoding and I frame will usually make it many times larger than the original if you started with lossy compression

[Jay123210599]

What about h265 to h264? And tools make video structures I-frames only?

Check your previous threads. Everything has been answered

ffmpeg -g 1

 -c:v libx264 -g 1

It requires re-encoding.

Quality loss if you use lossy encoding . No quality loss if you use lossless . You decide on the amount of quality loss tradeoff vs. filesize . Lossless encoding and I frame will usually make it many times larger than the original if you started with lossy compression

Wait, I got it. Say my input video file size is 864 MB, and I select a number that makes the output file size match the output. Will that make the video visually/virtually lossless? If so, how do I get ffmpeg to show me the file size of the output before using it? If not, is just using -g 1 will already be enough, even when the input is h265 and it will encode it to h264?

Also, why does using prores, cineform , dnxhr will result in a lower quality than h264 and h265?

[poisondeathray]

Wait, I got it. Say my input video file size is 864 MB, and I select a number that makes the output file size match the output. Will that make the video visually/virtually lossless?

Generally no , but it depends on your definition of "visually lossless" . Some people think Youtube is "visually lossless". Some people think it's "garbage". ie. There are wide differences in perception

If you use QP 0, and the filesize balloons to maybe 4-10x the filesize on average for a typical compressed input - that is lossless. From there you can choose what what is "visually lossless" to you, or how much quality loss you are willing to tradeoff for filesize

If so, how do I get ffmpeg to show me the file size of the output before using it? If not, is just using -g 1 will already be enough, even when the input is h265 and it will encode it to h264?

You can't unless you use multipass encoding using a target bitrate e.g. 2pass encoding using the same bitrate as the input would give you the same filesize. The quality will typically be lower if you use the same bitrate as the input. Is it visually lossless ? Maybe to some people, not to others

Filesize = bitrate x running time

The same bitrate results in the same filesize .

Lossy encoding means the quality is always worse, even if you can't "see" the quality loss (you increase the filesize 10x , but using lossy encoding) the quality loss would still be measureable by metrics

Also, why does using prores, cineform , dnxhr will result in a lower quality than h264 and h265?

The short answer is they (prores, cineform , dnxhr) are less compressed. They are meant to be fast, for decoding speed , not high compression

So at equivalent bitrates, the quality of h264 / h265 will generally be higher, especially if using temporal compression and a good encoder (there are several different types of h264, h265 encoders) . Or another way to put it is you can have similar quality as prores/cineform etc... at lower bitrates (thus filesizes) when using higher compression using x264/x265. The main tradeoffs are slower encoding, decoding speed . If you try to edit a highly compressed file in an editor - it's much slower and less responsive

[Cornucopia]

"input" does NOT automatically mean original, source, uncompressed. Yet that (uncompressed) is how all files are compared to, compression-wise, and what almost all files have to revert to (or its nearest remaining equivalent) as the 1st step of recompression.

Iow, your "input" may be a file that has already been compressed 100:1 compared to a master uncompressed source. But for you to recompress back to 100:1 - the quote EQUAL bitrate to YOUR input, you are very, very likely to be using lossy compression. If instead you used true lossless compression, it would be 2:1 or 3:1 compared to the master uncompressed source, which means it will be 33:1 to 50:1 BIGGER than your input.

Again, what pdr mentioned was that if you had a "visually lossless" (but in actuality still a lossy) codec, and you tried to match your 100:1 compression, it would have to cut out much more than efficient codecs like h264, h265 do. The reason those are used is because computer have a super easy and fast time working with them, because they are such simple, straightforward codecs, while h264 and h265 are efficient specifically because they are complex. And being complex, they have much more latency and require a much more powerful computer to use smoothly.


Scott

[Jay123210599]

How about, in Shutter Encoder, I choose VBR/CBR and select auto for video bitrate?

[Cornucopia]

How about it?

It's not magic. It will follow the same rules that we've already laid out to you.

Don't know for sure how it wants to decide "auto" bitrate, but most likely it will try to match, as closely as it can, the picture quality of the input file. So if it sees the metadata of the input as having a crf = 16, it might try to make the crf of the output also = 16. But with a lossy codec, that STILL means loss. And depending on intermediate processing operations, it might be less than or equal or higher bitrate than the input. Without existing metadata, it has to make an even wilder guess. Do you really want to leave that up to some app that doesn't know what your priorities are?


Scott

[Jay123210599]

How about it?

It's not magic. It will follow the same rules that we've already laid out to you.

Don't know for sure how it wants to decide "auto" bitrate, but most likely it will try to match, as closely as it can, the picture quality of the input file. So if it sees the metadata of the input as having a crf = 16, it might try to make the crf of the output also = 16. But with a lossy codec, that STILL means loss. And depending on intermediate processing operations, it might be less than or equal or higher bitrate than the input. Without existing metadata, it has to make an even wilder guess. Do you really want to leave that up to some app that doesn't know what your priorities are?


Scott

Well then, what this code for h264 (-c:v libx264 -g 1) and this code for h265 videos (-c:v libx265 -g 1)? Will that be visually lossless enough?

[Cornucopia]

All that does is what has already been told to you twice before: it will change the GOP structure to be all I frames (the "g" usually refers to GOP lenth). Since you aren't specifying a bitrate, it will very likely automatically raise the bitrate a good amount to compensate for reducing the efficiency. If you DID specify the bitrate, assumedly to be equal to the input, since the output will be less efficient, it will also be worse quality.

"enough?" Is always a personal decision...


Scott

[poisondeathray]

Well then, what this code for h264 (-c:v libx264 -g 1) and this code for h265 videos (-c:v libx265 -g 1)? Will that be visually lossless enough?

Usually not, but again, it depends on your definition of "visually lossless enough" . What is "enough" for you ?

The default encoding mode is CRF 23 if you don't enter anything . Most people wouldn't call CRF23 "visually lossless" . Some people say around CRF 18 for example that reddit thread - but personally I think the CRF 18 quality isn't "visually lossless" - certainly it's not on the level of ProresHQ quality -it's much lower. You'd need to use lower CRF, higher bitrates to achieve similar to ProresHQ quality.

What level of quality is "visually lossless" for your scenario ? That is the important question

Also , why do you need all keyframes ? All keyframes usually means filesize will need to be about 1.5-2x to achieve a certain level of quality - because there is no temporal compression used

If you're thinking about editing, keyframes - that's only for cutting and stream copying - not re-encoding for an end distribution format (or another scenario is low latency in a editor.) You should edit before you final encode, preferably in the lossless domain (e.g. avisynth, or lossless intermediate), then encode normally with temporal compression for final output. Otherwise you lose quality twice, instead of once . Most people wouldn't use an I-frame all keyframe file as a final delivery file, because it's inefficient (large filesizes) -but you haven't provided any information on what you scenario is

If you provide background information on your situation, what exactly that you are trying to do - you might get some better information

[Jay123210599]

Well then, what this code for h264 (-c:v libx264 -g 1) and this code for h265 videos (-c:v libx265 -g 1)? Will that be visually lossless enough?

Usually not, but again, it depends on your definition of "visually lossless enough" . What is "enough" for you ?

The default encoding mode is CRF 23 if you don't enter anything . Most people wouldn't call CRF23 "visually lossless" . Some people say around CRF 18 for example that reddit thread - but personally I think the CRF 18 quality isn't "visually lossless" - certainly it's not on the level of ProresHQ quality. You'd need to use lower CRF, higher bitrates to achieve similar to ProresHQ quality.

What level of quality is "visually lossless" for your scenario ? That is the important question

Also , why do you need all keyframes ? All keyframes usually means filesize will need to be about 1.5-2x to achieve a certain level of quality - because there is no temporal compression used

If you're thinking about editing, then you should edit before you final encode, preferably in the lossless domain (e.g. avisynth, or lossless intermediate), then encode normally with temporal compression for final output. Otherwise you lose quality twice, instead of once

If you provide background information on your situation, what exactly that you are trying to do - you might get some better information

All right, here's the truth: I have h264 and h265 videos that I want to losslessly cut into smaller parts, but there are certain sections that can only be cut at P or B frames instead of I frames. What should I do if I want to get that certain section without losing any quality?

[poisondeathray]

All right, here's the truth: I have h264 and h265 videos that I want to losslessly cut into smaller parts, but there are certain sections that can only be cut at P or B frames instead of I frames. What should I do if I want to get that certain section without losing any quality?

For what purpose ? Why are you doing this ?


Otherwise this has already been answered in your other threads:

If cuts are not on keyframes - without losing any quality means lossless reencode - and massive filesizes as I think you have already seen

Otherwise use a CRF value that has minimal quality loss and a filesize that you can tolerate. Do some tests - try CRF 16, 12, 8, 4 etc... Maybe CRF 12 is "good enough" for your goals without making filesize that much larger? Again it depends on what is "visually lossless" for your eyes and goals, and how much larger are you willing to suffer


If it's a long fragment with many GOP's - then a smart renderer might be a better option such as tmpgenc smart renderer, solviegmm video spliter - because most frames will be stream copied (same quaiity, same filesize for those frames) , and only affected GOP's around cutsites will be re-encoded

[Jay123210599]

All right, here's the truth: I have h264 and h265 videos that I want to losslessly cut into smaller parts, but there are certain sections that can only be cut at P or B frames instead of I frames. What should I do if I want to get that certain section without losing any quality?

For what purpose ? Why are you doing this ?


Otherwise this has already been answered in your other threads:

If cuts are not on keyframes - without losing any quality means lossless reencode - and massive filesizes as I think you have already seen

Otherwise use a CRF value that has minimal quality loss and a filesize that you can tolerate. Do some tests - try CRF 16, 12, 8, 4 etc... Maybe CRF 12 is "good enough" for your goals without making filesize that much larger? Again it depends on what is "visually lossless" for your eyes and goals, and how much larger are you willing to suffer


If it's a long fragment with many GOP's - then a smart renderer might be a better option such as tmpgenc smart renderer, solviegmm video spliter - because most frames will be stream copied (same quaiity, same filesize for those frames) , and only affected GOP's around cutsites will be re-encoded

I am going this because I want people to be able to watch this. The frames in the output video themselves won't be reencoded?

[poisondeathray]

I am going this because I want people to be able to watch this.

How are people going to watch it ? Are you sending them a clip ? Posting on a website ? etc....

The frames in the output video themselves won't be reencoded?

Stream copy means not re-encoded

If it's a short clip, then it might be 1 GOP - then whole thing has to be re-encoded

If you re-encode and use a low enough CRF value such as 10-16 it's probably "good enough" for general watching, and people won't "hate" you for making the filesize so big if you're sending a clip

[Cornucopia]

You keep asking ahead of trying, but have you actually tried anything?

It's always a compromise of some sort. Try different variations and find a compromise you can accept.


Scott

[Jay123210599]

You keep asking ahead of trying, but have you actually tried anything?

It's always a compromise of some sort. Try different variations and find a compromise you can accept.


Scott

Well, I'm gonna trust in what this video about the tool has to say.
https://www.youtube.com/watch?v=JE2zPxDuohk

[Jay123210599]

I am going this because I want people to be able to watch this.

How are people going to watch it ? Are you sending them a clip ? Posting on a website ? etc....

The frames in the output video themselves won't be reencoded?

Stream copy means not re-encoded

If it's a short clip, then it might be 1 GOP - then whole thing has to be re-encoded

If you re-encode and use a low enough CRF value such as 10-16 it's probably "good enough" for general watching, and people won't "hate" you for making the filesize so big if you're sending a clip

Well, I was gonna convert the clips into either apng or gif files and upload them to DeviantArt, but I don't know which ones have the higher quality. Do you know?

[poisondeathray]

Well, I was gonna convert the clips into either apng or gif files and upload them to DeviantArt, but I don't know which ones have the higher quality. Do you know?

unless your "videos" are extremely simple, apng will be higher in quality, because gif only supports 256 colors. 8bit apng will support 16.3 million colors

It's bad etiquette to upload large files and embed in websites, and your apng will be large unless you downscale it, or edit it down to a few frames. See your other thread - many times larger than the input video. That's a big reason gif is used more often despite the very low quality


https://forum.videohelp.com/threads/412810-Video-to-APNG

If I didn't downscale, just keep 8bit RGB the apng is massive - 12.7MB source video balloons to 474MB (!)

Even with downscaling it's still 59.3MB .

No downscaling plus 16bit RGB ballons to 1.15GB(!!)

apng's are meant to be used in very specific display scenarios, not general use

[usually_quiet]

Well, I'm gonna trust in what this video about the tool has to say.
https://www.youtube.com/watch?v=JE2zPxDuohk

People keep recommending TMPGEnc Smart Renderer to you for a reason. It should be a whole lot faster than converting to all I-frames, editing that file, and re-compressing the edited video for practicality. Since there is a free trial it will cost you nothing but your time to see if you like the UI and find out if the results are satisfactory.