Re: [FFmpeg-devel] [PATCH 2/2] avformat: Do not search through the AVOption table for a option not in it repeatedly on each packet
On Sat, Mar 26, 2022 at 12:06:50AM +0100, Michael Niedermayer wrote: > This search takes alot of time especially when compared with small packets > > Signed-off-by: Michael Niedermayer > --- > libavformat/demux.c| 15 +-- > libavformat/internal.h | 5 + > 2 files changed, 14 insertions(+), 6 deletions(-) with amr-nb in 3gp this changes ./ffmpeg -i matrixbench_mpeg2.mpg -ar 8000 -ac 1 -acodec amr_nb -ab 4.75k -vn test.3gp ./ffmpeg -i test.3gp -f null - 46631 decicycles in read_frame_internal,8191 runs, 1 skips to 15719 decicycles in read_frame_internal,8188 runs, 4 skips [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ 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 2/2] avformat: Do not search through the AVOption table for a option not in it repeatedly on each packet
probably fine ___ 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] Suggestions on best way to add capture timestamp functionality over RTSP
Hi, I was looking for some advice on how to best add capture timestamp support to ffmpeg (namely RTP muxer) so that it would be accepted as a patch. I'll try to explain the rationale and what I see as an mvp and would like to get some feedback. Currently, a lot of live streaming stacks use rtmp onFI messages to signal capture timestamp mapping to pts, but with stuff like OPUS / AV1 / ... becoming more and more popular, using rtmp becomes harder since none of these codecs are supported in rtmp. Some vendors add extensions to rtmp to be able to ingest these codecs, but rtsp already has muxers for most of them, but it sadly lacks a good mechanism to send capture timestamps that would help to estimate a/v desync and end to end latency. So, there is this rtp header extension ( https://github.com/webrtc/webrtc-org/blob/gh-pages/experiments/rtp-hdrext/abs-capture-time/index.md) and I just found that ffmpeg now supports AV_PKT_DATA_S12M_TIMECODE side data, that would allow passing the capture time allthrough from the capture device to the muxer (which was the main obstacle why I did not evaluate this earlier). So, what I'd like to do and get that accepted is: 1) Add a feature to the rtpenc.c, controlled by a flag which would be off by default, which generates the abs-capture-time header if AV_PKT_DATA_S12M_TIMECODE is present. The spec says that one should not send the header on each packet which makes sense so I assume I need and on/off flag and a frequency parameter, or a single parameter which just does nothing if defaulted to -1 ? In this case, what would be a good unit of frequency of the header (since potentially this could be used with any kind of media) - milliseconds? Or maybe leave the frequency up to the caputre device? 2) Add a way to actually embed this sidedata into a captured stream. As far as I can see decklink is the only device which currently generates this kind of side data, but unfortunately only from the smpte coming from the source. I have access to some decklink cards, but I certainly am not able to set up a signal chain with embedded smpte. So I see a couple of options here: a) add a "wallclock" parameter to the decklink "timecode_format" option, which would generate the side data value from wallclock b) add a filter which just adds AV_PKT_DATA_S12M_TIMECODE data to any packet going through (possibly, with a configurable frequency). The latter of course suffers from the fact that all latencies up to the filter are lost, but then again it could be then combined with any type of input device. It would be great to get some feedback on this and understand what is a good patch functionality wise, that would actually get accepted. ___ 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 v4 1/2] lavc/vaapi_encode: add support for maxframesize
On Wed, 23. Mar 08:51, Wang, Fei W wrote:
> > -Original Message-
> > From: Wang, Fei W
> > Sent: Tuesday, March 22, 2022 10:11 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Linjie Fu ; Wang, Fei W
> > Subject: [PATCH v4 1/2] lavc/vaapi_encode: add support for maxframesize
> >
> > From: Linjie Fu
> >
> > Add support for max frame size:
> > - max_frame_size (bytes) to indicate the max allowed size for frame.
> >
> > If the frame size exceeds the limitation, encoder will to control the frame
> > size by
> > adjusting QP value.
> > - MFS_NUM_PASSES to indicate number of passes for QP adjust.
> > - MFS_DELTA_QP to indicate adjust qp value per pass.
> >
> > To simplify the usage, default QP adjust is set to delta_qp[4] = {1, 1, 1,
> > 1}.
> > Use new_qp for encoder if frame size exceeds the limitation:
> > new_qp = base_qp + delta_qp[0] + delta_qp[1] + ...
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > -c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4 \
> > -vframes 100 -y ./max_frame_size.h264
> >
> > Max frame size was enabled since VA-API version (1, 3, 0), but query is
> > available
> > since (1, 5, 0). It will be passed as a parameter in picParam and should be
> > set for
> > each frame.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > 1. re-send the 2 legacy patch:
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190715105936.4860-1-
> > linjie...@intel.com/
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/2019071511.5069-1-
> > linjie...@intel.com/
> >
> > libavcodec/vaapi_encode.c | 67
> > +++
> > libavcodec/vaapi_encode.h | 19 +--
> > 2 files changed, 84 insertions(+), 2 deletions(-)
Hi,
>
> Hi Andriy,
>
> Is there any way to know the details of failure for this patch? Like OS,
> configuration,
> gcc version, etc. It looks good on my local Ubuntu with gcc 9.3, but show
> fails in patchwork checks:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220322141119.595627-1-fei.w.w...@intel.com/
>
I don't think it was a real issue. I was upgrading the x86 runner at the time.
--
Andriy
___
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] [EXT] [PATCH v5 7/7] avcodec/v4l2_m2m_dec: setup capture queue before enqueue the first frame
Hi Ming, On Mon, 21. Mar 07:27, Ming Qian wrote: > Hi Andriy, > > What do you think of this patch? > > The Initialization flow defined in > linux/Documentation/userspace-api/media/v4l/dev-decoder.rst > 1. Set the coded format on OUTPUT via VIDIOC_S_FMT(). > 2. Allocate source (bytestream) buffers via VIDIOC_REQBUFS() on OUTPUT. > 3. Start streaming on the OUTPUT queue via VIDIOC_STREAMON(). > 4. This step only applies to coded formats that contain resolution > information in the stream. Continue queuing/dequeuing bytestream buffers > to/from the OUTPUT queue via VIDIOC_QBUF() and VIDIOC_DQBUF(). The buffers > will be processed and returned to the client in order, until required > metadata to configure the CAPTURE queue are found. This is indicated by the > decoder sending a V4L2_EVENT_SOURCE_CHANGE event with changes set to > V4L2_EVENT_SRC_CH_RESOLUTION. > Note: A client capable of acquiring stream parameters from the > bytestream on its own may attempt to set the width and height of the OUTPUT > format to non-zero values matching the coded size of the stream, skip this > step and continue with the Capture Setup sequence. > > 5. Continue with the Capture Setup sequence. > > In ffmpeg's implementation, ffmpeg will set non-zero width and height on > output queue, so the step 4 should be skipped, and setup the capture queue > directly. > So the flow should be: > 1. Set the coded format and valid resolution on OUTPUT via VIDIOC_S_FMT(). > 2. Allocate source (bytestream) buffers via VIDIOC_REQBUFS() on OUTPUT. > 3. Start streaming on the OUTPUT queue via VIDIOC_STREAMON(). > 5. Continue with the Capture Setup sequence. > > And this patch is just following the above flow. > > Ming The v4 version didn't work for me on odroid xu4 http://ffmpeg.org/pipermail/ffmpeg-devel/2022-January/290679.html I haven't had time retest but don't think anything has changed. -- Andriy ___ 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] test: tiny_ssim: Don't include config.h
tiny_ssim is built for the build host, not for the target platform. Therefore, it mustn't include the config.h header, which is set up specifically for the target platform and compiler. This fixes cross building for older WinStore platforms, where config.h contains "#define getenv(x) NULL". Signed-off-by: Martin Storsjö --- tests/tiny_ssim.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/tiny_ssim.c b/tests/tiny_ssim.c index 08f8e92a03..9740652288 100644 --- a/tests/tiny_ssim.c +++ b/tests/tiny_ssim.c @@ -27,7 +27,6 @@ * overlapped 8x8 block sums, rather than the original gaussian weights. */ -#include "config.h" #include #include #include -- 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] web/consulting: add myself
On Thu, Mar 24, 2022 at 03:53:56PM +0100, Tomas Härdin wrote: > > consulting | 12 > 1 file changed, 12 insertions(+) > 901f8f38d654798a4fcb579ac2e50c0a443f5843 0001-web-consulting-add-myself.patch > From 446777e4333726cb05843ff16ac76e9eb83a5e57 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Sun, 2 Jan 2022 15:47:30 +0100 > Subject: [PATCH] web/consulting: add myself > > --- > src/consulting | 12 > 1 file changed, 12 insertions(+) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ 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] web/consulting: add myself
On Thu, Mar 24, 2022 at 03:53:56PM +0100, Tomas Härdin wrote: > > consulting | 12 > 1 file changed, 12 insertions(+) > 901f8f38d654798a4fcb579ac2e50c0a443f5843 0001-web-consulting-add-myself.patch > From 446777e4333726cb05843ff16ac76e9eb83a5e57 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Sun, 2 Jan 2022 15:47:30 +0100 > Subject: [PATCH] web/consulting: add myself > > --- > src/consulting | 12 > 1 file changed, 12 insertions(+) > > diff --git a/src/consulting b/src/consulting > index 01e4995..96a5b28 100644 > --- a/src/consulting > +++ b/src/consulting > @@ -106,6 +106,18 @@ E.g.: > > > > + > + > + Tomas Härdin > + > +Tomas is located in Umeå, Sweden. > +He has worked on FFmpeg since 2009 and has been a maintainer since > 2010. > +He has expertise in broadcast formats, mainly MXF and AAF, and is > also available for general FFmpeg work. > +For more information on Tomas' areas of expertise see href="https://www.haerdin.se/pages/consulting.html";>the consulting page on > his website. > +You can contact him by email at href="mailto:consult...@haerdin.se";>consult...@haerdin.se or by XMPP at > t...@haerdin.se. > + > + > + > > >Steven Liu I applied this not realizing it messes the "table" style up a bit maybe you can fix this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ 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] web/consulting: add myself
On 2022-03-27 05:15 am, Michael Niedermayer wrote: On Thu, Mar 24, 2022 at 03:53:56PM +0100, Tomas Härdin wrote: consulting | 12 1 file changed, 12 insertions(+) 901f8f38d654798a4fcb579ac2e50c0a443f5843 0001-web-consulting-add-myself.patch From 446777e4333726cb05843ff16ac76e9eb83a5e57 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Sun, 2 Jan 2022 15:47:30 +0100 Subject: [PATCH] web/consulting: add myself --- src/consulting | 12 1 file changed, 12 insertions(+) diff --git a/src/consulting b/src/consulting index 01e4995..96a5b28 100644 --- a/src/consulting +++ b/src/consulting @@ -106,6 +106,18 @@ E.g.: + + + Tomas Härdin + +Tomas is located in Umeå, Sweden. +He has worked on FFmpeg since 2009 and has been a maintainer since 2010. +He has expertise in broadcast formats, mainly MXF and AAF, and is also available for general FFmpeg work. +For more information on Tomas' areas of expertise see https://www.haerdin.se/pages/consulting.html";>the consulting page on his website. +You can contact him by email at mailto:consult...@haerdin.se";>consult...@haerdin.se or by XMPP at t...@haerdin.se. + + + Steven Liu I applied this not realizing it messes the "table" style up a bit maybe you can fix this Done. Regards, Gyan ___ 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/alimiter: Add "flush_buffer" option to flush the remaining valid data to the output
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.
Signed-off-by: Wang Cao
---
doc/filters.texi | 5
libavfilter/af_alimiter.c | 57 ---
2 files changed, 53 insertions(+), 9 deletions(-)
If the intention is clear to you, do you prefer us add the "zero_delay"
option to the same patch or it needs to go in a separate patch? Thanks!
diff --git a/doc/filters.texi b/doc/filters.texi
index d70ac3e237..bb8f7c1a0b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1978,6 +1978,11 @@ in release time while 1 produces higher release times.
@item level
Auto level output signal. Default is enabled.
This normalizes audio back to 0dB if enabled.
+
+@item flush_buffer
+Flushes the internal buffer so that all the input audio samples to the limiter
+will appear to the output. Currently due to lookahead buffer, the total number
+of output samples will be larger than the input.
@end table
Depending on picked setting it is recommended to upsample input 2x or 4x times
diff --git a/libavfilter/af_alimiter.c b/libavfilter/af_alimiter.c
index 133f98f165..ba0a1361ac 100644
--- a/libavfilter/af_alimiter.c
+++ b/libavfilter/af_alimiter.c
@@ -55,6 +55,9 @@ typedef struct AudioLimiterContext {
int *nextpos;
double *nextdelta;
+int flush_buffer;
+int total_samples_to_flush;
+
double delta;
int nextiter;
int nextlen;
@@ -65,14 +68,15 @@ typedef struct AudioLimiterContext {
#define AF AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_FILTERING_PARAM |
AV_OPT_FLAG_RUNTIME_PARAM
static const AVOption alimiter_options[] = {
-{ "level_in", "set input level", OFFSET(level_in),
AV_OPT_TYPE_DOUBLE, {.dbl=1},.015625, 64, AF },
-{ "level_out", "set output level", OFFSET(level_out),
AV_OPT_TYPE_DOUBLE, {.dbl=1},.015625, 64, AF },
-{ "limit", "set limit",OFFSET(limit),
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0.0625,1, AF },
-{ "attack","set attack", OFFSET(attack),
AV_OPT_TYPE_DOUBLE, {.dbl=5},0.1, 80, AF },
-{ "release", "set release", OFFSET(release),
AV_OPT_TYPE_DOUBLE, {.dbl=50}, 1, 8000, AF },
-{ "asc", "enable asc", OFFSET(auto_release), AV_OPT_TYPE_BOOL,
{.i64=0}, 0,1, AF },
-{ "asc_level", "set asc level",OFFSET(asc_coeff),
AV_OPT_TYPE_DOUBLE, {.dbl=0.5},0,1, AF },
-{ "level", "auto level", OFFSET(auto_level), AV_OPT_TYPE_BOOL,
{.i64=1}, 0,1, AF },
+{ "level_in", "set input level",
OFFSET(level_in), AV_OPT_TYPE_DOUBLE, {.dbl=1},.015625, 64, AF },
+{ "level_out", "set output level",
OFFSET(level_out),AV_OPT_TYPE_DOUBLE, {.dbl=1},.015625, 64, AF },
+{ "limit", "set limit",
OFFSET(limit),AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0.0625,1, AF },
+{ "attack","set attack",
OFFSET(attack), AV_OPT_TYPE_DOUBLE, {.dbl=5},0.1, 80, AF },
+{ "release", "set release",
OFFSET(release), AV_OPT_TYPE_DOUBLE, {.dbl=50}, 1, 8000, AF },
+{ "asc", "enable asc",
OFFSET(auto_release), AV_OPT_TYPE_BOOL, {.i64=0}, 0,1, AF },
+{ "asc_level", "set asc level",
OFFSET(asc_coeff),AV_OPT_TYPE_DOUBLE, {.dbl=0.5},0,1, AF },
+{ "level", "auto level",
OFFSET(auto_level), AV_OPT_TYPE_BOOL, {.i64=1}, 0,1, AF },
+{ "flush_buffer","flush the samples in the lookahead buffer",
OFFSET(flush_buffer), AV_OPT_TYPE_BOOL, {.i64=0}, 0,1, AF },
{ NULL }
};
@@ -275,6 +279,39 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
return ff_filter_frame(outlink, out);
}
+
+static int request_frame(AVFilterLink* outlink) {
+ AVFilterContext* ctx = outlink->src;
+ AudioLimiterContext* s = (AudioLimiterContext*)ctx->priv;
+ int ret;
+ AVFilterLink *inlink;
+ AVFrame *silence_frame;
+
+ ret = ff_request_frame(ctx->inputs[0]);
+
+ if (!s->flush_buffer) {
+ return 0;
+ }
+
+ if (ret != AVERROR_EOF || s->total_samples_to_flush) {
+// Not necessarily an error, just not EOF.s
+return ret;
+ }
+
+ // We reach here when input filters have finished producing data (i.e. EOF),
+ // but because of the attac param, s->buffer still has meaningful
+ // audio content that needs flushing. The amount of remaining audio to flush
+ // is the same as the amount of lookahead that was trimmed from the
beginning.
+ inlink = ctx->inputs[0];
+ // Pushes silence frame to flush valid audio in the s->buffer
+ silence_frame = ff_get_audio_buffer(inlink, s
