Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

segmentation fault when quit at hdr output #12666

Open
hooke007 opened this issue Oct 18, 2023 · 12 comments
Open

segmentation fault when quit at hdr output #12666

hooke007 opened this issue Oct 18, 2023 · 12 comments

Comments

@hooke007
Copy link
Contributor

hooke007 commented Oct 18, 2023

Important Information

Provide following Information:

  • mpv version
    master 02d009b
  • macOS Version
    Sonoma
  • Source of the mpv binary or bundle
    build by the toolchain of https://github.com/deus0ww/homebrew-tap
  • If known which version of mpv introduced the problem
    N/a
  • Possible screenshot or video of visual glitches
    No

Reproduction steps

mpv --config=no --force-window=yes --idle=yes --vo=gpu-next --gpu-context=macvk --target-colorspace-hint=yes --log-file=test.log

Expected behavior

No error

Actual behavior

segmentation fault

seg.txt

Log file

test.log

Sample files

Any hdr video

@Akemi
Copy link
Member

Akemi commented Nov 23, 2023

i can reproduce this, though no idea what exactly happens there. just to make things clear, it only happens with --target-colorspace-hint=yes.

[edit]
used this as test file https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/

@bigipalabom
Copy link

i can reproduce this, though no idea what exactly happens there. just to make things clear, it only happens with --target-colorspace-hint=yes.

[edit] used this as test file https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/

Same finds here, mpv crashes. but how can I achieve HDR passthrough without using target-colorspace-hint?

@bigipalabom
Copy link

bigipalabom commented Nov 27, 2023

new founds hope it's helpful to locate the glitch. certain hdr video will keep on flashing less adjust mpv window size

below are my settings:

vo=gpu-next
gpu-context=macvk
gpu-api=vulkan
hwdec=videotoolbox
target-colorspace-hint=yes

[HDR pq]
profile-cond=p[ "video-params/gamma"]=="pq"
target-prim=bt.2020
target-trc=pq

[HDR hlg]
profile-cond=p["video-params/gamma"]=="hlg"
target-prim=bt.2020
target-trc=hlg

@Akemi
Copy link
Member

Akemi commented Feb 26, 2024

the minimum settings to reproduce this mpv --no-config --vo=gpu-next --target-colorspace-hint.

crash report: crash.txt
log: log.log

terminal also outputs a zsh: bus error

akemi@Mac-Studio mpv % build/mpv --no-config --vo=gpu-next --target-colorspace-hint /Users/Akemi/Downloads/LG\ New\ York\ HDR\ UHD\ 4K\ Demo.ts --log-file=/Users/Akemi/Desktop/log.log   
[ffmpeg/demuxer] mpegts: start time for stream 1 is not set in estimate_timings_from_pts
[ffmpeg/demuxer] mpegts: stream 1 : no TS found at start of file, duration not set
[ffmpeg/demuxer] mpegts: Could not find codec parameters for stream 1 (Audio: aac ([15][0][0][0] / 0x000F), 0 channels): unspecified sample format
[ffmpeg/demuxer] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
 (+) Video --vid=1 (hevc 3840x2160 25.000fps)
 (+) Audio --aid=1 (aac)
AO: [coreaudio] 48000Hz stereo 2ch floatp
VO: [gpu-next] 3840x2160 yuv420p10
AV: 00:00:01 / 00:01:12 (1%) A-V: -0.008 ct: -0.072 Dropped: 1 
Exiting... (Quit)
AV: 00:00:01 / 00:01:12 (1%) A-V: -0.008 ct: -0.072 Dropped: 1zsh: bus error  build/mpv --no-config --vo=gpu-next --target-colorspace-hint  

[edit]
output with/from ASan

