<div dir="ltr"><div>Regarding my expertise, I was one of the developers most involved in developing the "livido" standard which was one of the main topics of the Piksel Festivals held in Bergen, Norway.</div><div>In the early days (2004 - 2006) the focus of the annual event was precisely the formulation of free / open standards, in this case for video effects. Other contributors included:</div><div> Niels Elburg, Denis "Jaromil" Rojo, Tom Schouten, Andraz Tori, Kentaro Fukuchi and Carlo Prelz.</div><div>I've also been involved with and put forward proposals for common command / query / reply actions (Open Media Control). To the extent that these proposals have not gained traction, I don't ascribe this to a failing in the proposals, but rather to a lack of developer awareness.</div><div><br></div><div>Now regarding specific areas, I went back and reviewed some of the available material at <a href="https://www.freedesktop.org/wiki/Specifications/">https://www.freedesktop.org/wiki/Specifications/</a></div><div><br></div><div>free media player specifications <a href="https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/">https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/</a> metadata standards for things like comments and ratings - talks mainly about audio but describes video files also </div><div><br></div><div>I am not a big fan of dbus, but this looks fine, it could be used for video players. I'd be happier if it were a bit more abstracted and not tied to a specific implementation (dbus). I could suggest some enhancements but I guess this is a dbus thing and not an xdg thing.</div><div><br></div><div>IMO what would be useful would be to define a common set of constants, most specifically related to frame pixel fornats</div><div>The 2 most common in use are fourCC and avformat</div><div><br></div><div>Consider a frame in UYVY fornat </div><div><br></div><div>fourCC values: <br></div><div><br></div><div> #define MK_FOURCC(a, b, c, d) (((uint32_t)a) | (((uint32_t)b) << 8) \</div> | (((uint32_t)c) << 16) | (((uint32_t)d) << 24))<br><div><br></div><div>MK_FOURCC('U', 'Y', 'V', 'Y')</div><div>but also </div><div>MK_FOURCC('I', 'U', 'Y', 'B')<br></div><div>the same but with interlacing</div><div>MK_FOURCC('H', 'D', 'Y', 'C')<br></div><div>same but bt709 (hdtv) encoding</div><div><br></div><div>so this requires interpretation by sender / receiver - a simpler way could be with constants</div><div><br></div><div><div>- probably the nearest we have are ffmpeg / libav definitions, but this is the wrong way around, a lib shouldn't define a global standard, the standard should come first and the lib should align to that.</div><div><br></div><div>We have AV_PIX_FMT_UYVY422 which was formerly PIX_FMT_UYVY422</div><div>and AVCOL_TRC_BT709, which is actually the gamma transfer function, There is no equivalent bt709 constant fot bt709 yuv / rgb, instead this exists as a matrix.</div><div><br></div><div>Now consider how much easier it would be to share data if we had the following constants enumerated:</div><div><br></div><div><div><b>XDG_VIDEO_PALETTE_UYVY</b></div><div><b>XDG_VIDEO_INTERLACE_TOP_FIRST</b></div><div><b>XDG_VIDEO_YUV_SUBSPACE_BT709</b></div><div><b>XDG_VIDEO_GAMMA_SRGB</b></div></div><div><br></div><div>(this is an invented example, not intended to be a real example).</div><div><br></div><div>There is a bit more too it but that should be enough to give a general idea.</div><div><br></div><div>G,</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Apr 2024 at 08:12, Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi">pekka.paalanen@haloniitty.fi</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">On Thu, 28 Mar 2024 19:19:33 -0300<br> salsaman <<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>> wrote:<br> <br> > There are two hardware settings from the monitor that overlap video, these<br> > are<br> > - monitor aspect ratio<br> > - monitor pixel aspect ratio<br> > These are both useful when rendering video. The first defines how much<br> > stretch or letterbocing to apply, the second defines non square pixels,<br> > which is goof to know if you want to render fixed size objects (a circle<br> > for example). Knowing the monitor size in RGB or Y plane pixels can also be<br> > useful to define a max or min resize limit (whether it is min or max<br> > depends on the desired display quality level)<br> <br> Thanks. I was trying to ask what kind of video standards you have<br> experience and expertise in?<br> <br> I'm also interested in what kind of standards you see as missing. The<br> Wayland extension aims to cover everything display related. I'm sure<br> video file format specifications do their job.<br> <br> What would be left to define?<br> <br> What goals would there be?<br> <br> I suppose individual APIs like Pipewire might be lacking something, but<br> that's a Pipewire API rather than an XDG standard. Or do we need an XDG<br> standard to be used as the design guide and reference for APIs?<br> <br> <br> Thanks,<br> pq<br> <br> > On Thu, 28 Mar 2024 at 19:05, salsaman <<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>> wrote:<br> > <br> > > colour management and hdr mostly intersect with three areas of video:<br> > > pixel formats, yuv <-> rgb conversions and gamma transfer functions.<br> > > For example<br> > > xdg_pixformat_yuv121010<br> > > xdg_subspace_bt2020<br> > > xdg_gamma_bt2020<br> > ><br> > > just off the top of my head, these arent intended to be actual suggestions<br> > ><br> > ><br> > > On Thu, 28 Mar 2024 at 18:57, salsaman <<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>> wrote:<br> > > <br> > >> In addition, I am not sure if there are xdg standards for audio, but I<br> > >> would suggest video and follow similar hierarchies, and that both could be<br> > >> classed under a more generic xdg multimedia standard.<br> > >><br> > >><br> > >> On Thu, 28 Mar 2024 at 18:48, salsaman <<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>> wrote:<br> > >> <br> > >>> Hi, IMO hardware related would be more appropriate under display<br> > >>> standards<br> > >>> Video standards could be more software related, and provide common<br> > >>> definitions, for example , allowing exchange of information between<br> > >>> applications which produce or consume video frames or streams of frames.<br> > >>> Some examples I can think of might be<br> > >>> xdg_colorspace_RGB,<br> > >>> xdg_colorspace_YUV<br> > >>><br> > >>> xdg_pixfmt_RGB24<br> > >>> xdg_pixfmt_YUV420p<br> > >>> etc<br> > >>><br> > >>> xdg_gamma_linear<br> > >>> xdg_gamma_sRGB<br> > >>><br> > >>> xdg_video_width<br> > >>> xdg_video_height<br> > >>><br> > >>> I could provide a more full list, but I think if it goes along this<br> > >>> route. the starting point has to be what are we setting out to achieve with<br> > >>> the standards / definitions, and provide a range of speculative use cases.<br> > >>><br> > >>> Gabriel (salsaman)<br> > >>><br> > >>><br> > >>> On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen < <br> > >>> <a href="mailto:pekka.paalanen@haloniitty.fi" target="_blank">pekka.paalanen@haloniitty.fi</a>> wrote: <br> > >>> <br> > >>>> On Wed, 27 Mar 2024 11:45:00 -0300<br> > >>>> salsaman <<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>> wrote:<br> > >>>> <br> > >>>> > ISTR that the xdg video standards were never defined, If you need any<br> > >>>> > advice or assistance with this, I would be happy to act in an<br> > >>>> > advisory capacity if that is called for. I have over 20 years <br> > >>>> experience of <br> > >>>> > developing Free Software video and have been an active participant in<br> > >>>> > developing other video / effects standards. I have been a bit our of <br> > >>>> the <br> > >>>> > spotlight recently as I have been busy architecting and implementing <br> > >>>> the <br> > >>>> > core components of the upcoming next gen LiVES 4,0 video application <br> > >>>> plus <br> > >>>> > its accompanying state-of-the-art effects standard) <br> > >>>><br> > >>>> Hi,<br> > >>>><br> > >>>> what kind of video standards would that be?<br> > >>>><br> > >>>> I'm wondering if it would have anything to do with Wayland color<br> > >>>> management and HDR:<br> > >>>><br> > >>>> <a href="https://gitlab.freedesktop.org/pq/color-and-hdr" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/pq/color-and-hdr</a><br> > >>>><br> > >>>> <a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183</a><br> > >>>><br> > >>>> <a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14</a><br> > >>>><br> > >>>> Would there need to be any XDG standards to support color managed HDR<br> > >>>> desktops, or is the window system support enough?<br> > >>>><br> > >>>> I have not much in my mind, but then I've been staring only at the<br> > >>>> window system interactions, and haven't seen what else the desktop<br> > >>>> ecosystem or applications might need.<br> > >>>><br> > >>>> Recommended display calibration and measurement procedures maybe?<br> > >>>><br> > >>>> Desktop viewing environment standards?<br> > >>>><br> > >>>> Viewing environment measurement?<br> > >>>><br> > >>>> They could be as straightforward as referring to a freely available<br> > >>>> ITU-R or SMPTE papers or others, if there are suitable ones.<br> > >>>><br> > >>>><br> > >>>> Thanks,<br> > >>>> pq<br> > >>>> <br> > >>> <br> <br> </blockquote></div>