search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.66k stars 2.93k forks source link

different chromaloc position between GPU and GPU-NEXT and general placement issues #15299

Closed mightyhuhn closed 1 week ago

mightyhuhn commented 1 week ago

mpv Information

mpv v0.39.0-325-gd66ed2d8 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Nov 10 2024 00:40:04
libplacebo version: v7.349.0 (v7.349.0-19-g118d810-dirty)
FFmpeg version: N-117737-g10c02decc
FFmpeg library versions:
   libavcodec      61.24.100
   libavdevice     61.4.100
   libavfilter     10.6.101
   libavformat     61.9.100
   libavutil       59.46.100
   libswresample   5.4.100
   libswscale      8.9.101

Other Information

Microsoft Windows [Version 10.0.19045.4046]- GPU model, driver and version:
- Source of mpv: update.bat
- Latest known working version: -
- Issue started after the following happened: -

Reproduction Steps

play files with chromaloc information that is not 0. compare the output with GPU and GPU-next

Expected Behavior

they should do the same thing on GPU and GPU-next. and top left should be moved bot right not somewhere else.

Actual Behavior

it moves it to the wrong position. comparison 3 https://slow.pics/c/YNnEmLwg

mpv.conf profile=gpu-hq vo=gpu gpu-api=vulkan fbo-format=rgba32f

screenshot-high-bit-depth=no volume=25 loop-file=yes screenshot-format=png

cscale=bilinear

Log File

outputgpunCC.txt outputgpunLC.txt outputgpunLT.txt outputgpuCC.txt outputgpuLC.txt outputgpult.txt

Sample Files

edit: the orginal sample files have been removed they have been wrongly encoded by me and no one else when i added the meta data the originals have mpeg2 but are subsampled correctly. the error is entirely on me and talk about me saying i didn't created them is true but the error is mine alone!

the new samples will show the difference between GPU and GPU next error which was already fixed 2 days ago. and hopefully correctly encoded. 420.zip they are only added for reproduction. end of edit.

I carefully read all instruction and confirm that I did the following:

llyyr commented 1 week ago

mpv v0.39.0-325-gd66ed2d8

Can you update mpv? This commit should fix it https://github.com/mpv-player/mpv/commit/ca7aeb71ee30f73b516a2cfc1b7afca9c10d75c5

Duplicate of #15288

mightyhuhn commented 1 week ago

i can't find a newer windows build. i literally just run the update.bat. source is https://mpv.io/installation/ https://github.com/shinchiro/mpv-winbuild-cmake/releases these do not look like windows executables to me.

someone actually used my old chromaloc "test pattern." i'm confused...

BTW. GPU does it more correctly then GPU-next.

llyyr commented 1 week ago

https://github.com/zhongfly/mpv-winbuild these update nightly

mightyhuhn commented 1 week ago

can confirm both do it wrong now the same way now.

llyyr commented 1 week ago

can confirm both do it wrong now the same way now.

Both do it correctly, and also match zimg output now.

top left should be moved bot right not somewhere else.

That would be incorrect, copying this from ffmpeg's documentation:

/**
 * Location of chroma samples.
 *
 * Illustration showing the location of the first (top left) chroma sample of the
 * image, the left shows only luma, the right
 * shows the location of the chroma sample, the 2 could be imagined to overlay
 * each other but are drawn separately due to limitations of ASCII
 *
 *                1st 2nd       1st 2nd horizontal luma sample positions
 *                 v   v         v   v
 *                 ______        ______
 *1st luma line > |X   X ...    |3 4 X ...     X are luma samples,
 *                |             |1 2           1-6 are possible chroma positions
 *2nd luma line > |X   X ...    |5 6 X ...     0 is undefined/unknown position
 */
enum AVChromaLocation {
    AVCHROMA_LOC_UNSPECIFIED = 0,
    AVCHROMA_LOC_LEFT        = 1, ///< MPEG-2/4 4:2:0, H.264 default for 4:2:0
    AVCHROMA_LOC_CENTER      = 2, ///< MPEG-1 4:2:0, JPEG 4:2:0, H.263 4:2:0
    AVCHROMA_LOC_TOPLEFT     = 3, ///< ITU-R 601, SMPTE 274M 296M S314M(DV 4:1:1), mpeg2 4:2:2
    AVCHROMA_LOC_TOP         = 4,
    AVCHROMA_LOC_BOTTOMLEFT  = 5,
    AVCHROMA_LOC_BOTTOM      = 6,
    AVCHROMA_LOC_NB               ///< Not part of ABI
};

