10 bit videos playback ugly #1918
Comments
|
I suspect the GPU applies rounding, which chips of the higher bits, resulting in these colors. But normally 10 bit output should be disabled automatically if this can happen. I'd like to have glxinfo output, and the mpv output with -v while playing something with the broken output present. |
|
glxinfo: OpenGL version string: 4.5.0 NVIDIA 346.47 OpenGL ES profile version string: OpenGL ES 3.1 NVIDIA 346.47 228 GLX Visuals id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat0x021 24 tc 0 24 0 r y . 8 8 8 0 . s 4 24 8 16 16 16 16 0 0 None 311 GLXFBConfigs: id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat0x105 24 tc 0 24 0 r y . 8 8 8 0 . s 4 24 8 16 16 16 16 0 0 None mpv -v, same file: Something to note is that blacklisting yuv420p10 using noformat selects yuv420p16, which does display correctly. |
|
I see nothing wrong. This is strange and unexpected. Is it the same with |
|
It doesn't happen with --no-config. Here's the output: mpv config: Write your default config options here!#no-sub Disabling the scaling filter fixes the problem. This would not be optimal as I like how this filter looks, especially for scaling up low resolution videos. I know there are better filters but they cause framedrops. |
Try a different FBO format, or use We might consider changing the FBO format for the |
|
Disabling the scaling filter fixes the problem. This would not be optimal
as I like how this filter looks, especially for scaling up low resolution
videos. I know there are better filters but they cause framedrops.
That sounds like something is broken on your system. This hardware should be
more than capable enough to handle all of the available scaling filters at
your display resolution.
|
|
Adding fbo-format=rgba16 fixed it. Thanks for the help! |
No, I think the driver is not to blame here. We use GL_RGBA, which has unspecified precision - or maybe the fine print of the OpenGL spec specifies one, but then the required minimum is 8 bit. The problem here is that We should probably set the default format to GL_RGBA16 for vo_opengl too. |
ghost
closed this as 
|
Why don't you add a 'auto' option which tests GL_RGBA16 for FBO and uses it only if it's available and fall back to GL_RGBA if not available? |
|
On Tuesday 05 May 2015 05:38:31 V. Lang wrote:
Was talking about the performance issues mostly. |
There is some very limited testing, which disables features needing FBO if the framebuffer completeness check fails. But then we still don't know its precision and performance. Doing a full test would probably be complicated. And AFAIK, even OpenGL 2.x supports GL_RGBA16.
Ah, missed this. Maybe he was referring to placebo things or software filters. |
Well, there are always damn gap between spec and implementation. Frankly speaking, the default FBO format in mpv doesn't matter for me because I'm already doing so on initialization of my application. |
|
I was talking about the "Dropped" counter increasing by a couple per second, which was making pans look jerky. I'm sure it's possible something is up with my set up or nvidia's graphics drivers or something. Basically, the only filter I found that looks better is haasnsoft, which causes a gradual increase in drops over tiem with VO dropping enabled, otherwise the audio and video just desync. |
|
Yeah, that’s odd. My old GeForce 9800 GT could handle this at 1920x1080.
|
|
@wm4's analysis is correct. The culprit is the chroma merge optimization, whivh is enabled automatically when cscale is set to something nontrivial. Another option to fix this would be to disable this optimization if the input depth is not equal to the input texture depth, but that's only possible if source-shader is not enabled. (source-shader requires texture merging) On May 5, 2015 2:38:31 PM GMT+02:00, "V. Lang" [email protected] wrote:
|
10 bit videos play back with very wrong colors as seen in the image below:
Mediainfo output:
General
Unique ID : 191927923406190416676768106360014409508 (0x9063F936538B2AAB81174B4A28708F24)
Complete name : Dragonball.Z.-.076.-.1080p.BluRay.x264.DHD.mkv
Format : Matroska
Format version : Version 2
File size : 896 MiB
Duration : 24mn 13s
Overall bit rate : 5 172 Kbps
Encoded date : UTC 2014-03-28 10:29:10
Writing application : mkvmerge v5.0.1 ('Es ist Sommer') built on Oct 9 2011 11:55:43
Writing library : libebml v1.2.2 + libmatroska v1.3.0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 13s
Nominal bit rate : 4 500 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.091
Writing library : x264 core 142 r2409 d6b4e63
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=abr / mbtree=1 / bitrate=4500 / ratetol=2.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Audio #1
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 24mn 13s
Channel count : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : ENG+JAP MUSIC
Language : English
Default : Yes
Forced : No
Audio #2
ID : 3
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 24mn 13s
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : ENG+ENG MUSIC
Language : English
Default : No
Forced : No
Audio #3
ID : 4
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Muxing mode : Header stripping
Codec ID : A_AC3
Duration : 24mn 13s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel count : 1 channel
Channel positions : Front: C
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 16.6 MiB (2%)
Title : JAP+JAP MUSIC
Language : Japanese
Default : No
Forced : No
Text
ID : 5
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : The same subtitle format used on BDs/HD-DVDs
Language : English
Default : No
Forced : No
mpv output:
$ mpv --vf-clr Dragonball.Z.-.076.-.1080p.BluRay.x264.DHD.mkv
Playing: Dragonball.Z.-.076.-.1080p.BluRay.x264.DHD.mkv
(+) Video --vid=1 (h264)
(+) Audio --aid=1 --alang=eng (*) 'ENG+JAP MUSIC' (aac)
Audio --aid=2 --alang=eng 'ENG+ENG MUSIC' (aac)
Audio --aid=3 --alang=jpn 'JAP+JAP MUSIC' (ac3)
Subs --sid=1 --slang=eng (hdmv_pgs_subtitle)
Using hardware decoding.
AO: [pulse] 48000Hz stereo 2ch float
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame!
Error using hardware decoding, falling back to software decoding.
VO: [opengl] 1920x1080 yuv420p10
AV: 00:00:04 / 00:24:13 (0%) A-V: 0.000
Adding a line to my mpv config fixes the problem:
vf-add=noformat=yuv420p10
--vf-clr was used for that output just to get rid of that line. It happens otherwise with the same output.
The text was updated successfully, but these errors were encountered: