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 BD31D452D5 for ; Sun, 19 Mar 2023 18:38:43 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4989668C3CE; Sun, 19 Mar 2023 20:38:41 +0200 (EET) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2D24968C26B for ; Sun, 19 Mar 2023 20:38:35 +0200 (EET) Received: by mail-wm1-f51.google.com with SMTP id fm20-20020a05600c0c1400b003ead37e6588so7884958wmb.5 for ; Sun, 19 Mar 2023 11:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679251114; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=zsUPq0DtO0UwQZqBrpHD86vYoH+J7zIIADNYjAaAhOc=; b=E0vi7lH+9uIZfXfj9bmpZJ0crbudNeToFTOVDp9hQWLtUK1Pn2FQA4w6j+bydaazpq aHx9jTzhKO9MykM3AhbbbK87AKxXVhHvGekdvV+t2YYUp1/4lMLKbR/hObjxEfr7kjYb Y7Lgy+jXL3EokBNxqpd32yMQbFHelLaUizkEkLQzQs5YsYhzjqQjFk9x4SLFiUqYSY4i 6gCbYKYdfgszla4hAI7gQVEkxtj5eWUzG8oTbLCfIp7Yc7MNPYlm+vuObY0Ano6424Vc rf7bvYbYBre/oDWXloEXYQeU9OKCI+tBp9xqDBB9Qcavtw+bi5x9sqQTAh74G4ZkHxMB c0hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679251114; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zsUPq0DtO0UwQZqBrpHD86vYoH+J7zIIADNYjAaAhOc=; b=EitFWipaX5e4S8//NzonPu/P9ZB+A8j+YORgQqMdIpcFMAm1lPGGKhhZiV9iHcv7gn 7x1oQi4XcaF2RmubDAPtxgmKeYttV/gp3E/73AA0MMpGklN4znNBPgVkf9fsXMso8Q90 ZJ+YTaJKtBL8Ukc148x/clgi+EZcgH+PqlimErfp9n+TVQNCyL+IlDS5CaP7KiMpKLWi OhRMxw9kCI5sqFxi+gSVojyeRxkFOTH9+w39YAtTFUhxJSqAj/jcWBa3qj6m2Qb5ZRLt DzyMvySgvg/OFM5WzanBQdYlN5XtawFeD4JFTml39lEkGR7VPz9O0oHCIJU5Du7rADcZ lMnw== X-Gm-Message-State: AO0yUKW4Q9AJ6BaUv3Ll63/dyKMEi1jF4NECnoBbYIjzJa/QBL/bVshU F6q+W5xONdnFSTzS3XCOBq9MqXKK1uY= X-Google-Smtp-Source: AK7set8ziZKhaKPHY8Q1gS9X/eBlKd0cQHOeB107JMnIsUoo0lYjcmtI2yGxgg6ilMektUd+HX9lwg== X-Received: by 2002:a7b:ce8e:0:b0:3ed:9e29:4c38 with SMTP id q14-20020a7bce8e000000b003ed9e294c38mr6099604wmj.31.1679251113802; Sun, 19 Mar 2023 11:38:33 -0700 (PDT) Received: from mariano (dynamic-adsl-62-10-90-114.clienti.tiscali.it. [62.10.90.114]) by smtp.gmail.com with ESMTPSA id bi6-20020a05600c3d8600b003ede178dc52sm2031140wmb.40.2023.03.19.11.38.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Mar 2023 11:38:33 -0700 (PDT) Received: by mariano (Postfix, from userid 1000) id 0E25BBFB73; Sun, 19 Mar 2023 19:38:31 +0100 (CET) Date: Sun, 19 Mar 2023 19:38:31 +0100 From: Stefano Sabatini To: FFmpeg development discussions and patches Message-ID: <20230319183831.GE48946@mariano> Mail-Followup-To: FFmpeg development discussions and patches References: <167907670856.27013.1024468160578947954@lain.khirnov.net> <2126853.oF9KHgkBuv@basile.remlab.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2126853.oF9KHgkBuv@basile.remlab.net> User-Agent: Mutt/1.13.2 (2019-12-18) Subject: Re: [FFmpeg-devel] RFC: opinions on making fftools work like a library 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: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On date Sunday 2023-03-19 11:01:55 +0200, R=E9mi Denis-Courmont wrote: > Le lauantaina 18. maaliskuuta 2023, 13.33.36 EET Neal Gompa a =E9crit : > > > Maybe you should first clarify what exactly do you mean by "work like= a > > > library". Meaning literally turn it into a library with a C API you c= an > > > call? That would be a massive amount of work, though my current > > > refactorings are moving in that direction. > > > Or provide stronger guarantees for commandline options? Or something > > > else? > > = > > I think the idea is to turn fftools (e.g. ffmpeg/ffplay/ffprobe) into > > a generic, simple high level stable API that consumers can use. The > > raw libav* APIs are difficult for most people to use, which leads to a > > ton of wrappers around the fftools instead. > = > That sounds like a self-contradictory goal, TBH. > = > There are so many different settings, complex interactions between settin= gs, = > and so much variability depending on versions and build parameters. > = > > Yes, it would be a lot of work, but it would make using ffmpeg way easi= er. > = > Or not. You would have to define an API for literally every command line = switch = > that each of the tools exhibits. This would unavoidably result in some ki= nd of = > high-level abstract and rather complex settings API that would be prone t= o = > silent breaks has the names, values and semantics of settings vary with = > versions and builds. > = > There may be value in doing that anyway. In particular, it could improve = the = > progress and error reporting with callbacks rather than parsing the stand= ard = > output. But it probably wouldn't be in "simplifying" the use of the tools. One of the ideas at some point was to move the functionality into kind of high-level constructs such as a libavfilter filtergraph: you would have basically to define the input and output of the filtergraph and then feed and read the output from it. At the moment this has several limitations though: for example there is all kind of custom logic into ffmpeg.c (e.g. related to timestamp handling and global synchronization). This in theory could be achieved by extending the filtering logic to data, so that you have pluggable filters to handle custom data processing logic (e.g. timestamp tweaking). Then you could implement a player by reading from the filtergraph and sending the output packets to your rendering engine and sending controls to the filtergraph to stop/resume processing and changing the filters parameters. ffprobe could be implemented as a data filter/processor on top of a decoding filtergraph. This is an ideal design but in practice there are still many things missing (for example data filtering) and threading/synchronization with the application logic might be tricky. _______________________________________________ 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".