topleft is correct now, and it wasn't before.

mightyhuhn commented 1 week ago

ahh specifications.

for completion. ffmpeg spec is right. 1 2 and 3 are just and shown correctly as they are placed in the 4:2:0 file.

in AVC and HEVC left top is 2 centre centre is 1 left centre is 0 i prefer to use these terms because this is what is actually used in encoding.

i will now keep to LT CC and LC.

so yes for UHD BD LT is correct that's where the chroma is but that's the issue for correct displaying placement in RGB you need to move it to the CC point and you do that by moving bot right. CC 420 chroma can be upscaled like luma and the result will match the luma channel that'S what we need for RGB.

LC needs to be moved right. CC doesn't need moving. LT we needs to move bot right.

there are exception it is called NN "scaling" this scaler will always move by half a subpixel. so if you use NN on LT you get CC as a result.

so now let me proof this. let's add wrong meta data to LT we use LC. where will the chroma look like relative to TL here is the answer: https://slow.pics/c/Rkkh1vpM

if the chroma is already top why does it move it even more top?

there are other traps that can be done wrongly. relative to the chroma channel it is only moved 0.25 which is the same distance as 0.5 luma.

astiob commented 1 week ago

if the chroma is already top why does it move it even more top?

The chroma isn't "already" anywhere. The renderer has to place it somewhere when aligning the planes. "Top" chroma must be placed at the top.

mightyhuhn commented 1 week ago

luma ahh...

astiob commented 1 week ago

("luma" was a typo, but I hope that was obvious)

mightyhuhn commented 1 week ago

no because it makes no sense. a chromaloc in a 420 tells you where the chroma is not where it needs to go when you do 444. if you go 444 you need to match luma which needs placement correction if it isn't centred using bilinear.

with LT we know the first luma has a chroma sample below it. if we upscale it with let's say bilinear it will bleed to the left and top... so what? moving more top fixes it by now bleeding an entire pixel? the smallest 420 progressive image is 4 luma and 1 chroma pixel so the top left pixel get's chroma all-round it and the rest get's some bleeding if they are lucky?

if the ffmpeg spec is wrong and LT means move chroma to that point because it is RB you would be right.

astiob commented 1 week ago

a chromaloc in a 420 tells you where the chroma is not where it needs to go when you do 444.

These are the same thing.

For more illustrations of chroma placement, see, for example, the pictures in fmtconv docs (scroll down for the picture; in particular, the very last example shows top-left chroma: black and white are the luma pixels; colours are the chroma).

the smallest 420 progressive image is 4 luma and 1 chroma pixel so the top left pixel get's chroma all-round it and the rest get's some bleeding if they are lucky?

Yes. If you have a single top-left chroma sample, that’s the value of chroma at the top-left luma pixel. For the other three luma pixels, the chroma is unspecified and needs to be interpolated. That’s literally what “chroma is at the top left” means.

It sounds like you’re realizing how silly subsampled chroma is, but why blame us?

astiob commented 1 week ago

a chromaloc in a 420 tells you where the chroma is not where it needs to go when you do 444.

These are the same thing.

Further to this: where a particular chroma sample “is” doesn’t depend on whether the format is 420 or 444. It stays in place, the same place. When going from 420 to 444, the upsampler must take care to preserve this place, and that’s exactly what gpu-next does (and now gpu). If the chroma is at the top left, then it must stay at the top left. If you have a single red spot of top-left chroma, this red spot must stay at the top left in 444.

with LT we know the first luma has a chroma sample below it.

Correct, if by “below” you mean “at the same planar position (but on a different layer)”. If it were actually below, it would be left or left-bottom chroma sample.

if we upscale it with let's say bilinear it will bleed to the left and top...

Correct.

so what? moving more top fixes it by now bleeding an entire pixel?

Nobody moves it anywhere. Where do you get this impression?

After upsampling, the original chroma sample stays where it is: in the same position as the top-left luma sample. The surrounding chroma is interpolated.

By contrast, you seem to be proposing that the chroma sample should be moved further down, which would change where it is (because that’s what moving does).

mightyhuhn commented 1 week ago

