emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was R


From: Eli Zaretskii
Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)
Date: Fri, 27 Nov 2020 22:01:03 +0200

> From: Arthur Miller <arthur.miller@live.com>
> Date: Fri, 27 Nov 2020 20:22:42 +0100
> Cc: tom@logand.com, emacs-devel@gnu.org
> 
> To my knowledge, mpv is probably the neetiest one to bring in media
> playing capabilities; it has lots of codecs, is written to be embedded,
> is free and would make Emacs be able to play music and video files
> without external players. Adding multimedia capabilities opens up for
> lots of flexibility and creativity; people can maybe do interesting
> stuff with it. I would certainly like Emacs to become a multimedia
> player, I play my music with Emacs already :-).
> 
> If other people think it is too expensive in terms of implementation
> cost and what it offers, and if multimedia is not desirable in Emacs, I
> can have understanding with that. I might not agree, but my opinion is
> just one persons opinion, and I am not even an Emacs developer, so of
> course, you who make Emacs work probably know better and have precedence
> in what Emacs should do/have or not. It would be wrong to claim anything
> else :). 

Expensive or not, talking about mpv as providing video playing
facilities for Emacs is makes little sense as long as the issue of
embedding video in a window that shows an Emacs buffer is not
resolved.  As the xwidgets experiment suggests, the problem to solve
here is not a trivial one.  Until someone comes up with some clever
idea for how to do that, let alone submits patches for that, the issue
of which library to use is not really relevant to Emacs development.

If someone wants a flexible way of playing video under Emacs control,
I think a more practically useful way at this time is to provide a
feature that runs VLC or a similar player program as an Emacs
subprocess, and controls that player via Emacs commands.  That could
need extending the players themselves, if their command-line arguments
aren't flexible enough and there's no other API that Emacs could use.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]