mary :)

720p when? i need 720p

thanks mary

Mary ❤

Blown out lighting compared to just letting mpv handle the hdr -> sdr conversion? https://slow.pics/c/AN5Se6e6 I also feel like the SDR conversion lighting is worse than just letting mpv map. https://slow.pics/c/USN95uWW Also no chapters.

> I have a 1440p display that is not HDR Lmfao

If you're confident enough to edit an mpv config, then yes, you should download an HDR remux and watch that. But that doesn't describe everyone, or rather, it describes hardly anyone in the grand scheme of things.

> confident enough to edit an mpv config lol? Setting gpu-next (vo=gpu-next) takes next to no effort and is probably going to be changed as the new default relatively "soon" to phase out the old gpu vo. If people are already going through the effort of installing mpv since everyone now puts in their description that their release / subs only work best with mpv, it's not that much more effort to use gpu-next for tonemapping. Heck, it's also not that much more effort to also add profile=high-quality alongside it. You're claiming your SDR version is best for people with 1440p SDR monitors when that is strictly not true - both in conversion errors and worse mapping. If the 1080p BD wasn't so fucked up, it would probably also have more proper lighting than your conversion. mpv can handle tonemapping pretty well now and much better than this. Even for 1440p+ SDR only monitors. This encode is just going to age poorly as the worst choice when mpv defaults are changed and pushed more widespread. > then yes, you should download an HDR remux and watch that Don't even have to download remuxes. There are HDR encodes that look better on SDR monitors.

Anyone that cares about quality should be using a nightly build of mpv (or something newish containing the more recent profile changes) and set this to your mpv.conf. https://github.com/shinchiro/mpv-winbuild-cmake/releases ``` vo=gpu-next profile=high-quality ``` Anyone that cares about frame pacing can add this to help with jitter. ``` video-sync=display-resample ``` Have a 60hz monitor or something not cleanly divisible by 23.976 fps (120hz/144hz/240hz)? Guess what, you're affected by 2:3 pull-down as well. If you happen to notice it, you can add interpolation to help with that but don't recommend changing the tscale away from the default oversample unless you like blur! You're already trading blurring frames trying to fix the problem, why make it worse. ``` interpolation blend-subtitles ``` Anyone looking for something more advanced can look into pixel doublers, but I don't recommend anything other than these unless you like haloing / sharpening artifacts from FSRCNNX or Anime4K smoothing. You can edit nnedi3 to always double for 1080p and get better results downscaling to 1440p which doesn't run into any haloing or sharpening problems ewa_lanczossharp sometimes does upscaling. All without needing to add anti-ringing to the config which kills detail. ``` glsl-shader="~~/shaders/nnedi3-nns64-win8x4.hook" glsl-shader="~~/shaders/KrigBilateral.glsl" ``` Super autistic and notice the half pixel shift when doubling evenly with nnedi3? (720p -> 1440p) Yep, can even "fix" that by trading slight sharpness. ``` scaler-resizes-only=no ```

> Don’t even have to download remuxes. There are HDR encodes that look better on SDR monitors. please don't do that. just get the remux > interpolation please buy a gsync monitor > glsl-shader="\~\~/shaders/nnedi3-nns64-win8x4.hook" > glsl-shader="\~\~/shaders/KrigBilateral.glsl" meme shaders are not good other than nnedi3, and even that is situational

> please don’t do that. just get the remux lol. > please buy a gsync monitor display-resample does not work with VRR and gsync range doesn't even support 24hz for low framerate compensation. You're better off buying a monitor that is divisible evenly, otherwise gotta live with interpolation if you don't want 2:3 judder. This is the blending of every other frame (i.e. madvr smoothmotion), not SVP 60fps fake frame garbage. https://mpv.io/manual/master/#options-oversample https://mpv.io/manual/master/#options-interpolation MPV isn't even VRR aware unless you force it and try to double / triple frames. Also enjoy the flickering / stutter using gsync on VFR video that randomly jumps between 24hz and 30hz. > meme shaders are not good other than nnedi3, and even that is situational Where did I recommend a meme shader? nnedi3 is a pixel doubler for luma and KrigBilateral is a chroma scaler which is more accurate than ewa_lanczos. If you want something not as resource intensive, you can use ravu for luma (not as good) or CfL Prediction for chroma (not as thoroughly benchmarked and tested against Krig yet).

> display-resample does not work with VRR Because display-resample is for copers who dont have VRR > gsync range doesn’t even support 24hz Just false, good gsync monitors go all the way down to 1hz > You’re better off buying a monitor that is divisible evenly Doesnt exist, 24hz (or a multiple of 24) still gives judder on 23.976hz content without speedup