Further to this: where a particular chroma sample “is” doesn’t depend on whether the format is 420 or 444. It stays in place, the same place. When going from 420 to 444, the upsampler must take care to preserve this place, and that’s exactly what gpu-next does (and now gpu). If the chroma is at the top left, then it must stay at the top left. If you have a single red spot of top-left chroma, this red spot must stay at the top left in 444.

mpeg2 placement is LC so pretty much every video ever created since the DVD is LC (i don't care about half res mpeg1 DVD encodes what ever it's a spec it isn't used). to preserve a position you do nothing. if you flag a video LT it actively moves the planes to the top relative to LC so that flag does something. this is a FLAG it does not change the encoded video.

Nobody moves it anywhere. Where do you get this impression? because it clear does LT flag and the image is moved top who else moved it if not the chroma scaler?

After upsampling, the original chroma sample stays where it is: in the same position as the top-left luma sample. The surrounding chroma is interpolated.

yes you can do such an operation and this operation will move the chroma btw. i doubt anyone has written a scaler like that and instead using normal interpolation with an correction. with LT you can technical bob deint it as a top field turn it 90° and bob deint it as top field again.

with CC you can't do that and all pixel "moved" with LC you can do it in one way.

By contrast, you seem to be proposing that the chroma sample should be moved further down, which would change where it is (because that’s what moving does).

yes indeed that's the basic about chroma scaling you need to move the Cb and Cr plane to match Y. why do i have to say this. in RGB all planes have the same position. and GPU and GPU-next are already moving the planes it's just in the wrong direction.

how could GPU or GPU next do it wrong if we don't need to move in the first place?

Artoriuz commented 1 week ago

I think the key misconception here is what "chroma sample location" entails, and as @astiob already explained this term is literal, it simply tells you where you're sampling from.

For centre chromaloc each chroma sample contains an information that corresponds to a position centred between 4 luma samples. For left you merely move that half a pixel to the left, which means you're now between the 2 luma pixels that were previously at the left. And for top-left you simply sample at the exact same location your top-left luma pixel is.

You simply take this information into account when interpolating the samples to ensure your planes end up aligned.

astiob commented 1 week ago

i doubt anyone has written a scaler like that and instead using normal interpolation with an correction.

You should doubt less and research more.

Normal interpolation (upscaling with an interpolatory filter, e. g. bilinear) literally does this by definition. Some higher-quality upscalers also do this, e. g. nnedi3 copies one row of data verbatim and interpolates the next. Other upscalers intentionally recompute every output sample to provide a sharper and more cohesive overall picture.

and this operation will move the chroma btw

I have no idea what you mean here.

mpeg2 placement is LC so pretty much every video ever created since the DVD is LC (i don't care about half res mpeg1 DVD encodes what ever it's a spec it isn't used).

This is irrelevant. Left chroma is on the left. Top-left chroma is on the top-left.

if you flag a video LT it actively moves the planes to the top relative to LC so that flag does something. this is a FLAG it does not change the encoded video.

If you take a left-chroma video and retag it to top-left, then of course you’re moving the chroma, in the very action of retagging it. You’re now telling the player that the same colours are at the top, rather than at the centre, so when you play this file, it renders its colours at the top for you. Which is half a pixel above the centre. You’ve moved the location, not the player.

The rest of your response seems to be in agreement, so I don’t know why you’re arguing.

mightyhuhn commented 1 week ago

I think the key misconception here is what "chroma sample location" entails, and as @astiob already explained this term is literal, it simply tells you where you're sampling from.

For centre chromaloc each chroma sample contains an information that corresponds to a position centred between 4 luma samples. For left you merely move that half a pixel to the left, which means you're now between the 2 luma pixels that were previously at the left. And for top-left you simply sample at the exact same location your top-left luma pixel is.

You simply take this information into account when interpolating the samples to ensure your planes end up aligned.

i know all that.

now you look at the image and see it is moved an entire pixel to the top instead of correcting it to match the luma. which is moving it to the RB. i will stop using move i use interpolate to the RB better?

chroma doctrine

first line LC example second row LT and 3rd what mpv is seemingly doing.

it's like it thinks it is LB. like it is m... interpolated in the wrong direction.

if the pixel are already in the top left it has to interpolate the to the other luma pixel to the bot right. there is no way if we flag the same image as LC that it will look like it does. either LC is broken (please no) or LT is.

i can tell you from a very reliable source that madVR does not sample from position x and used X scales at the end just saying some scaler can't be used any other way and need to be m... in mean interpolated to the correct position after scaling like nnedi (not always).

Artoriuz commented 1 week ago

Any interpolatory filter can deal with this correctly, you need to output a chroma sample for each luma sample and at the top-left location the distance between the top-left sample you already have and the output sample you're trying to compute is (0, 0), the weight will be 1.0 for that sample and 0.0 for the others.

You're not explicitly moving anything, you're just correctly accounting for where the chroma samples are.

mightyhuhn commented 1 week ago

cool cool.

back to the important part. does it look like it is doing that correctly for LT?

kasper93 commented 1 week ago

LC needs to be moved right. CC doesn't need moving. LT we needs to move bot right.

On the contrary, but I think others have already explained why. Some say a picture is worth a thousand words, so perhaps we should communicate with images to align (pun intended) on the correct solution.

For example, with a 4.2.0 top-left input, one of these images shifts the chroma plane half a pixel towards the top-left, while the other shifts it towards the bottom-right. Which one looks better to you?

Image A: image Image B: image

can confirm both do it wrong now the same way now.

I think the easiest path moving forward is if you would provide input and expected output where gpu/gpu-next is not correct. And we can fix the rendering pipeline to produce output you expect.

Not sure if this simple visualization will help or produce more confusion. It is very simplified if it comes to upsampled values.

Y0 Y1 Y2 Y3
Y4 Y5 Y6 Y7
top-left chroma after upsampling:
C0 C0 C2 C2
C0 C0 C2 C2

C0 has to remain centered around Y0 and C2 around Y2. So we "move" it towards top-left, no?
center chroma after upsampling:
C0145 C0145 C2367 C2367
C0145 C0145 C2367 C2367

C0145 has to remain centered around Y0/Y1/Y4/Y5 and C2367 around Y2/Y3/Y6/Y7. So the planes are already aligned, no?
left chroma after upsampling:
C04 C04 C26 C26
C04 C04 C26 C26

C04 has to remain centered around Y0/Y4 and C26 around Y2/Y6. So we "move" it towards left, no?
Artoriuz commented 1 week ago

This is from a 4k HDR demo with top-left chromaloc: rgb luma Seems perfectly fine. Luma screenshot taken with a shader setting chroma to a constant vec2(0.5, 0.5) on all pixels.

mightyhuhn commented 1 week ago

LC needs to be moved right. CC doesn't need moving. LT we needs to move bot right.

On the contrary, but I think others have already explained why. Some say a picture is worth a thousand words, so perhaps we should communicate with images to align (pun intended) on the correct solution.

For example, with a 4.2.0 top-left input, one of these images shifts the chroma plane half a pixel towards the top-left, while the other shifts it towards the bottom-right. Which one looks better to you?

Image A: image Image B: image

can confirm both do it wrong now the same way now.

I think the easiest path moving forward is if you would provide input and expected output where gpu/gpu-next is not correct. And we can fix the rendering pipeline to produce output you expect.

Not sure if this simple visualization will help or produce more confusion. It is very simplified if it comes to upsampled values.

Y0 Y1 Y2 Y3
Y4 Y5 Y6 Y7
top-left chroma after upsampling:
C0 C0 C2 C2
C0 C0 C2 C2

C0 has to remain centered around Y0 and C2 around Y2. So we "move" it towards top-left, no?
center chroma after upsampling:
C0145 C0145 C2367 C2367
C0145 C0145 C2367 C2367

C0145 has to remain centered around Y0/Y1/Y4/Y5 and C2367 around Y2/Y3/Y6/Y7. So the planes are already aligned, no?
left chroma after upsampling:
C04 C04 C26 C26
C04 C04 C26 C26

C04 has to remain centered around Y0/Y4 and C26 around Y2/Y6. So we "move" it towards left, no?

the first issue with test files is we need one that is created correctly... so it does not matter which one looks better the obviously counts for my shared ones i got from madshi. i do not know if they are correct. the sample is provided the result is terrible that doesn't mean anything i use it for relativity to other results.

LC C0 is aligned between Y0 and Y4. if a dumb upscale is applied like with centred you need to move the result half a sub pixel to the right because it moved left.

why is this the case let's take CC. C0 is between Y0 Y1 Y4 and Y5. directly in the middle. if you would use NN they would be miss aligned. if again no offset bilinear is used they will magic move in place because around c0 4 new samples are created that will land directly where Y0 Y1 Y4 and Y5 are but the original location does not exist anymore.

LT C0 is directly where it should if it is upscaled it will build 4 pixel around Y1 none is matching and to match it needs to be moved bot right because it moved top right. now use NN and... the result will match.

images are currently not working so can not look at it... not even my own.

kasper93 commented 1 week ago

the first issue with test files is we need one that is created correctly...

You can use command like that to produce samples with different chroma location. (with recent ffmpeg)

ffmpeg -i rgb.png -vf scale=out_chroma_loc=topleft -pix_fmt yuv420p topleft.y4m

If you think samples produces this way are not correct feel free to report the issue on https://trac.ffmpeg.org/ , they should be helpful there to resolve it.

EDIT: You can also add flags=lanczos to make the scaling quality better, especially for center chroma it matters.

astiob commented 1 week ago

images are currently not working so can not look at it... not even my own.

If you’ve had the GitHub page open in the browser for a while, reload the page.

LC C0 is aligned between Y0 and Y4. if a dumb upscale is applied like with centred you need to move the result half a sub pixel to the right because it moved left.

No. If a dumb upscale like with centred is applied… applied to what exactly, in your mind?

If a dumb upscale like with centred is applied to the chroma plane independent of the luma, and then the result is overlaid on top of the luma without shifting, then the chroma has moved right. Not left. Because it should have been placed left, but you interpreted it as placed centre, which is more to the right of its real position.

The data is just numbers; they don’t have an inherent absolute position in space. The chroma plane is just a grid of numbers. You can take this grid of numbers and place it anywhere. In the above example, the chroma is just:

C0 C2

So, let’s say you upsample this grid of numbers, dumb like with centred.

You get a different grid of numbers. It still has no inherent position in space. It can still be placed anywhere. But each original sample has turned into a 2×2 square:

C0 C0 C2 C2
C0 C0 C2 C2

Then you take one grid of numbers (the luma) and another (the upsampled chroma) and put them together. This is the first time that some semblance of position physically manifests. Usually, we want these two planes to be aligned, so that the co-sited (= placed together) chroma and luma can together be converted to RGB. So you end up with:

Y0+C0  Y1+C0  Y2+C2  Y3+C2
Y4+C0  Y5+C0  Y6+C2  Y7+C2

So where did the chroma move?

If the video file says that the original (downsampled) chroma was actually located top-left, then where has the chroma moved now?

does it look like it is doing that correctly for LT?

Well, yes.

It seems this thread has devolved into several people explaining from the ground up what chroma positioning is. This is great and all, but do keep in mind that there are other learning resources out on the web that explain this and are publicly available. If you’re confused, I recommend searching and consulting those resources, too.

kasper93 commented 1 week ago

It seems this thread has devolved into several people explaining from the ground up what chroma positioning is. This is great and all, but do keep in mind that there are other learning resources out on the web that explain this and are publicly available. If you’re confused, I recommend searching and consulting those resources, too.

I agree. It would probably be explained much better than the examples in this thread.

mightyhuhn commented 1 week ago

the first issue with test files is we need one that is created correctly...

You can use command like that to produce samples with different chroma location. (with recent ffmpeg)

ffmpeg -i rgb.png -vf scale=out_chroma_loc=topleft -pix_fmt yuv420p topleft.y4m

If you think samples produces this way are not correct feel free to report the issue on https://trac.ffmpeg.org/ , they should be helpful there to resolve it.

EDIT: You can also add flags=lanczos to make the scaling quality better, especially for center chroma it matters.

that was your idea and lanczos didn't save it: https://slow.pics/c/9kTaI7MN

ffmpeg.exe -i Gundam5.png -vf scale=out_color_matrix=bt709:out_chroma_loc=center:flags=lanczos -pix_fmt yuv420p centrelan.y4m ffmpeg.exe -i Gundam5.png -vf scale=out_color_matrix=bt709:out_chroma_loc=left:flags=lanczos -pix_fmt yuv420p leftlan.y4m ffmpeg.exe -i Gundam5.png -vf scale=out_color_matrix=bt709:out_chroma_loc=topleft:flags=lanczos -pix_fmt yuv420p topleftlan.y4m

x264.exe --crf 0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --chromaloc 1 --output "centrelan.mkv" "D:\mpv chroma positon\centrelan.y4m" x264.exe --crf 0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --chromaloc 0 --output "leftlan.mkv" "D:\mpv chroma positon\leftlan.y4m" x264.exe --crf 0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --chromaloc 2 --output "topleftlan.mkv" "D:\mpv chroma positon\topleftlan.y4m"

i don't know who is to blame but that looks moved to me.

edit: false positive from bilinear: the original i didn't create move like crazy ignore GPU leftop https://slow.pics/c/YNnEmLwg

kasper93 commented 1 week ago

https://slow.pics/c/9kTaI7MN

Looks good. Are there remaining issues we should look into?

ValeZAA commented 1 week ago

Do you even realise how simple is it to verify?? OMG! Just take true 444 or better RGB or even XYZ video and encode to top-left. Then you will see that best SSIM (structural similarity) is if you decode with top-left. Try this file, JPEG 2000 XYZ12 https://www.sandflow.com/public/mer_shrt_23976_vdm_sdr_rec709_g24_3840x2160_20170913_12bit_DCDM.4bpp.mxf

Also the FIR (finite impulse response) filter calculus for each of chroma sample location is specified with high detail in H series supplement 15. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.Sup15-201701-I!!PDF-E&type=items

mightyhuhn commented 1 week ago

Do you even realise how simple is it to verify?? OMG! Just take true 444 or better RGB or even XYZ video and encode to top-left. Then you will see that best SSIM (structural similarity) is if you decode with top-left. Try this file, JPEG 2000 XYZ12 https://www.sandflow.com/public/mer_shrt_23976_vdm_sdr_rec709_g24_3840x2160_20170913_12bit_DCDM.4bpp.mxf

Also the FIR (finite impulse response) filter calculus for each of chroma sample location is specified with high detail in H series supplement 15. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.Sup15-201701-I!!PDF-E&type=items

wow just think about if someone would have actually done that! ohh wait it was even shared here i wonder how you missed that.

https://slow.pics/c/9kTaI7MN

Looks good. Are there remaining issues we should look into?

this is the interesting one one: https://slow.pics/c/YNnEmLwg i need to know how they got created ffmpeg is "matching". LT is clearly placed to high and again ignore GPU. if they are created wrongly then there is no issue anymore.

kasper93 commented 1 week ago

this is the interesting one one: https://slow.pics/c/YNnEmLwg i need to know how they got created ffmpeg is "matching". LT is clearly placed to high and again ignore GPU. if they are created wrongly then there is no issue anymore.

If we are talking about 420.zip from the first post. All three files are bitexact for image data, the only difference is chroma placement tagging. I don't know how were they created, but it is clearly not correct as the metadata should reflect the image data.

This is all the difference between those files.

diff -u <(xxd Gundam5CC.mkv) <(xxd Gundam5LT.mkv)

--- /proc/self/fd/11    2024-11-13 14:11:30.000000000 +0100
+++ /proc/self/fd/12    2024-11-13 14:11:30.000000000 +0100
@@ -8,7 +8,7 @@
 00000070: 54ae 6be8 aee6 d781 0173 c581 0183 8101  T.k......s......
 00000080: 9c81 0086 8f56 5f4d 5045 4734 2f49 534f  .....V_MPEG4/ISO
 00000090: 2f41 5643 63a2 ad01 f400 20ff e100 1d67  /AVCc..... ....g
-000000a0: f400 20ae b200 b00c bcb3 cd40 4040 6940  .. ........@@@i@
+000000a0: f400 20ae b200 b00c bcb3 cd40 4040 6dc0  .. ........@@@m.
 000000b0: 0000 0300 4000 01f4 03c6 0c92 0100 0568  ....@..........h
 000000c0: ebc0 6bcb e096 b082 0578 ba82 0314 54b2  ..k......x....T.
 000000d0: 8100 54b0 8205 7854 ba82 0314 1f43 b675  ..T...xT.....C.u

I'm closing the issue. If there is anything else missing, feel free to provide more information.

ValeZAA commented 1 week ago

If there is anything else missing, feel free to provide more information

There would be no difference if all three files were not bitexact for image data. Assuming mpv decodes correctly that is. Top left image data decoded as top left would look the same as left decoded as left.

@mightyhuhn What are you saying? Is there a bug in decoder from 420 to 444 top left 420?