is x264lossless really "lossless?

[deadrats]

as the title suggests, is lossless mode x264 really lossless? i'm asking because over at the dipshit9 forums some clowns where comparing divx's hevc encodes against x264's and concluding that x264 produced the superior results. when they were asked how they were viewing the encodes they explained that they would do the encode with each and then they would redo the hevc encode with x264lossless and compare those results with the encodes done with x264.

to me this seems incredibly idiotic and purposely done to cheat for x264. i decided to try it myself using both handbrake and xvid4psp5 since both allow for supposed lossless x264 but i quickly discovered that "lossless" basically just sets the crf value to 0 but you're free to change the other encoding options anyway you want. so if one where so inclined you could choose "lossless" encoding, crank up trellis, subme, psy-rd, psy trellis, mb-tree and aq and claim that the result was the equivalent of the input, which clearly wouldn't be because the psy optimizations would have conspired to change the resultant image from the source image.

so is it possible to use x264 for a true lossless encode? should i set crf to 0 and disable all the other encoding options like weighted p, all the b frame options, subme and all the rest? should i be using I frame only? or should i stick with a more proven lossless codec?

[poisondeathray]

Yes it's truly lossless in the same colorspace

The different settings only affect compression (higher settings slower to encode, but smaller filesizes)

The reason it's used is uncompressed YUV files are large. But you can just as easily use another lossless codec. Something like FFV1 provides better compression

It's not a conspiracy

The reason is DivX has quite handicapped their encoder compared to the reference HEVC encoder. Yes it's faster than the reference , but quality is a LOT worse. Many features are disabled or not available. It's almost worse than x264 on many tests at this point, and slower . (Same thing with x265, btw) . But don't worry, they will improve - it's still very early in development

[deadrats]

maybe i'm getting caught up in semantics but if set crf 0 + ultra fast it wouldn't produce the same image as crf 0 + placebo, i understand what you say about the settings increasing compression but with lossless encoding one setting should not use less bit rate than the other.

likewise i can't wrap my head around the notion that x264lossless + psy optimizations can somehow result in a truly lossless encode since by their nature psy optimizations reduce psnr and ssim (except for mb-tree which increases each).

so for true lossless export, should i disable all x264 options and set crf to 0?

[poisondeathray]

maybe i'm getting caught up in semantics but if set crf 0 + ultra fast it wouldn't produce the same image as crf 0 + placebo, i understand what you say about the settings increasing compression but with lossless encoding one setting should not use less bit rate than the other.

That's exactly what it does. It also uses long GOP by default (not intra only like lagarith , or huffyuv, or ut video) ; usually the longer the GOP, the more data can be used as similarities, and the less is require to be stored as the residual thus smaller filesizes . That's one big reason why FFV1 gets so good compression

When people talk about "lossless" codecs in terms of video, it refers to the decoded output. So the decoded output of say, a lagarith lossless encode in YUV 4:2:0 will be the same as the decoded output of x264 crf0 YUV 4:2:0 using intra only, or the decoded output of x264 crf0 YUV 4:2:0 long GOP + some slower settings. The only difference in terms of quality will be the last one will be smaller in filesize . The decoded output and uncompressed filesize will be exactly the same for all 3

There are various reasons/scenarios why people might use different x264 settings or other lossless codecs (other criteria for selecting lossless codecs) . Compatibility between different applications, encoding speed, decoding speed (latency), compression efficiency . For example x264 lossless (using any settings) isn't as compatible in most NLE's as some other lossless codecs like UT Video. UT Video is super smooth and much faster to edit with (decoding latency is much lower) compared to x264 (even in --tune fastdecode --keyint 1 mode)

likewise i can't wrap my head around the notion that x264lossless + psy optimizations can somehow result in a truly lossless encode since by their nature psy optimizations reduce psnr and ssim (except for mb-tree which increases each).

so for true lossless export, should i disable all x264 options and set crf to 0?

psy opts are automatically disabled in lossless mode

[jagabo]

Give it up deadrats. Some people other than you actually know what they're doing too. You don't always need to assume everybody else is an idiot. x264 lossless is lossless. Test it yourself -- compare input and output. I've done testing myself and I'm satisfied it's truly lossless.

Be careful with handbrake though. It will use CRF 1 instead of CRF 0 if you don't set the Profile/Level to Auto.

[deadrats]

Give it up deadrats. Some people other than you actually know what they're doing too. You don't always need to assume everybody else is an idiot. x264 lossless is lossless. Test it yourself -- compare input and output. I've done testing myself and I'm satisfied it's truly lossless.

