Github messages for voidlinux
 help / color / mirror / Atom feed
From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: mpv: green tilt in the video
Date: Fri, 11 Oct 2019 04:10:14 +0200	[thread overview]
Message-ID: <20191011021014.J2CXKenZCxU_eVicaTqWQaFcKME1rlAKsaJFxHV95Sc@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-15294@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

New comment by obunden on void-packages repository

https://github.com/void-linux/void-packages/issues/15294#issuecomment-540869342

Comment:
I'm just taking a guess here, but this should probably reported upstream somewhere.

Seems like there has been very little changes in mpv and the biggest change in void seems to be that that the package got rebuilt against ffmpeg-4.2.

If your card supports vulkan you could try gpu_context=waylandvk and see if you get the same problem. Don't know if it's relevant but you should probably post your video card / drivers, it might be useful.

Also check and see which video output is used in mpv, I imagine it is 'gpu' but have a look. This message from the mpv manual might also shed some light on the issue:

```
Quality reduction with hardware decoding

In theory, hardware decoding does not reduce video
quality (at least for the codecs h264 and HEVC).
However, due to restrictions in video output APIs, as
well as bugs in the actual hardware decoders, there
can be some loss, or even blatantly incorrect results.

In some cases, RGB conversion is forced, which means
the RGB conversion is performed by the hardware
decoding API, instead of the shaders used by --vo=gpu.
This means certain colorspaces may not display
correctly, and certain filtering (such as debanding)
cannot be applied in an ideal way. This will also
usually force the use of low quality chroma scalers
instead of the one specified by --cscale. In other
cases, hardware decoding can also reduce the bit depth
of the decoded image, which can introduce banding or
precision loss for 10-bit files.
```

  reply	other threads:[~2019-10-11  2:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 13:05 [ISSUE] " voidlinux-github
2019-10-11  2:10 ` voidlinux-github [this message]
2019-10-11 12:54 ` voidlinux-github
2019-10-12  5:55 ` voidlinux-github
2019-10-14  8:33 ` voidlinux-github
2019-10-14 10:14 ` voidlinux-github
2019-10-14 17:28 ` voidlinux-github
2019-10-14 17:38 ` voidlinux-github
2019-10-14 17:39 ` voidlinux-github
2019-10-14 17:39 ` [ISSUE] [CLOSED] " voidlinux-github

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191011021014.J2CXKenZCxU_eVicaTqWQaFcKME1rlAKsaJFxHV95Sc@z \
    --to=voidlinux-github@inbox.vuxu.org \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).