From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 9970B48706 for ; Fri, 15 Dec 2023 12:37:46 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AB66E68D1CD; Fri, 15 Dec 2023 14:37:43 +0200 (EET) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3E6ED68CFC2 for ; Fri, 15 Dec 2023 14:37:37 +0200 (EET) X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from metallschleimette ([91.4.224.196]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N7zBb-1rJT1P1lgJ-0152GH for ; Fri, 15 Dec 2023 13:37:36 +0100 Date: Fri, 15 Dec 2023 13:37:35 +0100 To: FFmpeg development discussions and patches Message-ID: References: <170245852534.8914.12550775596488175101@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:8Z7mIQ5ZkGz4qKTdaZpB+Z51c0aAwKwsiiuzqo5woDdrt8m5b7w rFj+w80exyN1Vm48576ct+AtIQFwQ9Lwm26WeiY2pGM9ulHTZcvrpual0zQeDYGJvHEL2xT P22SOS9m0JqD9BUFrIqasebyhzjm1AXTkwGL3KVkvxEZ7ylGx42Cvqb8HQoHQstUu7CALtk fTCHcdGHY5ts3DsOAmL9g== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:+7k0lUR2G04=;pb9RQk/FpLm3kfMN+riaiIOyTJv NY6+XQmJL6c+muJc61HsvXgw0QaY8QovurXqgrIVo04cxYbQSzQVljENQMToh/dFiADaDsl2/ JLpaO4eMBdKIUPjxN0d/Rr4A3msKuiXzfDexXJ/LLcIIBEZHLtj2uxYdqjXLO6ZL4ZaJQb2T9 LFWozYpOfIonh10hqJQuVOS6qbCSqLUNToqlko6DPMPni2UbBiyXTxly+8QP6xRnZvtOTk9kv H5L9o/2PnfnphrbvOxUO1jj0JwQz5fnTSmFxjDGCeRdw2rS485EVm600Z+SljiX18DldbdNns d687LMc9zXhSfopqEx8AJDnNTC5Wi2Ejwuv2FejoAaLSoLQtoF9x7Qs/V4q7lLDqhTIUGF7sc bj+PrE3zxIvfUVm0XibVU1iOX9L3SjvgRmTheWH4iShDD8tjVJSqv4K78hrm+q6UCXkRTRTaZ VfXxFZQRcX90AKoQL1g4+fj/wPY9O4QsJmVGgA4lgWfPBXtipaCPsXPsZ86EdA8e0VMlSt/4X uUH4VTS45kakzeWQ/I1/aB3qbmRHApbhvjgUH3314nHJTI7Doeg9Nhfw6lPdSAb3GGWRG2F4O 77g7F8kma/xBL9VZNzimjLRgOof5QpuiQNdQzLz0d7RxlfEgyDkAUeIo3cjkBblx7u7DoK4aP uAnlsmoWZ/RtI9fBIrqFxcgUk1fkB70IVTar6v+fmX9wfVHij/wYrxHdvH4yKXJMI9wtx3NUH SYX9SL1wK5pwIpF1whqZf5xMo8IMuzQvuOHltU+Bp7bg4cButPhfRm1mPpMptllWMnmupcNOT gCe5t04V+wjbenmcNuFXQuQbu8iF7jHnAyH0QlRC7jKvwQTMieG7Ae0pxgE/szG7GX7WWG9EZ k5v70CBM6OU/Xljifc58K5Hc9Gr1MXbb4GEXpH50feuDWgprYWQaJ2ohEvML+e9JSZ5LcZB4a Axnzuw== Subject: Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Alexander Strasser via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Alexander Strasser Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2023-12-14 01:47 +0100, Stefano Sabatini wrote: > On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote: > > Quoting Zhao Zhili (2023-12-12 18:27:39) > [...] > > Honestly I don't see how this could be done in ffmpeg CLI without > > disgusting hacks, but before that the question is: > > > why is there an SDL > > "muxer" and why would anyone want to use it in ffmpeg CLI? What actual > > use cases does it serve that cannot be better handled otherwise? > > As the author of the first sdl.c muxer, maybe I can answer to this > question. It was done partly as an exercise and for fun, but also > because this was useful extremely handy for testing (e.g. to display > the output of a filterchain from ffmpeg, or to display a streamed > video in realtime). That is what I used it for countless times as well. It has a lot of merit in handling compared to piping to a player, where one needs to run 2 processes in one command line with all the drawbacks that come with it. > The final goal was (still is) to unify all the tools as very thin > instances of the library. Even if this might be not practical, I think > it is a good final design plan (e.g. ffprobe might be turned to a > custom muxer, ffplay would be the realtime output of a filtergraph > connected to a rendering device, ffmpeg would be a data filtergraph > processor, and you can mix rendering and encoding if you add a movie > sink to the game). I agree to this perspective. Making most of the functionality available through the FFmpeg libs and therefore available for wider application of a broader audience seems valuable. Such a big goal that cannot be reached in a predictable time frame should be challenged over the years and the plans, in so far they exist, need to be adjusted accordingly. Still that doesn't mean the goal is not worthwhile or not achievable. On an ending note: I don't like at all the way this discussion unraveled: 1. Someone wants to fix a reported problem after the new threading changes 2. It is questioned why a feature that exists for over a decade is there I hope this can get back on a more constructive rail. Otherwise I fear it just sets precedence for more to come :( Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".