> KrigBilateral is a chroma scaler which is more accurate than ewa_lanczos Mathematically that is true. But it also creates insane artifacts when it screws up lol

> Because display-resample is for copers who dont have VRR The whole point of display-resample is to do micro speedup and slowdowns to calculates the timing between each frame and keep consistent frame pacing. The real cope is interpolation, not display-resample, to fix the pulldown judder. > mpv will display 1 frame every 1/23.976 seconds. video-sync determines when it actually sends the frame and how it calculates the timing between each frame. By default it times frames to match the audio timer, so it is completely divorced from the actual video card/TV timings. This can lead your video to get slightly out of sync since the timers don't match exactly. When mpv detects this it will drop video frames or repeat them to catch up - this can lead to stutter or jerkiness. > > display-resample improves this by syncing to the video clock, which should lead to the overall smoothest video. It does this by dropping/duplicating/stretching audio samples instead to keep a/v in sync, which is far less noticeable because there are so many more audio samples (e.g. 44khz). You can observe the vsync ratio and jitter to see how it is timing, no frames should be mistimed or dropped unless there is an issue. > > G-sync should be disabled, it messes up display-resample. > Just false, good gsync monitors go all the way down to 1hz My mistake, I had to look it up to double check. The gsync standard doesn't go to 1hz. Gsync ultimate goes to 1hz but the number of monitors which use that is small and you must cope with a fan. Then they also changed the gsync ultimate standard to be more relaxed. Freesync (standardized VRR) also doesn't support LFC that low. Studio grading monitors aren't using gsync ultimate. > Doesnt exist, 24hz (or a multiple of 24) still gives judder on 23.976hz content without speedup Not sure what monitor you are using but mine supports setting hz on an integer not forced rounded. I only wrote 24hz to simplify.

> But it also creates insane artifacts when it screws up lol I would love to see these artifacts. In my own comparisons and benchmarks, Krig always was a net positive and had more accuracy to color intent. Specially around reds.

> The whole point of display-resample is to do micro speedup and slowdowns to calculates the timing between each frame and keep consistent frame pacing. Which is pointless when you have VRR. With VRR you get perfect frame pacing without speeding up or slowing down the video. display-resample also breaks on VFR content, where VRR works perfectly.

> With VRR you get perfect frame pacing without speeding up or slowing down the video > display-resample also breaks on VFR content, where VRR works perfectly. I'm calling doubt on this. Just a couple months ago VRR was being discussed by mpv devs. https://github.com/mpv-player/mpv/issues/12005 > Moving the cursor sometimes introduces a slight hiccup as the cursor update pushes the display from content-synced mode into maximum refresh, but this is not hugely noticeable at 175 Hz. > LFC on my display+GPU combo works fine for normal content, but may stutter/flicker sometimes when the framerate suddenly changes (e.g. VFR going from 24 Hz to 30 Hz). This effect seems transient though. I haven't yet tested it on "true" VFR content (where every frame is timed differently, rather than being merely a glued-together series of CFR segments) > ~30 Hz content sometimes likes bouncing between 60 Hz (frame doubling) and 90 Hz (frame tripling), but this doesn't appear to cause any visible issues. Not to mention all the driver and OS bugs that have existed with VRR in the past. I'll have to do my own testing down the road but nevertheless, the number of gsync monitors that actually support LFC is not significant. Finding a monitor that can be close to or exactly divisible would likely be more common, or using the "copium" settings to avoid blindly spending money on something that might not fix the problem.

> I’m calling doubt on this. Just a couple months ago VRR was being discussed by mpv devs. This discussion is about VRR+LFC, which is just an issue of low quality monitors not having good VRR ranges and poor LFC implementations. A proper VRR display won't have any of these problems.

> the number of gsync monitors that actually support LFC is not significant Are these gsync monitors that don't support LFC in the room with us right now?

> Are these gsync monitors that don’t support LFC in the room with us right now? They are in your walls, tear them up to find the magical non-LFC gsync display (gsync certification requires LFC) Only time you have to cope with LFC is when you want to buy Freesync display that is NOT freesync premium as its not mandatory in lower tiers. Oh also funfact, you could just use mpv for conversion and encode it, would probably look better and create no drama when they are making comps and its 1:1.

> you could just use mpv for conversion and encode it citation needed, I tried to do this and failed to figure out how. Fairly sure it's not actually possible. Ended up using libplacebo in ffmpeg, which I thought would be the same thing but apparently not. Version differences maybe? I had `-vf libplacebo=colorspace=bt709:color_primaries=bt709:color_trc=bt709:range=tv:format=yuv444p10le`, letting jesus take the wheel on the tonemapping settings since I didn't want to second-guess the defaults. EDIT: And at any rate, honestly, it's not clear that this encode is worse than playing the HDR remux in mpv. We would need more than two cherrypicked comparisons to make that decision. But I know making the comp would be a pain, so I don't exactly expect anyone to do it.

