Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
2017-10-04 14:04 GMT+02:00 wm4 : > if you care about what gets merged, discuss it with the > original author on the libav-devel mailing list before it > gets committed. You do realize that you are asking for something that is not possible - did you forget? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter
2017-10-04 10:54 GMT+02:00 Tobias Rapp : > On 27.09.2017 17:20, Carl Eugen Hoyos wrote: >> >> 2017-09-27 15:30 GMT+02:00 Tobias Rapp : >>> >>> Metadata filter output is passed through an Awk script comparing floats >> >> >> Is awk needed on the host or the target system? > > > Awk is started by fate-run.sh directly, so it is needed on the > host system AFAICS. > Note that Awk was already used before in fate-run.sh, which was one > reason why I didn't use the proposed Perl script. Thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: fix id3 chapters
On 10/5/17, Lukas Stabe wrote: > These changes store id3 chapter data in ID3v2ExtraMeta and introduce > ff_id3v2_parse_chapters to parse them into the format context if needed. > > Encoders using ff_id3v2_read, which previously parsed chapters into the > format context automatically, were adjusted to call ff_id3v2_parse_chapters. > --- > libavformat/aiffdec.c | 3 +- > libavformat/asfdec_f.c | 4 +- > libavformat/asfdec_o.c | 4 +- > libavformat/dsfdec.c | 4 +- > libavformat/id3v2.c| 120 > - > libavformat/id3v2.h| 15 +-- > libavformat/iff.c | 3 +- > libavformat/omadec.c | 5 +++ > libavformat/utils.c| 2 + > 9 files changed, 122 insertions(+), 38 deletions(-) > Fix? It wasn't broken at all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding
2017-09-28 11:14 GMT+02:00 Tom Butterworth : > On Wed, 27 Sep 2017 at 16:52 Carl Eugen Hoyos wrote: >> As long as FFmpeg does not have a native alpha-only >> pix_fmt (I am not sure this would have any user-visible >> advantage), single-layer 8bit formats should be decoded >> as gray8. > > This would result in a transcode to another alpha-carrying codec > incorrectly placing the alpha channel in the colour channels, and > setting the alpha channel to solid. Likewise, API users would not > be able to know the channel intentions of the decoded frame. I'd > argue that either a new pixel format be added, or an existing > format which carries alpha should be used, even if that has the > cost of redundant colour channels. Allow me to repeat my question: How would the workflow look like that is easier if we use RGBA instead of gray? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/hap : add HapAlphaOnly decoding/encoding
2017-09-29 11:03 GMT+02:00 Martin Vignali : > 2017-09-28 23:24 GMT+02:00 Carl Eugen Hoyos : > >> 2017-09-28 21:50 GMT+02:00 Martin Vignali : >> >> > After comments about the previous patchs >> >> Please explain how this encoder and decoder can be used >> from the FFmpeg cli: What kind of input could be used, what >> could be done with the output? >> >> I believe you force every user to add an additional filter >> to do anything useful, please convince me that this is wrong. >> >> Hello, > > I didn't design the HAP codec, so my answer mostly follow the comments > of Tom Butterworth. (in the previous discussion of decoding/encoding) But this isn't about the HAP codec, but about its representation within the existing FFmpeg framework. > Like it seems that the Hap Alpha Only is only design to be use > for alpha channel encoding But FFmpeg does not define "only alpha"... > (not to encode gray), it use in this new patch : RGBA > input/output (using only the alpha channel) ... so we have to choose which pix_fmt we can use to emulate "only alpha". I believe gray is not only the most expected one but also the one that makes further work easier than RGBA (that is not "only alpha" either). > In a more general way, HAP is only useful when use with GPU > decoding/compositing (specially in very big resolution, with lot > of video layer) > (not the case in the ffmpeg). Ok. > IMO, the ffmpeg support is mostly interesting to convert hap > file to something else or to check what we can encode with > the ffmpeg hap encoder. I don't disagree (on the contrary), I believe we should make it as easy as possible for users to work with it: Do you believe that it would be easier for users if HAP alpha only is represented as FFmpeg RGBA or gray? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mips: Cleanup unused functions
From: Kaustubh Raste
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/h264qpel_msa.c | 746
libavcodec/mips/hevc_mc_uniw_msa.c | 67
libavcodec/mips/hevcdsp_msa.c | 50 ---
3 files changed, 863 deletions(-)
diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index 0b42bc4..afc0183 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -159,300 +159,6 @@ static const uint8_t luma_mask_arr[16 * 8] = {
out0_m; \
} )
-static void avc_luma_hz_4w_msa(const uint8_t *src, int32_t src_stride,
- uint8_t *dst, int32_t dst_stride,
- int32_t height)
-{
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3;
-v8i16 res0, res1;
-v16u8 out;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-
-LD_SB3(&luma_mask_arr[48], 16, mask0, mask1, mask2);
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
-HADD_SB2_SH(vec0, vec1, res0, res1);
-VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec2, vec3);
-DPADD_SB2_SH(vec2, vec3, minus5b, minus5b, res0, res1);
-VSHF_B2_SB(src0, src1, src2, src3, mask2, mask2, vec4, vec5);
-DPADD_SB2_SH(vec4, vec5, plus20b, plus20b, res0, res1);
-SRARI_H2_SH(res0, res1, 5);
-SAT_SH2_SH(res0, res1, 7);
-out = PCKEV_XORI128_UB(res0, res1);
-ST4x4_UB(out, out, 0, 1, 2, 3, dst, dst_stride);
-dst += (4 * dst_stride);
-}
-}
-
-static void avc_luma_hz_8w_msa(const uint8_t *src, int32_t src_stride,
- uint8_t *dst, int32_t dst_stride,
- int32_t height)
-{
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3;
-v8i16 res0, res1, res2, res3;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 vec6, vec7, vec8, vec9, vec10, vec11;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-v16u8 out0, out1;
-
-LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
-
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec1);
-VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec2, vec3);
-HADD_SB4_SH(vec0, vec1, vec2, vec3, res0, res1, res2, res3);
-VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec4, vec5);
-VSHF_B2_SB(src2, src2, src3, src3, mask1, mask1, vec6, vec7);
-DPADD_SB4_SH(vec4, vec5, vec6, vec7, minus5b, minus5b, minus5b,
minus5b,
- res0, res1, res2, res3);
-VSHF_B2_SB(src0, src0, src1, src1, mask2, mask2, vec8, vec9);
-VSHF_B2_SB(src2, src2, src3, src3, mask2, mask2, vec10, vec11);
-DPADD_SB4_SH(vec8, vec9, vec10, vec11, plus20b, plus20b, plus20b,
- plus20b, res0, res1, res2, res3);
-SRARI_H4_SH(res0, res1, res2, res3, 5);
-SAT_SH4_SH(res0, res1, res2, res3, 7);
-out0 = PCKEV_XORI128_UB(res0, res1);
-out1 = PCKEV_XORI128_UB(res2, res3);
-ST8x4_UB(out0, out1, dst, dst_stride);
-dst += (4 * dst_stride);
-}
-}
-
-static void avc_luma_hz_16w_msa(const uint8_t *src, int32_t src_stride,
-uint8_t *dst, int32_t dst_stride,
-int32_t height)
-{
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7;
-v8i16 res0, res1, res2, res3, res4, res5, res6, res7;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 vec6, vec7, vec8, vec9, vec10, vec11;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-
-LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
-
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB2(src, 8, src0, src1);
-src += src_stride;
-LD_SB2(src, 8, src2, src3);
-src += src_stride;
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec3);
-VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec6, vec9);
-VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec1, vec4);
-VSHF_B2_SB(src2, src2, src3, src3, mask1, mask1, vec7, vec10);
-VSHF_B2_SB(src0, src0, src1, src1, mask2, mask2, vec2, vec5);
-VSHF_B2_SB(src2, src2, src3, src3, mask2, mask2, vec8, vec11);
-HADD_SB4_SH(vec0, ve
Re: [FFmpeg-devel] [PATCH 2/2] avformat/wavenc: skip writing peak-of-peaks position when writing peaks only
On 05.10.2017 00:05, Michael Niedermayer wrote: On Wed, Oct 04, 2017 at 10:33:11AM +0200, Tobias Rapp wrote: On 30.09.2017 02:48, Michael Niedermayer wrote: On Fri, Sep 29, 2017 at 05:08:16PM +0200, Tobias Rapp wrote: Signed-off-by: Tobias Rapp --- libavformat/wavenc.c | 5 - tests/ref/lavf/wav_peak_only | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) The commit message doest say why this chnage is done As I understand the BWF peak envelope chunk definition in EBU Tech 3285 - Supplement 3 the "dwPosPeakOfPeaks" field contains the (absolute) byte position of the peak audio sample within the _data_ chunk: """ The peak-of-peaks is first audio sample whose absolute value is the maximum value of the entire audio file. Rather than storing the peak-of-peaks as a sample value, the position of the peak of the peaks is stored. In other words, an audio sample frame index is stored. An application then knows where to read the peak of the peaks in the audio file. It would be more difficult to store a value for peak since this is dependant on the binary format of the audio samples (integers, floats, double...). If the value is 0x, then that means that the peak of the peaks is unknown. """ As a peak-only file doesn't contain a data chunk it would make no sense to store the data position. But when looking at FFmpeg's implementation within wavenc.c I notice now, that the implementation is using a totally different interpretation of the spec and stores the peak frame index (position relative to peak chunk data) instead. In my opinion the current implementation of "dwPosPeakOfPeaks" is wrong and the patch should actually be changed to always write "-1" unconditionally until the peak-of-peaks feature is implemented correctly. See attached patch update. have you confirmed that files not created by ffmpeg mismatch what we do ? If so this is ok but please bump the micro version of libavformat every time this muxer behavior changes. So demuxers can know what they are dealing with Actually our own software (NOA MediaButler) always sets this field to "-1" when writing BWF files exactly due to the hassle of calculating the value. And when reading a Wave file for normalization the peak-of-peaks is re-calculated within the target time-range anyway, so this field is ignored. Unfortunately I don't have access to other software that writes "levl" chunks but am putting Georg Lippitsch on CC as he did the implementation of BWF features within wavenc.c . I don't care if this patch is dropped, just stumbled over it when comparing FFmpeg BWF output to files of our own software and to the BWF specs. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: fix id3 chapters
> On 5. Oct 2017, at 09:08, Paul B Mahol wrote: > > On 10/5/17, Lukas Stabe wrote: >> These changes store id3 chapter data in ID3v2ExtraMeta and introduce >> ff_id3v2_parse_chapters to parse them into the format context if needed. >> >> Encoders using ff_id3v2_read, which previously parsed chapters into the >> format context automatically, were adjusted to call ff_id3v2_parse_chapters. >> --- >> libavformat/aiffdec.c | 3 +- >> libavformat/asfdec_f.c | 4 +- >> libavformat/asfdec_o.c | 4 +- >> libavformat/dsfdec.c | 4 +- >> libavformat/id3v2.c| 120 >> - >> libavformat/id3v2.h| 15 +-- >> libavformat/iff.c | 3 +- >> libavformat/omadec.c | 5 +++ >> libavformat/utils.c| 2 + >> 9 files changed, 122 insertions(+), 38 deletions(-) >> > > > Fix? It wasn't broken at all. It was. I forgot to link the issue in the commit message, but see here https://trac.ffmpeg.org/ticket/6558 for details on how it was broken and when. signature.asc Description: Message signed with OpenPGP ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/wavenc: replace literal numbers with enum constants
On 30.09.2017 02:44, Michael Niedermayer wrote: On Fri, Sep 29, 2017 at 05:08:15PM +0200, Tobias Rapp wrote: Signed-off-by: Tobias Rapp --- libavformat/wavenc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) LGTM Pushed, thanks for review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Thu, 5 Oct 2017 09:02:10 +0200 Carl Eugen Hoyos wrote: > 2017-10-04 14:04 GMT+02:00 wm4 : > > > if you care about what gets merged, discuss it with the > > original author on the libav-devel mailing list before it > > gets committed. > > You do realize that you are asking for something that > is not possible - did you forget? Yes, I forgot that it's impossible for you to communicate like a normal human being. Sorry I can't deal with all your bullshit all at once. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/srt: add Haivision SRT protocol
protocol requires libsrt (https://github.com/Haivision/srt) to be
installed
Signed-off-by: Nablet Developer
---
configure |5 +
libavformat/Makefile|1 +
libavformat/protocols.c |1 +
libavformat/srt.c | 1105 +++
libavformat/url.h |4 +
5 files changed, 1116 insertions(+)
create mode 100644 libavformat/srt.c
diff --git a/configure b/configure
index 391c141..d955805 100755
--- a/configure
+++ b/configure
@@ -301,6 +301,7 @@ External library support:
on OSX if openssl and gnutls are not used
[autodetect]
--disable-xlib disable xlib [autodetect]
--disable-zlib disable zlib [autodetect]
+ --enable-libsrt enable libsrt [autodetect]
The following libraries provide various hardware acceleration features:
--disable-audiotoolbox disable Apple AudioToolbox code [autodetect]
@@ -1638,6 +1639,7 @@ EXTERNAL_LIBRARY_LIST="
openal
opencl
opengl
+libsrt
"
HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3170,6 +3172,8 @@ tls_securetransport_protocol_select="tcp_protocol"
tls_protocol_deps_any="tls_schannel_protocol tls_securetransport_protocol
tls_gnutls_protocol tls_openssl_protocol"
udp_protocol_select="network"
udplite_protocol_select="network"
+srt_protocol_select="network"
+srt_protocol_deps="libsrt"
unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
@@ -6076,6 +6080,7 @@ enabled rkmpp && { { require_pkg_config
rockchip_mpp rockchip_mpp ro
{ enabled libdrm ||
die "ERROR: rkmpp requires --enable-libdrm"; }
}
+enabled libsrt && require_pkg_config srt srt/srt.h srt_socket
if enabled gcrypt; then
GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index df709c29..695cf51 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -593,6 +593,7 @@ OBJS-$(CONFIG_TLS_SCHANNEL_PROTOCOL) += tls_schannel.o
tls.o
OBJS-$(CONFIG_TLS_SECURETRANSPORT_PROTOCOL) += tls_securetransport.o tls.o
OBJS-$(CONFIG_UDP_PROTOCOL) += udp.o
OBJS-$(CONFIG_UDPLITE_PROTOCOL) += udp.o
+OBJS-$(CONFIG_SRT_PROTOCOL) += srt.o
OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
# libavdevice dependencies
diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 8d3555e..8b4fded 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -62,6 +62,7 @@ extern const URLProtocol ff_tls_securetransport_protocol;
extern const URLProtocol ff_tls_openssl_protocol;
extern const URLProtocol ff_udp_protocol;
extern const URLProtocol ff_udplite_protocol;
+extern const URLProtocol ff_srt_protocol;
extern const URLProtocol ff_unix_protocol;
extern const URLProtocol ff_librtmp_protocol;
extern const URLProtocol ff_librtmpe_protocol;
diff --git a/libavformat/srt.c b/libavformat/srt.c
new file mode 100644
index 000..5950a50
--- /dev/null
+++ b/libavformat/srt.c
@@ -0,0 +1,1105 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * SRT protocol
+ */
+
+#define _DEFAULT_SOURCE
+#define _BSD_SOURCE /* Needed for using struct ip_mreq with recent glibc */
+
+#include "avformat.h"
+#include "avio_internal.h"
+#include "libavutil/avassert.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/fifo.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/log.h"
+#include "libavutil/time.h"
+#include "internal.h"
+#include "network.h"
+#include "os_support.h"
+#include "url.h"
+
+#ifdef __APPLE__
+#include "TargetConditionals.h"
+#endif
+
+#include
+#include
+
+
+#if HAVE_PTHREAD_CANCEL
+#include
+#endif
+
+#ifndef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 0
+#endif
+
+#ifndef IPV6_ADD_MEMBERSHIP
+#define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
+#define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
+#endif
+
+#define UDP_TX_BUF_SIZE 32768
+#define UDP_MAX_PKT_SIZE 65536
+#define UDP_HEADER_SIZE 8
+
+typedef struct SRTContext {
+const AVClass *class;
+SRTSOCKET srt_fd;
+int buffer_size;
+int pkt_size;
+
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Cleanup unused functions
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Thursday, October 5, 2017 1:15 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Cleanup unused functions
From: Kaustubh Raste
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/h264qpel_msa.c | 746
libavcodec/mips/hevc_mc_uniw_msa.c | 67
libavcodec/mips/hevcdsp_msa.c | 50 ---
3 files changed, 863 deletions(-)
diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index 0b42bc4..afc0183 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -159,300 +159,6 @@ static const uint8_t luma_mask_arr[16 * 8] = {
out0_m; \
} )
-static void avc_luma_hz_4w_msa(const uint8_t *src, int32_t src_stride,
- uint8_t *dst, int32_t dst_stride,
- int32_t height)
-{
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3;
-v8i16 res0, res1;
-v16u8 out;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-
-LD_SB3(&luma_mask_arr[48], 16, mask0, mask1, mask2);
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
-HADD_SB2_SH(vec0, vec1, res0, res1);
-VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec2, vec3);
-DPADD_SB2_SH(vec2, vec3, minus5b, minus5b, res0, res1);
-VSHF_B2_SB(src0, src1, src2, src3, mask2, mask2, vec4, vec5);
-DPADD_SB2_SH(vec4, vec5, plus20b, plus20b, res0, res1);
-SRARI_H2_SH(res0, res1, 5);
-SAT_SH2_SH(res0, res1, 7);
-out = PCKEV_XORI128_UB(res0, res1);
-ST4x4_UB(out, out, 0, 1, 2, 3, dst, dst_stride);
-dst += (4 * dst_stride);
-}
-}
-
-static void avc_luma_hz_8w_msa(const uint8_t *src, int32_t src_stride,
- uint8_t *dst, int32_t dst_stride,
- int32_t height)
-{
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3;
-v8i16 res0, res1, res2, res3;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 vec6, vec7, vec8, vec9, vec10, vec11;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-v16u8 out0, out1;
-
-LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
-
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec1);
-VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec2, vec3);
-HADD_SB4_SH(vec0, vec1, vec2, vec3, res0, res1, res2, res3);
-VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec4, vec5);
-VSHF_B2_SB(src2, src2, src3, src3, mask1, mask1, vec6, vec7);
-DPADD_SB4_SH(vec4, vec5, vec6, vec7, minus5b, minus5b, minus5b,
minus5b,
- res0, res1, res2, res3);
-VSHF_B2_SB(src0, src0, src1, src1, mask2, mask2, vec8, vec9);
-VSHF_B2_SB(src2, src2, src3, src3, mask2, mask2, vec10, vec11);
-DPADD_SB4_SH(vec8, vec9, vec10, vec11, plus20b, plus20b, plus20b,
- plus20b, res0, res1, res2, res3);
-SRARI_H4_SH(res0, res1, res2, res3, 5);
-SAT_SH4_SH(res0, res1, res2, res3, 7);
-out0 = PCKEV_XORI128_UB(res0, res1);
-out1 = PCKEV_XORI128_UB(res2, res3);
-ST8x4_UB(out0, out1, dst, dst_stride);
-dst += (4 * dst_stride);
-}
-}
-
-static void avc_luma_hz_16w_msa(const uint8_t *src, int32_t src_stride,
-uint8_t *dst, int32_t dst_stride,
-int32_t height)
-{
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7;
-v8i16 res0, res1, res2, res3, res4, res5, res6, res7;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 vec6, vec7, vec8, vec9, vec10, vec11;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-
-LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
-
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB2(src, 8, src0, src1);
-src += src_stride;
-LD_SB2(src, 8, src2, src3);
-src += src_stride;
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec3);
-VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec6, vec9);
-VSHF_B2_SB(sr
Re: [FFmpeg-devel] [PATCH] avformat/srt: add Haivision SRT protocol
2017-10-05 10:25 GMT+02:00 Nablet Developer : > protocol requires libsrt (https://github.com/Haivision/srt) to be > installed > + --enable-libsrt enable libsrt [autodetect] Given that there is a libsrt that you don't meant, I don't think this is the right name for the option: I suggest --enable-srt. This should not be auto-detected since this certainly is no system library. And I suspect there is some alphabetical ordering, please respect it, same below. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/2] avfilter/vf_fps: clean-up filter options
On 04.10.2017 23:27, Michael Niedermayer wrote: On Mon, Sep 25, 2017 at 01:31:18PM +0200, Tobias Rapp wrote: Align order of "start_time" option within filter documentation to actual implementation and add missing AV_OPT_FLAG_FILTERING_PARAM flag. Fix indent of "round" named constants and clear unused field values. Also fix some documentation cosmetics. This sounds a bit like it could be split into multiple commits but the content all LGTM Patch split and applied, thanks for review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: fix id3 chapters
On Thu, 5 Oct 2017 03:34:19 +0200
Lukas Stabe wrote:
> These changes store id3 chapter data in ID3v2ExtraMeta and introduce
> ff_id3v2_parse_chapters to parse them into the format context if needed.
>
> Encoders using ff_id3v2_read, which previously parsed chapters into the
> format context automatically, were adjusted to call ff_id3v2_parse_chapters.
> ---
> libavformat/aiffdec.c | 3 +-
> libavformat/asfdec_f.c | 4 +-
> libavformat/asfdec_o.c | 4 +-
> libavformat/dsfdec.c | 4 +-
> libavformat/id3v2.c| 120
> -
> libavformat/id3v2.h| 15 +--
> libavformat/iff.c | 3 +-
> libavformat/omadec.c | 5 +++
> libavformat/utils.c| 2 +
> 9 files changed, 122 insertions(+), 38 deletions(-)
>
> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
> index 2ef9386edb..99e05c78ec 100644
> --- a/libavformat/aiffdec.c
> +++ b/libavformat/aiffdec.c
> @@ -258,7 +258,8 @@ static int aiff_read_header(AVFormatContext *s)
> position = avio_tell(pb);
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, size);
> if (id3v2_extra_meta)
> -if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0) {
> +if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0 ||
> +(ret = ff_id3v2_parse_chapters(s, &id3v2_extra_meta)) <
> 0) {
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> return ret;
> }
> diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
> index cc648b9a2f..64a0b9d7f2 100644
> --- a/libavformat/asfdec_f.c
> +++ b/libavformat/asfdec_f.c
> @@ -307,8 +307,10 @@ static void get_id3_tag(AVFormatContext *s, int len)
> ID3v2ExtraMeta *id3v2_extra_meta = NULL;
>
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
> -if (id3v2_extra_meta)
> +if (id3v2_extra_meta) {
> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
> +}
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> }
>
> diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
> index 818d6f3573..5122e33c78 100644
> --- a/libavformat/asfdec_o.c
> +++ b/libavformat/asfdec_o.c
> @@ -460,8 +460,10 @@ static void get_id3_tag(AVFormatContext *s, int len)
> ID3v2ExtraMeta *id3v2_extra_meta = NULL;
>
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
> -if (id3v2_extra_meta)
> +if (id3v2_extra_meta) {
> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
> +}
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> }
>
> diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
> index 49ca336427..41538fd83c 100644
> --- a/libavformat/dsfdec.c
> +++ b/libavformat/dsfdec.c
> @@ -53,8 +53,10 @@ static void read_id3(AVFormatContext *s, uint64_t id3pos)
> return;
>
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, 0);
> -if (id3v2_extra_meta)
> +if (id3v2_extra_meta) {
> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
> +}
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> }
>
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index f15cefee47..6c216ba7a2 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
> @@ -670,59 +670,68 @@ fail:
> avio_seek(pb, end, SEEK_SET);
> }
>
> +static void free_chapter(void *obj)
> +{
> +ID3v2ExtraMetaCHAP *chap = obj;
> +av_freep(&chap->element_id);
> +av_dict_free(&chap->meta);
> +av_freep(&chap);
> +}
> +
> static void read_chapter(AVFormatContext *s, AVIOContext *pb, int len, const
> char *ttag, ID3v2ExtraMeta **extra_meta, int isv34)
> {
> -AVRational time_base = {1, 1000};
> -uint32_t start, end;
> -AVChapter *chapter;
> -uint8_t *dst = NULL;
> int taglen;
> char tag[5];
> +ID3v2ExtraMeta *new_extra = NULL;
> +ID3v2ExtraMetaCHAP *chap = NULL;
>
> -if (!s) {
> -/* We should probably just put the chapter data to extra_meta here
> - * and do the AVFormatContext-needing part in a separate
> - * ff_id3v2_parse_apic()-like function. */
> -av_log(NULL, AV_LOG_DEBUG, "No AVFormatContext, skipped ID3 chapter
> data\n");
> -return;
> -}
> +new_extra = av_mallocz(sizeof(*new_extra));
> +chap = av_mallocz(sizeof(*chap));
> +
> +if (!new_extra || !chap)
> +goto fail;
> +
> +if (decode_str(s, pb, 0, &chap->element_id, &len) < 0)
> +goto fail;
>
> -if (decode_str(s, pb, 0, &dst, &len) < 0)
> -return;
> if (len < 16)
> -return;
> +goto fail;
>
> -start = avio_rb32(pb);
> -end = avio_rb32(pb);
> +chap->start = avio_rb32(pb);
> +chap->end = avio_rb32(pb);
> avio_skip(pb, 8)
Re: [FFmpeg-devel] [PATCH] avformat: fix id3 chapters
> On 5. Oct 2017, at 10:51, wm4 wrote:
>
> On Thu, 5 Oct 2017 03:34:19 +0200
> Lukas Stabe wrote:
>
>> These changes store id3 chapter data in ID3v2ExtraMeta and introduce
>> ff_id3v2_parse_chapters to parse them into the format context if needed.
>>
>> Encoders using ff_id3v2_read, which previously parsed chapters into the
>> format context automatically, were adjusted to call ff_id3v2_parse_chapters.
>> ---
>> libavformat/aiffdec.c | 3 +-
>> libavformat/asfdec_f.c | 4 +-
>> libavformat/asfdec_o.c | 4 +-
>> libavformat/dsfdec.c | 4 +-
>> libavformat/id3v2.c| 120
>> -
>> libavformat/id3v2.h| 15 +--
>> libavformat/iff.c | 3 +-
>> libavformat/omadec.c | 5 +++
>> libavformat/utils.c| 2 +
>> 9 files changed, 122 insertions(+), 38 deletions(-)
>>
>> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
>> index 2ef9386edb..99e05c78ec 100644
>> --- a/libavformat/aiffdec.c
>> +++ b/libavformat/aiffdec.c
>> @@ -258,7 +258,8 @@ static int aiff_read_header(AVFormatContext *s)
>> position = avio_tell(pb);
>> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, size);
>> if (id3v2_extra_meta)
>> -if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0) {
>> +if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0 ||
>> +(ret = ff_id3v2_parse_chapters(s, &id3v2_extra_meta)) <
>> 0) {
>> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
>> return ret;
>> }
>> diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
>> index cc648b9a2f..64a0b9d7f2 100644
>> --- a/libavformat/asfdec_f.c
>> +++ b/libavformat/asfdec_f.c
>> @@ -307,8 +307,10 @@ static void get_id3_tag(AVFormatContext *s, int len)
>> ID3v2ExtraMeta *id3v2_extra_meta = NULL;
>>
>> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
>> -if (id3v2_extra_meta)
>> +if (id3v2_extra_meta) {
>> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
>> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
>> +}
>> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
>> }
>>
>> diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
>> index 818d6f3573..5122e33c78 100644
>> --- a/libavformat/asfdec_o.c
>> +++ b/libavformat/asfdec_o.c
>> @@ -460,8 +460,10 @@ static void get_id3_tag(AVFormatContext *s, int len)
>> ID3v2ExtraMeta *id3v2_extra_meta = NULL;
>>
>> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
>> -if (id3v2_extra_meta)
>> +if (id3v2_extra_meta) {
>> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
>> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
>> +}
>> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
>> }
>>
>> diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
>> index 49ca336427..41538fd83c 100644
>> --- a/libavformat/dsfdec.c
>> +++ b/libavformat/dsfdec.c
>> @@ -53,8 +53,10 @@ static void read_id3(AVFormatContext *s, uint64_t id3pos)
>> return;
>>
>> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, 0);
>> -if (id3v2_extra_meta)
>> +if (id3v2_extra_meta) {
>> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
>> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
>> +}
>> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
>> }
>>
>> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
>> index f15cefee47..6c216ba7a2 100644
>> --- a/libavformat/id3v2.c
>> +++ b/libavformat/id3v2.c
>> @@ -670,59 +670,68 @@ fail:
>> avio_seek(pb, end, SEEK_SET);
>> }
>>
>> +static void free_chapter(void *obj)
>> +{
>> +ID3v2ExtraMetaCHAP *chap = obj;
>> +av_freep(&chap->element_id);
>> +av_dict_free(&chap->meta);
>> +av_freep(&chap);
>> +}
>> +
>> static void read_chapter(AVFormatContext *s, AVIOContext *pb, int len, const
>> char *ttag, ID3v2ExtraMeta **extra_meta, int isv34)
>> {
>> -AVRational time_base = {1, 1000};
>> -uint32_t start, end;
>> -AVChapter *chapter;
>> -uint8_t *dst = NULL;
>> int taglen;
>> char tag[5];
>> +ID3v2ExtraMeta *new_extra = NULL;
>> +ID3v2ExtraMetaCHAP *chap = NULL;
>>
>> -if (!s) {
>> -/* We should probably just put the chapter data to extra_meta here
>> - * and do the AVFormatContext-needing part in a separate
>> - * ff_id3v2_parse_apic()-like function. */
>> -av_log(NULL, AV_LOG_DEBUG, "No AVFormatContext, skipped ID3 chapter
>> data\n");
>> -return;
>> -}
>> +new_extra = av_mallocz(sizeof(*new_extra));
>> +chap = av_mallocz(sizeof(*chap));
>> +
>> +if (!new_extra || !chap)
>> +goto fail;
>> +
>> +if (decode_str(s, pb, 0, &chap->element_id, &len) < 0)
>> +goto fail;
>>
>> -if (decode_str(s, pb, 0, &dst, &len) < 0)
>> -return;
>> if (len < 16)
>> -return;
>> +goto fail;
>>
>> -start = avio_r
Re: [FFmpeg-devel] [PATCH] avformat/srt: add Haivision SRT protocol
Le quartidi 14 vendémiaire, an CCXXVI, Nablet Developer a écrit : > protocol requires libsrt (https://github.com/Haivision/srt) to be > installed > > Signed-off-by: Nablet Developer > --- > configure |5 + > libavformat/Makefile|1 + > libavformat/protocols.c |1 + > libavformat/srt.c | 1105 > +++ SRT is a subtitle format: a more specific name would be better. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/srt: add Haivision SRT protocol
> SRT is a subtitle format: a more specific name would be better. for example? haivision_srt? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information
Am 02.10.2017 um 18:34 schrieb Marton Balint: > Yeah, you can capture both at the same time, and one signal might be > key, other might be fill, but as far as I know the driver will not > merge these two signals behind the scenes to one single input with an > alpha channel. Is there a video filter for splitting RGBA->key/fill or joining key/fill -> RGBA? Then an example in the docs would be helpful, though I'm not sure if the two streams will be perfectly synchronized. Matthias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Infrastructure: patchwork.ffmpeg.org SSL certificate
There is still a StartCom certificate in place, which is refused from Chrome and soon other browsers. Any help appreciated to also move that machine to Let's Encrypt? Matthias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Wed, 4 Oct 2017 15:03:34 -0700
Aman Gupta wrote:
> From: Aman Gupta
>
> This teaches the HLS demuxer to use the HTTP protocols
> multiple_requests=1 option, to take advantage of "Connection:
> Keep-Alive" when downloading playlists and segments from the HLS server.
>
> With the new option, you can avoid TCP connection and TLS negotiation
> overhead, which is particularly beneficial when streaming via a
> high-latency internet connection.
> ---
> libavformat/hls.c | 51 +++
> 1 file changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 786934af03..bf90582755 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -26,6 +26,7 @@
> * http://tools.ietf.org/html/draft-pantos-http-live-streaming
> */
>
> +#include "libavformat/http.h"
> #include "libavutil/avstring.h"
> #include "libavutil/avassert.h"
> #include "libavutil/intreadwrite.h"
> @@ -94,6 +95,7 @@ struct playlist {
> AVIOContext pb;
> uint8_t* read_buffer;
> AVIOContext *input;
> +int input_done;
> AVFormatContext *parent;
> int index;
> AVFormatContext *ctx;
> @@ -206,6 +208,8 @@ typedef struct HLSContext {
> int strict_std_compliance;
> char *allowed_extensions;
> int max_reload;
> +int http_keepalive;
> +AVIOContext *playlist_pb;
> } HLSContext;
>
> static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
> @@ -640,7 +644,17 @@ static int open_url(AVFormatContext *s, AVIOContext
> **pb, const char *url,
> else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
> return AVERROR_INVALIDDATA;
>
> -ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +if (c->http_keepalive && *pb && av_strstart(proto_name, "http", NULL)) {
> +URLContext *uc = (URLContext *)av_opt_child_next(*pb, NULL);
> +(*pb)->eof_reached = 0;
> +ret = ff_http_do_new_request(uc, url);
> +if (ret < 0) {
> +ff_format_io_close(c->ctx, pb);
> +ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +}
> +} else {
> +ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +}
> if (ret >= 0) {
> // update cookies on http response with setcookies.
> char *new_cookies = NULL;
> @@ -683,10 +697,20 @@ static int parse_playlist(HLSContext *c, const char
> *url,
> char tmp_str[MAX_URL_SIZE];
> struct segment *cur_init_section = NULL;
>
> +if (!in && c->http_keepalive && c->playlist_pb) {
> +in = c->playlist_pb;
> +URLContext *uc = (URLContext *)av_opt_child_next(in, NULL);
> +in->eof_reached = 0;
> +ret = ff_http_do_new_request(uc, url);
> +if (ret < 0) {
> +ff_format_io_close(c->ctx, &c->playlist_pb);
> +in = NULL;
> +}
> +}
> +
> if (!in) {
> #if 1
> AVDictionary *opts = NULL;
> -close_in = 1;
> /* Some HLS servers don't like being sent the range header */
> av_dict_set(&opts, "seekable", "0", 0);
>
> @@ -696,10 +720,18 @@ static int parse_playlist(HLSContext *c, const char
> *url,
> av_dict_set(&opts, "headers", c->headers, 0);
> av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
>
> +if (c->http_keepalive)
> +av_dict_set(&opts, "multiple_requests", "1", 0);
> +
> ret = c->ctx->io_open(c->ctx, &in, url, AVIO_FLAG_READ, &opts);
> av_dict_free(&opts);
> if (ret < 0)
> return ret;
> +
> +if (c->http_keepalive)
> +c->playlist_pb = in;
> +else
> +close_in = 1;
> #else
> ret = open_in(c, &in, url);
> if (ret < 0)
> @@ -,6 +1143,9 @@ static int open_input(HLSContext *c, struct playlist
> *pls, struct segment *seg)
> av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
> av_dict_set(&opts, "seekable", "0", 0);
>
> +if (c->http_keepalive)
> +av_dict_set(&opts, "multiple_requests", "1", 0);
> +
> if (seg->size >= 0) {
> /* try to restrict the HTTP request to the part we want
> * (if this is in fact a HTTP request) */
> @@ -1270,7 +1305,7 @@ restart:
> if (!v->needed)
> return AVERROR_EOF;
>
> -if (!v->input) {
> +if (!v->input || (c->http_keepalive && v->input_done)) {
> int64_t reload_interval;
> struct segment *seg;
>
> @@ -1329,6 +1364,7 @@ reload:
> goto reload;
> }
>
> +v->input_done = 0;
> seg = current_segment(v);
>
> /* load/update Media Initialization Section, if any */
> @@ -1366,7 +1402,11 @@ reload:
>
> return ret;
> }
> -ff_format_io_close(v->parent, &v->input);
> +if (c->http_keepalive) {
> +v->input_done = 1;
> +} else {
> +ff_format_io_close(v->parent, &v->input);
> +}
> v->cur_seq_no++;
>
[FFmpeg-devel] [PATCH 1/1] lavc: add support for OpenJPEG 2.3.0
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
configure | 5 -
libavcodec/libopenjpegdec.c | 8 +---
libavcodec/libopenjpegenc.c | 10 ++
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 391c141e7a..77c9a18c3c 100755
--- a/configure
+++ b/configure
@@ -1930,6 +1930,7 @@ HEADERS_LIST="
machine_ioctl_meteor_h
malloc_h
opencv2_core_core_c_h
+openjpeg_2_3_openjpeg_h
openjpeg_2_2_openjpeg_h
openjpeg_2_1_openjpeg_h
openjpeg_2_0_openjpeg_h
@@ -5950,7 +5951,9 @@ enabled libopencv && { check_header
opencv2/core/core_c.h &&
require opencv opencv2/core/core_c.h
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config libopencv opencv
opencv/cxcore.h cvCreateImageHeader; }
enabled libopenh264 && require_pkg_config libopenh264 openh264
wels/codec_api.h WelsGetCodecVersion
-enabled libopenjpeg && { { check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+enabled libopenjpeg && { { check_lib libopenjpeg openjpeg-2.3/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+ check_lib libopenjpeg openjpeg-2.3/openjpeg.h
opj_version -lopenjp2 ||
+ { check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 ||
{ check_lib libopenjpeg openjpeg-2.1/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.1/openjpeg.h
opj_version -lopenjp2 ||
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 1210123265..67d47bd6a0 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -34,7 +34,9 @@
#include "internal.h"
#include "thread.h"
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H
+# include
+#elif HAVE_OPENJPEG_2_2_OPENJPEG_H
# include
#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
# include
@@ -46,7 +48,7 @@
# include
#endif
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
# define OPENJPEG_MAJOR_VERSION 2
# define OPJ(x) OPJ_##x
#else
@@ -431,7 +433,7 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
opj_stream_set_read_function(stream, stream_read);
opj_stream_set_skip_function(stream, stream_skip);
opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H
opj_stream_set_user_data(stream, &reader, NULL);
#elif HAVE_OPENJPEG_2_0_OPENJPEG_H
opj_stream_set_user_data(stream, &reader);
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index b67e533d1d..92b4433b04 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -32,7 +32,9 @@
#include "avcodec.h"
#include "internal.h"
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H
+# include
+#elif HAVE_OPENJPEG_2_2_OPENJPEG_H
# include
#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
# include
@@ -44,7 +46,7 @@
# include
#endif
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
# define OPENJPEG_MAJOR_VERSION 2
# define OPJ(x) OPJ_##x
#else
@@ -307,7 +309,7 @@ static av_cold int libopenjpeg_encode_init(AVCodecContext
*avctx)
opj_set_default_encoder_parameters(&ctx->enc_params);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H
switch (ctx->cinema_mode) {
case OPJ_CINEMA2K_24:
ctx->enc_params.rsiz = OPJ_PROFILE_CINEMA_2K;
@@ -771,7 +773,7 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
opj_stream_set_write_function(stream, stream_write);
opj_stream_set_skip_function(stream, stream_skip);
opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H
opj_stream_set_user_data(stream, &writer, NULL);
#elif HAVE_OPENJPEG_2_0_OPENJPEG_H
opj_stream_set_user_data(stream, &writer);
--
2.13.5 (Ap
[FFmpeg-devel] [PATCH 0/1] lavc: add support for OpenJPEG 2.3.0
From: Michael Bradshaw This adds support for OpenJPEG 2.3.0, which was just released and contains many security-related fixes. Michael Bradshaw (1): lavc: add support for OpenJPEG 2.3.0 configure | 5 - libavcodec/libopenjpegdec.c | 8 +--- libavcodec/libopenjpegenc.c | 10 ++ 3 files changed, 15 insertions(+), 8 deletions(-) -- 2.13.5 (Apple Git-94) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Wed, Oct 04, 2017 at 15:03:34 -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> This teaches the HLS demuxer to use the HTTP protocols
> multiple_requests=1 option, to take advantage of "Connection:
> Keep-Alive" when downloading playlists and segments from the HLS server.
Nice.
Quick test: A random akamaihd.net HLS stream (they provide great
bandwidth) with quite small segments (~10s per segment) goes from 14.8x
to 16x. The overhead reduction seems significant, and this isn't even
https segments.
Issue: The hls demuxer now inconsistently no longer reports each opened
URL, only the first one. (Reporting of these at default log-level was
only recently added though.)
>
> With the new option, you can avoid TCP connection and TLS negotiation
> overhead, which is particularly beneficial when streaming via a
> high-latency internet connection.
> ---
> libavformat/hls.c | 51 +++
> 1 file changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 786934af03..bf90582755 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -26,6 +26,7 @@
> * http://tools.ietf.org/html/draft-pantos-http-live-streaming
> */
>
> +#include "libavformat/http.h"
> #include "libavutil/avstring.h"
> #include "libavutil/avassert.h"
> #include "libavutil/intreadwrite.h"
> @@ -94,6 +95,7 @@ struct playlist {
> AVIOContext pb;
> uint8_t* read_buffer;
> AVIOContext *input;
> +int input_done;
> AVFormatContext *parent;
> int index;
> AVFormatContext *ctx;
> @@ -206,6 +208,8 @@ typedef struct HLSContext {
> int strict_std_compliance;
> char *allowed_extensions;
> int max_reload;
> +int http_keepalive;
> +AVIOContext *playlist_pb;
> } HLSContext;
>
> static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
> @@ -640,7 +644,17 @@ static int open_url(AVFormatContext *s, AVIOContext
> **pb, const char *url,
> else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
> return AVERROR_INVALIDDATA;
>
> -ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +if (c->http_keepalive && *pb && av_strstart(proto_name, "http", NULL)) {
> +URLContext *uc = (URLContext *)av_opt_child_next(*pb, NULL);
> +(*pb)->eof_reached = 0;
> +ret = ff_http_do_new_request(uc, url);
> +if (ret < 0) {
> +ff_format_io_close(c->ctx, pb);
> +ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +}
> +} else {
> +ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +}
> if (ret >= 0) {
> // update cookies on http response with setcookies.
> char *new_cookies = NULL;
> @@ -683,10 +697,20 @@ static int parse_playlist(HLSContext *c, const char
> *url,
> char tmp_str[MAX_URL_SIZE];
> struct segment *cur_init_section = NULL;
>
> +if (!in && c->http_keepalive && c->playlist_pb) {
> +in = c->playlist_pb;
> +URLContext *uc = (URLContext *)av_opt_child_next(in, NULL);
> +in->eof_reached = 0;
> +ret = ff_http_do_new_request(uc, url);
> +if (ret < 0) {
> +ff_format_io_close(c->ctx, &c->playlist_pb);
> +in = NULL;
> +}
> +}
> +
> if (!in) {
> #if 1
> AVDictionary *opts = NULL;
> -close_in = 1;
> /* Some HLS servers don't like being sent the range header */
> av_dict_set(&opts, "seekable", "0", 0);
>
> @@ -696,10 +720,18 @@ static int parse_playlist(HLSContext *c, const char
> *url,
> av_dict_set(&opts, "headers", c->headers, 0);
> av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
>
> +if (c->http_keepalive)
> +av_dict_set(&opts, "multiple_requests", "1", 0);
> +
> ret = c->ctx->io_open(c->ctx, &in, url, AVIO_FLAG_READ, &opts);
> av_dict_free(&opts);
> if (ret < 0)
> return ret;
> +
> +if (c->http_keepalive)
> +c->playlist_pb = in;
> +else
> +close_in = 1;
> #else
> ret = open_in(c, &in, url);
> if (ret < 0)
> @@ -,6 +1143,9 @@ static int open_input(HLSContext *c, struct playlist
> *pls, struct segment *seg)
> av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
> av_dict_set(&opts, "seekable", "0", 0);
>
> +if (c->http_keepalive)
> +av_dict_set(&opts, "multiple_requests", "1", 0);
> +
> if (seg->size >= 0) {
> /* try to restrict the HTTP request to the part we want
> * (if this is in fact a HTTP request) */
> @@ -1270,7 +1305,7 @@ restart:
> if (!v->needed)
> return AVERROR_EOF;
>
> -if (!v->input) {
> +if (!v->input || (c->http_keepalive && v->input_done)) {
> int64_t reload_interval;
> struct segment *seg;
>
> @@ -1329,6 +1364,7 @@ reload:
> goto reload;
> }
>
> +v->in
[FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
Time to time some devices send UDP packets without payload.
ffmpeg previously exited on receiving such packet, this patch
adds an option to ignore such packets.
Signed-off-by: Daniel Kucera
---
libavformat/udp.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 3835f989c4..15455dbef5 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -88,6 +88,7 @@ typedef struct UDPContext {
int is_broadcast;
int local_port;
int reuse_socket;
+int ignore_empty;
int overrun_nonfatal;
struct sockaddr_storage dest_addr;
int dest_addr_len;
@@ -137,6 +138,7 @@ static const AVOption options[] = {
{ "timeout","set raise error timeout (only in read mode)",
OFFSET(timeout),AV_OPT_TYPE_INT,{ .i64 = 0 }, 0, INT_MAX, D },
{ "sources","Source list",
OFFSET(sources),AV_OPT_TYPE_STRING, { .str = NULL },
.flags = D|E },
{ "block", "Block list",
OFFSET(block), AV_OPT_TYPE_STRING, { .str = NULL },
.flags = D|E },
+{ "ignore_empty", "ignore empty UDP packets",
OFFSET(ignore_empty), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D|E
},
{ NULL }
};
@@ -786,6 +788,9 @@ static int udp_open(URLContext *h, const char *uri, int
flags)
FF_ARRAY_ELEMS(exclude_sources)))
goto fail;
}
+if (av_find_info_tag(buf, sizeof(buf), "ignore_empty", p)) {
+s->ignore_empty = strtol(buf, NULL, 10);
+}
if (!is_output && av_find_info_tag(buf, sizeof(buf), "timeout", p))
s->timeout = strtol(buf, NULL, 10);
if (is_output && av_find_info_tag(buf, sizeof(buf), "broadcast", p))
@@ -1039,7 +1044,12 @@ static int udp_read(URLContext *h, uint8_t *buf, int
size)
av_fifo_generic_read(s->fifo, buf, avail, NULL);
av_fifo_drain(s->fifo, AV_RL32(tmp) - avail);
pthread_mutex_unlock(&s->mutex);
-return avail;
+if (s->ignore_empty && avail == 0){
+ av_log(h, AV_LOG_DEBUG, "Ignoring empty UDP packet\n");
+ continue;
+} else {
+ return avail;
+}
} else if(s->circular_buffer_error){
int err = s->circular_buffer_error;
pthread_mutex_unlock(&s->mutex);
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] build: add install targets for the examples
On 10/5/2017 3:10 AM, Clément Bœsch wrote: > On Thu, Oct 05, 2017 at 12:55:19AM -0300, James Almer wrote: >> Split it off from install-data. >> >> Among other things, this prevents spamming triplicate log lines during >> install. >> >> Signed-off-by: James Almer >> --- >> Updated to apply after a recent merge. >> >> Makefile | 6 ++ >> doc/examples/Makefile | 14 +- >> 2 files changed, 15 insertions(+), 5 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index 3007da50f7..4a1253a052 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -120,11 +120,9 @@ install: install-libs install-headers >> >> install-libs: install-libs-yes >> >> -install-data: $(DATA_FILES) $(EXAMPLES_FILES) $(EXAMPLE_MAKEFILE) >> -$(Q)mkdir -p "$(DATADIR)/examples" >> +install-data: $(DATA_FILES) >> +$(Q)mkdir -p "$(DATADIR)" >> $(INSTALL) -m 644 $(DATA_FILES) "$(DATADIR)" >> -$(INSTALL) -m 644 $(EXAMPLES_FILES) "$(DATADIR)/examples" >> -$(INSTALL) -m 644 $(EXAMPLE_MAKEFILE:%=%.example) >> "$(DATADIR)/examples/Makefile" >> >> uninstall: uninstall-libs uninstall-headers uninstall-data >> >> diff --git a/doc/examples/Makefile b/doc/examples/Makefile >> index af000d9ddb..58afd71b85 100644 >> --- a/doc/examples/Makefile >> +++ b/doc/examples/Makefile >> @@ -26,8 +26,8 @@ ALL_EXAMPLES := $(EXAMPLES) >> $(EXAMPLES-:%=doc/examples/%$(PROGSSUF)$(EXESUF)) >> ALL_EXAMPLES_G := $(EXAMPLES_G) >> $(EXAMPLES-:%=doc/examples/%$(PROGSSUF)_g$(EXESUF)) >> PROGS += $(EXAMPLES) >> >> -EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) >> $(SRC_PATH)/doc/examples/README >> EXAMPLE_MAKEFILE := $(SRC_PATH)/doc/examples/Makefile >> +EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) >> $(SRC_PATH)/doc/examples/README $(EXAMPLE_MAKEFILE) >> >> $(foreach P,$(EXAMPLES),$(eval OBJS-$(P:%$(PROGSSUF)$(EXESUF)=%) = >> $(P:%$(PROGSSUF)$(EXESUF)=%).o)) >> $(EXAMPLES_G): %$(PROGSSUF)_g$(EXESUF): %.o >> @@ -39,6 +39,18 @@ OBJDIRS += doc/examples >> >> DOXY_INPUT += $(EXAMPLES:%$(PROGSSUF)$(EXESUF)=%.c) >> >> +install: install-examples >> + >> +install-examples: $(EXAMPLES_FILES) > >> +$(Q)mkdir -p "$(DATADIR)/examples" > > I think you're supposed to use $(INSTALL) -d We use "mkdir -p" on every other install target (including install-data where this comes from), so I'd rather not change that here. > > [...] > > Rest should be fine Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Thu, Oct 05, 2017 at 13:41:07 +0200, wm4 wrote:
> I don't really see where this patch checks whether the host changes?
> The minimal requirements for reusing the connection would be using
> the same protocol and the same host.
I *believe* it just tries to reuse the connection and falls back to
re-opening on failure. On any failure - that could be a cookie issue, a
timeout, or whatever:
> +ret = ff_http_do_new_request(uc, url);
> +if (ret < 0) {
> +ff_format_io_close(c->ctx, pb);
> +ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +}
I wonder what the patch as a whole does if the server doesn't support
this? The same as above - just fail and reconnect?
Does the hls demuxer support HTTP 1.0? This would need a "Connection:
keep-alive" header in the request (and such a response from the
server to confirm).
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Thu, 5 Oct 2017 16:39:25 +0200
Moritz Barsnick wrote:
> On Thu, Oct 05, 2017 at 13:41:07 +0200, wm4 wrote:
> > I don't really see where this patch checks whether the host changes?
> > The minimal requirements for reusing the connection would be using
> > the same protocol and the same host.
>
> I *believe* it just tries to reuse the connection and falls back to
> re-opening on failure. On any failure - that could be a cookie issue, a
> timeout, or whatever:
Couldn't find anything that would make ff_http_do_new_request fail if
the host changed, but maybe I didn't look close enough.
> > +ret = ff_http_do_new_request(uc, url);
> > +if (ret < 0) {
> > +ff_format_io_close(c->ctx, pb);
> > +ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> > +}
>
> I wonder what the patch as a whole does if the server doesn't support
> this? The same as above - just fail and reconnect?
I'd think so.
> Does the hls demuxer support HTTP 1.0? This would need a "Connection:
> keep-alive" header in the request (and such a response from the
> server to confirm).
That's definitely added. Not sure what happens if the server doesn't
support it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/7] Removing some debugging
On Tue, Oct 3, 2017 at 4:02 AM, Carl Eugen Hoyos wrote:
> 2017-10-03 1:52 GMT+02:00 Bjorn Roche :
>
> > Attached is a patch for paletteuse only.
>
> I tested the following with and without your patch:
> $ ffmpeg -i fate-suite/lena.pnm -vf palettegen pal.png
> $ ffmpeg -i fate-suite/lena.pnm -i pal.png -lavfi paletteuse out.png
>
> out.png changes with your patch: Is that intended?
>
Not intended, but not unexpected -- the ordering of colors in the palette
changed to make it easier to deal with transparency. However, there are
visual differences, so that's obviously a bug. I've supplied a new patch
(below) that fixes that bug, and maintains the order so it's easier to test
for that.
> The input frame contains no transparency.
>
> Your patch still contains printfs that should be removed
> (change them to av_log(DEBUG) if you think they are
> useful) and a new warning is shown at compilation:
> libavfilter/vf_paletteuse.c: In function ‘colormap_nearest_recursive’:
> libavfilter/vf_paletteuse.c:242:5: warning: ISO C90 forbids mixed
> declarations and code
>
> Please fix the style: Space after "if", no space after "if ("
>
Thank you for your attention. This should also be resolved in the attached
patch.
I have tested fate, all dithering (including none, which I added) and all
color search algorithms.
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index ffd37bf1da..7cb5a3db02 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -56,7 +56,7 @@ enum diff_mode {
};
struct color_node {
-uint8_t val[3];
+uint8_t val[4];
uint8_t palette_id;
int split;
int left_id, right_id;
@@ -86,6 +86,7 @@ typedef struct PaletteUseContext {
struct cache_node cache[CACHE_SIZE];/* lookup cache */
struct color_node map[AVPALETTE_COUNT]; /* 3D-Tree (KD-Tree with K=3) for
reverse colormap */
uint32_t palette[AVPALETTE_COUNT];
+int transparency_index; /* index in the palette of transparency. -1 if
there isn't a transparency. */
int palette_loaded;
int dither;
int new;
@@ -108,6 +109,7 @@ typedef struct PaletteUseContext {
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption paletteuse_options[] = {
{ "dither", "select dithering mode", OFFSET(dither), AV_OPT_TYPE_INT,
{.i64=DITHERING_SIERRA2_4A}, 0, NB_DITHERING-1, FLAGS, "dithering_mode" },
+{ "none","no dither",
0, AV_OPT_TYPE_CONST, {.i64=DITHERING_NONE},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "bayer", "ordered 8x8 bayer dithering (deterministic)",
0, AV_OPT_TYPE_CONST, {.i64=DITHERING_BAYER},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "heckbert","dithering as defined by Paul Heckbert in 1982
(simple error diffusion)", 0, AV_OPT_TYPE_CONST, {.i64=DITHERING_HECKBERT},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "floyd_steinberg", "Floyd and Steingberg dithering (error
diffusion)", 0, AV_OPT_TYPE_CONST,
{.i64=DITHERING_FLOYD_STEINBERG}, INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
@@ -157,7 +159,8 @@ static int query_formats(AVFilterContext *ctx)
static av_always_inline int dither_color(uint32_t px, int er, int eg, int eb,
int scale, int shift)
{
-return av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<> 24 & 0xff) ) << 24
+ | av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<> 8 & 0xff) + ((eg * scale) / (1<>24 & 0xff,
palette[i]>>16 & 0xff,
palette[i]>> 8 & 0xff,
palette[i] & 0xff,
};
-const int d = diff(palrgb, rgb);
+const int d = diff(palargb, rgb);
if (d < min_dist) {
pal_id = i;
min_dist = d;
}
}
}
+
return pal_id;
}
@@ -325,14 +338,15 @@ end:
* Note: r, g, and b are the component of c but are passed as well to avoid
* recomputing them (they are generally computed by the caller for other uses).
*/
-static av_always_inline int color_get(struct cache_node *cache, uint32_t color,
- uint8_t r, uint8_t g, uint8_t b,
+static av_always_inline int color_get(struct cache_node *cache, uint32_t argb,
+ uint8_t a, uint8_t r, uint8_t g, uint8_t
b,
+ int transparency_index,
const struct color_node *map,
const uint32_t *palette,
const enum color_search_method
search_method)
{
int i;
-const uint8_t rgb[] = {r, g, b};
+const uint8_t argb_elts[] = {a, r, g, b};
const uint8_t rhash = r & ((1<= 0) {
+return transparency_index;
+}
+
[FFmpeg-devel] libavcodec/blockdsp : add clear_blocks_prores func (SSE, AVX) for prores decoding
Hello,
In attach patchs to add a dedicated func for clear_block inside
prores decoding (proresdec2)
currently slice decode func use a loop and call the blockdsp.clear_block
func
After some test, it seems to be slower, than memset (for me)
I check using this "fake" func in the blockdsp
static void ff_clear_blocks_prores_sse_loop(int16_t * blocks, ptrdiff_t
block_count){
int i;
for (i = 0; i < block_count; i++)
ff_clear_block_sse(blocks+(i<<6));
}
static void ff_clear_blocks_prores_avx_loop(int16_t * blocks, ptrdiff_t
block_count){
int i;
for (i = 0; i < block_count; i++)
ff_clear_block_avx(blocks+(i<<6));
}
the result in checkasm are (need patch in attach to reproduce the test) :
using the loop
blockdsp.clear_blocks_prores_c: 137.8
blockdsp.clear_blocks_prores_sse: 292.0
blockdsp.clear_blocks_prores_avx: 230.5
Using the new asm func this is the result (Kaby Lake, os 10.12, Clang 8.1)
blockdsp.clear_blocks_prores_c: 153.4
blockdsp.clear_blocks_prores_sse: 284.4
blockdsp.clear_blocks_prores_avx: 142.2
Pass fate test for me (X86_64)
Like the block_per_slice value in prores decoder, is multiply by 2 or 4
(depend of the codec), the asm function
can process two blocks in the same loop (in AVX)
I also put in attach a patch to fix comment, for clear_block dsp func,
(need 32 aligned now because of avx) (to avoid a "dedicated" thread on the
mailing list)
Martin
Jokyo Images
0001-libavcodec-blockdsp-fix-comment.-clear_block-need-32.patch
Description: Binary data
0002-libavcodec-blockdsp-add-clear_block_prores.patch
Description: Binary data
0003-libavcodec-proresdec2-use-clear_blocks_prores-for-ea.patch
Description: Binary data
0004-libavcodec-blockdsp-cosmetic-indent.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: fix id3 chapters
On Thu, 5 Oct 2017 03:34:19 +0200
Lukas Stabe wrote:
> These changes store id3 chapter data in ID3v2ExtraMeta and introduce
> ff_id3v2_parse_chapters to parse them into the format context if needed.
>
> Encoders using ff_id3v2_read, which previously parsed chapters into the
> format context automatically, were adjusted to call ff_id3v2_parse_chapters.
> ---
> libavformat/aiffdec.c | 3 +-
> libavformat/asfdec_f.c | 4 +-
> libavformat/asfdec_o.c | 4 +-
> libavformat/dsfdec.c | 4 +-
> libavformat/id3v2.c| 120
> -
> libavformat/id3v2.h| 15 +--
> libavformat/iff.c | 3 +-
> libavformat/omadec.c | 5 +++
> libavformat/utils.c| 2 +
> 9 files changed, 122 insertions(+), 38 deletions(-)
>
> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
> index 2ef9386edb..99e05c78ec 100644
> --- a/libavformat/aiffdec.c
> +++ b/libavformat/aiffdec.c
> @@ -258,7 +258,8 @@ static int aiff_read_header(AVFormatContext *s)
> position = avio_tell(pb);
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, size);
> if (id3v2_extra_meta)
> -if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0) {
> +if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0 ||
> +(ret = ff_id3v2_parse_chapters(s, &id3v2_extra_meta)) <
> 0) {
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> return ret;
> }
> diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
> index cc648b9a2f..64a0b9d7f2 100644
> --- a/libavformat/asfdec_f.c
> +++ b/libavformat/asfdec_f.c
> @@ -307,8 +307,10 @@ static void get_id3_tag(AVFormatContext *s, int len)
> ID3v2ExtraMeta *id3v2_extra_meta = NULL;
>
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
> -if (id3v2_extra_meta)
> +if (id3v2_extra_meta) {
> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
> +}
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> }
>
> diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
> index 818d6f3573..5122e33c78 100644
> --- a/libavformat/asfdec_o.c
> +++ b/libavformat/asfdec_o.c
> @@ -460,8 +460,10 @@ static void get_id3_tag(AVFormatContext *s, int len)
> ID3v2ExtraMeta *id3v2_extra_meta = NULL;
>
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
> -if (id3v2_extra_meta)
> +if (id3v2_extra_meta) {
> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
> +}
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> }
>
> diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
> index 49ca336427..41538fd83c 100644
> --- a/libavformat/dsfdec.c
> +++ b/libavformat/dsfdec.c
> @@ -53,8 +53,10 @@ static void read_id3(AVFormatContext *s, uint64_t id3pos)
> return;
>
> ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, 0);
> -if (id3v2_extra_meta)
> +if (id3v2_extra_meta) {
> ff_id3v2_parse_apic(s, &id3v2_extra_meta);
> +ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
> +}
> ff_id3v2_free_extra_meta(&id3v2_extra_meta);
> }
>
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index f15cefee47..6c216ba7a2 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
> @@ -670,59 +670,68 @@ fail:
> avio_seek(pb, end, SEEK_SET);
> }
>
> +static void free_chapter(void *obj)
> +{
> +ID3v2ExtraMetaCHAP *chap = obj;
> +av_freep(&chap->element_id);
> +av_dict_free(&chap->meta);
> +av_freep(&chap);
> +}
> +
> static void read_chapter(AVFormatContext *s, AVIOContext *pb, int len, const
> char *ttag, ID3v2ExtraMeta **extra_meta, int isv34)
> {
> -AVRational time_base = {1, 1000};
> -uint32_t start, end;
> -AVChapter *chapter;
> -uint8_t *dst = NULL;
> int taglen;
> char tag[5];
> +ID3v2ExtraMeta *new_extra = NULL;
> +ID3v2ExtraMetaCHAP *chap = NULL;
>
> -if (!s) {
> -/* We should probably just put the chapter data to extra_meta here
> - * and do the AVFormatContext-needing part in a separate
> - * ff_id3v2_parse_apic()-like function. */
> -av_log(NULL, AV_LOG_DEBUG, "No AVFormatContext, skipped ID3 chapter
> data\n");
> -return;
> -}
> +new_extra = av_mallocz(sizeof(*new_extra));
> +chap = av_mallocz(sizeof(*chap));
> +
> +if (!new_extra || !chap)
> +goto fail;
> +
> +if (decode_str(s, pb, 0, &chap->element_id, &len) < 0)
> +goto fail;
>
> -if (decode_str(s, pb, 0, &dst, &len) < 0)
> -return;
> if (len < 16)
> -return;
> +goto fail;
>
> -start = avio_rb32(pb);
> -end = avio_rb32(pb);
> +chap->start = avio_rb32(pb);
> +chap->end = avio_rb32(pb);
> avio_skip(pb, 8)
Re: [FFmpeg-devel] [PATCH 0/7] Fix for transparent gif creation
On Wed, Oct 4, 2017 at 2:50 AM, Clément Bœsch wrote: > On Mon, Oct 02, 2017 at 01:24:32PM -0400, Bjorn Roche wrote: > [...] > > Bjorn Roche (7): > > First pass at fixing paletteuse > > Fix for dithering. > > Removing some debugging > > First pass at making the gif support transparency with the right > > disposal methods. Needs more optimization. > > Reimplement optimization for transparency > > cleanup > > Fix for detecting opaque correctly. > > Please organize your patches in atomic changes instead of your > chronological construction: > > - a patch should ideally change only one thing > - each patch should be applicable without breaking anything > - changes that do not belong at the end of the patchset should not be > present in the middle of the history unless technically required (your > debug logs don't). > Thank you Clement. I cleaned it up and sent a separate patch just for paletteuse in response to a similar request from Carl Eugen. bjorn -- Bjorn Roche Sr. Video Pipeline Engineer bj...@giphy.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/blockdsp : add clear_blocks_prores func (SSE, AVX) for prores decoding
On Thu, Oct 5, 2017 at 4:58 PM, Martin Vignali wrote:
> Hello,
>
> In attach patchs to add a dedicated func for clear_block inside
> prores decoding (proresdec2)
>
> currently slice decode func use a loop and call the blockdsp.clear_block
> func
>
> After some test, it seems to be slower, than memset (for me)
> I check using this "fake" func in the blockdsp
> static void ff_clear_blocks_prores_sse_loop(int16_t * blocks, ptrdiff_t
> block_count){
> int i;
> for (i = 0; i < block_count; i++)
> ff_clear_block_sse(blocks+(i<<6));
> }
>
> static void ff_clear_blocks_prores_avx_loop(int16_t * blocks, ptrdiff_t
> block_count){
> int i;
> for (i = 0; i < block_count; i++)
> ff_clear_block_avx(blocks+(i<<6));
> }
>
> the result in checkasm are (need patch in attach to reproduce the test) :
> using the loop
> blockdsp.clear_blocks_prores_c: 137.8
> blockdsp.clear_blocks_prores_sse: 292.0
> blockdsp.clear_blocks_prores_avx: 230.5
>
>
> Using the new asm func this is the result (Kaby Lake, os 10.12, Clang 8.1)
> blockdsp.clear_blocks_prores_c: 153.4
> blockdsp.clear_blocks_prores_sse: 284.4
> blockdsp.clear_blocks_prores_avx: 142.2
>
>
This is still slower then the memset numbers from the first test, why
the high variation in there?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] update ffmpeg to recognise and build with newest openjpeg available in its git, up from v2.2 to v2.3
I have attempted to post my first patch suggestion per
https://trac.ffmpeg.org/ticket/6719#comment:1
If I have done something wrong, please feel free to say so (and how to fix it,
if possible).
Openjpeg git at https://github.com/uclouvain/openjpeg is up from v2.2 to v2.3,
which means that ffmpeg no longer builds with the openjpeg dependency as built
from its git.
The patch seems to fix ffmpeg so that it builds with openjpeg v2.3 as a
dependency built from its git.
From 80412c4b26d197e9627b097443e7032c106de4ff Mon Sep 17 00:00:00 2001
From: hydra
Date: Fri, 6 Oct 2017 02:19:34 +1030
Subject: [PATCH] update ffmpeg to recognise and build with newest openjpeg
available in its git, up from v2.2 to v2.3
---
configure | 11 +++
libavcodec/libopenjpegdec.c | 8 +---
libavcodec/libopenjpegenc.c | 10 ++
3 files changed, 18 insertions(+), 11 deletions(-)
mode change 100755 => 100644 configure
diff --git a/configure b/configure
old mode 100755
new mode 100644
index 391c141e7a..3c8f84b0c8
--- a/configure
+++ b/configure
@@ -1930,6 +1930,7 @@ HEADERS_LIST="
machine_ioctl_meteor_h
malloc_h
opencv2_core_core_c_h
+openjpeg_2_3_openjpeg_h
openjpeg_2_2_openjpeg_h
openjpeg_2_1_openjpeg_h
openjpeg_2_0_openjpeg_h
@@ -5910,7 +5911,7 @@ enabled libbs2b && require_pkg_config libbs2b
libbs2b bs2b.h bs2b_open
enabled libcelt && require libcelt celt/celt.h celt_decode -lcelt0 &&
{ check_lib libcelt celt/celt.h
celt_decoder_create_custom -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 libcaca && require_pkg_config libcaca caca caca.h
caca_create_canvas -DCACA_STATIC && add_cppflags -DCACA_STATIC
enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
dc1394/dc1394.h dc1394_new
enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
enabled libfdk_aac&& { use_pkg_config libfdk_aac fdk-aac
"fdk-aac/aacenc_lib.h" aacEncOpen ||
@@ -5937,7 +5938,7 @@ enabled libkvazaar&& require_pkg_config
libkvazaar "kvazaar >= 0.8.1" kv
# can find the libraries and headers through other means.
enabled libmfx&& { use_pkg_config libmfx libmfx "mfx/mfxvideo.h"
MFXInit ||
{ require libmfx "mfx/mfxvideo.h" MFXInit
-llibmfx && warn "using libmfx without pkg-config"; } }
-enabled libmodplug&& require_pkg_config libmodplug libmodplug
libmodplug/modplug.h ModPlug_Load
+enabled libmodplug&& require_pkg_config libmodplug libmodplug
libmodplug/modplug.h ModPlug_Load -DMODPLUG_STATIC && add_cppflags
-DMODPLUG_STATIC
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h
lame_set_VBR_quality -lmp3lame
enabled libmysofa && require libmysofa "mysofa.h" mysofa_load -lmysofa
enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig
-lnppicc -lnppc ||
@@ -5950,7 +5951,9 @@ enabled libopencv && { check_header
opencv2/core/core_c.h &&
require opencv opencv2/core/core_c.h
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config libopencv opencv
opencv/cxcore.h cvCreateImageHeader; }
enabled libopenh264 && require_pkg_config libopenh264 openh264
wels/codec_api.h WelsGetCodecVersion
-enabled libopenjpeg && { { check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+enabled libopenjpeg && { { check_lib libopenjpeg openjpeg-2.3/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+ check_lib libopenjpeg openjpeg-2.3/openjpeg.h
opj_version -lopenjp2 ||
+ { check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 ||
{ check_lib libopenjpeg openjpeg-2.1/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.1/openjpeg.h
opj_version -lopenjp2 ||
@@ -5980,7 +5983,7 @@ enabled libssh&& require_pkg_config libssh
libssh libssh/sftp.h sftp
enabled libspeex && require_pkg_config libspeex speex speex/speex.h
speex_decoder_init -lspeex
enabled libtesseract && require_pkg_config libtesseract tesseract
tesseract/capi.h TessBaseAPICreate
enabled libtheora && require libtheora theora/theoraenc.h th_info_init
-ltheoraenc -ltheoradec -logg
-enabled libtwolame&& require libtwolame twolame.h twolame_init
-ltwolame &&
+enable
Re: [FFmpeg-devel] [PATCH 1/2] mov: fix decode of fragments that overlap in time
On 10/04/2017 03:21 PM, Michael Niedermayer wrote: > On Wed, Oct 04, 2017 at 10:58:19AM -0700, John Stebbins wrote: >> On 10/04/2017 10:13 AM, Michael Niedermayer wrote: >>> On Wed, Oct 04, 2017 at 08:18:59AM -0700, John Stebbins wrote: On 10/04/2017 03:50 AM, Michael Niedermayer wrote: > On Fri, Sep 29, 2017 at 08:54:08AM -0700, John Stebbins wrote: >> When keyframe intervals of dash segments are not perfectly aligned, >> fragments in the stream can overlap in time. Append new "trun" index >> entries to the end of the index instead of sorting by timestamp. >> Sorting by timestamp causes packets to be read out of decode order and >> results in decode errors. >> --- >> libavformat/mov.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavformat/mov.c b/libavformat/mov.c >> index 899690d920..c7422cd9ed 100644 >> --- a/libavformat/mov.c >> +++ b/libavformat/mov.c >> @@ -4340,8 +4340,8 @@ static int mov_read_trun(MOVContext *c, >> AVIOContext *pb, MOVAtom atom) >>MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES)); >> if (keyframe) >> distance = 0; >> -ctts_index = av_add_index_entry(st, offset, dts, sample_size, >> distance, >> -keyframe ? AVINDEX_KEYFRAME : >> 0); >> +ctts_index = add_index_entry(st, offset, dts, sample_size, >> distance, >> + keyframe ? AVINDEX_KEYFRAME : 0); > can this lead to timestamps being out of order not just changing > from strictly monotone to monotone ? > > Maybe iam missing somehing but out of order could/would cause problems > with av_index_search_timestamp() and possibly others > > I'm not sure I understand the question. But I think I can answer. The new fragment can start before the last fragment ends. I'll make a concrete example. Lets say the new fragment's first DTS is 10 frames before the end of the previous fragment. So the first DTS of the new fragment is before the timestamp of 10 entries in the index from the previous fragment. av_add_index_entry searches the existing index and inserts the first sample of the new fragment in position nb_index_entries - 10 (and shifts the existing entries). The next 9 samples of the new fragment get intermixed with the remaining 9 samples of the previous fragment, sorted by DTS. When the samples are read out, you get samples from the last fragment and the new fragment interleaved together causing decoding errors. Using add_index_entry will result in the timestamps in the index going backwards by 10 frames at the fragment boundary in this example. In the other patch that accompanied this one, I've marked the samples from the new fragment that overlap previous samples with AVINDEX_DISCARD. ff_index_search_timestamp appears to be AVINDEX_DISCARD aware. So I think av_index_search_timestamp will do the right thing. >>> yes, that makes sense now. >>> Please correct me if iam wrong but then patch 1 would introduce a >>> issue that the 2nd fixes. So both patches should be merged to avoid >>> this >>> >>> But theres another problem, trun can be read out of order, when one >>> seeks around, so the next might have to be put elsewhere than after the >>> previous >>> >>> thanks >>> >> Hmm, can you describe the circumstances where this would happen. I looked >> at the seek code and can't see any way for it >> to seek to the middle somewhere without first reading previous trun. It >> looks to me like if avformat_seek_file or >> av_seek_frame fails to find the desired timestamp in the index it falls back >> to seek_frame_generic which seeks to the >> position of the last sample in the index and performs av_read_frame until it >> gets to the timestamp it wants. Is there a >> path I've missed where it can skip to the middle of the file somehow? > I used > -rw-r- 1 michael michael 66908195 Dec 11 2015 buck480p30_na.mp4 > ./ffplay buck480p30_na.mp4 > > (i can upload this if needed, i dont know where its from exactly) > > and when seeking around by using the right mouse buttonq it sometimes read > trun chunks with lower times than previous (seen from the av_logs in > there) > > I hope i made no mistake and would assume this happens with any file > with these chunks > > ... > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f3884000940] AVIndex stream 0, sample 151, > offset 60134, dts 45, size 194, distance 25, keyframe 0 > ... > Seek to 68% ( 0:07:11) of total duration ( 0:10:34) > ... > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f3884000940] AVIndex stream 0, sample 152, > offset 2b74fd6, dts 38757000, size 8284, distance 0, keyframe 1 > ... > Seek to 14% ( 0:01:29) of total duration ( 0:10:34) > ... > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f388400094
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Wed, Oct 04, 2017 at 02:04:54PM +0200, wm4 wrote: > On Wed, 4 Oct 2017 13:37:31 +0200 > Tobias Rapp wrote: > > > On 04.10.2017 11:34, wm4 wrote: > > > On Wed, 4 Oct 2017 11:22:37 +0200 > > > Michael Niedermayer wrote: > > > > > >> On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: > > >>> On Tue, 3 Oct 2017 21:40:58 +0200 > > >>> Michael Niedermayer wrote: > > >>> > > On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: > > > From: Anton Khirnov > > > > > > > > Use the AVFrame.opaque_ref field. The original user's opaque_ref is > > > wrapped in the lavc struct and then unwrapped before the frame is > > > returned to the caller. > > > > this is a ugly hack > > > > one and the same field should not be used to hold both the > > users opaque_ref as well as a structure which is itself not a user > > opaque_ref > > >>> > > >>> While the AVFrame is within libavcodec, it's libavcodec's frame, not > > >>> the user's. Thus your claim doesn't make too much sense. libavcodec > > >>> fully controls the meaning for its own AVFrames' opaque_ref, but > > >>> reconstruct the user's value when returning it. > > >> > > >> i disagree > > > > > > Well, you're wrong anyway. > > > > > >> such hacks should not be added, we do have enough hacks already > > > > > > It's not a hack. > > > > Changing the semantics of a field during its lifetime, even when only > > done within private code, is at least unexpected behavior. > > That's not done. The semantics are defined by the docs, which state: "AVBufferRef for free use by the API user." And before the patch this is true, all instances of this field are controled by the user application and are consistent. after the patch the AVFrames used by a codec have their opaque_ref replaced by a wraped structure relative to what the outside of this codec has. > Conceptually the AVFrame with the changed behavior is > a new reference. Internally, AVFrame.opaque_ref will always have the > same semantics, pointing to the FrameDecodeData struct. Only at points > where the AVFrame ref is converted to/from the user struct this is > changed. > > > > This is done strictly when returning a valid AVFrame, so there is no > > > room for mistakes. > > > > The room for mistake might not increase for external developers but it > > increases for internal developers (maintenance cost). > > Like where? There are only 2 places where the code needs to deal with > it, and these are in shared code, not individual decoders. just greping for AVFrame in the headers shows callbacks, a direct pointer to a AVFrame and the API functions that interface the codec Just thinking of a codec that instanciates another codec and how exactly the callback which may originate from the user or the outer codec would unwrap the potential nested wraping. I really dont think we want this in FFmpeg And this is just one example ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/blockdsp : add clear_blocks_prores func (SSE, AVX) for prores decoding
2017-10-05 18:04 GMT+02:00 Hendrik Leppkes :
> On Thu, Oct 5, 2017 at 4:58 PM, Martin Vignali
> wrote:
> > Hello,
> >
> > In attach patchs to add a dedicated func for clear_block inside
> > prores decoding (proresdec2)
> >
> > currently slice decode func use a loop and call the blockdsp.clear_block
> > func
> >
> > After some test, it seems to be slower, than memset (for me)
> > I check using this "fake" func in the blockdsp
> > static void ff_clear_blocks_prores_sse_loop(int16_t * blocks, ptrdiff_t
> > block_count){
> > int i;
> > for (i = 0; i < block_count; i++)
> > ff_clear_block_sse(blocks+(i<<6));
> > }
> >
> > static void ff_clear_blocks_prores_avx_loop(int16_t * blocks, ptrdiff_t
> > block_count){
> > int i;
> > for (i = 0; i < block_count; i++)
> > ff_clear_block_avx(blocks+(i<<6));
> > }
> >
> > the result in checkasm are (need patch in attach to reproduce the test) :
> > using the loop
> > blockdsp.clear_blocks_prores_c: 137.8
> > blockdsp.clear_blocks_prores_sse: 292.0
> > blockdsp.clear_blocks_prores_avx: 230.5
> >
> >
> > Using the new asm func this is the result (Kaby Lake, os 10.12, Clang
> 8.1)
> > blockdsp.clear_blocks_prores_c: 153.4
> > blockdsp.clear_blocks_prores_sse: 284.4
> > blockdsp.clear_blocks_prores_avx: 142.2
> >
> >
>
> This is still slower then the memset numbers from the first test, why
> the high variation in there?
>
> Hello,
Don't know why, i often have this kind of variation between each test with
check_asm (and with -benchmark (like in other thread of exr simd, where the
decoding of the image sequence, have several variation)
In both test, this is the same c func
But if i run the same test several time, with the new asm, i always have an
avx version faster than C (who seems to be already optimized in my computer)
(and following James Almer answer in discussion : libavcodec/blockdsp : add
AVX version, having avx/sse for this simple func, can be interesting on
some computer/compiler...)
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] lavc: add support for OpenJPEG 2.3.0
On 10/5/2017 10:45 AM, Michael Bradshaw wrote:
> From: Michael Bradshaw
>
> Signed-off-by: Michael Bradshaw
> ---
> configure | 5 -
> libavcodec/libopenjpegdec.c | 8 +---
> libavcodec/libopenjpegenc.c | 10 ++
> 3 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/configure b/configure
> index 391c141e7a..77c9a18c3c 100755
> --- a/configure
> +++ b/configure
> @@ -1930,6 +1930,7 @@ HEADERS_LIST="
> machine_ioctl_meteor_h
> malloc_h
> opencv2_core_core_c_h
> +openjpeg_2_3_openjpeg_h
Is there a reason OpenJPEG uses a different folder to store the header
with each release from the 2.x family? It's really bloating both
configure and the wrappers.
> openjpeg_2_2_openjpeg_h
> openjpeg_2_1_openjpeg_h
> openjpeg_2_0_openjpeg_h
> @@ -5950,7 +5951,9 @@ enabled libopencv && { check_header
> opencv2/core/core_c.h &&
> require opencv opencv2/core/core_c.h
> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config libopencv opencv
> opencv/cxcore.h cvCreateImageHeader; }
> enabled libopenh264 && require_pkg_config libopenh264 openh264
> wels/codec_api.h WelsGetCodecVersion
> -enabled libopenjpeg && { { check_lib libopenjpeg
> openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
> -DOPJ_STATIC; } ||
> +enabled libopenjpeg && { { check_lib libopenjpeg
> openjpeg-2.3/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
> -DOPJ_STATIC; } ||
> + check_lib libopenjpeg openjpeg-2.3/openjpeg.h
> opj_version -lopenjp2 ||
> + { check_lib libopenjpeg
> openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
> -DOPJ_STATIC; } ||
> check_lib libopenjpeg openjpeg-2.2/openjpeg.h
> opj_version -lopenjp2 ||
> { check_lib libopenjpeg
> openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
> -DOPJ_STATIC; } ||
> check_lib libopenjpeg openjpeg-2.1/openjpeg.h
> opj_version -lopenjp2 ||
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 1210123265..67d47bd6a0 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -34,7 +34,9 @@
> #include "internal.h"
> #include "thread.h"
>
> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H
> +# include
> +#elif HAVE_OPENJPEG_2_2_OPENJPEG_H
> # include
> #elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> # include
> @@ -46,7 +48,7 @@
> # include
> #endif
>
> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
> HAVE_OPENJPEG_2_0_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
> HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
> # define OPENJPEG_MAJOR_VERSION 2
> # define OPJ(x) OPJ_##x
> #else
> @@ -431,7 +433,7 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
> opj_stream_set_read_function(stream, stream_read);
> opj_stream_set_skip_function(stream, stream_skip);
> opj_stream_set_seek_function(stream, stream_seek);
> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
> HAVE_OPENJPEG_2_1_OPENJPEG_H
> opj_stream_set_user_data(stream, &reader, NULL);
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> opj_stream_set_user_data(stream, &reader);
Oh, i see. They don't care about breaking API...
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index b67e533d1d..92b4433b04 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -32,7 +32,9 @@
> #include "avcodec.h"
> #include "internal.h"
>
> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H
> +# include
> +#elif HAVE_OPENJPEG_2_2_OPENJPEG_H
> # include
> #elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> # include
> @@ -44,7 +46,7 @@
> # include
> #endif
>
> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
> HAVE_OPENJPEG_2_0_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
> HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
> # define OPENJPEG_MAJOR_VERSION 2
> # define OPJ(x) OPJ_##x
> #else
> @@ -307,7 +309,7 @@ static av_cold int libopenjpeg_encode_init(AVCodecContext
> *avctx)
>
> opj_set_default_encoder_parameters(&ctx->enc_params);
>
> -#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
> HAVE_OPENJPEG_2_1_OPENJPEG_H
> switch (ctx->cinema_mode) {
> case OPJ_CINEMA2K_24:
> ctx->enc_params.rsiz = OPJ_PROFILE_CINEMA_2K;
> @@ -771,7 +773,7 @@ static int libopenjpeg_encode_frame(AVCodecContext
Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information
29.09.2017 0:20, Carl Eugen Hoyos пише: Hi! I don't have decklink hardware but I assume it never outputs actual transparency. Or does it? it outputs or use internal keyer to put it over passthrow SDI signal. in external keyer mode it accept BGRA frame and output two SDI signals: one for *fill* another one for *key* -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/7] Removing some debugging
On Thu, Oct 05, 2017 at 10:43:04AM -0400, Bjorn Roche wrote:
> On Tue, Oct 3, 2017 at 4:02 AM, Carl Eugen Hoyos wrote:
>
> > 2017-10-03 1:52 GMT+02:00 Bjorn Roche :
> >
> > > Attached is a patch for paletteuse only.
> >
> > I tested the following with and without your patch:
> > $ ffmpeg -i fate-suite/lena.pnm -vf palettegen pal.png
> > $ ffmpeg -i fate-suite/lena.pnm -i pal.png -lavfi paletteuse out.png
> >
> > out.png changes with your patch: Is that intended?
> >
>
> Not intended, but not unexpected -- the ordering of colors in the palette
> changed to make it easier to deal with transparency. However, there are
> visual differences, so that's obviously a bug. I've supplied a new patch
> (below) that fixes that bug, and maintains the order so it's easier to test
> for that.
>
>
> > The input frame contains no transparency.
> >
> > Your patch still contains printfs that should be removed
> > (change them to av_log(DEBUG) if you think they are
> > useful) and a new warning is shown at compilation:
> > libavfilter/vf_paletteuse.c: In function ‘colormap_nearest_recursive’:
> > libavfilter/vf_paletteuse.c:242:5: warning: ISO C90 forbids mixed
> > declarations and code
> >
> > Please fix the style: Space after "if", no space after "if ("
> >
>
> Thank you for your attention. This should also be resolved in the attached
> patch.
>
> I have tested fate, all dithering (including none, which I added) and all
> color search algorithms.
> vf_paletteuse.c | 163
> ++--
> 1 file changed, 101 insertions(+), 62 deletions(-)
> 3d215b0705c5352700ed11c6ab8fd8638c9fea48 palette-use-transparency2.diff
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index ffd37bf1da..7cb5a3db02 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -56,7 +56,7 @@ enum diff_mode {
This is not a git patch with commit message, all patches should
contain a commit message
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] Add support for 10-bit output for Decklink SDI
Hello Marton,
Thanks for taking the time to provide feedback.
>> + } else {
>> +*buffer = (void *)(_avpacket->data);
>
> The DeckLink SDK requires a 128 byte alignment for data. I am thinking
> AVPacket does not always provides that. Maybe we should simply ignore the SDK
> requirement (if it works without it?) Can you test this somehow?
The SDK does expect the stride to be a multiple of 128 (which the v210 codec
does), and the SDK does suggest that each line should start on a 128-byte
aligned boundary. I’ve worked with three or four different implementations on
both the input and output side, and never had an issue where alignment was a
problem. That said, it’s possible that the issue is present on some less
common model decklink card, or perhaps the implementation of some feature
internal to the SDK has optimized assembly which expects the alignment.
In any case, it would be a pre-existing bug in libavcodec/v210enc.c, not
something specific to the decklink output.
If someone wants to point me to an example of aligned allocation in libavcodec,
I can take a look. I think any such issue though would be separate from the
content in this patch.
The other issues you mentioned have been addressed and I’m testing the changes
now. I should have updated patches for you shortly.
Regards,
Devin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Thu, 5 Oct 2017 18:47:01 +0200 Michael Niedermayer wrote: > On Wed, Oct 04, 2017 at 02:04:54PM +0200, wm4 wrote: > > On Wed, 4 Oct 2017 13:37:31 +0200 > > Tobias Rapp wrote: > > > > > On 04.10.2017 11:34, wm4 wrote: > > > > On Wed, 4 Oct 2017 11:22:37 +0200 > > > > Michael Niedermayer wrote: > > > > > > > >> On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: > > > >>> On Tue, 3 Oct 2017 21:40:58 +0200 > > > >>> Michael Niedermayer wrote: > > > >>> > > > On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: > > > > From: Anton Khirnov > > > > > > > > > > > Use the AVFrame.opaque_ref field. The original user's opaque_ref is > > > > wrapped in the lavc struct and then unwrapped before the frame is > > > > returned to the caller. > > > > > > this is a ugly hack > > > > > > one and the same field should not be used to hold both the > > > users opaque_ref as well as a structure which is itself not a user > > > opaque_ref > > > >>> > > > >>> While the AVFrame is within libavcodec, it's libavcodec's frame, not > > > >>> the user's. Thus your claim doesn't make too much sense. libavcodec > > > >>> fully controls the meaning for its own AVFrames' opaque_ref, but > > > >>> reconstruct the user's value when returning it. > > > >> > > > >> i disagree > > > > > > > > Well, you're wrong anyway. > > > > > > > >> such hacks should not be added, we do have enough hacks already > > > > > > > > It's not a hack. > > > > > > Changing the semantics of a field during its lifetime, even when only > > > done within private code, is at least unexpected behavior. > > > > That's not done. > > The semantics are defined by the docs, which state: > "AVBufferRef for free use by the API user." libavcodec is the API user. I know the semantics of opaque_ref very well btw., because I added it. > And before the patch this is true, all instances of this field are > controled by the user application and are consistent. The "user" is the AVFrame user, which includes libavcodec. > after the patch the AVFrames used by a codec have their opaque_ref > replaced by a wraped structure relative to what the outside of this > codec has. > > > > Conceptually the AVFrame with the changed behavior is > > a new reference. Internally, AVFrame.opaque_ref will always have the > > same semantics, pointing to the FrameDecodeData struct. Only at points > > where the AVFrame ref is converted to/from the user struct this is > > changed. > > > > > > This is done strictly when returning a valid AVFrame, so there is no > > > > room for mistakes. > > > > > > The room for mistake might not increase for external developers but it > > > increases for internal developers (maintenance cost). > > > > Like where? There are only 2 places where the code needs to deal with > > it, and these are in shared code, not individual decoders. > > just greping for AVFrame in the headers shows callbacks, a direct > pointer to a AVFrame and the API functions that interface the codec Do you mean get_buffer? I explained that in-depth. > Just thinking of a codec that instanciates another codec and how > exactly the callback which may originate from the user or the outer > codec would unwrap the potential nested wraping. That would happen only if you'd nest get_buffer in an incorrect way. "Nested codecs" are an ugly hack anyway that are likely to break other things, especially if get_buffer is used. I see two decoders which recursively open other codecs (weird jpg variants). Both would not be broken by this patch, because they don't proxy get_buffer to the underlying codecs. (But what I see is that they require shitty ugly hacks due to shitty ugly codec locking, which was added as shitty ugly hack for shitty ugly broken shit. But apparently accepting that kind of code in FFmpeg is strangely no problem.) > I really dont think we want this in FFmpeg Why so obstinate. > And this is just one example ... Your one example was invalid, next one please. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] libavdevice/decklink: add support for -sources and -sinks arguments
Add support for enumerating the sources/sinks via the ffmpeg
command line options, as opposed to having to create a real pipeline
and use the "-list_devices" option which does exit() after dumping
out the options.
Note that this patch preserves the existing "-list_devices" option,
but now shares common code for the actual enumeration.
Updated to reflect feedback from Marton Balink .
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_common.cpp | 89 ++---
libavdevice/decklink_common.h | 3 +-
libavdevice/decklink_dec.cpp| 8 +++-
libavdevice/decklink_dec.h | 1 +
libavdevice/decklink_dec_c.c| 1 +
libavdevice/decklink_enc.cpp| 10 -
libavdevice/decklink_enc.h | 1 +
libavdevice/decklink_enc_c.c| 1 +
8 files changed, 104 insertions(+), 10 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index c782171f2c..61d8ad86a9 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -37,6 +37,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/bswap.h"
+#include "avdevice.h"
}
#include "decklink_common.h"
@@ -261,24 +262,100 @@ int ff_decklink_set_format(AVFormatContext *avctx,
decklink_direction_t directio
return ff_decklink_set_format(avctx, 0, 0, 0, 0, AV_FIELD_UNKNOWN,
direction, num);
}
-int ff_decklink_list_devices(AVFormatContext *avctx)
+int ff_decklink_list_devices(AVFormatContext *avctx,
+struct AVDeviceInfoList *device_list,
+int show_inputs, int show_outputs)
{
IDeckLink *dl = NULL;
IDeckLinkIterator *iter = CreateDeckLinkIteratorInstance();
+int ret = 0;
+
if (!iter) {
av_log(avctx, AV_LOG_ERROR, "Could not create DeckLink iterator\n");
return AVERROR(EIO);
}
-av_log(avctx, AV_LOG_INFO, "Blackmagic DeckLink devices:\n");
-while (iter->Next(&dl) == S_OK) {
+
+while (ret == 0 && iter->Next(&dl) == S_OK) {
+IDeckLinkOutput *output_config;
+IDeckLinkInput *input_config;
const char *displayName;
+AVDeviceInfo *new_device = NULL;
+int add = 0;
+
ff_decklink_get_display_name(dl, &displayName);
-av_log(avctx, AV_LOG_INFO, "\t'%s'\n", displayName);
-av_free((void *) displayName);
+
+if (show_outputs) {
+if (dl->QueryInterface(IID_IDeckLinkOutput, (void
**)&output_config) == S_OK) {
+output_config->Release();
+add = 1;
+}
+}
+
+if (show_inputs) {
+if (dl->QueryInterface(IID_IDeckLinkInput, (void **)&input_config)
== S_OK) {
+input_config->Release();
+add = 1;
+}
+}
+
+if (add == 1) {
+new_device = (AVDeviceInfo *) av_mallocz(sizeof(AVDeviceInfo));
+if (!new_device) {
+ret = AVERROR(ENOMEM);
+goto next;
+}
+new_device->device_name = av_strdup(displayName);
+if (!new_device->device_name) {
+ret = AVERROR(ENOMEM);
+goto next;
+}
+
+new_device->device_description = av_strdup(displayName);
+if (!new_device->device_description) {
+av_freep(&new_device->device_name);
+ret = AVERROR(ENOMEM);
+goto next;
+}
+
+if ((ret = av_dynarray_add_nofree(&device_list->devices,
+ &device_list->nb_devices,
new_device)) < 0) {
+av_freep(&new_device->device_name);
+av_freep(&new_device->device_description);
+av_freep(&new_device);
+goto next;
+}
+}
+
+next:
+av_freep(&displayName);
dl->Release();
}
iter->Release();
-return 0;
+return ret;
+}
+
+/* This is a wrapper around the ff_decklink_list_devices() which dumps the
+ output to av_log() and exits (for backward compatibility with the
+ "-list_devices" argument). */
+void ff_decklink_list_devices_legacy(AVFormatContext *avctx,
+ int show_inputs, int show_outputs)
+{
+struct AVDeviceInfoList *device_list = NULL;
+int ret;
+
+device_list = (struct AVDeviceInfoList *)
av_mallocz(sizeof(AVDeviceInfoList));
+if (!device_list)
+return;
+
+ret = ff_decklink_list_devices(avctx, device_list, show_inputs,
show_outputs);
+if (ret == 0) {
+av_log(avctx, AV_LOG_INFO, "Blackmagic DeckLink %s devices:\n",
+ show_inputs ? "input" : "output");
+for (int i = 0; i < device_list->nb_devices; i++) {
+av_log(avctx, AV_LOG_INFO, "\t'%s'\n",
device_list->devices[i]->device_name);
+}
+}
+avdevice_free_list_devices(&device_list);
}
int
[FFmpeg-devel] [PATCH 2/2] libavdevice/decklink: add support for 10-bit output for Decklink SDI
Can be tested via the following command:
./ffmpeg -i foo.ts -f decklink -vcodec v210 'DeckLink Duo (1)'
Note that the 8-bit support works as it did before, and setting
the pix_fmt isn't required for 10-bit mode. The code defaults to
operating in 8-bit mode when no vcodec is specified, for backward
compatibility.
Updated to reflect feedback from Marton Balink
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_enc.cpp | 112 ---
1 file changed, 83 insertions(+), 29 deletions(-)
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 0776741812..81df563b3b 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -44,20 +44,45 @@ extern "C" {
class decklink_frame : public IDeckLinkVideoFrame
{
public:
-decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe) :
- _ctx(ctx), _avframe(avframe), _refs(1) { }
-
-virtual long STDMETHODCALLTYPE GetWidth (void) {
return _avframe->width; }
-virtual long STDMETHODCALLTYPE GetHeight (void) {
return _avframe->height; }
-virtual long STDMETHODCALLTYPE GetRowBytes (void) {
return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] :
_avframe->linesize[0]; }
-virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void) {
return bmdFormat8BitYUV; }
-virtual BMDFrameFlags STDMETHODCALLTYPE GetFlags (void) {
return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical :
bmdFrameFlagDefault; }
-virtual HRESULTSTDMETHODCALLTYPE GetBytes (void **buffer)
+decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, AVCodecID
codec_id, int height, int width) :
+_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+decklink_frame(struct decklink_ctx *ctx, AVPacket *avpacket, AVCodecID
codec_id, int height, int width) :
+_ctx(ctx), _avframe(NULL), _avpacket(avpacket), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+
+virtual long STDMETHODCALLTYPE GetWidth (void) {
return _width; }
+virtual long STDMETHODCALLTYPE GetHeight (void) {
return _height; }
+virtual long STDMETHODCALLTYPE GetRowBytes (void)
+{
+ if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+ return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] :
_avframe->linesize[0];
+ else
+ return ((GetWidth() + 47) / 48) * 128;
+}
+virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void)
{
-if (_avframe->linesize[0] < 0)
-*buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] *
(_avframe->height - 1));
+if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+return bmdFormat8BitYUV;
else
-*buffer = (void *)(_avframe->data[0]);
+return bmdFormat10BitYUV;
+}
+virtual BMDFrameFlags STDMETHODCALLTYPE GetFlags (void)
+{
+ if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+ return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical :
bmdFrameFlagDefault;
+ else
+ return bmdFrameFlagDefault;
+}
+
+virtual HRESULTSTDMETHODCALLTYPE GetBytes (void **buffer)
+{
+if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+if (_avframe->linesize[0] < 0)
+*buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] *
(_avframe->height - 1));
+else
+*buffer = (void *)(_avframe->data[0]);
+} else {
+*buffer = (void *)(_avpacket->data);
+}
return S_OK;
}
@@ -71,6 +96,7 @@ public:
int ret = --_refs;
if (!ret) {
av_frame_free(&_avframe);
+av_packet_free(&_avpacket);
delete this;
}
return ret;
@@ -78,6 +104,10 @@ public:
struct decklink_ctx *_ctx;
AVFrame *_avframe;
+AVPacket *_avpacket;
+AVCodecID _codec_id;
+int _height;
+int _width;
private:
std::atomic _refs;
@@ -90,9 +120,11 @@ public:
{
decklink_frame *frame = static_cast(_frame);
struct decklink_ctx *ctx = frame->_ctx;
-AVFrame *avframe = frame->_avframe;
-av_frame_unref(avframe);
+if (frame->_avframe)
+av_frame_unref(frame->_avframe);
+if (frame->_avpacket)
+av_packet_unref(frame->_avpacket);
pthread_mutex_lock(&ctx->mutex);
ctx->frames_buffer_available_spots++;
@@ -118,11 +150,18 @@ static int decklink_setup_video(AVFormatContext *avctx,
AVStream *st)
return -1;
}
-if (c->format != AV_PIX_FMT_UYVY422) {
-av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!"
- " Only AV_PIX_FMT_UYVY422 is supported.\n");
+if (c->cod
[FFmpeg-devel] [PATCHv2 0/2] avdevice/decklink: 10-bit video out and sources/sinks support
Hello all, Below please find several patches which adds support for 10-bit video on output and the "-sources" and"-sinks" argument when specified by ffmpeg.c. This patch series incorporates feedback provided from Marton Balint. Note that patch 4 in the previous patch series was consolidated into patch 3 per Marton's suggestion. If you have any question/concerns, please don't hesitate to reply. Thanks, Devin Heitmueller Devin Heitmueller (2): libavdevice/decklink: add support for -sources and -sinks arguments libavdevice/decklink: add support for 10-bit output for Decklink SDI libavdevice/decklink_common.cpp | 89 +++-- libavdevice/decklink_common.h | 3 +- libavdevice/decklink_dec.cpp| 8 ++- libavdevice/decklink_dec.h | 1 + libavdevice/decklink_dec_c.c| 1 + libavdevice/decklink_enc.cpp| 122 ++-- libavdevice/decklink_enc.h | 1 + libavdevice/decklink_enc_c.c| 1 + 8 files changed, 187 insertions(+), 39 deletions(-) -- 2.13.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/7] Removing some debugging
2017-10-05 16:43 GMT+02:00 Bjorn Roche :
> On Tue, Oct 3, 2017 at 4:02 AM, Carl Eugen Hoyos wrote:
>
>> 2017-10-03 1:52 GMT+02:00 Bjorn Roche :
>>
>> > Attached is a patch for paletteuse only.
>>
>> I tested the following with and without your patch:
>> $ ffmpeg -i fate-suite/lena.pnm -vf palettegen pal.png
>> $ ffmpeg -i fate-suite/lena.pnm -i pal.png -lavfi paletteuse out.png
>>
>> out.png changes with your patch: Is that intended?
>
> Not intended, but not unexpected -- the ordering of colors in the palette
> changed to make it easier to deal with transparency. However, there are
> visual differences, so that's obviously a bug. I've supplied a new patch
> (below) that fixes that bug, and maintains the order so it's easier to test
> for that.
>
>> The input frame contains no transparency.
>>
>> Your patch still contains printfs that should be removed
>> (change them to av_log(DEBUG) if you think they are
>> useful) and a new warning is shown at compilation:
>> libavfilter/vf_paletteuse.c: In function ‘colormap_nearest_recursive’:
>> libavfilter/vf_paletteuse.c:242:5: warning: ISO C90 forbids mixed
>> declarations and code
>>
>> Please fix the style: Space after "if", no space after "if ("
>>
>
> Thank you for your attention. This should also be resolved
> in the attached patch.
>
> I have tested fate, all dithering (including none, which I added)
> and all color search algorithms.
I tested the following with the sample from ticket #503:
$ ffmpeg -i rgba64le-lzw.tif -vf palettegen pal.png
$ ffmpeg -i rgba64le-lzw.tif -i pal.png -lavfi paletteuse out.gif
The output file has its background (that is supposed to be
transparent) converted to white (which I believe is good)
but the respective colour white (that is the 256th and last
colour in the palette) is not transparent but opaque (0xff).
Instead the first colour (0x00ff00) is the only transparent
colour in the palette. The output gif is opaque.
I confirmed that if I force the first palette entry to opaque
(0xFF00FF00) and the last one to transparent (0xFF)
in apply_palette() I get the expected transparent output with
above command line.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
2017-10-05 21:22 GMT+02:00 wm4 : >> And this is just one example ... > > Your one example was invalid, next one please. One example is more than enough, we can all see that this is not clean new code. What is wrong about adding a new field if you really need it? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On 05/10/17 17:47, Michael Niedermayer wrote: > On Wed, Oct 04, 2017 at 02:04:54PM +0200, wm4 wrote: >> On Wed, 4 Oct 2017 13:37:31 +0200 >> Tobias Rapp wrote: >> >>> On 04.10.2017 11:34, wm4 wrote: On Wed, 4 Oct 2017 11:22:37 +0200 Michael Niedermayer wrote: > On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: >> On Tue, 3 Oct 2017 21:40:58 +0200 >> Michael Niedermayer wrote: >> >>> On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: From: Anton Khirnov >>> Use the AVFrame.opaque_ref field. The original user's opaque_ref is wrapped in the lavc struct and then unwrapped before the frame is returned to the caller. >>> >>> this is a ugly hack >>> >>> one and the same field should not be used to hold both the >>> users opaque_ref as well as a structure which is itself not a user >>> opaque_ref >> >> While the AVFrame is within libavcodec, it's libavcodec's frame, not >> the user's. Thus your claim doesn't make too much sense. libavcodec >> fully controls the meaning for its own AVFrames' opaque_ref, but >> reconstruct the user's value when returning it. > > i disagree Well, you're wrong anyway. > such hacks should not be added, we do have enough hacks already It's not a hack. >>> >>> Changing the semantics of a field during its lifetime, even when only >>> done within private code, is at least unexpected behavior. >> >> That's not done. > > The semantics are defined by the docs, which state: > "AVBufferRef for free use by the API user." > > And before the patch this is true, all instances of this field are > controled by the user application and are consistent. > > after the patch the AVFrames used by a codec have their opaque_ref > replaced by a wraped structure relative to what the outside of this > codec has. > > >> Conceptually the AVFrame with the changed behavior is >> a new reference. Internally, AVFrame.opaque_ref will always have the >> same semantics, pointing to the FrameDecodeData struct. Only at points >> where the AVFrame ref is converted to/from the user struct this is >> changed. >> This is done strictly when returning a valid AVFrame, so there is no room for mistakes. >>> >>> The room for mistake might not increase for external developers but it >>> increases for internal developers (maintenance cost). >> >> Like where? There are only 2 places where the code needs to deal with >> it, and these are in shared code, not individual decoders. > > just greping for AVFrame in the headers shows callbacks, a direct > pointer to a AVFrame and the API functions that interface the codec > > Just thinking of a codec that instanciates another codec and how > exactly the callback which may originate from the user or the outer > codec would unwrap the potential nested wraping. > I really dont think we want this in FFmpeg > And this is just one example ... I don't understand this discussion. As far as I can tell, the sequence is this: * libavcodec allocates an AVFrame structure. * libavcodec calls get_buffer2 with that AVFrame structure; the user fills its fields. * libavcodec extracts the buffer references and metadata from the AVFrame, and maybe frees it (some codecs reuse a single AVFrame for the lifetime of the codec, others allocate them each time). ~ decoding happens, the buffers are written to ~ * The user allocates a new AVFrame structure. * The user calls receive_frame with that new AVFrame structure; libavcodec its fields with references to the decoded data and associated metadata. * The user can then read the buffers of the frame, along with its metadata. Why would it matter what happens in the middle? The AVFrame structure at the end is not the AVFrame structure at the start, and the user can't assume anything about it at all - if they try to dereference a pointer to the AVFrame supplied by libavcodec for get_buffer2 after get_buffer2 has returned then they are definitely invoking undefined behaviour. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
2017-10-05 16:26 GMT+02:00 Daniel Kucera : > Time to time some devices send UDP packets without payload. > ffmpeg previously exited on receiving such packet Just curious: Is it useful at all to exit on an empty packet? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
2017-10-05 16:32 GMT+02:00 Moritz Barsnick : > Issue: The hls demuxer now inconsistently no longer reports > each opened URL, only the first one. (Reporting of these at > default log-level was only recently added though.) Could you remind me why this was useful? I was about to start a patch to stop printing those debug lines... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: fix id3 chapters
2017-10-05 17:13 GMT+02:00 wm4 : > Pushed, with commit message adjusted to 72 columns limit. You forgot to add the ticket number. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Thu, 5 Oct 2017 22:01:56 +0200 Carl Eugen Hoyos wrote: > 2017-10-05 21:22 GMT+02:00 wm4 : > > >> And this is just one example ... > > > > Your one example was invalid, next one please. > > One example is more than enough, we can all see that this > is not clean new code. But I showed that his example isn't actually a problem. > What is wrong about adding a new field if you really need it? Because AVFrame shouldn't have internal libavcodec fields? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] mov: fix decode of fragments that overlap in time
On 10/05/2017 09:45 AM, John Stebbins wrote: > On 10/04/2017 03:21 PM, Michael Niedermayer wrote: >> On Wed, Oct 04, 2017 at 10:58:19AM -0700, John Stebbins wrote: >>> On 10/04/2017 10:13 AM, Michael Niedermayer wrote: On Wed, Oct 04, 2017 at 08:18:59AM -0700, John Stebbins wrote: > On 10/04/2017 03:50 AM, Michael Niedermayer wrote: >> On Fri, Sep 29, 2017 at 08:54:08AM -0700, John Stebbins wrote: >>> When keyframe intervals of dash segments are not perfectly aligned, >>> fragments in the stream can overlap in time. Append new "trun" index >>> entries to the end of the index instead of sorting by timestamp. >>> Sorting by timestamp causes packets to be read out of decode order and >>> results in decode errors. >>> --- >>> libavformat/mov.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/libavformat/mov.c b/libavformat/mov.c >>> index 899690d920..c7422cd9ed 100644 >>> --- a/libavformat/mov.c >>> +++ b/libavformat/mov.c >>> @@ -4340,8 +4340,8 @@ static int mov_read_trun(MOVContext *c, >>> AVIOContext *pb, MOVAtom atom) >>>MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES)); >>> if (keyframe) >>> distance = 0; >>> -ctts_index = av_add_index_entry(st, offset, dts, sample_size, >>> distance, >>> -keyframe ? AVINDEX_KEYFRAME : >>> 0); >>> +ctts_index = add_index_entry(st, offset, dts, sample_size, >>> distance, >>> + keyframe ? AVINDEX_KEYFRAME : 0); >> can this lead to timestamps being out of order not just changing >> from strictly monotone to monotone ? >> >> Maybe iam missing somehing but out of order could/would cause problems >> with av_index_search_timestamp() and possibly others >> >> > I'm not sure I understand the question. But I think I can answer. The > new fragment can start before the last fragment > ends. I'll make a concrete example. Lets say the new fragment's first > DTS is 10 frames before the end of the previous > fragment. So the first DTS of the new fragment is before the timestamp of > 10 entries in the index from the previous > fragment. av_add_index_entry searches the existing index and inserts the > first sample of the new fragment in position > nb_index_entries - 10 (and shifts the existing entries). The next 9 > samples of the new fragment get intermixed with the > remaining 9 samples of the previous fragment, sorted by DTS. When the > samples are read out, you get samples from the > last fragment and the new fragment interleaved together causing decoding > errors. > > Using add_index_entry will result in the timestamps in the index going > backwards by 10 frames at the fragment boundary > in this example. In the other patch that accompanied this one, I've > marked the samples from the new fragment that > overlap previous samples with AVINDEX_DISCARD. ff_index_search_timestamp > appears to be AVINDEX_DISCARD aware. So I > think av_index_search_timestamp will do the right thing. yes, that makes sense now. Please correct me if iam wrong but then patch 1 would introduce a issue that the 2nd fixes. So both patches should be merged to avoid this But theres another problem, trun can be read out of order, when one seeks around, so the next might have to be put elsewhere than after the previous thanks >>> Hmm, can you describe the circumstances where this would happen. I looked >>> at the seek code and can't see any way for it >>> to seek to the middle somewhere without first reading previous trun. It >>> looks to me like if avformat_seek_file or >>> av_seek_frame fails to find the desired timestamp in the index it falls >>> back to seek_frame_generic which seeks to the >>> position of the last sample in the index and performs av_read_frame until >>> it gets to the timestamp it wants. Is there a >>> path I've missed where it can skip to the middle of the file somehow? >> I used >> -rw-r- 1 michael michael 66908195 Dec 11 2015 buck480p30_na.mp4 >> ./ffplay buck480p30_na.mp4 >> >> (i can upload this if needed, i dont know where its from exactly) >> >> and when seeking around by using the right mouse buttonq it sometimes read >> trun chunks with lower times than previous (seen from the av_logs in >> there) >> >> I hope i made no mistake and would assume this happens with any file >> with these chunks >> >> ... >> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f3884000940] AVIndex stream 0, sample 151, >> offset 60134, dts 45, size 194, distance 25, keyframe 0 >> ... >> Seek to 68% ( 0:07:11) of total duration ( 0:10:34) >> ... >> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f3884000940] AVIndex stream 0, sample 152, >> offset 2b74fd6, dts 38757
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Thu, Oct 05, 2017 at 09:03:40PM +0100, Mark Thompson wrote: > On 05/10/17 17:47, Michael Niedermayer wrote: > > On Wed, Oct 04, 2017 at 02:04:54PM +0200, wm4 wrote: > >> On Wed, 4 Oct 2017 13:37:31 +0200 > >> Tobias Rapp wrote: > >> > >>> On 04.10.2017 11:34, wm4 wrote: > On Wed, 4 Oct 2017 11:22:37 +0200 > Michael Niedermayer wrote: > > > On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: > >> On Tue, 3 Oct 2017 21:40:58 +0200 > >> Michael Niedermayer wrote: > >> > >>> On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: > From: Anton Khirnov > > >>> > Use the AVFrame.opaque_ref field. The original user's opaque_ref is > wrapped in the lavc struct and then unwrapped before the frame is > returned to the caller. > >>> > >>> this is a ugly hack > >>> > >>> one and the same field should not be used to hold both the > >>> users opaque_ref as well as a structure which is itself not a user > >>> opaque_ref > >> > >> While the AVFrame is within libavcodec, it's libavcodec's frame, not > >> the user's. Thus your claim doesn't make too much sense. libavcodec > >> fully controls the meaning for its own AVFrames' opaque_ref, but > >> reconstruct the user's value when returning it. > > > > i disagree > > Well, you're wrong anyway. > > > such hacks should not be added, we do have enough hacks already > > It's not a hack. > >>> > >>> Changing the semantics of a field during its lifetime, even when only > >>> done within private code, is at least unexpected behavior. > >> > >> That's not done. > > > > The semantics are defined by the docs, which state: > > "AVBufferRef for free use by the API user." > > > > And before the patch this is true, all instances of this field are > > controled by the user application and are consistent. > > > > after the patch the AVFrames used by a codec have their opaque_ref > > replaced by a wraped structure relative to what the outside of this > > codec has. > > > > > >> Conceptually the AVFrame with the changed behavior is > >> a new reference. Internally, AVFrame.opaque_ref will always have the > >> same semantics, pointing to the FrameDecodeData struct. Only at points > >> where the AVFrame ref is converted to/from the user struct this is > >> changed. > >> > This is done strictly when returning a valid AVFrame, so there is no > room for mistakes. > >>> > >>> The room for mistake might not increase for external developers but it > >>> increases for internal developers (maintenance cost). > >> > >> Like where? There are only 2 places where the code needs to deal with > >> it, and these are in shared code, not individual decoders. > > > > just greping for AVFrame in the headers shows callbacks, a direct > > pointer to a AVFrame and the API functions that interface the codec > > > > Just thinking of a codec that instanciates another codec and how > > exactly the callback which may originate from the user or the outer > > codec would unwrap the potential nested wraping. > > I really dont think we want this in FFmpeg > > And this is just one example ... > > I don't understand this discussion. yes, i realize this, but iam not sure why its pretty simple and clear but you seem to skip over parts of what i said. > > As far as I can tell, the sequence is this: > > * libavcodec allocates an AVFrame structure. > * libavcodec calls get_buffer2 with that AVFrame structure; the user fills > its fields. > * libavcodec extracts the buffer references and metadata from the AVFrame, > and maybe frees it (some codecs reuse a single AVFrame for the lifetime of > the codec, others allocate them each time). > ~ decoding happens, the buffers are written to ~ > * The user allocates a new AVFrame structure. > * The user calls receive_frame with that new AVFrame structure; libavcodec > its fields with references to the decoded data and associated metadata. > * The user can then read the buffers of the frame, along with its metadata. > > Why would it matter what happens in the middle? The AVFrame structure at the > end is not the AVFrame structure at the start, and the user can't assume > anything about it at all - if they try to dereference a pointer to the > AVFrame supplied by libavcodec for get_buffer2 after get_buffer2 has returned > then they are definitely invoking undefined behaviour. First this does not consider nested codecs. A decoder can instanciate a internal decoder, if that now uses the user callback it would have to unwrap twice for it if it used a callback from the outer decoder it has to unwrap once. This of course also depends on how it instanciates the decoder, that is at which API level. Next, if you look at the API and search for AVFrame you will find that there are more callbacks than get_buffer2() that use AVFrames. there is for example al
Re: [FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
Dňa 5. 10. 2017 10:19 odpoludnia používateľ "Carl Eugen Hoyos" < ceffm...@gmail.com> napísal: 2017-10-05 16:26 GMT+02:00 Daniel Kucera : > Time to time some devices send UDP packets without payload. > ffmpeg previously exited on receiving such packet Just curious: Is it useful at all to exit on an empty packet? Carl Eugen No, It's a bug and it's so deep that it would require fixing many modules but I'm not able to do it and noone other cares. So I'm proposing this workaround. Daniel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Thu, Oct 5, 2017 at 10:21 PM, Carl Eugen Hoyos wrote: > 2017-10-05 16:32 GMT+02:00 Moritz Barsnick : > >> Issue: The hls demuxer now inconsistently no longer reports >> each opened URL, only the first one. (Reporting of these at >> default log-level was only recently added though.) > > Could you remind me why this was useful? > I was about to start a patch to stop printing those > debug lines... > Supposedly its a "security" feature. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
2017-10-06 0:19 GMT+02:00 Hendrik Leppkes : > On Thu, Oct 5, 2017 at 10:21 PM, Carl Eugen Hoyos wrote: >> 2017-10-05 16:32 GMT+02:00 Moritz Barsnick : >> >>> Issue: The hls demuxer now inconsistently no longer reports >>> each opened URL, only the first one. (Reporting of these at >>> default log-level was only recently added though.) >> >> Could you remind me why this was useful? >> I was about to start a patch to stop printing those >> debug lines... > > Supposedly its a "security" feature. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: support multichannel XMA stream configurations
Here are samples of many stream configurations, generated with Microsoft's
encoder:
https://mega.nz/#!aQRUnTIT!gWUAfGNLIP62VKV2JEOGoyQ1jbVc3M7_qu7ChXQwb7w
For real XMA used in games, I've only seen 2ch+..+2ch+1/2ch (usual, what
FFmpeg supported before) and 1ch+..+1ch (rare, what motivates this patch).
This adds support for all possible combinations though.
I don't know enough about FATE to set up tests so I hope somebody could
help, as the learning curve seems steep.
2017-10-03 23:49 GMT+02:00 :
> From: bnnm
>
> Signed-off-by: bnnm
>
> Now accepts any combination of 1/2ch streams, described in the RIFF
> chunks/extradata
> ---
> libavcodec/wmaprodec.c | 151 ++
> ++-
> libavformat/wavdec.c | 20 ---
> 2 files changed, 112 insertions(+), 59 deletions(-)
>
> diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
> index 5c99628c52..77a49c9db8 100644
> --- a/libavcodec/wmaprodec.c
> +++ b/libavcodec/wmaprodec.c
> @@ -106,6 +106,9 @@
> #define MAX_SUBFRAMES 32///< max
> number of subframes per channel
> #define MAX_BANDS 29///< max
> number of scale factor bands
> #define MAX_FRAMESIZE 32768 ///< maximum
> compressed frame size
> +#define XMA_MAX_STREAMS 8
> +#define XMA_MAX_CHANNELS8
> +#define XMA_MAX_CHANNELS_STREAM 2
>
> #define WMAPRO_BLOCK_MIN_BITS 6
> ///< log2 of min block size
> #define WMAPRO_BLOCK_MAX_BITS 13
> ///< log2 of max block size
> @@ -215,7 +218,7 @@ typedef struct WMAProDecodeCtx {
> uint8_t drc_gain; ///< gain for the DRC
> tool
> int8_t skip_frame;///< skip output step
> int8_t parsed_all_subframes; ///< all subframes
> decoded?
> -uint8_t skip_packets;
> +uint8_t skip_packets; ///< packets to skip
> to find next packet in a stream (XMA1/2)
>
> /* subframe/block decode state */
> int16_t subframe_len; ///< current subframe
> length
> @@ -235,11 +238,13 @@ typedef struct WMAProDecodeCtx {
> } WMAProDecodeCtx;
>
> typedef struct XMADecodeCtx {
> -WMAProDecodeCtx xma[4];
> -AVFrame *frames[4];
> +WMAProDecodeCtx xma[XMA_MAX_STREAMS];
> +AVFrame *frames[XMA_MAX_STREAMS];
> int current_stream;
> -float samples[8][512 * 64];
> -int offset[4];
> +int num_streams;
> +float samples[XMA_MAX_CHANNELS][512 * 64];
> +int offset[XMA_MAX_STREAMS];
> +int start_channel[XMA_MAX_STREAMS];
> } XMADecodeCtx;
>
> /**
> @@ -306,7 +311,7 @@ static av_cold int get_rate(AVCodecContext *avctx)
> *@param avctx codec context
> *@return 0 on success, -1 otherwise
> */
> -static av_cold int decode_init(WMAProDecodeCtx *s, AVCodecContext *avctx)
> +static av_cold int decode_init(WMAProDecodeCtx *s, AVCodecContext *avctx,
> int num_stream)
> {
> uint8_t *edata_ptr = avctx->extradata;
> unsigned int channel_mask;
> @@ -333,18 +338,30 @@ static av_cold int decode_init(WMAProDecodeCtx *s,
> AVCodecContext *avctx)
> for (i = 0; i < avctx->extradata_size; i++)
> av_log(avctx, AV_LOG_DEBUG, "[%x] ", avctx->extradata[i]);
> av_log(avctx, AV_LOG_DEBUG, "\n");
> -if (avctx->codec_id == AV_CODEC_ID_XMA2 && (!avctx->extradata ||
> avctx->extradata_size >= 6)) {
> +
> +if (avctx->codec_id == AV_CODEC_ID_XMA2 && avctx->extradata_size ==
> 34) { /* XMA2WAVEFORMATEX */
> +s->decode_flags= 0x10d6;
> +s->bits_per_sample = 16;
> +channel_mask = 0; //AV_RL32(edata_ptr+2); /* not always in
> expected order */
> +if ((num_stream+1) * XMA_MAX_CHANNELS_STREAM > avctx->channels)
> /* stream config is 2ch + 2ch + ... + 1/2ch */
> +s->nb_channels = 1;
> +else
> +s->nb_channels = 2;
> +} else if (avctx->codec_id == AV_CODEC_ID_XMA2) { /* XMA2WAVEFORMAT */
> s->decode_flags= 0x10d6;
> -channel_mask = avctx->extradata ? AV_RL32(edata_ptr+2) : 0;
> s->bits_per_sample = 16;
> - } else if (avctx->codec_id == AV_CODEC_ID_XMA1) {
> +channel_mask = 0; /* would need to aggregate from all
> streams */
> +s->nb_channels = edata_ptr[32 + ((edata_ptr[0]==3)?0:8) +
> 4*num_stream + 0]; /* nth stream config */
> +} else if (avctx->codec_id == AV_CODEC_ID_XMA1) { /* XMAWAVEFORMAT */
> s->decode_flags= 0x10d6;
> s->bits_per_sample = 16;
> -channel_mask = 0;
> - } else if (avctx->codec_id == AV_CODEC_ID_WMAPRO &&
> avctx->extradata_size >= 18) {
> +channel_mask = 0; /* would need to aggregate from all
> streams */
> +s->nb_channels = edata_ptr[8 + 20*num_stream + 17]; /* nth
> stream config */
> +} else if (avctx->codec_id == AV_CODEC_ID_WMAPRO &&
> avctx->extradata_size >= 18) {
> s-
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On 05/10/17 23:01, Michael Niedermayer wrote: > On Thu, Oct 05, 2017 at 09:03:40PM +0100, Mark Thompson wrote: >> On 05/10/17 17:47, Michael Niedermayer wrote: >>> On Wed, Oct 04, 2017 at 02:04:54PM +0200, wm4 wrote: On Wed, 4 Oct 2017 13:37:31 +0200 Tobias Rapp wrote: > On 04.10.2017 11:34, wm4 wrote: >> On Wed, 4 Oct 2017 11:22:37 +0200 >> Michael Niedermayer wrote: >> >>> On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: On Tue, 3 Oct 2017 21:40:58 +0200 Michael Niedermayer wrote: > On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: >> From: Anton Khirnov >> > >> Use the AVFrame.opaque_ref field. The original user's opaque_ref is >> wrapped in the lavc struct and then unwrapped before the frame is >> returned to the caller. > > this is a ugly hack > > one and the same field should not be used to hold both the > users opaque_ref as well as a structure which is itself not a user > opaque_ref While the AVFrame is within libavcodec, it's libavcodec's frame, not the user's. Thus your claim doesn't make too much sense. libavcodec fully controls the meaning for its own AVFrames' opaque_ref, but reconstruct the user's value when returning it. >>> >>> i disagree >> >> Well, you're wrong anyway. >> >>> such hacks should not be added, we do have enough hacks already >> >> It's not a hack. > > Changing the semantics of a field during its lifetime, even when only > done within private code, is at least unexpected behavior. That's not done. >>> >>> The semantics are defined by the docs, which state: >>> "AVBufferRef for free use by the API user." >>> >>> And before the patch this is true, all instances of this field are >>> controled by the user application and are consistent. >>> >>> after the patch the AVFrames used by a codec have their opaque_ref >>> replaced by a wraped structure relative to what the outside of this >>> codec has. >>> >>> Conceptually the AVFrame with the changed behavior is a new reference. Internally, AVFrame.opaque_ref will always have the same semantics, pointing to the FrameDecodeData struct. Only at points where the AVFrame ref is converted to/from the user struct this is changed. >> This is done strictly when returning a valid AVFrame, so there is no >> room for mistakes. > > The room for mistake might not increase for external developers but it > increases for internal developers (maintenance cost). Like where? There are only 2 places where the code needs to deal with it, and these are in shared code, not individual decoders. >>> >>> just greping for AVFrame in the headers shows callbacks, a direct >>> pointer to a AVFrame and the API functions that interface the codec >>> >>> Just thinking of a codec that instanciates another codec and how >>> exactly the callback which may originate from the user or the outer >>> codec would unwrap the potential nested wraping. >>> I really dont think we want this in FFmpeg >>> And this is just one example ... >> > >> I don't understand this discussion. > > yes, i realize this, but iam not sure why > > its pretty simple and clear but you seem to skip over parts of what > i said. > > >> >> As far as I can tell, the sequence is this: >> >> * libavcodec allocates an AVFrame structure. >> * libavcodec calls get_buffer2 with that AVFrame structure; the user fills >> its fields. >> * libavcodec extracts the buffer references and metadata from the AVFrame, >> and maybe frees it (some codecs reuse a single AVFrame for the lifetime of >> the codec, others allocate them each time). >> ~ decoding happens, the buffers are written to ~ >> * The user allocates a new AVFrame structure. >> * The user calls receive_frame with that new AVFrame structure; libavcodec >> its fields with references to the decoded data and associated metadata. >> * The user can then read the buffers of the frame, along with its metadata. >> >> Why would it matter what happens in the middle? The AVFrame structure at >> the end is not the AVFrame structure at the start, and the user can't assume >> anything about it at all - if they try to dereference a pointer to the >> AVFrame supplied by libavcodec for get_buffer2 after get_buffer2 has >> returned then they are definitely invoking undefined behaviour. > > First this does not consider nested codecs. > A decoder can instanciate a internal decoder, if that now uses the > user callback it would have to unwrap twice for it if it used a > callback from the outer decoder it has to unwrap once. > This of course also depends on how it instanciates the decoder, that > is at which API level. All decoders pass back to their callers the opaque reference they r
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4'
On Wed, Oct 04, 2017 at 02:20:07AM +, James Almer wrote: > ffmpeg | branch: master | James Almer | Tue Oct 3 > 23:08:06 2017 -0300| [1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9] | committer: > James Almer > > Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4' > > * commit '79331df362fb05a0d04ca9489c87e5b80077a3f4': > rtsp: Lazily set up the pollfd array once > > Merged-by: James Almer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9 > --- > > libavformat/rtsp.c | 53 ++--- > libavformat/rtsp.h | 1 + > 2 files changed, 27 insertions(+), 27 deletions(-) This breaks rtsp example: ./ffmpeg -itsoffset 2 -re -i matrixbench_mpeg2.mpg -acodec libspeex -ar 16K -ac 1 -vn -t 3 -f rtp rtp://127.0.0.1:19745 > speex.sdp flags & AVIO_FLAG_READ)) [Current thread is 1 (Thread 0x77f93800 (LWP 13134))] (gdb) bt Python Exception No module named gdb.frames: #0 0x00649110 in ffurl_read_complete (h=0x0, buf=0x7fff9f17 "", size=1) at libavformat/avio.c:414 #1 0x0077243a in ff_rtsp_read_reply (s=0x2171640, reply=0x7fffbd50, content_ptr=0x0, return_on_interleaved_data=0, method=0x0) at libavformat/rtsp.c:1165 #2 0x0077511d in udp_read_packet (s=0x2171640, prtsp_st=0x7fffd8d0, buf=0x21a2600 "\200\341\002:\354\347^\301\220\362x\357\066\235m\232 \001\r\376\265\270\251`\340\260\350", , buf_size=81920, wait_end=0) at libavformat/rtsp.c:1999 #3 0x0077547d in read_packet (s=0x2171640, rtsp_st=0x7fffd8d0, first_queue_st=0x0, wait_end=0) at libavformat/rtsp.c:2075 #4 0x007758ba in ff_rtsp_fetch_packet (s=0x2171640, pkt=0x7fffda90) at libavformat/rtsp.c:2161 #5 0x007ab592 in ff_read_packet (s=0x2171640, pkt=0x7fffda90) at libavformat/utils.c:816 #6 0x007ae65c in read_frame_internal (s=0x2171640, pkt=0x7fffde90) at libavformat/utils.c:1518 #7 0x007af674 in av_read_frame (s=0x2171640, pkt=0x7fffde90) at libavformat/utils.c:1722 #8 0x0043a7a1 in get_input_packet (f=0x2179140, pkt=0x7fffde90) at fftools/ffmpeg.c:4097 #9 0x0043abfd in process_input (file_index=0) at fftools/ffmpeg.c:4217 #10 0x0043c9ba in transcode_step () at fftools/ffmpeg.c:4553 #11 0x0043cb05 in transcode () at fftools/ffmpeg.c:4607 #12 0x0043d2e4 in main (argc=9, argv=0x7fffe3a8) at fftools/ffmpeg.c:4813 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/7] Removing some debugging
2017-10-05 21:44 GMT+02:00 Carl Eugen Hoyos : > I tested the following with the sample from ticket #503: > $ ffmpeg -i rgba64le-lzw.tif -vf palettegen pal.png > $ ffmpeg -i rgba64le-lzw.tif -i pal.png -lavfi paletteuse out.gif > > The output file has its background (that is supposed to be > transparent) converted to white (which I believe is good) > but the respective colour white (that is the 256th and last > colour in the palette) is not transparent but opaque (0xff). > Instead the first colour (0x00ff00) is the only transparent > colour in the palette. The output gif is opaque. > > I confirmed that if I force the first palette entry to opaque > (0xFF00FF00) and the last one to transparent (0xFF) > in apply_palette() I get the expected transparent output with > above command line. Forgot to mention: I can reproduce this exact behaviour writing a png image: $ ffmpeg -i rgba64le-lzw.tif -i pal.png -lavfi paletteuse out.png Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Thu, Oct 05, 2017 at 22:21:09 +0200, Carl Eugen Hoyos wrote: > Could you remind me why this was useful? It never was to me. (Except at loglevel debug and above.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On 05/10/17 23:59, Mark Thompson wrote: > On 05/10/17 23:01, Michael Niedermayer wrote: >> On Thu, Oct 05, 2017 at 09:03:40PM +0100, Mark Thompson wrote: >>> On 05/10/17 17:47, Michael Niedermayer wrote: On Wed, Oct 04, 2017 at 02:04:54PM +0200, wm4 wrote: > On Wed, 4 Oct 2017 13:37:31 +0200 > Tobias Rapp wrote: > >> On 04.10.2017 11:34, wm4 wrote: >>> On Wed, 4 Oct 2017 11:22:37 +0200 >>> Michael Niedermayer wrote: >>> On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: > On Tue, 3 Oct 2017 21:40:58 +0200 > Michael Niedermayer wrote: > >> On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: >>> From: Anton Khirnov >>> >> >>> Use the AVFrame.opaque_ref field. The original user's opaque_ref is >>> wrapped in the lavc struct and then unwrapped before the frame is >>> returned to the caller. >> >> this is a ugly hack >> >> one and the same field should not be used to hold both the >> users opaque_ref as well as a structure which is itself not a user >> opaque_ref > > While the AVFrame is within libavcodec, it's libavcodec's frame, not > the user's. Thus your claim doesn't make too much sense. libavcodec > fully controls the meaning for its own AVFrames' opaque_ref, but > reconstruct the user's value when returning it. i disagree >>> >>> Well, you're wrong anyway. >>> such hacks should not be added, we do have enough hacks already >>> >>> It's not a hack. >> >> Changing the semantics of a field during its lifetime, even when only >> done within private code, is at least unexpected behavior. > > That's not done. The semantics are defined by the docs, which state: "AVBufferRef for free use by the API user." And before the patch this is true, all instances of this field are controled by the user application and are consistent. after the patch the AVFrames used by a codec have their opaque_ref replaced by a wraped structure relative to what the outside of this codec has. > Conceptually the AVFrame with the changed behavior is > a new reference. Internally, AVFrame.opaque_ref will always have the > same semantics, pointing to the FrameDecodeData struct. Only at points > where the AVFrame ref is converted to/from the user struct this is > changed. > >>> This is done strictly when returning a valid AVFrame, so there is no >>> room for mistakes. >> >> The room for mistake might not increase for external developers but it >> increases for internal developers (maintenance cost). > > Like where? There are only 2 places where the code needs to deal with > it, and these are in shared code, not individual decoders. just greping for AVFrame in the headers shows callbacks, a direct pointer to a AVFrame and the API functions that interface the codec Just thinking of a codec that instanciates another codec and how exactly the callback which may originate from the user or the outer codec would unwrap the potential nested wraping. I really dont think we want this in FFmpeg And this is just one example ... >>> >> >>> I don't understand this discussion. >> >> yes, i realize this, but iam not sure why >> >> its pretty simple and clear but you seem to skip over parts of what >> i said. >> >> >>> >>> As far as I can tell, the sequence is this: >>> >>> * libavcodec allocates an AVFrame structure. >>> * libavcodec calls get_buffer2 with that AVFrame structure; the user fills >>> its fields. >>> * libavcodec extracts the buffer references and metadata from the AVFrame, >>> and maybe frees it (some codecs reuse a single AVFrame for the lifetime of >>> the codec, others allocate them each time). >>> ~ decoding happens, the buffers are written to ~ >>> * The user allocates a new AVFrame structure. >>> * The user calls receive_frame with that new AVFrame structure; libavcodec >>> its fields with references to the decoded data and associated metadata. >>> * The user can then read the buffers of the frame, along with its metadata. >>> >>> Why would it matter what happens in the middle? The AVFrame structure at >>> the end is not the AVFrame structure at the start, and the user can't >>> assume anything about it at all - if they try to dereference a pointer to >>> the AVFrame supplied by libavcodec for get_buffer2 after get_buffer2 has >>> returned then they are definitely invoking undefined behaviour. >> >> First this does not consider nested codecs. >> A decoder can instanciate a internal decoder, if that now uses the >> user callback it would have to unwrap twice for it if it used a >> callback from the outer decoder it has to unwrap once. >> This of co
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Fri, 6 Oct 2017 00:01:30 +0200 Michael Niedermayer wrote: > The opaque_ref wraping is a really bad design. Iam not sure why > people defend it. FFmpeg is full of this design. There are plenty of structs with opaque/priv fields that change meaning depending on the context (basically how the struct is used or what uses it). It affects all decoders, encoders, filters, demuxers, muxers, the av_log() call, functions that work with AVClass, AVOption, and probably more. Are you saying that FFmpeg is really bad design? That's funny. There is nothing unclean about this use of opaque_ref, just that it somewhat collides with awful legacy hacks like draw_horiz_band (but which could be fixed anyway). Also what you said about nested decoders is simply incorrect. The nested decoder is used only by the decoder implementation itself, and always uses the default get_buffer callback for the nested codec, so the returned AVFrame.opaque_ref is returned as NULL. Now it's possible that the new code will assert if the parent codec has AV_CODEC_CAP_DR1 set. This is because if AV_CODEC_CAP_DR1 is set, the AVFrame is expected to be allocated by the codec context's ff_get_buffer() (which would guarantee opaque_ref is set correctly). It looks like avrndec.c does not do this correctly if is_mjpeg is set. But in fact, this codec violates the API by declaring DR1 support, but not calling the user get_buffer2 callback. This could be fixed. An actually valid point is brought up by Mark Thompson (and not by you), but this can be fixed easily by wrapping the AVFrame properly before returning. (Assuming the desired semantics are that the opaque_ref is returned to the user as-is.) So, still no problem found. What is the problem? Now I'm very curious to hear what your "cleaner" solution to this problem is. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hls: add http_keepalive option
On Fri, 6 Oct 2017 00:19:33 +0200 Hendrik Leppkes wrote: > On Thu, Oct 5, 2017 at 10:21 PM, Carl Eugen Hoyos wrote: > > 2017-10-05 16:32 GMT+02:00 Moritz Barsnick : > > > >> Issue: The hls demuxer now inconsistently no longer reports > >> each opened URL, only the first one. (Reporting of these at > >> default log-level was only recently added though.) > > > > Could you remind me why this was useful? > > I was about to start a patch to stop printing those > > debug lines... > > > > Supposedly its a "security" feature. wat ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
> ffmpeg | branch: master | Ashish Singh | Sat Sep 16
> 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] | committer:
> Ronald S. Bultje
>
> avfilter: add vmafmotion filter
>
> Signed-off-by: Ashish Singh
> Signed-off-by: Ronald S. Bultje
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=148c8e88c43cfbabd6aee9f01ef30942cee9d359
> ---
>
> Changelog | 1 +
> doc/filters.texi| 14 ++
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/vf_vmafmotion.c | 365
>
> libavfilter/vmaf_motion.h | 58 +++
> 6 files changed, 440 insertions(+)
[...]
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +VMAFMotionContext *s = ctx->priv;
> +
> +if (s->stats_file_str) {
> +if (!strcmp(s->stats_file_str, "-")) {
> +s->stats_file = stdout;
Using stdout can interfere with the user application using the filter
> +} else {
> +s->stats_file = fopen(s->stats_file_str, "w");
Opening a filter parameter provided string for writing is a dangerous
way to output data. It allows one with access to the parameters to
overwrite any writable file
data should only be output in a safe way
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat/http: fix stray quote in trace logging
On Wed, Oct 04, 2017 at 03:03:33PM -0700, Aman Gupta wrote: > From: Aman Gupta > > --- > libavformat/http.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/http.c b/libavformat/http.c > index 6af3259a43..f76a71fbb7 100644 > --- a/libavformat/http.c > +++ b/libavformat/http.c > @@ -1298,7 +1298,7 @@ static int http_buf_read(URLContext *h, uint8_t *buf, > int size) > s->chunksize = strtoull(line, NULL, 16); > > av_log(h, AV_LOG_TRACE, > - "Chunked encoding data size: %"PRIu64"'\n", > + "Chunked encoding data size: %"PRIu64"\n", > s->chunksize); should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4'
On 10/5/2017 8:10 PM, Michael Niedermayer wrote: > On Wed, Oct 04, 2017 at 02:20:07AM +, James Almer wrote: >> ffmpeg | branch: master | James Almer | Tue Oct 3 >> 23:08:06 2017 -0300| [1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9] | committer: >> James Almer >> >> Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4' >> >> * commit '79331df362fb05a0d04ca9489c87e5b80077a3f4': >> rtsp: Lazily set up the pollfd array once >> >> Merged-by: James Almer >> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9 >> --- >> >> libavformat/rtsp.c | 53 >> ++--- >> libavformat/rtsp.h | 1 + >> 2 files changed, 27 insertions(+), 27 deletions(-) > > This breaks rtsp > > example: > ./ffmpeg -itsoffset 2 -re -i matrixbench_mpeg2.mpg -acodec libspeex -ar 16K > -ac 1 -vn -t 3 -f rtp rtp://127.0.0.1:19745 > speex.sdp ; ./ffmpeg -protocol_whitelist file,rtp,udp -i speex.sdp -y -t 0.9 out.wav > > segfaults but i think this is not specific to this one case Libav commit ca960161f087ca38267b88ce90592010c59584f1 seems to fix it for me. If you can confirm that I'll cherry-pick it asap. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/h264:Only check x264_build if it was set
On Thu, Oct 05, 2017 at 08:31:39AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #6717. > > Please comment, Carl Eugen > h264_cabac.c |2 +- > h264_mb.c|2 +- > h264_slice.c |2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > 9e712a4dbc032aa844d8693e699f105d99e4b3d5 > 0001-lavc-h264-Only-check-x264_build-if-it-was-set.patch > From 3315fa024958246685b2431c2605e867f651ad5b Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Thu, 5 Oct 2017 08:29:27 +0200 > Subject: [PATCH] lavc/h264: Only check x264_build if it was set. > > Fixes ticket #6718. 6717 or 6718 ? also the default x264_build is -1, that should already be larger than the unsigned thresholds but maybe iam missing something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Cleanup unused functions
On Thu, Oct 05, 2017 at 08:34:00AM +, Manojkumar Bhosale wrote: > LGTM applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
Signed-off-by: Sasi Inguva
---
libavfilter/avfilter.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 58917ed445..ec7dfc0bd3 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
return 0;
}
-static int64_t guess_status_pts(AVFilterContext *ctx, int status)
+static int64_t guess_status_pts_from_src(AVFilterLink *link, int status)
{
unsigned i;
int64_t r = INT64_MAX;
-for (i = 0; i < ctx->nb_inputs; i++)
-if (ctx->inputs[i]->status_out == status)
-r = FFMIN(r, ctx->inputs[i]->current_pts);
+for (i = 0; i < link->src->nb_inputs; i++)
+if (link->src->inputs[i]->status_out == status)
+ r = FFMIN(r, av_rescale_q(link->src->inputs[i]->current_pts,
link->src->inputs[i]->time_base, link->time_base));
if (r < INT64_MAX)
return r;
-av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
-for (i = 0; i < ctx->nb_inputs; i++)
-r = FFMIN(r, ctx->inputs[i]->status_in_pts);
+av_log(link->src, AV_LOG_WARNING, "EOF timestamp not reliable\n");
+for (i = 0; i < link->src->nb_inputs; i++)
+ r = FFMIN(r, av_rescale_q(link->src->inputs[i]->status_in_pts,
link->src->inputs[i]->time_base, link->time_base));
if (r < INT64_MAX)
return r;
return AV_NOPTS_VALUE;
@@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink *link)
ret = ff_request_frame(link->src->inputs[0]);
if (ret < 0) {
if (ret != AVERROR(EAGAIN) && ret != link->status_in)
-ff_avfilter_link_set_in_status(link, ret,
guess_status_pts(link->src, ret));
+ff_avfilter_link_set_in_status(link, ret,
guess_status_pts_from_src(link, ret));
if (ret == AVERROR_EOF)
ret = 0;
}
--
2.14.2.920.gcf0c67979c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4'
On Thu, Oct 05, 2017 at 09:15:13PM -0300, James Almer wrote: > On 10/5/2017 8:10 PM, Michael Niedermayer wrote: > > On Wed, Oct 04, 2017 at 02:20:07AM +, James Almer wrote: > >> ffmpeg | branch: master | James Almer | Tue Oct 3 > >> 23:08:06 2017 -0300| [1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9] | > >> committer: James Almer > >> > >> Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4' > >> > >> * commit '79331df362fb05a0d04ca9489c87e5b80077a3f4': > >> rtsp: Lazily set up the pollfd array once > >> > >> Merged-by: James Almer > >> > >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9 > >> --- > >> > >> libavformat/rtsp.c | 53 > >> ++--- > >> libavformat/rtsp.h | 1 + > >> 2 files changed, 27 insertions(+), 27 deletions(-) > > > > This breaks rtsp > > > > example: > > ./ffmpeg -itsoffset 2 -re -i matrixbench_mpeg2.mpg -acodec libspeex -ar 16K > > -ac 1 -vn -t 3 -f rtp rtp://127.0.0.1:19745 > speex.sdp > 1 ; ./ffmpeg -protocol_whitelist file,rtp,udp -i speex.sdp -y -t 0.9 out.wav > > > > segfaults but i think this is not specific to this one case > > Libav commit ca960161f087ca38267b88ce90592010c59584f1 seems to fix it > for me. If you can confirm that I'll cherry-pick it asap. confirmed thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] ffmpeg: send EOF pts to filters.
I've encountered the same problem, and tracked it to guess_status_pts
function which tries to take the end timestamp from the input links
however without converting it to correct time base. Sent a patch, PTAL.
On Tue, Oct 3, 2017 at 5:36 PM, Thomas Mundt wrote:
> Hi Nicolas,
>
> 2017-09-07 10:59 GMT+02:00 Nicolas George :
>
> > Signed-off-by: Nicolas George
> > ---
> > ffmpeg.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/ffmpeg.c b/ffmpeg.c
> > index b95addd277..1d248bc269 100644
> > --- a/ffmpeg.c
> > +++ b/ffmpeg.c
> > @@ -2223,14 +2223,14 @@ static int ifilter_send_frame(InputFilter
> > *ifilter, AVFrame *frame)
> > return 0;
> > }
> >
> > -static int ifilter_send_eof(InputFilter *ifilter)
> > +static int ifilter_send_eof(InputFilter *ifilter, int64_t pts)
> > {
> > int i, j, ret;
> >
> > ifilter->eof = 1;
> >
> > if (ifilter->filter) {
> > -ret = av_buffersrc_add_frame_flags(ifilter->filter, NULL,
> > AV_BUFFERSRC_FLAG_PUSH);
> > +ret = av_buffersrc_close(ifilter->filter, pts,
> > AV_BUFFERSRC_FLAG_PUSH);
> > if (ret < 0)
> > return ret;
> > } else {
> > @@ -2581,8 +2581,12 @@ out:
> > static int send_filter_eof(InputStream *ist)
> > {
> > int i, ret;
> > +/* TODO keep pts also in stream time base to avoid converting back
> */
> > +int64_t pts = av_rescale_q_rnd(ist->pts, AV_TIME_BASE_Q,
> > ist->st->time_base,
> > + AV_ROUND_NEAR_INF |
> > AV_ROUND_PASS_MINMAX);
> > +
> > for (i = 0; i < ist->nb_filters; i++) {
> > -ret = ifilter_send_eof(ist->filters[i]);
> > +ret = ifilter_send_eof(ist->filters[i], pts);
> > if (ret < 0)
> > return ret;
> > }
> >
>
> The sended pts always seems to refer to the input time base.
> When a filter changes the time base, the EOF pts becomes wrong for
> subsequent filters in the chain.
> E.g. when using vf_fps behind vf_yadif=1 with interlaced input, the sended
> EOF pts is only half of the expected pts.
>
> I tried to find a solution, but without success.
> Do you have an idea?
>
> Regards,
> Thomas
>
>
> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virenfrei.
> www.avg.com
> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4'
On 10/5/2017 11:59 PM, Michael Niedermayer wrote: > On Thu, Oct 05, 2017 at 09:15:13PM -0300, James Almer wrote: >> On 10/5/2017 8:10 PM, Michael Niedermayer wrote: >>> On Wed, Oct 04, 2017 at 02:20:07AM +, James Almer wrote: ffmpeg | branch: master | James Almer | Tue Oct 3 23:08:06 2017 -0300| [1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9] | committer: James Almer Merge commit '79331df362fb05a0d04ca9489c87e5b80077a3f4' * commit '79331df362fb05a0d04ca9489c87e5b80077a3f4': rtsp: Lazily set up the pollfd array once Merged-by: James Almer > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1e7b6e47d2752a91bcd6d0c91ed2aaf118eaeee9 --- libavformat/rtsp.c | 53 ++--- libavformat/rtsp.h | 1 + 2 files changed, 27 insertions(+), 27 deletions(-) >>> >>> This breaks rtsp >>> >>> example: >>> ./ffmpeg -itsoffset 2 -re -i matrixbench_mpeg2.mpg -acodec libspeex -ar 16K >>> -ac 1 -vn -t 3 -f rtp rtp://127.0.0.1:19745 > speex.sdp >> 1 ; ./ffmpeg -protocol_whitelist file,rtp,udp -i speex.sdp -y -t 0.9 out.wav >>> >>> segfaults but i think this is not specific to this one case >> >> Libav commit ca960161f087ca38267b88ce90592010c59584f1 seems to fix it >> for me. If you can confirm that I'll cherry-pick it asap. > > confirmed > > thx Cherry picked and pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/srt: add Haivision SRT protocol
> SRT is a subtitle format: a more specific name would be better. Haivision suggested name "opensrt" - is it acceptable to distinguish with SRT subtitile format? if yes, I'll go ahead and submit new patch with name changed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
