Re: [FFmpeg-devel] [PATCH 1/3] avcodec/exr: fix undefined shift in pxr24_uncompress()
On 11/4/17, Michael Niedermayer wrote:
> Fixes: runtime error: left shift of 255 by 24 places cannot be represented
> in type 'int'
> Fixes: 3787/clusterfuzz-testcase-minimized-5728764920070144
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/exr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 0b755db3cb..b1ecde4ebd 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -855,7 +855,7 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t
> *src,
> in = ptr[2] + td->xsize;
>
> for (j = 0; j < td->xsize; ++j) {
> -uint32_t diff = (*(ptr[0]++) << 24) |
> +uint32_t diff = ((unsigned)*(ptr[0]++) << 24) |
> (*(ptr[1]++) << 16) |
> (*(ptr[2]++) << 8);
> pixel += diff;
> --
> 2.15.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/alac: Avoid allocating huge memory blocks for malicious alac input.
On 11/4/17, Carl Eugen Hoyos wrote: > 2017-11-01 17:03 GMT+01:00 Carl Eugen Hoyos : >> 2017-11-01 17:01 GMT+01:00 Paul B Mahol : >>> On 11/1/17, Carl Eugen Hoyos wrote: 2017-11-01 15:40 GMT+01:00 Paul B Mahol : > On 11/1/17, Carl Eugen Hoyos wrote: >> Hi! >> >> It appears to me that the alac decoder can be used for DoS, >> the attached patch limits the maximum frame size to eight >> times the default value. >> (Higher values brake our encoder here.) >> >> Please comment and / or suggest another value, Carl Eugen >> > > So alac encoder can not handle bigger frames or what? > > Look at other alac encoders, what are their limit on frame size? I am not sure if it is enough to look on Apple's encoder, after all, their decoder looks exploitable (or maybe I miss something). > The limit you set is too low IMHO. Could you suggest a limit that's below the several-GB area? >>> >>> I remmeber some lossless audio codecs can have very big >>> frames, several MB. >> >> So what about 4096 * 4096 as an arbitrary limit? > > Any opinion? ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add TiVo ty demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/ty.c | 765 +++
3 files changed, 767 insertions(+)
create mode 100644 libavformat/ty.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index caebe5b146..045200e882 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -490,6 +490,7 @@ OBJS-$(CONFIG_TRUEHD_MUXER) += rawenc.o
OBJS-$(CONFIG_TTA_DEMUXER) += tta.o apetag.o img2.o
OBJS-$(CONFIG_TTA_MUXER) += ttaenc.o apetag.o img2.o
OBJS-$(CONFIG_TTY_DEMUXER) += tty.o sauce.o
+OBJS-$(CONFIG_TY_DEMUXER)+= ty.o
OBJS-$(CONFIG_TXD_DEMUXER) += txd.o
OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
OBJS-$(CONFIG_V210_DEMUXER) += v210.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5ad9..3f72a566eb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -320,6 +320,7 @@ static void register_all(void)
REGISTER_MUXDEMUX(TTA, tta);
REGISTER_DEMUXER (TXD, txd);
REGISTER_DEMUXER (TTY, tty);
+REGISTER_DEMUXER (TY, ty);
REGISTER_MUXER (UNCODEDFRAMECRC, uncodedframecrc);
REGISTER_DEMUXER (V210, v210);
REGISTER_DEMUXER (V210X,v210x);
diff --git a/libavformat/ty.c b/libavformat/ty.c
new file mode 100644
index 00..bd871cba2e
--- /dev/null
+++ b/libavformat/ty.c
@@ -0,0 +1,765 @@
+/*
+ * TiVo ty stream demuxer
+ * Copyright (c) 2005 VLC authors and VideoLAN
+ * Copyright (c) 2005 by Neal Symms (t...@freakinzoo.com) - February 2005
+ * based on code by Christopher Wingert for tivo-mplayer
+ * tivo(at)wingert.org, February 2003
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "internal.h"
+#include "mpeg.h"
+
+#define SERIES1_PES_LENGTH 11/* length of audio PES hdr on S1 */
+#define SERIES2_PES_LENGTH 16/* length of audio PES hdr on S2 */
+#define AC3_PES_LENGTH 14/* length of audio PES hdr for AC3 */
+#define VIDEO_PES_LENGTH16/* length of video PES header */
+#define DTIVO_PTS_OFFSET6 /* offs into PES for MPEG PTS on DTivo */
+#define SA_PTS_OFFSET 9 /* offset into PES for MPEG PTS on SA */
+#define AC3_PTS_OFFSET 9 /* offset into PES for AC3 PTS on DTivo */
+#define VIDEO_PTS_OFFSET9 /* offset into PES for video PTS on all */
+#define AC3_PKT_LENGTH 1536 /* size of TiVo AC3 pkts (w/o PES hdr) */
+
+static const uint8_t ty_VideoPacket[] = { 0x00, 0x00, 0x01, 0xe0 };
+static const uint8_t ty_MPEGAudioPacket[] = { 0x00, 0x00, 0x01, 0xc0 };
+static const uint8_t ty_AC3AudioPacket[] = { 0x00, 0x00, 0x01, 0xbd };
+
+#define TIVO_PES_FILEID 0xf5467abd
+#define CHUNK_SIZE(128 * 1024)
+#define CHUNK_PEEK_COUNT 3 /* number of chunks to probe */
+
+typedef struct TyRecHdr {
+int64_t rec_size;
+uint8_t ex[2];
+uint8_t rec_type;
+uint8_t subrec_type;
+uint64_t ty_pts;/* TY PTS in the record header */
+} TyRecHdr;
+
+typedef enum {
+TIVO_TYPE_UNKNOWN,
+TIVO_TYPE_SA,
+TIVO_TYPE_DTIVO
+} TiVo_type;
+
+typedef enum {
+TIVO_SERIES_UNKNOWN,
+TIVO_SERIES1,
+TIVO_SERIES2
+} TiVo_series;
+
+typedef enum {
+TIVO_AUDIO_UNKNOWN,
+TIVO_AUDIO_AC3,
+TIVO_AUDIO_MPEG
+} TiVo_audio;
+
+typedef struct TySeqTable {
+uint64_ttimestamp;
+uint8_t chunk_bitmask[8];
+} TySeqTable;
+
+typedef struct TYDemuxContext {
+unsignedcur_chunk;
+unsignedcur_chunk_pos;
+int64_t cur_pos;
+TiVo_type tivo_type;/* TiVo type (SA / DTiVo) */
+TiVo_series tivo_series; /* Series1 or Series2 */
+TiVo_audio audio_type; /* AC3 or MPEG */
+int pes_length; /* Length of Audio PES header */
+int pts_offset; /* offset into audio PES of PTS */
+uint8_t pes_buffer[20]; /* holds incomplete pes headers */
+int pe
Re: [FFmpeg-devel] [PATCH] avformat/dv : change audio format endianess to BE
On Fri, Nov 03, 2017 at 05:44:28PM -0800, Lou Logan wrote: > On Fri, Nov 3, 2017, at 04:49 PM, Michael Niedermayer wrote: > > This does not explain why this change is done. > > does it fix a bug? > > does it make the code faster? > > ffmbc uses BE too, but I'm ignorant as to why it does. If BE is the expected output by most DV users (is it ?) then this should be mentioned in the commit message. Otherwise most people looking at this commit in the future will not have a clue why it was changed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()
On Sun, 29 Oct 2017 21:45:04 +0100 Peter Große wrote: > On Sun, 29 Oct 2017 21:33:10 +0100 > Michael Niedermayer wrote: > > > seems this doesnt apply > > > > Yeah, it depends on the patch I started the thread with. > > I can swap the order of the two patches if you want, so that the > style fix can go in first. But they will depend on each other either way, > since their contexts overlap. Which one do you prefer? Regards Peter pgplZ2OUs77IG.pgp Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Maintainers : add myself for exr
Hello, Following Michael Niedermayer request, patch in attach to add myself for exr decoder Martin 0001-Maintainers-add-myself-for-exr.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat: LibreSSL (libtls) support
Attached patch adds support for LibreSSL. Instead of trying to implement support into the existing tls_openssl.c using lots of #ifdefs (which was rejected previously(?)) this adds a new TLS backend making use of the new libtls library. Things to note: - Haven't looked at LibreSSL's license closely, I assume that it has the same GPL licensing incompatibility as a derivative of OpenSSL (requires --enable-nonfree if --enable-gpl is used) - ffrtmpcrypt support is not implemented since the bignum functions are not part of libtls itself - Not sure why anyone would use libtls without pkg-config but supporting it probably doesn't hurt I have tested all features (client mode, listen mode, cert/hostname verification) on both Alpine and Arch Linux. Before michaelni asks again: Yes, the absence of my real name in git is intended. From d4336b0733a1e582d7bf30795bf99df4cc60d7df Mon Sep 17 00:00:00 2001 From: sfan5 Date: Sat, 4 Nov 2017 15:45:16 +0100 Subject: [PATCH] libavformat: LibreSSL (libtls) support Signed-off-by: sfan5 --- Changelog| 1 + configure| 16 ++-- doc/protocols.texi | 2 +- libavformat/Makefile | 1 + libavformat/tls_libtls.c | 207 +++ 5 files changed, 221 insertions(+), 6 deletions(-) create mode 100644 libavformat/tls_libtls.c diff --git a/Changelog b/Changelog index 8c45b2946d..bd37971af5 100644 --- a/Changelog +++ b/Changelog @@ -7,6 +7,7 @@ version : requires 2.1 (or later) and pkg-config. - VDA dropped (use VideoToolbox instead) - MagicYUV encoder +- support LibreSSL (via libtls) version 3.4: diff --git a/configure b/configure index 1b0f064607..2938be7b07 100755 --- a/configure +++ b/configure @@ -215,7 +215,7 @@ External library support: --enable-gmp enable gmp, needed for rtmp(t)e support if openssl or librtmp is not used [no] --enable-gnutls enable gnutls, needed for https support - if openssl is not used [no] + if openssl or libtls is not used [no] --disable-iconv disable iconv [autodetect] --enable-jni enable JNI support [no] --enable-ladspa enable LADSPA audio filtering [no] @@ -260,6 +260,8 @@ External library support: --enable-libssh enable SFTP protocol via libssh [no] --enable-libtesseractenable Tesseract, needed for ocr filter [no] --enable-libtheora enable Theora encoding via libtheora [no] + --enable-libtls enable LibreSSL (via libtls), needed for https support + if openssl or gnutls is not used [no] --enable-libtwolame enable MP2 encoding via libtwolame [no] --enable-libv4l2 enable libv4l2/v4l-utils [no] --enable-libvidstab enable video stabilization using vid.stab [no] @@ -292,7 +294,7 @@ External library support: --enable-opencl enable OpenCL code --enable-opengl enable OpenGL rendering [no] --enable-openssl enable openssl, needed for https support - if gnutls is not used [no] + if gnutls or libtls is not used [no] --disable-sndio disable sndio support [autodetect] --disable-schannel disable SChannel SSP, needed for TLS support on Windows if openssl and gnutls are not used [autodetect] @@ -1563,6 +1565,7 @@ EXTERNAL_LIBRARY_NONFREE_LIST=" libndi_newtek libfdk_aac openssl +libtls " EXTERNAL_LIBRARY_VERSION3_LIST=" @@ -3135,6 +3138,7 @@ librtmpt_protocol_deps="librtmp" librtmpte_protocol_deps="librtmp" libsmbclient_protocol_deps="libsmbclient gplv3" libssh_protocol_deps="libssh" +libtls_conflict="openssl gnutls" mmsh_protocol_select="http_protocol" mmst_protocol_select="network" rtmp_protocol_conflict="librtmp_protocol" @@ -3152,13 +3156,13 @@ rtmpte_protocol_suggest="zlib" rtmpts_protocol_select="ffrtmphttp_protocol https_protocol" rtmpts_protocol_suggest="zlib" rtp_protocol_select="udp_protocol" -schannel_conflict="openssl gnutls" +schannel_conflict="openssl gnutls libtls" sctp_protocol_deps="struct_sctp_event_subscribe struct_msghdr_msg_flags" sctp_protocol_select="network" -securetransport_conflict="openssl gnutls" +securetransport_conflict="openssl gnutls libtls" srtp_protocol_select="rtp_protocol srtp" tcp_protocol_select="network" -tls_protocol_deps_any="gnutls openssl schannel securetransport" +tls_protocol_deps_any="gnutls openssl schannel securetransport libtls" tls_protocol_select="tcp_protocol" udp_protocol_select="network" udplite_protocol_select="network" @@ -6009,6 +6013,8 @@ enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h sftp enabled libspeex && require_pkg_config libspeex speex speex/speex.h speex_decoder_init -lspeex enabled libtesseract && require_pkg_config libtesseract tesseract tesseract/ca
Re: [FFmpeg-devel] [PATCH]lavc/alac: Avoid allocating huge memory blocks for malicious alac input.
2017-11-04 10:23 GMT+01:00 Paul B Mahol : > On 11/4/17, Carl Eugen Hoyos wrote: >> 2017-11-01 17:03 GMT+01:00 Carl Eugen Hoyos : >>> 2017-11-01 17:01 GMT+01:00 Paul B Mahol : On 11/1/17, Carl Eugen Hoyos wrote: > 2017-11-01 15:40 GMT+01:00 Paul B Mahol : >> On 11/1/17, Carl Eugen Hoyos wrote: >>> Hi! >>> >>> It appears to me that the alac decoder can be used for DoS, >>> the attached patch limits the maximum frame size to eight >>> times the default value. >>> (Higher values brake our encoder here.) >>> >>> Please comment and / or suggest another value, Carl Eugen >>> >> >> So alac encoder can not handle bigger frames or what? >> >> Look at other alac encoders, what are their limit on frame size? > > I am not sure if it is enough to look on Apple's encoder, after > all, their decoder looks exploitable (or maybe I miss something). > >> The limit you set is too low IMHO. > > Could you suggest a limit that's below the several-GB area? I remmeber some lossless audio codecs can have very big frames, several MB. >>> >>> So what about 4096 * 4096 as an arbitrary limit? >> >> Any opinion? > > ok Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/template_head2: Prevent battleforthenet widget to show again after being clicked away
Also ensure that the widget does not use google analytics. Iam not sure it actually did before, my box has too many layers that stop this. Signed-off-by: Michael Niedermayer --- src/template_head2 | 22 ++ 1 file changed, 22 insertions(+) diff --git a/src/template_head2 b/src/template_head2 index d7bb7bd..71daf07 100644 --- a/src/template_head2 +++ b/src/template_head2 @@ -3,6 +3,28 @@
Re: [FFmpeg-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.
On 11/3/2017 6:23 PM, Kieran Kunhya wrote:
> This patch fixes very high memory usage on pathological streams.
[...]
> -H2645Packet pkt = { 0 };
> +H2645Packet pkt;
> +memset(&pkt, 0, sizeof(pkt));
Stray unrelated change.
Rest seems reasonable from a cursory glance. I assume it's
been run with ASAN or whatever + FATE, and valgrind.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.
On 11/4/2017 2:52 PM, Derek Buitenhuis wrote:
> On 11/3/2017 6:23 PM, Kieran Kunhya wrote:
>> This patch fixes very high memory usage on pathological streams.
>
> [...]
>
>> -H2645Packet pkt = { 0 };
>> +H2645Packet pkt;
>> +memset(&pkt, 0, sizeof(pkt));
>
> Stray unrelated change.
Yed, it's both unnecessary and will raise a warning about mixed
declaration and code.
>
> Rest seems reasonable from a cursory glance. I assume it's
> been run with ASAN or whatever + FATE, and valgrind.
I ran it with asan, using one and four threads. No reported failures or
leaks.
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.
On Sat, 6 May 2017 at 17:51 James Almer wrote: > The proper change here would be to look at the uuid and print only those > known to store printable strings, and of course after making sure they > are in fact printable. > As of now, that means x264's uuid only. > The UUID can be corrupt as well. We shouldn't be printing random data from the bitstream to the users terminal. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.
On Sat, Nov 04, 2017 at 06:23:12PM +, Kieran Kunhya wrote: > On Sat, 6 May 2017 at 17:51 James Almer wrote: > > > The proper change here would be to look at the uuid and print only those > > known to store printable strings, and of course after making sure they > > are in fact printable. > > As of now, that means x264's uuid only. > > > > The UUID can be corrupt as well. > We shouldn't be printing random data from the bitstream to the users > terminal. i agree [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffplay: create the window and the renderer before starting playback
On Sun, 29 Oct 2017, Marton Balint wrote:
On Sat, 28 Oct 2017, Clément Bœsch wrote:
On Sat, Oct 28, 2017 at 11:05:15PM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 67
+---
1 file changed, 35 insertions(+), 32 deletions(-)
Won't this prevent using ffplay without a display? Think of playing audio
with ffplay on a headless machine (no display server).
No, for that, the user have to use -nodisp, and it should work the
same way as before, because the window/renderer creating code is in an if
(!display_disable) {...} block.
Applied the series.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/huffyuvdsp(enc) : add avx2 version for add(diff)_int16
2017-10-22 0:26 GMT+02:00 Martin Vignali : > Hello, > > In attach patch to add avx2 version for huffyuv dsp and huffyuvdsp enc > for add_int16 and diff_int16 func > > Check asm result for add_int16 (Kaby Lake, os 10.12) > add_int16_128_c: 1607.9 > add_int16_128_sse2: 442.7 > add_int16_128_avx2: 218.9 > > Pass fate test for me > > > 0001-checkasm-add-test-for-huffyuvdsp-add_int16 : > add a checkasm test for add_int16 > base on lossless_videodsp checkasm test > > i add a test with a fix size, to make speed test more easy to compare > > 0002-libavcodec-huffyuvdsp-enc-move-duplicate-macro-to-a- > huffyuvdsp.asm and huffyuvdspenc.asm use the same INT16_LOOP macro > with arg add for dec and sub for encoder > > this patch move this macro in an asm file in order to be share by both dsp > asm > > 0003-libavcodec-huffyuvdsp-reorganize-add_int16-asm > 0005-libavcodec-huffyuvdspenc-reorganize-diff_int16 > Code reorganization > > > 0004-libavcodec-huffyuvdsp-add-add_int16-AVX2-func > 0006-libavcodec-huffyuvdspenc-add-diff_int16-AVX2-func > AVX2 version for each func > > > > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/utvideodsp : add avx2 version
2017-10-25 21:53 GMT+02:00 Martin Vignali : > > > 2017-10-22 14:05 GMT+02:00 Martin Vignali : > >> Hello, >> >> In attach patch to add AVX2 version for the utvideodsp >> >> Checkasm result (Kaby Lake, os 10.12) >> restore_rgb_planes_c: 8371.0 >> restore_rgb_planes_sse2: 6583.7 >> restore_rgb_planes_avx2: 3596.5 >> >> restore_rgb_planes10_c: 16735.7 >> restore_rgb_planes10_sse2: 11478.5 >> restore_rgb_planes10_avx2: 7193.7 >> >> >> Pass fate test for me >> >> >> 0001-checkasm-add-utvideodsp-test : >> I'm not entirely sure of mine, for this checkasm, >> >> 0002-libavcodec-x86-utvideodsp-make-macro-for-func >> Code reorganization >> >> 0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp >> AVX2 version >> >> 0004-libavcodec-x86-utvideodsp.asm-cosmetic >> Cosmetic >> >> > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffplay: use SDL2 audio API
It allows us to specify what kind of audio parameter changes are allowed.
Should fix ticket #6721.
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index c264e92535..bd1457c7e3 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -362,6 +362,7 @@ static AVPacket flush_pkt;
static SDL_Window *window;
static SDL_Renderer *renderer;
static SDL_RendererInfo renderer_info = {0};
+static SDL_AudioDeviceID audio_dev;
static const struct TextureFormatEntry {
enum AVPixelFormat format;
@@ -1192,7 +1193,7 @@ static void stream_component_close(VideoState *is, int
stream_index)
switch (codecpar->codec_type) {
case AVMEDIA_TYPE_AUDIO:
decoder_abort(&is->auddec, &is->sampq);
-SDL_CloseAudio();
+SDL_CloseAudioDevice(audio_dev);
decoder_destroy(&is->auddec);
swr_free(&is->swr_ctx);
av_freep(&is->audio_buf1);
@@ -2451,7 +2452,7 @@ static void sdl_audio_callback(void *opaque, Uint8
*stream, int len)
else {
memset(stream, 0, len1);
if (!is->muted && is->audio_buf)
-SDL_MixAudio(stream, (uint8_t *)is->audio_buf +
is->audio_buf_index, len1, is->audio_volume);
+SDL_MixAudioFormat(stream, (uint8_t *)is->audio_buf +
is->audio_buf_index, AUDIO_S16SYS, len1, is->audio_volume);
}
len -= len1;
stream += len1;
@@ -2496,7 +2497,7 @@ static int audio_open(void *opaque, int64_t
wanted_channel_layout, int wanted_nb
wanted_spec.samples = FFMAX(SDL_AUDIO_MIN_BUFFER_SIZE, 2 <<
av_log2(wanted_spec.freq / SDL_AUDIO_MAX_CALLBACKS_PER_SEC));
wanted_spec.callback = sdl_audio_callback;
wanted_spec.userdata = opaque;
-while (SDL_OpenAudio(&wanted_spec, &spec) < 0) {
+while (!(audio_dev = SDL_OpenAudioDevice(NULL, 0, &wanted_spec, &spec,
SDL_AUDIO_ALLOW_FREQUENCY_CHANGE | SDL_AUDIO_ALLOW_CHANNELS_CHANGE))) {
av_log(NULL, AV_LOG_WARNING, "SDL_OpenAudio (%d channels, %d Hz):
%s\n",
wanted_spec.channels, wanted_spec.freq, SDL_GetError());
wanted_spec.channels = next_nb_channels[FFMIN(7,
wanted_spec.channels)];
@@ -2659,7 +2660,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
}
if ((ret = decoder_start(&is->auddec, audio_thread, is)) < 0)
goto out;
-SDL_PauseAudio(0);
+SDL_PauseAudioDevice(audio_dev, 0);
break;
case AVMEDIA_TYPE_VIDEO:
is->video_stream = stream_index;
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: use SDL2 audio API
On 11/4/2017 3:54 PM, Marton Balint wrote:
> It allows us to specify what kind of audio parameter changes are allowed.
>
> Should fix ticket #6721.
Seems to work. Thanks.
>
> Signed-off-by: Marton Balint
> ---
> fftools/ffplay.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index c264e92535..bd1457c7e3 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -362,6 +362,7 @@ static AVPacket flush_pkt;
> static SDL_Window *window;
> static SDL_Renderer *renderer;
> static SDL_RendererInfo renderer_info = {0};
> +static SDL_AudioDeviceID audio_dev;
>
> static const struct TextureFormatEntry {
> enum AVPixelFormat format;
> @@ -1192,7 +1193,7 @@ static void stream_component_close(VideoState *is, int
> stream_index)
> switch (codecpar->codec_type) {
> case AVMEDIA_TYPE_AUDIO:
> decoder_abort(&is->auddec, &is->sampq);
> -SDL_CloseAudio();
> +SDL_CloseAudioDevice(audio_dev);
> decoder_destroy(&is->auddec);
> swr_free(&is->swr_ctx);
> av_freep(&is->audio_buf1);
> @@ -2451,7 +2452,7 @@ static void sdl_audio_callback(void *opaque, Uint8
> *stream, int len)
> else {
> memset(stream, 0, len1);
> if (!is->muted && is->audio_buf)
> -SDL_MixAudio(stream, (uint8_t *)is->audio_buf +
> is->audio_buf_index, len1, is->audio_volume);
> +SDL_MixAudioFormat(stream, (uint8_t *)is->audio_buf +
> is->audio_buf_index, AUDIO_S16SYS, len1, is->audio_volume);
> }
> len -= len1;
> stream += len1;
> @@ -2496,7 +2497,7 @@ static int audio_open(void *opaque, int64_t
> wanted_channel_layout, int wanted_nb
> wanted_spec.samples = FFMAX(SDL_AUDIO_MIN_BUFFER_SIZE, 2 <<
> av_log2(wanted_spec.freq / SDL_AUDIO_MAX_CALLBACKS_PER_SEC));
> wanted_spec.callback = sdl_audio_callback;
> wanted_spec.userdata = opaque;
> -while (SDL_OpenAudio(&wanted_spec, &spec) < 0) {
> +while (!(audio_dev = SDL_OpenAudioDevice(NULL, 0, &wanted_spec, &spec,
> SDL_AUDIO_ALLOW_FREQUENCY_CHANGE | SDL_AUDIO_ALLOW_CHANNELS_CHANGE))) {
> av_log(NULL, AV_LOG_WARNING, "SDL_OpenAudio (%d channels, %d Hz):
> %s\n",
> wanted_spec.channels, wanted_spec.freq, SDL_GetError());
> wanted_spec.channels = next_nb_channels[FFMIN(7,
> wanted_spec.channels)];
> @@ -2659,7 +2660,7 @@ static int stream_component_open(VideoState *is, int
> stream_index)
> }
> if ((ret = decoder_start(&is->auddec, audio_thread, is)) < 0)
> goto out;
> -SDL_PauseAudio(0);
> +SDL_PauseAudioDevice(audio_dev, 0);
> break;
> case AVMEDIA_TYPE_VIDEO:
> is->video_stream = stream_index;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] HW accelerator: Indicate when HW acceleration is in use
On 03/11/17 18:35, Michele Lim wrote: > Having clear indication of when a hardware accelerator is in > operation prevents false assumptions, for e.g., in situations when > the command line argument inadvertently omits options for enabling > it, resulting to the framework silently switching to the SW path. > > Signed-off-by: Michele Lim > --- > fftools/ffmpeg_hw.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/fftools/ffmpeg_hw.c b/fftools/ffmpeg_hw.c > index a4d1cad..f071746 100644 > --- a/fftools/ffmpeg_hw.c > +++ b/fftools/ffmpeg_hw.c > @@ -306,6 +306,8 @@ int hw_device_setup_for_decode(InputStream *ist) > if (!ist->dec_ctx->hw_device_ctx) > return AVERROR(ENOMEM); > > +/* Indicate HW accelerator has been prepared for decode */ > +av_log(ist->dec_ctx, AV_LOG_INFO, "HW accelerator prepared for decode: > %s\n", av_hwdevice_get_type_name(type)); > return 0; > } > > @@ -331,6 +333,9 @@ int hw_device_setup_for_encode(OutputStream *ost) > // No device required. > return 0; > } > + > +/* Indicate HW accelerator has been prepared for encode */ > +av_log(ost->enc_ctx, AV_LOG_INFO, "HW accelerator prepared for encode: > %s\n", av_hwdevice_get_type_name(type)); > } > > static int hwaccel_retrieve_data(AVCodecContext *avctx, AVFrame *input) > I don't think this does what you want. It is only a preparation step which sets hardware devices which might then be used by a codec, and tells you little about whether it is actually used in practice. Consider that your message will appear when setting -hwaccel_device and decoding with a random codec with no hardware support, and also when a codec does support some hardware but not the actual stream being decoded (e.g. H.264 4:2:2). If you want a message like this (which I admit ambivalence to, but if other people think it's useful then sure), I think it has to be logged later when we actually know whether the hardware is usable - either inside lavc or in ffmpeg.c after a frame is returned. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.
On Sat, 4 Nov 2017 at 18:28 Michael Niedermayer wrote: > > The UUID can be corrupt as well. > > We shouldn't be printing random data from the bitstream to the users > > terminal. > > i agree > Ok, I will push unless someone objects. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/pcm-dvd: Do not use an incompatible pointer on big-endian.
2017-11-01 18:33 GMT+01:00 Carl Eugen Hoyos :
> 2017-11-01 18:18 GMT+01:00 Hendrik Leppkes :
>> On Wed, Nov 1, 2017 at 5:13 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch silences a gcc warning, tested with Fever.vob
>>>
>>>
>>> @@ -163,10 +162,12 @@ static void *pcm_dvd_decode_samples(AVCodecContext
>>> *avctx, const uint8_t *src,
>>> switch (avctx->bits_per_coded_sample) {
>>> case 16: {
>>> #if HAVE_BIGENDIAN
>>> +int8_t *dst16 = dst;
>>> bytestream2_get_buffer(&gb, dst16, blocks * s->block_size);
>>> -dst16 += blocks * s->block_size / 2;
>>> +dst16 += blocks * s->block_size;
>>> #else
>>> int samples = blocks * avctx->channels;
>>> +int16_t *dst16 = dst;
>>> do {
>>> *dst16++ = bytestream2_get_be16u(&gb);
>>> } while (--samples);
>>
>> This results in quite misleading code. dst16 is named like that
>> because its a 16-bit pointer, using the same pointer with different
>> types based on this ifdef seems error-prone in the future.
>
> Agree, new patch attached.
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/pcm-bluray: Do not use incompatible pointers on big-endian.
2017-11-01 19:01 GMT+01:00 Carl Eugen Hoyos :
> 2017-11-01 18:31 GMT+01:00 Hendrik Leppkes :
>> On Wed, Nov 1, 2017 at 6:25 PM, Carl Eugen Hoyos wrote:
>>> 2017-11-01 18:16 GMT+01:00 Hendrik Leppkes :
On Wed, Nov 1, 2017 at 5:16 PM, Carl Eugen Hoyos
wrote:
> Hi!
>
> Attached patch silences two gcc warnings, no sample for odd channel count
> found.
>
> #if HAVE_BIGENDIAN
> -bytestream2_get_buffer(&gb, dst16, avctx->channels *
> 2);
> -dst16 += avctx->channels;
> +uint8_t *dst = frame->data[0];
> +bytestream2_get_buffer(&gb, frame->data[0],
> avctx->channels * 2);
> +dst += avctx->channels * 2;
> #else
> channel = avctx->channels;
> do {
This hunk seems fishy. dst is only ever set, never read, and this code
is executed in a loop but always writes to the same position.
>>>
>>> I had sent the wrong version, please review this one.
>>
>> That still won't work, dst is declared within the loop, so its reset
>> back to the start at the beginning of the frame each iteration.
>
> New try attached.
Ping.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/exr: fix undefined shift in pxr24_uncompress()
On Sat, Nov 04, 2017 at 10:21:37AM +0100, Paul B Mahol wrote:
> On 11/4/17, Michael Niedermayer wrote:
> > Fixes: runtime error: left shift of 255 by 24 places cannot be represented
> > in type 'int'
> > Fixes: 3787/clusterfuzz-testcase-minimized-5728764920070144
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/exr.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> > index 0b755db3cb..b1ecde4ebd 100644
> > --- a/libavcodec/exr.c
> > +++ b/libavcodec/exr.c
> > @@ -855,7 +855,7 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t
> > *src,
> > in = ptr[2] + td->xsize;
> >
> > for (j = 0; j < td->xsize; ++j) {
> > -uint32_t diff = (*(ptr[0]++) << 24) |
> > +uint32_t diff = ((unsigned)*(ptr[0]++) << 24) |
> > (*(ptr[1]++) << 16) |
> > (*(ptr[2]++) << 8);
> > pixel += diff;
> > --
> > 2.15.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> ok
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/xan: Check for bitstream end in xan_huffman_decode()
On Fri, Nov 03, 2017 at 05:48:29PM +0100, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: 3707/clusterfuzz-testcase-6465922706440192 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/xan.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni 4 tap hz and vt mc msa functions
On Sat, Nov 04, 2017 at 01:07:41AM +, Manojkumar Bhosale wrote: > LGTM will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni weighted 4 tap hz mc msa functions
On Sat, Nov 04, 2017 at 01:08:20AM +, Manojkumar Bhosale wrote: > LGTM applied thanks [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK
On 31/10/17 19:39, mmironov wrote: > From 8640b995634f827eb39ae87bcbe2c1992d8140f2 Mon Sep 17 00:00:00 2001 > From: mmironov > Date: Fri, 27 Oct 2017 13:03:15 -0400 > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD GPUs > based on AMF SDK > > Signed-off-by: mmironov > --- > Changelog|3 +- > compat/amd/amfsdkenc.h | 1753 > ++ > configure| 25 + > libavcodec/Makefile |4 + > libavcodec/allcodecs.c |2 + > libavcodec/amfenc.c | 513 ++ > libavcodec/amfenc.h | 136 > libavcodec/amfenc_h264.c | 368 ++ > libavcodec/amfenc_hevc.c | 296 > libavcodec/version.h |4 +- > 10 files changed, 3101 insertions(+), 3 deletions(-) > create mode 100644 compat/amd/amfsdkenc.h > create mode 100644 libavcodec/amfenc.c > create mode 100644 libavcodec/amfenc.h > create mode 100644 libavcodec/amfenc_h264.c > create mode 100644 libavcodec/amfenc_hevc.c > > diff --git a/Changelog b/Changelog > index 6592d86..f0d22fa 100644 > --- a/Changelog > +++ b/Changelog > @@ -6,7 +6,8 @@ version : > - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now >requires 2.1 (or later) and pkg-config. > - VDA dropped (use VideoToolbox instead) > - > +- AMF H.264 encoder > +- AMF HEVC encoder > > version 3.4: > - deflicker video filter > diff --git a/compat/amd/amfsdkenc.h b/compat/amd/amfsdkenc.h > new file mode 100644 > index 000..0d48451 > --- /dev/null > +++ b/compat/amd/amfsdkenc.h> @@ -0,0 +1,1753 @@ > +// > +// MIT license > +// > +// Copyright (c) 2017 Advanced Micro Devices, Inc. All rights reserved. > +// > +// Permission is hereby granted, free of charge, to any person obtaining a > copy > +// of this software and associated documentation files (the "Software"), to > deal > +// in the Software without restriction, including without limitation the > rights > +// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > +// copies of the Software, and to permit persons to whom the Software is > +// furnished to do so, subject to the following conditions: > +// > +// The above copyright notice and this permission notice shall be included in > +// all copies or substantial portions of the Software. > +// > +// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > +// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > +// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > FROM, > +// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > +// THE SOFTWARE. > +// > + > +// Reduced AMF API > +// > +// Full version of AMF SDK and the latest version of this file > +// can be found at https://github.com/GPUOpen-LibrariesAndSDKs/AMF On further consideration I am against including this header. Just ask the user to get it from this link you are including anyway. (Also maybe make that packagable by providing some means to install it, preferably including pkg-config support.) > diff --git a/configure b/configure > index 0e1ccaa..403e010 100755 > --- a/configure > +++ b/configure > @@ -304,6 +304,7 @@ External library support: > >The following libraries provide various hardware acceleration features: >--disable-audiotoolbox disable Apple AudioToolbox code [autodetect] > + --disable-amfdisable AMF video encoding code [autodetect] m < u >--disable-cuda disable dynamically linked Nvidia CUDA code > [autodetect] >--enable-cuda-sdkenable CUDA features that require the CUDA SDK > [no] >--disable-cuvid disable Nvidia CUVID support [autodetect] > @@ -1641,6 +1642,7 @@ EXTERNAL_LIBRARY_LIST=" > " > > HWACCEL_AUTODETECT_LIBRARY_LIST=" > +amf > audiotoolbox > crystalhd > cuda > @@ -2785,12 +2787,15 @@ scale_npp_filter_deps="cuda libnpp" > scale_cuda_filter_deps="cuda_sdk" > thumbnail_cuda_filter_deps="cuda_sdk" > > +amf_deps_any="dlopen LoadLibrary" > + > nvenc_deps="cuda" > nvenc_deps_any="libdl LoadLibrary" > nvenc_encoder_deps="nvenc" > > h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m" > h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m" > +h264_amf_encoder_deps="amf" > h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser" > h264_cuvid_decoder_deps="cuda cuvid" > h264_cuvid_decoder_select="h264_mp4toannexb_bsf" > @@ -2809,6 +2814,7 @@ > h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264" > h264_vaapi_encoder_select="cbs_h264 vaapi_encode" > h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m" > h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m" > +hevc_amf_encoder_deps="amf" > hevc_cuvid_decoder_deps="cuda cuvid" > hevc_cuvid_d
[FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo
Hello, I need to remove MPEG-4 support from mpegvideo in order to upstream the following code: https://github.com/kierank/ffmpeg-sstp I'll need to extract mpeg4video from mpegvideo for the following reasons in the Studio Profile: - 10-bit video, mpegvideo.c is entirely 8-bit, I'll need to write a new idct or use an existing (e.g ProRes) if applicable - DPCM mode (a bit like h264's mode) In particular I think this will break lowres. Is this ok or will the patch be blocked? Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo
On 11/4/2017 5:27 PM, Kieran Kunhya wrote: > Hello, > > I need to remove MPEG-4 support from mpegvideo in order to upstream the > following code: > https://github.com/kierank/ffmpeg-sstp > > I'll need to extract mpeg4video from mpegvideo for the following reasons in > the Studio Profile: > > - 10-bit video, mpegvideo.c is entirely 8-bit, I'll need to write a new > idct or use an existing (e.g ProRes) if applicable > - DPCM mode (a bit like h264's mode) > > In particular I think this will break lowres. Is this ok or will the patch > be blocked? > lowres is deprecated and the only reason it wasn't removed during this major bump was because i couldn't feasibly find a way to untangle it from the rest of the codebase, and no one else answered my call for help when i sent the major bump patch two months ago. The unstable ABI period is still open, for that matter, so if you or anyone else feels like giving it a try then there's still a couple weeks to remove it as originally scheduled. Otherwise, it will be removed next year or so alongside AVStream->codec. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Allow -to on input files as well
From: Vitaly _Vi Shukela
Why only output files can have both -t and -to?
Signed-off-by: Vitaly "_Vi" Shukela
---
fftools/ffmpeg_opt.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ca6f10d5ca..e453cb34c5 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -972,6 +972,21 @@ static int open_input_file(OptionsContext *o, const char
*filename)
char *data_codec_name = NULL;
int scan_all_pmts_set = 0;
+if (o->stop_time != INT64_MAX && o->recording_time != INT64_MAX) {
+o->stop_time = INT64_MAX;
+av_log(NULL, AV_LOG_WARNING, "-t and -to cannot be used together;
using -t.\n");
+}
+
+if (o->stop_time != INT64_MAX && o->recording_time == INT64_MAX) {
+int64_t start_time = o->start_time == AV_NOPTS_VALUE ? 0 :
o->start_time;
+if (o->stop_time <= start_time) {
+av_log(NULL, AV_LOG_ERROR, "-to value smaller than -ss;
aborting.\n");
+exit_program(1);
+} else {
+o->recording_time = o->stop_time - start_time;
+}
+}
+
if (o->format) {
if (!(file_iformat = av_find_input_format(o->format))) {
av_log(NULL, AV_LOG_FATAL, "Unknown input format: '%s'\n",
o->format);
@@ -3403,7 +3418,7 @@ const OptionDef options[] = {
OPT_INPUT | OPT_OUTPUT, { .off =
OFFSET(recording_time) },
"record or transcode \"duration\" seconds of audio/video",
"duration" },
-{ "to", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_OUTPUT, { .off
= OFFSET(stop_time) },
+{ "to", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_INPUT |
OPT_OUTPUT, { .off = OFFSET(stop_time) },
"record or transcode stop time", "time_stop" },
{ "fs", HAS_ARG | OPT_INT64 | OPT_OFFSET | OPT_OUTPUT, { .off
= OFFSET(limit_filesize) },
"set the limit file size in bytes", "limit_size" },
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Document the fact that -to option is now also for input
From: Vitaly _Vi Shukela
Signed-off-by: Vitaly _Vi Shukela
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7db80ebf6a..3df171fe63 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -290,7 +290,7 @@ see @ref{time duration syntax,,the Time duration section in
the ffmpeg-utils(1)
-to and -t are mutually exclusive and -t has priority.
@item -to @var{position} (@emph{output})
-Stop writing the output at @var{position}.
+Stop writing the output or reading the input at @var{position}.
@var{position} must be a time duration specification,
see @ref{time duration syntax,,the Time duration section in the
ffmpeg-utils(1) manual,ffmpeg-utils}.
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo
2017-11-04 21:27 GMT+01:00 Kieran Kunhya : > I need to remove MPEG-4 support from mpegvideo in order > to upstream the following code: > https://github.com/kierank/ffmpeg-sstp Decoding of the yuv422p10 samples does not yet work. Is the rgb output correct? It looks as if seen through a strange colour filter, do you think this is intended? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC/PATCH]lavc/v4l2_context: Change the type of the ioctl cmd to unsigned long
Hi!
Attached patch fixes a warning on a current 64bit Linux system (that I
do not see on my ancient system where the ioctl cmd has type int).
Is there a better way to deal with it?
Please comment, Carl Eugen
From 06886eea147cd68ee14291de1e437c364682f8ef Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 5 Nov 2017 01:42:37 +0100
Subject: [PATCH] lavc/v4l2_context: Change the type of the ioctl cmd to
unsigned long.
Fixes a warning on recent Linux:
libavcodec/v4l2_context.c: In function 'ff_v4l2_context_set_status':
libavcodec/v4l2_context.c:496:26: warning: comparison is always false due to limited range of data type
---
libavcodec/v4l2_context.c |2 +-
libavcodec/v4l2_context.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 9f3b56d..e3f0175 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -484,7 +484,7 @@ static int v4l2_get_coded_format(V4L2Context* ctx, uint32_t *p)
*
*/
-int ff_v4l2_context_set_status(V4L2Context* ctx, int cmd)
+int ff_v4l2_context_set_status(V4L2Context* ctx, unsigned long cmd)
{
int type = ctx->type;
int ret;
diff --git a/libavcodec/v4l2_context.h b/libavcodec/v4l2_context.h
index 503cc36..1a6ad7a 100644
--- a/libavcodec/v4l2_context.h
+++ b/libavcodec/v4l2_context.h
@@ -135,7 +135,7 @@ void ff_v4l2_context_release(V4L2Context* ctx);
*those frames will be dropped.
* @return 0 in case of success, a negative value representing the error otherwise.
*/
-int ff_v4l2_context_set_status(V4L2Context* ctx, int cmd);
+int ff_v4l2_context_set_status(V4L2Context* ctx, unsigned long cmd);
/**
* Dequeues a buffer from a V4L2Context to an AVPacket.
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo
On Sat, 4 Nov 2017 at 22:33 Carl Eugen Hoyos wrote: > 2017-11-04 21:27 GMT+01:00 Kieran Kunhya : > > > I need to remove MPEG-4 support from mpegvideo in order > > to upstream the following code: > > https://github.com/kierank/ffmpeg-sstp > > Decoding of the yuv422p10 samples does not yet work. > Is the rgb output correct? It looks as if seen through a > strange colour filter, do you think this is intended? > I haven't looked at this for nearly a year but at the time all samples I had looked correct. Except some macroblocks which used DPCM were not decodable for the reasons I described previously (impossible to fit this into mpegvideo.c). I will look at this again over the Christmas holidays. Regards, Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC/PATCH]lavc/v4l2_context: Change the type of the ioctl cmd to unsigned long
2017-11-05 1:46 GMT+01:00 Carl Eugen Hoyos :
> Attached patch fixes a warning on a current 64bit Linux system (that I
> do not see on my ancient system where the ioctl cmd has type int).
> Is there a better way to deal with it?
The way I understand the issue the attached patch works with both
int and unsigned long as types.
Please comment, Carl Eugen
From 7acece14950f212f49d7a24e14803a25c27aba3b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 5 Nov 2017 01:53:49 +0100
Subject: [PATCH] lavc/v4l2_context: Change the type of the ioctl cmd to
unsigned.
Fixes a warning on recent Linux:
libavcodec/v4l2_context.c: In function 'ff_v4l2_context_set_status':
libavcodec/v4l2_context.c:496:26: warning: comparison is always false due to limited range of data type
---
libavcodec/v4l2_context.c |2 +-
libavcodec/v4l2_context.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 9f3b56d..78aa0fa 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -484,7 +484,7 @@ static int v4l2_get_coded_format(V4L2Context* ctx, uint32_t *p)
*
*/
-int ff_v4l2_context_set_status(V4L2Context* ctx, int cmd)
+int ff_v4l2_context_set_status(V4L2Context* ctx, unsigned cmd)
{
int type = ctx->type;
int ret;
diff --git a/libavcodec/v4l2_context.h b/libavcodec/v4l2_context.h
index 503cc36..4d7734a 100644
--- a/libavcodec/v4l2_context.h
+++ b/libavcodec/v4l2_context.h
@@ -135,7 +135,7 @@ void ff_v4l2_context_release(V4L2Context* ctx);
*those frames will be dropped.
* @return 0 in case of success, a negative value representing the error otherwise.
*/
-int ff_v4l2_context_set_status(V4L2Context* ctx, int cmd);
+int ff_v4l2_context_set_status(V4L2Context* ctx, unsigned cmd);
/**
* Dequeues a buffer from a V4L2Context to an AVPacket.
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC/PATCH]lavc/v4l2_context: Change the type of the ioctl cmd to unsigned long
On 05/11/17 01:25, Carl Eugen Hoyos wrote:
> 2017-11-05 1:46 GMT+01:00 Carl Eugen Hoyos :
>
>> Attached patch fixes a warning on a current 64bit Linux system (that I
>> do not see on my ancient system where the ioctl cmd has type int).
>> Is there a better way to deal with it?
>
> The way I understand the issue the attached patch works with both
> int and unsigned long as types.
> From 7acece14950f212f49d7a24e14803a25c27aba3b Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Sun, 5 Nov 2017 01:53:49 +0100
> Subject: [PATCH] lavc/v4l2_context: Change the type of the ioctl cmd to
> unsigned.
>
> Fixes a warning on recent Linux:
> libavcodec/v4l2_context.c: In function 'ff_v4l2_context_set_status':
> libavcodec/v4l2_context.c:496:26: warning: comparison is always false due to
> limited range of data type
> ---
> libavcodec/v4l2_context.c |2 +-
> libavcodec/v4l2_context.h |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
> index 9f3b56d..78aa0fa 100644
> --- a/libavcodec/v4l2_context.c
> +++ b/libavcodec/v4l2_context.c
> @@ -484,7 +484,7 @@ static int v4l2_get_coded_format(V4L2Context* ctx,
> uint32_t *p)
>*
>
> */
>
> -int ff_v4l2_context_set_status(V4L2Context* ctx, int cmd)
> +int ff_v4l2_context_set_status(V4L2Context* ctx, unsigned cmd)
> {
> int type = ctx->type;
> int ret;
> diff --git a/libavcodec/v4l2_context.h b/libavcodec/v4l2_context.h
> index 503cc36..4d7734a 100644
> --- a/libavcodec/v4l2_context.h
> +++ b/libavcodec/v4l2_context.h
> @@ -135,7 +135,7 @@ void ff_v4l2_context_release(V4L2Context* ctx);
> *those frames will be dropped.
> * @return 0 in case of success, a negative value representing the error
> otherwise.
> */
> -int ff_v4l2_context_set_status(V4L2Context* ctx, int cmd);
> +int ff_v4l2_context_set_status(V4L2Context* ctx, unsigned cmd);
>
> /**
> * Dequeues a buffer from a V4L2Context to an AVPacket.
> --
> 1.7.10.4
>
This one LGTM. (I don't mind between unsigned int or uint32_t.)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC/PATCH]lavc/v4l2_context: Change the type of the ioctl cmd to unsigned long
On 05/11/17 00:46, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes a warning on a current 64bit Linux system (that I > do not see on my ancient system where the ioctl cmd has type int). > Is there a better way to deal with it? > Fixes a warning on recent Linux: > libavcodec/v4l2_context.c: In function 'ff_v4l2_context_set_status': > libavcodec/v4l2_context.c:496:26: warning: comparison is always false due to > limited range of data type Huh. I didn't realise that the standard Linux ioctl numbering actually acts differently on different achitectures (you don't hit this on ARM or x86-64 with a write-only ioctl, as VIDIOC_STREAMON is). The patch is probably correct, though I think I would prefer the type to be uint32_t as the ioctl numbering in Linux really is 32-bit regardless of what some external prototypes (i.e. glibc) might say. (Inside the kernel it's unsigned int, but uint32_t would be more explicit.) Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK
> > +//
> > +
> > +// Reduced AMF API
> > +//
> > +// Full version of AMF SDK and the latest version of this file
> > +// can be found at https://github.com/GPUOpen-LibrariesAndSDKs/AMF
>
> On further consideration I am against including this header. Just ask the
> user
> to get it from this link you are including anyway. (Also maybe make that
> packagable by providing some means to install it, preferably including pkg-
> config support.)
>
You put very accurate description of the situation in a different thread.
Few opinions were expressed but then discussion paused.
How does this group resolve such issues?
> > +
> > +#define PTS_PROP L"PtsProp"
>
> Who is defining this key? (Does the AMF code look inside it?)
>
This key is the private one for amfenc implementation in ffmpeg. AMF runtime
will pass it
though to the output object.
> > +
> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> > +AV_PIX_FMT_NV12,
> > +AV_PIX_FMT_RGB0,
> > +AV_PIX_FMT_BGR0,
>
> I still think including RGB formats here is a bad idea without any colourspace
> support.
There are pros and cons here.:
Pros: it will provide HW acceleration in simple cases.
Cons: no control for user.
I will remove it till I expose color converter property from the encoder in
runtime implementation.
Currently supported are 601, 709 and JPEG. Is it good enough to reinstate these
formats once such
encoder option is added?
> > +buffer->pVtbl->GetProperty(buffer, PTS_PROP, &var);
> > +
> > +pkt->pts = var.int64Value; // original pts
> > +pkt->dts = buffer->pVtbl->GetPts(buffer); // in monotonic order
>
> Does the GetPts function really return the DTS?
Yes. Though DTS is not exactly the right term. The component will reorder PTSs
that are set in SetPts() (in case of B-frames)
and return them in GetPts() - so it is monotonic order timestamps. BTW: NV has
the same behavior, only PTS reordering
is done in ffmpeg code.
> > +res = ctx->context->pVtbl->CreateSurfaceFromDX11Native(ctx-
> >context, texture, &surface, NULL); // wrap to AMF surface
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR(ENOMEM),
> "CreateSurfaceFromDX11Native() failed with error %d\n", res);
>
> I think you will need to hold a reference to the input frame while it's in the
> encoder here, assuming it doesn't get copied away immediately. If not, it
> will
> be returned to the frame pool and might be reused by someone else - it can't
> be freed because you are holding a reference to its frames context, but I
> think it can be written to.
>
> (I could believe that testing with ffmpeg (something like "./ffmpeg_g -hwaccel
> d3d11va -hwaccel_output_format d3d11 input.mp4 -c:v h264_amf ...
> output.mp4", presumably?) is not sufficient to show any problems here. Not
> sure what would be.)
I will add ref to the frame if it is D3D11. In case of system memory it was
already copied.
>
> Just to confirm, the encoder will /always/ be able to consume the new
> surface after returning a packet?
Yes at this point.
> > +{ "baseline", "", 0,
> > AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_PROFILE_BASELINE }, 0, 0, VE, "profile" },
>
> I still very much doubt you support baseline profile. Please remove it to
> avoid confusion.
According to codec it is but I will remove - not much use of it.
> > +{ "quality","", 0, AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET_QUALITY }, 0, 0, VE,
> "quality" },
>
> These are 0, 5, 10. Do the intermediate values work? Should they be
> exposed?
>
Only enum values are supported. I guess they left space for future extensions.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()
On Sun, Oct 29, 2017 at 03:09:13PM +0100, Peter Große wrote: > On Sun, 29 Oct 2017 14:56:20 +0100 > Moritz Barsnick wrote: > > > On Sun, Oct 29, 2017 at 12:08:05 +0100, Peter Große wrote: > > > } else duration = 1; > > > > For style/readability, the statement should be on a new line, perhaps > > even with brackets. (Not necessarily as part of this patch though.) > > Sure. > > Regards > Peter > ffmpeg.c |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > ad25b12935744d7c3a6b169bb7585c89f4f70c4d > 0001-ffmpeg.c-fix-code-style-in-seek_to_start.patch > From 14032f4185a0824b819b062068f5777a33057ece Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Peter=20Gro=C3=9Fe?= > Date: Sun, 29 Oct 2017 15:07:12 +0100 > Subject: [PATCH] ffmpeg.c: fix code style in seek_to_start > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > To: ffmpeg-devel@ffmpeg.org patchset applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo
On Sat, Nov 04, 2017 at 08:27:42PM +, Kieran Kunhya wrote: > Hello, > > I need to remove MPEG-4 support from mpegvideo in order to upstream the > following code: > https://github.com/kierank/ffmpeg-sstp > > I'll need to extract mpeg4video from mpegvideo for the following reasons in > the Studio Profile: > > - 10-bit video, mpegvideo.c is entirely 8-bit, I'll need to write a new > idct or use an existing (e.g ProRes) if applicable > - DPCM mode (a bit like h264's mode) > > In particular I think this will break lowres. Is this ok or will the patch > be blocked? If the patch breaks lowres and people lack interrest in fixing it then please give me a chance to find a solution that doesnt break it. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
