[FFmpeg-devel] [PATCH] web/generate-doc.sh: fix generate-doc warning for configure ffmpeg part
Signed-off-by: Steven Liu --- generate-doc.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/generate-doc.sh b/generate-doc.sh index d8d01d3..e316c05 100755 --- a/generate-doc.sh +++ b/generate-doc.sh @@ -34,7 +34,7 @@ export FA_ICONS=true rm -rf build-doc mkdir build-doc && cd build-doc -$src/configure --enable-gpl --disable-yasm || die "configure failed" +$src/configure --enable-gpl --enable-x86asm || die "configure failed" make doc || die "doc not made" cp doc/*.html ../htdocs/ || die "copy failed" -- 2.25.0 ___ 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] doc/muxers: add missing MOV muxer options
On 13-03-2020 12:08 am, Lou Logan wrote: Signed-off-by: Lou Logan --- The options for this muxer have a separate section about fragmenting. I tried to organize the missing options into the proper sections, but I don't use fragmenting so I may have placed them in the wrong section. I already started on this after I added the MOV demuxer options. But this is a good start. I'll probably want to expand descriptions later on. Will have a look and push this weekend. 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".
Re: [FFmpeg-devel] [PATCH] lavc/v4l2_m2m_dec: Init reserved bytes to zero before ioctl call
On Sun, 08. Mar 11:49, Andriy Gelman wrote:
> From: Andriy Gelman
>
> struct v4l2_selection contains reserved bytes which should be set to
> zero before the ioctl call.
>
> Fixes valgrind error:
> Syscall param ioctl(VKI_V4L2_S_SELECTION) points to uninitialised byte(s)
>
> Signed-off-by: Andriy Gelman
> ---
> libavcodec/v4l2_m2m_dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index d666edffe46..c5ee86b9935 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -39,7 +39,7 @@ static int v4l2_try_start(AVCodecContext *avctx)
> V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
> V4L2Context *const capture = &s->capture;
> V4L2Context *const output = &s->output;
> -struct v4l2_selection selection;
> +struct v4l2_selection selection = { 0 };
> int ret;
>
> /* 1. start the output process */
> --
> 2.25.0
>
ping
--
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 v3 7/7] avformat/audiointerleave: use a fixed frame duration for non-audio packets
The packet durations might not be set properly which can cause the MXF muxer
to write more than one packet of a stream to an edit unit messing up the
constant byte per element index...
Also warn the user if the incoming DTS is not increasing by frame duration
because in that case A-V sync issues can occur because of the DTS rewriting.
Also use nb_samples directly to calculate dts of audio packets because adding
packet durations might not be precise.
Signed-off-by: Marton Balint
---
libavformat/audiointerleave.c | 21 ++---
libavformat/audiointerleave.h | 4 +++-
libavformat/gxfenc.c | 2 +-
libavformat/mxfenc.c | 2 +-
4 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
index 2e83031bd6..a235a4456a 100644
--- a/libavformat/audiointerleave.c
+++ b/libavformat/audiointerleave.c
@@ -40,6 +40,7 @@ void ff_audio_interleave_close(AVFormatContext *s)
int ff_audio_interleave_init(AVFormatContext *s,
const int samples_per_frame,
+ const int frame_duration,
AVRational time_base)
{
int i;
@@ -48,10 +49,15 @@ int ff_audio_interleave_init(AVFormatContext *s,
av_log(s, AV_LOG_ERROR, "timebase not set for audio interleave\n");
return AVERROR(EINVAL);
}
+if (!frame_duration) {
+av_log(s, AV_LOG_ERROR, "frame_duration not set for audio
interleave\n");
+return AVERROR(EINVAL);
+}
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
AudioInterleaveContext *aic = st->priv_data;
+aic->start_dts = AV_NOPTS_VALUE;
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
int max_samples = samples_per_frame ? samples_per_frame :
av_rescale_rnd(st->codecpar->sample_rate,
time_base.num, time_base.den, AV_ROUND_UP);
@@ -67,6 +73,8 @@ int ff_audio_interleave_init(AVFormatContext *s,
if (!(aic->fifo = av_fifo_alloc_array(100, max_samples)))
return AVERROR(ENOMEM);
aic->fifo_size = 100 * max_samples;
+} else {
+aic->frame_duration = frame_duration;
}
}
@@ -94,10 +102,9 @@ static int interleave_new_audio_packet(AVFormatContext *s,
AVPacket *pkt,
if (size < pkt->size)
memset(pkt->data + size, 0, pkt->size - size);
-pkt->dts = pkt->pts = aic->dts;
+pkt->dts = pkt->pts = av_rescale_q(aic->nb_samples, st->time_base,
aic->time_base);
pkt->duration = av_rescale_q(nb_samples, st->time_base, aic->time_base);
pkt->stream_index = stream_index;
-aic->dts += pkt->duration;
aic->nb_samples += nb_samples;
aic->n++;
@@ -122,9 +129,17 @@ int ff_audio_rechunk_interleave(AVFormatContext *s,
AVPacket *out, AVPacket *pkt
}
av_fifo_generic_write(aic->fifo, pkt->data, pkt->size, NULL);
} else {
+if (aic->start_dts == AV_NOPTS_VALUE)
+aic->start_dts = pkt->dts;
+if (pkt->dts != aic->dts + aic->start_dts) {
+av_log(s, AV_LOG_WARNING, "Non-linear DTS in stream %d: got
%"PRId64" instead of %"PRId64","
+ "this can cause sync issues.\n", pkt->stream_index,
pkt->dts, aic->dts + aic->start_dts);
+aic->start_dts = pkt->dts - aic->dts;
+}
+
// rewrite pts and dts to be decoded time line position
pkt->pts = pkt->dts = aic->dts;
-aic->dts += pkt->duration;
+aic->dts += aic->frame_duration;
if ((ret = ff_interleave_add_packet(s, pkt, compare_ts)) < 0)
return ret;
}
diff --git a/libavformat/audiointerleave.h b/libavformat/audiointerleave.h
index 0933310f4c..3ec4ed503a 100644
--- a/libavformat/audiointerleave.h
+++ b/libavformat/audiointerleave.h
@@ -31,13 +31,15 @@ typedef struct AudioInterleaveContext {
unsigned fifo_size; ///< size of currently allocated FIFO
int64_t n;///< number of generated packets
int64_t nb_samples; ///< number of generated samples
+int64_t start_dts;///< start dts of a non-audio source stream
uint64_t dts; ///< current dts
int sample_size; ///< size of one sample all channels included
int samples_per_frame;///< samples per frame if fixed, 0 otherwise
+int frame_duration; ///< frame duration for non-audio data
AVRational time_base; ///< time base of output audio packets
} AudioInterleaveContext;
-int ff_audio_interleave_init(AVFormatContext *s, const int samples_per_frame,
AVRational time_base);
+int ff_audio_interleave_init(AVFormatContext *s, const int samples_per_frame,
const int frame_duration, AVRational time_base);
void ff_audio_interleave_close(AVFormatContext *s);
/**
diff --
Re: [FFmpeg-devel] [PATCH] doc/muxers: add missing MOV muxer options
On Thu, Mar 12, 2020 at 10:38:37AM -0800, Lou Logan wrote: > Signed-off-by: Lou Logan > --- > The options for this muxer have a separate section about fragmenting. > I tried to organize the missing options into the proper sections, but > I don't use fragmenting so I may have placed them in the wrong section. > --- > doc/muxers.texi | 116 +++- > 1 file changed, 95 insertions(+), 21 deletions(-) didnt review but just wanted to say thanks, missing options in our docs seems not to receive as much attention as they should thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus 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".
[FFmpeg-devel] [PATCH 2/4] avisynth: switch to AviSynth+ on Linux
AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete. Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth+.
As a result, the USING_AVISYNTH defines can be switched back
to generic _WIN32.
---
libavformat/avisynth.c | 56 +++---
1 file changed, 15 insertions(+), 41 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 55a2efd884..43b65badc9 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -1,5 +1,5 @@
/*
- * AviSynth/AvxSynth support
+ * AviSynth(+) support
* Copyright (c) 2012 AvxSynth Team
*
* This file is part of FFmpeg
@@ -31,20 +31,19 @@
/* Enable function pointer definitions for runtime loading. */
#define AVSC_NO_DECLSPEC
-/* Platform-specific directives for AviSynth vs AvxSynth. */
+/* Platform-specific directives. */
#ifdef _WIN32
#include "compat/w32dlfcn.h"
#undef EXTERN_C
- #include "compat/avisynth/avisynth_c.h"
#define AVISYNTH_LIB "avisynth"
- #define USING_AVISYNTH
#else
#include
- #include "compat/avisynth/avxsynth_c.h"
- #define AVISYNTH_NAME "libavxsynth"
+ #define AVISYNTH_NAME "libavisynth"
#define AVISYNTH_LIB AVISYNTH_NAME SLIBSUF
#endif
+#include
+
typedef struct AviSynthLibrary {
void *library;
#define AVSC_DECLARE_FUNC(name) name ## _func name
@@ -62,7 +61,6 @@ typedef struct AviSynthLibrary {
AVSC_DECLARE_FUNC(avs_release_value);
AVSC_DECLARE_FUNC(avs_release_video_frame);
AVSC_DECLARE_FUNC(avs_take_clip);
-#ifdef USING_AVISYNTH
AVSC_DECLARE_FUNC(avs_bits_per_pixel);
AVSC_DECLARE_FUNC(avs_get_height_p);
AVSC_DECLARE_FUNC(avs_get_pitch_p);
@@ -70,7 +68,6 @@ typedef struct AviSynthLibrary {
AVSC_DECLARE_FUNC(avs_get_row_size_p);
AVSC_DECLARE_FUNC(avs_is_planar_rgb);
AVSC_DECLARE_FUNC(avs_is_planar_rgba);
-#endif
#undef AVSC_DECLARE_FUNC
} AviSynthLibrary;
@@ -97,14 +94,12 @@ static const int avs_planes_packed[1] = { 0 };
static const int avs_planes_grey[1] = { AVS_PLANAR_Y };
static const int avs_planes_yuv[3]= { AVS_PLANAR_Y, AVS_PLANAR_U,
AVS_PLANAR_V };
-#ifdef USING_AVISYNTH
static const int avs_planes_rgb[3]= { AVS_PLANAR_G, AVS_PLANAR_B,
AVS_PLANAR_R };
static const int avs_planes_yuva[4] = { AVS_PLANAR_Y, AVS_PLANAR_U,
AVS_PLANAR_V, AVS_PLANAR_A };
static const int avs_planes_rgba[4] = { AVS_PLANAR_G, AVS_PLANAR_B,
AVS_PLANAR_R, AVS_PLANAR_A };
-#endif
/* A conflict between C++ global objects, atexit, and dynamic loading requires
* us to register our own atexit handler to prevent double freeing. */
@@ -142,7 +137,6 @@ static av_cold int avisynth_load_library(void)
LOAD_AVS_FUNC(avs_release_value, 0);
LOAD_AVS_FUNC(avs_release_video_frame, 0);
LOAD_AVS_FUNC(avs_take_clip, 0);
-#ifdef USING_AVISYNTH
LOAD_AVS_FUNC(avs_bits_per_pixel, 1);
LOAD_AVS_FUNC(avs_get_height_p, 1);
LOAD_AVS_FUNC(avs_get_pitch_p, 1);
@@ -150,7 +144,6 @@ static av_cold int avisynth_load_library(void)
LOAD_AVS_FUNC(avs_get_row_size_p, 1);
LOAD_AVS_FUNC(avs_is_planar_rgb, 1);
LOAD_AVS_FUNC(avs_is_planar_rgba, 1);
-#endif
#undef LOAD_AVS_FUNC
atexit(avisynth_atexit_handler);
@@ -249,7 +242,6 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator,
avs->vi->fps_numerator);
switch (avs->vi->pixel_type) {
-#ifdef USING_AVISYNTH
/* 10~16-bit YUV pix_fmts (AviSynth+) */
case AVS_CS_YUV444P10:
st->codecpar->format = AV_PIX_FMT_YUV444P10;
@@ -434,8 +426,7 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
case AVS_CS_BGR64:
st->codecpar->format = AV_PIX_FMT_BGRA64;
break;
-#endif
-/* AviSynth 2.5 and AvxSynth pix_fmts */
+/* AviSynth 2.5 pix_fmts */
case AVS_CS_BGR24:
st->codecpar->format = AV_PIX_FMT_BGR24;
break;
@@ -461,7 +452,6 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
}
switch (planar) {
-#ifdef USING_AVISYNTH
case 5: // Planar RGB + Alpha
avs->n_planes = 4;
avs->planes = avs_planes_rgba;
@@ -474,7 +464,6 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
avs->n_planes = 3;
avs->planes = avs_planes_rgb;
break;
-#endif
case 2: // Y8
avs->n_planes = 1;
avs->planes = avs_planes_grey;
@@ -556,7 +545,7 @@ static int avisynth_open_file(AVFormatContext *s)
AviSynthContext *avs = s->priv_data;
AVS_Value arg, val;
int ret;
-#ifdef USING_AVISYNTH
+#ifdef _WIN32
char filename_ansi[MAX_PATH * 4];
wchar_t filename_wc[MAX_PATH * 4];
#endif
@@ -564,7 +
[FFmpeg-devel] [PATCH]lavf/tty: Reduce probe score and fix ffmetadata auto-detection
Hi! Attached patch fixes ticket #8568 for me. Please comment, Carl Eugen From f89862eebf6814567ea8a2d0a7a7c138607dcc01 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Fri, 13 Mar 2020 00:53:16 +0100 Subject: [PATCH] lavf/tty: Reduce probe score and fix ffmetadata auto-detection. Fixes ticket #8568. --- libavformat/tty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/tty.c b/libavformat/tty.c index 56438d5f1c..aed5c888c3 100644 --- a/libavformat/tty.c +++ b/libavformat/tty.c @@ -65,7 +65,7 @@ static int read_probe(const AVProbeData *p) for (int i = 8; i < p->buf_size; i++) cnt += !!isansicode(p->buf[i]); -return (cnt * 100LL / p->buf_size) * (cnt > 400) * +return (cnt * 99LL / p->buf_size) * (cnt > 400) * !!av_match_ext(p->filename, tty_extensions); } -- 2.24.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".
[FFmpeg-devel] [PATCH 1/4] compat: remove avisynth headers
---
compat/avisynth/avisynth_c.h | 1264 -
compat/avisynth/avs/capi.h| 94 --
compat/avisynth/avs/config.h | 70 -
compat/avisynth/avs/types.h | 57 -
compat/avisynth/avxsynth_c.h | 728 --
.../windowsPorts/basicDataTypeConversions.h | 85 --
compat/avisynth/windowsPorts/windows2linux.h | 77 -
configure |1 +
tests/ref/fate/source |9 -
9 files changed, 1 insertion(+), 2384 deletions(-)
delete mode 100644 compat/avisynth/avisynth_c.h
delete mode 100644 compat/avisynth/avs/capi.h
delete mode 100644 compat/avisynth/avs/config.h
delete mode 100644 compat/avisynth/avs/types.h
delete mode 100644 compat/avisynth/avxsynth_c.h
delete mode 100644 compat/avisynth/windowsPorts/basicDataTypeConversions.h
delete mode 100644 compat/avisynth/windowsPorts/windows2linux.h
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
deleted file mode 100644
index 9ff9321552..00
--- a/compat/avisynth/avisynth_c.h
+++ /dev/null
@@ -1,1264 +0,0 @@
-// Avisynth C Interface Version 0.20
-// Copyright 2003 Kevin Atkinson
-
-// This program is free software; you can redistribute it and/or modify
-// it under the terms of the GNU General Public License as published by
-// the Free Software Foundation; either version 2 of the License, or
-// (at your option) any later version.
-//
-// This program 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 General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, write to the Free Software
-// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
-// MA 02110-1301 USA, or visit
-// http://www.gnu.org/copyleft/gpl.html .
-//
-// As a special exception, I give you permission to link to the
-// Avisynth C interface with independent modules that communicate with
-// the Avisynth C interface solely through the interfaces defined in
-// avisynth_c.h, regardless of the license terms of these independent
-// modules, and to copy and distribute the resulting combined work
-// under terms of your choice, provided that every copy of the
-// combined work is accompanied by a complete copy of the source code
-// of the Avisynth C interface and Avisynth itself (with the version
-// used to produce the combined work), being distributed under the
-// terms of the GNU General Public License plus this exception. An
-// independent module is a module which is not derived from or based
-// on Avisynth C Interface, such as 3rd-party filters, import and
-// export plugins, or graphical user interfaces.
-
-// NOTE: this is a partial update of the Avisynth C interface to recognize
-// new color spaces added in Avisynth 2.60. By no means is this document
-// completely Avisynth 2.60 compliant.
-// 170103: added new CPU constants (FMA4, AVX512xx)
-// 171102: define SIZETMOD. do not use yet, experimental. Offsets are size_t
instead of int. Affects x64.
-// 171106: avs_get_row_size calls into avs_get_row_size_p, instead of direct
field access
-// 171106: avs_get_height calls into avs_get_row_size_p, instead of direct
field access
-// 180524: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
-// 180524: avs_is_same_colorspace VideoInfo parameters to const
-// 181230: Readability: functions regrouped to mix less AVSC_API and
AVSC_INLINE, put together Avisynth+ specific stuff
-// 181230: use #ifndef AVSC_NO_DECLSPEC for AVSC_INLINE functions which are
calling API functions
-// 181230: comments on avs_load_library (helper for loading API entries
dynamically into a struct using AVSC_NO_DECLSPEC define)
-// 181230: define alias AVS_FRAME_ALIGN as FRAME_ALIGN
-// 181230: remove unused form of avs_get_rowsize and avs_get_height (kept
earlier for reference)
-// 190104: avs_load_library: smart fallback mechanism for Avisynth+ specific
functions:
-// if they are not loadable, they will work in a classic Avisynth
compatible mode
-// Example#1: e.g. avs_is_444 will call the existing avs_is_yv24
instead
-// Example#2: avs_bits_per_component will return 8 for all colorspaces
(Classic Avisynth supports only 8 bits/pixel)
-// Thus the Avisynth+ specific API functions are safely callable even
when connected to classic Avisynth DLL
-
-#ifndef __AVISYNTH_C__
-#define __AVISYNTH_C__
-
-#include "avs/config.h"
-#include "avs/capi.h"
-#include "avs/types.h"
-
-#define AVS_FRAME_ALIGN FRAME_ALIGN
-/
-//
-// Constants
-//
-
-#ifndef __AVISYNTH_6_H__
-enum { AVISYNTH_INTERFACE_VERSION = 6 };
-#endif
-
-enum {AVS_SAMPLE_INT8 = 1<<0,
- AVS_SAMPLE_INT16 = 1<<1,
-
[FFmpeg-devel] [PATCH 3/4] doc/general.texi: AviSynth+ works on Linux now, AvxSynth is gone.
Related to this are the following changes:
* Mention the GNUmakefile that AviSynth+ provides for installing
just the headers.
* Expand on users installing AviSynth on their system a little
more.
---
doc/general.texi | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/doc/general.texi b/doc/general.texi
index 3684847ac1..ceea4210f3 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -50,16 +50,17 @@ This driver can be installed using amdgpu-pro-install
script in official amd dri
@section AviSynth
FFmpeg can read AviSynth scripts as input. To enable support, pass
-@code{--enable-avisynth} to configure. The correct headers are
-included in compat/avisynth/, which allows the user to enable support
-without needing to search for these headers themselves.
+@code{--enable-avisynth} to configure after installing the headers
+provided by @url{https://github.com/AviSynth/AviSynthPlus, AviSynth+}.
+AviSynth+ supplies a @code{GNUmakefile} to install only the headers,
+as CMake does not make header-only installs an easy task.
For Windows, supported AviSynth variants are
@url{http://avisynth.nl, AviSynth 2.6 RC1 or higher} for 32-bit builds and
@url{http://avisynth.nl/index.php/AviSynth+, AviSynth+ r1718 or higher} for
32-bit and 64-bit builds.
-For Linux and OS X, the supported AviSynth variant is
-@url{https://github.com/avxsynth/avxsynth, AvxSynth}.
+For Linux, macOS, and BSD, the only supported AviSynth variant is
+@url{https://github.com/AviSynth/AviSynthPlus, AviSynth+}, starting with
version 3.5.
@float NOTE
In 2016, AviSynth+ added support for building with GCC. However, due to
@@ -77,10 +78,11 @@ GCC builds of AviSynth+ without any special flags.
@end float
@float NOTE
-AviSynth and AvxSynth are loaded dynamically. Distributors can build FFmpeg
-with @code{--enable-avisynth}, and the binaries will work regardless of the
-end user having AviSynth or AvxSynth installed - they'll only need to be
-installed to use AviSynth scripts (obviously).
+AviSynth(+) is loaded dynamically. Distributors can build FFmpeg
+with @code{--enable-avisynth}, and the binaries will work regardless
+of the end user having AviSynth installed. If/when an end user
+would like to use AviSynth scripts, then they can install AviSynth(+)
+and FFmpeg will be able to find and use it to open scripts.
@end float
@section Chromaprint
--
2.20.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".
[FFmpeg-devel] [PATCH 4/4] avisynth: fix deprecation warning
---
libavformat/avisynth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 43b65badc9..2c08ace8db 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -555,12 +555,12 @@ static int avisynth_open_file(AVFormatContext *s)
#ifdef _WIN32
/* Convert UTF-8 to ANSI code page */
-MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, MAX_PATH *
4);
+MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH * 4);
WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, filename_ansi,
MAX_PATH * 4, NULL, NULL);
arg = avs_new_value_string(filename_ansi);
#else
-arg = avs_new_value_string(s->filename);
+arg = avs_new_value_string(s->url);
#endif
val = avs_library.avs_invoke(avs->env, "Import", arg, 0);
if (avs_is_error(val)) {
--
2.20.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 1/5] compat/avisynth: update headers
On 3/12/20 4:46 AM, Marton Balint wrote: Is it still required to include the headers in our source tree? AVISynth was frowned upon in the past beacuse generally we do not allow headers of external libraries in our tree. If there is a way to completely remove the headers and keep the feature buildable with reasonable amount of work then I suggest we should do that. I had a feeling this would get brought up, which is why I did make sure the necessary changes occurred in AviSynth+ upstream so that FFmpeg could use the system headers. I'll send the revised patches as a reply to this message. ___ 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][GSOC] avfilter: add fluidsynth filter
This patch is part of the qualification task for Audio Tones Source Filter.
---
Changelog | 1 +
configure | 4 +
doc/filters.texi | 26 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/asrc_fluidsynth.c | 177 ++
libavfilter/version.h | 2 +-
7 files changed, 211 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/asrc_fluidsynth.c
diff --git a/Changelog b/Changelog
index db2ca92e8a..2a22599969 100644
--- a/Changelog
+++ b/Changelog
@@ -46,6 +46,7 @@ version :
- High Voltage Software ADPCM decoder
- LEGO Racers ALP (.tun & .pcm) demuxer
- AMQP 0-9-1 protocol (RabbitMQ)
+- fluidsynth filter
version 4.2:
diff --git a/configure b/configure
index 8b17134944..b22a09fac1 100755
--- a/configure
+++ b/configure
@@ -233,6 +233,7 @@ External library support:
and libraw1394 [no]
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
--enable-libfliteenable flite (voice synthesis) support via libflite
[no]
+ --enable-libfluidsynth enable fluidsynth support via libfluidsynth [no]
--enable-libfontconfig enable libfontconfig, useful for drawtext filter
[no]
--enable-libfreetype enable libfreetype, needed for drawtext filter [no]
--enable-libfribidi enable libfribidi, improves drawtext filter [no]
@@ -1770,6 +1771,7 @@ EXTERNAL_LIBRARY_LIST="
libdc1394
libdrm
libflite
+libfluidsynth
libfontconfig
libfreetype
libfribidi
@@ -3509,6 +3511,7 @@ find_rect_filter_deps="avcodec avformat gpl"
firequalizer_filter_deps="avcodec"
firequalizer_filter_select="rdft"
flite_filter_deps="libflite"
+fluidsynth_filter_deps="libfluidsynth"
framerate_filter_select="scene_sad"
freezedetect_filter_select="scene_sad"
frei0r_filter_deps="frei0r libdl"
@@ -6269,6 +6272,7 @@ enabled libfdk_aac&& { check_pkg_config
libfdk_aac fdk-aac "fdk-aac/aace
warn "using libfdk without pkg-config"; } }
flite_extralibs="-lflite_cmu_time_awb -lflite_cmu_us_awb -lflite_cmu_us_kal
-lflite_cmu_us_kal16 -lflite_cmu_us_rms -lflite_cmu_us_slt -lflite_usenglish
-lflite_cmulex -lflite"
enabled libflite && require libflite "flite/flite.h" flite_init
$flite_extralibs
+enabled libfluidsynth && require_pkg_config libfluidsynth fluidsynth
"fluidsynth.h" fluid_log
enabled fontconfig&& enable libfontconfig
enabled libfontconfig && require_pkg_config libfontconfig fontconfig
"fontconfig/fontconfig.h" FcInit
enabled libfreetype && require_pkg_config libfreetype freetype2
"ft2build.h FT_FREETYPE_H" FT_Init_FreeType
diff --git a/doc/filters.texi b/doc/filters.texi
index ff008b119f..cdf96d1ba1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6010,6 +6010,32 @@ ffplay -f lavfi flite=text='No more be grieved for which
that thou hast done.'
For more information about libflite, check:
@url{http://www.festvox.org/flite/}
+@section fluidsynth
+
+Synthesize random notes using libfluidsynth library.
+
+To compile this filter you need to configure FFmpeg with
+@code{--enable-libfluidsynth}.
+
+The filter accepts the following options:
+
+@table @option
+@item sample_rate, r
+Set the sample rate of the synthesizer. Default value is 44100.
+
+@item nb_samples, n
+Set the number of samples per frame. Default value is 1024.
+
+@item duration, d
+Set the duration of sound generation. Default value is 10 sec.
+
+@item soundfont
+Enter the location of the soundfont. Without loading the soundfont fluidsynth
won't be able to synthesize.
+
+@item chan
+Set the MIDI channel. Default value is 0.
+@end table
+
@section anoisesrc
Generate a noise audio signal.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 750412da6b..626d7c0f09 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -148,6 +148,7 @@ OBJS-$(CONFIG_AFIRSRC_FILTER)+=
asrc_afirsrc.o
OBJS-$(CONFIG_ANOISESRC_FILTER) += asrc_anoisesrc.o
OBJS-$(CONFIG_ANULLSRC_FILTER) += asrc_anullsrc.o
OBJS-$(CONFIG_FLITE_FILTER) += asrc_flite.o
+OBJS-$(CONFIG_FLUIDSYNTH_FILTER) += asrc_fluidsynth.o
OBJS-$(CONFIG_HILBERT_FILTER)+= asrc_hilbert.o
OBJS-$(CONFIG_SINC_FILTER) += asrc_sinc.o
OBJS-$(CONFIG_SINE_FILTER) += asrc_sine.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 501e5d041b..a1e812093c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -142,6 +142,7 @@ extern AVFilter ff_asrc_afirsrc;
extern AVFilter ff_asrc_anoisesrc;
extern AVFilter ff_asrc_anullsrc;
extern AVFilter ff_asrc_flite;
+extern AVFilter ff_asrc_fluidsynth;
extern AVFilter ff_asrc_hilbert;
extern AVFilter ff_asrc_sinc;
extern AVFilter ff_asrc_sine;
diff --git a/libavfilter/asrc_fluidsynth.c b/libavfilter
Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support
> -Original Message- > From: ffmpeg-devel On Behalf Of > Max Dmitrichenko > Sent: Thursday, March 12, 2020 9:57 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > > > DX11 support has certain and strong benefits. > > we have this patch for DX11 support already no clear understanding if and > when any other implementation(s) to expect. Hi Max, My approach is more complete but still not perfect, that's why I haven't submitted it yet. I'll contact you off-list so we can maybe work together to get a good result. sotworkz ___ 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 v2 6/7] avformat/mxfenc: allow all frame rates if -strict mode is set to unofficial or lower
On Sat, 7 Mar 2020, Tomas Härdin wrote:
tor 2020-03-05 klockan 22:56 +0100 skrev Marton Balint:
There was no consensus wheter or not to allow unofficial frame rates due to
possible interoperability issues, a compromise is to only allow it if -strict
mode is set to unofficial.
Signed-off-by: Marton Balint
---
libavformat/mxfenc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 51e2dc5f31..6279ba9d6d 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2413,8 +2413,12 @@ static int mxf_init_timecode(AVFormatContext *s,
AVStream *st, AVRational tbc)
AVDictionaryEntry *tcr = av_dict_get(s->metadata, "timecode", NULL, 0);
if (!ff_mxf_get_content_package_rate(tbc)) {
-av_log(s, AV_LOG_ERROR, "Unsupported frame rate %d/%d\n", tbc.den,
tbc.num);
-return AVERROR(EINVAL);
+if (s->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
+av_log(s, AV_LOG_ERROR, "Unsupported frame rate %d/%d. Set -strict
option to 'unofficial' or lower in order to allow it!\n", tbc.den, tbc.num);
+return AVERROR(EINVAL);
+} else {
+av_log(s, AV_LOG_WARNING, "Unofficial frame rate %d/%d.\n",
tbc.den, tbc.num);
+}
This can work. That way we make it clear to users that here be dragons
Thanks, it seems there are no further comments for patches 1-6, so I plan
to apply them soon.
Regards,
Marton
___
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 v2] lavc/qsv: adding DX11 support
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > On Wed, Mar 11, 2020 at 10:58 PM Soft Works > wrote: > > > > The submitted patch is far away from being complete. I know it > > because I've already done a full implementation of D3D11 support for > > QuickSync (but not yet submitted). > > > > Do note that only supporting array-textures in d3d11va was an intentional > choice, and its unlikely that a patch that would vastly increase the > complexity > in dealing with d3d11va by introducing an alternate mode for only legacy > hardware would likely not see much agreement. Hendrik, In this case, "legacy hardware" does not mean some age-old CPUs but a significant share of Intel CPUs that are in use today. softworkz ___ 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 v2] lavf/dashenc: add dash SegmentBase manifest generator
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this
box to have a reference to all fragments in the media.
Signed-off-by: David Martin
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 16
2 files changed, 21 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -309,6 +309,11 @@ escaped.
@item global_sidx @var{global_sidx}
Write global SIDX atom. Applicable only for single file, mp4 output,
non-streaming mode.
+@item use_segmentbase @var{use_segmentbase}
+Generates a dash SegmentBase manifest as defined in section 5.3.9.2 of the ISO
+DASH specification. Only applicable when global sidx is enabled since the
player
+uses it to have a reference of all the segments in the media
+
@item dash_segment_type @var{dash_segment_type}
Possible values:
@table @option
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..39286e9e11 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -193,6 +193,8 @@ typedef struct DASHContext {
int profile;
int64_t target_latency;
int target_latency_refid;
+int use_segmentbase;
+int64_t sidx_size;
} DASHContext;
static struct codec_string {
@@ -694,6 +696,12 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
avio_printf(out, "\t\t\t\t\t\n");
}
avio_printf(out, "\t\t\t\t\n");
+} else if (c->single_file && c->use_segmentbase && final) {
+avio_printf(out, "\t\t\t\t%s\n", os->initfile);
+int64_t init_segment_size = os->init_start_pos + os->init_range_length;
+avio_printf(out, "\t\t\t\t\n", init_segment_size -
c->sidx_size, init_segment_size - 1, AV_TIME_BASE);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size -
c->sidx_size - 1);
+avio_printf(out, "\t\t\t\t\n");
} else if (c->single_file) {
avio_printf(out, "\t\t\t\t%s\n", os->initfile);
avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
@@ -1389,6 +1397,12 @@ static int dash_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as
streaming is enabled\n");
c->global_sidx = 0;
}
+
+if (c->use_segmentbase && !c->global_sidx) {
+av_log(s, AV_LOG_WARNING, "SegmentBase manifest signaling option will
be ignored as global SIDX is not enabled\n");
+c->use_segmentbase = 0;
+}
+
if (c->frag_type == FRAG_TYPE_NONE && c->streaming) {
av_log(s, AV_LOG_VERBOSE, "Changing frag_type from none to every_frame
as streaming is enabled\n");
c->frag_type = FRAG_TYPE_EVERY_FRAME;
@@ -1981,6 +1995,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (c->global_sidx) {
int j, start_index, start_number;
int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
+c->sidx_size = sidx_size;
get_start_index_number(os, c, &start_index, &start_number);
if (start_index >= os->nb_segments ||
os->segment_type != SEGMENT_TYPE_MP4)
@@ -2350,6 +2365,7 @@ static const AVOption options[] = {
{ "index_correction", "Enable/Disable segment index correction logic",
OFFSET(index_correction), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ "format_options","set list of options for the container format
(mp4/webm) used for dash", OFFSET(format_options), AV_OPT_TYPE_DICT, {.str =
NULL}, 0, 0, E},
{ "global_sidx", "Write global SIDX atom. Applicable only for single file,
mp4 output, non-streaming mode", OFFSET(global_sidx), AV_OPT_TYPE_BOOL, { .i64
= 0 }, 0, 1, E },
+{ "use_segmentbase", "Use SegmentBase in Representation",
OFFSET(use_segmentbase), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ "dash_segment_type", "set dash segment files type",
OFFSET(segment_type_option), AV_OPT_TYPE_INT, {.i64 = SEGMENT_TYPE_AUTO }, 0,
SEGMENT_TYPE_NB - 1, E, "segment_type"},
{ "auto", "select segment file format based on codec", 0,
AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_AUTO }, 0, UINT_MAX, E,
"segment_type"},
{ "mp4", "make segment file in ISOBMFF format", 0, AV_OPT_TYPE_CONST,
{.i64 = SEGMENT_TYPE_MP4 }, 0, UINT_MAX, E, "segment_type"},
--
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".
[FFmpeg-devel] [PATCH] doc/muxers: add missing MOV muxer options
Signed-off-by: Lou Logan
---
The options for this muxer have a separate section about fragmenting.
I tried to organize the missing options into the proper sections, but
I don't use fragmenting so I may have placed them in the wrong section.
---
doc/muxers.texi | 116 +++-
1 file changed, 95 insertions(+), 21 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..750ab88a18 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1409,19 +1409,43 @@ how to cut the file into fragments:
@item -moov_size @var{bytes}
Reserves space for the moov atom at the beginning of the file instead of
placing the
moov atom at the end. If the space reserved is insufficient, muxing will fail.
-@item -movflags frag_keyframe
-Start a new fragment at each video keyframe.
@item -frag_duration @var{duration}
Create fragments that are @var{duration} microseconds long.
+@item -min_frag_duration @var{duration}
+Don't create fragments that are shorter than @var{duration} microseconds long.
@item -frag_size @var{size}
Create fragments that contain up to @var{size} bytes of payload data.
-@item -movflags frag_custom
+@item -frag_interleave @var{integer}
+Interleave samples within fragments. Max number of consecutive samples, lower
is
+tighter interleaving, but with more overhead. From 0 to INT_MAX.
+@item -movflags
+MOV muxer flags. Default is 0.
+
+Possible values:
+@table @samp
+@item delay_moov
+Delay writing the initial moov until the first fragment is cut, or
+until the first fragment is flushed.
+@item frag_custom
Allow the caller to manually choose when to cut fragments, by
calling @code{av_write_frame(ctx, NULL)} to write a fragment with
the packets written so far. (This is only useful with other
applications integrating libavformat, not from @command{ffmpeg}.)
-@item -min_frag_duration @var{duration}
-Don't create fragments that are shorter than @var{duration} microseconds long.
+@item frag_discont
+Signal that the next fragment is discontinuous from earlier ones.
+@item frag_every_frame
+Fragment at every frame.
+@item frag_keyframe
+Start a new fragment at each video keyframe.
+@item skip_trailer
+Skip writing the mfra/tfra/mfro trailer for fragmented files.
+@item cmaf
+Write CMAF compatible fragmented MP4.
+@item dash
+Write DASH compatible fragmented MP4.
+@item isml
+Create a live smooth streaming feed (for pushing to a publishing point).
+@end table
@end table
If more than one condition is specified, fragments are cut when
@@ -1433,7 +1457,15 @@ Additionally, the way the output file is written can be
adjusted
through a few other options:
@table @option
-@item -movflags empty_moov
+
+@item -movflags
+MOV muxer flags. Default is 0.
+
+Possible values:
+@table @samp
+
+
+@item empty_moov
Write an initial moov atom directly at the start of the file, without
describing any samples in it. Generally, an mdat/moov pair is written
at the start of the file, as a normal MOV/MP4 file, containing only
@@ -1442,50 +1474,65 @@ mdat atom, and the moov atom only describes the tracks
but has
a zero duration.
This option is implicitly set when writing ismv (Smooth Streaming) files.
-@item -movflags separate_moof
+@item separate_moof
Write a separate moof (movie fragment) atom for each track. Normally,
packets for all tracks are written in a moof atom (which is slightly
more efficient), but with this option set, the muxer writes one moof/mdat
pair for each track, making it easier to separate tracks.
This option is implicitly set when writing ismv (Smooth Streaming) files.
-@item -movflags skip_sidx
+
+@item negative_cts_offsets
+Enables utilization of version 1 of the CTTS box, in which the CTS offsets can
+be negative. This enables the initial sample to have DTS/CTS of zero, and
+reduces the need for edit lists for some cases such as video tracks with
+B-frames. Additionally, eases conformance with the DASH-IF interoperability
+guidelines.
+
+This option is implicitly set when writing ismv (Smooth Streaming) files.
+@item skip_sidx
Skip writing of sidx atom. When bitrate overhead due to sidx atom is high,
this option could be used for cases where sidx atom is not mandatory.
When global_sidx flag is enabled, this option will be ignored.
-@item -movflags faststart
+@item faststart
Run a second pass moving the index (moov atom) to the beginning of the file.
This operation can take a while, and will not work in various situations such
as fragmented output, thus it is not enabled by default.
-@item -movflags rtphint
+@item rtphint
Add RTP hinting tracks to the output file.
-@item -movflags disable_chpl
+@item disable_chpl
Disable Nero chapter markers (chpl atom). Normally, both Nero chapters
and a QuickTime chapter track are written to the file. With this option
set, only the QuickTime chapter track will be written. Nero chapters can
cause failures when the file is reprocessed with certain tagging programs, like
mp3Tag 2.61a and
[FFmpeg-devel] [PATCH 2/2] avformat/mux: Unify setting number of muxed packets
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index bc2eab0c96..bfd1bf491b 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -763,7 +763,8 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
if (ret < 0) {
pkt->pts = pts_backup;
pkt->dts = dts_backup;
-}
+} else
+s->streams[pkt->stream_index]->nb_frames++;
return ret;
}
@@ -912,11 +913,7 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
return ret;
#endif
-ret = write_packet(s, pkt);
-
-if (ret >= 0)
-s->streams[pkt->stream_index]->nb_frames++;
-return ret;
+return write_packet(s, pkt);
}
#define CHUNK_START 0x1000
@@ -1237,8 +1234,6 @@ int av_interleaved_write_frame(AVFormatContext *s,
AVPacket *pkt)
return ret;
ret = write_packet(s, &opkt);
-if (ret >= 0)
-s->streams[opkt.stream_index]->nb_frames++;
av_packet_unref(&opkt);
@@ -1263,8 +1258,6 @@ int av_write_trailer(AVFormatContext *s)
break;
ret = write_packet(s, &pkt);
-if (ret >= 0)
-s->streams[pkt.stream_index]->nb_frames++;
av_packet_unref(&pkt);
--
2.20.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".
[FFmpeg-devel] [PATCH 1/2] avformat/mux: Remove redundant checks for write errors
If writing a packet didn't directly return an error, the AVIOContext's error flag is checked for errors (if existing) by write_packet(). And if write_packet() didn't indicate an error, its callers checked the error flag of the AVIOContext (if existing). The latter check is redundant. The reason for checking twice lies in the FFmpeg-Libav split: The check in write_packet() has been added in 9ad1e0c1 in Libav. FFmpeg already had the other checks (since aec9390a), but when 9ad1e0c1 was merged (in 1f1c1008), no one noticed the redundant checks. Signed-off-by: Andreas Rheinhardt --- libavformat/mux.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/libavformat/mux.c b/libavformat/mux.c index d88746e8c5..bc2eab0c96 100644 --- a/libavformat/mux.c +++ b/libavformat/mux.c @@ -913,8 +913,6 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt) #endif ret = write_packet(s, pkt); -if (ret >= 0 && s->pb && s->pb->error < 0) -ret = s->pb->error; if (ret >= 0) s->streams[pkt->stream_index]->nb_frames++; @@ -1246,8 +1244,6 @@ int av_interleaved_write_frame(AVFormatContext *s, AVPacket *pkt) if (ret < 0) return ret; -if(s->pb && s->pb->error) -return s->pb->error; } fail: av_packet_unref(pkt); @@ -1274,8 +1270,6 @@ int av_write_trailer(AVFormatContext *s) if (ret < 0) goto fail; -if(s->pb && s->pb->error) -goto fail; } fail: -- 2.20.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] libavformat/matroskaenc.c: Check if we can seek before writing the end of the ebml of the segment.
Thanks Andreas
On Wed, Mar 11, 2020 at 5:35 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Thierry Foucu:
> > On Wed, Mar 11, 2020 at 10:13 AM Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Thierry Foucu:
> >>> ---
> >>> libavformat/matroskaenc.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> >>> index 42f21eae8b..cf436f9e3e 100644
> >>> --- a/libavformat/matroskaenc.c
> >>> +++ b/libavformat/matroskaenc.c
> >>> @@ -2630,7 +2630,7 @@ static int mkv_write_trailer(AVFormatContext *s)
> >>> avio_seek(pb, currentpos, SEEK_SET);
> >>> }
> >>>
> >>> -if (!mkv->is_live) {
> >>> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live) {
> >>> end_ebml_master(pb, mkv->segment);
> >>> }
> >>>
> >>>
> >> Why? Even if the output is unseekable, the seek to the beginning might
> >> succeed if it happens in the output buffer (unlikely but possible). Or
> >> do you have a specific usecase in mind where the segment should be
> >> unknown-length?
> >>
> >>
> > In most cases in the muxer, we are checking if the file support seeking
> > before writing some ebml, like we do for the cues in the trailer
> function.
> > It is true that in some cases, the offset will be in the output buffer,
> > then why not as well check it for cues?
>
> Because in order to write cues, one would have to store them first and
> we don't do that given that it is very unlikely for the cues to be
> used later.
> Furthermore, in the other cases (e.g. the Info element): These are
> already written and freed when writing the header if the output is
> unseekable (or actually: if the output was unseekable during writing
> the header; the logic is wrong if the output's seekability status
> changes and dangerous if it was unseekable when writing the header and
> changes to seekable later; I'll send a patch for this).
>
> > but most of the time, this offset will not when we are in streaming
> more.
> >
> > Maybe the aviobuf layer should not then call io_seek if the under
> > layer has is_streamed
> > = true?
> >
> First of all, the aviobuf layer doesn't call io_seek() any more
> because it has been removed in 6e8e8431. And does it matter from which
> layer the error for a failed seek comes if the seek was unsuccessfull?
> (Furthermore, there is (at least?) an instance where the is_streamed
> is wrong: Namely if you use the seekable option for file output. But
> that seems to be intentional.)
>
>
We have some code to check if ffmpeg was calling seek for some streamable
url or not and found this one.
what about this: not only check for the seek function to be present (which
will true for file.c) but check if it is seekable?
===
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index cc22beff28..bbf7545750 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -312,7 +312,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int
whence)
if (s->write_flag) {
flush_buffer(s);
}
-if (!s->seek)
+if (!s->seek || s->seekable == 0)
return AVERROR(EPIPE);
if ((res = s->seek(s->opaque, offset, SEEK_SET)) < 0)
return res;
> - Andreas
> ___
> 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".
--
Thierry Foucu
___
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] configure: Add llviddsp to mvha select
--- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 8b17134944..6ceb0c7af4 100755 --- a/configure +++ b/configure @@ -2791,6 +2791,7 @@ msmpeg4v3_encoder_select="h263_encoder" mss2_decoder_select="mpegvideo qpeldsp vc1_decoder" mts2_decoder_select="mss34dsp" mvha_decoder_deps="zlib" +mvha_decoder_select="llviddsp" mwsc_decoder_deps="zlib" mxpeg_decoder_select="mjpeg_decoder" nellymoser_decoder_select="mdct sinewin" -- 2.25.1.481.gfbce0eb801-goog ___ 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] configure: Add llviddsp to mvha deps
On Wed, Mar 11, 2020 at 3:35 PM Michael Niedermayer wrote: > On Wed, Mar 11, 2020 at 11:20:48PM +0100, Michael Niedermayer wrote: > > On Wed, Mar 11, 2020 at 03:39:23PM +0100, Paul B Mahol wrote: > > > lgtm > > > > will apply > > actually, i wont apply this yet, it looks a bit odd > > -mvha_decoder_deps="zlib" > +mvha_decoder_select="llviddsp zlib" > > zlib should be a _deps not _select i think > > Correct. Let me send you another patch. > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Rewriting code that is poorly written but fully understood is good. > Rewriting code that one doesnt understand is a sign that one is less smart > then the original author, trying to rewrite it will not make it better. > ___ > 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". -- Thierry Foucu ___ 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] pthread_frame: attempt to get frame to reduce latency
On 3/12/2020 7:05 AM, Dai, Jianhui J wrote: > Apologize for segfaults. > I do pass FATE and some basic tests myself before submit for review. It probably doesn't need to be mentioned, but since this affects frame threading, make sure to run "make fate THREADS=N THREAD_TYPE=frame" or similar. > Fixed locally and wait for other review comments. > > Thanks, > Jianhui Dai > > -Original Message- > From: ffmpeg-devel On Behalf Of Michael > Niedermayer > Sent: Wednesday, March 11, 2020 5:56 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to > reduce latency > > On Tue, Mar 10, 2020 at 05:36:40PM +0800, Jianhui Dai wrote: >> Avoid constant N frames latency in video streaming. >> >> Signed-off-by: Jianhui Dai >> --- >> libavcodec/pthread_frame.c | 17 ++--- >> 1 file changed, 2 insertions(+), 15 deletions(-) > > This patch causes segfaults > > ./ffmpeg_g -i tickets/466/Brazil.ts -t 3 random.avi > > Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault. > 0x55e64a5d in submit_packet (p=0x578c5e80, > user_avctx=0x5787fac0, avpkt=0x57845340) at > libavcodec/pthread_frame.c:380 > 380 PerThreadContext *prev_thread = fctx->prev_thread; > (gdb) bt > #0 0x55e64a5d in submit_packet (p=0x578c5e80, > user_avctx=0x5787fac0, avpkt=0x57845340) at > libavcodec/pthread_frame.c:380 > #1 0x55e64fea in ff_thread_decode_frame (avctx=0x5787fac0, > picture=0x57845080, got_picture_ptr=0x7fffd344, avpkt=0x57845340) > at libavcodec/pthread_frame.c:486 > #2 0x55bc5431 in decode_simple_internal (avctx=0x5787fac0, > frame=0x57845080) at libavcodec/decode.c:430 > #3 0x55bc6050 in decode_simple_receive_frame (avctx=0x5787fac0, > frame=0x57845080) at libavcodec/decode.c:628 > #4 0x55bc6120 in decode_receive_frame_internal > (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:646 > #5 0x55bc6380 in avcodec_send_packet (avctx=0x5787fac0, > avpkt=0x7fffd530) at libavcodec/decode.c:704 > #6 0x55694420 in decode (avctx=0x5787fac0, frame=0x57906280, > got_frame=0x7fffd67c, pkt=0x7fffd530) at fftools/ffmpeg.c:2232 > #7 0x55694cd0 in decode_video (ist=0x578f6900, > pkt=0x7fffd6c0, got_output=0x7fffd67c, duration_pts=0x7fffd6b8, > eof=0, decode_failed=0x7fffd680) at fftools/ffmpeg.c:2374 > #8 0x55695dbd in process_input_packet (ist=0x578f6900, > pkt=0x7fffd900, no_eof=0) at fftools/ffmpeg.c:2615 > #9 0x5569d74a in process_input (file_index=0) at > fftools/ffmpeg.c:4509 > #10 0x5569dd0b in transcode_step () at fftools/ffmpeg.c:4629 > #11 0x5569de88 in transcode () at fftools/ffmpeg.c:4683 > #12 0x5569e7ae in main (argc=6, argv=0x7fffe268) at > fftools/ffmpeg.c:4885 > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket466/ > > [...] > ___ 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] Reimbursement request
On 3/12/20, Thilo Borgmann wrote: > Am 12.03.20 um 12:08 schrieb Paul B Mahol: >> On 3/12/20, Thilo Borgmann wrote: >>> Am 12.03.20 um 11:56 schrieb Paul B Mahol: On 3/11/20, Carl Eugen Hoyos wrote: > Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan : >> >> On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote: > >>> The Chemnitzer Linuxtage were canceled yesterday because of the >>> Coronavirus. >>> I request reimbursement of €138,86 for the flight to Germany I had >>> booked last month. >> >> Some airlines are providing a more generous refund policy lately. >> Is your purchase covered by something like that? > > I tried to find out today but failed because the airline > telephone contact (canceling is only possible via > telephone) on multiple tries was either busy immediately > or went busy after I waited for some time. > > If nobody objects I will send the usual paperwork to Stefano. I object. >>> >>> Don't feed the troll and send the paperwork. >> >> This is outrageous and uncalled vilification! >> >> Lets's all buy something and than ask somebody else to pay for us instead. > >> Instead person should try to cancel it several times, only if it fails >> then ask for money. > > Totally agree. Therefore, "...on multiple tries...", see above. > Consider for the moment that Carl is not alone in the big world. Carl should try harder next time. > -Thilo > ___ > 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] Reimbursement request
Am 12.03.20 um 12:08 schrieb Paul B Mahol: > On 3/12/20, Thilo Borgmann wrote: >> Am 12.03.20 um 11:56 schrieb Paul B Mahol: >>> On 3/11/20, Carl Eugen Hoyos wrote: Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan : > > On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote: >> The Chemnitzer Linuxtage were canceled yesterday because of the >> Coronavirus. >> I request reimbursement of €138,86 for the flight to Germany I had >> booked last month. > > Some airlines are providing a more generous refund policy lately. > Is your purchase covered by something like that? I tried to find out today but failed because the airline telephone contact (canceling is only possible via telephone) on multiple tries was either busy immediately or went busy after I waited for some time. If nobody objects I will send the usual paperwork to Stefano. >>> >>> I object. >> >> Don't feed the troll and send the paperwork. > > This is outrageous and uncalled vilification! > > Lets's all buy something and than ask somebody else to pay for us instead. > Instead person should try to cancel it several times, only if it fails > then ask for money. Totally agree. Therefore, "...on multiple tries...", see above. -Thilo ___ 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] Reimbursement request
On 3/12/20, Thilo Borgmann wrote: > Am 12.03.20 um 11:56 schrieb Paul B Mahol: >> On 3/11/20, Carl Eugen Hoyos wrote: >>> Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan : On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote: >>> > The Chemnitzer Linuxtage were canceled yesterday because of the > Coronavirus. > I request reimbursement of €138,86 for the flight to Germany I had > booked last month. Some airlines are providing a more generous refund policy lately. Is your purchase covered by something like that? >>> >>> I tried to find out today but failed because the airline >>> telephone contact (canceling is only possible via >>> telephone) on multiple tries was either busy immediately >>> or went busy after I waited for some time. >>> >>> If nobody objects I will send the usual paperwork to Stefano. >> >> I object. > > Don't feed the troll and send the paperwork. This is outrageous and uncalled vilification! Lets's all buy something and than ask somebody else to pay for us instead. Instead person should try to cancel it several times, only if it fails then ask for money. ___ 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] lavc/qsv: adding DX11 support
On Fri, 6 Mar 2020 at 22:15, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Artem Galin
> > Sent: Friday, March 6, 2020 2:10 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Artem Galin
> > Subject: [FFmpeg-devel] [PATCH v4] lavc/qsv: adding DX11 support
> >
> > This enables DX11 support for QSV with higher priority than DX9.
> > In case of multiple GPUs configuration, DX9 API does not allow to get
> access
> > to QSV device in some cases - headless.
> > Implementation based on DX11 resolves that restriction by enumerating
> list
> > of available GPUs and finding device with QSV support.
> >
> > Signed-off-by: Artem Galin
> > ---
> > fftools/ffmpeg_opt.c | 12 +-
> > libavcodec/qsv.c | 53 +++-
> > libavcodec/qsv_internal.h | 2 +
> > libavfilter/qsvvpp.c | 36 +++--
> > libavutil/hwcontext_d3d11va.c | 56 +++-
> > libavutil/hwcontext_qsv.c | 240 --
> > 6 files changed, 340 insertions(+), 59 deletions(-)
> >
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c index
> > 1b721c4954..da619b0043 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -504,7 +504,17 @@ static int opt_init_hw_device(void *optctx, const
> > char *opt, const char *arg)
> > printf("\n");
> > exit_program(0);
> > } else {
> > -return hw_device_init_from_string(arg, NULL);
> > +HWDevice *dev;
> > +int err;
> > +if (!arg)
> > +return AVERROR(ENOMEM);
> > +err = hw_device_init_from_string(arg, &dev);
> > +if (err < 0)
> > +return err;
> > +hw_device_ctx = av_buffer_ref(dev->device_ref);
> > +if (!hw_device_ctx)
> > +return AVERROR(ENOMEM);
> > +return 0;
> > }
> > }
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > db98c75073..beea76896f 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -36,6 +36,8 @@
> > #include "avcodec.h"
> > #include "qsv_internal.h"
> >
> > +#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
> > +
> > #if QSV_VERSION_ATLEAST(1, 12)
> > #include "mfx/mfxvp8.h"
> > #endif
> > @@ -221,8 +223,13 @@ int ff_qsv_find_surface_idx(QSVFramesContext
> > *ctx, QSVFrame *frame)
> > int i;
> > for (i = 0; i < ctx->nb_mids; i++) {
> > QSVMid *mid = &ctx->mids[i];
> > +#if CONFIG_D3D11VA
> > +if (mid->handle_pair.second == frame->surface.Data.MemId)
> > +return i;
> > +#else
> > if (mid->handle == frame->surface.Data.MemId)
> > return i;
> > +#endif
> > }
> > return AVERROR_BUG;
> > }
> > @@ -362,7 +369,11 @@ static int
> > ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession *qs) int
> > ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
> > const char *load_plugins, int
> gpu_copy) {
> > +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> > mfxIMPL impl = MFX_IMPL_AUTO_ANY;
> > +#else
> > +mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11;
> > +#endif
> > mfxVersionver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR }
> > };
> > mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
> >
> > @@ -449,11 +460,21 @@ static AVBufferRef *qsv_create_mids(AVBufferRef
> > *hw_frames_ref)
> > return NULL;
> > }
> >
> > +#if CONFIG_D3D11VA
> > +for (i = 0; i < nb_surfaces; i++) {
> > +QSVMid *mid = &mids[i];
> > +mid->handle_is_pair = 1;
> > +mid->handle_pair.first = (mfxHDL)frames_hwctx-
> > >surfaces[i].Data.reserved2;
> > +mid->handle_pair.second = frames_hwctx->surfaces[i].Data.MemId;
> > +mid->hw_frames_ref = hw_frames_ref1;
> > +}
> > +#else
> > for (i = 0; i < nb_surfaces; i++) {
> > QSVMid *mid = &mids[i];
> > mid->handle= frames_hwctx->surfaces[i].Data.MemId;
> > mid->hw_frames_ref = hw_frames_ref1;
> > }
> > +#endif
> >
> > return mids_buf;
> > }
> > @@ -661,7 +682,12 @@ static mfxStatus qsv_frame_unlock(mfxHDL pthis,
> > mfxMemId mid, mfxFrameData *ptr) static mfxStatus
> > qsv_frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl) {
> > QSVMid *qsv_mid = (QSVMid*)mid;
> > -*hdl = qsv_mid->handle;
> > +if (qsv_mid->handle_is_pair) {
> > +mfxHDLPair *hdlpair = (mfxHDLPair*)hdl;
> > +*hdlpair = qsv_mid->handle_pair;
> > +} else {
> > +*hdl = qsv_mid->handle;
> > +}
> > return MFX_ERR_NONE;
> > }
> >
> > @@ -679,11 +705,11 @@ int ff_qsv_init_session_device(AVCodecContext
> > *avctx, mfxSession *psession,
> > mfxSessionparent_session = device_hwctx->session;
> > mfxInitParaminit_par = { MFX_IMPL_AUTO_ANY };
> > mfxHDLhandle = NULL;
> > +mfxHandleTypehandle_type = MFX_HANDLE_D3D11_DEVICE;
> >
> > mfxSession
Re: [FFmpeg-devel] Reimbursement request
Am 12.03.20 um 11:56 schrieb Paul B Mahol: > On 3/11/20, Carl Eugen Hoyos wrote: >> Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan : >>> >>> On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote: >> The Chemnitzer Linuxtage were canceled yesterday because of the Coronavirus. I request reimbursement of €138,86 for the flight to Germany I had booked last month. >>> >>> Some airlines are providing a more generous refund policy lately. >>> Is your purchase covered by something like that? >> >> I tried to find out today but failed because the airline >> telephone contact (canceling is only possible via >> telephone) on multiple tries was either busy immediately >> or went busy after I waited for some time. >> >> If nobody objects I will send the usual paperwork to Stefano. > > I object. Don't feed the troll and send the paperwork. -Thilo ___ 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] Reimbursement request
On 3/11/20, Carl Eugen Hoyos wrote: > Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan : >> >> On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote: > >> > The Chemnitzer Linuxtage were canceled yesterday because of the >> > Coronavirus. >> > I request reimbursement of €138,86 for the flight to Germany I had >> > booked last month. >> >> Some airlines are providing a more generous refund policy lately. >> Is your purchase covered by something like that? > > I tried to find out today but failed because the airline > telephone contact (canceling is only possible via > telephone) on multiple tries was either busy immediately > or went busy after I waited for some time. > > If nobody objects I will send the usual paperwork to Stefano. I object. > > Thank you, Carl Eugen > ___ > 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 v2] lavc/qsv: adding DX11 support
On Wed, Mar 11, 2020 at 10:58 PM Soft Works wrote: > > The submitted patch is far away from being complete. I know it > because I've already done a full implementation of D3D11 > support for QuickSync (but not yet submitted). > Do note that only supporting array-textures in d3d11va was an intentional choice, and its unlikely that a patch that would vastly increase the complexity in dealing with d3d11va by introducing an alternate mode for only legacy hardware would likely not see much agreement. - 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] lavd/avfoundation: Add basic transport control observation, for capable devices.
Hi, > fixes infinite loop waiting for input using e.g. tape devices that suport > transport control. will apply soon. -Thilo ___ 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] avfilter: add Audio Video Sync Test filter
Paul B Mahol (12020-03-12): > I changed my mind, I will not follow Nicolas advice at all. > Will apply this filter ASAP. > > I kindly ask Nicolas to stay away from my code for ever. This is not how it works. Re-send the patch for consideration by the whole project. -- Nicolas George ___ 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] pthread_frame: attempt to get frame to reduce latency
Apologize for segfaults. I do pass FATE and some basic tests myself before submit for review. Fixed locally and wait for other review comments. Thanks, Jianhui Dai -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Wednesday, March 11, 2020 5:56 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency On Tue, Mar 10, 2020 at 05:36:40PM +0800, Jianhui Dai wrote: > Avoid constant N frames latency in video streaming. > > Signed-off-by: Jianhui Dai > --- > libavcodec/pthread_frame.c | 17 ++--- > 1 file changed, 2 insertions(+), 15 deletions(-) This patch causes segfaults ./ffmpeg_g -i tickets/466/Brazil.ts -t 3 random.avi Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault. 0x55e64a5d in submit_packet (p=0x578c5e80, user_avctx=0x5787fac0, avpkt=0x57845340) at libavcodec/pthread_frame.c:380 380 PerThreadContext *prev_thread = fctx->prev_thread; (gdb) bt #0 0x55e64a5d in submit_packet (p=0x578c5e80, user_avctx=0x5787fac0, avpkt=0x57845340) at libavcodec/pthread_frame.c:380 #1 0x55e64fea in ff_thread_decode_frame (avctx=0x5787fac0, picture=0x57845080, got_picture_ptr=0x7fffd344, avpkt=0x57845340) at libavcodec/pthread_frame.c:486 #2 0x55bc5431 in decode_simple_internal (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:430 #3 0x55bc6050 in decode_simple_receive_frame (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:628 #4 0x55bc6120 in decode_receive_frame_internal (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:646 #5 0x55bc6380 in avcodec_send_packet (avctx=0x5787fac0, avpkt=0x7fffd530) at libavcodec/decode.c:704 #6 0x55694420 in decode (avctx=0x5787fac0, frame=0x57906280, got_frame=0x7fffd67c, pkt=0x7fffd530) at fftools/ffmpeg.c:2232 #7 0x55694cd0 in decode_video (ist=0x578f6900, pkt=0x7fffd6c0, got_output=0x7fffd67c, duration_pts=0x7fffd6b8, eof=0, decode_failed=0x7fffd680) at fftools/ffmpeg.c:2374 #8 0x55695dbd in process_input_packet (ist=0x578f6900, pkt=0x7fffd900, no_eof=0) at fftools/ffmpeg.c:2615 #9 0x5569d74a in process_input (file_index=0) at fftools/ffmpeg.c:4509 #10 0x5569dd0b in transcode_step () at fftools/ffmpeg.c:4629 #11 0x5569de88 in transcode () at fftools/ffmpeg.c:4683 #12 0x5569e7ae in main (argc=6, argv=0x7fffe268) at fftools/ffmpeg.c:4885 https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket466/ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. ___ 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] avfilter: add Audio Video Sync Test filter
On 8/23/17, Nicolas George wrote: > Le sextidi 6 fructidor, an CCXXV, Paul B Mahol a écrit : >> I was asked multiple times to implement this filter. > > I was not referring to the advice of single users with a tunnel vision > of their own use case. > >> What framework? There is only framework for video source filter which >> outputs static frames. > > You are mistaken: testsrc and testsrc2 use that framework and output > variable frames. > >> I could make use of sine filter code. > > Exactly. > > Regards, I changed my mind, I will not follow Nicolas advice at all. Will apply this filter ASAP. I kindly ask Nicolas to stay away from my code for ever. ___ 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 v2] lavc/qsv: adding DX11 support
On Wed, Mar 11, 2020 at 10:58 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Wednesday, March 11, 2020 12:49 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > On Tue, Mar 10, 2020 at 10:36 PM Soft Works > > wrote: > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Artem Galin > > > > Sent: Tuesday, March 10, 2020 5:10 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > > > > > Any comments on updated patch by link below: > > > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200306130954.893 > > > > 8- > > > > 1-artem.ga...@gmail.com/ > > > > > > I don't see any comments there. > > > > > > > > I can help commenting below: > > > Allow selection of a specific DXGI adapter > > QSV can make use only one Intel's adapter for currently available HW, if > > changed in the future - this comment should be addressed. > > 1. It wil change this year because Intel is about to release discrete gpu > boards > we have plans to address it when appropriate > 2. Users can have other GPU boars installed so Intel's GPU is not always > the first > DXGI/D3D11 adapter > > see d3d11va_device_find_adapter_by_vendor_id() related changes > > > Change filters to support mfxHandlePair > > Filters should come in next patches, > > This is initial implementation which will establish base for later > filters > > change(s). > > I don't think it is a good idea to submit a path that will break filtering > functionality. > > it is not possible to break DX11 filtering functionality when DX11 support doesnt exist at the first place. > The submitted patch is far away from being complete. I know it > because I've already done a full implementation of D3D11 > support for QuickSync (but not yet submitted). > > DX11 support has certain and strong benefits. we have this patch for DX11 support already no clear understanding if and when any other implementation(s) to expect. softworkz > regards Max (max.dmitriche...@intel.com) ___ 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 1/5] compat/avisynth: update headers
On Wed, 11 Mar 2020, Stephen Hutchinson wrote:
AviSynth+ can now be used on Linux, which required some changes
to the headers.
As part of this, and to not cause issues with adding a new header,
correct the header inclusion guards to make FATE happy.
Is it still required to include the headers in our source tree? AVISynth
was frowned upon in the past beacuse generally we do not allow headers of
external libraries in our tree.
If there is a way to completely remove the headers and keep the
feature buildable with reasonable amount of work then I suggest
we should do that.
Thanks,
Marton
---
compat/avisynth/avisynth_c.h | 30 ++
compat/avisynth/avs/capi.h | 22 ++-
compat/avisynth/avs/config.h | 52 +---
compat/avisynth/avs/posix.h | 111 +++
compat/avisynth/avs/types.h | 19 +++---
tests/ref/fate/source| 4 --
6 files changed, 197 insertions(+), 41 deletions(-)
create mode 100644 compat/avisynth/avs/posix.h
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 9ff9321552..d30d7caca9 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -51,8 +51,8 @@
// Example#2: avs_bits_per_component will return 8 for all colorspaces
(Classic Avisynth supports only 8 bits/pixel)
// Thus the Avisynth+ specific API functions are safely callable even
when connected to classic Avisynth DLL
-#ifndef __AVISYNTH_C__
-#define __AVISYNTH_C__
+#ifndef COMPAT_AVISYNTH_AVISYNTH_C_H
+#define COMPAT_AVISYNTH_AVISYNTH_C_H
#include "avs/config.h"
#include "avs/capi.h"
@@ -341,7 +341,7 @@ typedef struct AVS_VideoInfo {
int audio_samples_per_second; // 0 means no audio
int sample_type;
- INT64 num_audio_samples;
+ int64_t num_audio_samples;
int nchannels;
// Image type properties
@@ -444,16 +444,16 @@ AVSC_INLINE int avs_bytes_per_channel_sample(const
AVS_VideoInfo * p)
AVSC_INLINE int avs_bytes_per_audio_sample(const AVS_VideoInfo * p)
{ return p->nchannels*avs_bytes_per_channel_sample(p);}
-AVSC_INLINE INT64 avs_audio_samples_from_frames(const AVS_VideoInfo * p, INT64
frames)
-{ return ((INT64)(frames) * p->audio_samples_per_second *
p->fps_denominator / p->fps_numerator); }
+AVSC_INLINE int64_t avs_audio_samples_from_frames(const AVS_VideoInfo * p,
int64_t frames)
+{ return ((int64_t)(frames) * p->audio_samples_per_second *
p->fps_denominator / p->fps_numerator); }
-AVSC_INLINE int avs_frames_from_audio_samples(const AVS_VideoInfo * p, INT64
samples)
-{ return (int)(samples * (INT64)p->fps_numerator /
(INT64)p->fps_denominator / (INT64)p->audio_samples_per_second); }
+AVSC_INLINE int avs_frames_from_audio_samples(const AVS_VideoInfo * p, int64_t
samples)
+{ return (int)(samples * (int64_t)p->fps_numerator /
(int64_t)p->fps_denominator / (int64_t)p->audio_samples_per_second); }
-AVSC_INLINE INT64 avs_audio_samples_from_bytes(const AVS_VideoInfo * p, INT64
bytes)
+AVSC_INLINE int64_t avs_audio_samples_from_bytes(const AVS_VideoInfo * p,
int64_t bytes)
{ return bytes / avs_bytes_per_audio_sample(p); }
-AVSC_INLINE INT64 avs_bytes_from_audio_samples(const AVS_VideoInfo * p, INT64
samples)
+AVSC_INLINE int64_t avs_bytes_from_audio_samples(const AVS_VideoInfo * p,
int64_t samples)
{ return samples * avs_bytes_per_audio_sample(p); }
AVSC_INLINE int avs_audio_channels(const AVS_VideoInfo * p)
@@ -764,7 +764,7 @@ AVSC_API(int, avs_get_parity)(AVS_Clip *, int n);
// return field parity if field_based, else parity of first field in frame
AVSC_API(int, avs_get_audio)(AVS_Clip *, void * buf,
- INT64 start, INT64 count);
+ int64_t start, int64_t count);
// start and count are in samples
AVSC_API(int, avs_set_cache_hints)(AVS_Clip *,
@@ -784,7 +784,7 @@ struct AVS_FilterInfo
AVS_VideoFrame * (AVSC_CC * get_frame)(AVS_FilterInfo *, int n);
int (AVSC_CC * get_parity)(AVS_FilterInfo *, int n);
int (AVSC_CC * get_audio)(AVS_FilterInfo *, void * buf,
- INT64 start, INT64 count);
+ int64_t start, int64_t count);
int (AVSC_CC * set_cache_hints)(AVS_FilterInfo *, int cachehints,
int frame_range);
void (AVSC_CC * free_filter)(AVS_FilterInfo *);
@@ -933,6 +933,8 @@ AVSC_API(void,
avs_delete_script_environment)(AVS_ScriptEnvironment *);
AVSC_API(AVS_VideoFrame *, avs_subframe_planar)(AVS_ScriptEnvironment *,
AVS_VideoFrame * src, int rel_offset, int new_pitch, int new_row_size, int
new_height, int rel_offsetU, int rel_offsetV, int new_pitchUV);
// The returned video frame must be be released
+#if defined(AVS_WINDOWS)
+// The following stuff is only relevant for Windows DLL handling; Linux does
it completely differently.
#ifdef AVSC_NO_DECLSPEC
// This part uses LoadLibrary and related functions to dynamically load
Avisynth instead of declspec(dl
Re: [FFmpeg-devel] [PATCH] lavf/mux: bypass interleave delay early when waiting on subtitle streams
rcombs:
> This avoids long delays when converting live streams that have sparse
> subtitles
> ---
> libavformat/avformat.h | 9 +
> libavformat/mux.c | 25 +
> libavformat/options_table.h | 1 +
> libavformat/version.h | 2 +-
> 4 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 9b9b634ec3..da7e5755e8 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1957,6 +1957,15 @@ typedef struct AVFormatContext {
> * - decoding: set by user
> */
> int max_probe_packets;
> +
> +/**
> + * Maximum buffering duration for interleaving sparse streams.
> + *
> + * @see max_interleave_delta
> + *
> + * Applies only to subtitle and data streams.
> + */
> +int64_t max_sparse_interleave_delta;
> } AVFormatContext;
>
> #if FF_API_FORMAT_GET_SET
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index d88746e8c5..f2f272cf65 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -1033,6 +1033,7 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
> AVPacket *out,
> AVPacketList *pktl;
> int stream_count = 0;
> int noninterleaved_count = 0;
> +int sparse_count = 0;
> int i, ret;
> int eof = flush;
>
> @@ -1044,6 +1045,9 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
> AVPacket *out,
> for (i = 0; i < s->nb_streams; i++) {
> if (s->streams[i]->last_in_packet_buffer) {
> ++stream_count;
> +} else if (s->streams[i]->codecpar->codec_type ==
> AVMEDIA_TYPE_SUBTITLE ||
> + s->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_DATA)
> {
> +++sparse_count;
> } else if (s->streams[i]->codecpar->codec_type !=
> AVMEDIA_TYPE_ATTACHMENT &&
> s->streams[i]->codecpar->codec_id != AV_CODEC_ID_VP8 &&
> s->streams[i]->codecpar->codec_id != AV_CODEC_ID_VP9) {
> @@ -1054,10 +1058,12 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
> AVPacket *out,
> if (s->internal->nb_interleaved_streams == stream_count)
> flush = 1;
>
> -if (s->max_interleave_delta > 0 &&
> -s->internal->packet_buffer &&
> +if (s->internal->packet_buffer &&
> !flush &&
> -s->internal->nb_interleaved_streams ==
> stream_count+noninterleaved_count
> +((s->max_interleave_delta > 0 &&
> + s->internal->nb_interleaved_streams ==
> stream_count+noninterleaved_count+sparse_count) ||
> + (s->max_sparse_interleave_delta > 0 &&
> + s->internal->nb_interleaved_streams == stream_count+sparse_count))
If max_sparse_interleave_delta has its default value and
max_interleave_delta has been explicitly set to zero (thereby
indicating that one should wait until one has one packet for each
stream), the check used here might output a packet even if one does
not have packets for some of the sparse streams. This is in
contradiction to the documentation of max_interleave_delta.
(Nit: Use stream_count+sparse_count+noninterleaved_count.)
> ) {
> AVPacket *top_pkt = &s->internal->packet_buffer->pkt;
> int64_t delta_dts = INT64_MIN;
> @@ -1078,12 +1084,23 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
> AVPacket *out,
> delta_dts = FFMAX(delta_dts, last_dts - top_dts);
> }
>
> -if (delta_dts > s->max_interleave_delta) {
> +if (s->max_interleave_delta > 0 &&
> +delta_dts > s->max_interleave_delta &&
> +s->internal->nb_interleaved_streams ==
> stream_count+noninterleaved_count+sparse_count) {
> av_log(s, AV_LOG_DEBUG,
> "Delay between the first packet and last packet in the "
> "muxing queue is %"PRId64" > %"PRId64": forcing output\n",
> delta_dts, s->max_interleave_delta);
> flush = 1;
> +} else if (s->max_sparse_interleave_delta > 0 &&
> + delta_dts > s->max_sparse_interleave_delta &&
> + s->internal->nb_interleaved_streams ==
> stream_count+sparse_count) {
> +av_log(s, AV_LOG_DEBUG,
> + "Delay between the first packet and last packet in the "
> + "muxing queue is %"PRId64" > %"PRId64" and all delayed "
> + "streams are sparse: forcing output\n",
> + delta_dts, s->max_sparse_interleave_delta);
> +flush = 1;
> }
> }
>
Do all of these additional checks have a measurable performance impact?
Why didn't you include attached picture-streams (whether or not they
are timed thumbnails) among the sparse streams? (They are counted
among the nb_interleaved_streams and cause lots of delay*.)
The muxing code has even more gotchas: a06fac35 added these exceptions
for VP8 and VP9 (which exempted them from max_interleave_de
