<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Back again. Working on 1.20.1, I've modified kmssink to retrieve HDR caps from the stream and set an HDR Infoframe to the correct values, if present in the stream. This works like a charm if I display a stream on a single display, but if I try to display two streams on two displays (different connector-id and plane-id) from two separate processes OR from the same python program, I get a 13 Permission Denied from both the drmModeObjectSetProperty call and the drmModeSetPlane call, which seems nonsensical.  </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">When I comment out my DRM calls (to more or less get back to pre-mods), drmModeSetPlane still fails with the same error message (logs below, full attached)</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The graphs:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">GST_DEBUG=1,kms*:9 gst-launch-1.0 filesrc location=/home/wdh/test/0AB7525E-6452-4A5B-8573-84125B5744B0/0/vw_0000.m4s ! parsebin ! vaapih265dec ! video/x-raw,format=P010_10LE ! queue max-size-bytes=100663300 ! kmssink restore-crtc=true connector-id=327 plane-id=100<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">GST_DEBUG_FILE=kmslog.txt GST_DEBUG=1,kms*:9 gst-launch-1.0 filesrc location=/home/wdh/test/0AB7525E-6452-4A5B-8573-84125B5744B0/0/vw_0000.m4s ! parsebin ! vaapih265dec ! video/x-raw,format=P010_10LE ! queue max-size-bytes=100663300 ! kmssink restore-crtc=true connector-id=308 plane-id=31<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I can run one or the other separately, so the connector-id and plane-id parameters are correct.  But when I run the first, then immediately (from another shell, or by backgrounding the first) run the second, the log looks like this:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style=""><font face="monospace">0:00:00.088549896  1815 0x564ce99f78c0 DEBUG                kmssink gstkmssink.c:1403:gst_kms_sink_set_caps:<kmssink0> negotiated caps = video/x-raw, format=(string)P010_10LE, width=(int)3840, height=(int)2160, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt2100-pq, framerate=(fraction)60000/1001, mastering-display-info=(string)34000:16000:13250:34500:7500:3000:15635:16450:40000000:50, content-light-level=(string)9935:124<br>0:00:00.088563267  1815 0x564ce99f78c0 DEBUG                kmssink gstkmssink.c:1449:gst_kms_sink_propose_allocation:<kmssink0> propose allocation<br>0:00:00.089074455  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:218:gst_kms_allocator_memory_create:<KMSMemory::allocator> Created BO plane 0 with stride 7680 and offset 0<br>0:00:00.089089090  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:218:gst_kms_allocator_memory_create:<KMSMemory::allocator> Created BO plane 1 with stride 7680 and offset 16588800<br>0:00:00.089098233  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:469:gst_kms_allocator_add_fb:<KMSMemory::allocator> bo handles: 1, 1, 0, 0<br>0:00:00.089116246  1815 0x564ce99f78c0 DEBUG          kmsbufferpool gstkmsbufferpool.c:163:gst_kms_buffer_pool_alloc_buffer:<kmsbufferpool1> adding GstVideoMeta<br>0:00:00.089128011  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:114:gst_kms_allocator_memory_reset:<KMSMemory::allocator> removing fb id 368<br>0:00:00.089147324  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:218:gst_kms_allocator_memory_create:<KMSMemory::allocator> Created BO plane 0 with stride 7680 and offset 0<br>0:00:00.089165083  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:218:gst_kms_allocator_memory_create:<KMSMemory::allocator> Created BO plane 1 with stride 7680 and offset 16588800<br>0:00:00.089174233  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:469:gst_kms_allocator_add_fb:<KMSMemory::allocator> bo handles: 1, 1, 0, 0<br>0:00:00.089184435  1815 0x564ce99f78c0 DEBUG          kmsbufferpool gstkmsbufferpool.c:163:gst_kms_buffer_pool_alloc_buffer:<kmsbufferpool1> adding GstVideoMeta<br>0:00:00.089192315  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:114:gst_kms_allocator_memory_reset:<KMSMemory::allocator> removing fb id 368<br>0:00:00.089216900  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:218:gst_kms_allocator_memory_create:<KMSMemory::allocator> Created BO plane 0 with stride 7680 and offset 0<br>0:00:00.089225922  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:218:gst_kms_allocator_memory_create:<KMSMemory::allocator> Created BO plane 1 with stride 7680 and offset 16588800<br>0:00:00.089234807  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:469:gst_kms_allocator_add_fb:<KMSMemory::allocator> bo handles: 1, 1, 0, 0<br>0:00:00.089243309  1815 0x564ce99f78c0 DEBUG          kmsbufferpool gstkmsbufferpool.c:163:gst_kms_buffer_pool_alloc_buffer:<kmsbufferpool1> adding GstVideoMeta<br>0:00:00.138840940  1815 0x564ce99f78c0 TRACE                kmssink gstkmssink.c:1848:gst_kms_sink_show_frame:<kmssink0> displaying fb 368<br>0:00:00.138860715  1815 0x564ce99f78c0 TRACE                kmssink gstkmssink.c:1912:gst_kms_sink_show_frame:<kmssink0> drmModeSetPlane at (0,0) 3840x2160 sourcing at (0,0) 3840x2160<br>0:00:00.138871078  1815 0x564ce99f78c0 WARN                 kmssink gstkmssink.c:1922:gst_kms_sink_show_frame: drmModeSetPlane(368, 100, 167) failed -13, go to retry_set_plane<br>0:00:00.138880343  1815 0x564ce99f78c0 TRACE                kmssink gstkmssink.c:1912:gst_kms_sink_show_frame:<kmssink0> drmModeSetPlane at (0,0) 3840x2160 sourcing at (0,0) 3840x2160<br>0:00:00.138888501  1815 0x564ce99f78c0 DEBUG                kmssink gstkmssink.c:1971:gst_kms_sink_show_frame:<kmssink0> result = { 0, 0, 3840, 2160} / src = { 0, 0, 3840 2160 } / dst = { 0, 0, 3840 2160 }<br>0:00:00.138905801  1815 0x564ce99f78c0 WARN                 kmssink gstkmssink.c:1975:gst_kms_sink_show_frame:<kmssink0> error: drmModeSetPlane failed: Permission denied (13)<br>ERROR: from element /GstPipeline:pipeline0/GstKMSSink:kmssink0: GStreamer encountered a general resource error.<br>Additional debug info:<br>../subprojects/gst-plugins-bad/sys/kms/gstkmssink.c(1975): gst_kms_sink_show_frame (): /GstPipeline:pipeline0/GstKMSSink:kmssink0:<br>drmModeSetPlane failed: Permission denied (13)<br>ERROR: pipeline doesn't want to preroll.<br>0:00:00.138981967  1815 0x564ce99f78c0 DEBUG           kmsallocator gstkmsallocator.c:114:gst_kms_allocator_memory_reset:<KMSMemory::allocator> removing fb id 368<br>Setting pipeline to NULL ...<br>Freeing pipeline ...</font><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style=""><font face="verdana, sans-serif">which propagates out and causes the playback to fail.  Note I added the "</font><span style="font-family:monospace">retry_set_plane" </span><font face="verdana, sans-serif">logging as part of debugging</font><span style="font-family:monospace">. </span><font face="verdana, sans-serif"></font></div><div class="gmail_default" style=""><span style="font-family:monospace"><br></span></div><div class="gmail_default" style=""><font face="verdana, sans-serif">So - hoping this is something easy to solve, or at least *POSSIBLE* to solve.  Thoughts?</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">-Bill</font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 30, 2022 at 2:12 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le mercredi 30 mars 2022 à 12:51 -0700, Bill Hofmann a écrit :<br>
> Thanks for the hints on kmssink, sad it's not performant. Will consider.<br>
> <br>
> Looking at the waylandsink - it doesn't like P010 pixels, and doesn't seem to<br>
> want to negotiate NV12 pixels - so I'm concerned that it won't support HDR10 -<br>
<br>
Yeah, HDR10 would require you to do some patching with early work. Also note<br>
that I said in Weston, I don't expect this to work on Gnome or Plasma at the<br>
moment.  Regardless of the direction, you have to do some plumbing for HDR10 on<br>
Linux.<br>
<br>
> <br>
> GST_DEBUG=way*:5 gst-launch-1.0 filesrc<br>
> location=04_Tryptic_Right_UHD_HDR10_010522.mp4 ! qtdemux ! h265parse !<br>
> vaapih265dec ! video/x-raw,format=NV12 ! vaapipostproc ! waylandsink<br>
> fullscreen=1<br>
> Setting pipeline to PAUSED ...<br>
> Pipeline is PREROLLING ...<br>
> Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context,<br>
> gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0";<br>
> Got context from element 'vaapipostproc0': gst.vaapi.Display=context,<br>
> gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayEGL\)\ vaapidisplayegl0";<br>
> 0:00:00.103692914  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.103860649  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.104163879  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.104282762  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.104418197  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.104696971  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.104808871  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> 0:00:00.186018372  6503 0x7f2270005b00 DEBUG            waylandsink<br>
> gstwaylandsink.c:512:gst_wayland_sink_get_caps:<waylandsink0> display caps:<br>
> video/x-raw, format=(string){ BGRA, BGRx, RGB16 }, width=(int)[ 1, 2147483647<br>
> ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ];<br>
> video/x-raw(memory:DMABuf), format=(string){ BGRA, BGRx, RGB16 }, width=(int)[<br>
> 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1,<br>
> 2147483647/1 ]<br>
> Redistribute latency...<br>
> ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Internal data<br>
> stream error.<br>
> Additional debug info:<br>
> ../gst/isomp4/qtdemux.c(6545): gst_qtdemux_loop ():<br>
> /GstPipeline:pipeline0/GstQTDemux:qtdemux0:<br>
> streaming stopped, reason not-negotiated (-4)<br>
> ERROR: pipeline doesn't want to preroll.<br>
> Setting pipeline to NULL ...<br>
> Freeing pipeline ...<br>
> 0:00:00.190220809  6503 0x5562d2c0c230 DEBUG            waylandsink<br>
> gstwaylandsink.c:286:gst_wayland_sink_finalize:<waylandsink0> Finalizing the<br>
> sink..<br>
> <br>
> On Wed, Mar 30, 2022 at 4:50 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br>
> > <br>
> > <br>
> > Le mar. 29 mars 2022 20 h 20, Bill Hofmann <<a href="mailto:bill.hofmann@gmail.com" target="_blank">bill.hofmann@gmail.com</a>> a<br>
> > écrit :<br>
> > > Thanks for the very helpful feedback. I am able to connect to kmssink, and<br>
> > > after specifying connector-id and (the correct, I think) plane-id, I get<br>
> > > video out from the non-X view. Defaults don't work there, but that's<br>
> > > manageable. Clearly not yet HDR (haven't made changes to kmssink yet). <br>
> > > <br>
> > > HOWEVER, performance is exceptionally poor - whereas vaapisink is able to<br>
> > > keep up with 4k30 P010 without a problem (in a window on the desktop),<br>
> > > kmssink seems to run at about 15fps. As someone relatively new to this<br>
> > > whole process, what's the best way to debug these performance issues? <br>
> > > Looking at debug all the way up to 9, there isn't (of course) any helpful<br>
> > > logged info at least that's helpful to me.  I'll note autovideosink also<br>
> > > has performance issues (but again isn't full screen or non-X).<br>
> > <br>
> > There is poorly implemented vsync in kmssink, combined with DRM emulation of<br>
> > the legacy API kmssink uses, the frame rate get halved. The only solution I<br>
> > have for now is to comment out the legacy vsync  code, the emulation will<br>
> > sync already.<br>
> > <br>
> > The use a queue before the sink, ensure the byte size is large enough for<br>
> > 4K.<br>
> > <br>
> > Long term solution is to move on to atomic API. There is a MR for that, but<br>
> > last time I checked it was of poor quality and the author wasn't replying.<br>
> > <br>
> > > <br>
> > > A little more context - this is an "embedded" Linux situation - will never<br>
> > > be other than full screen video (likely no UI), so there is no need for<br>
> > > interop with desktop functionality.<br>
> > <br>
> > I would really like to see this type of use cases improve. This is common in<br>
> > NXP and Xilinx SDK, though they hold downstream patches to workaround this.<br>
> > <br>
> > Meanwhile, be aware that Weston + waylandsink works better, Weston<br>
> > automatically (and smartly) use HW layer. The limitation is that it only<br>
> > works in combination of a GPU, it's not supported by the pixman backend<br>
> > (yet?).<br>
> > <br>
> > > <br>
> > > -Bill<br>
> > > <br>
> > > On Sun, Mar 27, 2022 at 6:05 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>><br>
> > > wrote:<br>
> > > > <br>
> > > > <br>
> > > > Le sam. 26 mars 2022 21 h 45, Bill Hofmann via gstreamer-devel<br>
> > > > <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> a écrit :<br>
> > > > > <br>
> > > > > So.  What's the next step here? Is this a big gap in kmssink? Is there<br>
> > > > > another sink I should be trying?<br>
> > > > <br>
> > > > There is no mainline HDR10 support on Linux outside of vendors BSP (NXP<br>
> > > > to note one vendor). Vendors seems to want to compete on this feature,<br>
> > > > and don't really work very hard to come up with generic implementation.<br>
> > > > <br>
> > > > That being said, if the kmssink is sufficient for your use case, then<br>
> > > > its the smallest way forward, since you don't need a new Wayland<br>
> > > > protocol and compositors support. What I'm uncertain though is if this<br>
> > > > will work with the fact the kmssink code base have aged and isn't using<br>
> > > > the newest DRM API (atomic kms). But other then that, if you have done<br>
> > > > that in the past, this is plain C and mapping the caps field to the DRM<br>
> > > > properties is all you need. Unlike HDR10+, the metadata does not change<br>
> > > > every frames.<br>
> > > > <br>
> > > > <br>
> > > > Regards,<br>
> > > > Nicolas<br>
> > > > <br>
> > > > p.s. vaapipostproc have a HDR to SDR converter to help improve SDR<br>
> > > > output quality<br>
> > > > <br>
> > > <br>
> > > <br>
> > > -- <br>
> > > Bill Hofmann<br>
> > > +1 510 387-0952<br>
> <br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(51,51,51);font-family:verdana,sans-serif">Bill Hofmann</span><br></div><div><span style="color:rgb(102,102,102);font-family:verdana,sans-serif">+1 510 387-0952</span><br></div></div></div></div></div></div>
</div>