Be careful with handbrake though. It will use CRF 1 instead of CRF 0 if you don't set the Profile/Level to Auto.

i have no idea where that came from. what i was saying is that (as an example) x264lossless + subme=10 + tesa + psy-rd + psy-trellis + mb-tree + aq can't be equal to x264lossless + no subpel + diamond + no-psy + calvc + every feature disabled, that's ridiculous. by their very nature psy optimizations are not meant to reproduce the source image as closely as possible but rather to improve the subjective visual quality and if they're improving the quality then including them with a lossless setting doesn't result in a truly lossless output.

and it is idiotic to do a test encode with a new codec then re-encode the output using a high bit rate x264 encode and then compare the second generation encode to the first generation x264 baseline encode and conclude that the new codec is inferior to the standard bearer.

surely you must see why testing any new codec via this methodology is at best misguided and at worst blatantly dishonest.

[poisondeathray]

and it is idiotic to do a test encode with a new codec then re-encode the output using a high bit rate x264 encode and then compare the second generation encode to the first generation x264 baseline encode and conclude that the new codec is inferior to the standard bearer.

surely you must see why testing any new codec via this methodology is at best misguided and at worst blatantly dishonest.

Yes, that would be idiotic

But if you're talking about xooyoozoo's recent comparison , you probably don't understand what was done . It's not a case of dishonest, it's a case of failure to read or lack of comprehension

All bitstreams are available - meaning the original output of x264 and divx hevc are available for you to compare

The lossy re-encodes are side by side comparisons, meaning both streams are re-encoded for the A/B side by side view

That is completely transparent testing methodology ; but I suppose you could argue why use lossy x264 to encode - hypothetically there might be some advantage. Well - it's so you an easily examine the side-by-side view. Decoding hevc streams still isn't "easy" with common software or players

[jagabo]

Give it up deadrats. Some people other than you actually know what they're doing too. You don't always need to assume everybody else is an idiot. x264 lossless is lossless. Test it yourself -- compare input and output. I've done testing myself and I'm satisfied it's truly lossless.

Be careful with handbrake though. It will use CRF 1 instead of CRF 0 if you don't set the Profile/Level to Auto.

i have no idea where that came from. what i was saying is that (as an example) x264lossless + subme=10 + tesa + psy-rd + psy-trellis + mb-tree + aq can't be equal to x264lossless + no subpel + diamond + no-psy + calvc + every feature disabled, that's ridiculous. by their very nature psy optimizations are not meant to reproduce the source image as closely as possible but rather to improve the subjective visual quality and if they're improving the quality then including them with a lossless setting doesn't result in a truly lossless output.

And what makes you think the x264 developers aren't smart enough not to use the features that would not give lossless results when set to CRF=0? Once again, all you have to do is compare CRF=0 encodings with different presets/settings and you'll see for yourself.

[deadrats]

But if you're talking about xooyoozoo's recent comparison , you probably don't understand what was done . It's not a case of dishonest, it's a case of failure to read or lack of comprehension

All bitstreams are available - meaning the original output of x264 and divx hevc are available for you to compare

The lossy re-encodes are side by side comparisons, meaning both streams are re-encoded for the A/B side by side view

That is completely transparent testing methodology ; but I suppose you could argue why use lossy x264 to encode - hypothetically there might be some advantage. Well - it's so you an easily examine the side-by-side view. Decoding hevc streams still isn't "easy" with common software or players

wait, he used lossy x264 not lossless? that's even worse! the avc spec and the hevc spec are significantly different from one another, call for the use of significantly different encoding and decoding algorithms and methods and aside from a few things like cabac, some motion search and look-ahead they have little in common, hell hevc doesn't use macroblocks anymore, it uses ctu's.

starting with a baseline source file and doing two encodes, using each compression scheme, then redoing the hevc encode with an inferior compression technology, effectively undoes the hevc compression scheme and what you have now is 2 encodes done using x264.

what if i did 2 encodes, an mpeg-2 encode and an x264 encode, then stitched them together side-by-side and redid the whole thing with lossy mpeg-2 and concluded that mpeg-2 is the better compression technology, would you defend my moronic test or would you say it was an example of my anti-x264 bias?

