Latest-ish MPC-HC ported for XP

[D.Draker]

I don't know what happened, I dunno whose fault it is, but the picture quality simply went down. LAV filters could be the reason.

[dmiranda]

Hi, unfortunately i can;t login into mydifitallive foum. My settings (quad9 secutirty, DOH, etc) may be it.
I'm looking to try the last MPV build for XP by Maroc. If someone finds the time, would you post it here? thanks!

[j7n]

The link from the head post is this. I don't know if the version is the latest.

http://j7n.sytes.net/temp/mpv-0.35.0.7z

https://pixeldrain.com/u/TsU8ihJu

Edited November 26, 2024 by j7n

[nicolaasjan]

8 hours ago, dmiranda said:

Hi, unfortunately i can;t login into mydifitallive foum. My settings (quad9 secutirty, DOH, etc) may be it.
I'm looking to try the last MPV build for XP by Maroc. If someone finds the time, would you post it here? thanks!

And here is a pdf with all the links to his latest apps done for XP.

[j7n]

GTX960/CUVID seems to only work with 8-bit H.265. Higher crashes or falls back to software. This is disappointing because most h.265 is 10-bit. Although most content I care about is still available in h.264. 10-bit h.264 is also not handled on the GPU. I launched seven Web-grade 8-bit videos, video engine load 44%, power draw 40 watts. The eighth video shows black screen, lol. It can also do seven decent full HD h.264 videos with CABAC with about 50% engine and 60% GPU usage. One video draws 30 watts, quiet as a mouse.

Does h.265 work with a later version of Windows NT on GTX960? I don't have time to install a new OS now, and I'm tired dealing with its flat/white/permissions issues. Could it be that CUVID wasn't updated because the Nev guy has deprecated it? He has shown much disdain towards old technology.

There still seems to be vocal support for h.264 among film archival sites, even though they don't care about WinXP per se.

[D.Draker]

12 hours ago, j7n said:

GTX960/CUVID seems to only work with 8-bit H.265

You'd need a GTX1060 or similar. 

[j7n]

https://forums.developer.nvidia.com/t/will-hevc-main-10-profile-decoding-work-using-cuvid-when/44981

"the developer has no interest in exposing 10bit support as long as it doesn’t return 10bit output frames"

"What you can do it is convince it to decode the 10bit content and then dither it down to 8bit to return as NV12. This is undocumented, and I discovered it by accident"

"I am not sure if LAV Video Decoder’s developer will do" - of course Nev can afford a €2000 GPU from NASA and has no interest.

https://forums.developer.nvidia.com/t/hevc-main-10-profile-decoding-using-vdpau-unsupported-on-gtx-950-361-28/41557

"Today, the driver doesn’t support MAIN 10, although the hardware does (hence why MAIN 10 works on windows)."

So from what I hear it does work, but you have to use Microsoft's interface on new Windows. Of course at the quality of web video there are no more tha 8 good bits, so stupid for Nvidia not to give the video.

[user57]

so there is progress in this one now ? what is the status ?

that with the bit depth is a longer discussion
as for RGB 8 bit per color or RGB 24, it dont improve any pixels
as it supports already over 16 million possible resolution per 1 pixel
even on a 4 k video you need a lot less then that for the entire frame (8,8 million pixels)

so if you copied a picture in RGB you got a lossless picture, but it get big in filesize

many camera´s actually dont resolve 4 k either (yet), useally they are upscaled 
those who actually can do nativ 4 k are rare
i dont want to advertise them but here are the only 2 i know that resolve nativ 4 k
https://www.red.com/red-tech/red-tech-red-ranger-with-monstro-8k-vv
https://www.arri.com/en/camera-systems/cameras/alexa-lf

notice the smallers versions of those dont resolve that resolution 
sometimes even these dont resolve 4k if the low light performance is coming for example
or the lens is not on the best spot 
also from consideration is how many light the object emmits (if the shutter speed is high the momentums get more bad)
its a very long discussion

many lenses dont resolve that resolutions either, and for a nativ performance you need a large sensor or/and very good light
https://www.dxomark.com/Lenses/

to me it raise questions to go higher because its getting less of a compression
jpg is a yuv 4:2:0 compression, there might be other modes - but they not very common (main 10 main 12)
where only 4:4:4 can resolve the maximum, but for this useally RGB 8 bit or RGB24 is used
going to 10 bit raise exactly that question, the filesize will go up, in sence of bit from 8 to 10 bit its 25 % 
so lets say you have a 750 mb video would have 937 mb video
what i for example want is better performance for the same filesize, not a increase for example in bitrate that cause a few more pixels but a bigger file

the hardware compressions for a stream useally dont produce that much quality either

i think they might have to use a older compression version and have to use medium to keep the frames to realtime

https://youtu.be/5rgteZRNb-A?t=72

we can see that software performed a lot better (both P3 and P6) (well seen at the white parts at the mountains)

we might start this pixel discussion that way, but being set to peak performance
because in other case it might cause a few more pixels with 10 bit because the encoder performance needed to be realtime

hard to say

if 10 bit it should be reasoned 

[j7n]

I don't think there is progress because the threads I found were from 2016. It was found to be possible then by Philipl from nVidia, but there was no interest putting it into MPC-HC. Something was done in ffmpeg, but I think that doesn't apply to us.

