Unity version
2022.3.62f3
Unity editor platform
Windows
AVPro Video edition
Ultra
AVPro Video version
3.4.2
Device hardware
CPU: 13th Gen Intel Core i9-13900
RAM: 64 GB
GPU: NVIDIA GeForce RTX 3090, 24322 MB VRAM, driver 32.0.16.1074
Which Windows version are you using?
11
Graphics API
D3D 11
Video API
DirectShow
Audio output
System Direct
Any other Media Player component configuration required to reproduce the issue.
Project color space: Gamma (QualitySettings.activeColorSpace == Gamma)
useHapNotchLC: true
useHardwareDecoding: true
parallelFrameCount: 3, prerollFrameCount: 4
maxDropMode: left at its 3.4.2 default (5)
Which output component(s) are you using?
No response
Any other component configuration required to reproduce the issue.
No response
The issue
HAP video plays much darker than it should in 3.4.2. The same file was correct
in 3.3.4. This is probably a follow-on to #2489 (HAP not rendering at all in
3.4.1, fixed in 3.4.2): HAP renders now, but with the wrong transfer applied.
Repro
- Unity 2022.3.62f3, project color space Gamma, D3D11.
- MediaPlayer, Video API = DirectShow, useHapNotchLC = true.
- Open a plain HAP (Hap1 / BC1) .mov and display it.
- Image comes out well below the brightness of the source it was encoded
from. Shadows are crushed and midtones pulled down, highlights are roughly
where they should be. Looks like an sRGB to linear decode that never gets
re-encoded.
Expected: what 3.3.4 gave us from the same file.
The file itself is fine
We pulled the same frame out of the H.264 source and out of the HAP transcode
and compared them in display space. Mean RGB comes back identical on both
(123, 140, 120), and PSNR between the two frames is 36 dB, which is just BC1
block noise with no brightness shift in it. If the encode had a gamma error the
mean would have moved a long way (an sRGB decode would put 123 down around 50).
So the file is good and the darkening is happening at playback.
Diagnostics
We don't use any AVPro output component. We read
MediaPlayer.TextureProducer.GetTexture() and blit it ourselves into an ARGB32
RenderTexture, no color conversion anywhere in that path, so none of AVPro's
shader or output code is in play.
Logging at texture creation in WindowsMediaPlayer.UpdateTexture() gives:
dxgi=8 isLinear=True gfxFormat=RGBA_DXT1_UNorm
sampleLinear=True activeColorSpace=Gamma mips=False size=1280x720
- dxgi=8 (BC1) lines up with the file. ffprobe reports codec hap, tag Hap1,
pix_fmt rgb0, and no color_range, color_space, color_transfer or
color_primaries metadata at all.
- gfxFormat=RGBA_DXT1_UNorm means Unity's SRV over the native shared texture
is not sRGB, so Unity isn't converting anything on sample, and it's still
dark. The dark values are already in the surface by the time Unity has it.
- sampleLinear is Native.IsTextureSampleLinear() and it returns true, so the
plugin is telling us the surface is already linear.
Our guess at the cause from that: the surface holds linear values but the
project is in Gamma color space, so nothing re-encodes on output and the decode
only ever happens once. In a Linear color space project this would come out
right, which might be why it got missed.
What we tried
Forcing the linear argument of Texture2D.CreateExternalTexture to true for the
DXT1/DXT5/BC7 cases, so Unity definitely builds a UNorm view. No change, and
the gfxFormat above confirms the view really is UNorm. We can't see anything
that would fix this from managed code.
Scope
Only tested with HAP, since our pipeline transcodes everything to HAP on
import. We haven't checked whether other codecs on the DirectShow path have the
same problem. 3.3.4 is correct with the same files and the same project
settings, so the plugin version is the only thing that changed.
Media information
Can't share the source clip for rights reasons, but you don't need it. The file
is plain ffmpeg HAP output and reproduces from any input:
ffmpeg -i <any_input.mp4> -c:v hap <out.mov>
That's the exact command our importer runs. The output fingerprints as:
codec_name=hap
codec_tag_string=Hap1
pix_fmt=rgb0
color_range/color_space/color_transfer/color_primaries = unknown (unset)
1280x720, 30 fps, video only, no audio stream
Source we transcoded from was H.264, yuv420p, bt709 primaries/transfer/matrix,
limited range.
Log output
[AVProVideo] Initialising AVPro Video v3.4.2 (native plugin v3.4.2f1-ultra) on
NVIDIA GeForce RTX 3090/Direct3D 11.0 [level 11.1] (MT True) on WindowsEditor
[AVProVideo] Opening Common/Imported/Clip 3.mov (offset 0) with API DirectShow
[AVProVideo] Using playback path: DirectShow (1280x720@29.97)
[FW TEMP #9797] dxgi=8 isLinear=True gfxFormat=RGBA_DXT1_UNorm sampleLinear=True activeColorSpace=Gamma mips=False size=1280x720
The last line is our own instrumentation, not plugin output. It's a Debug.Log
we added inside WindowsMediaPlayer.UpdateTexture() at the point the external
texture is created, reporting Native.GetTextureFormat(), the isLinear local,
_texture.graphicsFormat, Native.IsTextureSampleLinear(),
QualitySettings.activeColorSpace, UseNativeMips() and the texture size.
The plugin logs no warnings or errors at any point. Playback reports success
and runs at the right resolution and frame rate, it's only the pixel values
that are wrong.
Unity version
2022.3.62f3
Unity editor platform
Windows
AVPro Video edition
Ultra
AVPro Video version
3.4.2
Device hardware
CPU: 13th Gen Intel Core i9-13900
RAM: 64 GB
GPU: NVIDIA GeForce RTX 3090, 24322 MB VRAM, driver 32.0.16.1074
Which Windows version are you using?
11
Graphics API
D3D 11
Video API
DirectShow
Audio output
System Direct
Any other Media Player component configuration required to reproduce the issue.
Project color space: Gamma (QualitySettings.activeColorSpace == Gamma)
useHapNotchLC: true
useHardwareDecoding: true
parallelFrameCount: 3, prerollFrameCount: 4
maxDropMode: left at its 3.4.2 default (5)
Which output component(s) are you using?
No response
Any other component configuration required to reproduce the issue.
No response
The issue
HAP video plays much darker than it should in 3.4.2. The same file was correct
in 3.3.4. This is probably a follow-on to #2489 (HAP not rendering at all in
3.4.1, fixed in 3.4.2): HAP renders now, but with the wrong transfer applied.
Repro
from. Shadows are crushed and midtones pulled down, highlights are roughly
where they should be. Looks like an sRGB to linear decode that never gets
re-encoded.
Expected: what 3.3.4 gave us from the same file.
The file itself is fine
We pulled the same frame out of the H.264 source and out of the HAP transcode
and compared them in display space. Mean RGB comes back identical on both
(123, 140, 120), and PSNR between the two frames is 36 dB, which is just BC1
block noise with no brightness shift in it. If the encode had a gamma error the
mean would have moved a long way (an sRGB decode would put 123 down around 50).
So the file is good and the darkening is happening at playback.
Diagnostics
We don't use any AVPro output component. We read
MediaPlayer.TextureProducer.GetTexture() and blit it ourselves into an ARGB32
RenderTexture, no color conversion anywhere in that path, so none of AVPro's
shader or output code is in play.
Logging at texture creation in WindowsMediaPlayer.UpdateTexture() gives:
pix_fmt rgb0, and no color_range, color_space, color_transfer or
color_primaries metadata at all.
is not sRGB, so Unity isn't converting anything on sample, and it's still
dark. The dark values are already in the surface by the time Unity has it.
plugin is telling us the surface is already linear.
Our guess at the cause from that: the surface holds linear values but the
project is in Gamma color space, so nothing re-encodes on output and the decode
only ever happens once. In a Linear color space project this would come out
right, which might be why it got missed.
What we tried
Forcing the linear argument of Texture2D.CreateExternalTexture to true for the
DXT1/DXT5/BC7 cases, so Unity definitely builds a UNorm view. No change, and
the gfxFormat above confirms the view really is UNorm. We can't see anything
that would fix this from managed code.
Scope
Only tested with HAP, since our pipeline transcodes everything to HAP on
import. We haven't checked whether other codecs on the DirectShow path have the
same problem. 3.3.4 is correct with the same files and the same project
settings, so the plugin version is the only thing that changed.
Media information
Can't share the source clip for rights reasons, but you don't need it. The file
is plain ffmpeg HAP output and reproduces from any input:
That's the exact command our importer runs. The output fingerprints as:
Source we transcoded from was H.264, yuv420p, bt709 primaries/transfer/matrix,
limited range.
Log output