Re: [FFmpeg-devel] [PATCH] avformat/webmdashenc: fix on-demand profile string
On Fri, Apr 8, 2022 at 2:58 AM James Almer wrote:
>
> Fixes ticket #9596
>
> Signed-off-by: James Almer
> ---
> libavformat/webmdashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
> index a942c484e9..f8f2274556 100644
> --- a/libavformat/webmdashenc.c
> +++ b/libavformat/webmdashenc.c
> @@ -95,7 +95,7 @@ static int write_header(AVFormatContext *s)
> }
> avio_printf(pb, " minBufferTime=\"PT%gS\"\n", min_buffer_time);
> avio_printf(pb, " profiles=\"%s\"%s",
> -w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" :
> "urn:webm:dash:profile:webm-on-demand:2012",
> +w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" :
> "urn:mpeg:dash:profile:webm-on-demand:2012",
> w->is_live ? "\n" : ">\n");
> if (w->is_live) {
> time_t local_time = time(NULL);
> --
> 2.35.1
This needs FATE updates now, got a bit yellow around there.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/webmdashenc: fix on-demand profile string
On Fri, Apr 8, 2022 at 8:58 AM James Almer wrote:
>
> Fixes ticket #9596
>
> Signed-off-by: James Almer
> ---
> libavformat/webmdashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
> index a942c484e9..f8f2274556 100644
> --- a/libavformat/webmdashenc.c
> +++ b/libavformat/webmdashenc.c
> @@ -95,7 +95,7 @@ static int write_header(AVFormatContext *s)
> }
> avio_printf(pb, " minBufferTime=\"PT%gS\"\n", min_buffer_time);
> avio_printf(pb, " profiles=\"%s\"%s",
> -w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" :
> "urn:webm:dash:profile:webm-on-demand:2012",
> +w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" :
> "urn:mpeg:dash:profile:webm-on-demand:2012",
> w->is_live ? "\n" : ">\n");
> if (w->is_live) {
> time_t local_time = time(NULL);
LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] movenc: add write_btrt option
> On Apr 8, 2022, at 4:36 AM, Jan Ekström wrote:
>
> On Thu, Apr 7, 2022 at 11:42 AM Eran Kornblau
> wrote:
>>
>>>
>>>
>>> -Original Message-
>>> From: ffmpeg-devel On Behalf Of
>>> "zhilizhao(???)"
>>> Sent: Wednesday, 6 April 2022 11:46
>>> To: FFmpeg development discussions and patches
>>> Subject: Re: [FFmpeg-devel] movenc: add write_btrt option
>>>
On Apr 3, 2022, at 1:07 PM, Eran Kornblau
wrote:
Trying my luck in a new thread…
This patch is in continuation to this discussion –
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmp
eg.org%2Fpipermail%2Fffmpeg-devel%2F2022-March%2F294623.html&data=
04%7C01%7C%7Cb9907958f97048f5645708da17a9f3c8%7C0c503748de3f4e2597e268
19d53a42b6%7C1%7C0%7C637848315958196733%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
p;sdata=flQc21b5EVWTy%2Bkmw%2FncIWzdLqUxY5XFislPRs5Ij6o%3D&reserve
d=0
supports forcing or disabling the writing of the btrt atom.
the default behavior is to write the atom only for mp4 mode.
---
libavformat/movenc.c | 30 +++---
libavformat/movenc.h | 1 +
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c index
4c868919ae..b75f1c6909 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
>>> […]
-if (track->mode == MODE_MP4 &&
-((ret = mov_write_btrt_tag(pb, track)) < 0))
-return ret;
+if ((mov->write_btrt == -1 && track->mode == MODE_MP4) ||
mov->write_btrt == 1) {
+if ((ret = mov_write_btrt_tag(pb, track)) < 0) {
+return ret;
+}
+}
>>>
>>> I prefer to handle the auto mode (mov->write_btrt == -1) in a single place,
>>> so we don’t need to change multiple lines if the condition changed, e.g.,
>>> enable btrt for MODE_MOV. Please correct me if I’m wrong, mov_init() has
>>> all of the contexts to overwrite mov->write_btrt.
>>>
>> Makes sense, thanks for the feedback!
>> Updated patch attached
>>
>> Eran
>
> Generally speaking I am not against this patch. Would have possibly
> came up with something similar myself in case the actual output of
> libavformat would have caused issues, which surprisingly enough it
> wasn't.
>
> I know you have just copied the logic from tmcd or so, but I think the
> -1 logic is unnecessary. We don't need to force writing of this
> structure no matter what, so you either have it enabled (by default),
> or disabled. If additional formats such as QTFF have since added the
> btrt box into their specification, that doesn't need forcing, but
> rather addition of it into the logic later (if you wanted forcing then
> you'd have to deal with strict_std_compliance being
> unofficial/experimental or higher etc, and if this was not set -
> warning the user that a not officially defined functionality was being
> written into the container and exiting with AVERROR_EXPERIMENTAL).
>
> Additionally, I thought new options go to the end of the AVOption
> array, but then saw 1dddb930aaf0cadaa19f86e81225c9c352745262 where
> James added "crf" into the middle of an array... so I guess since it's
> an array and not a struct the location no longer matters as much?
> ┐(´д｀)┌ Although the struct integer should definitely go to the end of
> it, otherwise you are breaking existing offsets? Although thankfully,
> the struct isn't externally exposed so someone else could chime in
> regarding this, I am unfortunately quite tired throughout this week :P
> .
The order of options and the offset of fields in private struct have no
effect on ABI. I take these into consideration:
1. Readability. Related options and fields should be put at the same
place.
2. Memory footprint. Reduce struct padding.
>
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] qsvenc: fix typo
> -Original Message- > From: ffmpeg-devel On Behalf Of Haihao Xiang > Sent: Thursday, April 7, 2022 3:01 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Xiang, Haihao > Subject: [FFmpeg-devel] [PATCH] qsvenc: fix typo > > --- > libavcodec/qsvenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c > index 2514d5b256..fbb22ca436 100644 > --- a/libavcodec/qsvenc.c > +++ b/libavcodec/qsvenc.c > @@ -1003,7 +1003,7 @@ static int init_video_param(AVCodecContext *avctx, > QSVEncContext *q) > q->extco3.LowDelayBRC = q->low_delay_brc ? > MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF; > #endif > #if QSV_VERSION_ATLEAST(1, 19) > -if (q->max_frame_size_p >= 0) > +if (q->max_frame_size_i >= 0) > q->extco3.MaxFrameSizeI = q->max_frame_size_i; > if (q->max_frame_size_p >= 0) > q->extco3.MaxFrameSizeP = q->max_frame_size_p; > -- > 2.17.1 > LGTM > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/webmdashenc: fix on-demand profile string
Fixes ticket #9596
Signed-off-by: James Almer
---
libavformat/webmdashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index a942c484e9..f8f2274556 100644
--- a/libavformat/webmdashenc.c
+++ b/libavformat/webmdashenc.c
@@ -95,7 +95,7 @@ static int write_header(AVFormatContext *s)
}
avio_printf(pb, " minBufferTime=\"PT%gS\"\n", min_buffer_time);
avio_printf(pb, " profiles=\"%s\"%s",
-w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" :
"urn:webm:dash:profile:webm-on-demand:2012",
+w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" :
"urn:mpeg:dash:profile:webm-on-demand:2012",
w->is_live ? "\n" : ">\n");
if (w->is_live) {
time_t local_time = time(NULL);
--
2.35.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffmpeg: document -d option
On date Wednesday 2022-04-06 16:43:02 +0200, Michael Niedermayer wrote:
> On Tue, Apr 05, 2022 at 11:27:08PM +0200, Stefano Sabatini wrote:
> > On date Tuesday 2022-04-05 07:23:27 +0200, Anton Khirnov wrote:
> > > Quoting Stefano Sabatini (2022-04-03 17:27:06)
> > > > Option was added in commit 39aafa5ee90e10382e.
> > > >
> > > > Fix trac issue: http://trac.ffmpeg.org/ticket/1698
> > > > ---
> > > > doc/ffmpeg.texi | 12
> > > > fftools/ffmpeg_opt.c | 3 +++
> > > > 2 files changed, 15 insertions(+)
> > >
> > > Does this option do anything useful? Shouldn't it rather be removed?
> >
> > Works for me.
> >
> > Do we have a use case for this? This basically disables logs and
> > detaches ffmpeg from the terminal.
> >
> > @Michael, can you comment about this (this was added by you)?
>
> i have a few udp&tcp tests that used it but i tried now and they work fine
> if i remove it so iam not aware of a current use case
Updated.
>From d5a8c745a7d82f424cc013d9d4b4429aa8fa20e6 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Sun, 3 Apr 2022 17:24:40 +0200
Subject: [PATCH] ffmpeg: drop undocumented -d option
Option was added in commit 39aafa5ee90e10382e but was never documented.
Also does not seem there are current use cases for it,
tests for which it was introduced are still working therefore we drop
it altogether.
Indirectly fix trac issue: http://trac.ffmpeg.org/ticket/1698
---
Changelog| 1 +
fftools/ffmpeg.c | 12 ++--
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/Changelog b/Changelog
index e173d43229..5bae61bad5 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version 5.1:
- pcm-bluray encoder
- DFPWM audio encoder/decoder and raw muxer/demuxer
- SITI filter
+- drop ffmpeg -d option
version 5.0:
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6d62bdc7b0..f82ba8a175 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -132,7 +132,6 @@ static BenchmarkTimeStamps get_benchmark_time_stamps(void);
static int64_t getmaxrss(void);
static int ifilter_has_all_input_formats(FilterGraph *fg);
-static int run_as_daemon = 0;
static int nb_frames_dup = 0;
static unsigned dup_warning = 1000;
static int nb_frames_drop = 0;
@@ -420,7 +419,7 @@ void term_init(void)
#endif
#if HAVE_TERMIOS_H
-if (!run_as_daemon && stdin_interaction) {
+if (stdin_interaction) {
struct termios tty;
if (tcgetattr (0, &tty) == 0) {
oldtty = tty;
@@ -3854,7 +3853,7 @@ static int check_keyboard_interaction(int64_t cur_time)
if (received_nb_signals)
return AVERROR_EXIT;
/* read_key() returns 0 on EOF */
-if(cur_time - last_time >= 10 && !run_as_daemon){
+if (cur_time - last_time >= 10) {
key = read_key();
last_time = cur_time;
}else
@@ -4864,13 +4863,6 @@ int main(int argc, char **argv)
av_log_set_flags(AV_LOG_SKIP_REPEATED);
parse_loglevel(argc, argv, options);
-if(argc>1 && !strcmp(argv[1], "-d")){
-run_as_daemon=1;
-av_log_set_callback(log_callback_null);
-argc--;
-argv++;
-}
-
#if CONFIG_AVDEVICE
avdevice_register_all();
#endif
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] tests: add README.md file with simple instructions
On date Wednesday 2022-04-06 09:24:16 +0200, Thilo Borgmann wrote: > Am 05.04.22 um 23:40 schrieb Stefano Sabatini: > > On date Monday 2022-04-04 10:30:27 +0200, Thilo Borgmann wrote: > > > Hi, > > > > > > Am 03.04.22 um 15:59 schrieb Stefano Sabatini: > > > > --- > > > >tests/README.md | 48 > > > >1 file changed, 48 insertions(+) > > > >create mode 100644 tests/README.md > > > > > > > > diff --git a/tests/README.md b/tests/README.md > > > > new file mode 100644 > > > > index 00..4bcae0b403 > > > > --- /dev/null > > > > +++ b/tests/README.md > > > > > > currently we got part of that in doc/fate.texi. Doesn't it make more > > > sense to add that there? > > > > Makes sense, totally missed it, updated. > > Pushed, thanks! Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v13 1/1] avformat: Add IPFS protocol support.
On Wed, Apr 6, 2022 at 2:02 PM Mark Gaiser wrote: > This patch adds support for: > - ffplay ipfs:// > - ffplay ipns:// > > IPFS data can be played from so called "ipfs gateways". > A gateway is essentially a webserver that gives access to the > distributed IPFS network. > > This protocol support (ipfs and ipns) therefore translates > ipfs:// and ipns:// to a http:// url. This resulting url is > then handled by the http protocol. It could also be https > depending on the gateway provided. > > To use this protocol, a gateway must be provided. > If you do nothing it will try to find it in your > $HOME/.ipfs/gateway file. The ways to set it manually are: > 1. Define a -gateway to the gateway. > 2. Define $IPFS_GATEWAY with the full http link to the gateway. > 3. Define $IPFS_PATH and point it to the IPFS data path. > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). > > Signed-off-by: Mark Gaiser > --- > configure | 2 + > doc/protocols.texi| 30 > libavformat/Makefile | 2 + > libavformat/ipfsgateway.c | 339 ++ > libavformat/protocols.c | 2 + > 5 files changed, 375 insertions(+) > create mode 100644 libavformat/ipfsgateway.c > > diff --git a/configure b/configure > index e4d36aa639..55af90957a 100755 > --- a/configure > +++ b/configure > @@ -3579,6 +3579,8 @@ udp_protocol_select="network" > udplite_protocol_select="network" > unix_protocol_deps="sys_un_h" > unix_protocol_select="network" > +ipfs_protocol_select="https_protocol" > +ipns_protocol_select="https_protocol" > > # external library protocols > libamqp_protocol_deps="librabbitmq" > diff --git a/doc/protocols.texi b/doc/protocols.texi > index d207df0b52..90a9eefde0 100644 > --- a/doc/protocols.texi > +++ b/doc/protocols.texi > @@ -2025,5 +2025,35 @@ decoding errors. > > @end table > > +@section ipfs > + > +InterPlanetary File System (IPFS) protocol support. One can access files > stored > +on the IPFS network through so called gateways. Those are http(s) > endpoints. > +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be > send > +to such a gateway. Users can (and should) host their own node which means > this > +protocol will use your local gateway to access files on the IPFS network. > + > +If a user doesn't have a node of their own then the public gateway > dweb.link is > +used by default. > + > +You can use this protocol in 2 ways. Using IPFS: > +@example > +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +Or the IPNS protocol (IPNS is mutable IPFS): > +@example > +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +You can also change the gateway to be used: > + > +@table @option > + > +@item gateway > +Defines the gateway to use. When nothing is provided the protocol will > first try > +your local gateway. If that fails dweb.link will be used. > + > +@end table > > @c man end PROTOCOLS > diff --git a/libavformat/Makefile b/libavformat/Makefile > index d7182d6bd8..e3233fd7ac 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -660,6 +660,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += > srtpproto.o srtp.o > OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o > OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o > OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o > +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o > +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o > TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o > TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o > TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c > new file mode 100644 > index 00..05fd37bbc5 > --- /dev/null > +++ b/libavformat/ipfsgateway.c > @@ -0,0 +1,339 @@ > +/* > + * IPFS and IPNS protocol support through IPFS Gateway. > + * Copyright (c) 2022 Mark Gaiser > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301 USA > + */ > + > +#include "libavutil/avstring.h" > +#include "libavutil/opt.h" > +#include > +#include "os_support.h" > +#include "url.h" > + > +typedef struct IPFSGatewayCon
Re: [FFmpeg-devel] [PATCH] avfilter/alimiter: Add "flush_buffer" option to flush the remaining valid data to the output
On Thu, Apr 7, 2022 at 12:44 AM Paul B Mahol wrote: > On Wed, Apr 6, 2022 at 1:49 PM Paul B Mahol wrote: > > > > > > > On Tue, Apr 5, 2022 at 8:57 PM Wang Cao < > wangcao-at-google@ffmpeg.org> > > wrote: > > > >> On Mon, Apr 4, 2022 at 3:28 PM Marton Balint wrote: > >> > >> > > >> > > >> > On Mon, 4 Apr 2022, Paul B Mahol wrote: > >> > > >> > > On Sun, Mar 27, 2022 at 11:41 PM Marton Balint > wrote: > >> > > > >> > >> > >> > >> > >> > >> On Sat, 26 Mar 2022, Wang Cao wrote: > >> > >> > >> > >>> The change in the commit will add some samples to the end of the > >> audio > >> > >>> stream. The intention is to add a "zero_delay" option eventually > to > >> not > >> > >>> have the delay in the begining the output from alimiter due to > >> > >>> lookahead. > >> > >> > >> > >> I was very much suprised to see that the alimiter filter actually > >> delays > >> > >> the audio - as in extra samples are inserted in the beginning and > >> some > >> > >> samples are cut in the end. This trashes A-V sync, so it is a bug > >> IMHO. > >> > >> > >> > >> So unless somebody has some valid usecase for the legacy way of > >> > operation > >> > >> I'd just simply change it to be "zero delay" without any additional > >> user > >> > >> option, in a single patch. > >> > >> > >> > > > >> > > > >> > > This is done by this patch in very complicated way and also it > really > >> > > should be optional. > >> > > >> > But why does it make sense to keep the current (IMHO buggy) > operational > >> > mode which adds silence in the beginning and trims the end? I > understand > >> > that the original implementation worked like this, but libavfilter has > >> > packet timestamps and N:M filtering so there is absolutely no reason > to > >> > use an 1:1 implementation and live with its limitations. > >> > > >> Hello Paul and Marton, thank you so much for taking time to review my > >> patch. > >> I totally understand that my patch may seem a little bit complicated > but I > >> can > >> show with a FATE test that if we set the alimiter to behave as a > >> passthrough filter, > >> the output frames will be the same from "framecrc" with my patch. The > >> existing > >> behavior will not work for all gapless audio processing. > >> > >> The complete patch to fix this issue is at > >> > >> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220330210314.2055201-1-wang...@google.com/ > >> > >> Regarding Paul's concern, I personally don't have any preference whether > >> to > >> put > >> the patch as an extra option or not. With respect to the implementation, > >> the patch > >> is the best I can think of by preserving as much information as possible > >> from input > >> frames. I also understand it may break concept that "filter_frame" > outputs > >> one frame > >> at a time. For alimiter with my patch, depending on the size of the > >> lookahead buffer, > >> it may take a few frames before one output frame can be generated. This > is > >> inevitable > >> to compensate for the delay of the lookahead buffer. > >> > >> Thanks again for reviewing my patch and I'm looking forward to hearing > >> from > >> you :) > >> > > > > Better than (because its no more 1 frame X nb_samples in, 1 frame X > > nb_samples out) to replace .filter_frame/.request_frame with .activate > > logic. > > > > And make this output delay compensation filtering optional. > > > > In this process make sure that output PTS frame timestamps are unchanged > > from input one, by keeping reference of needed frames in filter queue. > > > > Look how speechnorm/dynaudnorm does it. > > > > > Alternatively, use current logic in ladspa filter, (also add option with > same name). > > This would need less code, and probably better approach, as there is no > extra latency introduced. > > Than mapping 1:1 between same number of samples per frame is not hold any > more, but I think that is not much important any more. > Thank you for replying to me with your valuable feedback! I have checked af_ladspa and the "request_frame" function in af_ladspa looks similar to what I'm doing. The difference comes from the fact that I need an internal frame buffer to keep track of output frames. Essentially I add a frame to the internal buffer when an input frame comes in. The frames in this buffer will be the future output frames. We start writing these output frame data buffers only when the internal lookahead buffer has been filled. When there is no more input frames, we flushing all the remaining data in the internal frame buffers and lookahead buffers. Can you advise on my approach here? Thank you! I can put my current implementation of "filter_frame" and "request_frame" into the "activate" approach as you suggested with speechnorm/dynaudnorm. -- Wang Cao | Software Engineer | wang...@google.com | 650-203-7807 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or ema
Re: [FFmpeg-devel] movenc: add write_btrt option
On Thu, Apr 7, 2022 at 11:42 AM Eran Kornblau wrote:
>
> >
> >
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > "zhilizhao(???)"
> > Sent: Wednesday, 6 April 2022 11:46
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] movenc: add write_btrt option
> >
> > > On Apr 3, 2022, at 1:07 PM, Eran Kornblau
> > > wrote:
> > >
> > > Trying my luck in a new thread…
> > >
> > > This patch is in continuation to this discussion –
> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmp
> > > eg.org%2Fpipermail%2Fffmpeg-devel%2F2022-March%2F294623.html&data=
> > > 04%7C01%7C%7Cb9907958f97048f5645708da17a9f3c8%7C0c503748de3f4e2597e268
> > > 19d53a42b6%7C1%7C0%7C637848315958196733%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
> > > p;sdata=flQc21b5EVWTy%2Bkmw%2FncIWzdLqUxY5XFislPRs5Ij6o%3D&reserve
> > > d=0
> > >
> > > supports forcing or disabling the writing of the btrt atom.
> > > the default behavior is to write the atom only for mp4 mode.
> > > ---
> > > libavformat/movenc.c | 30 +++---
> > > libavformat/movenc.h | 1 +
> > > 2 files changed, 20 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c index
> > > 4c868919ae..b75f1c6909 100644
> > > --- a/libavformat/movenc.c
> > > +++ b/libavformat/movenc.c
> > >
> > […]
> > >
> > > -if (track->mode == MODE_MP4 &&
> > > -((ret = mov_write_btrt_tag(pb, track)) < 0))
> > > -return ret;
> > > +if ((mov->write_btrt == -1 && track->mode == MODE_MP4) ||
> > > mov->write_btrt == 1) {
> > > +if ((ret = mov_write_btrt_tag(pb, track)) < 0) {
> > > +return ret;
> > > +}
> > > +}
> >
> > I prefer to handle the auto mode (mov->write_btrt == -1) in a single place,
> > so we don’t need to change multiple lines if the condition changed, e.g.,
> > enable btrt for MODE_MOV. Please correct me if I’m wrong, mov_init() has
> > all of the contexts to overwrite mov->write_btrt.
> >
> Makes sense, thanks for the feedback!
> Updated patch attached
>
> Eran
Generally speaking I am not against this patch. Would have possibly
came up with something similar myself in case the actual output of
libavformat would have caused issues, which surprisingly enough it
wasn't.
I know you have just copied the logic from tmcd or so, but I think the
-1 logic is unnecessary. We don't need to force writing of this
structure no matter what, so you either have it enabled (by default),
or disabled. If additional formats such as QTFF have since added the
btrt box into their specification, that doesn't need forcing, but
rather addition of it into the logic later (if you wanted forcing then
you'd have to deal with strict_std_compliance being
unofficial/experimental or higher etc, and if this was not set -
warning the user that a not officially defined functionality was being
written into the container and exiting with AVERROR_EXPERIMENTAL).
Additionally, I thought new options go to the end of the AVOption
array, but then saw 1dddb930aaf0cadaa19f86e81225c9c352745262 where
James added "crf" into the middle of an array... so I guess since it's
an array and not a struct the location no longer matters as much?
┐(´д｀)┌ Although the struct integer should definitely go to the end of
it, otherwise you are breaking existing offsets? Although thankfully,
the struct isn't externally exposed so someone else could chime in
regarding this, I am unfortunately quite tired throughout this week :P
.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing
On Mon, Mar 28, 2022 at 1:49 PM Vignesh Venkatasubramanian
wrote:
>
> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
>
> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
>
> Sample usage for still image:
> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
>
> Sample usage for animated AVIF image:
> ffmpeg -i video.mp4 animated.avif
>
> We can re-use any of the AV1 encoding options that will make
> sense for image encoding (like bitrate, tiles, encoding speed,
> etc).
>
> The files generated by this muxer has been verified to be valid
> AVIF files by the following:
> 1) Displays on Chrome (both still and animated images).
> 2) Displays on Firefox (only still images, firefox does not support
>animated AVIF yet).
> 3) Verfied to be valid by Compliance Warden:
>https://github.com/gpac/ComplianceWarden
>
> Fixes the encoder/muxer part of Trac Ticket #7621
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> configure| 1 +
> libavformat/allformats.c | 1 +
> libavformat/movenc.c | 337 ---
> libavformat/movenc.h | 5 +
> 4 files changed, 319 insertions(+), 25 deletions(-)
>
> diff --git a/configure b/configure
> index e4d36aa639..b9a79d8982 100755
> --- a/configure
> +++ b/configure
> @@ -3396,6 +3396,7 @@ asf_stream_muxer_select="asf_muxer"
> av1_demuxer_select="av1_frame_merge_bsf av1_parser"
> avi_demuxer_select="riffdec exif"
> avi_muxer_select="riffenc"
> +avif_muxer_select="mov_muxer"
> caf_demuxer_select="iso_media"
> caf_muxer_select="iso_media"
> dash_muxer_select="mp4_muxer"
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 587ad59b3c..29e58353ee 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -81,6 +81,7 @@ extern const AVOutputFormat ff_au_muxer;
> extern const AVInputFormat ff_av1_demuxer;
> extern const AVInputFormat ff_avi_demuxer;
> extern const AVOutputFormat ff_avi_muxer;
> +extern const AVOutputFormat ff_avif_muxer;
> extern const AVInputFormat ff_avisynth_demuxer;
> extern const AVOutputFormat ff_avm2_muxer;
> extern const AVInputFormat ff_avr_demuxer;
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 70ceb0dea4..920f3dcf25 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1306,7 +1306,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, MOVTrack
> *track)
>
> avio_wb32(pb, 0);
> ffio_wfourcc(pb, "av1C");
> -ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
> +ff_isom_write_av1c(pb, track->vos_data, track->vos_len, track->mode !=
> MODE_AVIF);
> return update_size(pb, pos);
> }
>
> @@ -2007,12 +2007,13 @@ static int mov_write_colr_tag(AVIOContext *pb,
> MOVTrack *track, int prefer_icc)
> }
> }
>
> -/* We should only ever be called by MOV or MP4. */
> -av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4);
> +/* We should only ever be called for MOV, MP4 and AVIF. */
> +av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4 ||
> + track->mode == MODE_AVIF);
>
> avio_wb32(pb, 0); /* size */
> ffio_wfourcc(pb, "colr");
> -if (track->mode == MODE_MP4)
> +if (track->mode == MODE_MP4 || track->mode == MODE_AVIF)
> ffio_wfourcc(pb, "nclx");
> else
> ffio_wfourcc(pb, "nclc");
> @@ -2022,7 +2023,7 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack
> *track, int prefer_icc)
> avio_wb16(pb, track->par->color_primaries);
> avio_wb16(pb, track->par->color_trc);
> avio_wb16(pb, track->par->color_space);
> -if (track->mode == MODE_MP4) {
> +if (track->mode == MODE_MP4 || track->mode == MODE_AVIF) {
> int full_range = track->par->color_range == AVCOL_RANGE_JPEG;
> avio_w8(pb, full_range << 7);
> }
> @@ -2088,7 +2089,7 @@ static void find_compressor(char * compressor_name, int
> len, MOVTrack *track)
>|| (track->par->width == 1440 && track->par->height ==
> 1080)
>|| (track->par->width == 1920 && track->par->height ==
> 1080);
>
> -if (track->mode == MODE_MOV &&
> +if ((track->mode == MODE_AVIF || track->mode == MODE_MOV) &&
> (encoder = av_dict_get(track->st->metadata, "encoder", NULL, 0))) {
> av_strlcpy(compressor_name, encoder->value, 32);
> } else if (track->par->codec_id == AV_CODEC_ID_MPEG2VIDEO && xdcam_res) {
> @@ -2109,6 +2110,25 @@ static void find_compressor(char * compressor_name,
> int len, MOVTrack *track)
> }
> }
>
> +static int mov_write_ccst_tag(AVIOContext *pb)
> +{
> +int64_t pos = avio_tell(pb);
> +// Write sane defaults:
> +// all_ref_pics_intra = 0 : all samples can use any type of reference.
> +// intra_pred_used = 1 : intra prediction may or may not be used.
> +// max_ref_per_pic = 15 : reserved value to indicate that any number of
> +//reference ima
[FFmpeg-devel] [PATCH] doc: install css files along html docs
--- doc/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/Makefile b/doc/Makefile index 58ca3fabd8..0f09783699 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -27,6 +27,9 @@ HTMLPAGES = $(AVPROGS-yes:%=doc/%.html) $(AVPROGS-yes:%=doc/%-all.html) $(COMP doc/mailing-list-faq.html \ doc/nut.html \ doc/platform.html \ + doc/bootstrap.min.css \ + doc/style.min.css \ + doc/default.css \ TXTPAGES= doc/fate.txt \ -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] movenc: add write_btrt option
> On Apr 7, 2022, at 4:42 PM, Eran Kornblau wrote: > >> >> >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> "zhilizhao(???)" >> Sent: Wednesday, 6 April 2022 11:46 >> To: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] movenc: add write_btrt option >>> >>> supports forcing or disabling the writing of the btrt atom. >>> the default behavior is to write the atom only for mp4 mode. >>> --- >>> libavformat/movenc.c | 30 +++--- >>> libavformat/movenc.h | 1 + >>> 2 files changed, 20 insertions(+), 11 deletions(-) >>> >> >> I prefer to handle the auto mode (mov->write_btrt == -1) in a single place, >> so we don’t need to change multiple lines if the condition changed, e.g., >> enable btrt for MODE_MOV. Please correct me if I’m wrong, mov_init() has all >> of the contexts to overwrite mov->write_btrt. >> > Makes sense, thanks for the feedback! > Updated patch attached LGTM. > > Eran > <0001-movenc-add-write_btrt-option.patch>___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_colorkey: add >8 depth support
Signed-off-by: Paul B Mahol
---
libavfilter/vf_colorkey.c | 192 +-
1 file changed, 107 insertions(+), 85 deletions(-)
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 96e0f12878..b4f7c4a7c6 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -23,6 +23,7 @@
#include "libavutil/opt.h"
#include "libavutil/imgutils.h"
#include "avfilter.h"
+#include "drawutils.h"
#include "formats.h"
#include "internal.h"
#include "video.h"
@@ -31,105 +32,120 @@ typedef struct ColorkeyContext {
const AVClass *class;
/* color offsets rgba */
-int co[4];
+uint8_t co[4];
uint8_t colorkey_rgba[4];
float similarity;
float blend;
+double scale;
+int depth;
+int max;
int (*do_slice)(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs);
} ColorkeyContext;
-static uint8_t do_colorkey_pixel(ColorkeyContext *ctx, uint8_t r, uint8_t g,
uint8_t b)
+static int do_colorkey_pixel(const uint8_t *colorkey_rgba, int r, int g, int b,
+ float similarity, float blend, int max, double
scale)
{
-int dr = (int)r - ctx->colorkey_rgba[0];
-int dg = (int)g - ctx->colorkey_rgba[1];
-int db = (int)b - ctx->colorkey_rgba[2];
+double dr, dg, db, diff;
-double diff = sqrt((dr * dr + dg * dg + db * db) / (255.0 * 255.0 * 3.0));
+dr = r * scale - colorkey_rgba[0];
+dg = g * scale - colorkey_rgba[1];
+db = b * scale - colorkey_rgba[2];
-if (ctx->blend > 0.0001) {
-return av_clipd((diff - ctx->similarity) / ctx->blend, 0.0, 1.0) *
255.0;
+diff = sqrt((dr * dr + dg * dg + db * db) / (255.0 * 255.0 * 3.0));
+
+if (blend > 0.0001) {
+return av_clipd((diff - similarity) / blend, 0.0, 1.0) * max;
} else {
-return (diff > ctx->similarity) ? 255 : 0;
+return (diff > similarity) ? max : 0;
}
}
-static int do_colorkey_slice(AVFilterContext *avctx, void *arg, int jobnr, int
nb_jobs)
-{
-AVFrame *frame = arg;
-
-const int slice_start = (frame->height * jobnr) / nb_jobs;
-const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs;
-
-ColorkeyContext *ctx = avctx->priv;
-
-int o, x, y;
-
-for (y = slice_start; y < slice_end; ++y) {
-for (x = 0; x < frame->width; ++x) {
-o = frame->linesize[0] * y + x * 4;
-
-frame->data[0][o + ctx->co[3]] =
-do_colorkey_pixel(ctx,
- frame->data[0][o + ctx->co[0]],
- frame->data[0][o + ctx->co[1]],
- frame->data[0][o + ctx->co[2]]);
-}
-}
-
-return 0;
+#define COLORKEY_SLICE(name, type) \
+static int do_colorkey_slice##name(AVFilterContext *avctx, \
+ void *arg, \
+ int jobnr, int nb_jobs) \
+{ \
+AVFrame *frame = arg; \
+const int slice_start = (frame->height * jobnr) / nb_jobs; \
+const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs; \
+ColorkeyContext *ctx = avctx->priv;\
+const float similarity = ctx->similarity; \
+const float blend = ctx->blend;\
+const uint8_t *colorkey_rgba = ctx->colorkey_rgba; \
+const uint8_t *co = ctx->co; \
+const double scale = ctx->scale; \
+const int max = ctx->max; \
+ \
+for (int y = slice_start; y < slice_end; y++) {\
+type *dst = (type *)(frame->data[0] + y * frame->linesize[0]);\
+ \
+for (int x = 0; x < frame->width; x++) { \
+const int o = x * 4; \
+ \
+dst[o + co[3]] = do_colorkey_pixel(colorkey_rgba, \
+ dst[o + co[0]], \
+ dst[o + co[1]], \
+ dst[o + co[2]], \
+ similarity, blend, max, scale); \
+} \
+} \
+ \
+return 0; \
}
-static int do_colorhold_slice(AVFilterContext *avctx, void *arg, int jobnr
Re: [FFmpeg-devel] [PATCH] libavformat/mpegts.c: ignore a section with next flag
will apply
On 2022/04/03 19:23, TADANO Tokumei wrote:
'current_next_indicator' of 0 (next) on each section header indicates
the service information is for immediate future one.
ffmpeg doesn't need to parse it but current (1) one.
ref: section 5.1.1 of DVB BlueBook A038 (EN 300 468)
Signed-off-by: TADANO Tokumei
---
libavformat/mpegts.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index ecffb01562..49f7735123 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -645,6 +645,7 @@ typedef struct SectionHeader {
uint8_t tid;
uint16_t id;
uint8_t version;
+uint8_t current_next;
uint8_t sec_num;
uint8_t last_sec_num;
} SectionHeader;
@@ -773,6 +774,7 @@ static int parse_section_header(SectionHeader *h,
if (val < 0)
return val;
h->version = (val >> 1) & 0x1f;
+h->current_next = val & 0x01;
val = get8(pp, p_end);
if (val < 0)
return val;
@@ -2332,6 +2334,8 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
return;
if (h->tid != PMT_TID)
return;
+if (!h->current_next)
+return;
if (skip_identical(h, tssf))
return;
@@ -2541,6 +2545,8 @@ static void pat_cb(MpegTSFilter *filter, const uint8_t *section, int section_len
return;
if (h->tid != PAT_TID)
return;
+if (!h->current_next)
+return;
if (ts->skip_changes)
return;
@@ -2679,6 +2685,8 @@ static void sdt_cb(MpegTSFilter *filter, const uint8_t *section, int section_len
return;
if (h->tid != SDT_TID)
return;
+if (!h->current_next)
+return;
if (ts->skip_changes)
return;
if (skip_identical(h, tssf))
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mpegts.c: fix to check end of each descriptor of SDT
will apply
On 2022/04/03 19:07, TADANO Tokumei wrote:
Current code incorrectly check against end of section rather than
end of descriptor.
Signed-off-by: TADANO Tokumei
---
libavformat/mpegts.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index da77b50669..ecffb01562 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2718,13 +2718,13 @@ static void sdt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
switch (desc_tag) {
case 0x48:
-service_type = get8(&p, p_end);
+service_type = get8(&p, desc_end);
if (service_type < 0)
break;
-provider_name = getstr8(&p, p_end);
+provider_name = getstr8(&p, desc_end);
if (!provider_name)
break;
-name = getstr8(&p, p_end);
+name = getstr8(&p, desc_end);
if (name) {
AVProgram *program = av_new_program(ts->stream, sid);
if (program) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
Quoting Soft Works (2022-04-06 18:29:53) > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Wednesday, April 6, 2022 10:42 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > Quoting Soft Works (2022-04-05 23:05:57) > > > do I understand it right that there won't be a single-thread > > > operation mode that replicates/corresponds the current behavior? > > > > Correct, maintaining a single-threaded mode would require massive > > amounts of extra effort for questionable gain. > > The gain is not to be seen in having an alternate run-mode in > longer-term term perspective. It is about avoiding a single > point-of-no-return change which may have fundamental consequences > and impose debt on other developers when it would no longer be possible > to compare to the previous mode of operation. I don't understand where your apocalyptic language is coming from. Yes, overall this will be a very big change. But it will also be composed of many individual patches that can be understood on their own. And I am not a drive-by contributor, you can always just ask if something is unclear. Threads are not magic. It is ubiquitous well-understood technology that has been around for decades. Yes, they do involve their own challenges, but so does everything else, including the status quo. The current architecture of ffmpeg.c is, in my opinion, unsustainable. There is barely any separation of responsibilities. E.g. filtering code will modify muxer state, etc. It is very hard to understand the code behaviour in various scenarious (we have SO MANY options), and how will some code change affect it. This makes adding new major features much more painful than it should be. I am firmly convinced that these patches will make the code significantly easier to understand. > > If I understand correctly what you're suggesting then I don't believe > > this approach is feasible. The goal is not "add threading to improve > > performance", keeping everything else intact as much as possible. The > > goal is "improve architecture to make the code easier to > > understand/maintain/extend", threads are a means towards that goal. > > The > > fact that this should also improve throughput is more of a nice side > > effect than anything else. > > > > This patchset already changes behaviour in certain cases, making the > > output more predictable and consistent. Reordering it somehow to > > separate "semantically neutral" patches would require vast amounts of > > extra work. Note that progressing at all without obviously breaking > > anything is already quite hard --- I've been working on this since > > November and this is just the first step. I really do not want to make > > my work 10x harder for the vague benefit of maybe making some > > debugging > > slightly easier. > > I understand that, but I'm not talking about re-development. Let me try > explain it in a different way: > > What I mean is to go through your patches one after another but apply > only those parts that do not affect the current single-threaded execution > flow - effectively separating out those parts. Then, you go through > the remaining changes and make corresponding "similar" changes to the > working code, making it get as close as possible to your original code. > It's an iterative process. At the end you should have just a small set > of changes left which make up the difference between the working code > (still following the traditional flow) and the threaded execution flow. > That last set of differences can be finally applied in a way that it > can be activated/deactivated by an option. > > When you have been working on this for so long already, then this would > make up just a small part of the total work. Sorry, this does not seem a reasonable request to me. For one thing, the only advantage you claim involve highly hypothetical doomsday scenarios where you cannot compare to the old code and so ALL IS LOST. That smells like a cargo cult. The current code is not holy scripture determining how things should work for all eternity. It has bugs, inconsistencies, and poorly handled corner cases (some of which are fixed by this very patchset). Furthermore, remember that this is just the first step. There will be further patchsets converting the other components. I intend to upstream them gradually one after the other. Your suggestion would require me to instead write the whole thing at once, fighting rebase conflicts all the way, and then submit it as a giant utterly unreviewable patchset. That is a good recipe for never getting this finished. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subjec
Re: [FFmpeg-devel] [PATCH] avfilter/alimiter: Add "flush_buffer" option to flush the remaining valid data to the output
On Wed, Apr 6, 2022 at 1:49 PM Paul B Mahol wrote: > > > On Tue, Apr 5, 2022 at 8:57 PM Wang Cao > wrote: > >> On Mon, Apr 4, 2022 at 3:28 PM Marton Balint wrote: >> >> > >> > >> > On Mon, 4 Apr 2022, Paul B Mahol wrote: >> > >> > > On Sun, Mar 27, 2022 at 11:41 PM Marton Balint wrote: >> > > >> > >> >> > >> >> > >> On Sat, 26 Mar 2022, Wang Cao wrote: >> > >> >> > >>> The change in the commit will add some samples to the end of the >> audio >> > >>> stream. The intention is to add a "zero_delay" option eventually to >> not >> > >>> have the delay in the begining the output from alimiter due to >> > >>> lookahead. >> > >> >> > >> I was very much suprised to see that the alimiter filter actually >> delays >> > >> the audio - as in extra samples are inserted in the beginning and >> some >> > >> samples are cut in the end. This trashes A-V sync, so it is a bug >> IMHO. >> > >> >> > >> So unless somebody has some valid usecase for the legacy way of >> > operation >> > >> I'd just simply change it to be "zero delay" without any additional >> user >> > >> option, in a single patch. >> > >> >> > > >> > > >> > > This is done by this patch in very complicated way and also it really >> > > should be optional. >> > >> > But why does it make sense to keep the current (IMHO buggy) operational >> > mode which adds silence in the beginning and trims the end? I understand >> > that the original implementation worked like this, but libavfilter has >> > packet timestamps and N:M filtering so there is absolutely no reason to >> > use an 1:1 implementation and live with its limitations. >> > >> Hello Paul and Marton, thank you so much for taking time to review my >> patch. >> I totally understand that my patch may seem a little bit complicated but I >> can >> show with a FATE test that if we set the alimiter to behave as a >> passthrough filter, >> the output frames will be the same from "framecrc" with my patch. The >> existing >> behavior will not work for all gapless audio processing. >> >> The complete patch to fix this issue is at >> >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220330210314.2055201-1-wang...@google.com/ >> >> Regarding Paul's concern, I personally don't have any preference whether >> to >> put >> the patch as an extra option or not. With respect to the implementation, >> the patch >> is the best I can think of by preserving as much information as possible >> from input >> frames. I also understand it may break concept that "filter_frame" outputs >> one frame >> at a time. For alimiter with my patch, depending on the size of the >> lookahead buffer, >> it may take a few frames before one output frame can be generated. This is >> inevitable >> to compensate for the delay of the lookahead buffer. >> >> Thanks again for reviewing my patch and I'm looking forward to hearing >> from >> you :) >> > > Better than (because its no more 1 frame X nb_samples in, 1 frame X > nb_samples out) to replace .filter_frame/.request_frame with .activate > logic. > > And make this output delay compensation filtering optional. > > In this process make sure that output PTS frame timestamps are unchanged > from input one, by keeping reference of needed frames in filter queue. > > Look how speechnorm/dynaudnorm does it. > Alternatively, use current logic in ladspa filter, (also add option with same name). This would need less code, and probably better approach, as there is no extra latency introduced. Than mapping 1:1 between same number of samples per frame is not hold any more, but I think that is not much important any more. > > >> -- >> >> Wang Cao | Software Engineer | wang...@google.com | 650-203-7807 >> <(650)%20203-7807> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] qsvenc: fix typo
--- libavcodec/qsvenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index 2514d5b256..fbb22ca436 100644 --- a/libavcodec/qsvenc.c +++ b/libavcodec/qsvenc.c @@ -1003,7 +1003,7 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q) q->extco3.LowDelayBRC = q->low_delay_brc ? MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF; #endif #if QSV_VERSION_ATLEAST(1, 19) -if (q->max_frame_size_p >= 0) +if (q->max_frame_size_i >= 0) q->extco3.MaxFrameSizeI = q->max_frame_size_i; if (q->max_frame_size_p >= 0) q->extco3.MaxFrameSizeP = q->max_frame_size_p; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
