4:4:4 encoding/decoding

[juGGaKNot]

Input :

File size : 918 MB
Duration (ms) : 8s 700ms
Total bitrate : 885 Mbps
TCOD : 6755750000
TCDO : 6842750000

Format : RGB
Codec Id : 0x00000000
Codec info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Framerate : 40.000 fps
Bit depth : 8 bits

avisynth 2.6 and cmd using mulder's app

AviSource("0.avi")
ConvertToYV24(matrix="xx(see picture name)xx")

Output file: .mp4

RC Mode: CRF
Preset: Veryslow
Tuning: Animation
Profile: High444
Custom: --output-csp i444

x264 0.120.2146 bcd41db
(libswscale 2.1.100)
(libavformat 53.30.100)
(ffmpegsource 2.16.4.0)
built by Komisar on Jan 19 2012, gcc: 4.4.7 20110720 (prerelease) (x86.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all

Avs2YUV 0.24bm2

x264 revision: 2146 (core #120)
Avs2YUV version: 0.24.2

--- AVS INFO ---

Creating process:
"C:/Program Files/MuldeR/Simple x264 Launcher v2/toolset/avs2yuv.exe" -csp I444 -frames 1 D:\444\2709pc.avs NUL

D:\444\2709pc.avs: 1280x720, 40 fps, 348 frames

Resolution: 1280x720
Frame Rate: 40
No. Frames: 348

"C:/Program Files/MuldeR/Simple x264 Launcher v2/toolset/avs2yuv.exe" -csp I444 D:\444\2709pc.avs -

"C:/Program Files/MuldeR/Simple x264 Launcher v2/toolset/x264.exe" --crf 18.0 --preset veryslow --tune animation --profile high444 --output-csp i444 --output D:\2709pc.mp4 --frames 348 --demuxer y4m --stdin y4m -

y4m [info]: 1280x720p 0:0 @ 40/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:4:4 8-bit

VLC 2.0.0 used for playback / snapshots ( ffdshow has libavcodec set for avc, if that is important )

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/1_601_rec.png
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/2_709_rec.png
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/3_601_pc.png
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/4_709_pc.png

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/5_601_rec.png
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/6_709_rec.png
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/7_601_pc.png
http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/8_709_pc.png

pc601 looks better imo, what do you think ?
Is the encoding/decoding chain accurate ?
Would i benefit from using 10bit and not 8 bit ? Is it wise ?
Will people need anything more than vlc 2.0 to play the file ?
What if its 10bit, only vlc 2.0 ?

Cheers.

[smok3]

10 bit will not play on quicktime for example

it will play with vlc 2.0.0, vlc 2.1.x, mplayer (newish?), probably more (Dunno about windows stuff)

it is reported to play without violet border on new/beta adobe flash as well.

[juGGaKNot]

10 bit will not play on quicktime for example

it will play with vlc 2.0.0, vlc 2.1.x, mplayer (newish?), probably more (Dunno about windows stuff)

it is reported to play without violet border on new/beta adobe flash as well.

i see. thnx.

4:4:4 pc601 looks better imo, what do you think ?
Is the encoding/decoding chain accurate ?
Will people need anything more than vlc 2.0 to play the file ?

[Ghitulescu]

It looks to me like a game. There are no advantages in using 4:4:4 with CGI for encoding, 4:4:4 is generally used to prevent degradations during video processing. The colorimetry doesn't change, only its resolution, which you won't notice anyway, since the optical resolution of games is way below HD.
What do you intend to do after encoding? Watch it on your PC, on your standalone, distribute it? If you don't choose the first option, then you have to be sure that your video will be compatible with the recipients' players, be they software or hardware. 4:4:4 is not that portable as 4:2:2 on PC and not supported on standalones. Not to mention 40fps.

[aufkrawall]

i see. thnx.

4:4:4 pc601 looks better imo, what do you think ?
Is the encoding/decoding chain accurate ?
Will people need anything more than vlc 2.0 to play the file ?
Something went wrong when converting colorspaces, I guess.
There's that strange red/orange shift which I had encountered too.
I strongly suggest to let Avisnyth convert to Rec709.
Record in FRAPs RGB mode.

To play 10bit I444 video, best would be MPC HC, LAV and madVR.
EVR and VMR9 don't seem to convert correctly to RGB from I444, but madVR does.

[LoRd_MuldeR]

It looks to me like a game. There are no advantages in using 4:4:4 with CGI for encoding, 4:4:4 is generally used to prevent degradations during video processing.

I would have to disagree here. For example, sharp (colored) fonts, as they often appear in game/screen captures, can look really ugly, when chroma-subsampling is applied...

[aufkrawall]

I would have to disagree here. For example, sharp (colored) fonts, as they often appear in game/screen captures, can look really ugly, when chroma-subsampling is applied...
Yep, and not just fonts. The whole picture can get blurry.

I420: (TV range):
http://www.ld-host.de/uploads/thumbnails/ca7df51170aaffc01fc253fabc2df516.png (http://www.ld-host.de/show/ca7df51170aaffc01fc253fabc2df516.png)

I444 (TV range):
http://www.ld-host.de/uploads/thumbnails/42a8c5b99a3eb8ba6e940aca2e3f0f2b.png (http://www.ld-host.de/show/42a8c5b99a3eb8ba6e940aca2e3f0f2b.png)

RGB (full range):
http://www.ld-host.de/uploads/thumbnails/0e324f3b67d762f9fcd8abcc69a9a271.png (http://www.ld-host.de/show/0e324f3b67d762f9fcd8abcc69a9a271.png)

No visible difference between I444 and RGB, but I420 looks horrible.

Just a note: When you use I444 you need a very high bitrate to maintain transparency, CRF should be below 10.

[juGGaKNot]

quote

It is the only one that you can see great improvement, video recorded on a pc ( at least thats what Dark Shikari told me and the screens show it i think )

Something went wrong when converting colorspaces,

i will try madvr.

I would have to disagree here. For example, sharp (colored) fonts, as they often appear in game/screen captures, can look really ugly, when chroma-subsampling is applied...

Yes, fonts + colour.

The 4:4:4 video looks similar to what i record, the 4:2:0 one does not.

Should i add a picture from vdub ( original ) for comparition ?

Yep, and not just fonts. The whole picture can get blurry.

The 4:4:4 will be the ultra quality version, the main one will be 4:2:0

Noted about the bitrate, thnx.

And thank you all for your replies.

[juGGaKNot]

The remaining question would be

Is the encoding/decoding chain accurate ?

LE :

uncompressed bmp 2.6mb each frame, paint says 96dpi( all settings on quality from vga card )

80 frames per second ( each frame is sampled 10 times ingame, sps 800 )

vdub autoselect colorspace, result ( mediatab )

File size : 1.11 GB
Duration (ms) : 5s 413ms
Total bitrate : 1 769 Mbps
Format : RGB
Codec Id : 0x00000000
Codec info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Bit depth : 8 bits
Bits/(Pixel*Frame) : 23.998

Vegas project progressive, pixel aspect 1 square.

resulting avi ( 40 fps now, 80fps from vdub ) :

File size : 572 MB
Duration (ms) : 5s 425ms
Total bitrate : 885 Mbps
Format : RGB
Codec Id : 0x00000000
Codec info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Bit depth : 8 bits
Bits/(Pixel*Frame) : 24.000

And mulder's app, settings in first post.

I will try madvr for decoding.

LE 2 :

rec601 is ~identical to original ( crf 10 )
rec709 has darker red ( more shadow around the text )

All others are darker.

I will redo the encode tomorrow with sampling disabled from vegas for exact comparison with original.

[aufkrawall]

I will try madvr for decoding.
I use it just as a renderer and take LAV as decoder, can't guarantee anything else. ;)
But there surely isn't anything better regarding playback quality.

Just stick to matrix="Rec709", anything else doesn't work right or if it works there's most likely a bug that randomly "fixes" the result. :D

I had some discussions about converting FRAPS videos and annoyed some people, you better not repeat my mistakes. :o

[juGGaKNot]

I use it just as a renderer and take LAV as decoder, can't guarantee anything else. ;)
But there surely isn't anything better regarding playback quality.

Just stick to matrix="Rec709", anything else doesn't work right or if it works there's most likely a bug that randomly "fixes" the result. :D

I had some discussions about converting FRAPS videos and annoyed some people, you better not repeat my mistakes. :o

rec601 is ~identical to original
rec709 has darker red ( more shadow around the text than original )

crf 10

I will redo the encode tomorrow with sampling disabled from vegas for exact comparison with original.

And maybe qp 0

I will use madvr with LAV renderer after this to confirm.

and upload.

Thnx for the help, gonna get to the bottom of this.

Im in this for better quality on my video, have to do all the mistakes first to check for myself, no ? :)

[juGGaKNot]

New result, confirm my first ones.

video card was set to tv range when recording ( default )

x264 had no --fullrange switch on used.

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=1b558de42dc08a303c2faf79fc9999b48a876370

Use TV range algorithm for bit-depth conversions

I guess this is the case, no ?

http://www.mediafire.com/?1lb4j9sx2gbgxig

I have a TN display, can someone confirm my findings ?

LE : updated link, photobucker resized.

[Ghitulescu]

Yep, and not just fonts. The whole picture can get blurry.

I420: (TV range):
http://www.ld-host.de/uploads/thumbnails/ca7df51170aaffc01fc253fabc2df516.png (http://www.ld-host.de/show/ca7df51170aaffc01fc253fabc2df516.png)

I444 (TV range):
http://www.ld-host.de/uploads/thumbnails/42a8c5b99a3eb8ba6e940aca2e3f0f2b.png (http://www.ld-host.de/show/42a8c5b99a3eb8ba6e940aca2e3f0f2b.png)

RGB (full range):
http://www.ld-host.de/uploads/thumbnails/0e324f3b67d762f9fcd8abcc69a9a271.png (http://www.ld-host.de/show/0e324f3b67d762f9fcd8abcc69a9a271.png)

No visible difference between I444 and RGB, but I420 looks horrible.
The i420 is a little bit blurry on my monitor (27", 1920x1200, both in TV/PC levels). I don't see anything horrible. Or maybe we lack a common definition for horrible :)
I would say that supposing one cannot get a better image in 4:2:2/4:2:0, and supposing the recipients cannot see the 4:4:4 as you like to encode, that this is a really small price to be paid for compatibility.

It is the only one that you can see great improvement, video recorded on a pc ( at least that's what Dark Shikari told me and the screens show it I think)
And you quote what from what I said there? :)

New result, confirm my first ones.

original (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/1original.jpg)
original from vub (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/2originalvdub.png)
original from vegas (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/3originalvegas.png)
closest to original, rec601 (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/3rec601.png)
rec709, same as 601 but more shadow on red ( blacker edge ) (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/4rec709.png)
601pc, brighter colors, more contrast, font red seems ok (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/1601pc.png)
709pc, a bit brighter than 601pc, more shadow on font (http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/2709pc.png)

I have a TN display, can someone confirm my findings ?

How can one compare images of various sizes and compression?

[juGGaKNot]

The i420 is a little bit blurry on my monitor (27", 1920x1200, both in TV/PC levels). I don't see anything horrible. Or maybe we lack a common definition for horrible :)
I would say that supposing one cannot get a better image in 4:2:2/4:2:0, and supposing the recipients cannot see the 4:4:4 as you like to encode, that this is a really small price to be paid for compatibility.

Yes, i did not see a big difference there also.

Is was a long quote, i "edited it"

Photobucket resized the pictures, i updated the link, mediafire archive, please download that.

Now, the 4:4:4 looks like the original, the 4:2:0 does not, thats why i want to use it.

A 4:2:0 will also be available, the 4:4:4 will be extra.

LE : i have the original bmp from the capture, for the rest i used vlc snapshot and vdub save image.

[aufkrawall]

rec601 is ~identical to original
rec709 has darker red ( more shadow around the text than original )

Odd, can't confirm this. The I4XX screenshots are made of Rec709 video, colors just look like the original RGB.
How do you record? It's raw video, so probably MSI Afterburner?
I'm using FRAPS RGB, but it behaves exactly like raw video for me.
Are you absolutely sure that there's no decoding problem somewhere?


I would say that supposing one cannot get a better image in 4:2:2/4:2:0, and supposing the recipients cannot see the 4:4:4 as you like to encode, that this is a really small price to be paid for compatibility.

Yeah, it's about deciding what one want.
If you just want to watch the content of a video, 4:2:0 most likely isn't a problem, with other scenes there may be even just little blur.
But if you e.g. want to compare graphics quality differences, 4:2:0 isn't that great anymore.

I find the images I posted somewhat problematic (but to be honest, I'm a bit oversensitive regarding blur in games).
Diff pic of RGB PC and I444 TV:
http://www.ld-host.de/uploads/thumbnails/d20c99348299929c21701817eee7e758.png (http://www.ld-host.de/show/d20c99348299929c21701817eee7e758.png)

I444 and I420 (same tolerance level):
http://www.ld-host.de/uploads/thumbnails/c231750489a1e6d2be86a941de8a4f9e.png (http://www.ld-host.de/show/c231750489a1e6d2be86a941de8a4f9e.png)

The red pixels mostly show well which parts of the 4:2:0 image I find too blurry.

I wished there would be a portable MPC HC version, correctly preconfigured with LAV and madVR, then distribution of x264 I444 10bit would be much less complicated. :(
There are people in this forum who could do this. :o

[juGGaKNot]

Odd, can't confirm this. The I4XX screenshots are made of Rec709 video, colors just look like the original RGB.

I have a crappy tn display on my laptop, so the rec709 looks like original ?

I record using counter strike 1.6 internal engine via the HLAE app. I get bmp pictures > vdub

Autoselect colorspace, output default 24 RGB (888)

File size : 1.11 GB
Duration (ms) : 5s 413ms
Total bitrate : 1 769 Mbps
Format : RGB
Codec Id : 0x00000000
Codec info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Bit depth : 8 bits
Bits/(Pixel*Frame) : 23.998

I have tons of motion blur in the actual footage ( the pics are from unsampled video ), see first pictures for actual final look ( but motion blur will not allow you to see if it is like the original ).

[aufkrawall]

I have a crappy tn display on my laptop, so the rec709 looks like original ?

A conversion to rec709 is "needed" because otherwise correct working decoders like LAV/ffdshow will e.g. make red look rather orange.
VLC has a confirmed bug with these videos, so if they look right with it without rec709, you may be victim of a bug.
So, unfortunately all of your screenshots are wrong. ;)

MPC HC has a frame extraction feature too, but it doesn't work with madVR.
If you want to make a snapshot with it, simply go to fullscreen and do a screenshot by pressing the print button.

Converting screen capture is a total mess, it seems...

On Youtube you can often see game videos with wrong color/range conversion.
If you upload a video which is correctly converted to rec709, colors and luma should remain the same.




I record using counter strike 1.6 internal engine via the HLAE app. I get bmp pictures > vdub

Autoselect colorspace, output default 24 RGB (888)

I have tons of motion blur in the actual footage ( the pics are from unsampled video ), see first pictures for actual final look ( but motion blur will not allow you to see if it is like the original ).
I remember Team Fortress 2 has the same feature.
Didn't like it because of that loads of motion blur, but at least it doesn't slow down gaming.

[juGGaKNot]

A conversion to rec709 is "needed" because otherwise correct working decoders like LAV/ffdshow will e.g. make red look rather orange.
VLC has a confirmed bug with these videos, so if they look right with it without rec709, you may be victim of a bug.
So, unfortunately all of your screenshots are wrong. ;)

Ok so madvr + lav and new screens ( print in fullscreen )

[juGGaKNot]

http://www.mediafire.com/?92s00282mcfpspu

madvr + lav, print screen mpc-hc

709 looks better but still the shadow around the name is too dark.

[aufkrawall]

http://www.mediafire.com/?92s00282mcfpspu

madvr + lav, print screen mpc-hc

709 looks better but still the shadow around the name is too dark.
To me it seems, the only difference between original and 709 is chroma subsampling and other detail loss due to compression.

How does it look with I444 and crf 0?

Mine looks like this (to me exactly like the original, transparency is given):
http://www.ld-host.de/uploads/thumbnails/43e24b03889bca6b4c93056efd29aa35.png (http://www.ld-host.de/show/43e24b03889bca6b4c93056efd29aa35.png)

Original:
http://www.ld-host.de/uploads/thumbnails/944b90fdfc35cc98ef6d79c44010bce3.png (http://www.ld-host.de/show/944b90fdfc35cc98ef6d79c44010bce3.png)

You can use pngs instead of bmps, btw., they can be much smaller. Not in this case, but they can. :D

[juGGaKNot]

To me it seems, the only difference between original and 709 is chroma subsampling and other detail loss due to compression.

Should of used 0 in the first place to chose the exact one.

Ok, will do this.

[juGGaKNot]

http://www.mediafire.com/?y78wc98sthc9hpz

709 does indeed look identical on my monitor, with less bitrate i have pixelated red frag text @ the name.

601 has more blurr.

[aufkrawall]

601 has more blurr.
I'd say colors simply get screwed with it.

Btw: Why do you use animation tune in x264?
I've never used it so can't say how it behaves on that sample, but actually it's a 3D game with spatial depth and lots of detail information (at least compared to e.g. animes).
What about using default tune?
Just a guess, though.

So, you have found the solution you wanted right now?

[juGGaKNot]

So, you have found the solution you wanted right now?

Yes, i did not notice it, i do not use --tune, in general.

Yes, i got what i need.

thank you all.

cheers.

[aufkrawall]

So, I won't get any further notification PMs? :D

[juGGaKNot]

So, I won't get any further notification PMs? :D

Haha, on this no.

Now i'm thinking of how to decode it, madvr + lav + i3 sandy does not work.

I guess i'll go with qp 5.

[Zerofool]

juGGaKNot, your approach is wrong.
When you have ConvertToYV24(matrix="Rec709") in your script, you should also pass the "--colormatrix bt709" argument to x264 when encoding. And with
ConvertToYV24(matrix="Rec601") in the script, add the "--colormatrix bt470bg" argument. Now both should look exactly the same. But Rec709 is to be preferred, because stupid decoders/renderers will presume it's Rec709.

Just a note: When you use I444 you need a very high bitrate to maintain transparency, CRF should be below 10. Wow, dude! Are you just comparing screenshots or watching the actual video? :) It's very improbable that you'll spot any difference in moving images below 17-18 CRF. 10 is just overkill IMO, but if you use it for "archiving" purposes, then it's OK I guess. In my experience, even heavily aliased game footage looks transparent (to me) at CRF 18-19. And even higher for stereo-3D vids ;).


It looks to me like a game. There are no advantages in using 4:4:4 with CGI for encoding, 4:4:4 is generally used to prevent degradations during video processing.
You are absolutely wrong - (unaltered) game footage is actually THE area where 4:4:4 really makes sense (even more so without anti-aliasing). It's the nature of the content - sharp graphics - that benefit from it. As people before me already said - colored text, thin lines (crosshair) and so on...
And after all, we have all that valuable data, why throw it away when it costs so little bitrate-wise. That's what I try to do with my personal encodes - retain as much of the original data as possible without inflating the file size too much. And that's why I keep the full range, and use 4:4:4 (I also use 10bit encoding for better efficiency -> smaller file, even though the source is 8bit).
BUT for footage, which has been processed for the addition of motion blur, I see no big benefits from 4:4:4 from my own tests (not to mention the fact that mvtools2 doesn't support YV24 :p).
The colorimetry doesn't change, only its resolution, which you won't notice anyway, since the optical resolution of games is way below HD.
Sorry, what?
If you talk about crappy consoles that often render internally at 960x540 the OK, I agree. But tell that to a hardcore gaming enthusiast which plays at 1080p with downsampling (game is rendered at 2160p) with TrSSAA (or at least FXAA/SMAA) enabled, and they'll just laugh at your face :).
That's how Trine 2's internal AA works btw.

[QuantumRand]

If you want to try comparing images, you can give this a shot: http://quantumrand.net/random/imgcmp.php

It only works with PNGs right now, so keep that in mind. Error handling is limited, so be warned, lol. It'll do a pixel by pixel comparison and mark any that don't match in Red. It'll also tell you how many differences there are.

Oh, any images you upload are not saved; however, the resulting "difference" image is, and publicly accessible, so keep that in mind.

[juGGaKNot]

juGGaKNot, your approach is wrong.
When you have ConvertToYV24(matrix="Rec709") in your script, you should also pass the "--colormatrix bt709" argument to x264 when encoding.

Will try.

Already captured with tv range ( stock footage ), had some problems with the black before.

If you want to try comparing images, you can give this a shot: http://quantumrand.net/random/imgcmp.php

It only works with PNGs right now, so keep that in mind. Error handling is limited, so be warned, lol. It'll do a pixel by pixel comparison and mark any that don't match in Red. It'll also tell you how many differences there are.

Oh, any images you upload are not saved; however, the resulting "difference" image is, and publicly accessible, so keep that in mind.

Will also try this.

cheers.

[QuantumRand]

Will try.

Already captured with tv range ( stock footage ), had some problems with the black before.



Will also try this.

cheers.

It'll detect any difference in a pixel whatsoever, so if possible, it's best to use uncompressed PNGs to compare.

[aufkrawall]

juGGaKNot, your approach is wrong.
When you have ConvertToYV24(matrix="Rec709") in your script, you should also pass the "--colormatrix bt709" argument to x264 when encoding. And with
ConvertToYV24(matrix="Rec601") in the script, add the "--colormatrix bt470bg" argument. Now both should look exactly the same.

This should be just optional. Players which already can will still play it as expected and players that can't still won't be able to.
I made image comparisons with and without that flag, the hash checksums of the extracted frames were matching.
There doesn't seem to be any way to make VLC play those files correctly.
I personally would also convert from PC to TV range, otherwise decoding trouble will be bound to occur.


Wow, dude! Are you just comparing screenshots or watching the actual video? :)

To be honest, rather the first one. :D
It's about what you want, e.g. best compression by still preserving transparency or just having a nice looking video.


That's how Trine 2's internal AA works btw.
It was my favorite for best graphics in 2011.
One reason was the nice AA. :cool:

If you want to try comparing images, you can give this a shot: http://quantumrand.net/random/imgcmp.php

Or you use this program (free):
http://www.ld-host.de/uploads/thumbnails/4a0f0fc19648bf963e035022aa2f9d98.jpg (http://www.ld-host.de/show/4a0f0fc19648bf963e035022aa2f9d98.jpg)
http://www.mediafire.com/?w2rx06i26ld4jzh
I don't know from where it originates, maybe some user of the 3dcenter forum made it back some years ago.

[QuantumRand]

Or you use this program (free):
http://www.ld-host.de/uploads/thumbnails/4a0f0fc19648bf963e035022aa2f9d98.jpg (http://www.ld-host.de/show/4a0f0fc19648bf963e035022aa2f9d98.jpg)
http://www.mediafire.com/?w2rx06i26ld4jzh
I don't know from where it originates, maybe some user of the 3dcenter forum made it back some years ago.

Yeah. I just wrote up the quick PHP script because I didn't want to install anything. An actual released application to do it, like the one you mention, would certainly give you more options.

[Ghitulescu]

If one reencodes the video lossy or changes its colorimetry or ... or ..., there will always be differences between them. Since the colorspace of windows is always RGB (IIRC and if nothing changed with newer versions) even two lossless encodes, but with different colorimetries, might appear different.

Since in the end you'll watch that video with your eyes, use them also to compare the images/video :) - don't blindly rely on software only.

[aufkrawall]

Since in the end you'll watch that video with your eyes, use them also to compare the images/video :) - don't blindly rely on software only.
Well, if a pixel is different, then it's different.
Computers can detect this better then eyes.
But I don't see the reason why it has to be absolutely lossless, unless you want to reencode it. If transparency is given, what else could you want more?
No need for RGB or PC range.

[Ghitulescu]

Exactly, "transference" still could mean "different". That's what I said, that where a computer says there's a difference the human (to whom the video is in fact addressed) sees nothing different.
A watermarked image is completely different than the original (how much or how different, that depends on the algorithm) yet it's "transparent" to the naked eye.

My point was that it makes no sense to squeeze the latest quality drop in colorimetry, if the material has to be sent to other people, and therefore a compression mode more aggressive than "transparent" has to be used to keep the final size feasible (pure computational game: ~120MB/s in Huffy). There has to be a balance somewhere - and one can reach it only by trial and error.

[QuantumRand]

Yeah, not quite so useful for comparing frames of differently encoded video (though it does show a few things well). It is good for "Spot the Differences" though, haha:

http://quantumrand.net/misc/wedding-at-cana-thumb.png (http://quantumrand.net/misc/wedding-at-cana.png)
http://quantumrand.net/misc/tempimage1330062578-thumb.png (http://quantumrand.net/misc/tempimage1330062578.png)