On Thu, 11 Apr 2024 22:22:01 -0300
salsaman wrote:
> Sorry for the delay, there was a lot to respond to, most of it not relevant
> to the XDG discussion. I suggest we limit discussion on the mailing list to
> whatever is relevant. Pekka, if you want to continue this discussion, then
> we can
On Fri, 5 Apr 2024 19:16:55 -0300
salsaman wrote:
> On Fri, 5 Apr 2024 at 12:57, Pekka Paalanen
> wrote:
>
> > On Fri, 5 Apr 2024 08:28:27 -0300
> > salsaman wrote:
> >
> > > I don't think you are paying enough attention to the main points. Ir is
> > not
> > > simply a case of extending
On Fri, 5 Apr 2024 at 12:57, Pekka Paalanen
wrote:
> On Fri, 5 Apr 2024 08:28:27 -0300
> salsaman wrote:
>
> > I don't think you are paying enough attention to the main points. Ir is
> not
> > simply a case of extending the fourcc values to include more. If I didn't
> > make it clear enough,
On Fri, 5 Apr 2024 08:28:27 -0300
salsaman wrote:
> I don't think you are paying enough attention to the main points. Ir is not
> simply a case of extending the fourcc values to include more. If I didn't
> make it clear enough, the whole fourcc system is obscure, inadequate,
> ambiguous. The
I don't think you are paying enough attention to the main points. Ir is not
simply a case of extending the fourcc values to include more. If I didn't
make it clear enough, the whole fourcc system is obscure, inadequate,
ambiguous. The only reason ever to use it would be when you don't have meta
On Thu, 4 Apr 2024 17:13:40 -0300
salsaman wrote:
> Hi,
> the problem with the drm.h header is, it is complicated, still needs
> interpretation, and it lacks some commonly used formats, (e.g YUVAp)
They accept additions, if the additions serve userspace
interoperability. There is no
I missed out a link in an earlier email, this is the dbus player control
which I mentioned:
https://www.freedesktop.org/wiki/Specifications/mpris-spec/
A dbus <---> OSC endpoint could actually make this super useful, perhaps I
will do that when I have some time,
On Thu, 4 Apr 2024 at 21:57,
Just to re emphasise, the nearest we have presently are AV_PIXFMT_* which
are library specific values, and lack some important values
(there is no yuv888 packed for example), And the drm,h file is based on
monitor standards, and also lacks values like 'R', 'G', 'B', 'A' *
I think we can agree
I'll try to explain the rationale a bit. In the audio world it is quite
common for apps to send audio from one to another. Generally speaking they
would send or receive via an audio server, e.g pulseaudio, jack.
Now imagine the same for video, let us suppose you have an app that
generates video
Hi,
the problem with the drm.h header is, it is complicated, still needs
interpretation, and it lacks some commonly used formats, (e.g YUVAp)
Also it doesn't address the gamma value (linear, sRGB, bt701), or the yuv
subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 = clamped
/
On Wed, 3 Apr 2024 21:51:39 -0300
salsaman wrote:
> 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.
> In the early days (2004 - 2006) the focus of the annual
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.
In the early days (2004 - 2006) the focus of the annual event was precisely
the formulation of free / open
On Thu, 28 Mar 2024 19:19:33 -0300
salsaman wrote:
> There are two hardware settings from the monitor that overlap video, these
> are
> - monitor aspect ratio
> - monitor pixel aspect ratio
> These are both useful when rendering video. The first defines how much
> stretch or letterbocing to
There are two hardware settings from the monitor that overlap video, these
are
- monitor aspect ratio
- monitor pixel aspect ratio
These are both useful when rendering video. The first defines how much
stretch or letterbocing to apply, the second defines non square pixels,
which is goof to know if
colour management and hdr mostly intersect with three areas of video:
pixel formats, yuv <-> rgb conversions and gamma transfer functions.
For example
xdg_pixformat_yuv121010
xdg_subspace_bt2020
xdg_gamma_bt2020
just off the top of my head, these arent intended to be actual suggestions
On Thu,
In addition, I am not sure if there are xdg standards for audio, but I
would suggest video and follow similar hierarchies, and that both could be
classed under a more generic xdg multimedia standard.
On Thu, 28 Mar 2024 at 18:48, salsaman wrote:
> Hi, IMO hardware related would be more
Hi, IMO hardware related would be more appropriate under display standards
Video standards could be more software related, and provide common
definitions, for example , allowing exchange of information between
applications which produce or consume video frames or streams of frames.
Some examples I
17 matches
Mail list logo
