Video standards

[Pekka Paalanen]

On Wed, 3 Apr 2024 21:51:39 -0300
salsaman <salsaman at gmail.com> 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 event was precisely
> the formulation of free / open standards, in this case for video effects.
> Other contributors included:
>  Niels Elburg, Denis "Jaromil" Rojo, Tom Schouten, Andraz Tori, Kentaro
> Fukuchi and Carlo Prelz.
> 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.
> 
> Now regarding specific areas, I went back and reviewed some of the
> available material at  https://www.freedesktop.org/wiki/Specifications/
> 
> free media player specifications
> https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/
> metadata standards for things like comments and ratings - talks mainly
> about audio but describes video files also
> 
> 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.

Thanks, these sound like they do not need to involve Wayland in any
way, so they are not on my plate.

> IMO what would be useful would be to define a common set of constants, most
> specifically related to frame pixel fornats
> The 2 most common in use are fourCC and avformat

Wayland protocol extensions and I suppose also Wayland compositors
internally standardise on drm_fourcc.h formats. Their authoritative
definitions are in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h
and they are not intentionally mirroring any other fourcc coding.

These are strictly pixel formats, and do not define anything about
colorimetry, interlacing, field order, frame rate, quantization range,
or anything else.

> Consider a frame in UYVY fornat
> 
> fourCC values:
> 
>  #define MK_FOURCC(a, b, c, d) (((uint32_t)a) | (((uint32_t)b) << 8)     \
>                                | (((uint32_t)c) << 16) | (((uint32_t)d) <<
> 24))
> 
> MK_FOURCC('U', 'Y', 'V', 'Y')
> but also
> MK_FOURCC('I', 'U', 'Y', 'B')
> the same but with interlacing
> MK_FOURCC('H', 'D', 'Y', 'C')
> same but bt709 (hdtv) encoding
> 
> so this requires interpretation by sender / receiver - a simpler way could
> be with constants
> 
> - 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.
> 
> We have AV_PIX_FMT_UYVY422 which was formerly PIX_FMT_UYVY422
> 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.
> 
> Now consider how much easier it would be to share data if we had the
> following constants enumerated:
> 
> *XDG_VIDEO_PALETTE_UYVY*
> *XDG_VIDEO_INTERLACE_TOP_FIRST*
> *XDG_VIDEO_YUV_SUBSPACE_BT709*
> *XDG_VIDEO_GAMMA_SRGB*
> 
> (this is an invented example, not intended to be a real example).
> 
> There is a bit more too it but that should be enough to give a general idea.

Where should this be used?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240404/660a9d3d/attachment-0001.sig>