Re: [FFmpeg-devel] [PATCH 3/3] avformat/avio: remove 4k limit from avio_printf
On Tue, 6 Aug 2019, Nicolas George wrote:
Marton Balint (12019-08-05):
We do this by switching to AVBPrint.
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavformat/avio.h| 5 -
libavformat/aviobuf.c | 15 ++-
libavformat/version.h | 2 +-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 0b19fb067d..fe36c34b90 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-08-xx - xx - lavf 58.31.101 - avio.h
+ 4K limit removed from avio_printf.
+
2019-08-xx - xx - lavf 58.31.100 - avio.h
Add avio_print_n_strings and avio_print.
diff --git a/libavformat/avio.h b/libavformat/avio.h
index ca08907917..f2051da18d 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -571,7 +571,10 @@ int64_t avio_size(AVIOContext *s);
*/
int avio_feof(AVIOContext *s);
-/** @warning Writes up to 4 KiB per call */
+/**
+ * Writes a formatted string to the context.
+ * @return number of bytes written, < 0 on error.
+ */
int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
/**
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index c37b056b64..007fba6410 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1215,14 +1215,19 @@ int avio_closep(AVIOContext **s)
int avio_printf(AVIOContext *s, const char *fmt, ...)
{
va_list ap;
-char buf[4096]; /* update doc entry in avio.h if changed */
-int ret;
+AVBPrint bp;
+av_bprint_init(, 0, INT_MAX);
INT_MAX? Should be -1 or AV_BPRINT_SIZE_UNLIMITED.
The function returns an int so it can't signal writing longer strings that
that.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/avio: add avio_print_n_strings and avio_print
On Tue, 6 Aug 2019, Nicolas George wrote: Marton Balint (12019-08-05): These functions can be used to print a variable number of strings consecutively to the IO context. Unlike av_bprintf, no temporery buffer is necessary. I do not like this very much: the VA design disables type checking, which makes it rather fragile, and the benefit is really minor. This is only a problem if avio_print_n_strings is called directly, but the user should always use avio_print. And avio_print macro is casting every parameter to const char *, so the compiler emits a warning if the user passes an argument which is not const char *. Maybe add avio_print_string() to print a single string, and call it as many times as necessary. That reduces readability slightly, so I'd rather not do it. 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] avcodec/videotoolbox_hevc: avoid leaking cached_hw_frames_ctx
vtctx->cached_hw_frames_ctx is unref'd in videotoolbox_uninit,
but videotoolbox_hevc used ff_videotoolbox_uninit which
doesn't unref cache_hw_frames_ctx.
---
libavcodec/videotoolbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index c718e82cc5..acaeef77dd 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -1143,7 +1143,7 @@ const AVHWAccel ff_hevc_videotoolbox_hwaccel = {
.end_frame = videotoolbox_hevc_end_frame,
.frame_params = videotoolbox_frame_params,
.init = videotoolbox_common_init,
-.uninit = ff_videotoolbox_uninit,
+.uninit = videotoolbox_uninit,
.priv_data_size = sizeof(VTContext),
};
--
2.16.4
___
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] libavformat: Add ZeroMQ as a protocol option
On Wed, Aug 7, 2019 at 10:22 AM Andriy Gelman wrote: > On Sun, 04. Aug 14:36, Andriy Gelman wrote: > > Changes in v2: > > 1. Replaced zmq_poll with zmq_msg_recv. > > 2. Remove user timeout option as zmq_msg_recv(.., .., ZMQ_DONTWAIT) is > a > > non-blocking call. > > 3. Updated docs. > > > > Andriy > > > diff --git a/libavformat/Makefile b/libavformat/Makefile > > index a434b005a4..4a535429b7 100644 > > --- a/libavformat/Makefile > > +++ b/libavformat/Makefile > > @@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o > > OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o > > OBJS-$(CONFIG_LIBSRT_PROTOCOL) += libsrt.o > > OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o > > +OBJS-$(CONFIG_LIBZMQ_PROTOCOL) > += libzmq.o > > > There is a TAB here, Please remove it > > # libavdevice dependencies > > OBJS-$(CONFIG_IEC61883_INDEV)+= dv.o > > > ___ 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] avutil/mips: refactor msa SLDI_Bn_0 and SLDI_Bn macros.
LGTM. >-Original Message- >From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] >On Behalf Of gxw >Sent: Tuesday, August 6, 2019 7:11 PM >To: ffmpeg-devel@ffmpeg.org >Subject: [FFmpeg-devel] [PATCH v2] avutil/mips: refactor msa SLDI_Bn_0 and >SLDI_Bn macros. > >Changing details as following: >1. The previous order of parameters are irregular and difficult to > understand. Adjust the order of the parameters according to the > rule: (RTYPE, input registers, input mask/input index/..., output > registers). > Most of the existing msa macros follow the rule. >2. Remove the redundant macro SLDI_Bn_0 and use SLDI_Bn instead. >--- > libavcodec/mips/h264dsp_msa.c | 9 ++-- > libavcodec/mips/h264qpel_msa.c | 64 ++-- > libavcodec/mips/hevc_lpf_sao_msa.c | 70 --- > libavcodec/mips/hevcpred_msa.c | 30 ++--- > libavcodec/mips/hpeldsp_msa.c | 66 ++--- > libavcodec/mips/me_cmp_msa.c| 8 ++-- > libavcodec/mips/qpeldsp_msa.c | 84 ++--- > libavcodec/mips/vp8_mc_msa.c| 4 +- > libavcodec/mips/vp9_idct_msa.c | 3 +- > libavcodec/mips/vp9_lpf_msa.c | 3 +- > libavcodec/mips/vp9_mc_msa.c| 16 +++ > libavutil/mips/generic_macros_msa.h | 80 ++- > 12 files changed, 222 insertions(+), 215 deletions(-) > >diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c >index 89fe399..c4ba8c4 100644 >--- a/libavcodec/mips/h264dsp_msa.c >+++ b/libavcodec/mips/h264dsp_msa.c >@@ -620,7 +620,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, >int32_t stride, > \ > out0 = (v16u8) __msa_ilvr_b((v16i8) in1, (v16i8) in0); \ > out1 = (v16u8) __msa_sldi_b(zero_m, (v16i8) out0, 2);\ >-SLDI_B2_0_UB(out1, out2, out2, out3, 2); \ >+SLDI_B2_UB(zero_m, out1, zero_m, out2, 2, out2, out3); \ > } > > #define AVC_LPF_H_2BYTE_CHROMA_422(src, stride, tc_val, alpha, beta, res) \ >@@ -1025,7 +1025,8 @@ static void >avc_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int32_t >stride, > > ILVR_W2_SB(tmp2, tmp0, tmp3, tmp1, src6, src3); > ILVL_W2_SB(tmp2, tmp0, tmp3, tmp1, src1, src5); >-SLDI_B4_0_SB(src6, src1, src3, src5, src0, src2, src4, src7, 8); >+SLDI_B4_SB(zeros, src6, zeros, src1, zeros, src3, zeros, src5, >+ 8, src0, src2, src4, src7); > > p0_asub_q0 = __msa_asub_u_b((v16u8) src2, (v16u8) src3); > p1_asub_p0 = __msa_asub_u_b((v16u8) src1, (v16u8) src2); >@@ -1116,10 +1117,10 @@ static void >avc_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int32_t >stride, > ILVRL_H2_SH(zeros, dst2_x, tmp2, tmp3); > > ILVR_W2_UB(tmp2, tmp0, tmp3, tmp1, dst0, dst4); >-SLDI_B2_0_UB(dst0, dst4, dst1, dst5, 8); >+SLDI_B2_UB(zeros, dst0, zeros, dst4, 8, dst1, dst5); > dst2_x = (v16u8) __msa_ilvl_w((v4i32) tmp2, (v4i32) tmp0); > dst2_y = (v16u8) __msa_ilvl_w((v4i32) tmp3, (v4i32) tmp1); >-SLDI_B2_0_UB(dst2_x, dst2_y, dst3_x, dst3_y, 8); >+SLDI_B2_UB(zeros, dst2_x, zeros, dst2_y, 8, dst3_x, dst3_y); > > out0 = __msa_copy_u_w((v4i32) dst0, 0); > out1 = __msa_copy_u_h((v8i16) dst0, 2); >diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c >index df7e3e2..e435c18 100644 >--- a/libavcodec/mips/h264qpel_msa.c >+++ b/libavcodec/mips/h264qpel_msa.c >@@ -790,8 +790,8 @@ void ff_put_h264_qpel16_mc10_msa(uint8_t *dst, const >uint8_t *src, > minus5b, res4, res5, res6, res7); > DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b, > plus20b, res4, res5, res6, res7); >-SLDI_B2_SB(src1, src3, src0, src2, src0, src2, 2); >-SLDI_B2_SB(src5, src7, src4, src6, src4, src6, 2); >+SLDI_B4_SB(src1, src0, src3, src2, src5, src4, src7, src6, 2, >+ src0, src2, src4, src6); > SRARI_H4_SH(res0, res1, res2, res3, 5); > SRARI_H4_SH(res4, res5, res6, res7, 5); > SAT_SH4_SH(res0, res1, res2, res3, 7); >@@ -858,8 +858,8 @@ void ff_put_h264_qpel16_mc30_msa(uint8_t *dst, const >uint8_t *src, > minus5b, res4, res5, res6, res7); > DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b, > plus20b, res4, res5, res6, res7); >-SLDI_B2_SB(src1, src3, src0, src2, src0, src2, 3); >-SLDI_B2_SB(src5, src7, src4, src6, src4, src6, 3); >+SLDI_B4_SB(src1, src0, src3, src2, src5, src4, src7, src6, 3, >+ src0, src2, src4, src6); > SRARI_H4_SH(res0, res1, res2, res3, 5); > SRARI_H4_SH(res4, res5, res6, res7, 5); > SAT_SH4_SH(res0, res1, res2, res3, 7); >@@ -911,10 +911,10 @@ void ff_put_h264_qpel8_mc10_msa(uint8_t *dst, const >uint8_t *src, > VSHF_B2_SB(src6, src6, src7, src7, mask2,
[FFmpeg-devel] [PATCH V2] FATE/dnn: let fate/dnn tests depend on ffmpeg static libraries
background: DNN (deep neural network) is a sub module of libavfilter, and FATE/dnn is unit test for the DNN module, one unit test for one dnn layer. The unit tests are not based on the APIs exported by libavfilter, they just directly call into the functions within DNN submodule. There is an issue when run the following command: build$ ../ffmpeg/configure --disable-static --enable-shared make make fate-dnn-layer-pad And part of error message: tests/dnn/dnn-layer-pad-test.o: In function `test_with_mode_symmetric': /work/media/ffmpeg/build/src/tests/dnn/dnn-layer-pad-test.c:73: undefined reference to `dnn_execute_layer_pad' The root cause is that function dnn_execute_layer_pad is a LOCAL symbol in libavfilter.so, and so the linker could not find it when build dnn-layer-pad-test. To check it, just run: readelf -s libavfilter/libavfilter.so | grep dnn So, add dependency in fate/dnn Makefile with ffmpeg static libraries. This is the same method used in fate/checkasm Signed-off-by: Guo, Yejun --- tests/dnn/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/dnn/Makefile b/tests/dnn/Makefile index b2e6680..0e050ea 100644 --- a/tests/dnn/Makefile +++ b/tests/dnn/Makefile @@ -4,8 +4,8 @@ DNNTESTOBJS := $(DNNTESTOBJS:%=$(DNNTESTSDIR)%) $(DNNTESTPROGS:%=$(DNNTESTSDIR) DNNTESTPROGS := $(DNNTESTPROGS:%=$(DNNTESTSDIR)/%-test$(EXESUF)) -include $(wildcard $(DNNTESTOBJS:.o=.d)) -$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_DEP_LIBS) - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) $(FF_EXTRALIBS) $(ELIBS) +$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_STATIC_DEP_LIBS) + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) $(FF_STATIC_DEP_LIBS) $(ELIBS) testclean:: $(RM) $(addprefix $(DNNTESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF)) -- 2.7.4 ___ 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] libavformat: Add ZeroMQ as a protocol option
On Sun, 04. Aug 14:36, Andriy Gelman wrote:
> Changes in v2:
> 1. Replaced zmq_poll with zmq_msg_recv.
> 2. Remove user timeout option as zmq_msg_recv(.., .., ZMQ_DONTWAIT) is a
> non-blocking call.
> 3. Updated docs.
>
> Andriy
>
> From 53e6e00d30c9fbf5127eea9d377686d37e981c0c Mon Sep 17 00:00:00 2001
> From: Andriy Gelman
> Date: Tue, 30 Jul 2019 14:39:32 -0400
> Subject: [PATCH] libavformat: Add ZeroMQ as a protocol option
>
> Currently multiple clients are only supported by using a
> multicast destination address. An alternative is to stream to a server
> which re-distributes the content.
>
> This commit adds ZeroMQ as a protocol option, which allows
> multiple clients to connect to a single ffmpeg instance.
> ---
> configure | 2 +
> doc/general.texi| 1 +
> doc/protocols.texi | 32
> libavformat/Makefile| 1 +
> libavformat/libzmq.c| 159
> libavformat/protocols.c | 1 +
> 6 files changed, 196 insertions(+)
> create mode 100644 libavformat/libzmq.c
>
> diff --git a/configure b/configure
> index 5a4f507246..4515341b06 100755
> --- a/configure
> +++ b/configure
> @@ -3400,6 +3400,8 @@ libsrt_protocol_deps="libsrt"
> libsrt_protocol_select="network"
> libssh_protocol_deps="libssh"
> libtls_conflict="openssl gnutls mbedtls"
> +libzmq_protocol_deps="libzmq"
> +libzmq_protocol_select="network"
>
> # filters
> afftdn_filter_deps="avcodec"
> diff --git a/doc/general.texi b/doc/general.texi
> index 3c0c803449..b8e063268c 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -1329,6 +1329,7 @@ performance on systems without hardware floating point
> support).
> @item TCP @tab X
> @item TLS @tab X
> @item UDP @tab X
> +@item ZMQ @tab E
> @end multitable
>
> @code{X} means that the protocol is supported.
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 3e4e7af3d4..174eaacd0f 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1728,4 +1728,36 @@ Timeout in ms.
> Create the Unix socket in listening mode.
> @end table
>
> +@section libzmq
> +
> +ZeroMQ asynchronous messaging library.
> +
> +This library supports unicast streaming to multiple clients without relying
> on
> +an external server.
> +
> +The required syntax for streaming or connecting to a stream is:
> +@example
> +zmq:tcp://ip-address:port
> +@end example
> +
> +Example:
> +Create a localhost stream on port :
> +@example
> +ffmpeg -re -i input -f mpegts zmq:tcp://127.0.0.1:
> +@end example
> +
> +Multiple clients may connect to the stream using:
> +@example
> +ffplay zmq:tcp://127.0.0.1:
> +@end example
> +
> +Streaming to multiple clients is implemented using a ZMQ Pub-Sub pattern.
> +The server binds to a port and publishes data. Clients connect to the
> +server (IP address/port) and subscribe to the stream. The order in which
> +the server and client start generally does not matter.
> +
> +ffmpeg must be compiled with the --enable-libzmq option to support
> +this protocol option. See the compilation guide
> @url{https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu}
> +for an example on how this option may be set.
> +
> @c man end PROTOCOLS
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index a434b005a4..4a535429b7 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
> OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
> OBJS-$(CONFIG_LIBSRT_PROTOCOL) += libsrt.o
> OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
> +OBJS-$(CONFIG_LIBZMQ_PROTOCOL)+=
> libzmq.o
>
> # libavdevice dependencies
> OBJS-$(CONFIG_IEC61883_INDEV)+= dv.o
> diff --git a/libavformat/libzmq.c b/libavformat/libzmq.c
> new file mode 100644
> index 00..24eebb1fee
> --- /dev/null
> +++ b/libavformat/libzmq.c
> @@ -0,0 +1,159 @@
> +/*
> + * ZMQ URLProtocol
> + *
> + * 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
> +#include "url.h"
> +#include "network.h"
> +#include "libavutil/avstring.h"
> +#include
[FFmpeg-devel] [PATCH] avcodec/libdav1d: allow setting frame size limit in pixels
Signed-off-by: James Almer --- configure | 2 +- libavcodec/libdav1d.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 34c2adb4a4..eceb21b315 100755 --- a/configure +++ b/configure @@ -6196,7 +6196,7 @@ enabled libcelt && require libcelt celt/celt.h celt_decode -lcelt0 && die "ERROR: libcelt must be installed and version must be >= 0.11.0."; } enabled libcaca && require_pkg_config libcaca caca caca.h caca_create_canvas enabled libcodec2 && require libcodec2 codec2/codec2.h codec2_create -lcodec2 -enabled libdav1d && require_pkg_config libdav1d "dav1d >= 0.2.1" "dav1d/dav1d.h" dav1d_version +enabled libdav1d && require_pkg_config libdav1d "dav1d >= 0.4.0" "dav1d/dav1d.h" dav1d_version enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.6.0" davs2.h davs2_decoder_open enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2 dc1394/dc1394.h dc1394_new enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h drmGetVersion diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c index 12c63245f8..8335751b7b 100644 --- a/libavcodec/libdav1d.c +++ b/libavcodec/libdav1d.c @@ -130,6 +130,7 @@ static av_cold int libdav1d_init(AVCodecContext *c) s.allocator.cookie = dav1d; s.allocator.alloc_picture_callback = libdav1d_picture_allocator; s.allocator.release_picture_callback = libdav1d_picture_release; +s.frame_size_limit = c->max_pixels; s.apply_grain = dav1d->apply_grain; s.n_tile_threads = dav1d->tile_threads -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Extract QP from h264 encoded videos
On 05/08/2019 20:20, Juan De León wrote:
> AVQuantizationParams data structure for extracting qp and storing as
> AV_FRAME_DATA_QUANTIZATION_PARAMS AVFrameSideDataType
> design doc:
> https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
>
> Signed-off-by: Juan De León
> ---
> libavutil/Makefile | 2 +
> libavutil/frame.h | 6 ++
> libavutil/quantization_params.c | 83
> libavutil/quantization_params.h | 110
> 4 files changed, 201 insertions(+)
> create mode 100644 libavutil/quantization_params.c
> create mode 100644 libavutil/quantization_params.h
This should be in libavcodec, not libavutil - it relates directly to codecs.
(Indeed, you've ended up having to define a special non-libavcodec enum of
codecs below to make it work in libavutil at all.)
> diff --git a/libavutil/quantization_params.h b/libavutil/quantization_params.h
> new file mode 100644
> index 00..1c1b474dca
> --- /dev/null
> +++ b/libavutil/quantization_params.h
> @@ -0,0 +1,110 @@
> +/*
> + * 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
> + */
> +
> +#ifndef AVUTIL_QUANTIZATION_PARAMS_H
> +#define AVUTIL_QUANTIZATION_PARAMS_H
> +
> +/**
> + * Supported decoders for extraction and filter
> + */
> +enum AVExtractQPSupportedCodecs {
> +AV_EXTRACT_QP_CODEC_ID_H264 = 0,
> +AV_EXTRACT_QP_CODEC_ID_VP9,
> +AV_EXTRACT_QP_CODEC_ID_AV1,
> +};
> +
> +/**
> + * Enums for different codecs to store qp in the type array
> + * Each enum must have an array of strings describing each field
> + * declared in libavutil/quantization_params.c
> + */
> +
> +enum AVQPArrIndexesH264 { // varaible names in spec document
I don't think giving these enums a tag has any value?
> +AV_QP_Y_H264 = 0, // QPy
> +AV_QP_U_H264, // QPcb
There is no variable in the standard with this name, which will confuse
attempts to search for its meaning. I think you mean QPc for the Cb component,
as described in section 8.5.8.
> +AV_QP_V_H264, // QPcr
Likewise here.
> +AV_QP_ARR_SIZE_H264
> +};
> +
> +enum AVQPArrIndexesVP9 { // variable names in spec document
> +AV_QP_YAC_VP9 = 0, // get_dc_quant[][base_q_idx]
This isn't right - get_dc_quant() is a function of one variable, not a
two-dimensional array (confused with dc_qlookup[][] somehow?).
> +AV_QP_YDC_VP9, // get_dc_quant[][base_q_idx+delta_q_y_dc]
> +AV_QP_UVDC_VP9,// get_dc_quant[][base_q_idx+delta_q_uv_dc]
> +AV_QP_UVAC_VP9,// get_ac_quant[][base_q_idx+delta_q_uv_ac]
> +AV_QP_INDEX_YAC_VP9, // base_q_idx
> +AV_QP_INDEX_YDC_VP9, // base_q_idx+delta_q_y_dc
> +AV_QP_INDEX_UVDC_VP9, // base_q_idx+delta_q_uv_dc
> +AV_QP_INDEX_UVAC_VP9, // base_q_idx+delta_q_uv_ac
Why are you including higher-level frame values for VP9 and AV1, but not
including similar ones for H.264?
> +AV_QP_ARR_SIZE_VP9
> +};
> +
> +enum AVQPArrIndexesAV1 { // variable names in spec document
> +AV_QP_YAC_AV1 = 0,// dc_q(base_q_idx)
What is the motivation for AV1 returning the exponential coefficient scaling
values (range 4..29247) rather than the linear parameter (range 0..255) as you
do for H.264?
> +AV_QP_YDC_AV1,// dc_q(base_q_idx+DeltaQYDc)
> +AV_QP_UDC_AV1,// dc_q(base_q_idx+DeltaQUDc)
> +AV_QP_UAC_AV1,// dc_q(base_q_idx+DeltaQUAc)
> +AV_QP_VDC_AV1,// dc_q(base_q_idx+DeltaQVDc)
> +AV_QP_VAC_AV1,// dc_q(base_q_idx+DeltaQVAc)
> +AV_QP_INDEX_YAC_AV1, // base_q_idx
> +AV_QP_INDEX_YDC_AV1, // base_q_idx+DeltaQYDc
> +AV_QP_INDEX_UDC_AV1, // base_q_idx+DeltaQUDc
> +AV_QP_INDEX_UAC_AV1, // base_q_idx+DeltaQUAc
> +AV_QP_INDEX_VDC_AV1, // base_q_idx+DeltaQVDc
> +AV_QP_INDEX_VAC_AV1, // base_q_idx+DeltaQVAc
> +AV_QP_ARR_SIZE_AV1
> +};
The term "QP" is never used in VP9 or AV1. Maybe these could have a less
H.26[45]-oriented name?
> +
> +/**
> + * Update AV_QP_ARR_MAX_SIZE when a new enum is defined that
> + * exceeds the current max size.
> + */
> +
> +#define AV_QP_ARR_MAX_SIZE AV_QP_ARR_SIZE_AV1
Fixing this for all time for a particular
[FFmpeg-devel] [PATCH v4] avcodec/vaapi_encode_h264: add support for a/53 closed caption sei
From: Aman Gupta
Signed-off-by: Aman Gupta
---
libavcodec/vaapi_encode_h264.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f4965d8b09..f3da3ee299 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -39,6 +39,7 @@ enum {
SEI_TIMING = 0x01,
SEI_IDENTIFIER = 0x02,
SEI_RECOVERY_POINT = 0x04,
+SEI_A53_CC = 0x08,
};
// Random (version 4) ISO 11578 UUID.
@@ -72,6 +73,7 @@ typedef struct VAAPIEncodeH264Context {
int sei;
int profile;
int level;
+int enable_a53_cc;
// Derived settings.
int mb_width;
@@ -98,6 +100,8 @@ typedef struct VAAPIEncodeH264Context {
H264RawSEIRecoveryPointsei_recovery_point;
H264RawSEIUserDataUnregistered sei_identifier;
char *sei_identifier_string;
+H264RawSEIUserDataRegistered sei_a53cc;
+void *sei_a53cc_data;
int aud_needed;
int sei_needed;
@@ -251,6 +255,11 @@ static int
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
sei->payload[i].payload.recovery_point = priv->sei_recovery_point;
++i;
}
+if (priv->sei_needed & SEI_A53_CC) {
+sei->payload[i].payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED;
+sei->payload[i].payload.user_data_registered = priv->sei_a53cc;
+++i;
+}
sei->payload_count = i;
av_assert0(sei->payload_count > 0);
@@ -626,7 +635,8 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
VAAPIEncodePicture *prev = pic->prev;
VAAPIEncodeH264Picture *hprev = prev ? prev->priv_data : NULL;
VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
-int i;
+int i, err;
+size_t sei_a53cc_len;
if (pic->type == PICTURE_TYPE_IDR) {
av_assert0(pic->display_order == pic->encode_order);
@@ -700,6 +710,21 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
priv->sei_needed |= SEI_RECOVERY_POINT;
}
+if (priv->enable_a53_cc) {
+av_freep(>sei_a53cc_data);
+err = ff_alloc_a53_sei(pic->input_image, 0, >sei_a53cc_data,
_a53cc_len);
+if (err < 0)
+return err;
+
+if (priv->sei_a53cc_data) {
+priv->sei_a53cc.itu_t_t35_country_code = 181;
+priv->sei_a53cc.data = (uint8_t *)priv->sei_a53cc_data + 1;
+priv->sei_a53cc.data_length = sei_a53cc_len - 1;
+
+priv->sei_needed |= SEI_A53_CC;
+}
+}
+
vpic->CurrPic = (VAPictureH264) {
.picture_id = pic->recon_surface,
.frame_idx = hpic->frame_num,
@@ -1245,6 +1270,7 @@ static av_cold int vaapi_encode_h264_close(AVCodecContext
*avctx)
ff_cbs_fragment_free(priv->cbc, >current_access_unit);
ff_cbs_close(>cbc);
av_freep(>sei_identifier_string);
+av_freep(>sei_a53cc_data);
return ff_vaapi_encode_close(avctx);
}
@@ -1321,6 +1347,8 @@ static const AVOption vaapi_encode_h264_options[] = {
{ LEVEL("6.2", 62) },
#undef LEVEL
+{ "a53cc", "Use A53 Closed Captions (if available)",
OFFSET(enable_a53_cc), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
+
{ NULL },
};
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/fate: Document how to request samples upload access
Am 05.08.19 um 19:06 schrieb Michael Niedermayer: > Signed-off-by: Michael Niedermayer > --- > doc/fate.texi | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/fate.texi b/doc/fate.texi > index 2be61d639c..e04fbfbe43 100644 > --- a/doc/fate.texi > +++ b/doc/fate.texi > @@ -157,6 +157,9 @@ practice generally do not replace, remove or overwrite > files as it likely would > break older checkouts or releases. > Also all needed samples for a commit should be uploaded, ideally 24 > hours, before the push. > +If you need an account for frequently uploading samples or you wish to help > +others do so send mail to ffmpeg-devel. Also please state if you are > available > +to help others upload samples if you request access. Might be better grammar: If you need an account for frequently uploading samples or you wish to help others by doing that send a mail to ffmpeg-devel. -Thilo > > @example > #First update your local samples copy: > ___ 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/6] avcodec/hnm4video: Optimize postprocess_current_frame()
On Mon, Aug 05, 2019 at 11:58:01AM +0200, Tomas Härdin wrote:
> lör 2019-08-03 klockan 18:57 +0200 skrev Michael Niedermayer:
> > On Sat, Aug 03, 2019 at 04:07:22PM +0200, Tomas Härdin wrote:
> > > lör 2019-08-03 klockan 01:49 +0200 skrev Michael Niedermayer:
> > > > -uint32_t x, y, src_x, src_y;
> > > > +uint32_t x, y, src_y;
> > > > +int width = hnm->width;
> > > >
> > > > for (y = 0; y < hnm->height; y++) {
> > > > +uint8_t *dst = hnm->processed + y * width;
> > > > +const uint8_t *src = hnm->current;
> > > > src_y = y - (y % 2);
> > > > -src_x = src_y * hnm->width + (y % 2);
> > > > -for (x = 0; x < hnm->width; x++) {
> > > > -hnm->processed[(y * hnm->width) + x] = hnm-
> > > > > current[src_x];
> > > > -src_x += 2;
> > > > +src += src_y * width + (y % 2);
> > > > +for (x = 0; x < width; x++) {
> > > > +dst[x] = *src;
> > > > +src += 2;
> > >
> > > Looks OK. Maybe telling the compiler that src and dst don't alias
> > > would
> > > be worthwhile?
> >
> > i can add restrict keywords if you want:
> > ?
> >
> > diff --git a/libavcodec/hnm4video.c b/libavcodec/hnm4video.c
> > index 68d0baef6d..1c2501afab 100644
> > --- a/libavcodec/hnm4video.c
> > +++ b/libavcodec/hnm4video.c
> > @@ -121,8 +121,8 @@ static void
> > postprocess_current_frame(AVCodecContext *avctx)
> > int width = hnm->width;
> >
> > for (y = 0; y < hnm->height; y++) {
> > -uint8_t *dst = hnm->processed + y * width;
> > -const uint8_t *src = hnm->current;
> > +uint8_t * restrict dst = hnm->processed + y * width;
> > +const uint8_t * restrict src = hnm->current;
>
> Does it improve performance? Else there's little point
I cannot meassure a performance difference for it its within 1%
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
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] libavcodec: add timer bitstream filter [v2]
Hi Andreas!
On 2019-08-05 17:25 +, Andreas Håkon wrote:
> On Monday, 5 de August de 2019 17:31, Moritz Barsnick
> wrote:
>
[...]
> > > +static const AVClass timer_class = {
> > > + .class_name = "timer",
> >
> > In about half of the existing BSFs, this would be called "timer_bsf". I
> > don't care, I just look at other existing code. ;-)
> >
>
> Good point! Other bitstream filters have this. I'll update it.
> Thank you!
Sorry for the noise. IIRC the naming was previously discussed.
Can't remember the details right now. Unfortunately I don't have
any good name suggestions too :(
This is no objections, but at least to me the name timer sounds
like some autonomous unit/process that can interrupt/call your
process on defined/configured/subscribed intervals. Maybe it's
just me...
...what do others think?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developper: always use braces for statements
On 2019-08-06 22:51 +0200, Nicolas George wrote: > Tomas Härdin (12019-08-06): > > I think they should. See > > Documenting the coding standard and changing it are different matters. I guess a change was intended, because it should be fairly obvious that in the current code base the described style for ifs with a single statement body is barely used. IMHO the only con is that it uses up more vertical space (one line more, when sticking with the brace placement as is) and thus less real code fits on a screen/page. Anyway despite of other things pointed out below. There are additional advantages like making it easier to debug and to extend the code with less changes. In turn making the potentially resulting patches shorter and easier to read. > > https://www.imperialviolet.org/2014/02/22/applebug.html > > test_warn.c: In function ‘test’: > test_warn.c:6:5: warning: this ‘if’ clause does not guard... > [-Wmisleading-indentation] > if (x == y) > ^~ > test_warn.c:8:9: note: ...this statement, but the latter is misleadingly > indented as if it were guarded by the ‘if’ > return -1; > ^~ After all Style is subjective, and thus of course you are right, Nicolas, changes to the coding style should be discussed and not be tunneled through documentation patches. Though I don't think the latter was the intention of the OP. Clearly communicating the request for change would have been better though. Alexander ___ 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] avformat/avio: add avio_print_n_strings and avio_print
Hi Marton!
Not really sure if we need the API, but it definitely looks
handy. Just not sure how often it will used and really result
in clearer or shorter code.
Not opposed to it though; no strong opinion on this one.
Some comments follow inline. No in depth review, just what
came to my mind when reading your patch quickly.
On 2019-08-05 23:34 +0200, Marton Balint wrote:
> These functions can be used to print a variable number of strings
> consecutively
> to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
Small typo here: temporary
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges| 3 +++
> libavformat/avio.h| 16
> libavformat/aviobuf.c | 17 +
> libavformat/version.h | 2 +-
> 4 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 6603a8229e..0b19fb067d 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2019-08-xx - xx - lavf 58.31.100 - avio.h
> + Add avio_print_n_strings and avio_print.
> +
> 2019-07-27 - xx - lavu 56.33.100 - tx.h
>Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
>
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index dcb8dcdf93..ca08907917 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -574,6 +574,22 @@ int avio_feof(AVIOContext *s);
> /** @warning Writes up to 4 KiB per call */
> int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
>
> +/**
> + * Write nb_strings number of strings (const char *) to the context.
> + * @return the total number of bytes written
> + */
> +int avio_print_n_strings(AVIOContext *s, int nb_strings, ...);
> +
> +/**
> + * Write strings (const char *) to the context.
> + * This is a macro around avio_print_n_strings but the number of strings to
> be
> + * written is determined automatically at compile time based on the number of
> + * parameters passed to this macro. For simple string concatenations this
> + * function is more performant than using avio_printf.
> + */
> +#define avio_print(s, ...) \
> +avio_print_n_strings(s, sizeof((const char*[]){__VA_ARGS__}) /
> sizeof(const char*), __VA_ARGS__)
If we don't have this pattern in the code base already, it would
be better to compile and test on bunch of different compilers.
> +
> /**
> * Force flushing of buffered data.
> *
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 2d011027c9..c37b056b64 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -1225,6 +1225,23 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
> return ret;
> }
>
> +int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
> +{
> +va_list ap;
> +int ret = 0;
> +
> +va_start(ap, nb_strings);
> +for (int i = 0; i < nb_strings; i++) {
> +const char *str = va_arg(ap, const char *);
> +int len = strlen(str);
> +avio_write(s, (const unsigned char *)str, len);
> +ret += len;
I first wanted to say you should compute with the count returned
by avio_write; then after diving into libavformat/avio_buf and
reading a cascade of void functions and seeing signalling via
field error in the context which also is sometimes (mis)used
to store a length(?), I withdraw that comment.
Anyway you might consider using void for this function too,
otherwise I guess you should figure out how to do the error
checking inside of this function because if an error occurs
that call might have been partial and the following writes will
effectively not occur. So I'm feeling rather uncomfortable
with returning a count here. Maybe my stance is to narrow.
Alexander
> +}
> +va_end(ap);
> +
> +return ret;
> +}
> +
> int avio_pause(AVIOContext *s, int pause)
> {
> if (!s->read_pause)
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 45efaff9b9..feceaedc08 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
> // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
> Chromium)
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> -#define LIBAVFORMAT_VERSION_MINOR 30
> +#define LIBAVFORMAT_VERSION_MINOR 31
> #define LIBAVFORMAT_VERSION_MICRO 100
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> --
___
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 5/5] avcodec/pafvideo: Only clear frame when it was written to
Aug 6, 2019, 10:30 PM by mich...@niedermayer.cc:
> This avoids unneeded operations and makes the code faster.
>
> Fixes: Timeout (12sec -> 9sec)
> Fixes:
> 15724/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAF_VIDEO_fuzzer-5750842205929472
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pafvideo.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/pafvideo.c b/libavcodec/pafvideo.c
> index 323c662c59..72d5d4b523 100644
> --- a/libavcodec/pafvideo.c
> +++ b/libavcodec/pafvideo.c
> @@ -55,6 +55,7 @@ typedef struct PAFVideoDecContext {
>
> int current_frame;
> uint8_t *frame[4];
> +int dirty[4];
> int frame_size;
> int video_size;
>
> @@ -187,6 +188,7 @@ static int decode_0(PAFVideoDecContext *c, uint8_t *pkt,
> uint8_t code)
> j = bytestream2_get_le16(>gb) + offset;
> if (bytestream2_get_bytes_left(>gb) < (j - offset) * 16)
> return AVERROR_INVALIDDATA;
> +c->dirty[page] = 1;
> do {
> offset++;
> if (dst + 3 * c->width + 4 > dend)
> @@ -329,9 +331,13 @@ static int paf_video_decode(AVCodecContext *avctx, void
> *data,
> c->pic->palette_has_changed = 1;
> }
>
> +c->dirty[c->current_frame] = 1;
> if (code & 0x20)
> -for (i = 0; i < 4; i++)
> -memset(c->frame[i], 0, c->frame_size);
> +for (i = 0; i < 4; i++) {
> +if (c->dirty[i])
> +memset(c->frame[i], 0, c->frame_size);
> +c->dirty[i] = 0;
> +}
>
The extra code doesn't justify that speedup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/avio: remove 4k limit from avio_printf
Marton Balint (12019-08-05):
> We do this by switching to AVBPrint.
>
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges| 3 +++
> libavformat/avio.h| 5 -
> libavformat/aviobuf.c | 15 ++-
> libavformat/version.h | 2 +-
> 4 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 0b19fb067d..fe36c34b90 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2019-08-xx - xx - lavf 58.31.101 - avio.h
> + 4K limit removed from avio_printf.
> +
> 2019-08-xx - xx - lavf 58.31.100 - avio.h
>Add avio_print_n_strings and avio_print.
>
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index ca08907917..f2051da18d 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -571,7 +571,10 @@ int64_t avio_size(AVIOContext *s);
> */
> int avio_feof(AVIOContext *s);
>
> -/** @warning Writes up to 4 KiB per call */
> +/**
> + * Writes a formatted string to the context.
> + * @return number of bytes written, < 0 on error.
> + */
> int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
>
> /**
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index c37b056b64..007fba6410 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -1215,14 +1215,19 @@ int avio_closep(AVIOContext **s)
> int avio_printf(AVIOContext *s, const char *fmt, ...)
> {
> va_list ap;
> -char buf[4096]; /* update doc entry in avio.h if changed */
> -int ret;
> +AVBPrint bp;
>
> +av_bprint_init(, 0, INT_MAX);
INT_MAX? Should be -1 or AV_BPRINT_SIZE_UNLIMITED.
> va_start(ap, fmt);
> -ret = vsnprintf(buf, sizeof(buf), fmt, ap);
> +av_vbprintf(, fmt, ap);
> va_end(ap);
> -avio_write(s, buf, strlen(buf));
> -return ret;
> +if (!av_bprint_is_complete()) {
> +av_bprint_finalize(, NULL);
> +return AVERROR(ENOMEM);
> +}
> +avio_write(s, bp.str, bp.len);
> +av_bprint_finalize(, NULL);
> +return bp.len;
> }
>
> int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
> diff --git a/libavformat/version.h b/libavformat/version.h
> index feceaedc08..9814db8633 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -33,7 +33,7 @@
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> #define LIBAVFORMAT_VERSION_MINOR 31
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> LIBAVFORMAT_VERSION_MINOR, \
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 1/3] avformat/avio: add avio_print_n_strings and avio_print
Marton Balint (12019-08-05): > These functions can be used to print a variable number of strings > consecutively > to the IO context. Unlike av_bprintf, no temporery buffer is necessary. I do not like this very much: the VA design disables type checking, which makes it rather fragile, and the benefit is really minor. Maybe add avio_print_string() to print a single string, and call it as many times as necessary. 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".
[FFmpeg-devel] [PATCH 5/5] avcodec/pafvideo: Only clear frame when it was written to
This avoids unneeded operations and makes the code faster.
Fixes: Timeout (12sec -> 9sec)
Fixes:
15724/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAF_VIDEO_fuzzer-5750842205929472
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pafvideo.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pafvideo.c b/libavcodec/pafvideo.c
index 323c662c59..72d5d4b523 100644
--- a/libavcodec/pafvideo.c
+++ b/libavcodec/pafvideo.c
@@ -55,6 +55,7 @@ typedef struct PAFVideoDecContext {
int current_frame;
uint8_t *frame[4];
+int dirty[4];
int frame_size;
int video_size;
@@ -187,6 +188,7 @@ static int decode_0(PAFVideoDecContext *c, uint8_t *pkt,
uint8_t code)
j = bytestream2_get_le16(>gb) + offset;
if (bytestream2_get_bytes_left(>gb) < (j - offset) * 16)
return AVERROR_INVALIDDATA;
+c->dirty[page] = 1;
do {
offset++;
if (dst + 3 * c->width + 4 > dend)
@@ -329,9 +331,13 @@ static int paf_video_decode(AVCodecContext *avctx, void
*data,
c->pic->palette_has_changed = 1;
}
+c->dirty[c->current_frame] = 1;
if (code & 0x20)
-for (i = 0; i < 4; i++)
-memset(c->frame[i], 0, c->frame_size);
+for (i = 0; i < 4; i++) {
+if (c->dirty[i])
+memset(c->frame[i], 0, c->frame_size);
+c->dirty[i] = 0;
+}
switch (code & 0x0F) {
case 0:
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] avcodec/vp56: Consider the alpha start as end of the prior header
Fixes: Timeout (23sec -> 71ms) Fixes: 15661/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6A_fuzzer-6257865947348992 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/vp56.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c index 72fea3780e..695f37e972 100644 --- a/libavcodec/vp56.c +++ b/libavcodec/vp56.c @@ -572,7 +572,7 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void *data, int *got_frame, VP56Context *s = avctx->priv_data; AVFrame *const p = s->frames[VP56_FRAME_CURRENT]; int remaining_buf_size = avpkt->size; -int av_uninit(alpha_offset); +int alpha_offset = remaining_buf_size; int i, res; int ret; @@ -585,7 +585,7 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void *data, int *got_frame, return AVERROR_INVALIDDATA; } -res = s->parse_header(s, buf, remaining_buf_size); +res = s->parse_header(s, buf, alpha_offset); if (res < 0) return res; -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] [RFC] avcodec/hevcdec: Check for overread in hls_decode_entry()
This checks by adjusting the bytestream end pointer so as to detect
overread without the need of additional code in the innermost loop.
This should be safe as arrays have additional AV_INPUT_BUFFER_PADDING_SIZE
at their end.
This is simple and does not cause a slowdown but it is hackish.
The clean way to check for overread is a counter in the cabac reader.
There may or may not be other ways to infer that overread must occur,
that would require more in depth analysis of the following syntax
elements and their absolute minimum size.
The being a RFC as it is unquestionable not pretty and as i myself
would of course prefer a fast AND pretty solution in case anyone has
ideas ...
Improves: Timeout (190 seconds -> 86 seconds)
Improves:
15702/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5657764929470464
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevcdec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index f1934975d5..6ba07b959a 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2434,6 +2434,7 @@ static int hls_decode_entry(AVCodecContext *avctxt, void
*isFilterThread)
s->tab_slice_address[ctb_addr_rs] = -1;
return ret;
}
+s->HEVClc->cc.bytestream_end += 4;
hls_sao_param(s, x_ctb >> s->ps.sps->log2_ctb_size, y_ctb >>
s->ps.sps->log2_ctb_size);
@@ -2442,6 +2443,8 @@ static int hls_decode_entry(AVCodecContext *avctxt, void
*isFilterThread)
s->filter_slice_edges[ctb_addr_rs] =
s->sh.slice_loop_filter_across_slices_enabled_flag;
more_data = hls_coding_quadtree(s, x_ctb, y_ctb,
s->ps.sps->log2_ctb_size, 0);
+if (s->HEVClc->cc.bytestream >= s->HEVClc->cc.bytestream_end)
+more_data = AVERROR_INVALIDDATA;
if (more_data < 0) {
s->tab_slice_address[ctb_addr_rs] = -1;
return more_data;
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/5] avcodec/tiff: Detect infinite retry loop
Fixes: Timeout (Infinite->Finite)
Fixes:
15706/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5114674904825856
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..8c9e7b0881 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1407,7 +1407,7 @@ static int decode_frame(AVCodecContext *avctx,
GetByteContext stripsizes;
GetByteContext stripdata;
int retry_for_subifd, retry_for_page;
-
+int retry_count = 1;
bytestream2_init(>gb, avpkt->data, avpkt->size);
// parse image header
@@ -1467,6 +1467,10 @@ again:
av_log(avctx, AV_LOG_ERROR, "IFD offset is greater than image
size\n");
return AVERROR_INVALIDDATA;
}
+if (!retry_count--) {
+av_log(avctx, AV_LOG_ERROR, "too many retries\n");
+return AVERROR_INVALIDDATA;
+}
s->sub_ifd = 0;
goto again;
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avcodec/hevc_refs: Optimize 16bit generate_missing_ref()
Fixes: Timeout (86sec -> 8sec)
Fixes:
15702/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5657764929470464
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_refs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 7cf3a55725..7870a72fd6 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -394,7 +394,7 @@ static void mark_ref(HEVCFrame *frame, int flag)
static HEVCFrame *generate_missing_ref(HEVCContext *s, int poc)
{
HEVCFrame *frame;
-int i, x, y;
+int i, y;
frame = alloc_frame(s);
if (!frame)
@@ -407,11 +407,11 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s,
int poc)
frame->frame->buf[i]->size);
} else {
for (i = 0; frame->frame->data[i]; i++)
-for (y = 0; y < (s->ps.sps->height >> s->ps.sps->vshift[i]);
y++)
-for (x = 0; x < (s->ps.sps->width >>
s->ps.sps->hshift[i]); x++) {
-AV_WN16(frame->frame->data[i] + y *
frame->frame->linesize[i] + 2 * x,
-1 << (s->ps.sps->bit_depth - 1));
-}
+for (y = 0; y < (s->ps.sps->height >> s->ps.sps->vshift[i]);
y++) {
+uint8_t *dst = frame->frame->data[i] + y *
frame->frame->linesize[i];
+AV_WN16(dst, 1 << (s->ps.sps->bit_depth - 1));
+av_memcpy_backptr(dst + 2, 2, 2*(s->ps.sps->width >>
s->ps.sps->hshift[i]) - 2);
+}
}
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Extract QP from h264 encoded videos
On Mon, Aug 5, 2019 at 1:07 PM Michael Niedermayer wrote > a macro would still require a major version bump as its a ABI change, if > it changes. > To fix this would probably require a deeper change, we could also > of course just leave it and accept that as the maximum till the next > ABI major bump > I added the macro to at least make it clearer, I don't see any other cleaner solution at the moment. Please review my latest patch and if there are any more concerns please let me know. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developper: always use braces for statements
Tomas Härdin (12019-08-06): > I think they should. See Documenting the coding standard and changing it are different matters. > https://www.imperialviolet.org/2014/02/22/applebug.html test_warn.c: In function ‘test’: test_warn.c:6:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (x == y) ^~ test_warn.c:8:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ return -1; ^~ 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 v3 4/6] avformat/wavdec: s337m support
tis 2019-08-06 klockan 17:08 +0200 skrev Nicolas Gaullier:
> Enabled by AVOption dolbyeprobe
> Requires stereo
> ---
> libavformat/s337m.h | 1 +
> libavformat/wavdec.c | 23 +++
> 2 files changed, 24 insertions(+)
>
> diff --git a/libavformat/s337m.h b/libavformat/s337m.h
> index 0f21a23a30..aff76373d3 100644
> --- a/libavformat/s337m.h
> +++ b/libavformat/s337m.h
> @@ -32,6 +32,7 @@
>
> #define S337M_MIN_OFFSET 1601*4
> #define S337M_MAX_OFFSET 2002*6
> +#define AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE 2*S337M_MAX_OFFSET
>
> #define S337M_PROBE_GUARDBAND_MIN_BYTES 0
> #define DOLBY_E_PHASE_MIN 0.000610
> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> index 52194f54ef..2ef2d9e549 100644
> --- a/libavformat/wavdec.c
> +++ b/libavformat/wavdec.c
> @@ -41,6 +41,9 @@
> #include "riff.h"
> #include "w64.h"
> #include "spdif.h"
> +#if CONFIG_S337M_DEMUXER
> +#include "s337m.h"
> +#endif
>
> typedef struct WAVDemuxContext {
> const AVClass *class;
> @@ -59,6 +62,9 @@ typedef struct WAVDemuxContext {
> int smv_given_first;
> int unaligned; // e.g. if an odd number of bytes ID3 tag was
> prepended
> int rifx; // RIFX: integer byte order for parameters is big
> endian
> +#if CONFIG_S337M_DEMUXER
> +int dolby_e_probe;
> +#endif
> } WAVDemuxContext;
>
> static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
> @@ -593,6 +599,10 @@ break_loop:
> } else if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_MS && st-
> >codecpar->channels > 2) {
> st->codecpar->block_align *= st->codecpar->channels;
> }
> +#if CONFIG_S337M_DEMUXER
> +if (wav->dolby_e_probe)
> +avpriv_s337m_probe_stream((void *)s, s->pb, ,
> FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end -
> avio_tell(pb)));
Missing braces
> +#endif
>
> ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
> ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
> @@ -701,6 +711,7 @@ smv_out:
> wav->data_end = avio_tell(s->pb) + left;
> }
>
> +if (!CONFIG_S337M_DEMUXER || st->codecpar->codec_id !=
> AV_CODEC_ID_DOLBY_E) {
It seems you missed the other part of my comment on this. Keeping the
#if is fine, especially considering..
> size = MAX_SIZE;
> if (st->codecpar->block_align > 1) {
> if (size < st->codecpar->block_align)
> @@ -709,6 +720,11 @@ smv_out:
> }
> size = FFMIN(size, left);
> ret = av_get_packet(s->pb, pkt, size);
> +} else {
> +size = FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, left);
.. this won't compile if S377m is disabled. Just go with the old #if
solution, sorry for causing confusion
> +ret = avpriv_s337m_get_packet((void *)s, s->pb, pkt, size,
> 0);
> +}
> +
> if (ret < 0)
> return ret;
> pkt->stream_index = 0;
> @@ -754,6 +770,9 @@ static int wav_read_seek(AVFormatContext *s,
> #define DEC AV_OPT_FLAG_DECODING_PARAM
> static const AVOption demux_options[] = {
> { "ignore_length", "Ignore length", OFFSET(ignore_length),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
> +#if CONFIG_S337M_DEMUXER
> +{"dolbyeprobe", "Probe Dolby E in pcm/stereo streams",
> OFFSET(dolby_e_probe), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, DEC },
> +#endif
> { NULL },
> };
>
> @@ -895,6 +914,10 @@ static int w64_read_header(AVFormatContext *s)
> st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
>
> avio_seek(pb, data_ofs, SEEK_SET);
> +#if CONFIG_S337M_DEMUXER
> +if (wav->dolby_e_probe)
> +avpriv_s337m_probe_stream((void *)s, s->pb, ,
> FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end -
> avio_tell(pb)));
Braces here too
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developper: always use braces for statements
tis 2019-08-06 klockan 18:33 +0200 skrev Nicolas George: > Nicolas Gaullier (12019-08-06): > > --- > > doc/developer.texi | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index 5c342c9106..1e95768364 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -213,6 +213,14 @@ please use av_log() instead. > > @item > > Casts should be used only when necessary. Unneeded parentheses > > should also be avoided if they don't make the code easier to > > understand. > > + > > +@item > > +Single expression statements after if or while should always use > > braces: > > No they should not. What makes you think that? I think they should. See https://www.imperialviolet.org/2014/02/22/applebug.html /Tomas ___ 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 v3 3/6] avformat/s337m: Make available as subdemuxer
tis 2019-08-06 klockan 17:08 +0200 skrev Nicolas Gaullier:
> +int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream **st, int
> size)
> +{
> +if ( size >= S337M_MIN_OFFSET &&
> +((*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE ||
> (*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S24LE) &&
> + (*st)->codecpar->channels == 2) {
> +uint8_t *buf;
> +int64_t data_offset;
> +int pos = 0;
> +
> +size = FFMIN(size, S337M_MAX_OFFSET);
> +if (!(buf = av_mallocz(size))) {
> +return AVERROR(ENOMEM);
> +}
> +data_offset = avio_tell(pb);
> +if (avio_read(pb, buf, size) != size) {
> +av_freep();
> +return AVERROR(EIO);
> +}
> +avio_seek(pb, data_offset, SEEK_SET);
> +
> +while (pos < size - 9 && !buf[pos]) {
> +pos++;
> +}
> +if (pos < size - 9 && pos >= S337M_PROBE_GUARDBAND_MIN_BYTES) {
I think this 9 should be an 11 or 12..
> +uint64_t state;
> +int data_type = -1, data_size, offset;
> +
> +if ((*st)->codecpar->bits_per_coded_sample == 16) {
> +state = AV_RB32(buf + pos);
> +if (IS_16LE_MARKER(state)) {
> +data_type = AV_RL16(buf + pos + 4);
> +data_size = AV_RL16(buf + pos + 6);
> +}
> +} else if ((*st)->codecpar->bits_per_coded_sample == 24) {
> +state = AV_RB48(buf + pos);
> +if (IS_20LE_MARKER(state) || IS_24LE_MARKER(state)) {
> +data_type = AV_RL24(buf + pos + 6);
> +data_size = AV_RL24(buf + pos + 9);
.. because of this read
> +}
> +}
> +if (data_type >= 0 && !s337m_get_offset_and_codec(avc, state,
> data_type, data_size, , &(*st)->codecpar->codec_id)) {
> +double s337m_phase = pos * 4 /
> (*st)->codecpar->bits_per_coded_sample / (*st)->codecpar->sample_rate;
This isn't quite what I meant by turning it into an integer test :)
this will likely just be rounded to zero. I meant that things could
likely be rearranged so there's no divisions, so the probing isn't
subject to the vaguaries of float rounding
> +#define DOLBY_E_PHASE_MIN 0.000610
> +#define DOLBY_E_PHASE_MAX 0.001050
Where do these phase values come from? Is there a spec somewhere?
I notice the ratios DOLBY_E_PHASE_MAX/DOLBY_E_PHASE_MIN and
S337M_MAX_OFFSET/S337M_MIN_OFFSET are within 9% of eachother, which
doesn't feel like a coincidence
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developper: always use braces for statements
Aug 6, 2019, 5:33 PM by geo...@nsup.org: > Nicolas Gaullier (12019-08-06): > >> --- >> doc/developer.texi | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/doc/developer.texi b/doc/developer.texi >> index 5c342c9106..1e95768364 100644 >> --- a/doc/developer.texi >> +++ b/doc/developer.texi >> @@ -213,6 +213,14 @@ please use av_log() instead. >> @item >> Casts should be used only when necessary. Unneeded parentheses >> should also be avoided if they don't make the code easier to understand. >> + >> +@item >> +Single expression statements after if or while should always use braces: >> > > No they should not. What makes you think that? > +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] doc/developper: always use braces for statements
Nicolas Gaullier (12019-08-06):
> ---
> doc/developer.texi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5c342c9106..1e95768364 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -213,6 +213,14 @@ please use av_log() instead.
> @item
> Casts should be used only when necessary. Unneeded parentheses
> should also be avoided if they don't make the code easier to understand.
> +
> +@item
> +Single expression statements after if or while should always use braces:
No they should not. What makes you think that?
> +@example
> +if (x) @{
> +return;
> +@}
> +@end example
> @end itemize
>
> @section Editor configuration
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".
[FFmpeg-devel] [PATCH] doc/developper: always use braces for statements
---
doc/developer.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index 5c342c9106..1e95768364 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -213,6 +213,14 @@ please use av_log() instead.
@item
Casts should be used only when necessary. Unneeded parentheses
should also be avoided if they don't make the code easier to understand.
+
+@item
+Single expression statements after if or while should always use braces:
+@example
+if (x) @{
+return;
+@}
+@end example
@end itemize
@section Editor configuration
--
2.14.1.windows.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/2] swscale: Fix AltiVec/VSX build with recent GCC
The argument to vec_splat_u16 must be a literal. By making the
function always inline and marking the arguments const, gcc can
turn those into literals, and avoid build errors like:
swscale_vsx.c:165:53: error: argument 1 must be a 5-bit signed literal
Signed-off-by: Daniel Kolesa
---
libswscale/ppc/swscale_vsx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index e6a35d3f78..af8b0e1fa3 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -154,8 +154,10 @@ static void yuv2plane1_nbps_u(const int16_t *src, uint16_t
*dest, int dstW,
}
}
-static void yuv2plane1_nbps_vsx(const int16_t *src, uint16_t *dest, int dstW,
- int big_endian, int output_bits)
+static av_always_inline void yuv2plane1_nbps_vsx(const int16_t *src,
+ uint16_t *dest, int dstW,
+ const int big_endian,
+ const int output_bits)
{
const int dst_u = -(uintptr_t)dest & 7;
const int shift = 15 - output_bits;
@@ -273,8 +275,10 @@ static void yuv2plane1_16_u(const int32_t *src, uint16_t
*dest, int dstW,
}
}
-static void yuv2plane1_16_vsx(const int32_t *src, uint16_t *dest, int dstW,
- int big_endian, int output_bits)
+static av_always_inline void yuv2plane1_16_vsx(const int32_t *src,
+ uint16_t *dest, int dstW,
+ const int big_endian,
+ int output_bits)
{
const int dst_u = -(uintptr_t)dest & 7;
const int shift = 3;
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] swscale: Replace illegal vector keyword usage in altivec code
While this technically compiles in current ffmpeg, this is only
because ffmpeg is compiled in strict ISO C mode, which disables
the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
replaced with a macro inside altivec.h, which defines vector to
be actually __vector, which accepts random types.
Normally, the vector keyword should be used only with plain
scalar non-typedef types, such as unsigned int. But we have the
vec_(s|u)(8|16|32) macros, which can be used in a portable manner,
in util_altivec.h in libavutil.
This is also consistent with other AltiVec/VSX code elsewhere in
the tree.
Signed-off-by: Daniel Kolesa
---
libswscale/ppc/swscale_altivec.c | 36 +-
libswscale/ppc/swscale_vsx.c | 882 +++
2 files changed, 459 insertions(+), 459 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index 6b8cc2c194..1630355f51 100644
--- a/libswscale/ppc/swscale_altivec.c
+++ b/libswscale/ppc/swscale_altivec.c
@@ -153,13 +153,13 @@ static void yuv2plane1_float_altivec(const int32_t *src,
float *dest, int dstW)
const int add = (1 << (shift - 1));
const int clip = (1 << 16) - 1;
const float fmult = 1.0f / 65535.0f;
-const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
-const vector uint32_t vshift = (vector uint32_t) vec_splat_u32(shift);
-const vector uint32_t vlargest = (vector uint32_t) {clip, clip, clip,
clip};
-const vector float vmul = (vector float) {fmult, fmult, fmult, fmult};
-const vector float vzero = (vector float) {0, 0, 0, 0};
-vector uint32_t v;
-vector float vd;
+const vec_u32 vadd = (vec_u32) {add, add, add, add};
+const vec_u32 vshift = (vec_u32) vec_splat_u32(shift);
+const vec_u32 vlargest = (vec_u32) {clip, clip, clip, clip};
+const vec_f vmul = (vec_f) {fmult, fmult, fmult, fmult};
+const vec_f vzero = (vec_f) {0, 0, 0, 0};
+vec_u32 v;
+vec_f vd;
int i;
yuv2plane1_float_u(src, dest, dst_u, 0);
@@ -186,15 +186,15 @@ static void yuv2plane1_float_bswap_altivec(const int32_t
*src, uint32_t *dest, i
const int add = (1 << (shift - 1));
const int clip = (1 << 16) - 1;
const float fmult = 1.0f / 65535.0f;
-const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
-const vector uint32_t vshift = (vector uint32_t) vec_splat_u32(shift);
-const vector uint32_t vlargest = (vector uint32_t) {clip, clip, clip,
clip};
-const vector float vmul = (vector float) {fmult, fmult, fmult, fmult};
-const vector float vzero = (vector float) {0, 0, 0, 0};
-const vector uint32_t vswapbig = (vector uint32_t) {16, 16, 16, 16};
-const vector uint16_t vswapsmall = vec_splat_u16(8);
-vector uint32_t v;
-vector float vd;
+const vec_u32 vadd = (vec_u32) {add, add, add, add};
+const vec_u32 vshift = (vec_u32) vec_splat_u32(shift);
+const vec_u32 vlargest = (vec_u32) {clip, clip, clip, clip};
+const vec_f vmul = (vec_f) {fmult, fmult, fmult, fmult};
+const vec_f vzero = (vec_f) {0, 0, 0, 0};
+const vec_u32 vswapbig = (vec_u32) {16, 16, 16, 16};
+const vec_u16 vswapsmall = vec_splat_u16(8);
+vec_u32 v;
+vec_f vd;
int i;
yuv2plane1_float_bswap_u(src, dest, dst_u, 0);
@@ -208,8 +208,8 @@ static void yuv2plane1_float_bswap_altivec(const int32_t
*src, uint32_t *dest, i
vd = vec_ctf(v, 0);
vd = vec_madd(vd, vmul, vzero);
-vd = (vector float) vec_rl((vector uint32_t) vd, vswapbig);
-vd = (vector float) vec_rl((vector uint16_t) vd, vswapsmall);
+vd = (vec_f) vec_rl((vec_u32) vd, vswapbig);
+vd = (vec_f) vec_rl((vec_u16) vd, vswapsmall);
vec_st(vd, 0, (float *) [i]);
}
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 75dee5ea58..e6a35d3f78 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -103,9 +103,9 @@ static void yuv2plane1_8_vsx(const int16_t *src, uint8_t
*dest, int dstW,
const int dst_u = -(uintptr_t)dest & 15;
int i, j;
LOCAL_ALIGNED(16, int16_t, val, [16]);
-const vector uint16_t shifts = (vector uint16_t) {7, 7, 7, 7, 7, 7, 7, 7};
-vector int16_t vi, vileft, ditherleft, ditherright;
-vector uint8_t vd;
+const vec_u16 shifts = (vec_u16) {7, 7, 7, 7, 7, 7, 7, 7};
+vec_s16 vi, vileft, ditherleft, ditherright;
+vec_u8 vd;
for (j = 0; j < 16; j++) {
val[j] = dither[(dst_u + offset + j) & 7];
@@ -161,11 +161,11 @@ static void yuv2plane1_nbps_vsx(const int16_t *src,
uint16_t *dest, int dstW,
const int shift = 15 - output_bits;
const int add = (1 << (shift - 1));
const int clip = (1 << output_bits) - 1;
-const vector uint16_t vadd = (vector uint16_t) {add, add, add, add, add,
add, add, add};
-const vector uint16_t vswap = (vector uint16_t) vec_splat_u16(big_endian ?
8 : 0);
-const vector uint16_t vshift = (vector uint16_t)
[FFmpeg-devel] [PATCH 0/2] AltiVec/VSX fixes in swscale
The first of these patches fixes the original report as described in https://trac.ffmpeg.org/ticket/7861. The second of the patches fixes the second report in the same ticket (by leigh123linux). Daniel Kolesa (2): swscale: Replace illegal vector keyword usage in altivec code swscale: Fix AltiVec/VSX build with recent GCC libswscale/ppc/swscale_altivec.c | 36 +- libswscale/ppc/swscale_vsx.c | 894 --- 2 files changed, 467 insertions(+), 463 deletions(-) -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 5/6] avformat/wavdec: reindent
---
libavformat/wavdec.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 2ef2d9e549..b9a782bec5 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -712,14 +712,14 @@ smv_out:
}
if (!CONFIG_S337M_DEMUXER || st->codecpar->codec_id !=
AV_CODEC_ID_DOLBY_E) {
-size = MAX_SIZE;
-if (st->codecpar->block_align > 1) {
-if (size < st->codecpar->block_align)
-size = st->codecpar->block_align;
-size = (size / st->codecpar->block_align) * st->codecpar->block_align;
-}
-size = FFMIN(size, left);
-ret = av_get_packet(s->pb, pkt, size);
+size = MAX_SIZE;
+if (st->codecpar->block_align > 1) {
+if (size < st->codecpar->block_align)
+size = st->codecpar->block_align;
+size = (size / st->codecpar->block_align) *
st->codecpar->block_align;
+}
+size = FFMIN(size, left);
+ret = av_get_packet(s->pb, pkt, size);
} else {
size = FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, left);
ret = avpriv_s337m_get_packet((void *)s, s->pb, pkt, size, 0);
--
2.14.1.windows.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 v3 4/6] avformat/wavdec: s337m support
Enabled by AVOption dolbyeprobe
Requires stereo
---
libavformat/s337m.h | 1 +
libavformat/wavdec.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
index 0f21a23a30..aff76373d3 100644
--- a/libavformat/s337m.h
+++ b/libavformat/s337m.h
@@ -32,6 +32,7 @@
#define S337M_MIN_OFFSET 1601*4
#define S337M_MAX_OFFSET 2002*6
+#define AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE 2*S337M_MAX_OFFSET
#define S337M_PROBE_GUARDBAND_MIN_BYTES 0
#define DOLBY_E_PHASE_MIN 0.000610
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 52194f54ef..2ef2d9e549 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -41,6 +41,9 @@
#include "riff.h"
#include "w64.h"
#include "spdif.h"
+#if CONFIG_S337M_DEMUXER
+#include "s337m.h"
+#endif
typedef struct WAVDemuxContext {
const AVClass *class;
@@ -59,6 +62,9 @@ typedef struct WAVDemuxContext {
int smv_given_first;
int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
int rifx; // RIFX: integer byte order for parameters is big endian
+#if CONFIG_S337M_DEMUXER
+int dolby_e_probe;
+#endif
} WAVDemuxContext;
static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
@@ -593,6 +599,10 @@ break_loop:
} else if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_MS &&
st->codecpar->channels > 2) {
st->codecpar->block_align *= st->codecpar->channels;
}
+#if CONFIG_S337M_DEMUXER
+if (wav->dolby_e_probe)
+avpriv_s337m_probe_stream((void *)s, s->pb, ,
FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end - avio_tell(pb)));
+#endif
ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
@@ -701,6 +711,7 @@ smv_out:
wav->data_end = avio_tell(s->pb) + left;
}
+if (!CONFIG_S337M_DEMUXER || st->codecpar->codec_id !=
AV_CODEC_ID_DOLBY_E) {
size = MAX_SIZE;
if (st->codecpar->block_align > 1) {
if (size < st->codecpar->block_align)
@@ -709,6 +720,11 @@ smv_out:
}
size = FFMIN(size, left);
ret = av_get_packet(s->pb, pkt, size);
+} else {
+size = FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, left);
+ret = avpriv_s337m_get_packet((void *)s, s->pb, pkt, size, 0);
+}
+
if (ret < 0)
return ret;
pkt->stream_index = 0;
@@ -754,6 +770,9 @@ static int wav_read_seek(AVFormatContext *s,
#define DEC AV_OPT_FLAG_DECODING_PARAM
static const AVOption demux_options[] = {
{ "ignore_length", "Ignore length", OFFSET(ignore_length),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
+#if CONFIG_S337M_DEMUXER
+{"dolbyeprobe", "Probe Dolby E in pcm/stereo streams",
OFFSET(dolby_e_probe), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, DEC },
+#endif
{ NULL },
};
@@ -895,6 +914,10 @@ static int w64_read_header(AVFormatContext *s)
st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
avio_seek(pb, data_ofs, SEEK_SET);
+#if CONFIG_S337M_DEMUXER
+if (wav->dolby_e_probe)
+avpriv_s337m_probe_stream((void *)s, s->pb, ,
FFMIN(AVPRIV_S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end - avio_tell(pb)));
+#endif
set_spdif(s, wav);
--
2.14.1.windows.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 v3 0/6] avformat: Use s337m subdemux inside wav
Corrected with tomas's feedback The guard band minimum size is now specified in bytes to simplify and restrict the test to an integer checking, it is no big deal for me, and anyway I have set it to 0 by default, just overridable if someone wants to set it. S337M_MAX_RECOMMENDED_PROBE_SIZE is now prefixed with AVPRIV_, it is currently used for the wav demux, and could be helpful anyware else s337m is implemented. I don't feel other macros would be helpful to share; for example, DOLBY_E_PHASE_MIN/MAX represent some minimal core safeguards for logging alarms, but the accurate min/max values that would be really relevant and worth sharing depend on video resolution... Nicolas Gaullier (6): avformat/s337m: Use base AVClass for av_log usage avformat/s337m: Split read_packet/get_packet avformat/s337m: Make available as subdemuxer avformat/wavdec: s337m support avformat/wavdec: reindent avformat/s337m: Test wav subdemux libavformat/s337m.c | 99 +--- libavformat/s337m.h | 65 ++ libavformat/wavdec.c | 37 tests/Makefile | 1 + tests/fate-run.sh| 4 +++ tests/fate/audio.mak | 5 +++ 6 files changed, 184 insertions(+), 27 deletions(-) create mode 100644 libavformat/s337m.h -- 2.14.1.windows.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 v3 3/6] avformat/s337m: Make available as subdemuxer
---
libavformat/s337m.c | 64 -
libavformat/s337m.h | 64 +
2 files changed, 117 insertions(+), 11 deletions(-)
create mode 100644 libavformat/s337m.h
diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 22140297e6..3ec78d36e4 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -21,17 +21,7 @@
#include "libavutil/intreadwrite.h"
#include "avformat.h"
#include "spdif.h"
-
-#define MARKER_16LE 0x72F81F4E
-#define MARKER_20LE 0x20876FF0E154
-#define MARKER_24LE 0x72F8961F4EA5
-
-#define IS_16LE_MARKER(state) ((state & 0x) == MARKER_16LE)
-#define IS_20LE_MARKER(state) ((state & 0xF0F0) == MARKER_20LE)
-#define IS_24LE_MARKER(state) ((state & 0x) == MARKER_24LE)
-#define IS_LE_MARKER(state) (IS_16LE_MARKER(state) ||
IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
-
-int avpriv_s337m_get_packet(void *avc, AVIOContext *pb, AVPacket *pkt, int
size, enum AVCodecID *codec);
+#include "s337m.h"
static int s337m_get_offset_and_codec(void *avc,
uint64_t state,
@@ -129,6 +119,58 @@ static int s337m_probe(const AVProbeData *p)
return 0;
}
+int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream **st, int
size)
+{
+if ( size >= S337M_MIN_OFFSET &&
+((*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE ||
(*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S24LE) &&
+ (*st)->codecpar->channels == 2) {
+uint8_t *buf;
+int64_t data_offset;
+int pos = 0;
+
+size = FFMIN(size, S337M_MAX_OFFSET);
+if (!(buf = av_mallocz(size))) {
+return AVERROR(ENOMEM);
+}
+data_offset = avio_tell(pb);
+if (avio_read(pb, buf, size) != size) {
+av_freep();
+return AVERROR(EIO);
+}
+avio_seek(pb, data_offset, SEEK_SET);
+
+while (pos < size - 9 && !buf[pos]) {
+pos++;
+}
+if (pos < size - 9 && pos >= S337M_PROBE_GUARDBAND_MIN_BYTES) {
+uint64_t state;
+int data_type = -1, data_size, offset;
+
+if ((*st)->codecpar->bits_per_coded_sample == 16) {
+state = AV_RB32(buf + pos);
+if (IS_16LE_MARKER(state)) {
+data_type = AV_RL16(buf + pos + 4);
+data_size = AV_RL16(buf + pos + 6);
+}
+} else if ((*st)->codecpar->bits_per_coded_sample == 24) {
+state = AV_RB48(buf + pos);
+if (IS_20LE_MARKER(state) || IS_24LE_MARKER(state)) {
+data_type = AV_RL24(buf + pos + 6);
+data_size = AV_RL24(buf + pos + 9);
+}
+}
+if (data_type >= 0 && !s337m_get_offset_and_codec(avc, state,
data_type, data_size, , &(*st)->codecpar->codec_id)) {
+double s337m_phase = pos * 4 /
(*st)->codecpar->bits_per_coded_sample / (*st)->codecpar->sample_rate;
+av_log(avc, AV_LOG_INFO, "s337m detected with phase =
%.6fs\n", s337m_phase);
+if ((*st)->codecpar->codec_id == AV_CODEC_ID_DOLBY_E &&
(s337m_phase < DOLBY_E_PHASE_MIN || s337m_phase > DOLBY_E_PHASE_MAX))
+av_log(avc, AV_LOG_WARNING, "Dolby E phase is out of
valid range (%.6fs-%.6fs)\n", DOLBY_E_PHASE_MIN, DOLBY_E_PHASE_MAX);
+}
+}
+av_freep();
+}
+return 0;
+}
+
static int s337m_read_header(AVFormatContext *s)
{
s->ctx_flags |= AVFMTCTX_NOHEADER;
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
new file mode 100644
index 00..0f21a23a30
--- /dev/null
+++ b/libavformat/s337m.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2017 foo86
+ *
+ * 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
+ */
+
+#ifndef AVFORMAT_S337M_H
+#define AVFORMAT_S337M_H
+
+#define MARKER_16LE 0x72F81F4E
+#define MARKER_20LE 0x20876FF0E154
+#define MARKER_24LE 0x72F8961F4EA5
+
+#define IS_16LE_MARKER(state) ((state & 0x) == MARKER_16LE)
+#define IS_20LE_MARKER(state) ((state & 0xF0F0) == MARKER_20LE)
+#define
Re: [FFmpeg-devel] [PATCH v2 5/5] avformat/s337m: Test wav subdemux
tis 2019-08-06 klockan 13:09 + skrev Gaullier Nicolas: > > > +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += > > > +fate-dolby-e-wav > > > +fate-dolby-e-wav: CMD = dolbye2pcm16 -i > > > +$(TARGET_SAMPLES)/dolby_e/512.wav > > > +fate-dolby-e-wav: CMP = oneoff > > > +fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm > > > > This does a floaty comparison, right? Since the Dolby-E decoder is > > float at the moment.. > The test is similar to the current "fate-dolby-e", this new one is > only different because the input dolby E stream is 24 bits (instead > of 16), contains 5.1+2 (instead of 5.1)... and uses wav wrapper of > course. > In both case, the comparison is based on the truncated 16-bit output > of the Dolby-E decoder (but I think the inner precision of the codec > is higher) AND a tolerance of +/-1. There being a tolerance is what I was getting at. Some tests expect bitexact output, which is obviously problematic with a float decoder :) /Tomas ___ 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] web/index: add news entry for release 4.2
On 8/6/2019 10:47 AM, Thomas Volkert wrote: > On 06.08.2019 15:41, James Almer wrote: >> Signed-off-by: James Almer >> --- >> src/index | 47 +++ >> 1 file changed, 47 insertions(+) >> >> diff --git a/src/index b/src/index >> index 0dcf6c1..fafb0e8 100644 >> --- a/src/index >> +++ b/src/index >> @@ -37,6 +37,53 @@ >> News >> >> >> + August 5th, 2019, FFmpeg 4.2 "Ada" >> + >> +FFmpeg 4.2 "Ada", a new >> +major release, is now available! Some of the highlights: >> + >> + >> +tpad filter >> +AV1 decoding support through libdav1d >> +dedot filter >> +chromashift and rgbashift filters >> +freezedetect filter >> +truehd_core bitstream filter >> +dhav demuxer >> +PCM-DVD encoder >> +GIF parser >> +vividas demuxer >> +hymt decoder >> +anlmdn filter >> +maskfun filter >> +hcom demuxer and decoder >> +ARBC decoder >> +libaribb24 based ARIB STD-B24 caption support (profiles A and >> C) >> +Support decoding of HEVC 4:4:4 content in nvdec and cuviddec >> +removed libndi-newtek >> +agm decoder >> +KUX demuxer >> +AV1 frame split bitstream filter >> +lscr decoder >> +lagfun filter >> +asoftclip filter >> +Support decoding of HEVC 4:4:4 content in vdpau >> +colorhold filter >> +xmedian filter >> +asr filter >> +showspatial multimedia filter >> +VP4 video decoder >> +IFV demuxer >> +derain filter >> +deesser filter >> +mov muxer writes tracks with unspecified language instead of >> English by default >> +add support for using clang to compile CUDA kernels >> + >> + >> +We strongly recommend users, distributors, and system integrators to >> +upgrade unless they use current git master. >> + >> + > > > LGTM, I have also compared it with the Changelog file. > > Best regards, > Thomas. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.2
On 06.08.2019 15:41, James Almer wrote: > Signed-off-by: James Almer > --- > src/index | 47 +++ > 1 file changed, 47 insertions(+) > > diff --git a/src/index b/src/index > index 0dcf6c1..fafb0e8 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,53 @@ > News > > > + August 5th, 2019, FFmpeg 4.2 "Ada" > + > +FFmpeg 4.2 "Ada", a new > +major release, is now available! Some of the highlights: > + > + > +tpad filter > +AV1 decoding support through libdav1d > +dedot filter > +chromashift and rgbashift filters > +freezedetect filter > +truehd_core bitstream filter > +dhav demuxer > +PCM-DVD encoder > +GIF parser > +vividas demuxer > +hymt decoder > +anlmdn filter > +maskfun filter > +hcom demuxer and decoder > +ARBC decoder > +libaribb24 based ARIB STD-B24 caption support (profiles A and C) > +Support decoding of HEVC 4:4:4 content in nvdec and cuviddec > +removed libndi-newtek > +agm decoder > +KUX demuxer > +AV1 frame split bitstream filter > +lscr decoder > +lagfun filter > +asoftclip filter > +Support decoding of HEVC 4:4:4 content in vdpau > +colorhold filter > +xmedian filter > +asr filter > +showspatial multimedia filter > +VP4 video decoder > +IFV demuxer > +derain filter > +deesser filter > +mov muxer writes tracks with unspecified language instead of English > by default > +add support for using clang to compile CUDA kernels > + > + > +We strongly recommend users, distributors, and system integrators to > +upgrade unless they use current git master. > + > + LGTM, I have also compared it with the Changelog file. Best regards, Thomas. ___ 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] web/index: add news entry for release 4.2
Signed-off-by: James Almer --- src/index | 47 +++ 1 file changed, 47 insertions(+) diff --git a/src/index b/src/index index 0dcf6c1..fafb0e8 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,53 @@ News + August 5th, 2019, FFmpeg 4.2 "Ada" + +FFmpeg 4.2 "Ada", a new +major release, is now available! Some of the highlights: + + +tpad filter +AV1 decoding support through libdav1d +dedot filter +chromashift and rgbashift filters +freezedetect filter +truehd_core bitstream filter +dhav demuxer +PCM-DVD encoder +GIF parser +vividas demuxer +hymt decoder +anlmdn filter +maskfun filter +hcom demuxer and decoder +ARBC decoder +libaribb24 based ARIB STD-B24 caption support (profiles A and C) +Support decoding of HEVC 4:4:4 content in nvdec and cuviddec +removed libndi-newtek +agm decoder +KUX demuxer +AV1 frame split bitstream filter +lscr decoder +lagfun filter +asoftclip filter +Support decoding of HEVC 4:4:4 content in vdpau +colorhold filter +xmedian filter +asr filter +showspatial multimedia filter +VP4 video decoder +IFV demuxer +derain filter +deesser filter +mov muxer writes tracks with unspecified language instead of English by default +add support for using clang to compile CUDA kernels + + +We strongly recommend users, distributors, and system integrators to +upgrade unless they use current git master. + + November 6th, 2018, FFmpeg 4.1 "al-Khwarizmi" FFmpeg 4.1 "al-Khwarizmi", a new -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 4.2
On 8/6/2019 9:44 AM, Gyan wrote: > > > On 06-08-2019 03:19 AM, Michael Niedermayer wrote: >> On Sun, Aug 04, 2019 at 07:56:00AM +0200, Michael Niedermayer wrote: >>> On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote: On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote: > Hi > > Its quite some time since 4.1 so its probably getting time to branch > 4.2. > > If there are any bugs you want fixed in 4.2 its probably a good > idea to > fix them soon. > > Are there any suggestions for a name ? > If not ill pick something from unused past suggestions. > > If there are no objections i will likely make that release in the > next weeks 4.2 branch made i intend to make the 4.2 release from HEAD of release/4.2 in the next 1-2 weeks please backport any relevant bugfixes to it. >>> Status update: There are a few remaining crashes / security issues >>> which i think >>> we should fix and include before the release. Iam working on that >>> currently. >>> >>> When thats done depends on >>> 1. any delays (bikesheds, distractions, headaches, good weather that >>> makes me ignore >>> this and go for a walk or maybe going for a walk occasionally >>> actually helps >>> my efficiency who knows, ...) >>> 2. influx of more security reports (fuzzer and any human reports), >>> there where >>> several new reports in the last 2 weeks which fall in the "I >>> think that should >>> be fixed before the release" category >>> 3. murphies law and anything else unexpected >> 4.2 release made >> > > Someone with access should post the News entry. > > Gyan I'll send a patch in a bit. ___ 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 5/5] avformat/s337m: Test wav subdemux
>> +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += >> +fate-dolby-e-wav >> +fate-dolby-e-wav: CMD = dolbye2pcm16 -i >> +$(TARGET_SAMPLES)/dolby_e/512.wav >> +fate-dolby-e-wav: CMP = oneoff >> +fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm > >This does a floaty comparison, right? Since the Dolby-E decoder is float at >the moment.. The test is similar to the current "fate-dolby-e", this new one is only different because the input dolby E stream is 24 bits (instead of 16), contains 5.1+2 (instead of 5.1)... and uses wav wrapper of course. In both case, the comparison is based on the truncated 16-bit output of the Dolby-E decoder (but I think the inner precision of the codec is higher) AND a tolerance of +/-1. At the end, I think there is no rounding/platform-dependant issue, if this is your concern. Nicolas ___ 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] FFmpeg 4.2
On 06-08-2019 03:19 AM, Michael Niedermayer wrote: On Sun, Aug 04, 2019 at 07:56:00AM +0200, Michael Niedermayer wrote: On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote: On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote: Hi Its quite some time since 4.1 so its probably getting time to branch 4.2. If there are any bugs you want fixed in 4.2 its probably a good idea to fix them soon. Are there any suggestions for a name ? If not ill pick something from unused past suggestions. If there are no objections i will likely make that release in the next weeks 4.2 branch made i intend to make the 4.2 release from HEAD of release/4.2 in the next 1-2 weeks please backport any relevant bugfixes to it. Status update: There are a few remaining crashes / security issues which i think we should fix and include before the release. Iam working on that currently. When thats done depends on 1. any delays (bikesheds, distractions, headaches, good weather that makes me ignore this and go for a walk or maybe going for a walk occasionally actually helps my efficiency who knows, ...) 2. influx of more security reports (fuzzer and any human reports), there where several new reports in the last 2 weeks which fall in the "I think that should be fixed before the release" category 3. murphies law and anything else unexpected 4.2 release made Someone with access should post the News entry. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/5] avformat/s337m: Use base AVClass for av_log usage
tis 2019-08-06 klockan 13:50 +0200 skrev Nicolas Gaullier:
> s337m_get_offset_and_codec does not make use of
> AVFormatContext: AVClass is enough for logging.
> Will facilitate further use from outside
> ---
> libavformat/s337m.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/s337m.c b/libavformat/s337m.c
> index 48ab66a6da..8956afb23f 100644
> --- a/libavformat/s337m.c
> +++ b/libavformat/s337m.c
> @@ -31,7 +31,7 @@
> #define IS_24LE_MARKER(state) ((state & 0x) == MARKER_24LE)
> #define IS_LE_MARKER(state) (IS_16LE_MARKER(state) ||
> IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
>
> -static int s337m_get_offset_and_codec(AVFormatContext *s,
> +static int s337m_get_offset_and_codec(void *avc,
>uint64_t state,
>int data_type, int data_size,
>int *offset, enum AVCodecID *codec)
> @@ -50,8 +50,8 @@ static int s337m_get_offset_and_codec(AVFormatContext *s,
> }
>
> if ((data_type & 0x1F) != 0x1C) {
> -if (s)
> -avpriv_report_missing_feature(s, "Data type %#x in SMPTE 337M",
> data_type & 0x1F);
> +if (avc)
> +avpriv_report_missing_feature(avc, "Data type %#x in SMPTE
> 337M", data_type & 0x1F);
> return AVERROR_PATCHWELCOME;
> }
>
> @@ -72,8 +72,8 @@ static int s337m_get_offset_and_codec(AVFormatContext *s,
> *offset = 1601;
> break;
> default:
> -if (s)
> -avpriv_report_missing_feature(s, "Dolby E data size %d in SMPTE
> 337M", data_size);
> +if (avc)
> +avpriv_report_missing_feature(avc, "Dolby E data size %d in
> SMPTE 337M", data_size);
> return AVERROR_PATCHWELCOME;
> }
Trivial, so should be OK
/Tomas
___
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 5/5] avformat/s337m: Test wav subdemux
tis 2019-08-06 klockan 13:50 +0200 skrev Nicolas Gaullier: > diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak > index c41958ea2d..0e56d401ea 100644 > --- a/tests/fate/audio.mak > +++ b/tests/fate/audio.mak > @@ -24,6 +24,11 @@ fate-dolby-e: CMD = pcm -i $(TARGET_SAMPLES)/dolby_e/16-11 > fate-dolby-e: CMP = oneoff > fate-dolby-e: REF = $(SAMPLES)/dolby_e/16-11.pcm > > +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += fate-dolby-e-wav > +fate-dolby-e-wav: CMD = dolbye2pcm16 -i $(TARGET_SAMPLES)/dolby_e/512.wav > +fate-dolby-e-wav: CMP = oneoff > +fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm This does a floaty comparison, right? Since the Dolby-E decoder is float at the moment.. /Tomas ___ 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 4/5] avformat/wavdec: s337m support
tis 2019-08-06 klockan 13:50 +0200 skrev Nicolas Gaullier:
> Enabled by AVOption dolbyeprobe
> Requires stereo
> static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
> @@ -593,6 +599,10 @@ break_loop:
> } else if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_MS &&
> st->codecpar->channels > 2) {
> st->codecpar->block_align *= st->codecpar->channels;
> }
> +#if CONFIG_S337M_DEMUXER
> +if (wav->dolby_e_probe)
> +avpriv_s337m_probe_stream((void *)s, s->pb, ,
> FFMIN(S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end - avio_tell(pb)));
> +#endif
>
> ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
> ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
> @@ -701,14 +711,24 @@ smv_out:
> wav->data_end = avio_tell(s->pb) + left;
> }
>
> -size = MAX_SIZE;
> -if (st->codecpar->block_align > 1) {
> -if (size < st->codecpar->block_align)
> -size = st->codecpar->block_align;
> -size = (size / st->codecpar->block_align) *
> st->codecpar->block_align;
> +#if CONFIG_S337M_DEMUXER
> +if (st->codecpar->codec_id != AV_CODEC_ID_DOLBY_E) {
> +#endif
Perhaps prettier:
if (!CONFIG_S337M_DEMUXER || st->codecpar->codec_id !=
AV_CODEC_ID_DOLBY_E)
But then some of the other #ifs should probably change. Hum..
> +size = MAX_SIZE;
> +if (st->codecpar->block_align > 1) {
> +if (size < st->codecpar->block_align)
> +size = st->codecpar->block_align;
> +size = (size / st->codecpar->block_align) *
> st->codecpar->block_align;
> +}
Don't mix functional and indentation changes. Reindent in a separate
patch
> +size = FFMIN(size, left);
> +ret = av_get_packet(s->pb, pkt, size);
> +#if CONFIG_S337M_DEMUXER
> +} else {
If going with the above #if -> if change:
else if (CONFIG_S337M_DEMUXER)
> +size = FFMIN(S337M_MAX_RECOMMENDED_PROBE_SIZE, left);
> +ret = avpriv_s337m_get_packet((void *)s, s->pb, pkt, size, 0);
> }
> -size = FFMIN(size, left);
> -ret = av_get_packet(s->pb, pkt, size);
> +#endif
> +
> if (ret < 0)
> return ret;
> pkt->stream_index = 0;
> @@ -754,6 +774,9 @@ static int wav_read_seek(AVFormatContext *s,
> #define DEC AV_OPT_FLAG_DECODING_PARAM
> static const AVOption demux_options[] = {
> { "ignore_length", "Ignore length", OFFSET(ignore_length),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
> +#if CONFIG_S337M_DEMUXER
> +{"dolbyeprobe", "probe Dolby E in pcm/stereo streams",
> OFFSET(dolby_e_probe), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, DEC },
s/probe/Probe/
/Tomas
___
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 2/5] avformat/s337m: Split read_packet/get_packet
tis 2019-08-06 klockan 13:50 +0200 skrev Nicolas Gaullier: > Prepare use of s337m_get_packet from outside > --- > libavformat/s337m.c | 29 +++-- > 1 file changed, 23 insertions(+), 6 deletions(-) Looks OK /Tomas ___ 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 3/5] avformat/s337m: Make available as subdemuxer
tis 2019-08-06 klockan 13:50 +0200 skrev Nicolas Gaullier:
> +int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream
> **st, int size)
> +{
> +if ( size >= S337M_MIN_OFFSET &&
> +((*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE ||
> (*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S24LE) &&
> + (*st)->codecpar->channels == 2) {
> +uint8_t *buf;
> +int64_t data_offset;
> +int pos = 0;
> +double s337m_phase;
> +
> +size = FFMIN(size, S337M_MAX_OFFSET);
> +if (!(buf = av_mallocz(size)))
> +return AVERROR(ENOMEM);
braces missing here
> +data_offset = avio_tell(pb);
> +if (avio_read(pb, buf, size) != size) {
> +av_freep();
> +return AVERROR(EIO);
> +}
> +avio_seek(pb, data_offset, SEEK_SET);
> +
> +while (pos < size - 9 && !buf[pos])
> +pos++;
and here
> +if (pos < size - 9 &&
> +(s337m_phase = (double)pos * 4 / (*st)->codecpar-
> >bits_per_coded_sample / (*st)->codecpar->sample_rate) >=
> S337M_PHASE_PROBE_MIN) {
Can this be turned into an integer-only test?
I'd put the assignment outside the if since it's a bit involved.
> +#ifndef AVFORMAT_S337M_H
> +#define AVFORMAT_S337M_H
> +
> +#define MARKER_16LE 0x72F81F4E
> +#define MARKER_20LE 0x20876FF0E154
> +#define MARKER_24LE 0x72F8961F4EA5
> +
> +#define IS_16LE_MARKER(state) ((state & 0x) ==
> MARKER_16LE)
> +#define IS_20LE_MARKER(state) ((state & 0xF0F0) ==
> MARKER_20LE)
> +#define IS_24LE_MARKER(state) ((state & 0x) ==
> MARKER_24LE)
> +#define IS_LE_MARKER(state) (IS_16LE_MARKER(state) ||
> IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
> +
> +#define S337M_MIN_OFFSET 1601*4
> +#define S337M_MAX_OFFSET 2002*6
> +
> +#define S337M_PHASE_PROBE_MIN 0.00
> +#define DOLBY_E_PHASE_MIN 0.000610
> +#define DOLBY_E_PHASE_MAX 0.001050
These macros should probably have an AVPRIV_ prefix or similar,
assuming they're visible to users (not sure)
/Tomas
___
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] avutil/mips: refine msa macros CLIP_*.
Changing details as following: 1. Refine CLIP_SH, results are in placed to input vectors. 2. Reimplement the macro CLIP_SH/Wn_0_255. The new macro is more efficient than before. 3. Remove CLIP_SH/Wn_0_255_MAX_SATU. CLIP_SH/Wn_0_255_MAX_SATU and CLIP_SH/Wn_0_255 have the same function. It is not necessary to keep both, use CLIP_SH/Wn_0_255 instead. --- libavcodec/mips/h264dsp_msa.c | 39 +-- libavcodec/mips/h264idct_msa.c | 7 +- libavcodec/mips/hevc_idct_msa.c | 21 +++--- libavcodec/mips/hevc_lpf_sao_msa.c | 132 ++-- libavcodec/mips/hevc_mc_bi_msa.c| 44 ++-- libavcodec/mips/hevc_mc_biw_msa.c | 56 +++ libavcodec/mips/hevc_mc_uniw_msa.c | 40 +-- libavcodec/mips/hevcpred_msa.c | 8 +-- libavcodec/mips/idctdsp_msa.c | 9 +-- libavcodec/mips/qpeldsp_msa.c | 4 +- libavcodec/mips/simple_idct_msa.c | 98 +++--- libavcodec/mips/vp3dsp_idct_msa.c | 68 +++ libavcodec/mips/vp8_idct_msa.c | 5 +- libavcodec/mips/vp9_idct_msa.c | 10 ++- libavutil/mips/generic_macros_msa.h | 119 +--- 15 files changed, 280 insertions(+), 380 deletions(-) diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c index c4ba8c4..dd05982 100644 --- a/libavcodec/mips/h264dsp_msa.c +++ b/libavcodec/mips/h264dsp_msa.c @@ -413,8 +413,7 @@ static void avc_biwgt_8x8_msa(uint8_t *src, uint8_t *dst, int32_t stride, tmp7 = __msa_dpadd_s_h(offset, wgt, vec7); SRA_4V(tmp0, tmp1, tmp2, tmp3, denom); SRA_4V(tmp4, tmp5, tmp6, tmp7, denom); -CLIP_SH4_0_255(tmp0, tmp1, tmp2, tmp3); -CLIP_SH4_0_255(tmp4, tmp5, tmp6, tmp7); +CLIP_SH8_0_255(tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7); PCKEV_B2_UB(tmp1, tmp0, tmp3, tmp2, dst0, dst1); PCKEV_B2_UB(tmp5, tmp4, tmp7, tmp6, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -475,8 +474,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, SRA_4V(temp0, temp1, temp2, temp3, denom); SRA_4V(temp4, temp5, temp6, temp7, denom); -CLIP_SH4_0_255(temp0, temp1, temp2, temp3); -CLIP_SH4_0_255(temp4, temp5, temp6, temp7); +CLIP_SH8_0_255(temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7); PCKEV_B4_UB(temp1, temp0, temp3, temp2, temp5, temp4, temp7, temp6, dst0, dst1, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -531,7 +529,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, temp = p1_or_q1_org_in << 1; \ clip3 = clip3 - temp; \ clip3 = __msa_ave_s_h(p2_or_q2_org_in, clip3);\ -clip3 = CLIP_SH(clip3, negate_tc_in, tc_in); \ +CLIP_SH(clip3, negate_tc_in, tc_in); \ p1_or_q1_out = p1_or_q1_org_in + clip3; \ } @@ -549,7 +547,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta >>= 3;\ \ -delta = CLIP_SH(delta, negate_threshold_in, threshold_in); \ +CLIP_SH(delta, negate_threshold_in, threshold_in); \ \ p0_or_q0_out = p0_or_q0_org_in + delta; \ q0_or_p0_out = q0_or_p0_org_in - delta; \ @@ -598,7 +596,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc); \ \ ILVR_B2_SH(zeros, src1, zeros, src2, res0_r, res1_r);\ \ @@ -662,7 +660,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, q0_sub_p0 <<= 2; \ delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc); \ \
[FFmpeg-devel] [PATCH v2 5/5] avformat/s337m: Test wav subdemux
incl. 24bits 5.1+2 dolby_e decoding
---
tests/Makefile | 1 +
tests/fate-run.sh| 4
tests/fate/audio.mak | 5 +
3 files changed, 10 insertions(+)
diff --git a/tests/Makefile b/tests/Makefile
index 0ef571b067..ebaa465597 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -75,6 +75,7 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER $(lastword
$(1))_DECODER \
$(firstword $(3))_MUXER $(lastword $(3))_DEMUXER)
DEMDEC = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
+DEMDEMDEC = $(call ALLYES, $(1)_DEMUXER $(2)_DEMUXER $(3:%=%_DECODER))
ENCMUX = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER)
DEMMUX = $(call ALLYES, $(1)_DEMUXER $(2)_MUXER)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 2f1991da52..8ecb2b6cfa 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -162,6 +162,10 @@ pcm(){
ffmpeg "$@" -vn -f s16le -
}
+dolbye2pcm16(){
+ffmpeg -dolbyeprobe 1 "$@" -vn -f s16le -
+}
+
fmtstdout(){
fmt=$1
shift 1
diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak
index c41958ea2d..0e56d401ea 100644
--- a/tests/fate/audio.mak
+++ b/tests/fate/audio.mak
@@ -24,6 +24,11 @@ fate-dolby-e: CMD = pcm -i $(TARGET_SAMPLES)/dolby_e/16-11
fate-dolby-e: CMP = oneoff
fate-dolby-e: REF = $(SAMPLES)/dolby_e/16-11.pcm
+FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += fate-dolby-e-wav
+fate-dolby-e-wav: CMD = dolbye2pcm16 -i $(TARGET_SAMPLES)/dolby_e/512.wav
+fate-dolby-e-wav: CMP = oneoff
+fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm
+
FATE_SAMPLES_AUDIO-$(call DEMDEC, DSS, DSS_SP) += fate-dss-lp fate-dss-sp
fate-dss-lp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/lp.dss -frames 30
fate-dss-sp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/sp.dss -frames 30
--
2.14.1.windows.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 v2 3/5] avformat/s337m: Make available as subdemuxer
---
libavformat/s337m.c | 63 +++-
libavformat/s337m.h | 64 +
2 files changed, 116 insertions(+), 11 deletions(-)
create mode 100644 libavformat/s337m.h
diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 22140297e6..47cce4b82b 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -21,17 +21,7 @@
#include "libavutil/intreadwrite.h"
#include "avformat.h"
#include "spdif.h"
-
-#define MARKER_16LE 0x72F81F4E
-#define MARKER_20LE 0x20876FF0E154
-#define MARKER_24LE 0x72F8961F4EA5
-
-#define IS_16LE_MARKER(state) ((state & 0x) == MARKER_16LE)
-#define IS_20LE_MARKER(state) ((state & 0xF0F0) == MARKER_20LE)
-#define IS_24LE_MARKER(state) ((state & 0x) == MARKER_24LE)
-#define IS_LE_MARKER(state) (IS_16LE_MARKER(state) ||
IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
-
-int avpriv_s337m_get_packet(void *avc, AVIOContext *pb, AVPacket *pkt, int
size, enum AVCodecID *codec);
+#include "s337m.h"
static int s337m_get_offset_and_codec(void *avc,
uint64_t state,
@@ -129,6 +119,57 @@ static int s337m_probe(const AVProbeData *p)
return 0;
}
+int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream **st, int
size)
+{
+if ( size >= S337M_MIN_OFFSET &&
+((*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE ||
(*st)->codecpar->codec_id == AV_CODEC_ID_PCM_S24LE) &&
+ (*st)->codecpar->channels == 2) {
+uint8_t *buf;
+int64_t data_offset;
+int pos = 0;
+double s337m_phase;
+
+size = FFMIN(size, S337M_MAX_OFFSET);
+if (!(buf = av_mallocz(size)))
+return AVERROR(ENOMEM);
+data_offset = avio_tell(pb);
+if (avio_read(pb, buf, size) != size) {
+av_freep();
+return AVERROR(EIO);
+}
+avio_seek(pb, data_offset, SEEK_SET);
+
+while (pos < size - 9 && !buf[pos])
+pos++;
+if (pos < size - 9 &&
+(s337m_phase = (double)pos * 4 /
(*st)->codecpar->bits_per_coded_sample / (*st)->codecpar->sample_rate) >=
S337M_PHASE_PROBE_MIN) {
+uint64_t state;
+int data_type = -1, data_size, offset;
+
+if ((*st)->codecpar->bits_per_coded_sample == 16) {
+state = AV_RB32(buf + pos);
+if (IS_16LE_MARKER(state)) {
+data_type = AV_RL16(buf + pos + 4);
+data_size = AV_RL16(buf + pos + 6);
+}
+} else if ((*st)->codecpar->bits_per_coded_sample == 24) {
+state = AV_RB48(buf + pos);
+if (IS_20LE_MARKER(state) || IS_24LE_MARKER(state)) {
+data_type = AV_RL24(buf + pos + 6);
+data_size = AV_RL24(buf + pos + 9);
+}
+}
+if (data_type >= 0 && !s337m_get_offset_and_codec(avc, state,
data_type, data_size, , &(*st)->codecpar->codec_id)) {
+av_log(avc, AV_LOG_INFO, "s337m detected with phase =
%.6fs\n", s337m_phase);
+if ((*st)->codecpar->codec_id == AV_CODEC_ID_DOLBY_E &&
(s337m_phase < DOLBY_E_PHASE_MIN || s337m_phase > DOLBY_E_PHASE_MAX))
+av_log(avc, AV_LOG_WARNING, "Dolby E phase is out of
valid range (%.6fs-%.6fs)\n", DOLBY_E_PHASE_MIN, DOLBY_E_PHASE_MAX);
+}
+}
+av_freep();
+}
+return 0;
+}
+
static int s337m_read_header(AVFormatContext *s)
{
s->ctx_flags |= AVFMTCTX_NOHEADER;
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
new file mode 100644
index 00..bfe2a5d457
--- /dev/null
+++ b/libavformat/s337m.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2017 foo86
+ *
+ * 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
+ */
+
+#ifndef AVFORMAT_S337M_H
+#define AVFORMAT_S337M_H
+
+#define MARKER_16LE 0x72F81F4E
+#define MARKER_20LE 0x20876FF0E154
+#define MARKER_24LE 0x72F8961F4EA5
+
+#define IS_16LE_MARKER(state) ((state & 0x) == MARKER_16LE)
+#define IS_20LE_MARKER(state) ((state & 0xF0F0) == MARKER_20LE)
+#define IS_24LE_MARKER(state) ((state
[FFmpeg-devel] [PATCH v2 1/5] avformat/s337m: Use base AVClass for av_log usage
s337m_get_offset_and_codec does not make use of
AVFormatContext: AVClass is enough for logging.
Will facilitate further use from outside
---
libavformat/s337m.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 48ab66a6da..8956afb23f 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -31,7 +31,7 @@
#define IS_24LE_MARKER(state) ((state & 0x) == MARKER_24LE)
#define IS_LE_MARKER(state) (IS_16LE_MARKER(state) ||
IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
-static int s337m_get_offset_and_codec(AVFormatContext *s,
+static int s337m_get_offset_and_codec(void *avc,
uint64_t state,
int data_type, int data_size,
int *offset, enum AVCodecID *codec)
@@ -50,8 +50,8 @@ static int s337m_get_offset_and_codec(AVFormatContext *s,
}
if ((data_type & 0x1F) != 0x1C) {
-if (s)
-avpriv_report_missing_feature(s, "Data type %#x in SMPTE 337M",
data_type & 0x1F);
+if (avc)
+avpriv_report_missing_feature(avc, "Data type %#x in SMPTE 337M",
data_type & 0x1F);
return AVERROR_PATCHWELCOME;
}
@@ -72,8 +72,8 @@ static int s337m_get_offset_and_codec(AVFormatContext *s,
*offset = 1601;
break;
default:
-if (s)
-avpriv_report_missing_feature(s, "Dolby E data size %d in SMPTE
337M", data_size);
+if (avc)
+avpriv_report_missing_feature(avc, "Dolby E data size %d in SMPTE
337M", data_size);
return AVERROR_PATCHWELCOME;
}
--
2.14.1.windows.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 v2 2/5] avformat/s337m: Split read_packet/get_packet
Prepare use of s337m_get_packet from outside
---
libavformat/s337m.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 8956afb23f..22140297e6 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -31,6 +31,8 @@
#define IS_24LE_MARKER(state) ((state & 0x) == MARKER_24LE)
#define IS_LE_MARKER(state) (IS_16LE_MARKER(state) ||
IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
+int avpriv_s337m_get_packet(void *avc, AVIOContext *pb, AVPacket *pkt, int
size, enum AVCodecID *codec);
+
static int s337m_get_offset_and_codec(void *avc,
uint64_t state,
int data_type, int data_size,
@@ -141,18 +143,20 @@ static void bswap_buf24(uint8_t *data, int size)
FFSWAP(uint8_t, data[0], data[2]);
}
-static int s337m_read_packet(AVFormatContext *s, AVPacket *pkt)
+int avpriv_s337m_get_packet(void *avc, AVIOContext *pb, AVPacket *pkt, int
size, enum AVCodecID *codec)
{
-AVIOContext *pb = s->pb;
uint64_t state = 0;
int ret, data_type, data_size, offset;
-enum AVCodecID codec;
-int64_t pos;
+int64_t pos, orig_pos = avio_tell(pb);
while (!IS_LE_MARKER(state)) {
state = (state << 8) | avio_r8(pb);
if (avio_feof(pb))
return AVERROR_EOF;
+if (avio_tell(pb) - orig_pos + 6 >= size) {
+av_log(avc, AV_LOG_ERROR, "s337m : sync bytes not found at packet
pos=0x%"PRIx64" size_max=%d\n", orig_pos, size);
+return AVERROR_INVALIDDATA;
+}
}
if (IS_16LE_MARKER(state)) {
@@ -165,10 +169,12 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket
*pkt)
pos = avio_tell(pb);
-if ((ret = s337m_get_offset_and_codec(s, state, data_type, data_size,
, )) < 0)
+if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size,
, codec)) < 0)
return ret;
-if ((ret = av_new_packet(pkt, offset)) < 0)
+if (pos - orig_pos > size)
+return AVERROR_INVALIDDATA;
+if (ret = av_new_packet(pkt, FFMIN(offset, size - (pos - orig_pos))) < 0)
return ret;
pkt->pos = pos;
@@ -183,6 +189,17 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket
*pkt)
else
bswap_buf24(pkt->data, pkt->size);
+return 0;
+}
+
+static int s337m_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+enum AVCodecID codec;
+int ret;
+
+if ((ret = avpriv_s337m_get_packet((void *)s, s->pb, pkt,
avio_size(s->pb), )) < 0)
+return ret;
+
if (!s->nb_streams) {
AVStream *st = avformat_new_stream(s, NULL);
if (!st) {
--
2.14.1.windows.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 v2 4/5] avformat/wavdec: s337m support
Enabled by AVOption dolbyeprobe
Requires stereo
---
libavformat/s337m.h | 1 +
libavformat/wavdec.c | 41 ++---
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
index bfe2a5d457..0c3fbf1990 100644
--- a/libavformat/s337m.h
+++ b/libavformat/s337m.h
@@ -32,6 +32,7 @@
#define S337M_MIN_OFFSET 1601*4
#define S337M_MAX_OFFSET 2002*6
+#define S337M_MAX_RECOMMENDED_PROBE_SIZE 2*S337M_MAX_OFFSET
#define S337M_PHASE_PROBE_MIN 0.00
#define DOLBY_E_PHASE_MIN 0.000610
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 52194f54ef..fdcd7233f7 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -41,6 +41,9 @@
#include "riff.h"
#include "w64.h"
#include "spdif.h"
+#if CONFIG_S337M_DEMUXER
+#include "s337m.h"
+#endif
typedef struct WAVDemuxContext {
const AVClass *class;
@@ -59,6 +62,9 @@ typedef struct WAVDemuxContext {
int smv_given_first;
int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
int rifx; // RIFX: integer byte order for parameters is big endian
+#if CONFIG_S337M_DEMUXER
+int dolby_e_probe;
+#endif
} WAVDemuxContext;
static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
@@ -593,6 +599,10 @@ break_loop:
} else if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_MS &&
st->codecpar->channels > 2) {
st->codecpar->block_align *= st->codecpar->channels;
}
+#if CONFIG_S337M_DEMUXER
+if (wav->dolby_e_probe)
+avpriv_s337m_probe_stream((void *)s, s->pb, ,
FFMIN(S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end - avio_tell(pb)));
+#endif
ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
@@ -701,14 +711,24 @@ smv_out:
wav->data_end = avio_tell(s->pb) + left;
}
-size = MAX_SIZE;
-if (st->codecpar->block_align > 1) {
-if (size < st->codecpar->block_align)
-size = st->codecpar->block_align;
-size = (size / st->codecpar->block_align) * st->codecpar->block_align;
+#if CONFIG_S337M_DEMUXER
+if (st->codecpar->codec_id != AV_CODEC_ID_DOLBY_E) {
+#endif
+size = MAX_SIZE;
+if (st->codecpar->block_align > 1) {
+if (size < st->codecpar->block_align)
+size = st->codecpar->block_align;
+size = (size / st->codecpar->block_align) *
st->codecpar->block_align;
+}
+size = FFMIN(size, left);
+ret = av_get_packet(s->pb, pkt, size);
+#if CONFIG_S337M_DEMUXER
+} else {
+size = FFMIN(S337M_MAX_RECOMMENDED_PROBE_SIZE, left);
+ret = avpriv_s337m_get_packet((void *)s, s->pb, pkt, size, 0);
}
-size = FFMIN(size, left);
-ret = av_get_packet(s->pb, pkt, size);
+#endif
+
if (ret < 0)
return ret;
pkt->stream_index = 0;
@@ -754,6 +774,9 @@ static int wav_read_seek(AVFormatContext *s,
#define DEC AV_OPT_FLAG_DECODING_PARAM
static const AVOption demux_options[] = {
{ "ignore_length", "Ignore length", OFFSET(ignore_length),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC },
+#if CONFIG_S337M_DEMUXER
+{"dolbyeprobe", "probe Dolby E in pcm/stereo streams",
OFFSET(dolby_e_probe), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, DEC },
+#endif
{ NULL },
};
@@ -895,6 +918,10 @@ static int w64_read_header(AVFormatContext *s)
st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
avio_seek(pb, data_ofs, SEEK_SET);
+#if CONFIG_S337M_DEMUXER
+if (wav->dolby_e_probe)
+avpriv_s337m_probe_stream((void *)s, s->pb, ,
FFMIN(S337M_MAX_RECOMMENDED_PROBE_SIZE, wav->data_end - avio_tell(pb)));
+#endif
set_spdif(s, wav);
--
2.14.1.windows.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 v2 0/5] avformat: Use s337m subdemux inside wav
As discussed with tomas, this second revision does not include MXF anymore as it raises broader questions yet. The following track would certainly be to developp a generic audio filter that could be used in the general case with any format. Tests samples for fate-suite/dolby_e uploaded here: https://framadrop.org/r/05WkojY4i3#VWCpClXRaLnju5Z479g2qvLgMjD64rCTjYu31kQSAbI= https://framadrop.org/r/dL5lFkBf3P#3lBD0SHINiZsN8BNBHUL2D1lRx17FJurCxzIRpXsMXg= Nicolas Gaullier (5): avformat/s337m: Use base AVClass for av_log usage avformat/s337m: Split read_packet/get_packet avformat/s337m: Make available as subdemuxer avformat/wavdec: s337m support avformat/s337m: Test wav subdemux libavformat/s337m.c | 97 +--- libavformat/s337m.h | 65 +++ libavformat/wavdec.c | 19 ++ tests/Makefile | 1 + tests/fate-run.sh| 4 +++ tests/fate/audio.mak | 5 +++ 6 files changed, 171 insertions(+), 20 deletions(-) create mode 100644 libavformat/s337m.h -- 2.14.1.windows.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] avfilter/af_compand: change error path into warning
Hi, patch attached. 0001-avfilter-af_compand-check-error-condition-into-warni.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avutil/mips: refactor msa SLDI_Bn_0 and SLDI_Bn macros.
Changing details as following: 1. The previous order of parameters are irregular and difficult to understand. Adjust the order of the parameters according to the rule: (RTYPE, input registers, input mask/input index/..., output registers). Most of the existing msa macros follow the rule. 2. Remove the redundant macro SLDI_Bn_0 and use SLDI_Bn instead. --- libavcodec/mips/h264dsp_msa.c | 9 ++-- libavcodec/mips/h264qpel_msa.c | 64 ++-- libavcodec/mips/hevc_lpf_sao_msa.c | 70 --- libavcodec/mips/hevcpred_msa.c | 30 ++--- libavcodec/mips/hpeldsp_msa.c | 66 ++--- libavcodec/mips/me_cmp_msa.c| 8 ++-- libavcodec/mips/qpeldsp_msa.c | 84 ++--- libavcodec/mips/vp8_mc_msa.c| 4 +- libavcodec/mips/vp9_idct_msa.c | 3 +- libavcodec/mips/vp9_lpf_msa.c | 3 +- libavcodec/mips/vp9_mc_msa.c| 16 +++ libavutil/mips/generic_macros_msa.h | 80 ++- 12 files changed, 222 insertions(+), 215 deletions(-) diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c index 89fe399..c4ba8c4 100644 --- a/libavcodec/mips/h264dsp_msa.c +++ b/libavcodec/mips/h264dsp_msa.c @@ -620,7 +620,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, \ out0 = (v16u8) __msa_ilvr_b((v16i8) in1, (v16i8) in0); \ out1 = (v16u8) __msa_sldi_b(zero_m, (v16i8) out0, 2);\ -SLDI_B2_0_UB(out1, out2, out2, out3, 2); \ +SLDI_B2_UB(zero_m, out1, zero_m, out2, 2, out2, out3); \ } #define AVC_LPF_H_2BYTE_CHROMA_422(src, stride, tc_val, alpha, beta, res) \ @@ -1025,7 +1025,8 @@ static void avc_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int32_t stride, ILVR_W2_SB(tmp2, tmp0, tmp3, tmp1, src6, src3); ILVL_W2_SB(tmp2, tmp0, tmp3, tmp1, src1, src5); -SLDI_B4_0_SB(src6, src1, src3, src5, src0, src2, src4, src7, 8); +SLDI_B4_SB(zeros, src6, zeros, src1, zeros, src3, zeros, src5, + 8, src0, src2, src4, src7); p0_asub_q0 = __msa_asub_u_b((v16u8) src2, (v16u8) src3); p1_asub_p0 = __msa_asub_u_b((v16u8) src1, (v16u8) src2); @@ -1116,10 +1117,10 @@ static void avc_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int32_t stride, ILVRL_H2_SH(zeros, dst2_x, tmp2, tmp3); ILVR_W2_UB(tmp2, tmp0, tmp3, tmp1, dst0, dst4); -SLDI_B2_0_UB(dst0, dst4, dst1, dst5, 8); +SLDI_B2_UB(zeros, dst0, zeros, dst4, 8, dst1, dst5); dst2_x = (v16u8) __msa_ilvl_w((v4i32) tmp2, (v4i32) tmp0); dst2_y = (v16u8) __msa_ilvl_w((v4i32) tmp3, (v4i32) tmp1); -SLDI_B2_0_UB(dst2_x, dst2_y, dst3_x, dst3_y, 8); +SLDI_B2_UB(zeros, dst2_x, zeros, dst2_y, 8, dst3_x, dst3_y); out0 = __msa_copy_u_w((v4i32) dst0, 0); out1 = __msa_copy_u_h((v8i16) dst0, 2); diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c index df7e3e2..e435c18 100644 --- a/libavcodec/mips/h264qpel_msa.c +++ b/libavcodec/mips/h264qpel_msa.c @@ -790,8 +790,8 @@ void ff_put_h264_qpel16_mc10_msa(uint8_t *dst, const uint8_t *src, minus5b, res4, res5, res6, res7); DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b, plus20b, res4, res5, res6, res7); -SLDI_B2_SB(src1, src3, src0, src2, src0, src2, 2); -SLDI_B2_SB(src5, src7, src4, src6, src4, src6, 2); +SLDI_B4_SB(src1, src0, src3, src2, src5, src4, src7, src6, 2, + src0, src2, src4, src6); SRARI_H4_SH(res0, res1, res2, res3, 5); SRARI_H4_SH(res4, res5, res6, res7, 5); SAT_SH4_SH(res0, res1, res2, res3, 7); @@ -858,8 +858,8 @@ void ff_put_h264_qpel16_mc30_msa(uint8_t *dst, const uint8_t *src, minus5b, res4, res5, res6, res7); DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b, plus20b, res4, res5, res6, res7); -SLDI_B2_SB(src1, src3, src0, src2, src0, src2, 3); -SLDI_B2_SB(src5, src7, src4, src6, src4, src6, 3); +SLDI_B4_SB(src1, src0, src3, src2, src5, src4, src7, src6, 3, + src0, src2, src4, src6); SRARI_H4_SH(res0, res1, res2, res3, 5); SRARI_H4_SH(res4, res5, res6, res7, 5); SAT_SH4_SH(res0, res1, res2, res3, 7); @@ -911,10 +911,10 @@ void ff_put_h264_qpel8_mc10_msa(uint8_t *dst, const uint8_t *src, VSHF_B2_SB(src6, src6, src7, src7, mask2, mask2, vec10, vec11); DPADD_SB4_SH(vec8, vec9, vec10, vec11, plus20b, plus20b, plus20b, plus20b, res4, res5, res6, res7); -SLDI_B2_SB(src0, src1, src0, src1, src0, src1, 2); -SLDI_B2_SB(src2, src3, src2, src3, src2, src3, 2); -SLDI_B2_SB(src4, src5, src4, src5, src4, src5, 2); -SLDI_B2_SB(src6, src7, src6, src7, src6, src7, 2); +SLDI_B4_SB(src0,
Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
On Mon, Aug 05, 2019 at 09:03:32PM +0200, Paul B Mahol wrote: > On Mon, Aug 5, 2019 at 8:55 PM Michael Niedermayer > wrote: > > > On Mon, Aug 05, 2019 at 05:57:47PM +0200, Paul B Mahol wrote: > > > On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer > > > > > wrote: > > > > > > > On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote: > > > > > On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer > > > > > > > > > wrote: > > > > > > > > > > > On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote: > > > > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > > Behalf > > > > > > > > Of Michael Niedermayer > > > > > > > > Sent: Monday, August 5, 2019 3:45 AM > > > > > > > > To: FFmpeg development discussions and patches > > > > > > > > > > > > > > > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org > > > > > > > > > > > > > > > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote: > > > > > > > > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > > > It seems we do not have a list of people volunteering to do > > > > uploads > > > > > > > > > > to samples. And no place to send such requests to except > > here, > > > > > > where > > > > > > > > > > they sometimes get ignored. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just give everyone with push access right to upload. > > > > > > > > > > > > > > > > Upload currently requires an account on the server, giving > > > > everyone an > > > > > > > > account is a security risk. > > > > > > > > It also doesnt really make sense to give someone access who > > doesnt > > > > need > > > > > > > > access. > > > > > > > > If someone wants to take care of uploads (s)he can have access. > > > > > > > > > > > > > > > > Of course if theres a majority wanting everyone with push > > access to > > > > > > have an > > > > > > > > account on the server, sure we will do that but i dont think > > its a > > > > > > good idea. > > > > > > > > IMHO its always better (aka more secure) if access is kept at a > > > > > > minimum. > > > > > > > > > > > > > > > > besides, it would be a bit of work to keep the list of who has > > push > > > > > > access and > > > > > > > > who has sampeles access synchronized. Its different servers and > > > > > > different > > > > > > > > types of "accounts" > > > > > > > > and the whole point from my point of view is that id like to > > spend > > > > my > > > > > > time on > > > > > > > > other areas on FFmpeg While keeping accounts synchronized > > would be > > > > > > > > probably more work than doing the uploads myself > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > My suggestions would be: > > > > > > > 1. If there is any volunteer to be fate-samples MAINTAINERS, > > tell him > > > > > > how to apply and update the FATE MAINTAINERS list. > > > > > > > > > > > > Iam not sure if there is someone, but if so (s)he should send an > > email > > > > to > > > > > > root or to ffmpeg-devel (again in case he did long ago already) > > > > > > > > > > > > > > > > You are not sure that you gave someone upload access to fate samples? > > > > > Perhaps you forgot? > > > > > > > > iam not sure if someone volunteered and did not receive access as at a > > > > similar time other people suggested that the existing people with > > access > > > > could handle it and no new uploaders where needed. > > > > > > > > So yeah, short form: i forgot the name from an email months or years > > ago. > > > > > > > > > > > Can you check now who have access? > > > > Yes, > > > > compn > > carl > > reimar > > beastd, > > lou > > ubitux > > paul > > hendrik > > derek, > > james almer > > martin vignali > > thilo > > atomnuker > > peter ross > > > Great. > > Rule 777. of security: do not expose all people which can be used to break > security. the list was posted previously already and the public MAINTAINERS file provides a more complete superset for any nasty things but sure you have a point. In a open source project theres the tradeoff about openness though and many times the list of people having access to something is available to the public. > > I did not wanted to list all, just to confirm its me on that list. And you asked "do i have access?" ? or "Can you check now who have access?" I mean you know the admin can check that so the litteral form of the 2nd question makes no sense and a reply to that would not have even awnsered what you want to know. as in "yes i can check" doesnt tell you if you have access. I guess the conclusion is your questions are bizare and I should be more careful security wise. More carefullness about security can never hurt Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk
Re: [FFmpeg-devel] [PATCH] avutil/mips: refactor msa SLDI_Bn_0 and SLDI_Bn macros.
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of gxw
>Sent: Tuesday, August 6, 2019 11:38 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: [FFmpeg-devel] [PATCH] avutil/mips: refactor msa SLDI_Bn_0 and
>SLDI_Bn macros.
>
>Changing details as following:
>1. Modified the parameters order of SLDI_Bn. The previous order of
> parameters is difficult to understand.
>2. Remove the redundant macro SLDI_Bn_0 and use SLDI_Bn instead.
It would be better to add some explanation for the new macro parameter or the
rules it followed in the commit message.
……
>diff --git a/libavutil/mips/generic_macros_msa.h
>b/libavutil/mips/generic_macros_msa.h
>index 9ac0583..a5f8bba 100644
>--- a/libavutil/mips/generic_macros_msa.h
>+++ b/libavutil/mips/generic_macros_msa.h
>@@ -602,67 +602,48 @@
> }
> #define AVER_UB4_UB(...) AVER_UB4(v16u8, __VA_ARGS__)
>
>-/* Description : Immediate number of columns to slide with zero
>- Arguments : Inputs - in0, in1, slide_val
>- Outputs - out0, out1
>+/* Description : Immediate number of columns to slide
>+ Arguments : Inputs - s, d, slide_val
>+ Outputs - out
> Return Type - as per RTYPE
>- Details : Byte elements from 'zero_m' vector are slide into 'in0' by
>+ Details : Byte elements from 'd' vector are slide into 's' by
> number of elements specified by 'slide_val'
> */
>-#define SLDI_B2_0(RTYPE, in0, in1, out0, out1, slide_val) \
>-{ \
>-v16i8 zero_m = { 0 }; \
>-out0 = (RTYPE) __msa_sldi_b((v16i8) zero_m, (v16i8) in0, slide_val); \
>-out1 = (RTYPE) __msa_sldi_b((v16i8) zero_m, (v16i8) in1, slide_val); \
>-}
>-#define SLDI_B2_0_UB(...) SLDI_B2_0(v16u8, __VA_ARGS__)
>-#define SLDI_B2_0_SB(...) SLDI_B2_0(v16i8, __VA_ARGS__)
>-#define SLDI_B2_0_SW(...) SLDI_B2_0(v4i32, __VA_ARGS__)
>-
>-#define SLDI_B3_0(RTYPE, in0, in1, in2, out0, out1, out2, slide_val) \
>-{ \
>-v16i8 zero_m = { 0 }; \
>-SLDI_B2_0(RTYPE, in0, in1, out0, out1, slide_val);\
>-out2 = (RTYPE) __msa_sldi_b((v16i8) zero_m, (v16i8) in2, slide_val); \
>-}
>-#define SLDI_B3_0_UB(...) SLDI_B3_0(v16u8, __VA_ARGS__)
>-#define SLDI_B3_0_SB(...) SLDI_B3_0(v16i8, __VA_ARGS__)
>-
>-#define SLDI_B4_0(RTYPE, in0, in1, in2, in3,\
>- out0, out1, out2, out3, slide_val)\
>-{ \
>-SLDI_B2_0(RTYPE, in0, in1, out0, out1, slide_val); \
>-SLDI_B2_0(RTYPE, in2, in3, out2, out3, slide_val); \
>+#define SLDI_B1(RTYPE, d, s, slide_val, out) \
>+{ \
>+out = (RTYPE) __msa_sldi_b((v16i8) d, (v16i8) s, slide_val); \
> }
>-#define SLDI_B4_0_UB(...) SLDI_B4_0(v16u8, __VA_ARGS__)
>-#define SLDI_B4_0_SB(...) SLDI_B4_0(v16i8, __VA_ARGS__)
>-#define SLDI_B4_0_SH(...) SLDI_B4_0(v8i16, __VA_ARGS__)
>
>-/* Description : Immediate number of columns to slide
>- Arguments : Inputs - in0_0, in0_1, in1_0, in1_1, slide_val
>- Outputs - out0, out1
>- Return Type - as per RTYPE
>- Details : Byte elements from 'in0_0' vector are slide into 'in1_0' by
>- number of elements specified by 'slide_val'
>-*/
>-#define SLDI_B2(RTYPE, in0_0, in0_1, in1_0, in1_1, out0, out1, slide_val) \
>-{ \
>-out0 = (RTYPE) __msa_sldi_b((v16i8) in0_0, (v16i8) in1_0, slide_val); \
>-out1 = (RTYPE) __msa_sldi_b((v16i8) in0_1, (v16i8) in1_1, slide_val); \
>+#define SLDI_B2(RTYPE, d0, s0, d1, s1, slide_val, out0, out1) \
>+{ \
>+SLDI_B1(RTYPE, d0, s0, slide_val, out0)\
>+SLDI_B1(RTYPE, d1, s1, slide_val, out1)\
> }
> #define SLDI_B2_UB(...) SLDI_B2(v16u8, __VA_ARGS__)
> #define SLDI_B2_SB(...) SLDI_B2(v16i8, __VA_ARGS__)
> #define SLDI_B2_SH(...) SLDI_B2(v8i16, __VA_ARGS__)
>+#define SLDI_B2_SW(...) SLDI_B2(v4i32, __VA_ARGS__)
>
>-#define SLDI_B3(RTYPE, in0_0, in0_1, in0_2, in1_0, in1_1, in1_2, \
>-out0, out1, out2, slide_val) \
>-{ \
>-SLDI_B2(RTYPE, in0_0, in0_1, in1_0, in1_1, out0, out1, slide_val) \
>-out2 = (RTYPE) __msa_sldi_b((v16i8) in0_2, (v16i8) in1_2, slide_val); \
>+#define SLDI_B3(RTYPE, d0, s0, d1, s1, d2, s2, slide_val, \
>+out0, out1, out2) \
>+{ \
>+
Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Tuesday, August 6, 2019 16:27
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx for vp9 without destroy va_context
>
> On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu wrote:
> >
> > VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> > changes leads to va context destroy and reinit. This will cause
> > reference frame surface lost and produce garbage.
> >
> > Though refs surface id could be passed to media driver and found in
> > RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
> > new created VaContext could only got an empty RefList.
> >
> > As libva allows re-create surface separately without changing the
> > context, this issue could be handled by only recreating hw_frames_ctx.
> >
> > Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > hw_frame_ctx when dynamic resolution changing happens.
> >
> > Could be verified by:
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavcodec/decode.c| 10 +-
> > libavcodec/internal.h | 1 +
> > libavcodec/pthread_frame.c | 2 ++
> > libavcodec/vaapi_decode.c | 40 ++
> --
> > libavcodec/vaapi_vp9.c | 4
> > 5 files changed, 34 insertions(+), 23 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0863b82..7b15fa5 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1254,7 +1254,6 @@ int
> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> >
> > frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> >
> > -
> > if (frames_ctx->initial_pool_size) {
> > // We guarantee 4 base work surfaces. The function above guarantees
> 1
> > // (the absolute minimum), so add the missing count.
>
> Unrelated whitespace change
There is a redundant whitespace here, so I removed it within this patch.
> > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext *avctx,
> > return AVERROR_PATCHWELCOME;
> > }
> >
> > -if (hwaccel->priv_data_size) {
> > +if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
> > avctx->internal->hwaccel_priv_data =
> > av_mallocz(hwaccel->priv_data_size);
> > if (!avctx->internal->hwaccel_priv_data)
> > @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext *avctx,
> const enum AVPixelFormat *fmt)
> > memcpy(choices, fmt, (n + 1) * sizeof(*choices));
> >
> > for (;;) {
> > -// Remove the previous hwaccel, if there was one.
> > -hwaccel_uninit(avctx);
> > -
> > +// Remove the previous hwaccel, if there was one,
> > +// and no need for keeping.
> > +if (!avctx->internal->hwaccel_priv_data_keeping)
> > +hwaccel_uninit(avctx);
> > user_choice = avctx->get_format(avctx, choices);
> > if (user_choice == AV_PIX_FMT_NONE) {
> > // Explicitly chose nothing, give up.
>
> There could be a dozen special cases how stuff can go wrong here. What
> if get_format actually returns a different format then the one
> currently in use? Or a software format?
> Just removing this alone is not safe.
Didn't quite get your point.
IMHO, avctx->internal->hwaccel_priv_data_keeping won't be set in other cases
other than vaapi_vp9, so this patch won't break the default pipeline, and
hwaccel_uninit(avctx) will always be called.
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index 5096ffa..7adef08 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -188,6 +188,7 @@ typedef struct AVCodecInternal {
> > * hwaccel-specific private data
> > */
> > void *hwaccel_priv_data;
> > +int hwaccel_priv_data_keeping;
> >
> > /**
> > * checks API usage: after codec draining, flush is required to resume
> operation
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index 36ac0ac..6032818 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -283,6 +283,7 @@ static int
> update_context_from_thread(AVCodecContext *dst, AVCodecContext *src,
> > dst->sample_fmt = src->sample_fmt;
> > dst->channel_layout = src->channel_layout;
> > dst->internal->hwaccel_priv_data =
> > src->internal->hwaccel_priv_data;
> > +dst->internal->hwaccel_priv_data_keeping = src->internal-
> >hwaccel_priv_data_keeping;
> >
> > if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
> > (dst->hw_frames_ctx && dst->hw_frames_ctx->data != src-
> >hw_frames_ctx->data)) {
> > @@ -340,6 +341,7
Re: [FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
On Tue, Aug 06, 2019 at 05:42:22AM +, Jacob Siddall wrote: > > On Mon, Aug 05, 2019 at 06:05:29PM +0100, Kieran Kunhya wrote: > > > On Mon, 5 Aug 2019 at 17:10, Michael Niedermayer > > > wrote: > > > > > > > On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote: > > > > > The previous calculation code did not account for the fact that the > > > > > copy_offset for the start of the frame array is at index 0, yet the > > > > > scan line number from the rfc4175 RTP header starts at 1. > > > > > This caused 2 issues to appear: > > > > > - The first scan line was being copied into the array where the second > > > > > scan line should be. This caused the resulting video to have a green > > > > > line at the top of it. > > > > > - Since the packet containing the last scan line would fail the > > > > > calculation, the packet with the RTP marker would not be processed > > > > > which caused a log message saying "Missed previous RTP marker" to be > > > > > outputted for each frame. > > > > > > > > > > Signed-off-by: Jacob Siddall > > > > > --- > > > > > Changes in v2: > > > > > - Don't handle packet if the line number is less than 1 > > > > > > > > > > Section 12 in the VSF technical recommendation TR-03 specifies that > > > > > the > > > > > video scan line numbers should start at 1. > > > > > > > > > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf > > > > > > > > > > > SMPTE 2110-20 says line numbers start at 0. (Yes there are 3 different > > > "standards" for handling the line number because of the geniuses in the > > > broadcast industry). > > > > Jacob, can you look into this ? > > > > should i revert until this is fixed? > > > > Thanks > > Michael, yes lets revert this commit for now and come up with a better > solution that can cater for both starting line number cases. ok, will revert > > I think we could handle this in 1 of 2 ways: > 1. Add some sort of flag which allows overriding of the value which line >numbers start from. >We could leave the default as line numbering starting from 0 (how the >previous code worked). If the flag is set, then the line numbering >starts from 1. > 2. Add code which detects what the value of the first line number is and >use that value for any future processing. This could work by assuming >line numbering starts at 1 until it sees a frame with line 0. This >value would reside in memory so if ffmpeg is restarted, the line >number detection would re-run. > > What are your thoughts on this? It should be automatic, not requiring user input of course. So if the format can be detected somehow thats best Next best simply detecting if the first line is 0 or 1 and keeping that in the nearest instance context probably. Any global variables to hold that state would of course not work as there can be multiple instances running at the same time thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu wrote:
>
> VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> changes leads to va context destroy and reinit. This will cause
> reference frame surface lost and produce garbage.
>
> Though refs surface id could be passed to media driver and found in
> RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
> new created VaContext could only got an empty RefList.
>
> As libva allows re-create surface separately without changing the
> context, this issue could be handled by only recreating hw_frames_ctx.
>
> Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> hw_frame_ctx when dynamic resolution changing happens.
>
> Could be verified by:
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/decode.c| 10 +-
> libavcodec/internal.h | 1 +
> libavcodec/pthread_frame.c | 2 ++
> libavcodec/vaapi_decode.c | 40 ++--
> libavcodec/vaapi_vp9.c | 4
> 5 files changed, 34 insertions(+), 23 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 0863b82..7b15fa5 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1254,7 +1254,6 @@ int ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
>
> frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
>
> -
> if (frames_ctx->initial_pool_size) {
> // We guarantee 4 base work surfaces. The function above guarantees 1
> // (the absolute minimum), so add the missing count.
Unrelated whitespace change
> @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext *avctx,
> return AVERROR_PATCHWELCOME;
> }
>
> -if (hwaccel->priv_data_size) {
> +if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
> avctx->internal->hwaccel_priv_data =
> av_mallocz(hwaccel->priv_data_size);
> if (!avctx->internal->hwaccel_priv_data)
> @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext *avctx, const enum
> AVPixelFormat *fmt)
> memcpy(choices, fmt, (n + 1) * sizeof(*choices));
>
> for (;;) {
> -// Remove the previous hwaccel, if there was one.
> -hwaccel_uninit(avctx);
> -
> +// Remove the previous hwaccel, if there was one,
> +// and no need for keeping.
> +if (!avctx->internal->hwaccel_priv_data_keeping)
> +hwaccel_uninit(avctx);
> user_choice = avctx->get_format(avctx, choices);
> if (user_choice == AV_PIX_FMT_NONE) {
> // Explicitly chose nothing, give up.
There could be a dozen special cases how stuff can go wrong here. What
if get_format actually returns a different format then the one
currently in use? Or a software format?
Just removing this alone is not safe.
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 5096ffa..7adef08 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -188,6 +188,7 @@ typedef struct AVCodecInternal {
> * hwaccel-specific private data
> */
> void *hwaccel_priv_data;
> +int hwaccel_priv_data_keeping;
>
> /**
> * checks API usage: after codec draining, flush is required to resume
> operation
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 36ac0ac..6032818 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -283,6 +283,7 @@ static int update_context_from_thread(AVCodecContext
> *dst, AVCodecContext *src,
> dst->sample_fmt = src->sample_fmt;
> dst->channel_layout = src->channel_layout;
> dst->internal->hwaccel_priv_data = src->internal->hwaccel_priv_data;
> +dst->internal->hwaccel_priv_data_keeping =
> src->internal->hwaccel_priv_data_keeping;
>
> if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
> (dst->hw_frames_ctx && dst->hw_frames_ctx->data !=
> src->hw_frames_ctx->data)) {
> @@ -340,6 +341,7 @@ static int update_context_from_user(AVCodecContext *dst,
> AVCodecContext *src)
> dst->frame_number = src->frame_number;
> dst->reordered_opaque = src->reordered_opaque;
> dst->thread_safe_callbacks = src->thread_safe_callbacks;
> +dst->internal->hwaccel_priv_data_keeping =
> src->internal->hwaccel_priv_data_keeping;
>
> if (src->slice_count && src->slice_offset) {
> if (dst->slice_count < src->slice_count) {
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 69512e1..13f0cf0 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -613,8 +613,10 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
> VAStatus vas;
> int err;
>
> -ctx->va_config = VA_INVALID_ID;
> -ctx->va_context = VA_INVALID_ID;
> +if (!ctx->va_config &&
Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, June 4, 2019 17:11
> To: ffmpeg-devel@ffmpeg.org
> Cc: Mark Thompson
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
>
> > -Original Message-
> > From: Fu, Linjie
> > Sent: Friday, May 31, 2019 08:35
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [PATCH,v2] lavc/vaapi_encode: grow packet if vaMapBuffer
> returns
> > multiple buffers
> >
> > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> map
> > buffer for each slice.
> >
> > Currently, assigning new buffer for pkt when multiple buffer returns
> > from vaMapBuffer will cover the previous encoded pkt data and lead
> > to encode issues.
> >
> > Iterate through the buf_list first to find out the total buffer size
> > needed for the pkt, allocate the whole pkt to avoid repeated reallocation
> > and memcpy, then copy data from each buf to pkt.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > [v2]: allocate the whole pkt to avoid repeated reallocation
> > and memcpy
> >
> > libavcodec/vaapi_encode.c | 18 +-
> > 1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 2dda451..9c9e5dd 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > *avctx,
> > VAAPIEncodeContext *ctx = avctx->priv_data;
> > VACodedBufferSegment *buf_list, *buf;
> > VAStatus vas;
> > +int total_size = 0;
> > +uint8_t *ptr;
> > int err;
> >
> > err = vaapi_encode_wait(avctx, pic);
> > @@ -505,15 +507,21 @@ static int vaapi_encode_output(AVCodecContext
> > *avctx,
> > goto fail;
> > }
> >
> > +for (buf = buf_list; buf; buf = buf->next)
> > +total_size += buf->size;
> > +
> > +err = av_new_packet(pkt, total_size);
> > +ptr = pkt->data;
> > +
> > +if (err < 0)
> > +goto fail_mapped;
> > +
> > for (buf = buf_list; buf; buf = buf->next) {
> > av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > "(status %08x).\n", buf->size, buf->status);
> >
> > -err = av_new_packet(pkt, buf->size);
> > -if (err < 0)
> > -goto fail_mapped;
> > -
> > -memcpy(pkt->data, buf->buf, buf->size);
> > +memcpy(ptr, buf->buf, buf->size);
> > +ptr += buf->size;
> > }
> >
> > if (pic->type == PICTURE_TYPE_IDR)
> > --
> > 2.7.4
>
> Ping?
> This can fix the encoding issue for vaapi_vp8:
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -f
> rawvideo -pix_fmt yuv420p -s:v 1280x720 -i ./input_I420.yuv -vf
> 'format=nv12,hwupload' -c:v vp8_vaapi -rc_mode CQP -g 1 -global_quality 14
> -loop_filter_sharpness 0 -loop_filter_level 0 -vframes 10 -y out.ivf
Media driver will return 2 buffers in fact. The first buffer is
VACodedBufferSegment
buffer which includes encoded output. And the second buffer is extra
VACodedBufferVP9Status.
https://github.com/intel/media-driver/issues/624
Fixes vp8 encoding issues for core platforms(Kaby Lake) and could be verified.
Ping?
- linjie
___
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] avformat/assenc: optimize writing dialogs
On Mon, Aug 5, 2019 at 11:35 PM Marton Balint wrote: > An example where the preivously added API can be useful. > > Also fixes ticket #6390. > > Signed-off-by: Marton Balint > --- > libavformat/assenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/assenc.c b/libavformat/assenc.c > index d50f18feb1..12aadca171 100644 > --- a/libavformat/assenc.c > +++ b/libavformat/assenc.c > @@ -95,7 +95,7 @@ static void purge_dialogues(AVFormatContext *s, int > force) > ass->expected_readorder, dialogue->readorder); > ass->expected_readorder = dialogue->readorder; > } > -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line); > +avio_print(s->pb, "Dialogue: ", dialogue->line, "\r\n"); > if (dialogue == ass->last_added_dialogue) > ass->last_added_dialogue = next; > av_freep(>line); > -- > 2.16.4 > > ___ > 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". Whole patch set looks fine to me, but perhaps you want additional reviews. ___ 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".
