From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: GStreamer xwidget Date: Mon, 29 Nov 2021 14:31:20 +0700 Message-ID: References: <87ee7cq2mu.fsf.ref@yahoo.com> <87ee7cq2mu.fsf@yahoo.com> <87zgpzp80c.fsf@yahoo.com> <87czmvtf68.fsf@gnus.org> <87czmunkmo.fsf@yahoo.com> <8735noajkl.fsf@yahoo.com> <87sfvn5p0j.fsf@yahoo.com> <87v90i4cmc.fsf@yahoo.com> <87pmqozm99.fsf@yahoo.com> <87ee72cix7.fsf@yahoo.com> <87a6ho99gy.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30432"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Lars Magne Ingebrigtsen , Emacs developers To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 29 08:33:25 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mrbAC-0007nB-VI for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 08:33:25 +0100 Original-Received: from localhost ([::1]:45700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrbAA-0007gc-2m for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 02:33:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrb8S-0006ll-UZ for emacs-devel@gnu.org; Mon, 29 Nov 2021 02:31:36 -0500 Original-Received: from [2607:f8b0:4864:20::92f] (port=37755 helo=mail-ua1-x92f.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mrb8Q-0001VZ-HF; Mon, 29 Nov 2021 02:31:36 -0500 Original-Received: by mail-ua1-x92f.google.com with SMTP id o1so32090738uap.4; Sun, 28 Nov 2021 23:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iXZNpJ695r4i+Fz1F4YBwXETQFiWidkufDjBGRzC/6o=; b=OjSbBUWOV4AFvmvq33AjQMmWVKMxywoSChCxLucoywr4T9/SGlaO9ojzvKGI1lYJyX lrWWDFxY1u7gi1/EsLgkDMHcamohlzZFQMBVHRliPNj9e69ADXGYKyaFKCLTiAdfUGFk UO3PfjLnoyHFYRaKsGVe7IYJBLT9TP+Y7wkUheZBguFNCbJBO7aSRoNVhiGyhxTNFNsS iFRu6o7JTZyfSIXH/+4OQslLSWCq828ycn/FcpBakQkyJZggiNwd16JuTnty4iQFAM7g JJX2K4uDAR+50bmcOukFY7GeyGz6IAefF4W2d75s43bNX99KV0mCMbJu4WoakAkaGy+A B2zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iXZNpJ695r4i+Fz1F4YBwXETQFiWidkufDjBGRzC/6o=; b=h+AIXQEoxn3BjBJ7Y8CVfoHfQLTM+RwQN2N3k0qcfLHDZYYCNcAGdOQk+4Wmd9Dwvq NiKhU0J4KQPjswMS9xrKJ24qyAe6TsKdw2eqIzImzHRXBrFVpDn7JM6Pyz6boyVzKWd5 QZHfUYk6sdFdi5UiMP9ASF2SWwviglG4QUFlxJNbafvalxlntpQ514trAefjrCIJwRn+ /0WFTdxKGNiDtUyEIaMxrqs/7FEbgk0QM9523+GgLdy0aXI/OxfXY5bCWQPvP3BQGx5S UlQT+SKxVesgUQZjeZEtI90j9/sTekR6RAGmIVeaJBlw045fhgnaGUNCycL1X1uygboL xegA== X-Gm-Message-State: AOAM533cZ62wsGava5H8hkcM0hsbIT7Mj5pho/hLGzcJtVaW10c/XM58 5iNhyS4f7PV+IKzoqd/nUqdkg5A/cxUaIBHvzy4i7TK+YZ0= X-Google-Smtp-Source: ABdhPJy7fAx5JLes1V+xZvYOEfOOc88cIlT6rFI2fR+oQ58h1SQ/G0VM5tVH/2OP6Q+Eahox5eSfq9x6T7wFjs85CLs= X-Received: by 2002:ab0:72c8:: with SMTP id g8mr46990829uap.86.1638171091532; Sun, 28 Nov 2021 23:31:31 -0800 (PST) In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::92f (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::92f; envelope-from=yurivkhan@gmail.com; helo=mail-ua1-x92f.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280454 Archived-At: On Mon, 29 Nov 2021 at 10:02, Richard Stallman wrote: > > > + && gst_registry_find_feature (registry, "videotestsrc", > > > + GST_TYPE_ELEMENT_FACTORY) > > > > + xw->gst_source =3D gst_element_factory_make ("videotestsrc",= NULL); > ... > > You seem to know something about this code. Disclaimer: I have not worked specifically with GStreamer, but I come from a Windows background where I used to work with DirectShow. They are technically similar. > Can you explain the > meaning of it? What the dats structures are, and what these > operations actually do? I think the easiest way to explain media processing frameworks is to make an analogy with UNIX pipes. A typical UNIX process has a single input descriptor and two outputs (stdout and stderr). You combine them in pipelines by connecting an output of one program to the input of another. Shell pipelines are typically linear or tree-like. Media processing frameworks generalize this. Each =E2=80=9Cfilter=E2=80=9D = or =E2=80=9Celement=E2=80=9D can have an arbitrary number of inputs and output= s, and they are typed so the framework can check if the connection you are trying to make is nonsensical. For example, you cannot meaningfully connect an audio source to a video sink. Filters and connections form a directed acyclic graph. The videotestsrc element is a source. That is, it has no inputs, and has one video output. For this particular filter, the output is a fixed test image. There is a sink filter that can display video. By connecting a videotestsrc to a sink, you get a minimal complete graph that does something. A full graph for playing a video or audio clip will typically contain: * A file or URL source. This knows the URL of the input file and outputs a byte stream. * A splitter or demultiplexer. This takes the byte stream and outputs separate streams for any video, audio or subtitle tracks included. Different container formats (e.g. AVI, MP4, Matroska, Ogg) require different demux filters. (Closest UNIX analogy: zip and tar are different containers, and use different programs.) The user may not want all streams rendered =E2=80=94 e.g. when watching a f= ilm that contains audio tracks in English and Spanish, they will want just one. * Decoders for a subset of streams in the clip. (The user may not want all streams rendered =E2=80=94 e.g. when watching a film that contains audi= o tracks in English and Spanish, they will want just one.) Each specific video or audio compression format requires a different decoder filter. (Analogy: deflate, xz, and bzip are different compression formats.) A decoder takes a compressed stream from the demultiplexer and outputs raw RGB or YCbCr video or PCM audio. * =E2=80=9CRenderers=E2=80=9D or =E2=80=9Csinks=E2=80=9D for the decoded vi= deo and audio. These differ by target video or audio subsystem (e.g. pulseaudio), hardware acceleration capabilities, etc. > I'm trying to find out how Emacs determines which plug-ins to use > for any given argument supplied by the ueer. And what do they depend on? > Does a given file format fully determine the plug-ins to use? A given file format (which is a combination of the container format and compression formats of individual streams within) constrains the set of possible rendering graphs. A system may have multiple filters capable of filling each of the roles listed above. In that case, the application (e.g. Emacs) can choose between possibilities. Frameworks have a way to try to automatically complete a rendering graph for a source; I do not know all the details on how they resolve ambiguities.