[FFmpeg-devel] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On Ubuntu 20.10, I try to compile the latest git master version of
ffmpeg as below:
# In the needed prerequisites and execute the following command:
$ sudo apt-get build-dep ffmpeg
$ git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg.git
$ cd ffmpeg.git
$ ./configure --enable-rpath--enable-gpl--enable-version3
--enable-nonfree--enable-shared--enable-small--enable-gray
--enable-avresample--enable-avisynth--enable-chromaprint
--enable-frei0r--enable-gcrypt--enable-gmp--enable-ladspa
--enable-libaom--enable-libaribb24--enable-libass
--enable-libbluray--enable-libbs2b--enable-libcaca
--enable-libcelt--enable-libcdio--enable-libcodec2
--enable-libdav1d--enable-libdc1394--enable-libfdk-aac
--enable-libflite--enable-libfontconfig--enable-libfreetype
--enable-libfribidi--enable-libgme--enable-libgsm
--enable-libiec61883--enable-libjack--enable-libklvanc
--enable-liblensfun--enable-libmodplug--enable-libmp3lame
--enable-libopencore-amrnb--enable-libopencore-amrwb
--enable-libopenh264--enable-libopenjpeg--enable-libopenmpt
--enable-libopus--enable-libpulse--enable-librabbitmq
--enable-librsvg--enable-librubberband--enable-librtmp
--enable-libshine--enable-libsnappy--enable-libsoxr
--enable-libspeex--enable-libsrt--enable-libssh
--enable-libtesseract--enable-libtheora--enable-libtwolame
--enable-libv4l2--enable-libvidstab--enable-libvmaf
--enable-libvo-amrwbenc--enable-libvorbis--enable-libvpx
--enable-libwebp--enable-libx264--enable-libx265
--enable-libxavs2--enable-libdavs2--enable-libxcb
--enable-libxcb-shm--enable-libxcb-xfixes--enable-libxcb-shape
--enable-libxvid--enable-libxml2--enable-libzmq
--enable-libzvbi--enable-lv2--enable-libmysofa
--enable-openal--enable-opencl--enable-opengl
--enable-openssl--enable-pocketsphinx--enable-vulkan
--enable-libdrm--enable-libmfx--enable-pic--enable-thumb
--enable-lto--enable-hardcoded-tables--enable-extra-warnings
--enable-memory-poisoning--enable-ftrapv
--enable-neon-clobber-test--enable-xmm-clobber-test
--enable-random--enable-linux-perf --disable-avresample
$ make
[...]
libavfilter/vf_nnedi.c: At top level:
libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’
819 | static void read(float *dst, size_t n, const float **data)
| ^~~~
In file included from /usr/include/unistd.h:1183,
from ./libavutil/timer.h:35,
from ./libavutil/internal.h:42,
from ./libavutil/common.h:532,
from libavfilter/vf_nnedi.c:24:
/usr/include/x86_64-linux-gnu/bits/unistd.h:36:1: note: previous
definition of ‘read’ was here
36 | read (int __fd, void *__buf, size_t __nbytes)
| ^~~~
libavfilter/vf_nnedi.c: In function ‘subtract_mean_predictor’:
libavfilter/vf_nnedi.c:982:27: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
982 | for (int k = 0; k < filter_size; k++)
| ^
libavfilter/vf_nnedi.c:986:23: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
986 | for (int k = 0; k < filter_size; k++)
| ^
libavfilter/vf_nnedi.c:992:27: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
992 | for (int k = 0; k < filter_size; k++) {
| ^
libavfilter/vf_nnedi.c:1006:27: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
1006 | for (int k = 0; k < filter_size; k++) {
| ^
libavfilter/vf_nnedi.c:1011:23: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
1011 | for (int k = 0; k < filter_size; k++)
| ^
libavfilter/vf_nnedi.c:1016:30: warning: comparison of integer
expressions of different signedness: ‘unsigned int’ and ‘int’
[-Wsign-compare]
1016 | for (unsigned nn = 0; nn < nns; nn++) {
| ^
make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
Any hints for solving this problem are highly appreciated.
Regards,
--
Assoc. Prof. Hongyi Zhao
Theory and Simulation of Materials
Hebei Polytechnic University of Science and Technology engineering
NO. 552 North Gangtie Road, Xingtai, China
___
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 su
Re: [FFmpeg-devel] [PATCH] avformat/dhav: Fix incorrect non-DHAV chunk skipping logic
Oh i didn't notice that. Thanks.
On Mon, Jan 18, 2021 at 8:22 PM Paul B Mahol wrote:
> Isn't this applied already?
>
> On Mon, Jan 18, 2021 at 6:46 PM Idan Freiberg wrote:
>
> > Can one of the maintainers review the patch please?
> >
> > בתאריך יום ד׳, 13 בינו׳ 2021 ב-14:35 מאת Idan Freiberg >:
> >
> > > DAV files may contain a variable length padding in between chunks
> > > filled with 0xff bytes. The current skipping logic is incorrect as it
> > > may skip over DHAV chunks not appearing sequentially in the file.
> > >
> > > We now look for the 'DHAV' tag using a byte-by-byte search in order
> > > to handle such situations. Also the dhav->last_good_pos field will
> > > not be updated while skipping unrecognized data.
> > > ---
> > > libavformat/dhav.c | 15 +++
> > > 1 file changed, 3 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/libavformat/dhav.c b/libavformat/dhav.c
> > > index 00e0d8476e..6a6c235e65 100644
> > > --- a/libavformat/dhav.c
> > > +++ b/libavformat/dhav.c
> > > @@ -173,18 +173,9 @@ static int read_chunk(AVFormatContext *s)
> > > if (avio_feof(s->pb))
> > > return AVERROR_EOF;
> > >
> > > -if (avio_rl32(s->pb) != MKTAG('D','H','A','V') &&
> > dhav->last_good_pos
> > > < INT64_MAX - 0x8000) {
> > > -dhav->last_good_pos += 0x8000;
> > > -avio_seek(s->pb, dhav->last_good_pos, SEEK_SET);
> > > -
> > > -while (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
> > > -if (avio_feof(s->pb) || dhav->last_good_pos >= INT64_MAX -
> > > 0x8000)
> > > -return AVERROR_EOF;
> > > -dhav->last_good_pos += 0x8000;
> > > -ret = avio_skip(s->pb, 0x8000 - 4);
> > > -if (ret < 0)
> > > -return ret;
> > > -}
> > > +while (avio_r8(s->pb) != 'D' || avio_r8(s->pb) != 'H' ||
> > > avio_r8(s->pb) != 'A' || avio_r8(s->pb) != 'V') {
> > > +if (avio_feof(s->pb))
> > > +return AVERROR_EOF;
> > > }
> > >
> > > start = avio_tell(s->pb) - 4;
> > > --
> > > 2.30.0
> > >
> > > --
> > Idan Freiberg Mobile: +972-52-2925213
> > ___
> > 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".
--
Idan Freiberg
Mobile: +972-52-2925213
___
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] libavdevice: Add KMS/DRM output device
Quoting Mark Thompson (2021-01-19 00:37:09) > On 16/01/2021 22:12, Nicolas Caramelli wrote: > > This patch adds KMS/DRM output device for rendering a video stream > > using KMS/DRM dumb buffer. > > The proposed implementation is very basic, only bgr0 pixel format is > > currently supported (the most common format with KMS/DRM). > > To enable this output device you need to configure FFmpeg with > > --enable-libdrm. > > Example: ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0 > > If you want to render things to a normal display device why not use a normal > video player? Or even ffplay? > > IMO something like this would be of more value as a simple video player > example with the documentation rather than including it as weirdly > constrained library code which will see very little use. > > (Note that I would argue against adding more general display output devices > which are already present, like fb and xv, because they are of essentially no > value to libavdevice users. Removing legacy code is harder, though.) +1 IMO libavdevice output devices are worse than useless and should all be removed. Libavformat API is barely passable for input, but it really is NOT something you should use to drive outputs. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/flashsv2enc: factorize updating block dimensions
Quoting Marton Balint (2021-01-18 21:53:30) > > > On Mon, 18 Jan 2021, Anton Khirnov wrote: > > > Quoting Marton Balint (2021-01-10 02:20:45) > >> Signed-off-by: Marton Balint > >> --- > >> libavcodec/flashsv2enc.c | 76 +--- > >> 1 file changed, 32 insertions(+), 44 deletions(-) > >> > >> diff --git a/libavcodec/flashsv2enc.c b/libavcodec/flashsv2enc.c > >> index 6603d0ded1..5139b17a28 100644 > >> --- a/libavcodec/flashsv2enc.c > >> +++ b/libavcodec/flashsv2enc.c > >> @@ -252,7 +259,7 @@ static av_cold int flashsv2_encode_init(AVCodecContext > >> * avctx) > >> s->use_custom_palette = 0; > >> s->palette_type = -1;// so that the palette will be > >> generated in reconfigure_at_keyframe > >> > >> -return 0; > >> +return update_block_dimensions(s, 64, 64); > > > > This looks different from the original value. Why the change? > > Block dimensions are recalculated on every keyframe, so it does not > matter what the block width/height is after init. 64 is used > because the current code always selects that (see the > optimum_block_width/height functions). Okay, makes sense. You could mention it in the commit message, since one would not expect a 'factorize' commit to change behaviour. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat: add librist protocol
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 32 +
libavformat/Makefile| 1 +
libavformat/librist.c | 250
libavformat/protocols.c | 1 +
5 files changed, 289 insertions(+)
create mode 100644 libavformat/librist.c
diff --git a/configure b/configure
index 54fbbd6b5f..ad3171bfbc 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
--enable-libpulseenable Pulseaudio input via libpulse [no]
--enable-librabbitmq enable RabbitMQ library [no]
--enable-librav1eenable AV1 encoding via rav1e [no]
+ --enable-librist enable RIST via librist [no]
--enable-librsvg enable SVG rasterization via librsvg [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
--enable-librtmp enable RTMP[E] support via librtmp [no]
@@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
libpulse
librabbitmq
librav1e
+librist
librsvg
librtmp
libshine
@@ -3490,6 +3492,8 @@ unix_protocol_select="network"
# external library protocols
libamqp_protocol_deps="librabbitmq"
libamqp_protocol_select="network"
+librist_protocol_deps="librist"
+librist_protocol_select="network"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
@@ -6409,6 +6413,7 @@ enabled libopus && {
enabled libpulse && require_pkg_config libpulse libpulse
pulse/pulseaudio.h pa_context_new
enabled librabbitmq && require_pkg_config librabbitmq "librabbitmq >=
0.7.1" amqp.h amqp_new_connection
enabled librav1e && require_pkg_config librav1e "rav1e >= 0.4.0"
rav1e.h rav1e_context_new
+enabled librist && require_pkg_config librist "librist >= 0.2"
librist/librist.h rist_receiver_create
enabled librsvg && require_pkg_config librsvg librsvg-2.0
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp && require_pkg_config librtmp librtmp librtmp/rtmp.h
RTMP_Socket
enabled librubberband && require_pkg_config librubberband "rubberband >=
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append
librubberband_extralibs "-lstdc++"
diff --git a/doc/protocols.texi b/doc/protocols.texi
index c0b511b7a4..3160f846ff 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -690,6 +690,38 @@ Example usage:
-f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
@end example
+@section rist
+
+Reliable Internet Streaming Transport protocol
+
+The accepted options are:
+@table @option
+@item rist_profile
+Supported values:
+@table @samp
+@item simple
+@item main
+This one is default.
+@item advanced
+@end table
+
+@item buffer_size
+Set internal RIST buffer size for retransmission of data.
+
+@item pkt_size
+Set internal RIST buffer size for receiving and sending data.
+
+@item log_level
+Set loglevel for RIST logging messages.
+
+@item secret
+Set override of encryption secret, by default is unset.
+
+@item encryption
+Set encryption type, by default is disabled.
+Acceptable values are 128 and 256.
+@end table
+
@section rtmp
Real-Time Messaging Protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3a8fbcbe5f..85f432c8d9 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
# external library protocols
OBJS-$(CONFIG_LIBAMQP_PROTOCOL) += libamqp.o
+OBJS-$(CONFIG_LIBRIST_PROTOCOL) += librist.o
OBJS-$(CONFIG_LIBRTMP_PROTOCOL) += librtmp.o
OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
diff --git a/libavformat/librist.c b/libavformat/librist.c
new file mode 100644
index 00..724247e74c
--- /dev/null
+++ b/libavformat/librist.c
@@ -0,0 +1,250 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Reliable Internet Streaming Transport protocol
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/time.h"
+
+#include "avformat.h"
+#include "
Re: [FFmpeg-devel] [PATCH] libavdevice: Add KMS/DRM output device
On Mon, 18 Jan 2021 23:37:09 +, you wrote: >On 16/01/2021 22:12, Nicolas Caramelli wrote: >> This patch adds KMS/DRM output device for rendering a video stream >> using KMS/DRM dumb buffer. >> The proposed implementation is very basic, only bgr0 pixel format is >> currently supported (the most common format with KMS/DRM). >> To enable this output device you need to configure FFmpeg with >> --enable-libdrm. >> Example: ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0 > >If you want to render things to a normal display device why not use a normal >video player? Or even ffplay? > >IMO something like this would be of more value as a simple video player >example with the documentation rather than including it as weirdly constrained >library code which will see very little use. > >(Note that I would argue against adding more general display output devices >which are already present, like fb and xv, because they are of essentially no >value to libavdevice users. Removing legacy code is harder, though.) I take your point but I personally have found it very useful to have simple display devices on the output of ffmpeg for testing purposes. Though I guess that if I want that then the device should be bundled with the application rather than in a library. John Cox ___ 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] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On 19/01/2021 09:21, Hongyi Zhao wrote: > libavfilter/vf_nnedi.c: At top level: > libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’ > 819 | static void read(float *dst, size_t n, const float **data) I thought this might happen when I saw it go in. We shouldn't be naming functions things that clash with standard POSIX or stdlib functions like 'read'. - Derek ___ 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] [RFC][v2] Tech Resolution Process
Ronald S. Bultje (12021-01-18): > I agree "involved" should be constrained to just be one of the two parties > bringing this up to the TC. And yes this can be gamed, everything can. It's > meant to prevent extreme cases, not make the world a perfect place. We > can't do that with rules alone. I agree with all this. I would say that if "you" are part of an argument, you should know it. And if you have doubt, that means you probably are, and you should err on the side of caution and recuse yourself. After all, recusing oneself uselessly only means a little more work for the other members of the committee while not doing it when needed undermines the trust in the process. Let us remember that this committee is about serving the community by resolving conflicts, it is definitely not about personal power for the members. For it to work properly, technical competence is necessary, but technical expertise is much less important than honesty and willingness to listen. Regards, -- Nicolas George 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] [RFC][v2] Tech Resolution Process
On Tue, Jan 19, 2021 at 5:26 PM Nicolas George wrote: > Ronald S. Bultje (12021-01-18): > > I agree "involved" should be constrained to just be one of the two > parties > > bringing this up to the TC. And yes this can be gamed, everything can. > It's > > meant to prevent extreme cases, not make the world a perfect place. We > > can't do that with rules alone. > > I agree with all this. > > I would say that if "you" are part of an argument, you should know it. > And if you have doubt, that means you probably are, and you should err > on the side of caution and recuse yourself. After all, recusing oneself > uselessly only means a little more work for the other members of the > committee while not doing it when needed undermines the trust in the > process. > > Let us remember that this committee is about serving the community by > resolving conflicts, it is definitely not about personal power for the > members. > > For it to work properly, technical competence is necessary, but > technical expertise is much less important than honesty and willingness > to listen. > > Listen to whom? And honest about what? > Regards, > > -- > 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". ___ 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 4/7] avformat/nistspheredec: Check bits_per_coded_sample and channels
On Mon, Jan 18, 2021 at 09:06:10PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2021-01-17 00:07:26) > > Fixes: signed integer overflow: 80 * 92233009 cannot be represented in type > > 'int' > > Fixes: > > 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_NISTSPHERE_fuzzer-6669100654919680 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/nistspheredec.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c > > index 079369929f..fec5c88892 100644 > > --- a/libavformat/nistspheredec.c > > +++ b/libavformat/nistspheredec.c > > @@ -80,7 +80,9 @@ static int nist_read_header(AVFormatContext *s) > > > > avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); > > > > -st->codecpar->block_align = > > st->codecpar->bits_per_coded_sample * st->codecpar->channels / 8; > > +if (st->codecpar->bits_per_coded_sample * > > (uint64_t)st->codecpar->channels / 8 > INT_MAX) > > +return AVERROR_INVALIDDATA; > > +st->codecpar->block_align = > > st->codecpar->bits_per_coded_sample * (uint64_t)st->codecpar->channels / 8; > > > > if (avio_tell(s->pb) > header_size) > > return AVERROR_INVALIDDATA; > > -- > > 2.17.1 > > Both bits_per_coded_sample and channels seem to be arbitrary ints, so > you are assuming sizeof(int) < sizeof(int64) I wonder if we shouldnt limit these 2 fields in a platform independant way But if we dont then the change below should do more correct checks @@ -80,7 +80,11 @@ static int nist_read_header(AVFormatContext *s) avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); -st->codecpar->block_align = st->codecpar->bits_per_coded_sample * st->codecpar->channels / 8; +if (st->codecpar->bits_per_coded_sample < 0 || st->codecpar->channels <= 0 || +st->codecpar->bits_per_coded_sample > UINT64_MAX / st->codecpar->channels || +st->codecpar->bits_per_coded_sample * (uint64_t)st->codecpar->channels / 8 > INT_MAX) +return AVERROR_INVALIDDATA; +st->codecpar->block_align = st->codecpar->bits_per_coded_sample * (uint64_t)st->codecpar->channels / 8; if (avio_tell(s->pb) > header_size) return AVERROR_INVALIDDATA; [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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] libavdevice: Add KMS/DRM output device
I appreciate to directly experiment ffmpeg without X11 or SDL dependencies, just using the ffmpeg binary. This is especially true when I work on embedded systems and I use it a lot. Even though the fbdev output device is available, the Linux Framebuffer is often considered obsolete in favor of KMS/DRM. But if there are plans to remove output devices like fbdev or xv, I understand that it is difficult to consider supporting a KMS/DRM output ... Nicolas Caramelli Le mar. 19 janv. 2021 à 13:46, John Cox a écrit : > > On Mon, 18 Jan 2021 23:37:09 +, you wrote: > >On 16/01/2021 22:12, Nicolas Caramelli wrote: > >> This patch adds KMS/DRM output device for rendering a video stream > >> using KMS/DRM dumb buffer. > >> The proposed implementation is very basic, only bgr0 pixel format is > >> currently supported (the most common format with KMS/DRM). > >> To enable this output device you need to configure FFmpeg with > >> --enable-libdrm. > >> Example: ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0 > > > >If you want to render things to a normal display device why not use a normal > >video player? Or even ffplay? > > > >IMO something like this would be of more value as a simple video player > >example with the documentation rather than including it as weirdly > >constrained library code which will see very little use. > > > >(Note that I would argue against adding more general display output devices > >which are already present, like fb and xv, because they are of essentially > >no value to libavdevice users. Removing legacy code is harder, though.) > > I take your point but I personally have found it very useful to have > simple display devices on the output of ffmpeg for testing purposes. > Though I guess that if I want that then the device should be bundled > with the application rather than in a library. > > John Cox > ___ > 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] libavdevice: Add KMS/DRM output device
Anton Khirnov (12021-01-19): > > (Note that I would argue against adding more general display output > > devices which are already present, like fb and xv, because they are > > of essentially no value to libavdevice users. Removing legacy code > > is harder, though.) > > +1 > > IMO libavdevice output devices are worse than useless and should all be > removed. Libavformat API is barely passable for input, but it really is > NOT something you should use to drive outputs. I use libavdevice in my projects, and these output devices have a lot of value to me. With this kind of user-hostile attitude where you disregard everybody's use case except those you deem valuable, you almost killed the project once. It was ten years ago, time to try again? -- Nicolas George 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 1/3] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header
On 1/18/2021 2:39 PM, Nachiket Tarate wrote:
These will be used by HLS demuxer in case of SAMPLE-AES encryption/decryption.
Signed-off-by: Nachiket Tarate
---
libavcodec/adts_header.c | 1 +
libavcodec/adts_header.h | 1 +
libavcodec/adts_parser.c | 29 -
libavcodec/adts_parser.h | 4
4 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
index 0889820f8a..c6680b0fc8 100644
--- a/libavcodec/adts_header.c
+++ b/libavcodec/adts_header.c
@@ -66,6 +66,7 @@ int ff_adts_header_parse(GetBitContext *gbc,
AACADTSHeaderInfo *hdr)
hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
hdr->samples= (rdb + 1) * 1024;
hdr->bit_rate = size * 8 * hdr->sample_rate / hdr->samples;
+hdr->frame_length = size;
return size;
}
diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
index f615f6a9f9..c362ce46a5 100644
--- a/libavcodec/adts_header.h
+++ b/libavcodec/adts_header.h
@@ -34,6 +34,7 @@ typedef struct AACADTSHeaderInfo {
uint8_t sampling_index;
uint8_t chan_config;
uint8_t num_aac_frames;
+uint32_t frame_length;
} AACADTSHeaderInfo;
/**
diff --git a/libavcodec/adts_parser.c b/libavcodec/adts_parser.c
index 5c9f8ff6f2..3421d9fee8 100644
--- a/libavcodec/adts_parser.c
+++ b/libavcodec/adts_parser.c
@@ -21,7 +21,6 @@
#include
#include
-#include "adts_header.h"
#include "adts_parser.h"
int av_adts_header_parse(const uint8_t *buf, uint32_t *samples, uint8_t *frames)
@@ -42,3 +41,31 @@ int av_adts_header_parse(const uint8_t *buf, uint32_t
*samples, uint8_t *frames)
return AVERROR(ENOSYS);
#endif
}
+
+int avpriv_adts_header_parse (AACADTSHeaderInfo **phdr, const uint8_t *buf,
size_t size)
+{
+#if CONFIG_ADTS_HEADER
+int ret = 0;
+GetBitContext gb;
+
+if (size < AV_AAC_ADTS_HEADER_SIZE)
+return AVERROR_INVALIDDATA;
+
+if (!*phdr)
+*phdr = av_mallocz(sizeof(AACADTSHeaderInfo));
+if (!*phdr)
+return AVERROR(ENOMEM);
+
+ret = init_get_bits8(&gb, buf, AV_AAC_ADTS_HEADER_SIZE);
+if (ret < 0)
+return ret;
+
+ret = ff_adts_header_parse(&gb, *phdr);
+if (ret < 0)
+return ret;
+
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+}
diff --git a/libavcodec/adts_parser.h b/libavcodec/adts_parser.h
index f85becd131..faa6e47426 100644
--- a/libavcodec/adts_parser.h
+++ b/libavcodec/adts_parser.h
@@ -22,6 +22,8 @@
#include
#include
+#include "adts_header.h"
+
#define AV_AAC_ADTS_HEADER_SIZE 7
/**
@@ -34,4 +36,6 @@
int av_adts_header_parse(const uint8_t *buf, uint32_t *samples,
uint8_t *frames);
+int avpriv_adts_header_parse (AACADTSHeaderInfo **phdr, const uint8_t *buf, size_t size);
This is a private function, so it must not be in an installed header. It
should be in adts_header.h, alongside ff_adts_header_parse().
+
#endif /* AVCODEC_ADTS_PARSER_H */
___
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/3] libavformat/hls: add support for SAMPLE-AES decryption in HLS demuxer
On 1/18/2021 2:39 PM, Nachiket Tarate wrote:
+typedef struct AVParserContext {
+const uint8_t *buf_in;
+const uint8_t *buf_end;
+uint8_t *buf_out;
+int next_start_code_length;
+} AVParserContext;
The AV prefix in structs names should not be used for an internal struct
used in a single file.
[...]
+/*
+ * Parse 'dec3' EC3SpecificBox
+ */
+static int parse_dec3(AC3HeaderInfo **phdr, const uint8_t *buf, size_t size)
+{
+GetBitContext gb;
+AC3HeaderInfo *hdr;
+int err;
+
+int data_rate, fscod, acmod, lfeon;
+
+if (!*phdr)
+*phdr = av_mallocz(sizeof(AC3HeaderInfo));
sizeof(AC3HeaderInfo) is not meant to be used outside of libavcodec.
It's why avpriv_ac3_parse_header() resides in libavcodec and allocates
it when used from libavformat.
Since parsing the dec3 atom is trivial, you can do it directly in
ff_hls_parse_audio_setup_info and store the values in local independent
variables (or even straight to st->codecpar) without the need for an
AC3HeaderInfo struct.
+if (!*phdr)
+return AVERROR(ENOMEM);
+hdr = *phdr;
+
+err = init_get_bits8(&gb, buf, size);
+if (err < 0)
+return AVERROR_INVALIDDATA;
+
+data_rate = get_bits(&gb, 13);
+skip_bits(&gb, 3);
+fscod = get_bits(&gb, 2);
+skip_bits(&gb, 10);
+acmod = get_bits(&gb, 3);
+lfeon = get_bits(&gb, 1);
+
+hdr->sample_rate = eac3_sample_rate_tab[fscod];
+
+hdr->channel_layout = avpriv_ac3_channel_layout_tab[acmod];
+if (lfeon)
+hdr->channel_layout |= AV_CH_LOW_FREQUENCY;
+
+hdr->channels = av_get_channel_layout_nb_channels(hdr->channel_layout);
+
+hdr->bit_rate = data_rate*1000;
+
+return 0;
+}
+
+int ff_hls_parse_audio_setup_info(AVStream *st, HLSAudioSetupInfo *info)
+{
+int ret = 0;
+
+AC3HeaderInfo *ac3hdr = NULL;
+
+st->codecpar->codec_tag = info->codec_tag;
+
+if (st->codecpar->codec_id == AV_CODEC_ID_AAC)
+return 0;
+
+st->codecpar->extradata = av_mallocz(info->setup_data_length +
AV_INPUT_BUFFER_PADDING_SIZE);
+
+if (!st->codecpar->extradata)
+return AVERROR(ENOMEM);
+
+st->codecpar->extradata_size = info->setup_data_length;
+
+if (st->codecpar->codec_id == AV_CODEC_ID_AC3)
+ret = avpriv_ac3_parse_header(&ac3hdr, info->setup_data,
info->setup_data_length);
Are you sure this is correct? avpriv_ac3_parse_header() parses raw ac3
and eac3 frame headers, and if eac3 here is supposedly stored as a dec3
atom, wouldn't ac3 be the same using a dac3 atom?
+else if (st->codecpar->codec_id == AV_CODEC_ID_EAC3)
+ret = parse_dec3(&ac3hdr, info->setup_data, info->setup_data_length);
+else
+return -1;
AVERROR_INVALIDDATA. Is this function going to be called with other
codec ids to trigger this path?
[...]
@@ -2019,9 +2075,14 @@ static int hls_read_header(AVFormatContext *s)
* on us if they want to.
*/
if (pls->is_id3_timestamped || (pls->n_renditions > 0 &&
pls->renditions[0]->type == AVMEDIA_TYPE_AUDIO)) {
+if (seg && seg->key_type == KEY_SAMPLE_AES &&
pls->audio_setup_info.setup_data_length > 0 &&
+pls->ctx->nb_streams == 1) {
+ff_hls_parse_audio_setup_info(pls->ctx->streams[0],
&pls->audio_setup_info);
The return value is being ignored.
+} else {
ret = avformat_find_stream_info(pls->ctx, NULL);
if (ret < 0)
goto fail;
+}
}
pls->has_noheader_flag = !!(pls->ctx->ctx_flags & AVFMTCTX_NOHEADER);
___
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] libavdevice: Add KMS/DRM output device
On 1/19/2021 4:04 PM, Nicolas George wrote: Anton Khirnov (12021-01-19): (Note that I would argue against adding more general display output devices which are already present, like fb and xv, because they are of essentially no value to libavdevice users. Removing legacy code is harder, though.) +1 IMO libavdevice output devices are worse than useless and should all be removed. Libavformat API is barely passable for input, but it really is NOT something you should use to drive outputs. I use libavdevice in my projects, and these output devices have a lot of value to me. With this kind of user-hostile attitude where you disregard everybody's use case except those you deem valuable, you almost killed the project once. It was ten years ago, time to try again? This entire paragraph was absolutely unnecessary and uncalled for as a reply to a personal opinion. The first one alone was more than enough to let him and Mark know output devices have active users. ___ 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] libavdevice: Add KMS/DRM output device
On 19/01/2021 19:04, Nicolas George wrote: Anton Khirnov (12021-01-19): (Note that I would argue against adding more general display output devices which are already present, like fb and xv, because they are of essentially no value to libavdevice users. Removing legacy code is harder, though.) I use libavdevice in my projects, and these output devices have a lot of value to me. Can you explain in more detail your use of libavdevice here? My general sense is that while they might sometimes be convenient to use if you are already working in a libav* context, they are so limited (by both the API and the implementation) that most users who want video output to a screen will turn more full-featured players to implement this. (To be clear here, I am talking specifically about outputs to a screen like fbdev/xv, not about output to non-screen-like devices such as v4l2 which certainly do have other use-cases.) Thanks, - Mark ___ 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 07/13] cbs: Implement common parts of cbs-based bitstream filters separately
On 19/01/2021 03:07, James Almer wrote:
On 1/18/2021 7:44 PM, Mark Thompson wrote:
+#define BSF_ELEMENT_OPTIONS_PIR(name, help, field, unit_name) \
You could reuse name instead of also passing unit_name. The only bsf where it
differs is h264_metadata with display_orientation vs disp_or, and changing the
latter into the former should be fine (Is it even user facing?).
I don't think it can have any user effect, though technically they can inspect
it. So, sure, that's simpler.
+ { name, help, OFFSET(field), AV_OPT_TYPE_INT, \
+ { .i64 = BSF_ELEMENT_PASS }, \
+ BSF_ELEMENT_PASS, BSF_ELEMENT_REMOVE, FLAGS, unit_name }, \
This depends on FLAGS being defined before this macro is invoked. It's probably
safer and/or more robust to pass the flags as an argument.
All BSFs with options use this idiom, so it felt safe ("grep -r
AV_OPT_FLAG_BSF_PARAM libavcodec/").
I guess it is slightly surprising to have that extra implicit argument, though,
so no objection to making it explicit.
+ { "pass", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_PASS }, .flags = FLAGS, .unit = unit_name }, \
+ { "insert", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_INSERT }, .flags = FLAGS, .unit = unit_name }, \
+ { "remove", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_REMOVE }, .flags = FLAGS, .unit = unit_name }
+
+#define BSF_ELEMENT_OPTIONS_PIRE(name, help, field, unit_name) \
+ { name, help, OFFSET(field), AV_OPT_TYPE_INT, \
+ { .i64 = BSF_ELEMENT_PASS }, \
+ BSF_ELEMENT_PASS, BSF_ELEMENT_EXTRACT, FLAGS, unit_name }, \
+ { "pass", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_PASS }, .flags = FLAGS, .unit = unit_name }, \
+ { "insert", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_INSERT }, .flags = FLAGS, .unit = unit_name }, \
+ { "remove", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_REMOVE }, .flags = FLAGS, .unit = unit_name }, \
+ { "extract", NULL, 0, AV_OPT_TYPE_CONST, \
+ { .i64 = BSF_ELEMENT_EXTRACT }, .flags = FLAGS, .unit = unit_name } \
Thanks,
- Mark
___
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 3/3] avformat/mxfenc: prefer to use the configured metadta
On Tue, 19 Jan 2021, Tobias Rapp wrote: On 18.01.2021 23:53, Tomas Härdin wrote: lör 2021-01-16 klockan 08:43 +0800 skrev lance.lmw...@gmail.com: On Fri, Jan 15, 2021 at 09:43:58PM +0100, Marton Balint wrote: On Fri, 15 Jan 2021, Tomas Härdin wrote: Again, why? If you have a company that maintains a fork of FFmpeg then compile that info in here instead. Compare with FFmbc which always puts "FFmbc" as CompanyName. And how can a product based on libavformat set the company name, product name and product version? It seems a valid use case for me that these are overridable. Also note that this product version is only the "user friendly" version string, for the numeric version still LIBAVFORMAT_VERSION values are used. Yes, my use case is the product is using libavformat as library, so it's prefer to have way to override these information as requirements. What I'm worried about here is that we're going to get files which claim to have been written by something other than libavformat. I've had situations like this before, and it is a source of headache. For example, if mxfenc writes some field incorrectly then this might cause us to hack mxfdec to accept that field instead of fixing mxfenc. I agree that especially for the MXF format with its flexible structure it is more relevant to know the muxing library rather than the hosting application. Have seen MXF output files of other commercial products that also contain library identifiers like "libMXF" or "MXFtk" here. Other formats in FFmpeg use the "encoder" metadata key for embedding library information in the output file. A quick test with AVI output shows that this metadata is generated internally and cannot be overridden on the command-line. If your concern is being able to identify our mxf muxer, then why not use the Platform metadata item for this? "Human readable name of the toolkit and operating system used. Best practice is to use the form “SDK name (OS name)”" Seems a lot more fitting than the other metadata fields for the purpose of muxer identification. 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".
[FFmpeg-devel] [PATCH 1/3] avformat/asfdec_o: Check for EOF in asf_read_marker()
Fixes: Timeout Fixes: 26460/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-5710884393189376 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/asfdec_o.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c index 6ce5a3fb43..3729adee2f 100644 --- a/libavformat/asfdec_o.c +++ b/libavformat/asfdec_o.c @@ -245,6 +245,9 @@ static int asf_read_marker(AVFormatContext *s, const GUIDParseTable *g) avio_skip(pb, 4); // flags len = avio_rl32(pb); +if (avio_feof(pb)) +return AVERROR_INVALIDDATA; + if ((ret = avio_get_str16le(pb, len, name, sizeof(name))) < len) avio_skip(pb, len - ret); -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/asfdec_o: Check size vs. offset in detect_unknown_subobject()
On Tue, Jan 12, 2021 at 10:51:13PM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 2314885530818453566 + 7503032301549264928 > cannot be represented in type 'long' > Fixes: > 26639/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6024222100684800 > > Alternatively this could be ignored but then the end condition of the loop > would be hard to reach as avio_tell() is int64_t > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/asfdec_o.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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 3/3] avformat/paf: Check for EOF before allocation in read_header()
Fixes: OOM Fixes: 26584/clusterfuzz-testcase-minimized-ffmpeg_dem_PAF_fuzzer-5172661183053824 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/paf.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/paf.c b/libavformat/paf.c index bcd6213a45..23ad4bf41f 100644 --- a/libavformat/paf.c +++ b/libavformat/paf.c @@ -136,6 +136,10 @@ static int read_header(AVFormatContext *s) p->start_offset = avio_rl32(pb); p->max_video_blks = avio_rl32(pb); p->max_audio_blks = avio_rl32(pb); + +if (avio_feof(pb)) +return AVERROR_INVALIDDATA; + if (p->buffer_size< 175 || p->max_audio_blks < 2|| p->max_video_blks < 1|| -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avformat/paf: Do not zero allocated tables which are immedeately filled
Signed-off-by: Michael Niedermayer --- libavformat/paf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavformat/paf.c b/libavformat/paf.c index 9587111643..bcd6213a45 100644 --- a/libavformat/paf.c +++ b/libavformat/paf.c @@ -149,11 +149,11 @@ static int read_header(AVFormatContext *s) p->frame_blks > INT_MAX / sizeof(uint32_t)) return AVERROR_INVALIDDATA; -p->blocks_count_table = av_mallocz(p->nb_frames * +p->blocks_count_table = av_malloc(p->nb_frames * sizeof(*p->blocks_count_table)); -p->frames_offset_table = av_mallocz(p->nb_frames * +p->frames_offset_table = av_malloc(p->nb_frames * sizeof(*p->frames_offset_table)); -p->blocks_offset_table = av_mallocz(p->frame_blks * +p->blocks_offset_table = av_malloc(p->frame_blks * sizeof(*p->blocks_offset_table)); p->video_size = p->max_video_blks * p->buffer_size; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavdevice: Add KMS/DRM output device
On Tue, 19 Jan 2021, Anton Khirnov wrote: Quoting Mark Thompson (2021-01-19 00:37:09) On 16/01/2021 22:12, Nicolas Caramelli wrote: > This patch adds KMS/DRM output device for rendering a video stream > using KMS/DRM dumb buffer. > The proposed implementation is very basic, only bgr0 pixel format is > currently supported (the most common format with KMS/DRM). > To enable this output device you need to configure FFmpeg with --enable-libdrm. > Example: ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0 If you want to render things to a normal display device why not use a normal video player? Or even ffplay? IMO something like this would be of more value as a simple video player example with the documentation rather than including it as weirdly constrained library code which will see very little use. (Note that I would argue against adding more general display output devices which are already present, like fb and xv, because they are of essentially no value to libavdevice users. Removing legacy code is harder, though.) +1 IMO libavdevice output devices are worse than useless and should all be removed. Decklink is heavily used for both input and output. 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] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On Wed, Jan 20, 2021 at 12:19 AM Derek Buitenhuis wrote: > > On 19/01/2021 09:21, Hongyi Zhao wrote: > > libavfilter/vf_nnedi.c: At top level: > > libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’ > > 819 | static void read(float *dst, size_t n, const float **data) > > I thought this might happen when I saw it go in. > > We shouldn't be naming functions things that clash with standard POSIX > or stdlib functions like 'read'. I didn't make any changes to the source code, so how to fix the problem? Best, -- Assoc. Prof. Hongyi Zhao Theory and Simulation of Materials Hebei Polytechnic University of Science and Technology engineering NO. 552 North Gangtie Road, Xingtai, China ___ 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] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On 1/19/2021 11:24 PM, Hongyi Zhao wrote: On Wed, Jan 20, 2021 at 12:19 AM Derek Buitenhuis wrote: On 19/01/2021 09:21, Hongyi Zhao wrote: libavfilter/vf_nnedi.c: At top level: libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’ 819 | static void read(float *dst, size_t n, const float **data) I thought this might happen when I saw it go in. We shouldn't be naming functions things that clash with standard POSIX or stdlib functions like 'read'. I didn't make any changes to the source code, so how to fix the problem? Best, It was already fixed in f3f5ba0bf8, so simply pull the latest changes. ___ 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: add librist protocol
Hello Paul,
In the librist_read function, you must call the new API
called rist_receiver_data_block_free to free the buffer
when you are done using it.
I am not sure if ffmpeg supports a custom callback for
freeing a buffer. If it does, you could actually use the
rist buffer as a reference as long as you call the custom
free function when you are done, i.e. zero copy.
Regards,
Sergio
On Tue, 2021-01-19 at 13:01 +0100, Paul B Mahol wrote:
> This work is sponsored by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi | 32 +
> libavformat/Makefile| 1 +
> libavformat/librist.c | 250
> libavformat/protocols.c | 1 +
> 5 files changed, 289 insertions(+)
> create mode 100644 libavformat/librist.c
>
> diff --git a/configure b/configure
> index 54fbbd6b5f..ad3171bfbc 100755
> --- a/configure
> +++ b/configure
> @@ -259,6 +259,7 @@ External library support:
>--enable-libpulseenable Pulseaudio input via libpulse [no]
>--enable-librabbitmq enable RabbitMQ library [no]
>--enable-librav1eenable AV1 encoding via rav1e [no]
> + --enable-librist enable RIST via librist [no]
>--enable-librsvg enable SVG rasterization via librsvg [no]
>--enable-librubberband enable rubberband needed for rubberband filter
> [no]
>--enable-librtmp enable RTMP[E] support via librtmp [no]
> @@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
> libpulse
> librabbitmq
> librav1e
> +librist
> librsvg
> librtmp
> libshine
> @@ -3490,6 +3492,8 @@ unix_protocol_select="network"
> # external library protocols
> libamqp_protocol_deps="librabbitmq"
> libamqp_protocol_select="network"
> +librist_protocol_deps="librist"
> +librist_protocol_select="network"
> librtmp_protocol_deps="librtmp"
> librtmpe_protocol_deps="librtmp"
> librtmps_protocol_deps="librtmp"
> @@ -6409,6 +6413,7 @@ enabled libopus && {
> enabled libpulse && require_pkg_config libpulse libpulse
> pulse/pulseaudio.h pa_context_new
> enabled librabbitmq && require_pkg_config librabbitmq "librabbitmq >=
> 0.7.1" amqp.h amqp_new_connection
> enabled librav1e && require_pkg_config librav1e "rav1e >= 0.4.0"
> rav1e.h rav1e_context_new
> +enabled librist && require_pkg_config librist "librist >= 0.2"
> librist/librist.h rist_receiver_create
> enabled librsvg && require_pkg_config librsvg librsvg-2.0
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
> enabled librtmp && require_pkg_config librtmp librtmp
> librtmp/rtmp.h RTMP_Socket
> enabled librubberband && require_pkg_config librubberband "rubberband >=
> 1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append
> librubberband_extralibs "-lstdc++"
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index c0b511b7a4..3160f846ff 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -690,6 +690,38 @@ Example usage:
> -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
> @end example
>
> +@section rist
> +
> +Reliable Internet Streaming Transport protocol
> +
> +The accepted options are:
> +@table @option
> +@item rist_profile
> +Supported values:
> +@table @samp
> +@item simple
> +@item main
> +This one is default.
> +@item advanced
> +@end table
> +
> +@item buffer_size
> +Set internal RIST buffer size for retransmission of data.
> +
> +@item pkt_size
> +Set internal RIST buffer size for receiving and sending data.
> +
> +@item log_level
> +Set loglevel for RIST logging messages.
> +
> +@item secret
> +Set override of encryption secret, by default is unset.
> +
> +@item encryption
> +Set encryption type, by default is disabled.
> +Acceptable values are 128 and 256.
> +@end table
> +
> @section rtmp
>
> Real-Time Messaging Protocol.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 3a8fbcbe5f..85f432c8d9 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
>
> # external library protocols
> OBJS-$(CONFIG_LIBAMQP_PROTOCOL) += libamqp.o
> +OBJS-$(CONFIG_LIBRIST_PROTOCOL) += librist.o
> OBJS-$(CONFIG_LIBRTMP_PROTOCOL) += librtmp.o
> OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
> OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
> diff --git a/libavformat/librist.c b/libavformat/librist.c
> new file mode 100644
> index 00..724247e74c
> --- /dev/null
> +++ b/libavformat/librist.c
> @@ -0,0 +1,250 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmp
Re: [FFmpeg-devel] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On Wed, Jan 20, 2021 at 10:52 AM James Almer wrote: > > On 1/19/2021 11:24 PM, Hongyi Zhao wrote: > > On Wed, Jan 20, 2021 at 12:19 AM Derek Buitenhuis > > wrote: > >> > >> On 19/01/2021 09:21, Hongyi Zhao wrote: > >>> libavfilter/vf_nnedi.c: At top level: > >>> libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’ > >>>819 | static void read(float *dst, size_t n, const float **data) > >> > >> I thought this might happen when I saw it go in. > >> > >> We shouldn't be naming functions things that clash with standard POSIX > >> or stdlib functions like 'read'. > > > > I didn't make any changes to the source code, so how to fix the problem? > > > > Best, > > It was already fixed in f3f5ba0bf8, so simply pull the latest changes. But I still meet the following problem: make: *** [ffbuild/common.mak:67: libavutil/hwcontext_vulkan.o] Error 1 Best regards, -- Assoc. Prof. Hongyi Zhao Theory and Simulation of Materials Hebei Polytechnic University of Science and Technology engineering NO. 552 North Gangtie Road, Xingtai, China ___ 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] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On 1/20/2021 12:29 AM, Hongyi Zhao wrote: On Wed, Jan 20, 2021 at 10:52 AM James Almer wrote: On 1/19/2021 11:24 PM, Hongyi Zhao wrote: On Wed, Jan 20, 2021 at 12:19 AM Derek Buitenhuis wrote: On 19/01/2021 09:21, Hongyi Zhao wrote: libavfilter/vf_nnedi.c: At top level: libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’ 819 | static void read(float *dst, size_t n, const float **data) I thought this might happen when I saw it go in. We shouldn't be naming functions things that clash with standard POSIX or stdlib functions like 'read'. I didn't make any changes to the source code, so how to fix the problem? Best, It was already fixed in f3f5ba0bf8, so simply pull the latest changes. But I still meet the following problem: make: *** [ffbuild/common.mak:67: libavutil/hwcontext_vulkan.o] Error 1 Best regards, That line alone is not very descriptive of the compilation issue you're experiencing. This is in any case not the correct list to report this kind of problem. Either ask in ffmpeg-user, or open a ticket in https://trac.ffmpeg.org/ with a more detailed explanation of the problem. ___ 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] make: *** [ffbuild/common.mak:67: libavfilter/vf_nnedi.o] Error 1
On Wed, Jan 20, 2021 at 11:32 AM James Almer wrote:
>
> On 1/20/2021 12:29 AM, Hongyi Zhao wrote:
> > On Wed, Jan 20, 2021 at 10:52 AM James Almer wrote:
> >>
> >> On 1/19/2021 11:24 PM, Hongyi Zhao wrote:
> >>> On Wed, Jan 20, 2021 at 12:19 AM Derek Buitenhuis
> >>> wrote:
>
> On 19/01/2021 09:21, Hongyi Zhao wrote:
> > libavfilter/vf_nnedi.c: At top level:
> > libavfilter/vf_nnedi.c:819:13: error: conflicting types for ‘read’
> > 819 | static void read(float *dst, size_t n, const float **data)
>
> I thought this might happen when I saw it go in.
>
> We shouldn't be naming functions things that clash with standard POSIX
> or stdlib functions like 'read'.
> >>>
> >>> I didn't make any changes to the source code, so how to fix the problem?
> >>>
> >>> Best,
> >>
> >> It was already fixed in f3f5ba0bf8, so simply pull the latest changes.
> >
> > But I still meet the following problem:
> >
> > make: *** [ffbuild/common.mak:67: libavutil/hwcontext_vulkan.o] Error 1
> >
> > Best regards,
>
> That line alone is not very descriptive of the compilation issue you're
> experiencing.
>
> This is in any case not the correct list to report this kind of problem.
> Either ask in ffmpeg-user, or open a ticket in https://trac.ffmpeg.org/
> with a more detailed explanation of the problem.
I cont'd with this issue and cc'ed it to ffmpeg-user as shown below:
$ make
[...]
libavutil/hwcontext_vulkan.c:3273:11: note: in expansion of macro ‘CHECK_CU’
3273 | ret =
CHECK_CU(cu->cuWaitExternalSemaphoresAsync(dst_int->cu_sem, s_w_par,
| ^~~~
libavutil/cuda_check.h:32:39: note: expected ‘void *’ but argument is
of type ‘CUresult (*)(CUresult, const char **)’ {aka ‘enum
cudaError_enum (*)(enum cudaError_enum, const char **)’}
32 | void *cuGetErrorName_fn, void
*cuGetErrorString_fn,
| ~~^
libavutil/cuda_check.h:64:93: warning: ISO C forbids passing argument
3 of ‘ff_cuda_check’ between function pointer and ‘void *’
[-Wpedantic]
64 | A_CHECK_DL(avclass, cudl, x) ff_cuda_check(avclass,
cudl->cuGetErrorName, cudl->cuGetErrorString, (x), #x)
libavutil/hwcontext_vulkan.c:41:21: note: in expansion of macro
‘FF_CUDA_CHECK_DL’
41 | #define CHECK_CU(x) FF_CUDA_CHECK_DL(cuda_cu, cu, x)
| ^~~~
libavutil/hwcontext_vulkan.c:3273:11: note: in expansion of macro ‘CHECK_CU’
3273 | ret =
CHECK_CU(cu->cuWaitExternalSemaphoresAsync(dst_int->cu_sem, s_w_par,
| ^~~~
libavutil/cuda_check.h:32:64: note: expected ‘void *’ but argument is
of type ‘CUresult (*)(CUresult, const char **)’ {aka ‘enum
cudaError_enum (*)(enum cudaError_enum, const char **)’}
32 | void *cuGetErrorName_fn, void
*cuGetErrorString_fn,
|
~~^~~
libavutil/cuda_check.h:64:71: warning: ISO C forbids passing argument
2 of ‘ff_cuda_check’ between function pointer and ‘void *’
[-Wpedantic]
64 | #define FF_CUDA_CHECK_DL(avclass, cudl, x)
ff_cuda_check(avclass, cudl->cuGetErrorName, cudl->cuGetErrorString,
(x), #x)
libavutil/hwcontext_vulkan.c:41:21: note: in expansion of macro
‘FF_CUDA_CHECK_DL’
41 | #define CHECK_CU(x) FF_CUDA_CHECK_DL(cuda_cu, cu, x)
| ^~~~
libavutil/hwcontext_vulkan.c:3297:15: note: in expansion of macro ‘CHECK_CU’
3297 | ret = CHECK_CU(cu->cuMemcpy2DAsync(&cpy, cuda_dev->stream));
| ^~~~
libavutil/cuda_check.h:32:39: note: expected ‘void *’ but argument is
of type ‘CUresult (*)(CUresult, const char **)’ {aka ‘enum
cudaError_enum (*)(enum cudaError_enum, const char **)’}
32 | void *cuGetErrorName_fn, void
*cuGetErrorString_fn,
| ~~^
libavutil/cuda_check.h:64:93: warning: ISO C forbids passing argument
3 of ‘ff_cuda_check’ between function pointer and ‘void *’
[-Wpedantic]
64 | A_CHECK_DL(avclass, cudl, x) ff_cuda_check(avclass,
cudl->cuGetErrorName, cudl->cuGetErrorString, (x), #x)
libavutil/hwcontext_vulkan.c:41:21: note: in expansion of macro
‘FF_CUDA_CHECK_DL’
41 | #define CHECK_CU(x) FF_CUDA_CHECK_DL(cuda_cu, cu, x)
| ^~~~
libavutil/hwcontext_vulkan.c:3297:15: note: in expansion of macro ‘CHECK_CU’
3297 | ret = CHECK_CU(cu->cuMemcpy2DAsync(&cpy, cuda_dev->stream));
| ^~~~
libavutil/cuda_check.h:32:64: note: expected ‘void *’ but argument is
of type ‘CUresult (*)(CUresult, const char **)’ {aka ‘enum
cudaError_enum (*)(enum cudaError_enum, const char **)’}
32 | void *cuGetErrorName_fn, void
*cuGetErrorString_fn,
|
~~^~~
libavutil/cuda_check.h:64:71: warning: ISO C forbids passing argument
2 of ‘ff_cuda_check’ between function pointer and ‘void *’
[-Wpedantic]
64
