Knowing where it is NOT, isn't particularly useful. The obvious solution is
for somebody to upload a copy to gitlab, and then update the link in the
wiki.
http://lives-video.com
https://www.openhub.net/accounts/salsaman
On Mon, 17 Aug 2020 at 02:02, Thayne wrote:
> gitorious was repla
c.
Thanks in advance,
GF.
http://lives-video.com
https://www.openhub.net/accounts/salsaman
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
s 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.
G,
On Wed, 3 Apr 2024 at 08:12, Pekka Paalanen
wrote:
> On Thu, 28 Mar 2024 19:19:33 -0300
> salsaman wrote:
>
> > There are two
21:57, salsaman wrote:
> 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
their ambiguous yuv411 definition - if it were
yuv411p I would agree, otherwise it could be the camera format UYYVYY
packed).
On Thu, 4 Apr 2024 at 18:40, salsaman wrote:
> 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 a
it might be,
Or the easier way, you query the app and it responds with XDG constants.
G,
On Thu, 4 Apr 2024 at 17:13, 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 YUVA
6:34, Pekka Paalanen
wrote:
> 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)
>
> Th
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
if you want to render fixed size objects (a circle
for example). Knowing the monitor size in RGB or Y plane pixels can also be
useful to define a max or min resize limit (whether it is min or max
depends on the desired display quality level)
On Thu, 28 Mar 2024 at 19:05, salsaman wrote:
> col
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 m
are video and have been an active participant in
developing other video / effects standards. I have been a bit our of the
spotlight recently as I have been busy architecting and implementing the
core components of the upcoming next gen LiVES 4,0 video application plus
its accompanying state-of-the-art effe
out to achieve with the
standards / definitions, and provide a range of speculative use cases.
Gabriel (salsaman)
On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen
wrote:
> On Wed, 27 Mar 2024 11:45:00 -0300
> salsaman wrote:
>
> > ISTR that the xdg video standards were never defin
On Thu, 28 Mar 2024 at 18:57, salsaman wrote:
> 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 a
or to fourcc and if you were to supplement this with
gamma, interlace, yuv subspace, yuv clamping and yuv sampling, then you
would have a very comprehensive definition for any type of video frame.
G.
On Thu, 4 Apr 2024 at 08:52, Pekka Paalanen
wrote:
> On Wed, 3 Apr 2024 21:51:39 -0300
&g
14 matches
Mail list logo