I think 10-bit exists because during mixing and prediction of successive frames error accumulates, and the bottom 1 or 2 bits are not accurate anymore. So instead of losing bit 8, we lose bit 10, which is much smaller. DVD MPEG-2 video was also partially 10-bit, I think only in the DC coefficient, but don't quote me on that. This is why you didn't see banding on DVD, but the banding appeared in H.264 DVDrip, which was only 8-bit. If you boost a dark JPEG with curves, you can also find that the bottom 0..2 levels are blocky at maximum quality.

Regardless of the reasons, 10-bit exists for quality encodes, and we should ideally be able to watch it.

[j7n]

On Windows 2008 R2 10-bit h.265 works with 442.74. Six 50 fps videos playing. I can't even play 1 on CPU. Even screenshot works.

https://i.imgur.com/p5S3PTa.png

[user57]

i remember that effect quite often

https://fixthephoto.com/images/content/banding-in-photography.jpg

also in a raw format

but it raise questions why it happend

those stream encoders have to be realtime therefore they probaly cant use the encoder/decoder to the maximum extend
if the bitrate then drops they are more likely to apear

the next picture is wrong but:
https://fixthephoto.com/images/content/banding-in-photography-bit-mode.png

it says 16 million colors but actually the color palett to the left only has 22 colors instead of 16 million

one reason can be that there is not enough color differences aka only having like 16 colors
a other is that the picture/or pixel had to be repeated
a next reason is that somewhere before the progression unit what somewhere before arranged it inperfect
a next reason would be no 100 iso (if iso is pushed you have less information, also in colors)
a lack of dynamic range or a strong light differense can also be the reason

hard to say what exactly caused either the RGB to not having 1 contrast difference or in YUV why it also dont can make 1 contrast difference

i think we need pictures to really see if that is the case, and if yes how many the filesize actually increases, if its 20 % we just could use a higher bitrate and might have the same result

you might have some information for us ?

to the other part if version 442.74 can do this it raise the question if older versions can set this mode

we dont have insight into the nvidia driver source code but
therefore i would say if people from here just try to find where the problem rely it will be hard to figure out

regarding 1 cpu thats to simple to say we dont have insight into the entire thing
the entire os is also running in the background, then somewhere is the player,
that LAV engine and that d3d video engine + more (maybe the driver ? more engines ?)

it dont play just the h.265 codec
someone would actually have to study the player and engines - and then might fail because he cant see into the nvidia driver (since that LAV engines or d3d video engine calls up that somewhere somehow)

thats why i the past i pointed out it might be better to have a own engine 
the full source code is available at x265.com

but writing from here you also then have some work to bring this into that MPC-HC player

i might point out that the XMM registers are a lot faster in this like 5-150 times
(sometimes called SSL but mmx ssl, avx are the same origin and still are called XMM registers (maybe added a ZMM sometimes)) 
a pure player/decoder should not cause many cpu power - the encoder need a lot more

 

it certainly would be possible to bring that x265 decoder to that MPC-HC player - the question is rather who makes the work 

[user57]

somehow that website x265.com was down and changed weird ? also https://bitbucket.org/multicoreware/x265/ is down

here is a working one:

https://github.com/videolan/x265

https://www.file-upload.net/download-15418681/x265_3.5.tar.gz.html

[j7n]

When you go from RGB to Y'CbCr, you immediately lose some accuracy because there is a many to one relationship. Think what happens if Y is at 0 for minimum brightness, a variation in Cb (blue) or Cr (red) will give some negative colors, which will get clipped to black. Same happens at white. Then the range of video only utilizes values between 16 and 240 instead of 0 to 255, which is a legacy of TV where signal below black had other meanings. Here you compress the remaining values again. The range of blue and red is also smaller because more perceptual weight is given to green. When YCbCr is expanded back for display, some RGB combinations will never occur.

Here is Y'CbCr conversion loss visualized:

https://webdesignerdepot-wp.s3.us-east-2.amazonaws.com/2023/11/28121730/rgb-ycbcr.png

In HCenc MPEG-2 encoder, a choice between 8, 9, 10 and 11 for DC precision is given. Even if YV12 is passed directly from one program to another without conversion to RGB, the extended precision of DC (average color for the block) is lost.

I've heard from encoders of Anime content that they can produce smaller files at 10 bits because the quality factor can be lower and dithering doesn't need to be added. It used to be that grain needed to be added to combat banding.

There is now a JPEG encoder called Jpegli, which can preserve more accuracy by doing the intermediate calculations at higher precision. But to recover the data a JpegLi decoder is needed.

[D.Draker]

On 11/27/2024 at 4:05 PM, j7n said:

I don't think there is progress because the threads I found were from 2016.

Nvidia drivers are strictly close source, no docs to be found to even start a work here.

[D.Draker]

On 1/19/2024 at 4:57 PM, Dixel said:

Of course it's "less resources" for you simply because Windows XP doesn't support DirectX11, it never did, run DxDiag to see, hence less depth and the weird brightness, there's simply no acceleration when you choose DX11 on XP.

@j7n also asked when was the brightness start to kick in, take this last normal release, compare to the one from the topic or newer.

https://github.com/clsid2/mpc-hc/releases/tag/1.8.6

In all, the creator goes blind, which I guess is normal for older people. Natural ageing process.