Some HDR .PNGs do not open

[marat569]

I found the root cause of the issue

Its the sBIT size being 4 (RGB + Alpha) -- while ffmpeg expects 3

---

mpv Information

MPV mpv-x86_64-v3-20240609-git-d2bd77a
FFMPEG ffmpeg-x86_64-v3-git-be2cabce3

Important Information

W11 pro 23h2 Nvidia 4090

Reproduction Steps

So some HDR .PNG files don't open, and if you open the console via hotkey, you get [vd] Error while decoding frame!

Some HDR .PNG files open, so I don't know the difference

To reproduce you'd use my .conf file + enable HDR in windows + open the .png file with MPV

The required files can all be found below under the log file section I zipped up all the HDR PNGs to avoid the browser from potentially "messing" with the file.

All my other programs and hdr viewers can open both images just fine. Just a tool I use often to take screenshots creates the HDR PNGs that don't work with mpv.

If ya'll need more info, I'll be happy to provide it.

Also sorry for not providing direct commands, hdr images need a fair few arguments -- so I thought sharing my entire conf would've been better for everybody.

Expected Behavior

MPV would open the hdr png -.-

Actual Behavior

It doesn't :c

Log Files / Sample Files

HDR PNG - WORKS.txt -- Log for working HDR PNG

Doesn't Work -- HDR PNG.txt -- Log for Broken HDR PNG

mpv.conf.zip -- My MPV.conf

HDR PNG - WORKS.zip -- Working HDR PNG

HDR PNG - DOESNT WORK.zip -- Broken HDR PNG

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

• [X] I tested with the latest mpv version to validate that the issue is not already fixed.
• [X] I provided all required information including system and mpv version.
• [X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• [X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• [X] I attached the full, untruncated log file.
• [X] I attached the backtrace in the case of a crash.

[llyyr]

This is an ffmpeg bug, I can confirm that it works in the browser but not with ffplay/ffmpeg.

[richardpl]

Happily to inform you that latest Librempeg does not have this bug.

[MasterInQuestion]

    "HDR PNG - WORKS.zip"?     Probably irrelevant of HDR.

    Mostly just certain PNG outright not decodable with FFmpeg.

    See also: https://trac.ffmpeg.org/ticket/11002#comment:21

    Fix related:     https://github.com/librempeg/librempeg/commit/86473583b4cd11595f2d372666115024124d429f

    Also, browsers typically don't do alike "messing".     (the hosting service may do: deeming the file unreasonably large and recompress)

[marat569]

"HDR PNG - WORKS.zip"?     Probably irrelevant of HDR.

    Mostly just certain PNG outright not decodable with FFmpeg.

    See also: https://trac.ffmpeg.org/ticket/11002#comment:21

    Fix related:     https://github.com/librempeg/librempeg/commit/86473583b4cd11595f2d372666115024124d429f     Also, browsers typically don't do alike "messing".     (the hosting service may do: deeming the file unreasonably large and recompress)

What I had in mind is discord lol -- they sometimes mess with the hdr pngs when converting to webm . I know github embeds images, so I was worried it might "mess" with the png when making the embed.

but thanks for the fix!

hopefully they'll accept the commit soon :tm:

[MasterInQuestion]

    I have some doubt on whether the HDR thing could possibly make sense.

    See [ https://trac.ffmpeg.org/ticket/11002#comment:5 ] for relevant hints.

[marat569]

@MasterInQuestion sorry for the spam, but would you be able to build me ffmpeg with the fix in your other post please; so I could try it out

I don't have tools setup rn to compile it myself

[marat569]

I found the root cause of the issue

Its the sBIT size being 4 (RGB + Alpha) -- while ffmpeg expects 3

[Traneptora]

The file is broken.

$ umbrielpng HDR\ PNG\ -\ DOESNT\ WORK.png 
PNG signature found: HDR PNG - DOESNT WORK.png
Chunk: IHDR, Size: 25, Offset: 8, CRC32: 4f4c8066
Chunk: pHYs, Size: 21, Offset: 33, CRC32: d2dd7efc
Chunk: tEXt, Size: 31, Offset: 54, CRC32: ca46f697
Chunk: tEXt, Size: 45, Offset: 85, CRC32: 9d3d1317
Chunk: iCCP, Size: 2228, Offset: 130, CRC32: f0ff74cc
Chunk: cICP, Size: 16, Offset: 2358, CRC32: fe23234d
Chunk: cLLi, Size: 20, Offset: 2374, CRC32: e94660c9
Chunk: sBIT, Size: 16, Offset: 2394, CRC32: cdc95700
Chunk: cHRM, Size: 44, Offset: 2410, CRC32: 72676df9
Chunk: mDCv, Size: 52, Offset: 2454, CRC32: 9566d5a1
Chunk: IDAT, Size: 65381, Offset: 2506, CRC32: caf17293
Chunk: 31 more IDAT chunks
Chunk: IEND, Size: 12, Offset: 2091632, CRC32: ae426082
Size: 3840x2160, Color: 16-bit RGB
tEXt key: Software
tEXt key: Creation Time
Warning: computed CRC32 cc74fff0 does not match read CRC32 f0ff74cc
Warning: computed CRC32 4d2323fe does not match read CRC32 fe23234d
Warning: computed CRC32 c96046e9 does not match read CRC32 e94660c9
Warning: computed CRC32 0057c9cd does not match read CRC32 cdc95700
umbrielpng: Warning: Illegal sBIT chunk
Warning: computed CRC32 f96d6772 does not match read CRC32 72676df9
Warning: computed CRC32 a1d56695 does not match read CRC32 9566d5a1

[ValeZAA]

Should be fixed by https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/3fca5877d0341578eb4cb23ba74b71c8637f81a0