if you'll recall a while back, before we had any hevc encoders to play with, i made the prediction here and in that POS forum (which is what ultimately led that douche donald to ban me) that once we had hevc encoders to play with the x264 faithful, those that worship at the alter of DS and the penguin would start FUD campaigns, consisting of tests that "prove" that x264 is a better encoder than <insert hevc encoder of choice>.

my predictions have starting to come to pass, the narrative is spreading throughout that crappy forum that hevc encoders are inferior to x264 and even you, who initially said that hevc is already better than x264 and will only improve with time and you have said hevc>vp9>x264, now you have backtracked on those statements and i've seen you make the claims that x264 is better than hevc.

now i will grant you, because of the fact that there aren't all that many software players that support hevc playback it may be beneficial for the average user to use x264 with higher bit rates for the time being but one needs to use significant amounts of alcohol to do same bit rate encodes with strongene's hevc, divx's hevc and x264 and conclude that x264 is better than them.

[deadrats]

And what makes you think the x264 developers aren't smart enough not to use the features that would not give lossless results when set to CRF=0? Once again, all you have to do is compare CRF=0 encodings with different presets/settings and you'll see for yourself.

because the x264 developers aren't the sharpest knives in the drawer, that's why. or maybe they are just complete sellouts and some company paid them for such a feature.

i did do a few test encodes with crf 0 and various settings and then looked at the media info output and it would appear that x264 allows you to mix crf 0 with practically any combination of settings you desire.

as for the x264 developers, you shouldn't put that much faith in their intellects, Jason only got his bachelors degree in CS from Harvey Mudd College in May of 2011 and he was dumb enough to post his resume to his website (it's since been taken down) complete with his home address and phone number.

he's one of these people who may have significant amounts of book knowledge but lack that logical analytical ability to run through all possible scenarios and account for them all. his software is a clear example of that, rife with over-engineering, suffering from the include everything and the kitchen sink mentality that some software developers seem to suffer from.

[jagabo]

i did do a few test encodes with crf 0 and various settings and then looked at the media info output and it would appear that x264 allows you to mix crf 0 with practically any combination of settings you desire.