==7992==ERROR: AddressSanitizer: BUS on unknown address (pc 0x000180b9fed8 bp 0x00016fec6ed0 sp 0x00016fec6e90 T16)
==7992==The signal is caused by a READ memory access.
==7992==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x180b9fed8 in objc_release+0x10 (libobjc.A.dylib:arm64e+0x7ed8)
    #1 0x180ba3aec in objc_autoreleasePoolPop+0x100 (libobjc.A.dylib:arm64e+0xbaec)
    #2 0x180bd420c in objc_tls_direct_base<AutoreleasePoolPage*, (tls_key)3, AutoreleasePoolPage::HotPageDealloc>::dtor_(void*)+0xa4 (libobjc.A.dylib:arm64e+0x3c20c)
    #3 0x180f669f8 in _pthread_tsd_cleanup+0x268 (libsystem_pthread.dylib:arm64e+0x49f8)
    #4 0x180f69720 in _pthread_exit+0x50 (libsystem_pthread.dylib:arm64e+0x7720)
    #5 0x180f6903c in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x703c)
    #6 0x180f63e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)

==7992==Register values:
 x[0] = 0x0000000123d35710   x[1] = 0x04000001d76a7981   x[2] = 0x0000001000016578   x[3] = 0x0000000000000367  
 x[4] = 0x0000000000000048   x[5] = 0x0000000000000001   x[6] = 0x000000016fe44000   x[7] = 0x0000000000000001  
 x[8] = 0x0000000000000000   x[9] = 0x0000000123d35710  x[10] = 0x0000000116fed508  x[11] = 0x0000000000000003  
x[12] = 0x000000010e2fd8e0  x[13] = 0x000000010e2fd8f0  x[14] = 0x00000001d711d038  x[15] = 0x00000001d711d038  
x[16] = 0x000000100001657d  x[17] = 0x00000001daf3da18  x[18] = 0x0000000000000000  x[19] = 0x0000000121e26000  
x[20] = 0x0000000121e26038  x[21] = 0x0000000123d35710  x[22] = 0x000000016fec70e0  x[23] = 0x00000000a1a1a1a1  
x[24] = 0xa3a3a3a3a3a3a3a3  x[25] = 0x0000000000000001  x[26] = 0x0000000000000021  x[27] = 0x0000000000000000  
x[28] = 0x0000000000000000     fp = 0x000000016fec6ed0     lr = 0x0000000180ba7418     sp = 0x000000016fec6e90  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS (libobjc.A.dylib:arm64e+0x7ed8) in objc_release+0x10
Thread T16 created by T3 here:
    #0 0x1057681b0 in wrap_pthread_create+0x54 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4c1b0)
    #1 0x1012f0828 in vo_create vo.c:317
    #2 0x1012ede94 in init_best_video_out vo.c:342
    #3 0x100f7b50c in reinit_video_chain_src video.c:234
    #4 0x100f7ad10 in reinit_video_chain video.c:210
    #5 0x100eedcbc in play_current_file loadfile.c:1741
    #6 0x100ee4258 in mp_play_files loadfile.c:1998
    #7 0x100f0c5d0 in mpv_main main.c:432
    #8 0x10144fb20 in playback_thread macosx_application.m:278
    #9 0x180f69030 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x7030)
    #10 0x180f63e38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1e38)

Thread T3 created by T0 here:
    #0 0x1057681b0 in wrap_pthread_create+0x54 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4c1b0)
    #1 0x10144f104 in cocoa_main macosx_application.m:363
    #2 0x101468530 in main main-fn-cocoa.c:9
    #3 0x180bed0dc  (<unknown module>)

==7992==ABORTING
zsh: trace trap  build/mpv --no-config --vo=gpu-next --target-colorspace-hint 

@Akemi
Copy link
Member

Akemi commented Feb 26, 2024

coming from this call in mpv

pl_swapchain_colorspace_hint(p->sw, &hint);

in libplacebo https://github.com/haasn/libplacebo/blob/e987124b516507f4eb71a29b53e288d3c590aa75/src/swapchain.c#L65-L67

some problem with the pointer to pl_color_space and inappropriate freeing?

@Akemi
Copy link
Member

Akemi commented Feb 28, 2024