> two cherrypicked comparisons to make that decision Copium. It was the first two areas I randomly checked to compare, scrolling keyframes from the chapter marks using 'osd-msg-bar seek +5 relative+keyframes', not cherrypicked to find worse results. Your encode is just that flawed.

You're right, those two comparisons definitely prove beyond a shadow of a doubt that this encode is no good 👍

Certainly shows overblown lighting in areas and less lighting in others.

https://slow.pics/c/MgVHfNhL All right, look. This is a comp of two screenshots taken in mpv, one where where I seeked to a particular frame, and one where I let mpv play from the beginning. The "seek" frame makes a better tonemapping decision because it's not stuck with the adaptive peak decision that mpv made based on what it saw in the seconds leading up to this frame. In other words, seeking to a particular frame and taking a screenshot is an incorrect method of making a comp because mpv will make better decisions on a per-frame basis than a per-scene basis. In the interest of resolving this stupid discussion, I'll try to make a comp by playing the movie from the beginning, taking screenshots periodically, and matching them to the encode. I will post the results.

Huh, that's interesting. I'm able to reproduce that oddity using ``end=00:00:40.082`` & manually seeking to that frame, but the peak variance doesn't seem as extreme as in your example. Seems like it would be a bug if it needs to rely on previous frame information considering the vast majority of comparisons usually are done by seeking. I'll double check and recompare the same frames using playback instead of seek.

https://slow.pics/c/btulIY5o I prefer mpv. It's nice that my encode is overall brighter, but not at the cost of washed out highlights like this. Fun fact: the September 17 windows mpv build has washed out highlights that are identical to my encode. Which makes sense, since that's about the date of the ffmpeg build I used to make the encode. So a month's worth of updates to libplacebo made my encode obsolete. It's great that such active development is going on... (and it's also good to know that ffmpeg libplacebo can faithfully replicate mpv, as long as you have a recent enough build.) EDIT: the highlights are also washed out if you don't set gpu-next on master.

For what it's worth, I don't notice the seek vs playback bug in my comparisons because it's the 1st frame of every new scene. The variance bug _does_ seem to exist for in-scene frame comparing, just not at the start of the scene. So wouldn't have been relevant to my initial comparison anyways. I'll upload the new comparisons comparing seek vs playback in a moment.

Animeland 4k HDR vs Beatrice 4k HDR vs Lazy 4k SDR https://slow.pics/c/RJUVNTA1 Comparison 1 start of the scene at end=00:02:29.941 Comparison 2 start of the scene at end=00:05:36.003 Seeking was done by framestepping to the very 1st frame of the scene. CTRL+RIGHT frame-step ; show-text "Frame: ${estimated-frame-number} / ${estimated-frame-count}" CTRL+LEFT frame-back-step ; show-text "Frame: ${estimated-frame-number} / ${estimated-frame-count}" Playback stopping was done by config stopping at a specific time. ``` mpv v0.36.0-518-g1dd71a60 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects built on Oct 11 2023 01:15:39 libplacebo version: v6.338.0-30-g7ca8418-dirty FFmpeg version: N-112442-g6028728bb FFmpeg library versions: libavutil 58.27.100 libavcodec 60.30.102 libavformat 60.15.100 libswscale 7.4.100 libavfilter 9.11.100 libswresample 4.11.100 ``` None of this was me trying to attack you, I just stand by what I said with the mpv tonemapping being done better even for sdr monitors. > the highlights are also washed out if you don’t set gpu-next on master. Yes but hopefully gpu-next will be made the new default soon™️since it is better than the old one. Anyone who wants to do config editing should use it. Otherwise with time whenever it is changed, the encode would have become the worse option.

Followup: if anyone succeeds in replicating git master gpu-next default tonemapping with libplacebo ffmpeg (preferably a windows build), please let me know. I'm not sure how to make it happen.

It's always better to encode HDR as HDR because nowadays it's very easy for anyone to convert to SDR in real time on any video player with the settings that suit them personally. I used SDR conversion in some of one my encoding for a long time ago because at that time HDR wasn't that common. But doing this in 2023 is strange. By creating SDR encoding, you are forcing one option on everyone, which can become very outdated over time. This is the single most serious problem with this type of coding. I don't understand why you spend so much time arguing about the quality of SDR conversions. It's a bit pointless.

The point of this release is for people who don't have HDR capable displays and can't do tonemapping for one reason or another. The filtering done here doesn't really improve on the UHD BD to begin with, so if you want HDR just grab the remux.