And they all deliver lossless results (at least the variations I've tried). But you would rather not look at the results for some reason.

[poisondeathray]

But if you're talking about xooyoozoo's recent comparison , you probably don't understand what was done . It's not a case of dishonest, it's a case of failure to read or lack of comprehension

All bitstreams are available - meaning the original output of x264 and divx hevc are available for you to compare

The lossy re-encodes are side by side comparisons, meaning both streams are re-encoded for the A/B side by side view

That is completely transparent testing methodology ; but I suppose you could argue why use lossy x264 to encode - hypothetically there might be some advantage. Well - it's so you an easily examine the side-by-side view. Decoding hevc streams still isn't "easy" with common software or players

wait, he used lossy x264 not lossless? that's even worse! the avc spec and the hevc spec are significantly different from one another, call for the use of significantly different encoding and decoding algorithms and methods and aside from a few things like cabac, some motion search and look-ahead they have little in common, hell hevc doesn't use macroblocks anymore, it uses ctu's.

starting with a baseline source file and doing two encodes, using each compression scheme, then redoing the hevc encode with an inferior compression technology, effectively undoes the hevc compression scheme and what you have now is 2 encodes done using x264.

Your understanding is flawed.

When the raw x264 or HEVC is decoded, the compression is already "undone". It's an uncompressed stream.

what if i did 2 encodes, an mpeg-2 encode and an x264 encode, then stitched them together side-by-side and redid the whole thing with lossy mpeg-2 and concluded that mpeg-2 is the better compression technology, would you defend my moronic test or would you say it was an example of my anti-x264 bias?

I would defend your "moronic" test . The lossy mpeg2 re-encode would done at a high enough bitrate that it's near lossless. Any defects in the orginal bitstream caused by either MPEG2 or x264 will show up. If you still don't believe it, go back to there original streams and/or stack them together with a lossless codec . Remember his tests, he ALSO provides the original streams

if you'll recall a while back, before we had any hevc encoders to play with, i made the prediction here and in that POS forum (which is what ultimately led that douche donald to ban me) that once we had hevc encoders to play with the x264 faithful, those that worship at the alter of DS and the penguin would start FUD campaigns, consisting of tests that "prove" that x264 is a better encoder than <insert hevc encoder of choice>.

That's a BIG stretch. I don't see any FUD campaign. I see transparent testing methods and observations . Trust me, if there was any agenda (towards anything) they would get called out on it . It's almost like you have some psychosis going on there - you should get that checked out

my predictions have starting to come to pass, the narrative is spreading throughout that crappy forum that hevc encoders are inferior to x264 and even you, who initially said that hevc is already better than x264 and will only improve with time and you have said hevc>vp9>x264, now you have backtracked on those statements and i've seen you make the claims that x264 is better than hevc.

Go back and READ.

I said x265 and DivX implementation of HEVC aren't very good right now. They are stripped down "ghetto" versions of the reference encoder. The HEVC reference encoder is still the best (slow as molasses , but quality is better)

Better yet, go and do some of your own testing. My tests pretty much show this. The reference encoder CLEARLY beats x264 almost in every scenario (it's weakness only being lack of AQ, shadow areas sometimes worse. But those encodes are VERY VERY stable. VERY clean compared to x264, especially at low bitrates) . Not true with DivX HEVC or x265. The differences aren't as large and x264 even looks better in some cases.

[poisondeathray]

i did do a few test encodes with crf 0 and various settings and then looked at the media info output and it would appear that x264 allows you to mix crf 0 with practically any combination of settings you desire.

Again - not psy opts - they are automatically disabled.

Any other settings that you change (and aren't disabled in lossless mode) won't have an effect on the "losslessness" nature of the bitstream

as for the x264 developers, you shouldn't put that much faith in their intellects, Jason only got his bachelors degree in CS from Harvey Mudd College in May of 2011 and he was dumb enough to post his resume to his website (it's since been taken down) complete with his home address and phone number.

Nice stalking skills LOL

Maybe stalkers like you are the reason he took the contact info down ?

he's one of these people who may have significant amounts of book knowledge but lack that logical analytical ability to run through all possible scenarios and account for them all. his software is a clear example of that, rife with over-engineering, suffering from the include everything and the kitchen sink mentality that some software developers seem to suffer from.

Yes there are problems with the coding, perhaps it could have been done better from the start - but you can't disagree with the end results . You try to , but you get shot down all the time .

[deadrats]

i did do a few test encodes with crf 0 and various settings and then looked at the media info output and it would appear that x264 allows you to mix crf 0 with practically any combination of settings you desire.

And they all deliver lossless results (at least the variations I've tried). But you would rather not look at the results for some reason.

i did look at the results but it's absurd beyond belief to say that crf 0 + psy optimizations is the same as crf 0 + no-psy optimizations; to say they are the same is to say that psy optimizations have no effect on the encoding quality and if they do have an effect then any encoding test done to evaluate hevc where the hevc encode is redone using crf 0 + psy is invalid and clearly biases the tests.

what i'm looking for is a true test, i want to take snippets of various sources, export them using a true lossless setting and then re-encode each with both x264 and various hevc encoders and compare the ouput using the divx player.

[poisondeathray]

i did look at the results but it's absurd beyond belief to say that crf 0 + psy optimizations is the same as crf 0 + no-psy optimizations; to say they are the same is to say that psy optimizations have no effect on the encoding quality and if they do have an effect then any encoding test done to evaluate hevc where the hevc encode is redone using crf 0 + psy is invalid and clearly biases the tests.

They are the same . Psy is disabled when crf=0 or qp=0. It's hardcoded. It's impossible to use psy when crf=0 . Try it. Examine the encode with mediainfo (or look at the commandline) .

If you want definitive proof, do difference testing on the output streams . e.g. mediainfo might be reading it incorrectly. It's definitely lossless, without a doubt

what i'm looking for is a true test, i want to take snippets of various sources, export them using a true lossless setting and then re-encode each with both x264 and various hevc encoders and compare the ouput using the divx player.

Then they are all "true" tests. The direct output of x264 and various hevc encoders are posted

You're welcome to do the tests yourself. I didn't believe HEVC was that good either at first. I had to run tests myself on various sources to proove it. I'm convinced now. I'm also fairly convinced that these early x265 and DivX HEVC implementations aren't that great right now (but they should get a lot better in the future) . Just my hypothesis, but I think there is pressure to get those to work faster - rather than a quality emphasis - because they will be licensed out for $$ . Vendors won't license , and clients won't be buying software that encodes at fractional FPS's

[deadrats]

Just my hypothesis, but I think there is pressure to get those to work faster - rather than a quality emphasis - because they will be licensed out for $$ . Vendors won't license , and clients won't be buying software that encodes at fractional FPS's

absolutely, divx already has hardware vendors getting divx hevc certified so they need to have an encoder out quickly that can create content for the devices and the x265 guys have corporate sponsors that are demanding a product quickly.

That's a BIG stretch. I don't see any FUD campaign. I see transparent testing methods and observations . Trust me, if there was any agenda (towards anything) they would get called out on it . It's almost like you have some psychosis going on there - you should get that checked out

want to know the irony in this statement? as most of you know i was an exterminator for almost a dozen years but what i don't think i ever mentioned was that i had a serious accident back in 2010 and it led to me not being able to work. i decided to go back to school and got certified as a medical assistant. i recently started a new job in a hospital, want to take a guess in what kind of unit? i work in the psychiatric intensive care unit of a large hospital as a unit coordinator and one of my responsibilities is preparing commitment papers in order to keep patients involuntarily committed.

enjoy your laugh.

Your understanding is flawed.

When the raw x264 or HEVC is decoded, the compression is already "undone". It's an uncompressed stream.

i really hate when i read things like this as it shows a basic misunderstanding of compression schemes. with lossless compression such as used by zip and rar files, yes the compression is "undone" but with lossy compression scheme the compression can never be undone because a portion of the data is gone, if the compression were undone then there wouldn't be any point in using one encoder over another as when the decoded streams were played they would be exactly the same.

[poisondeathray]

Your understanding is flawed.

When the raw x264 or HEVC is decoded, the compression is already "undone". It's an uncompressed stream.

i really hate when i read things like this as it shows a basic misunderstanding of compression schemes. with lossless compression such as used by zip and rar files, yes the compression is "undone" but with lossy compression scheme the compression can never be undone because a portion of the data is gone, if the compression were undone then there wouldn't be any point in using one encoder over another as when the decoded streams were played they would be exactly the same.

You really don't understand?

It's "undone" in the sense that it is decoded to uncompressed. It's not "undone" in the sense that you get the original file - sorry that was probably a poor choice of words . I'm replying in the context of your sentence:

starting with a baseline source file and doing two encodes, using each compression scheme, then redoing the hevc encode with an inferior compression technology, effectively undoes the hevc compression scheme and what you have now is 2 encodes done using x264.

The point is, encoding anything in video requires the source to be decoded to uncompressed first, then it's re-encoded.

Unlike zip, rar , archiving software etc... where nothing is decoding to uncompressed first. With archiving software you can get back the very original format. Do you see the difference ?

You're "undoing" the hevc compression scheme in terms that it's decoded to uncompressed. YOU're not "undoing" it in the sense that you get back the original PRE-HEVC source

In the A/B side by side example - nothing is incurring an "extra penalty" because both x264 and hevc are decoded to uncompressed first, then both are re-compressed . Even if there was a theoretical disadvantage, you still have the original output bitstreams to compare. I see nothing wrong here

[Brad]

psy opts are automatically disabled in lossless mode

Indeed... Deadrats, I'd expect that someone who feels qualified to assess the software's engineering would have checked the source code.

 776     if( b_open && (h->param.rc.i_rc_method == X264_RC_CQP || h->param.rc.i_rc_method == X264_RC_CRF)
 777         && h->param.rc.i_qp_constant == 0 )
 778     {
 779         h->mb.b_lossless = 1;
 780         h->param.i_cqm_preset = X264_CQM_FLAT;
 781         h->param.psz_cqm_file = NULL;
 782         h->param.rc.i_rc_method = X264_RC_CQP;
 783         h->param.rc.f_ip_factor = 1;
 784         h->param.rc.f_pb_factor = 1;
 785         h->param.analyse.b_psnr = 0;
 786         h->param.analyse.b_ssim = 0;
 787         h->param.analyse.i_chroma_qp_offset = 0;
 788         h->param.analyse.i_trellis = 0;
 789         h->param.analyse.b_fast_pskip = 0;
 790         h->param.analyse.i_noise_reduction = 0;
 791         h->param.analyse.b_psy = 0;
 792         h->param.i_bframe = 0;
 793         /* 8x8dct is not useful without RD in CAVLC lossless */
 794         if( !h->param.b_cabac && h->param.analyse.i_subpel_refine < 6 )
 795             h->param.analyse.b_transform_8x8 = 0;
 796     }

[deadrats]

nothing

[Stears555]

Why do you use x264 lossless codec? There are many better lossless video compressors: the best: FFv1, Lagarith, Utvideo and Huffyuv.

[Baldrick]

Please try and behave and skip personal attacks. Just ignore users you don't like.

[Baldrick]

Thread locked. Continue at www.offtopic..com