after trying to fix a problem with rendering on the main queue (https://github.com/Akemi/mpv/commits/mac_vulkan_main/) the crash persists but already crashs when trying to load an HDR file.

crash.txt

V: 00:00:00 / 00:00:13 (5%) DS: 2.5/0AddressSanitizer:DEADLYSIGNAL
=================================================================
==6459==ERROR: AddressSanitizer: SEGV on unknown address 0x00000001ba80 (pc 0x000182827ed8 bp 0x00016b80de00 sp 0x00016b80ddc0 T0)
==6459==The signal is caused by a READ memory access.
    #0 0x182827ed8 in objc_release+0x10 (libobjc.A.dylib:arm64e+0x7ed8)
    #1 0x18282baec in objc_autoreleasePoolPop+0x100 (libobjc.A.dylib:arm64e+0xbaec)
    #2 0x182c8c5d0 in _CFAutoreleasePoolPop+0x1c (CoreFoundation:arm64e+0x3c5d0)
    #3 0x182d9f02c in __CFRunLoopPerCalloutARPEnd+0x2c (CoreFoundation:arm64e+0x14f02c)
    #4 0x182cccaa4 in __CFRunLoopRun+0x7f0 (CoreFoundation:arm64e+0x7caa4)
    #5 0x182ccbc58 in CFRunLoopRunSpecific+0x25c (CoreFoundation:arm64e+0x7bc58)
    #6 0x18d248444 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x30444)
    #7 0x18d248280 in ReceiveNextEventCommon+0x284 (HIToolbox:arm64e+0x30280)
    #8 0x18d247fd8 in _BlockUntilNextEventMatchingListInModeWithFilter+0x48 (HIToolbox:arm64e+0x2ffd8)
    #9 0x1864a6c50 in _DPSNextEvent+0x290 (AppKit:arm64e+0x39c50)
    #10 0x186c7ceb8 in -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+0x2c8 (AppKit:arm64e+0x80feb8)
    #11 0x18649a0fc in -[NSApplication run]+0x1d8 (AppKit:arm64e+0x2d0fc)
    #12 0x1052de838 in cocoa_run_runloop application.m:271
    #13 0x1052ddd88 in cocoa_main application.m:367
    #14 0x1052db0f4 in main main-fn-mac.c:9
    #15 0x1828750dc  (<unknown module>)

==6459==Register values:
 x[0] = 0x0000000134b6d8a0   x[1] = 0x02000001d932f981   x[2] = 0x000000000001ba60   x[3] = 0x000000016b80dfa0  
 x[4] = 0x0000000000003d03   x[5] = 0x0000000000000000   x[6] = 0x0000000000000000   x[7] = 0x0000000000000000  
 x[8] = 0x0000000000000000   x[9] = 0x0000000134b6d8a0  x[10] = 0x0000000000000000  x[11] = 0x0000000000000001  
x[12] = 0x0000000000000000  x[13] = 0x001ffe9e00000100  x[14] = 0x001ffe9e00000100  x[15] = 0x0000000000000000  
x[16] = 0x000000000001ba63  x[17] = 0x00000001dcbc5a18  x[18] = 0x0000000000000000  x[19] = 0x0000000113856000  
x[20] = 0x0000000113856d68  x[21] = 0x0000000134b6d8a0  x[22] = 0x00000001d8da1fa0  x[23] = 0x00000000a1a1a1a1  
x[24] = 0xa3a3a3a3a3a3a3a3  x[25] = 0x0000000000000001  x[26] = 0x0000000112502e50  x[27] = 0x0000000000000000  
x[28] = 0x0000000000000000     fp = 0x000000016b80de00     lr = 0x000000018282f418     sp = 0x000000016b80ddc0  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (libobjc.A.dylib:arm64e+0x7ed8) in objc_release+0x10
==6459==ABORTING

@kasper93
Copy link
Contributor

==7992==ERROR: AddressSanitizer: BUS on unknown address (pc 0x000180b9fed8 bp 0x00016fec6ed0 sp 0x00016fec6e90 T16)
==7992==The signal is caused by a READ memory access.
==7992==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x180b9fed8 in objc_release+0x10 (libobjc.A.dylib:arm64e+0x7ed8)
    #1 0x180ba3aec in objc_autoreleasePoolPop+0x100 (libobjc.A.dylib:arm64e+0xbaec)
    #2 0x180bd420c in objc_tls_direct_base<AutoreleasePoolPage*, (tls_key)3, AutoreleasePoolPage::HotPageDealloc>::dtor_(void*)+0xa4 (libobjc.A.dylib:arm64e+0x3c20c)
    #3 0x180f669f8 in _pthread_tsd_cleanup+0x268 (libsystem_pthread.dylib:arm64e+0x49f8)

This looks like TLS clean up touching module that has been unloaded. And we get BUS error. Could you save memory map before crash and compare this failing address? It is likely in something that is unloaded/reloaded.

@NekoAsakura
Copy link
Contributor

It seems to be caused by a double release (NSZombie) from libMoltenVK and libpthread, but I'm unsure how to resolve this without changing libplacebo api.

Instruments 1 Instruments 2

When first frame is drawn, pl_swapchain_start_frame creates NSData when passing HDR metadata.

if (!should_draw || !pl_swapchain_start_frame(p->sw, &swframe)) {

It is released shortly afterward.

https://github.com/KhronosGroup/MoltenVK/blob/26c7b0234dd093e6153237c4a8d94eedd07f9614/MoltenVK/MoltenVK/GPUObjects/MVKSwapchain.mm#L355-L370

However, when vo thread exits — it attempts to access (and clean up) the released memory. This cause the BAD_MEMORY_ACCESS.

I set a breakpoint in lldb and here is the output:

 % NSZombieEnabled=YES lldb -- build/mpv --no-config --vo=gpu-next --target-colorspace-hint=yes --autofit=50%  /Users/neko/Downloads/NY.ts
(lldb) breakpoint set --name vkSetHdrMetadataEXT
(lldb) run
...
Process 2149 stopped
* thread #17, name = 'vo', stop reason = breakpoint 1.1
    frame #0: 0x000000012488bd74 libMoltenVK.dylib`vkSetHdrMetadataEXT
libMoltenVK.dylib`vkSetHdrMetadataEXT:
->  0x12488bd74 <+0>:  sub    sp, sp, #0x50
    0x12488bd78 <+4>:  stp    x24, x23, [sp, #0x10]
    0x12488bd7c <+8>:  stp    x22, x21, [sp, #0x20]
    0x12488bd80 <+12>: stp    x20, x19, [sp, #0x30]
Target 0: (mpv) stopped.
(lldb) bt
* thread #17, name = 'vo', stop reason = breakpoint 1.1
  * frame #0: 0x000000012488bd74 libMoltenVK.dylib`vkSetHdrMetadataEXT
    frame #1: 0x00000001009803ec libplacebo.349.dylib`set_hdr_metadata + 236
    frame #2: 0x0000000100980280 libplacebo.349.dylib`vk_sw_recreate + 2236
    frame #3: 0x000000010097f540 libplacebo.349.dylib`vk_sw_start_frame + 148
    frame #4: 0x00000001001f68b8 mpv`draw_frame(vo=0x0000000106a2e830, frame=0x0000000106b22060) at vo_gpu_next.c:1007:26
    frame #5: 0x00000001001e3a10 mpv`render_frame(vo=0x0000000106a2e830) at vo.c:973:9
    frame #6: 0x00000001001e2e30 mpv`vo_thread(ptr=0x0000000106a2e830) at vo.c:1105:24
    frame #7: 0x000000019562026c libsystem_pthread.dylib`_pthread_start + 148
(lldb) frame select 4
frame #4: 0x00000001001f68b8 mpv`draw_frame(vo=0x0000000106a2e830, frame=0x0000000106b22060) at vo_gpu_next.c:1007:26
   1004	    struct pl_swapchain_frame swframe;
   1005	    struct ra_swapchain *sw = p->ra_ctx->swapchain;
   1006	    bool should_draw = sw->fns->start_frame(sw, NULL); // for wayland logic
-> 1007	    if (!should_draw || !pl_swapchain_start_frame(p->sw, &swframe)) {
   1008	        if (frame->current) {
   1009	            // Advance the queue state to the current PTS to discard unused frames
   1010	            struct pl_queue_params qparams = *pl_queue_params(
(lldb) c
...
Exiting... (Quit)
2024-12-01 02:33:59.764336+1000 mpv[22360:1380373] *** -[_NSInlineData release]: message sent to deallocated instance 0x600000213660
Process 22360 stopped
* thread #17, name = 'vo', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1958452e4)
    frame #0: 0x00000001958452e4 CoreFoundation`___forwarding___.cold.2 + 92
CoreFoundation`:
->  0x1958452e4 <+92>: brk    #0x1

CoreFoundation`:
    0x1958452e8 <+0>:  pacibsp 
    0x1958452ec <+4>:  sub    sp, sp, #0x30
    0x1958452f0 <+8>:  stp    x20, x19, [sp, #0x10]
Target 0: (mpv) stopped.
(lldb) thread list
Process 22360 stopped
  thread #1: tid = 0x150f91, 0x00000001955e2850 libsystem_kernel.dylib`mach_msg_trap + 8, queue = 'com.apple.main-thread'
  thread #2: tid = 0x150fbd, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #3: tid = 0x150fbe, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #4: tid = 0x150fbf, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #5: tid = 0x150fe3, 0x00000001955e47d4 libsystem_kernel.dylib`__ulock_wait + 8, name = 'core/playback'
  thread #6: tid = 0x150fe5, 0x00000001955ed538 libsystem_kernel.dylib`__select + 8, name = 'terminal/input'
  thread #13: tid = 0x150ff8, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #14: tid = 0x150ffb, 0x00000001955e2850 libsystem_kernel.dylib`mach_msg_trap + 8, name = 'com.apple.NSEventThread'
  thread #16: tid = 0x151014, 0x00000001955e6210 libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'worker'
* thread #17: tid = 0x151015, 0x00000001958452e4 CoreFoundation`___forwarding___.cold.2 + 92, name = 'vo', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1958452e4)
  thread #29: tid = 0x1513ae, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #30: tid = 0x1513c7, 0x00000001955e288c libsystem_kernel.dylib`semaphore_wait_trap + 8, name = 'AMCP Logging Spool'
  thread #31: tid = 0x151438, 0x00000001955e28a4 libsystem_kernel.dylib`semaphore_timedwait_trap + 8, queue = 'NSCGSDisableUpdates'
  thread #32: tid = 0x151439, 0x00000001955e288c libsystem_kernel.dylib`semaphore_wait_trap + 8, queue = 'com.apple.SkyLight.UpdateManager.SerialSema'
  thread #33: tid = 0x15143a, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #34: tid = 0x15143b, 0x00000001955e46cc libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #35: tid = 0x15146e, 0x0000000000000000
  thread #36: tid = 0x15146f, 0x0000000000000000
  thread #37: tid = 0x151470, 0x0000000000000000
  thread #38: tid = 0x151471, 0x0000000000000000
(lldb) thread select 5
* thread #5, name = 'core/playback'
    frame #0: 0x00000001955e47d4 libsystem_kernel.dylib`__ulock_wait + 8
libsystem_kernel.dylib`:
->  0x1955e47d4 <+8>:  b.lo   0x1955e47f4               ; <+40>
    0x1955e47d8 <+12>: pacibsp 
    0x1955e47dc <+16>: stp    x29, x30, [sp, #-0x10]!
    0x1955e47e0 <+20>: mov    x29, sp
(lldb) bt
* thread #5, name = 'core/playback'
  * frame #0: 0x00000001955e47d4 libsystem_kernel.dylib`__ulock_wait + 8
    frame #1: 0x00000001956225a0 libsystem_pthread.dylib`_pthread_join + 444
    frame #2: 0x00000001001e0b74 mpv`vo_destroy(vo=0x00000001075111c0) at vo.c:374:5
    frame #3: 0x0000000100180f64 mpv`uninit_video_out(mpctx=0x000000010b809050) at video.c:132:9
    frame #4: 0x0000000100174454 mpv`mp_destroy(mpctx=0x000000010b809050) at main.c:174:5
    frame #5: 0x0000000100175414 mpv`mpv_main(argc=6, argv=0x000000016fdfee70) at main.c:475:5
    frame #6: 0x0000000100014154 mpv`closure #1 in variable initialization expression of Application.playbackThread(ptr=0x106b06d00) at application.swift:98:31
    frame #7: 0x000000010001416c mpv`@objc closure #1 in variable initialization expression of Application.playbackThread at <compiler-generated>:0
    frame #8: 0x000000019562026c libsystem_pthread.dylib`_pthread_start + 148
(lldb) frame select 2
frame #2: 0x00000001001e0b74 mpv`vo_destroy(vo=0x00000001075111c0) at vo.c:374:5
   371 	{
   372 	    struct vo_internal *in = vo->in;
   373 	    mp_dispatch_run(in->dispatch, terminate_vo, vo);
-> 374 	    mp_thread_join(vo->in->thread);
   375 	    dealloc_vo(vo);
   376 	}
   377 

@kasper93
Copy link
Contributor

kasper93 commented Nov 30, 2024

It seems to be caused by a double release (NSZombie) from libMoltenVK and libpthread, but I'm unsure how to resolve this without changing libplacebo api.

Yes, your analysis seems to be consistent with what we already seen from @Akemi backtrace. There is allocation done inside MVKSwapchain::setHDRMetadataEXT which is attached as thread local storage data for current thread. But is released immediately, so why there is lingering reference in TLS?

without changing libplacebo api.

There is nothing wrong on libplacebo / mpv side. When VO thread is joined, pthread is calling TLS destructors for each key attached to given thread in _pthread_tsd_cleanup. Now we can see that is goes to objc_autoreleasePoolPop which is cleaning up after the thread. Now this is probably valid, the question is why there are dead allocations referenced.

I don't know Objective-C and not willing to learn just for that. But this should be obvious for someone familiar with their memory management model.

	NSData* colorVolData = [NSData dataWithBytes: &colorVol length: sizeof(colorVol)];
	NSData* lightLevelData = [NSData dataWithBytes: &lightLevel length: sizeof(lightLevel)];
	CAEDRMetadata* caMetadata = [CAEDRMetadata HDR10MetadataWithDisplayInfo: colorVolData
																contentInfo: lightLevelData
														 opticalOutputScale: 1];
	auto* mtlLayer = getCAMetalLayer();
	mtlLayer.EDRMetadata = caMetadata;
	mtlLayer.wantsExtendedDynamicRangeContent = YES;
	[caMetadata release];
	[colorVolData release];
	[lightLevelData release];

Does this code look correct to you? As we can see there are three references, colorVolData, lightLevelData and caMetadata.

caMetadata reference colorVolData and lightLevelData. And then caMetadata is added as EDRMetadata.

All three references are released.

Will they be refcounted correctly? Who is responsible for that?

Like I said, I don't do objc, so not sure what is proper way to handle those memory allocations, but it is clear to me that it is fully caused by MoltenVK, as we (libplacebo / mpv) does not interact with those allocations at all. We only call vkSetHdrMetadataEXT and it is driver responsibility to copy/use the data in whatever way it needs.

@NekoAsakura
Copy link
Contributor

Unfortunately, I'm not an expert in memory management either and feel not confident drawing any conclusions yet. I plan to build MoltenVK to run some tests later.

@NekoAsakura
Copy link
Contributor

NekoAsakura commented Dec 1, 2024

I confirmed that this issue is related to a bug in MoltenVK (KhronosGroup/MoltenVK#2399).

I've fixed this bug and successfully tested it on my local env.

Here is the dynamic library, can someone help verify if this resolves the problem?

libMoltenVK.dylib.zip

@Akemi
Copy link
Member

Akemi commented Dec 1, 2024

@NekoAsakura tested your moltenvk lib and the issue is fixed. i will keep this issue open till a new moltenvk release with the fix included is made, to keep track on this issue and we know when the blocker for the "vo=gpu-next" milestone is gone.

thanks for looking into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants