Re: [FFmpeg-devel] [PATCH] mpegvideo_enc: disable optimized huffman coding with AMV or slice threads
On 04.04.2017 11:58, Rostislav Pehlivanov wrote:
Doesn't work yet with slice threading and won't work with AMV.
---
libavcodec/mpegvideo_enc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 71a858fc72..db241c82f0 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -399,6 +399,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
return AVERROR(EINVAL);
}
+if (avctx->codec_id == AV_CODEC_ID_AMV || (avctx->active_thread_type &
FF_THREAD_SLICE))
+s->huffman = 0;
+
if (s->intra_dc_precision > (avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO ? 3
: 0)) {
av_log(avctx, AV_LOG_ERROR, "intra dc precision too large\n");
return AVERROR(EINVAL);
In case this gets applied I think it should also be backported to 3.3.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '5f102a9559099429826e84758b8b5182244c52db'
On Wed, Apr 05, 2017 at 12:31:24AM -0300, James Almer wrote: > On 4/4/2017 11:12 PM, Michael Niedermayer wrote: > > On Tue, Apr 04, 2017 at 11:44:21AM +0200, Clément Bœsch wrote: > >> ffmpeg | branch: master | Clément Bœsch | Tue Apr 4 > >> 11:44:45 2017 +0200| [4ea942f2ceaafbfed43933895bd0e8aad043ca44] | > >> committer: Clément Bœsch > >> > >> Merge commit '5f102a9559099429826e84758b8b5182244c52db' > >> > >> * commit '5f102a9559099429826e84758b8b5182244c52db': > >> examples/encode_video: switch to the new encoding API > >> > >> Merged-by: Clément Bœsch > >> > >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4ea942f2ceaafbfed43933895bd0e8aad043ca44 > >> --- > >> > >> doc/examples/encode_video.c | 59 > >> - > >> 1 file changed, 31 insertions(+), 28 deletions(-) > > > > This changes the output for encode_video > > > > Is this intended? > > > > ./doc/examples/encode_video ev.avi mpeg4 > > Write frame 0 (size= 6467) > > Write frame 2 (size= 3281) > > Write frame 1 (size= 1874) > > Write frame 4 (size= 3579) > > Write frame 3 (size= 2069) > > Write frame 6 (size= 4389) > > Write frame 5 (size= 2204) > > Write frame 8 (size= 3538) > > Write frame 7 (size= 2348) > > Write frame 10 (size=13024) > > Write frame 9 (size= 2303) > > Write frame 12 (size= 4718) > > Write frame 11 (size= 2504) > > Write frame 14 (size= 5082) > > Write frame 13 (size= 1898) > > Write frame 16 (size= 4186) > > Write frame 15 (size= 1842) > > Write frame 18 (size= 4676) > > Write frame 17 (size= 1782) > > Write frame 20 (size=12942) > > Write frame 19 (size= 2237) > > Write frame 22 (size= 5180) > > Write frame 21 (size= 2312) > > Write frame 24 (size= 4520) > > Write frame 23 (size= 2523) > > > > Before: > > ./doc/examples/encode_video ev.avi mpeg4 > > Write frame 1 (size= 6467) > > Write frame 2 (size= 3281) > > Write frame 3 (size= 1874) > > Write frame 4 (size= 3579) > > Write frame 5 (size= 2069) > > Write frame 6 (size= 4389) > > Write frame 7 (size= 2204) > > Write frame 8 (size= 3538) > > Write frame 9 (size= 2348) > > Write frame 10 (size=13024) > > Write frame 11 (size= 2303) > > Write frame 12 (size= 4718) > > Write frame 13 (size= 2504) > > Write frame 14 (size= 5082) > > Write frame 15 (size= 1898) > > Write frame 16 (size= 4186) > > Write frame 17 (size= 1842) > > Write frame 18 (size= 4676) > > Write frame 19 (size= 1782) > > Write frame 20 (size=12942) > > Write frame 21 (size= 2237) > > Write frame 22 (size= 5180) > > Write frame 23 (size= 2312) > > Write frame 24 (size= 4520) > > Write frame 25 (size= 2523) > > > > The written files seem to match > > Before this change, the printed "frame number" was a loop counter, and after > this changes it's the packet's pts. > If i make the old version also print the packet's pts i get the exact same > output as the new version, so i guess you could say it's "intended". ok then though changing the output should have been in a seperate commit. "switch to the new encoding API" is not really the right place Changes which inherently dont change the output like changing API shouldnt artifically change it to keep them easily testable [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter
>>>Thomas Mundt schrieb am Do, 30.3.2017: >>>Lou Logan schrieb am Do, 30.3.2017: >> On Mon, 13 Mar 2017 16:23:46 + (UTC) >> Thomas Mundt wrote: >> >> [...] >>> index 09ca4d3..0b5b858 100644 >>> --- a/libavfilter/vf_tinterlace.c >>> +++ b/libavfilter/vf_tinterlace.c >> [...] >>> +static void lowpass_line_complex_c(uint8_t *dstp, ptrdiff_t width, const >>> uint8_t *srcp, >>> + ptrdiff_t mref, ptrdiff_t pref) >> >> Trailing whitespace should be avoided. It prevents the patch from being >> applied. > > Oh, didn´t notice. Thanks. > New patch set attached. Ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '5f102a9559099429826e84758b8b5182244c52db'
On Wed, 5 Apr 2017 10:54:38 +0200 Michael Niedermayer wrote: > On Wed, Apr 05, 2017 at 12:31:24AM -0300, James Almer wrote: > > On 4/4/2017 11:12 PM, Michael Niedermayer wrote: > > > On Tue, Apr 04, 2017 at 11:44:21AM +0200, Clément Bœsch wrote: > > >> ffmpeg | branch: master | Clément Bœsch | Tue Apr 4 > > >> 11:44:45 2017 +0200| [4ea942f2ceaafbfed43933895bd0e8aad043ca44] | > > >> committer: Clément Bœsch > > >> > > >> Merge commit '5f102a9559099429826e84758b8b5182244c52db' > > >> > > >> * commit '5f102a9559099429826e84758b8b5182244c52db': > > >> examples/encode_video: switch to the new encoding API > > >> > > >> Merged-by: Clément Bœsch > > >> > > >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4ea942f2ceaafbfed43933895bd0e8aad043ca44 > > >>> > > >> --- > > >> > > >> doc/examples/encode_video.c | 59 > > >> - > > >> 1 file changed, 31 insertions(+), 28 deletions(-) > > > > > > This changes the output for encode_video > > > > > > Is this intended? > > > > > > ./doc/examples/encode_video ev.avi mpeg4 > > > Write frame 0 (size= 6467) > > > Write frame 2 (size= 3281) > > > Write frame 1 (size= 1874) > > > Write frame 4 (size= 3579) > > > Write frame 3 (size= 2069) > > > Write frame 6 (size= 4389) > > > Write frame 5 (size= 2204) > > > Write frame 8 (size= 3538) > > > Write frame 7 (size= 2348) > > > Write frame 10 (size=13024) > > > Write frame 9 (size= 2303) > > > Write frame 12 (size= 4718) > > > Write frame 11 (size= 2504) > > > Write frame 14 (size= 5082) > > > Write frame 13 (size= 1898) > > > Write frame 16 (size= 4186) > > > Write frame 15 (size= 1842) > > > Write frame 18 (size= 4676) > > > Write frame 17 (size= 1782) > > > Write frame 20 (size=12942) > > > Write frame 19 (size= 2237) > > > Write frame 22 (size= 5180) > > > Write frame 21 (size= 2312) > > > Write frame 24 (size= 4520) > > > Write frame 23 (size= 2523) > > > > > > Before: > > > ./doc/examples/encode_video ev.avi mpeg4 > > > Write frame 1 (size= 6467) > > > Write frame 2 (size= 3281) > > > Write frame 3 (size= 1874) > > > Write frame 4 (size= 3579) > > > Write frame 5 (size= 2069) > > > Write frame 6 (size= 4389) > > > Write frame 7 (size= 2204) > > > Write frame 8 (size= 3538) > > > Write frame 9 (size= 2348) > > > Write frame 10 (size=13024) > > > Write frame 11 (size= 2303) > > > Write frame 12 (size= 4718) > > > Write frame 13 (size= 2504) > > > Write frame 14 (size= 5082) > > > Write frame 15 (size= 1898) > > > Write frame 16 (size= 4186) > > > Write frame 17 (size= 1842) > > > Write frame 18 (size= 4676) > > > Write frame 19 (size= 1782) > > > Write frame 20 (size=12942) > > > Write frame 21 (size= 2237) > > > Write frame 22 (size= 5180) > > > Write frame 23 (size= 2312) > > > Write frame 24 (size= 4520) > > > Write frame 25 (size= 2523) > > > > > > The written files seem to match > > > > Before this change, the printed "frame number" was a loop counter, and after > > this changes it's the packet's pts. > > If i make the old version also print the packet's pts i get the exact same > > output as the new version, so i guess you could say it's "intended". > > ok then though changing the output should have been in a seperate > commit. "switch to the new encoding API" is not really the right place > > Changes which inherently dont change the output like changing API > shouldnt artifically change it to keep them easily testable > > [...] Yeah, it's totally like you didn't do major changes in merge commits back when you merged. (And that affected central code, not just unimportant stuff like examples.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] x86/simple_idct: add explicit sse2 simple_idct_put/add versions.
Hi, On Tue, Apr 4, 2017 at 9:54 PM, Michael Niedermayer wrote: > if the idct depends on external asm then it would need to be under > HAVE_EXTERNAL_*, you are correct. Also that is ugly It's temporary, I think James/Kieran were talking about converting the IDCT to yasm and then having an SSE2 version (for 8bit), which would be quite nice. Right now we have a SSE2 for 10/12 bit on 64bit only and the inline asm on 32+64bit for 8bit. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/h264: change some labels to be macro-local
Hi, On Tue, Apr 4, 2017 at 9:53 PM, James Darnley wrote: > The labels get stripped leading to (slightly) nicer disassembly from > objdump. > [..] > -jz .cycle%1end > +jz %%skip Can you preserve the leading dot? I don't mind the %%skip, but please make it .%%skip. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Build fix for MIPS
Hi, Updated the patch as per comments. As hevcpred_init_mips.c needs definition of HAVE_MSA and av_cold, now I have included config.h & libavutil/attributes.h in this file. Thanks, Shivraj From: Ronald S. Bultje [mailto:rsbul...@gmail.com] Sent: 04 April 2017 17:47 To: Shivraj Patil Cc: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] Build fix for MIPS On Tue, Apr 4, 2017 at 8:05 AM, Shivraj Patil mailto:shivraj.pa...@imgtec.com>> wrote: Hi, > diff --git a/libavcodec/hevcpred.h b/libavcodec/hevcpred.h > [..] > @@ -26,6 +26,8 @@ > #include > #include > > +#include "get_bits.h" > + hevcpred does not depend on get_bits.h and does not use any symbols (get_bits* or GetBit*) from it. What compiler error does this fix? diff --git a/libavcodec/mips/hevcpred_msa.c b/libavcodec/mips/hevcpred_msa.c [..] -#include "libavcodec/hevc.h" +#include "libavcodec/hevcdec.h" This looks correct. Ronald 0001-build-fix-for-mips.patch Description: 0001-build-fix-for-mips.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect
---
Changelog | 1 +
doc/filters.texi | 7 ++
libavfilter/vf_framestep.c| 242 ++
tests/fate/filter-video.mak | 5 +
tests/ref/fate/filter-framestep-1 | 17 +++
tests/ref/fate/filter-framestep-2 | 17 +++
tests/ref/fate/filter-framestep-3 | 17 +++
7 files changed, 286 insertions(+), 20 deletions(-)
create mode 100644 tests/ref/fate/filter-framestep-1
create mode 100644 tests/ref/fate/filter-framestep-2
create mode 100644 tests/ref/fate/filter-framestep-3
diff --git a/Changelog b/Changelog
index e76b324..880f10a 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- framestep filter: add blend parameter for motion blur effect
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/doc/filters.texi b/doc/filters.texi
index bc37e66..3ccb727 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8246,6 +8246,13 @@ This filter accepts the following option:
@item step
Select frame after every @code{step} frames.
Allowed values are positive integers higher than 0. Default value is @code{1}.
+@item blend
+Blend @code{blend} consequentive frames on every step,
+to produce a motion blur effect.
+Allowed values are positive integers between @code{1} and @code{step},
+where @code{1} corresponds to no motion blur, and @code{step}
+corresponds to maximal motion blur.
+Default value is @code{1}.
@end table
@anchor{frei0r}
diff --git a/libavfilter/vf_framestep.c b/libavfilter/vf_framestep.c
index 8102e7c..d68ed2d 100644
--- a/libavfilter/vf_framestep.c
+++ b/libavfilter/vf_framestep.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Stefano Sabatini
+ * Copyright (c) 2017 Matthias C. M. Troffaes
*
* This file is part of FFmpeg.
*
@@ -24,13 +25,25 @@
*/
#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
#include "avfilter.h"
#include "internal.h"
#include "video.h"
typedef struct NullContext {
const AVClass *class;
-int frame_step;
+int frame_step; ///< step size in frames
+int frame_blend;///< how many frames to blend on each step
+int nb_planes; ///< number of planes in the pixel format
+int planewidth[4]; ///< width of each plane (after subsampling)
+int planeheight[4]; ///< height of each plane (after subsampling)
+int linesize[4];///< linesize of buffer in bytes
+uint32_t *data[4]; ///< buffer for blending input frames
+
+void (*blend_set)(AVFilterContext *ctx, AVFrame *in, int plane);
+void (*blend_add)(AVFilterContext *ctx, AVFrame *in, int plane);
+void (*blend_div)(AVFilterContext *ctx, AVFrame *in, int plane);
+int (*filter_frame)(AVFilterLink *inlink, AVFrame *in);
} FrameStepContext;
#define OFFSET(x) offsetof(FrameStepContext, x)
@@ -38,43 +51,229 @@ typedef struct NullContext {
static const AVOption framestep_options[] = {
{ "step", "set frame step", OFFSET(frame_step), AV_OPT_TYPE_INT,
{.i64=1}, 1, INT_MAX, FLAGS},
+{ "blend", "number of frames to blend per step", OFFSET(frame_blend),
AV_OPT_TYPE_INT, {.i64=1}, 1, 65535, FLAGS},
{ NULL },
};
AVFILTER_DEFINE_CLASS(framestep);
+#define DEFINE_BLEND(NAME, TYPE, DECL, EXPR)
\
+static void blend_##NAME##_##TYPE(AVFilterContext *ctx, AVFrame *in, int
plane)\
+{
\
+FrameStepContext *s = ctx->priv;
\
+DECL
\
+const int height = s->planeheight[plane];
\
+const int width = s->planewidth[plane];
\
+const int stride = in->linesize[plane] / sizeof(TYPE);
\
+TYPE *src = (TYPE *)in->data[plane];
\
+uint32_t *dst = s->data[plane];
\
+int y, x;
\
+
\
+for (y = 0; y < height; y++) {
\
+for (x = 0; x < width; x++) {
\
+EXPR;
\
+}
\
+src += stride;
\
+}
\
+}
+
+#define SET_DECL
+#define SET_EXPR *dst++ = src[x]
+#define ADD_DECL
+#define ADD_EXPR *dst++ += src[x]
+#define DIV_DECL const int frame_blend = s->frame_blend;
+#define DIV_
[FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect
Attached a patch which adds a "blend" parameter to the framestep filter, to blend frames together at each step, for a motion blur effect. The number of frames that are blended (i.e. the exposure time, in frames) can be controlled, allowing control over the strength of the motion blur. The filter has timeline support, and supports both 8-bit and 16-bit pixel formats. Tests and documentation included. Note that a similar effect is already possible by repeatedly chaining the tblend and framestep=step=2 filters; see for example: https://video.stackexchange.com/questions/16552/4x-resample-videoframes-using-ffmpeg But this is limited to steps that are powers of two, and this does not allow an intermediate exposure time. It's also slower. The main use I've had for the attached patch myself is to blend down rendered high framerate footage to get a high quality motion blur effect. Matthias C. M. Troffaes (1): vf_framestep: add blend parameter for motion blur effect Changelog | 1 + doc/filters.texi | 7 ++ libavfilter/vf_framestep.c| 242 ++ tests/fate/filter-video.mak | 5 + tests/ref/fate/filter-framestep-1 | 17 +++ tests/ref/fate/filter-framestep-2 | 17 +++ tests/ref/fate/filter-framestep-3 | 17 +++ 7 files changed, 286 insertions(+), 20 deletions(-) create mode 100644 tests/ref/fate/filter-framestep-1 create mode 100644 tests/ref/fate/filter-framestep-2 create mode 100644 tests/ref/fate/filter-framestep-3 -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: add hls encrypt options
add hls encrypt options looks like libav's libavformat/hlsenc.c
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 118 ---
1 file changed, 113 insertions(+), 5 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e6c378df2e..4583d75a98 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -26,10 +26,18 @@
#include
#endif
+#if CONFIG_GCRYPT
+#include
+#elif CONFIG_OPENSSL
+#include
+#endif
+
#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/parseutils.h"
#include "libavutil/avstring.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/random_seed.h"
#include "libavutil/opt.h"
#include "libavutil/log.h"
#include "libavutil/time_internal.h"
@@ -139,6 +147,12 @@ typedef struct HLSContext {
char *subtitle_filename;
AVDictionary *format_options;
+int encrypt;
+char *key;
+char *key_url;
+char *iv;
+char *key_basename;
+
char *key_info_file;
char key_file[LINE_BUFFER_SIZE + 1];
char key_uri[LINE_BUFFER_SIZE + 1];
@@ -349,6 +363,89 @@ fail:
return ret;
}
+static int randomize(uint8_t *buf, int len)
+{
+#if CONFIG_GCRYPT
+gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
+return 0;
+#elif CONFIG_OPENSSL
+if (RAND_bytes(buf, len))
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+return AVERROR(EINVAL);
+}
+
+static int do_encrypt(AVFormatContext *s)
+{
+HLSContext *hls = s->priv_data;
+int ret;
+int len;
+AVIOContext *pb;
+uint8_t key[KEYSIZE];
+
+len = strlen(hls->basename) + 4 + 1;
+hls->key_basename = av_mallocz(len);
+if (!hls->key_basename)
+return AVERROR(ENOMEM);
+
+av_strlcpy(hls->key_basename, s->filename, len);
+av_strlcat(hls->key_basename, ".key", len);
+
+if (hls->key_url) {
+strncpy(hls->key_file, hls->key_url, sizeof(hls->key_file));
+strncpy(hls->key_uri, hls->key_url, sizeof(hls->key_uri));
+} else {
+strncpy(hls->key_file, hls->key_basename, sizeof(hls->key_file));
+strncpy(hls->key_uri, hls->key_basename, sizeof(hls->key_uri));
+}
+
+if (!*hls->iv_string) {
+uint8_t iv[16] = { 0 };
+char buf[33];
+
+if (!hls->iv) {
+AV_WB64(iv + 8, hls->sequence);
+} else {
+memcpy(iv, hls->iv, sizeof(iv));
+}
+ff_data_to_hex(buf, iv, sizeof(iv), 0);
+buf[32] = '\0';
+memcpy(hls->iv_string, buf, sizeof(hls->iv_string));
+}
+
+if (!*hls->key_uri) {
+av_log(hls, AV_LOG_ERROR, "no key URI specified in key info file\n");
+return AVERROR(EINVAL);
+}
+
+if (!*hls->key_file) {
+av_log(hls, AV_LOG_ERROR, "no key file specified in key info file\n");
+return AVERROR(EINVAL);
+}
+
+if(!*hls->key_string) {
+if (!hls->key) {
+if ((ret = randomize(key, sizeof(key))) < 0) {
+av_log(s, AV_LOG_ERROR, "Cannot generate a strong random
key\n");
+return ret;
+}
+} else {
+memcpy(key, hls->key, sizeof(key));
+}
+
+ff_data_to_hex(hls->key_string, key, sizeof(key), 0);
+if ((ret = s->io_open(s, &pb, hls->key_file, AVIO_FLAG_WRITE, NULL)) <
0)
+return ret;
+avio_seek(pb, 0, SEEK_CUR);
+avio_write(pb, key, KEYSIZE);
+avio_close(pb);
+}
+return 0;
+}
+
+
static int hls_encryption_start(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
@@ -662,7 +759,7 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
hls->discontinuity = 0;
}
-if (hls->key_info_file) {
+if (hls->key_info_file || hls->encrypt) {
av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
av_strlcpy(en->iv_string, hls->iv_string, sizeof(en->iv_string));
}
@@ -865,7 +962,7 @@ static int hls_window(AVFormatContext *s, int last)
hls->discontinuity_set = 1;
}
for (en = hls->segments; en; en = en->next) {
-if (hls->key_info_file && (!key_uri || strcmp(en->key_uri, key_uri) ||
+if ((hls->encrypt || hls->key_info_file) && (!key_uri ||
strcmp(en->key_uri, key_uri) ||
av_strcasecmp(en->iv_string, iv_string))) {
avio_printf(out, "#EXT-X-KEY:METHOD=AES-128,URI=\"%s\"",
en->key_uri);
if (*en->iv_string)
@@ -1031,9 +1128,14 @@ static int hls_start(AVFormatContext *s)
av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
}
-if (c->key_info_file) {
-if ((err = hls_encryption_start(s)) < 0)
-goto fail;
+if (c->key_info_file || c->encrypt) {
+if (c->key_info_file) {
+if ((err = hls_encryption_start(s)) < 0)
+goto fail;
+} else {
+if ((err = do_encrypt(s)) < 0)
+goto fail;
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
2017-04-03 20:32 GMT+08:00 Nicolas George : > Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : > > change name from av_strreplace to av_strireplace > > Use AVBprint to implement av_strireplace > > add av_strireplace test case TEST_STRIREPLACE > > > > Signed-off-by: Steven Liu > > --- > > libavutil/avstring.c | 76 +++--- > > > libavutil/avstring.h | 2 +- > > libavutil/tests/avstring.c | 16 ++ > > 3 files changed, 28 insertions(+), 66 deletions(-) > > This version looks fine to me. > > Maybe wait a little more for advice about the rename and the whole > thing. > > Thanks. > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On 4/5/2017 11:05 AM, Steven Liu wrote: > 2017-04-03 20:32 GMT+08:00 Nicolas George : > >> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>> change name from av_strreplace to av_strireplace >>> Use AVBprint to implement av_strireplace >>> add av_strireplace test case TEST_STRIREPLACE >>> >>> Signed-off-by: Steven Liu >>> --- >>> libavutil/avstring.c | 76 +++--- >> >>> libavutil/avstring.h | 2 +- >>> libavutil/tests/avstring.c | 16 ++ >>> 3 files changed, 28 insertions(+), 66 deletions(-) >> >> This version looks fine to me. >> >> Maybe wait a little more for advice about the rename and the whole >> thing. >> >> Thanks. >> >> -- >> Nicolas George >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > ping You can't rename the function. It's already in the 3.3 branch. This is one of the reasons why giving people enough time for reviews is a must before pushing new public symbols. The rest should be ok since Nicolas reviewed it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 1/2] codec: bitpacked: add decoder
On 4 April 2017 at 18:33, Damien Riegel wrote: > Hi, > > On Fri, Mar 31, 2017 at 07:23:28PM +0100, Rostislav Pehlivanov wrote: > > On 31 March 2017 at 18:11, Kieran Kunhya wrote: > > > > > On Fri, 31 Mar 2017 at 17:57 Rostislav Pehlivanov > > > > wrote: > > > > > > > On 31 March 2017 at 16:36, Damien Riegel < > > > > damien.rie...@savoirfairelinux.com > > > > > wrote: > > > > > > > > > Add a codec capable of decoding some formats of the RFC4175. For > now > > > > > it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit > depth. > > > > > > > > > > For 8-bit it's a simple pass-through, for 10-bit it depacks the > stream > > > > > in the AV_PIX_FMT_YUV422P10 pixel format. > > > > > > > > > > Signed-off-by: Damien Riegel > > > > > --- > > > > > Changes in v4: > > > > > - use uint64_t for comparison between frame_size and packet_size > > > > > - add a check to make sure width is even > > > > > - take into account linesize to compute buffer addresses > > > > > - use AVERROR_INVALIDDATA instead of custom error codes > > > > > > > > > > Changes in v3: > > > > > - Codec has been renamed bitpacked (instead of vrawdepay) > > > > > - A decoding function is now chosen at codec init based on the > pixel > > > > >format > > > > > - Codec marked as experimental > > > > > > > > > > > > > > Don't mark it as experimental. The experimental flag is only used for > > > > encoders to avoid picking ones which may generate invalid bitstreams > > > > instead of reference implementation external libraries > > > > > > > > > > I asked for it to be marked as experimental, it's not even a real > codec, it > > > doesn't handle any of the timestamp difficulties for example during > > > wraparound. > > > > > > Afaik this patch allows for stuff like raw bitpacked, bitpacked in > > > container X etc. > > > > > > Kieran > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > Didn't know it didn't do that, I guess it's okay then. When its fixed it > > can be unmarked. We still have some experimental features in the psd > > decoder too. > > Indeed I added the flag following Kieran's suggestion. Is there anything > else I could do to improve this patchset? > > Thanks, > -- > Damien > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Pushed, thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/2] rtp: rfc4175: add handler for YCbCr-4:2:2
On 31 March 2017 at 16:36, Damien Riegel wrote:
> This adds partial support for the RFC 4175 (raw video over RTP). The
> only supported formats are the YCbCr-4:2:2 8 bit because it's natively
> supported by FFmpeg with pixel format UYVY, and 10 bit which requires
> the vrawdepay codec to convert the payload in a format handled by
> FFmpeg.
>
> Signed-off-by: Damien Riegel
> ---
> Changes in v4:
> - use strncmp for string comparisons
> - use AVERROR_INVALIDDATA instead of custom error codes
>
> Changes in v3:
> - rename rawvideo to rfc4175
> - set pixel format in codec parameters
> - add additional check to prevent buffer overflow
>
> libavformat/Makefile | 1 +
> libavformat/rtpdec.c | 1 +
> libavformat/rtpdec_formats.h | 1 +
> libavformat/rtpdec_rfc4175.c | 236 ++
> +
> 4 files changed, 239 insertions(+)
> create mode 100644 libavformat/rtpdec_rfc4175.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index f56ef16532..a1dae894fe 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -55,6 +55,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o
>\
> rtpdec_qcelp.o \
> rtpdec_qdm2.o \
> rtpdec_qt.o \
> +rtpdec_rfc4175.o\
> rtpdec_svq3.o \
> rtpdec_vc2hq.o \
> rtpdec_vp8.o\
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index 53cdad7396..4acb1ca629 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -114,6 +114,7 @@ void ff_register_rtp_dynamic_payload_handlers(void)
> ff_register_dynamic_payload_handler(&ff_qt_rtp_vid_handler);
> ff_register_dynamic_payload_handler(&ff_quicktime_rtp_aud_handler);
> ff_register_dynamic_payload_handler(&ff_quicktime_rtp_vid_handler);
> +ff_register_dynamic_payload_handler(&ff_rfc4175_rtp_handler);
> ff_register_dynamic_payload_handler(&ff_svq3_dynamic_handler);
> ff_register_dynamic_payload_handler(&ff_theora_dynamic_handler);
> ff_register_dynamic_payload_handler(&ff_vc2hq_dynamic_handler);
> diff --git a/libavformat/rtpdec_formats.h b/libavformat/rtpdec_formats.h
> index 3292a3d265..a436c9d62c 100644
> --- a/libavformat/rtpdec_formats.h
> +++ b/libavformat/rtpdec_formats.h
> @@ -82,6 +82,7 @@ extern RTPDynamicProtocolHandler ff_qt_rtp_aud_handler;
> extern RTPDynamicProtocolHandler ff_qt_rtp_vid_handler;
> extern RTPDynamicProtocolHandler ff_quicktime_rtp_aud_handler;
> extern RTPDynamicProtocolHandler ff_quicktime_rtp_vid_handler;
> +extern RTPDynamicProtocolHandler ff_rfc4175_rtp_handler;
> extern RTPDynamicProtocolHandler ff_svq3_dynamic_handler;
> extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;
> extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler;
> diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> new file mode 100644
> index 00..498381dfd3
> --- /dev/null
> +++ b/libavformat/rtpdec_rfc4175.c
> @@ -0,0 +1,236 @@
> +/*
> + * RTP Depacketization of RAW video (TR-03)
> + * Copyright (c) 2016 Savoir-faire Linux, Inc
> + *
> + * 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
> + */
> +
> +/* Development sponsored by CBC/Radio-Canada */
> +
> +#include "avio_internal.h"
> +#include "rtpdec_formats.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/pixdesc.h"
> +
> +struct PayloadContext {
> +char *sampling;
> +int depth;
> +int width;
> +int height;
> +
> +uint8_t *frame;
> +unsigned int frame_size;
> +unsigned int pgroup; /* size of the pixel group in bytes */
> +unsigned int xinc;
> +
> +uint32_t timestamp;
> +};
> +
> +static int rfc4175_parse_format(AVStream *stream, PayloadContext *data)
> +{
> +enum AVPixelFormat pixfmt = AV_PIX_FMT_NONE;
> +int bits_per_sample = 0;
> +int tag = 0;
> +
> +if (!strncmp(data->sampling, "YCbCr-4
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On Wed, 5 Apr 2017, James Almer wrote: On 4/5/2017 11:05 AM, Steven Liu wrote: 2017-04-03 20:32 GMT+08:00 Nicolas George : Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : change name from av_strreplace to av_strireplace Use AVBprint to implement av_strireplace add av_strireplace test case TEST_STRIREPLACE Signed-off-by: Steven Liu --- libavutil/avstring.c | 76 +++--- libavutil/avstring.h | 2 +- libavutil/tests/avstring.c | 16 ++ 3 files changed, 28 insertions(+), 66 deletions(-) This version looks fine to me. Maybe wait a little more for advice about the rename and the whole thing. Thanks. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ping You can't rename the function. It's already in the 3.3 branch. This is one of the reasons why giving people enough time for reviews is a must before pushing new public symbols. Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there any practical reason for not renaming it before the release? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegvideo_enc: disable optimized huffman coding with AMV or slice threads
On Tue, Apr 04, 2017 at 10:58:37AM +0100, Rostislav Pehlivanov wrote: > Doesn't work yet with slice threading and won't work with AMV. > --- > libavcodec/mpegvideo_enc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c > index 71a858fc72..db241c82f0 100644 > --- a/libavcodec/mpegvideo_enc.c > +++ b/libavcodec/mpegvideo_enc.c > @@ -399,6 +399,9 @@ FF_ENABLE_DEPRECATION_WARNINGS > return AVERROR(EINVAL); > } > > +if (avctx->codec_id == AV_CODEC_ID_AMV || (avctx->active_thread_type & > FF_THREAD_SLICE)) > +s->huffman = 0; this should be under out_format == FMT_MJPEG or something like that Currently all codecs which support huffman tables optims have an issue with threads but that really is a limitation of the mjpeg implemantation [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > You can't rename the function. It's already in the 3.3 branch. AFAICS, it is only a branch yet, so I see no reason not to push this, provided it is backported to the branch and done before the actual release. Thus, I think this discussion should be considered blocking for the release. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: do not upsample during second-pass linear normalization
On Tue, Apr 4, 2017 at 7:14 AM, Kyle Swanson wrote:
> Hi,
>
>
> On Sun, Apr 2, 2017 at 6:32 PM, Kyle Swanson wrote:
>
>> Signed-off-by: Kyle Swanson
>> ---
>> libavfilter/af_loudnorm.c | 58 +++---
>> -
>> 1 file changed, 34 insertions(+), 24 deletions(-)
>>
>> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
>> index 9d91c76..e3e815e 100644
>> --- a/libavfilter/af_loudnorm.c
>> +++ b/libavfilter/af_loudnorm.c
>> @@ -682,6 +682,7 @@ static int request_frame(AVFilterLink *outlink)
>>
>> static int query_formats(AVFilterContext *ctx)
>> {
>> +LoudNormContext *s = ctx->priv;
>> AVFilterFormats *formats;
>> AVFilterChannelLayouts *layouts;
>> AVFilterLink *inlink = ctx->inputs[0];
>> @@ -707,15 +708,17 @@ static int query_formats(AVFilterContext *ctx)
>> if (ret < 0)
>> return ret;
>>
>> -formats = ff_make_format_list(input_srate);
>> -if (!formats)
>> -return AVERROR(ENOMEM);
>> -ret = ff_formats_ref(formats, &inlink->out_samplerates);
>> -if (ret < 0)
>> -return ret;
>> -ret = ff_formats_ref(formats, &outlink->in_samplerates);
>> -if (ret < 0)
>> -return ret;
>> +if (s->frame_type != LINEAR_MODE) {
>> +formats = ff_make_format_list(input_srate);
>> +if (!formats)
>> +return AVERROR(ENOMEM);
>> +ret = ff_formats_ref(formats, &inlink->out_samplerates);
>> +if (ret < 0)
>> +return ret;
>> +ret = ff_formats_ref(formats, &outlink->in_samplerates);
>> +if (ret < 0)
>> +return ret;
>> +}
>>
>> return 0;
>> }
>> @@ -754,21 +757,6 @@ static int config_input(AVFilterLink *inlink)
>>
>> init_gaussian_filter(s);
>>
>> -s->frame_type = FIRST_FRAME;
>> -
>> -if (s->linear) {
>> -double offset, offset_tp;
>> -offset= s->target_i - s->measured_i;
>> -offset_tp = s->measured_tp + offset;
>> -
>> -if (s->measured_tp != 99 && s->measured_thresh != -70 &&
>> s->measured_lra != 0 && s->measured_i != 0) {
>> -if ((offset_tp <= s->target_tp) && (s->measured_lra <=
>> s->target_lra)) {
>> -s->frame_type = LINEAR_MODE;
>> -s->offset = offset;
>> -}
>> -}
>> -}
>> -
>> if (s->frame_type != LINEAR_MODE) {
>> inlink->min_samples =
>> inlink->max_samples =
>> @@ -790,6 +778,27 @@ static int config_input(AVFilterLink *inlink)
>> return 0;
>> }
>>
>> +static av_cold int init(AVFilterContext *ctx)
>> +{
>> +LoudNormContext *s = ctx->priv;
>> +s->frame_type = FIRST_FRAME;
>> +
>> +if (s->linear) {
>> +double offset, offset_tp;
>> +offset= s->target_i - s->measured_i;
>> +offset_tp = s->measured_tp + offset;
>> +
>> +if (s->measured_tp != 99 && s->measured_thresh != -70 &&
>> s->measured_lra != 0 && s->measured_i != 0) {
>> +if ((offset_tp <= s->target_tp) && (s->measured_lra <=
>> s->target_lra)) {
>> +s->frame_type = LINEAR_MODE;
>> +s->offset = offset;
>> +}
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> static av_cold void uninit(AVFilterContext *ctx)
>> {
>> LoudNormContext *s = ctx->priv;
>> @@ -914,6 +923,7 @@ AVFilter ff_af_loudnorm = {
>> .priv_size = sizeof(LoudNormContext),
>> .priv_class= &loudnorm_class,
>> .query_formats = query_formats,
>> +.init = init,
>> .uninit= uninit,
>> .inputs= avfilter_af_loudnorm_inputs,
>> .outputs = avfilter_af_loudnorm_outputs,
>> --
>> 2.10.1
>>
>>
> If no one has anything for this, I'll push it in the next day or so.
>
> Kyle
>
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.3
Le quartidi 24 ventôse, an CCXXV, Michael Niedermayer a écrit : > are there any issues/tickets that block making 3.3 ? There is the issue of av_strreplace() / av_strireplace() that needs to be decided and then possibly backported. Regardss, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On 4/5/2017 1:49 PM, Marton Balint wrote: > > > On Wed, 5 Apr 2017, James Almer wrote: > >> On 4/5/2017 11:05 AM, Steven Liu wrote: >>> 2017-04-03 20:32 GMT+08:00 Nicolas George : >>> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : > change name from av_strreplace to av_strireplace > Use AVBprint to implement av_strireplace > add av_strireplace test case TEST_STRIREPLACE > > Signed-off-by: Steven Liu > --- > libavutil/avstring.c | 76 +++--- > libavutil/avstring.h | 2 +- > libavutil/tests/avstring.c | 16 ++ > 3 files changed, 28 insertions(+), 66 deletions(-) This version looks fine to me. Maybe wait a little more for advice about the rename and the whole thing. Thanks. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> ping >> >> You can't rename the function. It's already in the 3.3 branch. >> This is one of the reasons why giving people enough time for reviews >> is a must before pushing new public symbols. > > Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there > any practical reason for not renaming it before the release? > > Thanks, > Marton Library versions and feature sets in diverging branches. When you branch you do a feature freeze. Making a mess with this for a single function that should have not been applied in such short notice shouldn't be acceptable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > Library versions and feature sets in diverging branches. When you > branch you do a feature freeze. I do not agree with that. The delay between branching and tagging the release has exactly the purpose of fixing the big mistakes that were including. The feature freeze happens at the tagging, not the branching. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] flvdec: option for dropping negative CTS frames Initial frames with negative pts can produce video/audio desynchronization when a decoder is not prepared to handle negative pts.
From: Felipe Astroza
Signed-off-by: Felipe Astroza
---
libavformat/flvdec.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 3959a36..1556fe0 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -44,6 +44,7 @@
typedef struct FLVContext {
const AVClass *class; ///< Class for private options.
int trust_metadata; ///< configure streams according onMetaData
+int drop_negative_cts;///< drop frames if cts is negative
int wrong_dts;///< wrong dts due to negative cts
uint8_t *new_extradata[FLV_STREAM_TYPE_NB];
int new_extradata_size[FLV_STREAM_TYPE_NB];
@@ -1139,10 +1140,16 @@ retry_duration:
int32_t cts = (avio_rb24(s->pb) + 0xff80) ^ 0xff80;
pts = dts + cts;
if (cts < 0) { // dts might be wrong
-if (!flv->wrong_dts)
+if (flv->drop_negative_cts) {
av_log(s, AV_LOG_WARNING,
-"Negative cts, previous timestamps might be wrong.\n");
-flv->wrong_dts = 1;
+"Negative cts, frames will be dropped.\n");
+dts = pts = AV_NOPTS_VALUE;
+} else {
+if (!flv->wrong_dts)
+av_log(s, AV_LOG_WARNING,
+"Negative cts, previous timestamps might be
wrong.\n");
+flv->wrong_dts = 1;
+}
} else if (FFABS(dts - pts) > 1000*60*15) {
av_log(s, AV_LOG_WARNING,
"invalid timestamps %"PRId64" %"PRId64"\n", dts, pts);
@@ -1253,6 +1260,7 @@ static int flv_read_seek(AVFormatContext *s, int
stream_index,
#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = {
{ "flv_metadata", "Allocate streams according to the onMetaData array",
OFFSET(trust_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
+{ "flv_drop_negative_cts", "Drop frames with negative composition
timestamp", OFFSET(drop_negative_cts), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD
},
{ "missing_streams", "", OFFSET(missing_streams), AV_OPT_TYPE_INT, { .i64
= 0 }, 0, 0xFF, VD | AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY },
{ NULL }
};
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.3
On 4/5/2017 2:18 PM, Nicolas George wrote: > Le quartidi 24 ventôse, an CCXXV, Michael Niedermayer a écrit : >> are there any issues/tickets that block making 3.3 ? > > There is the issue of av_strreplace() / av_strireplace() that needs to > be decided and then possibly backported. > > Regardss, Apparently, av_strreplace didn't even get a version bump or an APIChanges line. This whole situation has been was overall pretty sloppy. I don't know what would be best. Master and release/3.3 have diverged, including separate version bumps. Renaming and backporting might be technically harmless, but still ugly. I'd leave the decision to Michael since he's the release manager. But really, there should be more than half a day for reviewers to comment before new public symbols are pushed and especially in an incomplete way... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On Wed, 5 Apr 2017, James Almer wrote: On 4/5/2017 1:49 PM, Marton Balint wrote: On Wed, 5 Apr 2017, James Almer wrote: On 4/5/2017 11:05 AM, Steven Liu wrote: 2017-04-03 20:32 GMT+08:00 Nicolas George : Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : change name from av_strreplace to av_strireplace Use AVBprint to implement av_strireplace add av_strireplace test case TEST_STRIREPLACE Signed-off-by: Steven Liu --- libavutil/avstring.c | 76 +++--- libavutil/avstring.h | 2 +- libavutil/tests/avstring.c | 16 ++ 3 files changed, 28 insertions(+), 66 deletions(-) This version looks fine to me. Maybe wait a little more for advice about the rename and the whole thing. Thanks. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ping You can't rename the function. It's already in the 3.3 branch. This is one of the reasons why giving people enough time for reviews is a must before pushing new public symbols. Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there any practical reason for not renaming it before the release? Thanks, Marton Library versions and feature sets in diverging branches. When you branch you do a feature freeze. Making a mess with this for a single function that should have not been applied in such short notice shouldn't be acceptable. I don't think it would cause any problems for the users in practice. But we can also remove the function alltogether from the release, so anybody who want's to use the function (with the new name) will only have to check for a single version number. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] cavs: add a sse2 idct implementation.
On Tue, Apr 04, 2017 at 12:48:16PM -0400, Ronald S. Bultje wrote: > This makes using the function pointer ff_add_pixels_clamped() unnecessary, > since we always know what the best implementation is at compile-time. > --- > libavcodec/x86/cavsdsp.c| 15 +- > libavcodec/x86/cavsidct.asm | 48 > - > 2 files changed, 61 insertions(+), 2 deletions(-) fails on mingw64 [cavs @ 00052ae0] XMM REGS CLOBBERED IN avcodec_send_packet! [cavs @ 00052ae0] xmm8 = [cavs @ 00052ae0] -> fdfffefffefffcfffafff8ff make: *** [fate-cavs] Error 3 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv 4] avutil/avstring: improve av_strreplace implement
Use AVBprint to implement av_strreplace
add av_strreplace test case TEST_STRREPLACE
Signed-off-by: Steven Liu
---
libavutil/avstring.c | 74 +++---
libavutil/tests/avstring.c | 16 ++
2 files changed, 26 insertions(+), 64 deletions(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 52e6e6cd13..6dee687e91 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -233,78 +233,24 @@ int av_strncasecmp(const char *a, const char *b, size_t n)
char *av_strreplace(const char *str, const char *from, const char *to)
{
-/* Adjust each of the below values to suit your needs. */
-/* Increment positions cache size initially by this number. */
-size_t cache_sz_inc = 16;
-/* Thereafter, each time capacity needs to be increased,
- * multiply the increment by this factor. */
-const size_t cache_sz_inc_factor = 3;
-/* But never increment capacity by more than this number. */
-const size_t cache_sz_inc_max = 1048576;
-
-char *pret, *ret = NULL;
+char *ret = NULL;
const char *pstr2, *pstr = str;
-size_t i, count = 0;
-uintptr_t *pos_cache_tmp, *pos_cache = NULL;
-size_t cache_sz = 0;
-size_t cpylen, orglen, retlen, tolen, fromlen = strlen(from);
+size_t tolen = strlen(to), fromlen = strlen(from);
+AVBPrint pbuf;
-/* Find all matches and cache their positions. */
+av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED);
while ((pstr2 = av_stristr(pstr, from))) {
-count++;
-/* Increase the cache size when necessary. */
-if (cache_sz < count) {
-cache_sz += cache_sz_inc;
-pos_cache_tmp = av_realloc(pos_cache, sizeof(*pos_cache) *
cache_sz);
-if (!pos_cache_tmp) {
-goto end_strreplace;
-} else pos_cache = pos_cache_tmp;
-cache_sz_inc *= cache_sz_inc_factor;
-if (cache_sz_inc > cache_sz_inc_max) {
-cache_sz_inc = cache_sz_inc_max;
-}
-}
-
-pos_cache[count-1] = pstr2 - str;
+av_bprint_append_data(&pbuf, pstr, pstr2 - pstr);
pstr = pstr2 + fromlen;
+av_bprint_append_data(&pbuf, to, tolen);
}
-orglen = pstr - str + strlen(pstr);
-/* Allocate memory for the post-replacement string. */
-if (count > 0) {
-tolen = strlen(to);
-retlen = orglen + (tolen - fromlen) * count;
-} else {
-retlen = orglen;
-}
-ret = av_malloc(retlen + 1);
-if (!ret) {
-goto end_strreplace;
-}
-
-if (!count) {
-/* If no matches, then just duplicate the string. */
-av_strlcpy(ret, str, retlen + 1);
+av_bprint_append_data(&pbuf, pstr, strlen(pstr));
+if (!av_bprint_is_complete(&pbuf)) {
+av_bprint_finalize(&pbuf, NULL);
} else {
-/* Otherwise, duplicate the string whilst performing
- * the replacements using the position cache. */
-pret = ret;
-memcpy(pret, str, pos_cache[0]);
-pret += pos_cache[0];
-for (i = 0; i < count; i++) {
-memcpy(pret, to, tolen);
-pret += tolen;
-pstr = str + pos_cache[i] + fromlen;
-cpylen = (i == count-1 ? orglen : pos_cache[i+1]) - pos_cache[i] -
fromlen;
-memcpy(pret, pstr, cpylen);
-pret += cpylen;
-}
-ret[retlen] = '\0';
+av_bprint_finalize(&pbuf, &ret);
}
-end_strreplace:
-/* Free the cache and return the post-replacement string,
- * which will be NULL in the event of an error. */
-av_free(pos_cache);
return ret;
}
diff --git a/libavutil/tests/avstring.c b/libavutil/tests/avstring.c
index 14bc7ffcea..8660b348a8 100644
--- a/libavutil/tests/avstring.c
+++ b/libavutil/tests/avstring.c
@@ -93,6 +93,22 @@ int main(void)
TEST_STRNSTR(haystack, needle [2], strlen(haystack), NULL );
TEST_STRNSTR(haystack, strings[1], strlen(haystack), haystack );
+/*Testing av_strreplace()*/
+#define TEST_STRREPLACE(haystack, needle, expected) \
+ptr = av_strreplace(haystack, needle, "instead"); \
+if (ptr == NULL) { \
+printf("error, received null pointer!\n"); \
+} else { \
+if (strcmp(ptr, expected) != 0) \
+printf( "expected: %s, received: %s\n", expected, ptr); \
+av_free(ptr); \
+}
+
+TEST_STRREPLACE(haystack, needle [0], "Education consists mainly in what
we have uninstead");
+TEST_STRREPLACE(haystack, needle [1], "Education consists mainly in what
we have instead");
+TEST_STRREPLACE(haystack, needle [2], "Education consists mainly in what
we have instead.");
+TEST_STRREPLACE(haystack, needle [1], "Education consists mainly in what
we have instead");
+
/*Testing av_d2str()*/
#define TEST_D2STR(value, expected) \
if((ptr = av_d2str(value)) == NULL){ \
--
2.11.0 (Apple Git-81)
Re: [FFmpeg-devel] FFmpeg 3.3
Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > Apparently, av_strreplace didn't even get a version bump or an > APIChanges line. This whole situation has been was overall pretty > sloppy. I do not see the point of throwing even more blame around; what is done is done. > I don't know what would be best. Master and release/3.3 have diverged, > including separate version bumps. Renaming and backporting might be > technically harmless, Until http://ffmpeg.org/download.html points to ffmpeg-3.3.tar.bz2, there can be no harm. > but still ugly. Staying until the end of time with an ill-named function is ugly too. (Did you not in the past advocate consistency above a lot of things?) Releasing with an ill-named function and going the deprecation dance is ugly too. Between three uglies, I say we choose the one that will be forgotten a week from now. > I'd leave the decision to Michael since he's the release manager. But > really, there should be more than half a day for reviewers to comment > before new public symbols are pushed and especially in an incomplete > way... The reproach has already been made to Steven, IMHO there is no need to pile even more of it. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv 4] avutil/avstring: improve av_strreplace implement
2017-04-06 1:39 GMT+08:00 Steven Liu :
> Use AVBprint to implement av_strreplace
> add av_strreplace test case TEST_STRREPLACE
>
> Signed-off-by: Steven Liu
> ---
> libavutil/avstring.c | 74 +++---
>
> libavutil/tests/avstring.c | 16 ++
> 2 files changed, 26 insertions(+), 64 deletions(-)
>
> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> index 52e6e6cd13..6dee687e91 100644
> --- a/libavutil/avstring.c
> +++ b/libavutil/avstring.c
> @@ -233,78 +233,24 @@ int av_strncasecmp(const char *a, const char *b,
> size_t n)
>
> char *av_strreplace(const char *str, const char *from, const char *to)
> {
> -/* Adjust each of the below values to suit your needs. */
> -/* Increment positions cache size initially by this number. */
> -size_t cache_sz_inc = 16;
> -/* Thereafter, each time capacity needs to be increased,
> - * multiply the increment by this factor. */
> -const size_t cache_sz_inc_factor = 3;
> -/* But never increment capacity by more than this number. */
> -const size_t cache_sz_inc_max = 1048576;
> -
> -char *pret, *ret = NULL;
> +char *ret = NULL;
> const char *pstr2, *pstr = str;
> -size_t i, count = 0;
> -uintptr_t *pos_cache_tmp, *pos_cache = NULL;
> -size_t cache_sz = 0;
> -size_t cpylen, orglen, retlen, tolen, fromlen = strlen(from);
> +size_t tolen = strlen(to), fromlen = strlen(from);
> +AVBPrint pbuf;
>
> -/* Find all matches and cache their positions. */
> +av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED);
> while ((pstr2 = av_stristr(pstr, from))) {
> -count++;
> -/* Increase the cache size when necessary. */
> -if (cache_sz < count) {
> -cache_sz += cache_sz_inc;
> -pos_cache_tmp = av_realloc(pos_cache, sizeof(*pos_cache) *
> cache_sz);
> -if (!pos_cache_tmp) {
> -goto end_strreplace;
> -} else pos_cache = pos_cache_tmp;
> -cache_sz_inc *= cache_sz_inc_factor;
> -if (cache_sz_inc > cache_sz_inc_max) {
> -cache_sz_inc = cache_sz_inc_max;
> -}
> -}
> -
> -pos_cache[count-1] = pstr2 - str;
> +av_bprint_append_data(&pbuf, pstr, pstr2 - pstr);
> pstr = pstr2 + fromlen;
> +av_bprint_append_data(&pbuf, to, tolen);
> }
> -orglen = pstr - str + strlen(pstr);
> -/* Allocate memory for the post-replacement string. */
> -if (count > 0) {
> -tolen = strlen(to);
> -retlen = orglen + (tolen - fromlen) * count;
> -} else {
> -retlen = orglen;
> -}
> -ret = av_malloc(retlen + 1);
> -if (!ret) {
> -goto end_strreplace;
> -}
> -
> -if (!count) {
> -/* If no matches, then just duplicate the string. */
> -av_strlcpy(ret, str, retlen + 1);
> +av_bprint_append_data(&pbuf, pstr, strlen(pstr));
> +if (!av_bprint_is_complete(&pbuf)) {
> +av_bprint_finalize(&pbuf, NULL);
> } else {
> -/* Otherwise, duplicate the string whilst performing
> - * the replacements using the position cache. */
> -pret = ret;
> -memcpy(pret, str, pos_cache[0]);
> -pret += pos_cache[0];
> -for (i = 0; i < count; i++) {
> -memcpy(pret, to, tolen);
> -pret += tolen;
> -pstr = str + pos_cache[i] + fromlen;
> -cpylen = (i == count-1 ? orglen : pos_cache[i+1]) -
> pos_cache[i] - fromlen;
> -memcpy(pret, pstr, cpylen);
> -pret += cpylen;
> -}
> -ret[retlen] = '\0';
> +av_bprint_finalize(&pbuf, &ret);
> }
>
> -end_strreplace:
> -/* Free the cache and return the post-replacement string,
> - * which will be NULL in the event of an error. */
> -av_free(pos_cache);
> return ret;
> }
>
> diff --git a/libavutil/tests/avstring.c b/libavutil/tests/avstring.c
> index 14bc7ffcea..8660b348a8 100644
> --- a/libavutil/tests/avstring.c
> +++ b/libavutil/tests/avstring.c
> @@ -93,6 +93,22 @@ int main(void)
> TEST_STRNSTR(haystack, needle [2], strlen(haystack), NULL );
> TEST_STRNSTR(haystack, strings[1], strlen(haystack), haystack );
>
> +/*Testing av_strreplace()*/
> +#define TEST_STRREPLACE(haystack, needle, expected) \
> +ptr = av_strreplace(haystack, needle, "instead"); \
> +if (ptr == NULL) { \
> +printf("error, received null pointer!\n"); \
> +} else { \
> +if (strcmp(ptr, expected) != 0) \
> +printf( "expected: %s, received: %s\n", expected, ptr); \
> +av_free(ptr); \
> +}
> +
> +TEST_STRREPLACE(haystack, needle [0], "Education consists mainly in
> what we have uninstead");
> +TEST_STRREPLACE(haystack, needle [1], "Education consists mainly in
> what we have instead");
> +TEST_STRREPLACE(haystack, needle [2], "Education consists mainly
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On 4/5/2017 2:38 PM, Marton Balint wrote: > > > On Wed, 5 Apr 2017, James Almer wrote: > >> On 4/5/2017 1:49 PM, Marton Balint wrote: >>> >>> >>> On Wed, 5 Apr 2017, James Almer wrote: >>> On 4/5/2017 11:05 AM, Steven Liu wrote: > 2017-04-03 20:32 GMT+08:00 Nicolas George : > >> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>> change name from av_strreplace to av_strireplace >>> Use AVBprint to implement av_strireplace >>> add av_strireplace test case TEST_STRIREPLACE >>> >>> Signed-off-by: Steven Liu >>> --- >>> libavutil/avstring.c | 76 +++--- >> >>> libavutil/avstring.h | 2 +- >>> libavutil/tests/avstring.c | 16 ++ >>> 3 files changed, 28 insertions(+), 66 deletions(-) >> >> This version looks fine to me. >> >> Maybe wait a little more for advice about the rename and the whole >> thing. >> >> Thanks. >> >> -- >> Nicolas George >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > ping You can't rename the function. It's already in the 3.3 branch. This is one of the reasons why giving people enough time for reviews is a must before pushing new public symbols. >>> >>> Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there >>> any practical reason for not renaming it before the release? >>> >>> Thanks, >>> Marton >> >> Library versions and feature sets in diverging branches. When you >> branch you do a feature freeze. >> >> Making a mess with this for a single function that should have not >> been applied in such short notice shouldn't be acceptable. > > I don't think it would cause any problems for the users in practice. But we > can also remove the function alltogether from the release, so anybody who > want's to use the function (with the new name) will only have to check for a > single version number. > > Regards, > Marton Fine by me. The thing didn't even get its own bump or APIChanges now that i look at it, so it might as well not exist. It would hardly be the worst "breakage" we've gone through. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv 4] avutil/avstring: improve av_strreplace implement
Le septidi 17 germinal, an CCXXV, Steven Liu a écrit : > This patch just remove the rename operation base on previous patch. Please hold your horses! Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > > I don't think it would cause any problems for the users in practice. > > But we can also remove the function alltogether from the release, so > > anybody who want's to use the function (with the new name) will only > > have to check for a single version number. > Fine by me. The thing didn't even get its own bump or APIChanges > now that i look at it, so it might as well not exist. > It would hardly be the worst "breakage" we've gone through. I think removing the function from the release branch (before actual release if possible) and renaming it in master is a good solution. Thanks, Marton, for thinking of it. Steven, would you be fine with it? Michael? Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On 4/5/2017 2:49 PM, Nicolas George wrote: > Le sextidi 16 germinal, an CCXXV, James Almer a écrit : >>> I don't think it would cause any problems for the users in practice. >>> But we can also remove the function alltogether from the release, so >>> anybody who want's to use the function (with the new name) will only >>> have to check for a single version number. > >> Fine by me. The thing didn't even get its own bump or APIChanges >> now that i look at it, so it might as well not exist. >> It would hardly be the worst "breakage" we've gone through. > > I think removing the function from the release branch (before > actual release if possible) and renaming it in master is a good > solution. Thanks, Marton, for thinking of it. > > Steven, would you be fine with it? > > Michael? > > Regards, Make sure to add a line in APIChanges when you do. Maybe also a version bump. In master of course. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
2017-04-06 1:49 GMT+08:00 Nicolas George : > Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > > > I don't think it would cause any problems for the users in practice. > > > But we can also remove the function alltogether from the release, so > > > anybody who want's to use the function (with the new name) will only > > > have to check for a single version number. > > > Fine by me. The thing didn't even get its own bump or APIChanges > > now that i look at it, so it might as well not exist. > > It would hardly be the worst "breakage" we've gone through. > > I think removing the function from the release branch (before > actual release if possible) and renaming it in master is a good > solution. Thanks, Marton, for thinking of it. > > Steven, would you be fine with it? > yes, of course, i think just avformat/dashdec using it now, > > Michael? > > Regards, > > -- > Nicolas George > ___ > 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] [PATCH] vf_framestep: add blend parameter for motion blur effect
On Wed, Apr 05, 2017 at 02:00:28PM +0100, Matthias C. M. Troffaes wrote: > --- > Changelog | 1 + > doc/filters.texi | 7 ++ > libavfilter/vf_framestep.c| 242 > ++ > tests/fate/filter-video.mak | 5 + > tests/ref/fate/filter-framestep-1 | 17 +++ > tests/ref/fate/filter-framestep-2 | 17 +++ > tests/ref/fate/filter-framestep-3 | 17 +++ > 7 files changed, 286 insertions(+), 20 deletions(-) > create mode 100644 tests/ref/fate/filter-framestep-1 > create mode 100644 tests/ref/fate/filter-framestep-2 > create mode 100644 tests/ref/fate/filter-framestep-3 fails on qemu mips --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-framestep-2 2017-04-05 20:01:02.223828986 +0200 +++ tests/data/fate/filter-framestep-2 2017-04-05 20:01:21.279829394 +0200 @@ -3,15 +3,15 @@ #codec_id 0: rawvideo #dimensions 0: 320x180 #sar 0: 1/1 -0, 0, 0,1,86400, 0x5a5fa606 -0, 1, 1,1,86400, 0xaadd94b9 -0, 2, 2,1,86400, 0x91879f92 -0, 3, 3,1,86400, 0x62e3aa29 -0, 4, 4,1,86400, 0xb0a5b0b4 -0, 5, 5,1,86400, 0x49f4cb42 -0, 6, 6,1,86400, 0x396befa1 -0, 7, 7,1,86400, 0xc30e7e5d -0, 8, 8,1,86400, 0x677b4d09 -0, 9, 9,1,86400, 0xe7384e86 -0, 10, 10,1,86400, 0xf48d4e8b -0, 11, 11,1,86400, 0x43834cdd +0, 0, 0,1,86400, 0xcaefac44 +0, 1, 1,1,86400, 0xfb4e9af7 +0, 2, 2,1,86400, 0x5a52a5e7 +0, 3, 3,1,86400, 0x649fb063 +0, 4, 4,1,86400, 0x96adb6e5 +0, 5, 5,1,86400, 0x531bd16c +0, 6, 6,1,86400, 0xb0d3f59c +0, 7, 7,1,86400, 0xcaaa84a9 +0, 8, 8,1,86400, 0x9c03548f +0, 9, 9,1,86400, 0xcd90560f +0, 10, 10,1,86400, 0x92955627 +0, 11, 11,1,86400, 0x0af75472 Test filter-framestep-2 failed. Look at tests/data/fate/filter-framestep-2.err for details. make: *** [fate-filter-framestep-2] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffprobe: only use custom logging callback if -show_log is set
The custom callback can cause significant CPU usage on Windows for some large files with many index entries for some reason. Signed-off-by: Marton Balint --- ffprobe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ffprobe.c b/ffprobe.c index 0a9ba14..3d321cb 100644 --- a/ffprobe.c +++ b/ffprobe.c @@ -3458,7 +3458,8 @@ int main(int argc, char **argv) goto end; } #endif -av_log_set_callback(log_callback); +if (do_show_log) +av_log_set_callback(log_callback); av_log_set_flags(AV_LOG_SKIP_REPEATED); register_exit(ffprobe_cleanup); -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] flvdec: option for dropping negative CTS frames Initial frames with negative pts can produce video/audio desynchronization when a decoder is not prepared to handle negative
On Wed, 5 Apr 2017 14:29:30 -0300
fel...@astroza.cl wrote:
> From: Felipe Astroza
>
> Signed-off-by: Felipe Astroza
> ---
> libavformat/flvdec.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 3959a36..1556fe0 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -44,6 +44,7 @@
> typedef struct FLVContext {
> const AVClass *class; ///< Class for private options.
> int trust_metadata; ///< configure streams according onMetaData
> +int drop_negative_cts;///< drop frames if cts is negative
> int wrong_dts;///< wrong dts due to negative cts
> uint8_t *new_extradata[FLV_STREAM_TYPE_NB];
> int new_extradata_size[FLV_STREAM_TYPE_NB];
> @@ -1139,10 +1140,16 @@ retry_duration:
> int32_t cts = (avio_rb24(s->pb) + 0xff80) ^ 0xff80;
> pts = dts + cts;
> if (cts < 0) { // dts might be wrong
> -if (!flv->wrong_dts)
> +if (flv->drop_negative_cts) {
> av_log(s, AV_LOG_WARNING,
> -"Negative cts, previous timestamps might be
> wrong.\n");
> -flv->wrong_dts = 1;
> +"Negative cts, frames will be dropped.\n");
> +dts = pts = AV_NOPTS_VALUE;
> +} else {
> +if (!flv->wrong_dts)
> +av_log(s, AV_LOG_WARNING,
> +"Negative cts, previous timestamps might be
> wrong.\n");
> +flv->wrong_dts = 1;
> +}
> } else if (FFABS(dts - pts) > 1000*60*15) {
> av_log(s, AV_LOG_WARNING,
> "invalid timestamps %"PRId64" %"PRId64"\n", dts, pts);
> @@ -1253,6 +1260,7 @@ static int flv_read_seek(AVFormatContext *s, int
> stream_index,
> #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> static const AVOption options[] = {
> { "flv_metadata", "Allocate streams according to the onMetaData array",
> OFFSET(trust_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> +{ "flv_drop_negative_cts", "Drop frames with negative composition
> timestamp", OFFSET(drop_negative_cts), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> VD },
> { "missing_streams", "", OFFSET(missing_streams), AV_OPT_TYPE_INT, {
> .i64 = 0 }, 0, 0xFF, VD | AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY },
> { NULL }
> };
This seems all kind of wrong. You don't add a hack to a single demuxer
just because a single decoder can't handle unusual things in "some"
files. You don't add it as option either. (If this is a "fix my problem
the easiest way" hack, you should probably keep it in your own ffmpeg
branch.)
Why do the negative CTS happen, and what are their semantics?
Is this just the audio delay?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cavs: add a sse2 idct implementation.
This makes using the function pointer ff_add_pixels_clamped() unnecessary,
since we always know what the best implementation is at compile-time.
---
libavcodec/x86/cavsdsp.c| 15 +-
libavcodec/x86/cavsidct.asm | 48 -
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c
index add4536..a8a198b 100644
--- a/libavcodec/x86/cavsdsp.c
+++ b/libavcodec/x86/cavsdsp.c
@@ -29,6 +29,7 @@
#include "libavutil/x86/cpu.h"
#include "libavcodec/cavsdsp.h"
#include "libavcodec/idctdsp.h"
+#include "libavcodec/x86/idctdsp.h"
#include "constants.h"
#include "fpel.h"
#include "idctdsp.h"
@@ -43,7 +44,16 @@ static void cavs_idct8_add_mmx(uint8_t *dst, int16_t *block,
ptrdiff_t stride)
{
LOCAL_ALIGNED(16, int16_t, b2, [64]);
ff_cavs_idct8_mmx(b2, block);
-ff_add_pixels_clamped(b2, dst, stride);
+ff_add_pixels_clamped_mmx(b2, dst, stride);
+}
+
+void ff_cavs_idct8_sse2(int16_t *out, const int16_t *in);
+
+static void cavs_idct8_add_sse2(uint8_t *dst, int16_t *block, ptrdiff_t stride)
+{
+LOCAL_ALIGNED(16, int16_t, b2, [64]);
+ff_cavs_idct8_sse2(b2, block);
+ff_add_pixels_clamped_sse2(b2, dst, stride);
}
#endif /* HAVE_MMX_EXTERNAL */
@@ -446,6 +456,9 @@ av_cold void ff_cavsdsp_init_x86(CAVSDSPContext *c,
AVCodecContext *avctx)
if (EXTERNAL_SSE2(cpu_flags)) {
c->put_cavs_qpel_pixels_tab[0][0] = put_cavs_qpel16_mc00_sse2;
c->avg_cavs_qpel_pixels_tab[0][0] = avg_cavs_qpel16_mc00_sse2;
+
+c->cavs_idct8_add = cavs_idct8_add_sse2;
+c->idct_perm = FF_IDCT_PERM_TRANSPOSE;
}
#endif
}
diff --git a/libavcodec/x86/cavsidct.asm b/libavcodec/x86/cavsidct.asm
index 5421196..6c768c2 100644
--- a/libavcodec/x86/cavsidct.asm
+++ b/libavcodec/x86/cavsidct.asm
@@ -29,11 +29,16 @@ cextern pw_64
SECTION .text
-%macro CAVS_IDCT8_1D 2 ; source, round
+%macro CAVS_IDCT8_1D 2-3 1 ; source, round, init_load
+%if %3 == 1
movam4, [%1+7*16] ; m4 = src7
movam5, [%1+1*16] ; m5 = src1
movam2, [%1+5*16] ; m2 = src5
movam7, [%1+3*16] ; m7 = src3
+%else
+SWAP 1, 7
+SWAP 4, 6
+%endif
movam0, m4
movam3, m5
movam6, m2
@@ -163,3 +168,44 @@ cglobal cavs_idct8, 2, 4, 8, 8 * 16, out, in, cnt, tmp
jg .loop_2
RET
+
+INIT_XMM sse2
+cglobal cavs_idct8, 2, 2, 8 + ARCH_X86_64, 0 - 8 * 16, out, in
+CAVS_IDCT8_1D inq, [pw_4]
+psraw m7, 3
+psraw m6, 3
+psraw m5, 3
+psraw m4, 3
+psraw m3, 3
+psraw m2, 3
+psraw m1, 3
+psraw m0, 3
+%if ARCH_X86_64
+TRANSPOSE8x8W7, 5, 3, 1, 0, 2, 4, 6, 8
+mova[rsp+4*16], m0
+%else
+mova[rsp+0*16], m4
+TRANSPOSE8x8W7, 5, 3, 1, 0, 2, 4, 6, [rsp+0*16], [rsp+4*16], 1
+%endif
+mova[rsp+0*16], m7
+mova[rsp+2*16], m3
+mova[rsp+6*16], m4
+CAVS_IDCT8_1D rsp, [pw_64], 0
+psraw m7, 7
+psraw m6, 7
+psraw m5, 7
+psraw m4, 7
+psraw m3, 7
+psraw m2, 7
+psraw m1, 7
+psraw m0, 7
+
+mova [outq+0*16], m7
+mova [outq+1*16], m5
+mova [outq+2*16], m3
+mova [outq+3*16], m1
+mova [outq+4*16], m0
+mova [outq+5*16], m2
+mova [outq+6*16], m4
+mova [outq+7*16], m6
+RET
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/simple_idct: add explicit sse2 simple_idct_put/add versions.
These use the mmx IDCT, but sse2 put/add_pixels_clamped implementations.
This way we don't need to use the ff_put/add_pixels_clamped function
pointers.
---
libavcodec/x86/idctdsp_init.c | 38 ++
libavcodec/x86/simple_idct.c | 15 +--
libavcodec/x86/simple_idct.h | 3 +++
3 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index bcf7e5b..3f078e8 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -63,27 +63,41 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c,
AVCodecContext *avctx,
{
int cpu_flags = av_get_cpu_flags();
-if (INLINE_MMX(cpu_flags)) {
-if (!high_bit_depth &&
-avctx->lowres == 0 &&
-(avctx->idct_algo == FF_IDCT_AUTO ||
- avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
- avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
-c->idct_put = ff_simple_idct_put_mmx;
-c->idct_add = ff_simple_idct_add_mmx;
-c->idct = ff_simple_idct_mmx;
-c->perm_type = FF_IDCT_PERM_SIMPLE;
-}
-}
if (EXTERNAL_MMX(cpu_flags)) {
c->put_signed_pixels_clamped = ff_put_signed_pixels_clamped_mmx;
c->put_pixels_clamped= ff_put_pixels_clamped_mmx;
c->add_pixels_clamped= ff_add_pixels_clamped_mmx;
+
+if (INLINE_MMX(cpu_flags)) {
+if (!high_bit_depth &&
+avctx->lowres == 0 &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+c->idct_put = ff_simple_idct_put_mmx;
+c->idct_add = ff_simple_idct_add_mmx;
+c->idct = ff_simple_idct_mmx;
+c->perm_type = FF_IDCT_PERM_SIMPLE;
+}
+}
}
+
if (EXTERNAL_SSE2(cpu_flags)) {
c->put_signed_pixels_clamped = ff_put_signed_pixels_clamped_sse2;
c->put_pixels_clamped= ff_put_pixels_clamped_sse2;
c->add_pixels_clamped= ff_add_pixels_clamped_sse2;
+
+if (INLINE_SSE2(cpu_flags)) {
+if (!high_bit_depth &&
+avctx->lowres == 0 &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+c->idct_put = ff_simple_idct_put_sse2;
+c->idct_add = ff_simple_idct_add_sse2;
+c->perm_type = FF_IDCT_PERM_SIMPLE;
+}
+}
}
if (ARCH_X86_64 && avctx->lowres == 0) {
diff --git a/libavcodec/x86/simple_idct.c b/libavcodec/x86/simple_idct.c
index d3a19fa..1155920 100644
--- a/libavcodec/x86/simple_idct.c
+++ b/libavcodec/x86/simple_idct.c
@@ -24,6 +24,7 @@
#include "libavutil/x86/asm.h"
#include "libavcodec/idctdsp.h"
+#include "libavcodec/x86/idctdsp.h"
#include "idctdsp.h"
#include "simple_idct.h"
@@ -907,12 +908,22 @@ void ff_simple_idct_mmx(int16_t *block)
void ff_simple_idct_put_mmx(uint8_t *dest, ptrdiff_t line_size, int16_t *block)
{
idct(block);
-ff_put_pixels_clamped(block, dest, line_size);
+ff_put_pixels_clamped_mmx(block, dest, line_size);
}
void ff_simple_idct_add_mmx(uint8_t *dest, ptrdiff_t line_size, int16_t *block)
{
idct(block);
-ff_add_pixels_clamped(block, dest, line_size);
+ff_add_pixels_clamped_mmx(block, dest, line_size);
+}
+void ff_simple_idct_put_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block)
+{
+idct(block);
+ff_put_pixels_clamped_sse2(block, dest, line_size);
+}
+void ff_simple_idct_add_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block)
+{
+idct(block);
+ff_add_pixels_clamped_sse2(block, dest, line_size);
}
#endif /* HAVE_INLINE_ASM */
diff --git a/libavcodec/x86/simple_idct.h b/libavcodec/x86/simple_idct.h
index ad76baf..d17ef6a 100644
--- a/libavcodec/x86/simple_idct.h
+++ b/libavcodec/x86/simple_idct.h
@@ -26,6 +26,9 @@ void ff_simple_idct_mmx(int16_t *block);
void ff_simple_idct_add_mmx(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
void ff_simple_idct_put_mmx(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct_add_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct_put_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+
void ff_simple_idct10_sse2(int16_t *block);
void ff_simple_idct10_avx(int16_t *block);
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/idctdsp_init: reindent.
---
libavcodec/x86/idctdsp_init.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index 3f078e8..fd5ef3f 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -102,22 +102,22 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c,
AVCodecContext *avctx,
if (ARCH_X86_64 && avctx->lowres == 0) {
if (avctx->bits_per_raw_sample == 10 &&
-(avctx->idct_algo == FF_IDCT_AUTO ||
- avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
- avctx->idct_algo == FF_IDCT_SIMPLE)) {
-if (EXTERNAL_SSE2(cpu_flags)) {
-c->idct_put = ff_simple_idct10_put_sse2;
-c->idct_add = NULL;
-c->idct = ff_simple_idct10_sse2;
-c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+(avctx->idct_algo == FF_IDCT_AUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLE)) {
+if (EXTERNAL_SSE2(cpu_flags)) {
+c->idct_put = ff_simple_idct10_put_sse2;
+c->idct_add = NULL;
+c->idct = ff_simple_idct10_sse2;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
-}
-if (EXTERNAL_AVX(cpu_flags)) {
-c->idct_put = ff_simple_idct10_put_avx;
-c->idct_add = NULL;
-c->idct = ff_simple_idct10_avx;
-c->perm_type = FF_IDCT_PERM_TRANSPOSE;
-}
+}
+if (EXTERNAL_AVX(cpu_flags)) {
+c->idct_put = ff_simple_idct10_put_avx;
+c->idct_add = NULL;
+c->idct = ff_simple_idct10_avx;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
}
if (avctx->bits_per_raw_sample == 12 &&
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mjpegenc: enable optimal huffman coding by default
On Tue, Apr 04, 2017 at 04:10:39PM +0200, Michael Niedermayer wrote: > On Tue, Apr 04, 2017 at 03:59:28PM +0200, Michael Niedermayer wrote: > > On Tue, Apr 04, 2017 at 11:00:23AM +0100, Rostislav Pehlivanov wrote: > > > On 4 April 2017 at 02:54, Michael Niedermayer > > > wrote: > > > > > > > On Mon, Apr 03, 2017 at 10:31:27PM +0100, Rostislav Pehlivanov wrote: > > > > > As it gives excellent encoding gains at an insignificant speed > > > > > increase > > > > > and passes fate without problems, it should now be safe to enable by > > > > > default. > > > > > > > > Still breaks slice threading > > > > > > > > both > > > > Assertion n <= 31 && value < (1U << n) failed at > > > > libavcodec/put_bits.h:157 > > > > > > > > and > > > > Assertion (header_bits & 7) == 0 failed at libavcodec/mjpegenc_common.c: > > > > 541 > > > > > > > > occur with > > > > ./ffmpeg -y -i ~/fatesamples/fate/fate-suite/lena.pnm -vf scale -strict > > > > -1 -threads 2 -thread_type slice test.jpg > > > > > > > > randomly > > > > > > > > also ive seen it not trigger an assert on repeating the command > > > > > > > > [...] > > > > -- > > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > > > You can kill me, but you cannot change the truth. > > > > > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > > > Sent a patch meant to be applied before this patch to disable it with AMV > > > and slice threads, should fix this issue. > > > > The failing case doesnt use AMV > > and i double checked, i had all 3 patches applied when i tested > > yestarday > > wait, i just saw you posted a new patch today, i havnt tried that > will do tried, seems to work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] mjpegenc_common: check for codec ID before using avctx->priv_data
On Mon, Apr 03, 2017 at 09:13:28PM +0100, Rostislav Pehlivanov wrote:
> When coding lossless jpeg the priv context will be pointing to LJpegEncContext
> rather than MpegEncContext, which the function expects.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavcodec/mjpegenc_common.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mjpegenc_common.c b/libavcodec/mjpegenc_common.c
> index 83a9e95766..6d9c982726 100644
> --- a/libavcodec/mjpegenc_common.c
> +++ b/libavcodec/mjpegenc_common.c
> @@ -91,13 +91,17 @@ static void jpeg_table_header(AVCodecContext *avctx,
> PutBitContext *p,
> {
> int i, j, size;
> uint8_t *ptr;
> -MpegEncContext *s = avctx->priv_data;
> +MpegEncContext *s = NULL;
> +
> +/* Since avctx->priv_data will point to LJpegEncContext in this case */
> +if (avctx->codec_id != AV_CODEC_ID_LJPEG)
> +s = avctx->priv_data;
>
> if (avctx->codec_id != AV_CODEC_ID_LJPEG) {
> int matrix_count = 1 + !!memcmp(luma_intra_matrix,
> chroma_intra_matrix,
> sizeof(luma_intra_matrix[0]) * 64);
> -if (s->force_duplicated_matrix)
> +if (s && s->force_duplicated_matrix)
> matrix_count = 2;
> /* quant matrixes */
> put_marker(p, DQT);
> @@ -134,7 +138,7 @@ static void jpeg_table_header(AVCodecContext *avctx,
> PutBitContext *p,
>
> // Only MJPEG can have a variable Huffman variable. All other
> // formats use the default Huffman table.
> -if (s->out_format == FMT_MJPEG && s->huffman == HUFFMAN_TABLE_OPTIMAL) {
> +if (s && s->huffman == HUFFMAN_TABLE_OPTIMAL) {
> size += put_huffman_table(p, 0, 0, s->mjpeg_ctx->bits_dc_luminance,
>s->mjpeg_ctx->val_dc_luminance);
> size += put_huffman_table(p, 0, 1, s->mjpeg_ctx->bits_dc_chrominance,
ljpeg uses the same huffman tables as mjpeg,the same
ff_mjpeg_encode_dc()
instead of special casing ljpeg it would be better if the identical
huffman stuff would be shared and the same
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- 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] huffyuv: assign correct per-thread avctx pointer to HYuvContext::avctx.
On Mon, Apr 03, 2017 at 10:28:33PM -0400, Ronald S. Bultje wrote: > Fixes the following tsan warning when running fate-vsynth_lena-ffvhuff: > > WARNING: ThreadSanitizer: data race (pid=6484) > Write of size 8 at 0x7d64000154b8 by main thread (mutexes: write M1331): > #0 update_context_from_user src/libavcodec/pthread_frame.c:331 > (ffmpeg+0x00dca887) > [..] > Previous read of size 8 at 0x7d64000154b8 by thread T2 (mutexes: write > M1334): > #0 draw_slice src/libavcodec/huffyuvdec.c:857 (ffmpeg+0x00bcc86f) > --- > libavcodec/huffyuvdec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c > index 5572b98..979c4b9 100644 > --- a/libavcodec/huffyuvdec.c > +++ b/libavcodec/huffyuvdec.c > @@ -579,6 +579,8 @@ static av_cold int decode_init_thread_copy(AVCodecContext > *avctx) > HYuvContext *s = avctx->priv_data; > int i, ret; > > +s->avctx = avctx; LGTM do you think its better in decode_init_thread_copy() or decode_frame() ? I think i would have instinctivly put it in decode_frame() but i dont see a issue with decode_init_thread_copy() thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] huffyuv: assign correct per-thread avctx pointer to HYuvContext::avctx.
Hi, On Wed, Apr 5, 2017 at 3:29 PM, Michael Niedermayer wrote: > On Mon, Apr 03, 2017 at 10:28:33PM -0400, Ronald S. Bultje wrote: > > Fixes the following tsan warning when running fate-vsynth_lena-ffvhuff: > > > > WARNING: ThreadSanitizer: data race (pid=6484) > > Write of size 8 at 0x7d64000154b8 by main thread (mutexes: write > M1331): > > #0 update_context_from_user src/libavcodec/pthread_frame.c:331 > (ffmpeg+0x00dca887) > > [..] > > Previous read of size 8 at 0x7d64000154b8 by thread T2 (mutexes: write > M1334): > > #0 draw_slice src/libavcodec/huffyuvdec.c:857 > (ffmpeg+0x00bcc86f) > > --- > > libavcodec/huffyuvdec.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c > > index 5572b98..979c4b9 100644 > > --- a/libavcodec/huffyuvdec.c > > +++ b/libavcodec/huffyuvdec.c > > @@ -579,6 +579,8 @@ static av_cold int > > decode_init_thread_copy(AVCodecContext > *avctx) > > HYuvContext *s = avctx->priv_data; > > int i, ret; > > > > +s->avctx = avctx; > > LGTM > > do you think its better in decode_init_thread_copy() or decode_frame() ? > I think i would have instinctivly put it in decode_frame() but i dont > see a issue with decode_init_thread_copy() I see _init() as logically more correct since this data is supposed to be stable across multiple (all) frames. But in practice I don't think it would matter. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread_frame: allow per-field ThreadFrame owners.
Hi, On Mon, Apr 3, 2017 at 10:24 AM, Ronald S. Bultje wrote: > This tries to handle cases where separate invocations of decode_frame() > (each running in separate threads) write to respective fields in the > same AVFrame->data[]. Having per-field owners makes interaction between > readers (the referencing thread) and writers (the decoding thread) > slightly more optimal if both accesses are field-based, since they will > use the respective producer's thread objects (mutex/cond) instead of > sharing the thread objects of the first field's producer. > > In practice, this fixes the following tsan-warning in fate-h264: > > WARNING: ThreadSanitizer: data race (pid=21615) > Read of size 4 at 0x7d64d9fc by thread T2 (mutexes: write M1006): > #0 ff_thread_report_progress pthread_frame.c:569 > (ffmpeg:x86_64+0x100f7cf54) > [..] > Previous write of size 4 at 0x7d64d9fc by main thread (mutexes: > write M1004): > #0 update_context_from_user pthread_frame.c:335 > (ffmpeg:x86_64+0x100f81abb) > --- > libavcodec/h264_slice.c| 8 +--- > libavcodec/pthread_frame.c | 18 ++ > libavcodec/thread.h| 2 +- > libavcodec/utils.c | 7 --- > 4 files changed, 20 insertions(+), 15 deletions(-) > Ping. (I realize this patch is probably very hard to review, but I'd really appreciate a second set of eyes/brains on my proposed solution, exactly because it's hard - and also because it touches a very fundamental core element of frame-mt design.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/h264: change RETs into REP_RETs where appropriate
On 2017-04-05 05:33, James Almer wrote: > On 4/4/2017 10:53 PM, James Darnley wrote: >> --- >> libavcodec/x86/h264_idct.asm | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm >> index c36fea5..878ff02 100644 >> --- a/libavcodec/x86/h264_idct.asm >> +++ b/libavcodec/x86/h264_idct.asm >> @@ -695,7 +695,7 @@ cglobal h264_idct_add8_8, 5, 8 + npicregs, 0, dst1, >> block_offset, block, stride, >> addr0mp, gprsize >> %endif >> call h264_idct_add8_mmx_plane >> -RET >> +RET ; TODO: check rep ret after a function call >> >> cglobal h264_idct_add8_422_8, 5, 8 + npicregs, 0, dst1, block_offset, >> block, stride, nnzc, cntr, coeff, dst2, picreg >> ; dst1, block_offset, block, stride, nnzc, cntr, coeff, dst2, picreg >> @@ -727,7 +727,7 @@ cglobal h264_idct_add8_422_8, 5, 8 + npicregs, 0, dst1, >> block_offset, block, str >> add r5, 4 >> call h264_idct_add8_mmx_plane >> >> -RET >> +RET ; TODO: check rep ret after a function call >> >> h264_idct_add8_mmxext_plane: >> movsxdifnidn r3, r3d >> @@ -795,7 +795,7 @@ cglobal h264_idct_add8_8, 5, 8 + npicregs, 0, dst1, >> block_offset, block, stride, >> addr0mp, gprsize >> %endif >> call h264_idct_add8_mmxext_plane >> -RET >> +RET ; TODO: check rep ret after a function call >> >> ; r0 = uint8_t *dst, r2 = int16_t *block, r3 = int stride, r6=clobbered >> h264_idct_dc_add8_mmxext: >> @@ -878,7 +878,7 @@ cglobal h264_idct_add16_8, 5, 5 + ARCH_X86_64, 8 >> add16_sse2_cycle 5, 0x24 >> add16_sse2_cycle 6, 0x1e >> add16_sse2_cycle 7, 0x26 >> -RET >> +REP_RET >> >> %macro add16intra_sse2_cycle 2 >> movzx r0, word [r4+%2] >> @@ -925,7 +925,7 @@ cglobal h264_idct_add16intra_8, 5, 7 + ARCH_X86_64, 8 >> add16intra_sse2_cycle 5, 0x24 >> add16intra_sse2_cycle 6, 0x1e >> add16intra_sse2_cycle 7, 0x26 >> -RET >> +REP_RET >> >> %macro add8_sse2_cycle 2 >> movzx r0, word [r4+%2] >> @@ -980,7 +980,7 @@ cglobal h264_idct_add8_8, 5, 7 + ARCH_X86_64, 8 >> %endif >> add8_sse2_cycle 2, 0x5c >> add8_sse2_cycle 3, 0x64 >> -RET >> +REP_RET >> >> ;void ff_h264_luma_dc_dequant_idct_mmx(int16_t *output, int16_t *input, int >> qmul) > > This is not necessary. Look at the RET macro in x86inc, It calls the > AUTO_REP_RET > macro. As I said last time, the macro only knows when the previous instruction was a jump, not when ret is a branch target. These macros contain a jump to a label at the end which means we should use REP_RET. The relevant doc comment: > ; On AMD cpus <=K10, an ordinary ret is slow if it immediately follows either > ; a branch or a branch target. So switch to a 2-byte form of ret in that case. > ; We can automatically detect "follows a branch", but not a branch target. > ; (SSSE3 is a sufficient condition to know that your cpu doesn't have this > problem.) Has x86inc gained more magic? I know people don't care much about old CPUs, I hardly do either. That said I do plan to resurrect an old K8 (if I ever tidy this place) just so I have an sse2slow machine available. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] vp8: make wait/thread_mb_pos atomic.
Fixes tsan warnings like this in fate-vp8-test-vector-007:
WARNING: ThreadSanitizer: data race (pid=3590)
Write of size 4 at 0x7d8ce07c by thread T2:
#0 decode_mb_row_no_filter src/libavcodec/vp8.c:2330 (ffmpeg+0x00ffb59e)
[..]
Previous write of size 4 at 0x7d8ce07c by thread T1:
#0 decode_mb_row_no_filter src/libavcodec/vp8.c:2330 (ffmpeg+0x00ffb59e)
---
libavcodec/vp8.c | 29 ++---
libavcodec/vp8.h | 6 --
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 1e8808c..9bc1d95 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2247,15 +2247,15 @@ static void vp8_decode_mv_mb_modes(AVCodecContext
*avctx, VP8Frame *cur_frame,
#define check_thread_pos(td, otd, mb_x_check, mb_y_check) \
do { \
int tmp = (mb_y_check << 16) | (mb_x_check & 0x); \
-if (otd->thread_mb_pos < tmp) { \
+if (atomic_load(&otd->thread_mb_pos) < tmp) { \
pthread_mutex_lock(&otd->lock); \
-td->wait_mb_pos = tmp;\
+atomic_store(&td->wait_mb_pos, tmp); \
do { \
-if (otd->thread_mb_pos >= tmp)\
+if (atomic_load(&otd->thread_mb_pos) >= tmp) \
break;\
pthread_cond_wait(&otd->cond, &otd->lock);\
} while (1); \
-td->wait_mb_pos = INT_MAX;\
+atomic_store(&td->wait_mb_pos, INT_MAX); \
pthread_mutex_unlock(&otd->lock); \
} \
} while (0)
@@ -2266,12 +2266,10 @@ static void vp8_decode_mv_mb_modes(AVCodecContext
*avctx, VP8Frame *cur_frame,
int sliced_threading = (avctx->active_thread_type == FF_THREAD_SLICE)
&& \
(num_jobs > 1);\
int is_null = !next_td || !prev_td; \
-int pos_check= (is_null) ? 1 \
- : (next_td != td && \
-pos >= next_td->wait_mb_pos) || \
- (prev_td != td && \
-pos >= prev_td->wait_mb_pos); \
-td->thread_mb_pos = pos; \
+int pos_check= (is_null) ? 1 :\
+(next_td != td && pos >= atomic_load(&next_td->wait_mb_pos)) || \
+(prev_td != td && pos >= atomic_load(&prev_td->wait_mb_pos)); \
+atomic_store(&td->thread_mb_pos, pos);\
if (sliced_threading && pos_check) { \
pthread_mutex_lock(&td->lock);\
pthread_cond_broadcast(&td->cond);\
@@ -2288,7 +2286,7 @@ static av_always_inline int
decode_mb_row_no_filter(AVCodecContext *avctx, void
{
VP8Context *s = avctx->priv_data;
VP8ThreadData *prev_td, *next_td, *td = &s->thread_data[threadnr];
-int mb_y = td->thread_mb_pos >> 16;
+int mb_y = atomic_load(&td->thread_mb_pos) >> 16;
int mb_x, mb_xy = mb_y * s->mb_width;
int num_jobs = s->num_jobs;
VP8Frame *curframe = s->curframe, *prev_frame = s->prev_frame;
@@ -2428,7 +2426,7 @@ static av_always_inline void filter_mb_row(AVCodecContext
*avctx, void *tdata,
{
VP8Context *s = avctx->priv_data;
VP8ThreadData *td = &s->thread_data[threadnr];
-int mb_x, mb_y = td->thread_mb_pos >> 16, num_jobs = s->num_jobs;
+int mb_x, mb_y = atomic_load(&td->thread_mb_pos) >> 16, num_jobs =
s->num_jobs;
AVFrame *curframe = s->curframe->tf.f;
VP8Macroblock *mb;
VP8ThreadData *prev_td, *next_td;
@@ -2507,7 +2505,7 @@ int vp78_decode_mb_row_sliced(AVCodecContext *avctx, void
*tdata, int jobnr,
td->thread_nr = threadnr;
for (mb_y = jobnr; mb_y < s->mb_height; mb_y += num_jobs) {
-td->thread_mb_pos = mb_y << 16;
+atomic_store(&td->thread_mb_pos, mb_y << 16);
ret = s->decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr);
if (ret < 0) {
update_pos(td, s->mb_height, INT_MAX & 0x)
[FFmpeg-devel] [PATCH 2/2] vp8: make mv_min/max thread-local if using partition threading.
Fixes tsan warnings like this in fate-vp8-test-vector-007:
WARNING: ThreadSanitizer: data race (pid=65909)
Write of size 4 at 0x7d8ce088 by thread T1:
#0 vp8_decode_mb_row_sliced vp8.c:2519 (ffmpeg:x86_64+0x100995ede)
[..]
Previous write of size 4 at 0x7d8ce088 by thread T2:
#0 vp8_decode_mb_row_sliced vp8.c:2519 (ffmpeg:x86_64+0x100995ede)
---
libavcodec/vp8.c | 53 -
libavcodec/vp8.h | 19 ---
2 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 9bc1d95..fe7aa23 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -772,7 +772,7 @@ static int vp8_decode_frame_header(VP8Context *s, const
uint8_t *buf, int buf_si
}
static av_always_inline
-void clamp_mv(VP8Context *s, VP56mv *dst, const VP56mv *src)
+void clamp_mv(VP8mvbounds *s, VP56mv *dst, const VP56mv *src)
{
dst->x = av_clip(src->x, av_clip(s->mv_min.x, INT16_MIN, INT16_MAX),
av_clip(s->mv_max.x, INT16_MIN, INT16_MAX));
@@ -1031,7 +1031,7 @@ void vp7_decode_mvs(VP8Context *s, VP8Macroblock *mb,
}
static av_always_inline
-void vp8_decode_mvs(VP8Context *s, VP8Macroblock *mb,
+void vp8_decode_mvs(VP8Context *s, VP8mvbounds *mv_bounds, VP8Macroblock *mb,
int mb_x, int mb_y, int layout)
{
VP8Macroblock *mb_edge[3] = { 0 /* top */,
@@ -1102,7 +1102,7 @@ void vp8_decode_mvs(VP8Context *s, VP8Macroblock *mb,
if (vp56_rac_get_prob_branchy(c,
vp8_mode_contexts[cnt[CNT_NEAREST]][1])) {
if (vp56_rac_get_prob_branchy(c,
vp8_mode_contexts[cnt[CNT_NEAR]][2])) {
/* Choose the best mv out of 0,0 and the nearest mv */
-clamp_mv(s, &mb->mv, &near_mv[CNT_ZERO + (cnt[CNT_NEAREST] >=
cnt[CNT_ZERO])]);
+clamp_mv(mv_bounds, &mb->mv, &near_mv[CNT_ZERO +
(cnt[CNT_NEAREST] >= cnt[CNT_ZERO])]);
cnt[CNT_SPLITMV] = ((mb_edge[VP8_EDGE_LEFT]->mode==
VP8_MVMODE_SPLIT) +
(mb_edge[VP8_EDGE_TOP]->mode ==
VP8_MVMODE_SPLIT)) * 2 +
(mb_edge[VP8_EDGE_TOPLEFT]->mode ==
VP8_MVMODE_SPLIT);
@@ -1116,11 +1116,11 @@ void vp8_decode_mvs(VP8Context *s, VP8Macroblock *mb,
mb->bmv[0] = mb->mv;
}
} else {
-clamp_mv(s, &mb->mv, &near_mv[CNT_NEAR]);
+clamp_mv(mv_bounds, &mb->mv, &near_mv[CNT_NEAR]);
mb->bmv[0] = mb->mv;
}
} else {
-clamp_mv(s, &mb->mv, &near_mv[CNT_NEAREST]);
+clamp_mv(mv_bounds, &mb->mv, &near_mv[CNT_NEAREST]);
mb->bmv[0] = mb->mv;
}
} else {
@@ -1166,7 +1166,8 @@ void decode_intra4x4_modes(VP8Context *s, VP56RangeCoder
*c, VP8Macroblock *mb,
}
static av_always_inline
-void decode_mb_mode(VP8Context *s, VP8Macroblock *mb, int mb_x, int mb_y,
+void decode_mb_mode(VP8Context *s, VP8mvbounds *mv_bounds,
+VP8Macroblock *mb, int mb_x, int mb_y,
uint8_t *segment, uint8_t *ref, int layout, int is_vp7)
{
VP56RangeCoder *c = &s->c;
@@ -1230,7 +1231,7 @@ void decode_mb_mode(VP8Context *s, VP8Macroblock *mb, int
mb_x, int mb_y,
if (is_vp7)
vp7_decode_mvs(s, mb, mb_x, mb_y, layout);
else
-vp8_decode_mvs(s, mb, mb_x, mb_y, layout);
+vp8_decode_mvs(s, mv_bounds, mb, mb_x, mb_y, layout);
} else {
// intra MB, 16.1
mb->mode = vp8_rac_get_tree(c, vp8_pred16x16_tree_inter,
s->prob->pred16x16);
@@ -2205,8 +2206,8 @@ void vp78_decode_mv_mb_modes(AVCodecContext *avctx,
VP8Frame *curframe,
VP8Context *s = avctx->priv_data;
int mb_x, mb_y;
-s->mv_min.y = -MARGIN;
-s->mv_max.y = ((s->mb_height - 1) << 6) + MARGIN;
+s->mv_bounds.mv_min.y = -MARGIN;
+s->mv_bounds.mv_max.y = ((s->mb_height - 1) << 6) + MARGIN;
for (mb_y = 0; mb_y < s->mb_height; mb_y++) {
VP8Macroblock *mb = s->macroblocks_base +
((s->mb_width + 1) * (mb_y + 1) + 1);
@@ -2214,20 +2215,20 @@ void vp78_decode_mv_mb_modes(AVCodecContext *avctx,
VP8Frame *curframe,
AV_WN32A(s->intra4x4_pred_mode_left, DC_PRED * 0x01010101);
-s->mv_min.x = -MARGIN;
-s->mv_max.x = ((s->mb_width - 1) << 6) + MARGIN;
+s->mv_bounds.mv_min.x = -MARGIN;
+s->mv_bounds.mv_max.x = ((s->mb_width - 1) << 6) + MARGIN;
for (mb_x = 0; mb_x < s->mb_width; mb_x++, mb_xy++, mb++) {
if (mb_y == 0)
AV_WN32A((mb - s->mb_width - 1)->intra4x4_pred_mode_top,
DC_PRED * 0x01010101);
-decode_mb_mode(s, mb, mb_x, mb_y, curframe->seg_map->data + mb_xy,
+decode_mb_mode(s, &s->mv_bounds, mb, mb_x, mb_y,
curframe->seg_map->data + mb_xy,
prev_frame && prev_frame->seg_map ?
Re: [FFmpeg-devel] [PATCH] flvdec: option for dropping negative CTS frames Initial frames with negative pts can produce video/audio desynchronization when a decoder is not prepared to handle negative
2017-04-05 15:35 GMT-03:00 wm4 :
> On Wed, 5 Apr 2017 14:29:30 -0300
> fel...@astroza.cl wrote:
>
> > From: Felipe Astroza
> >
> > Signed-off-by: Felipe Astroza
> > ---
> > libavformat/flvdec.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index 3959a36..1556fe0 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
> > @@ -44,6 +44,7 @@
> > typedef struct FLVContext {
> > const AVClass *class; ///< Class for private options.
> > int trust_metadata; ///< configure streams according onMetaData
> > +int drop_negative_cts;///< drop frames if cts is negative
> > int wrong_dts;///< wrong dts due to negative cts
> > uint8_t *new_extradata[FLV_STREAM_TYPE_NB];
> > int new_extradata_size[FLV_STREAM_TYPE_NB];
> > @@ -1139,10 +1140,16 @@ retry_duration:
> > int32_t cts = (avio_rb24(s->pb) + 0xff80) ^ 0xff80;
> > pts = dts + cts;
> > if (cts < 0) { // dts might be wrong
> > -if (!flv->wrong_dts)
> > +if (flv->drop_negative_cts) {
> > av_log(s, AV_LOG_WARNING,
> > -"Negative cts, previous timestamps might be
> wrong.\n");
> > -flv->wrong_dts = 1;
> > +"Negative cts, frames will be dropped.\n");
> > +dts = pts = AV_NOPTS_VALUE;
> > +} else {
> > +if (!flv->wrong_dts)
> > +av_log(s, AV_LOG_WARNING,
> > +"Negative cts, previous timestamps might be
> wrong.\n");
> > +flv->wrong_dts = 1;
> > +}
> > } else if (FFABS(dts - pts) > 1000*60*15) {
> > av_log(s, AV_LOG_WARNING,
> > "invalid timestamps %"PRId64" %"PRId64"\n", dts,
> pts);
> > @@ -1253,6 +1260,7 @@ static int flv_read_seek(AVFormatContext *s, int
> stream_index,
> > #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> > static const AVOption options[] = {
> > { "flv_metadata", "Allocate streams according to the onMetaData
> array", OFFSET(trust_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> > +{ "flv_drop_negative_cts", "Drop frames with negative composition
> timestamp", OFFSET(drop_negative_cts), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
> 1, VD },
> > { "missing_streams", "", OFFSET(missing_streams), AV_OPT_TYPE_INT,
> { .i64 = 0 }, 0, 0xFF, VD | AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY },
> > { NULL }
> > };
>
> This seems all kind of wrong. You don't add a hack to a single demuxer
> just because a single decoder can't handle unusual things in "some"
> files. You don't add it as option either. (If this is a "fix my problem
> the easiest way" hack, you should probably keep it in your own ffmpeg
> branch.)
>
> It was the way I found to avoid the initial frames without a preceding
keyframe (marked with pts < 0) that RTMP wowza server sends in live
streams, just cover flv format case :/. And yes yes, you're right, this is
a hack because of I was not able to patch QSV decoder.
h264_qsv decoder -> h264_qsv encoder produces a video delayed output
h264_qsv decoder -> libx264 encoder produces a video delayed output
libx264 decoder -> libx264 encoder produces a right output
h264_qsv is the source of my issues. I was passing -itsoffset CONSTANT(0.5
in my case) as workaround but it works 90% of the time and I just want a
definitive solution.
Maybe this option do not deserve be part of master but, maybe useful for
people trying to work with QSV transcoding
Why do the negative CTS happen, and what are their semantics?
>
> Context: https://patches.libav.org/patch/56714/
"Some streaming servers (such as wowza) send all preceding packets in
the current GOP (to allow starting decoding immediately, instead of
waiting for the next keyframe)"
Is this just the audio delay?
Video delay, audio goes first
> ___
> 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
[FFmpeg-devel] [PATCH] libavformat/mov: Fix memory leak, need to free the chapter tracks array
--- libavformat/mov.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index 90bc2499da..f2296f8917 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -5794,6 +5794,7 @@ static int mov_read_close(AVFormatContext *s) av_freep(&mov->fragment_index_data); av_freep(&mov->aes_decrypt); +av_freep(&mov->chapter_tracks); return 0; } -- 2.12.2.715.g7642488e1d-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/h264: change RETs into REP_RETs where appropriate
On Wed, Apr 5, 2017 at 3:53 AM, James Darnley wrote: > call h264_idct_add8_mmx_plane > -RET > +RET ; TODO: check rep ret after a function call call followed by RET should be replaced by the TAIL_CALL macro instead which outputs a jmp instruction if there's no function epilogue. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Build fix for MIPS
Hi, On Wed, Apr 5, 2017 at 8:38 AM, Shivraj Patil wrote: > Hi, > > > > Updated the patch as per comments. > > As hevcpred_init_mips.c needs definition of HAVE_MSA and av_cold, now I > have included config.h & libavutil/attributes.h in this file. > Patch LGTM. I'll leave it up for a day for others to comment before I push. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf: use the new bitstream filter for extracting extradata
On 4/1/2017 9:03 PM, James Almer wrote: > This merges commits 8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4 and > 096a8effa3f8f3455292c958c3ed07e798def7bd by Anton Khirnov, with the > following change: > > - extract_extradata_check() is added to know if the codec is supported > by the bsf before trying to initialize it. This behaviour is similar to > the old AVCodecParser.split checks. > > The FATE reference changes are due to the filtered out NAL units that > the old AVCodecParser.split implementation left alone. > Decoding is unchanged as the functions that parse extradata simply > ignored said unnecessary NAL units. > > Signed-off-by: James Almer > --- > libavformat/internal.h | 9 ++ > libavformat/utils.c | 146 > --- > tests/ref/fate/copy-trac2211-avi | 4 +- > tests/ref/fate/h264_mp4toannexb_ticket2991 | 2 +- > tests/ref/fate/h264_mp4toannexb_ticket5927 | 2 +- > tests/ref/fate/h264_mp4toannexb_ticket5927_2 | 2 +- > tests/ref/fate/segment-mp4-to-ts | 2 +- > 7 files changed, 148 insertions(+), 19 deletions(-) I'll be pushing this soon. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/hevc_parse: check for parameter set decoding failure
On 4/3/2017 10:46 AM, James Almer wrote:
> On 4/3/2017 7:00 AM, Michael Niedermayer wrote:
>> On Sun, Apr 02, 2017 at 10:45:41PM -0300, James Almer wrote:
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/hevc_parse.c | 32 +---
>>> 1 file changed, 25 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
>>> index 6c1138e015..028ca5afe5 100644
>>> --- a/libavcodec/hevc_parse.c
>>> +++ b/libavcodec/hevc_parse.c
>>> @@ -22,7 +22,8 @@
>>> #include "hevc_parse.h"
>>>
>>> static int hevc_decode_nal_units(const uint8_t *buf, int buf_size,
>>> HEVCParamSets *ps,
>>> - int is_nalff, int nal_length_size, void
>>> *logctx)
>>> + int is_nalff, int nal_length_size, int
>>> err_recognition,
>>> + void *logctx)
>>> {
>>> int i;
>>> int ret = 0;
>>> @@ -38,9 +39,21 @@ static int hevc_decode_nal_units(const uint8_t *buf, int
>>> buf_size, HEVCParamSets
>>>
>>> /* ignore everything except parameter sets and VCL NALUs */
>>> switch (nal->type) {
>>> -case HEVC_NAL_VPS: ff_hevc_decode_nal_vps(&nal->gb, logctx, ps);
>>> break;
>>> -case HEVC_NAL_SPS: ff_hevc_decode_nal_sps(&nal->gb, logctx, ps,
>>> 1); break;
>>> -case HEVC_NAL_PPS: ff_hevc_decode_nal_pps(&nal->gb, logctx, ps);
>>> break;
>>> +case HEVC_NAL_VPS:
>>> +ret = ff_hevc_decode_nal_vps(&nal->gb, logctx, ps);
>>> +if (ret < 0)
>>> +goto done;
>>> +break;
>>> +case HEVC_NAL_SPS:
>>> +ret = ff_hevc_decode_nal_sps(&nal->gb, logctx, ps, 1);
>>> +if (ret < 0)
>>> +goto done;
>>> +break;
>>> +case HEVC_NAL_PPS:
>>> +ret = ff_hevc_decode_nal_pps(&nal->gb, logctx, ps);
>>> +if (ret < 0)
>>> +goto done;
>>> +break;
>>> case HEVC_NAL_TRAIL_R:
>>> case HEVC_NAL_TRAIL_N:
>>> case HEVC_NAL_TSA_N:
>>
>> I didnt investigate how exactly this is used but from just the patch
>> this seems not optimal
>> For example, if you have 3 PPS NALs and the first fails to decode
>> you might still be able to fully decode the other 2
>
> I'm mimicking the behavior of decode_nal_unit() in hevcdec.c, which is
> currently used during frame decoding and extradata decoding.
> This patchset aims at removing duplicate code while keeping the hevc
> decoder behaving the same as it was before. I could skip this change
> if that's preferred, but if this behavior is not optimal then someone
> who better understands the codec should look at it.
To add some context, the functions in hevc_parse.c are currently used
only by the mediacodec based hevc decoder to decode extradata, and it's
a duplicate of existing functionality in hevcdec.c used by the internal
hevc decoder.
This set aims at putting the hevc_parse.c version on par with the
hevcdec.c one (in the scope of extradata parsing, not frame) to share it
between the two decoders and any other that may need it in the future.
This patch checks for PS failures and aborts if err_recog is set to
explode. The second makes apply_defdispwin user defined instead of
having it hardcoded to 1. The third avoids aborting on NALs not needed
or expected in extradata, and the last two patches make hevcdec.c use
ff_hevc_decode_extradata().
Not aborting on PS NAL failures here would technically mean a change in
behavior on the internal hevc decoder once patch five is applied, and
I'd rather no do that as part of this set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/ftp: Solve a crash bug when network occur a exception
On Tue, Apr 04, 2017 at 10:12:19PM +0800, F1 wrote: > This fixes a proble where ffmpeg would cause crash to do a seek when the > network disconnect. > The log like this: > 01-01 10:53:03.441 6580 6580 F DEBUG : backtrace: > 01-01 10:53:03.441 6580 6580 F DEBUG : #00 pc 0002942e > /system/lib/libavformat.so (ffurl_write+9) > > Signed-off-by: tiejun.peng > --- > libavformat/ftp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/ftp.c b/libavformat/ftp.c > index 0663b47..9aa7a45 100644 > --- a/libavformat/ftp.c > +++ b/libavformat/ftp.c > @@ -206,6 +206,9 @@ static int ftp_send_command(FTPContext *s, const char > *command, > if (response) > *response = NULL; > > +if (!s->conn_control) > +return AVERROR(EIO); > + > if ((err = ffurl_write(s->conn_control, command, strlen(command))) < 0) > return err; > if (!err) > -- > > Please have a look this patch, give some advice or merge it. > Thank you . applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/hevc_parse: check for parameter set decoding failure
On Wed, Apr 5, 2017 at 11:40 PM, James Almer wrote:
> On 4/3/2017 10:46 AM, James Almer wrote:
>> On 4/3/2017 7:00 AM, Michael Niedermayer wrote:
>>> On Sun, Apr 02, 2017 at 10:45:41PM -0300, James Almer wrote:
Signed-off-by: James Almer
---
libavcodec/hevc_parse.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
index 6c1138e015..028ca5afe5 100644
--- a/libavcodec/hevc_parse.c
+++ b/libavcodec/hevc_parse.c
@@ -22,7 +22,8 @@
#include "hevc_parse.h"
static int hevc_decode_nal_units(const uint8_t *buf, int buf_size,
HEVCParamSets *ps,
- int is_nalff, int nal_length_size, void
*logctx)
+ int is_nalff, int nal_length_size, int
err_recognition,
+ void *logctx)
{
int i;
int ret = 0;
@@ -38,9 +39,21 @@ static int hevc_decode_nal_units(const uint8_t *buf,
int buf_size, HEVCParamSets
/* ignore everything except parameter sets and VCL NALUs */
switch (nal->type) {
-case HEVC_NAL_VPS: ff_hevc_decode_nal_vps(&nal->gb, logctx, ps);
break;
-case HEVC_NAL_SPS: ff_hevc_decode_nal_sps(&nal->gb, logctx, ps,
1); break;
-case HEVC_NAL_PPS: ff_hevc_decode_nal_pps(&nal->gb, logctx, ps);
break;
+case HEVC_NAL_VPS:
+ret = ff_hevc_decode_nal_vps(&nal->gb, logctx, ps);
+if (ret < 0)
+goto done;
+break;
+case HEVC_NAL_SPS:
+ret = ff_hevc_decode_nal_sps(&nal->gb, logctx, ps, 1);
+if (ret < 0)
+goto done;
+break;
+case HEVC_NAL_PPS:
+ret = ff_hevc_decode_nal_pps(&nal->gb, logctx, ps);
+if (ret < 0)
+goto done;
+break;
case HEVC_NAL_TRAIL_R:
case HEVC_NAL_TRAIL_N:
case HEVC_NAL_TSA_N:
>>>
>>> I didnt investigate how exactly this is used but from just the patch
>>> this seems not optimal
>>> For example, if you have 3 PPS NALs and the first fails to decode
>>> you might still be able to fully decode the other 2
>>
>> I'm mimicking the behavior of decode_nal_unit() in hevcdec.c, which is
>> currently used during frame decoding and extradata decoding.
>> This patchset aims at removing duplicate code while keeping the hevc
>> decoder behaving the same as it was before. I could skip this change
>> if that's preferred, but if this behavior is not optimal then someone
>> who better understands the codec should look at it.
>
> To add some context, the functions in hevc_parse.c are currently used
> only by the mediacodec based hevc decoder to decode extradata, and it's
> a duplicate of existing functionality in hevcdec.c used by the internal
> hevc decoder.
>
> This set aims at putting the hevc_parse.c version on par with the
> hevcdec.c one (in the scope of extradata parsing, not frame) to share it
> between the two decoders and any other that may need it in the future.
> This patch checks for PS failures and aborts if err_recog is set to
> explode. The second makes apply_defdispwin user defined instead of
> having it hardcoded to 1. The third avoids aborting on NALs not needed
> or expected in extradata, and the last two patches make hevcdec.c use
> ff_hevc_decode_extradata().
>
> Not aborting on PS NAL failures here would technically mean a change in
> behavior on the internal hevc decoder once patch five is applied, and
> I'd rather no do that as part of this set.
>
Keeping the current behavior for the HEVC software decoder seems
ideal. If a change in behavior is wanted afterwards, it should be
dealt with in a separate change, and not this refactoring.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avutil/avstring: improve av_strreplace implement
On Wed, Apr 05, 2017 at 07:49:23PM +0200, Nicolas George wrote: > Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > > > I don't think it would cause any problems for the users in practice. > > > But we can also remove the function alltogether from the release, so > > > anybody who want's to use the function (with the new name) will only > > > have to check for a single version number. > > > Fine by me. The thing didn't even get its own bump or APIChanges > > now that i look at it, so it might as well not exist. > > It would hardly be the worst "breakage" we've gone through. > > I think removing the function from the release branch (before > actual release if possible) and renaming it in master is a good > solution. Thanks, Marton, for thinking of it. > > Steven, would you be fine with it? > > Michael? Its in no release, and there seems consensus that it shouldnt be in a release at this point, so id say remove it from release/3.3 branch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Merge of Libav's bitstream filter
On Sun, Apr 02, 2017 at 06:58:39PM +0200, Clément Bœsch wrote: [...] > Comments? Just wanted to say thanks for posting this to the ML [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Add experimental support for Opus in ISO BMFF (MP4)
On 3/15/2017 10:19 PM, Matthew Gregan wrote:
> Hi,
>
> The attached patch adds demuxing support for Opus audio codec in
> ISOBMFF/MP4. This is based on v0.6.8 of the draft spec at
> https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html.
>
> Firefox supports demuxing/playback of these files since Firefox 50.
>
>
> 0002-Add-experimental-demuxing-support-for-Opus-in-ISO-BM.patch
>
>
> From 9d6f1b4c12b08cf5fbba61bdeb31c785aa1a6a5f Mon Sep 17 00:00:00 2001
> From: Matthew Gregan
> Date: Thu, 16 Mar 2017 14:17:21 +1300
> Subject: [PATCH 2/2] Add experimental demuxing support for Opus in ISO BMFF
> (MP4).
>
> Based on the draft spec at
> http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
>
> Signed-off-by: Matthew Gregan
> ---
> libavformat/mov.c | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index d5c3949050..324d628985 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -5246,6 +5246,54 @@ static int cenc_filter(MOVContext *c, MOVStreamContext
> *sc, int64_t index, uint8
> return 0;
> }
>
> +static int mov_read_dops(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +const int OPUS_SEEK_PREROLL_MS = 80;
> +AVStream *st;
> +size_t size;
> +int16_t pre_skip;
> +
> +if (c->fc->nb_streams < 1)
> +return 0;
> +st = c->fc->streams[c->fc->nb_streams-1];
> +
> +if ((uint64_t)atom.size > (1<<30) || atom.size < 11)
> +return AVERROR_INVALIDDATA;
> +
> +/* Check OpusSpecificBox version. */
> +if (avio_r8(pb) != 0) {
> +av_log(c->fc, AV_LOG_ERROR, "unsupported OpusSpecificBox version\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +/* OpusSpecificBox size plus magic for Ogg OpusHead header. */
> +size = atom.size + 16;
This should be 8. "OpusHead" is not 16 bytes.
> +
> +if (ff_alloc_extradata(st->codecpar, size))
> +return AVERROR(ENOMEM);
> +
> +AV_WL32(st->codecpar->extradata, MKTAG('O','p','u','s'));
> +AV_WL32(st->codecpar->extradata + 4, MKTAG('H','e','a','d'));
> +AV_WB8(st->codecpar->extradata + 8, 1); /* OpusHead version */
> +avio_read(pb, st->codecpar->extradata + 9, size - 17);
Same, this should be size - 9.
> +
> +/* OpusSpecificBox is stored in big-endian, but OpusHead is
> + little-endian; aside from the preceeding magic and version they're
> + otherwise currently identical. Data after output gain at offset 16
> + doesn't need to be bytewapped. */
> +pre_skip = AV_RB16(st->codecpar->extradata + 10);
> +AV_WL16(st->codecpar->extradata + 10, pre_skip);
> +AV_WL32(st->codecpar->extradata + 12, AV_RB32(st->codecpar->extradata +
> 12));
> +AV_WL16(st->codecpar->extradata + 16, AV_RB16(st->codecpar->extradata +
> 16));
> +
> +st->codecpar->initial_padding = pre_skip;
> +st->codecpar->seek_preroll = av_rescale_q(OPUS_SEEK_PREROLL_MS,
> + (AVRational){1, 1000},
> + (AVRational){1, 48000});
> +
> +return 0;
> +}
> +
> static const MOVParseTableEntry mov_default_parse_table[] = {
> { MKTAG('A','C','L','R'), mov_read_aclr },
> { MKTAG('A','P','R','G'), mov_read_avid },
> @@ -5327,6 +5375,7 @@ static const MOVParseTableEntry
> mov_default_parse_table[] = {
> { MKTAG('d','f','L','a'), mov_read_dfla },
> { MKTAG('s','t','3','d'), mov_read_st3d }, /* stereoscopic 3D video box */
> { MKTAG('s','v','3','d'), mov_read_sv3d }, /* spherical video box */
> +{ MKTAG('d','O','p','s'), mov_read_dops },
> { 0, NULL }
> };
>
> -- 2.12.0
>
>
>
> ___
> 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] [PATCH] libavformat/mov: Fix memory leak, need to free the chapter tracks array
On Wed, Apr 05, 2017 at 01:23:31PM -0700, Thierry Foucu wrote: > --- > libavformat/mov.c | 1 + > 1 file changed, 1 insertion(+) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Add http cookie tests cases to fate
Hi, I didn't realize there was a year 2038 problem -- dates beyond it overflow a 32-bit time_t -- I've made the unit tests 32-bit compatible now. Thank you! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Add http cookie tests cases to fate
Signed-off-by: Micah Galizia
---
libavformat/Makefile | 1 +
libavformat/tests/http.c | 186 +
tests/fate/libavformat.mak | 5 ++
tests/ref/fate/http| 30
4 files changed, 222 insertions(+)
create mode 100644 libavformat/tests/http.c
create mode 100644 tests/ref/fate/http
diff --git a/libavformat/Makefile b/libavformat/Makefile
index f56ef16..a4abd1b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -597,6 +597,7 @@ SKIPHEADERS-$(CONFIG_NETWORK)+= network.h rtsp.h
TESTPROGS = seek\
url \
+http\
# async \
FIFO-MUXER-TESTPROGS-$(CONFIG_NETWORK) += fifo_muxer
diff --git a/libavformat/tests/http.c b/libavformat/tests/http.c
new file mode 100644
index 000..76a70ae
--- /dev/null
+++ b/libavformat/tests/http.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (c) 2017 Micah Galizia
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavformat/http.c"
+#include "libavformat/avio.h"
+
+typedef struct GetCookiesTestCase {
+const char *set_cookie;
+const char *cookie_str;
+const char *path;
+const char *domain;
+} GetCookiesTestCase;
+
+// Don't go past Tue, 19 Jan 2038 03:14:07 GMT or 32-bit time_t overflows
+GetCookiesTestCase get_cookies_tests[] = {
+/* Test good and expired cookie. Should be acceptable */
+{"first=\"good\"; Domain=.test.com; Path=/\nsecond=great;
domain=.test.com; path=/; HttpOnly",
+ "first=\"good\"; second=great", "/hello", "cookie.test.com"},
+
+ /* Test good and expired cookie. Should be acceptable */
+{"expired=\"really_old\"; Domain=.test.com; Expires=Thu, 01 Jan 1970
00:00:10 GMT; Path=/\ngood=not_expired; domain=.test.com; path=/; expires=Tue,
19 Jan 2038 03:14:07 GMT; HttpOnly",
+ "good=not_expired", "/hello", "cookie.test.com"},
+
+/* Test a good and expired cookie in the neulion format.
+ * Should be acceptable */
+{"expired=\"really_old\"; Domain=.test.com; Expires=Thu, 01-Jan-1970
00:00:10 GMT; Path=/\nneulion=not_expired; domain=.test.com; path=/;
expires=Tue, 19-Jan-2038 03:14:07 GMT; HttpOnly",
+ "neulion=not_expired", "/hello", "cookie.test.com"},
+
+/* Test an expiry date without the day of week specified */
+{"no_day=still_ok; domain=.test.com; path=/; expires=19 Jan 2038 03:14:07
GMT; HttpOnly",
+ "no_day=still_ok", "/hello", "cookie.test.com"},
+
+/* Test a date that cannot be parsed. Allow the cookie */
+{"unparsable_date=allow_cookie; domain=.test.com; path=/; expires=19 Jon
2038 03:14:07 GMT; HttpOnly",
+ "unparsable_date=allow_cookie", "/hello", "cookie.test.com"},
+
+/* Test a cookie that has a different domain. Do not use the cookie */
+{"different_domain=exclude; domain=.nottest.com; path=/; expires=19 Jan
2038 03:14:07 GMT; HttpOnly",
+ NULL, "/hello", "cookie.test.com"},
+
+/* Test a set-cookie that has no spaces */
+
{"no_spaces=no_big_deal;domain=.test.com;path=/;expires=Tue,19Jan203803:14:07GMT;HttpOnly",
+ "no_spaces=no_big_deal", "/hello", "cookie.test.com"},
+
+/* Test a set-cookie that has no spaces and is expired. Excluded */
+
{"no_spaces_expired=not_ok;domain=.test.com;path=/;expires=Thu01Jan197010GMT;HttpOnly",
+ NULL, "/hello", "cookie.test.com"},
+
+/* Test a set-cookie with a date that is too long. */
+{"long=handled;domain=.test.com;path=/;expires=Tue, 19 Jan 2038
03:14:07GMTGMTGMTGMTGMTGMT;HttpOnly",
+ "long=handled", "/hello", "cookie.test.com"},
+
+/* Test a set-cookie with a date that starts with too many characters */
+{"bad_start=ok;domain=.test.com;path=/;expires=BooBooBooTue, 19 Jan 2038
03:14:07;HttpOnly",
+ "bad_start=ok", "/hello", "cookie.test.com"},
+
+{NULL}
+};
+
+
+static int test_get_cookies(void)
+{
+URLContext *c = NULL;
+char *cookies = NULL;
+HTTPContext http;
+
+if (ffurl_alloc(&c, "http://test.com";, AVIO_FLAG_READ, NULL) < 0) {
+printf("Unable to allocate HTTP URL pro
Re: [FFmpeg-devel] [PATCH] flvdec: option for dropping negative CTS frames Initial frames with negative pts can produce video/audio desynchronization when a decoder is not prepared to handle negative
On Wed, 5 Apr 2017 17:15:26 -0300
Felipe Astroza wrote:
> 2017-04-05 15:35 GMT-03:00 wm4 :
>
> > On Wed, 5 Apr 2017 14:29:30 -0300
> > fel...@astroza.cl wrote:
> >
> > > From: Felipe Astroza
> > >
> > > Signed-off-by: Felipe Astroza
> > > ---
> > > libavformat/flvdec.c | 14 +++---
> > > 1 file changed, 11 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > > index 3959a36..1556fe0 100644
> > > --- a/libavformat/flvdec.c
> > > +++ b/libavformat/flvdec.c
> > > @@ -44,6 +44,7 @@
> > > typedef struct FLVContext {
> > > const AVClass *class; ///< Class for private options.
> > > int trust_metadata; ///< configure streams according onMetaData
> > > +int drop_negative_cts;///< drop frames if cts is negative
> > > int wrong_dts;///< wrong dts due to negative cts
> > > uint8_t *new_extradata[FLV_STREAM_TYPE_NB];
> > > int new_extradata_size[FLV_STREAM_TYPE_NB];
> > > @@ -1139,10 +1140,16 @@ retry_duration:
> > > int32_t cts = (avio_rb24(s->pb) + 0xff80) ^ 0xff80;
> > > pts = dts + cts;
> > > if (cts < 0) { // dts might be wrong
> > > -if (!flv->wrong_dts)
> > > +if (flv->drop_negative_cts) {
> > > av_log(s, AV_LOG_WARNING,
> > > -"Negative cts, previous timestamps might be
> > wrong.\n");
> > > -flv->wrong_dts = 1;
> > > +"Negative cts, frames will be dropped.\n");
> > > +dts = pts = AV_NOPTS_VALUE;
> > > +} else {
> > > +if (!flv->wrong_dts)
> > > +av_log(s, AV_LOG_WARNING,
> > > +"Negative cts, previous timestamps might be
> > wrong.\n");
> > > +flv->wrong_dts = 1;
> > > +}
> > > } else if (FFABS(dts - pts) > 1000*60*15) {
> > > av_log(s, AV_LOG_WARNING,
> > > "invalid timestamps %"PRId64" %"PRId64"\n", dts,
> > pts);
> > > @@ -1253,6 +1260,7 @@ static int flv_read_seek(AVFormatContext *s, int
> > stream_index,
> > > #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> > > static const AVOption options[] = {
> > > { "flv_metadata", "Allocate streams according to the onMetaData
> > array", OFFSET(trust_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> >
> > > +{ "flv_drop_negative_cts", "Drop frames with negative composition
> > timestamp", OFFSET(drop_negative_cts), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
> > 1, VD },
> > > { "missing_streams", "", OFFSET(missing_streams), AV_OPT_TYPE_INT,
> > { .i64 = 0 }, 0, 0xFF, VD | AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY },
> > > { NULL }
> > > };
> >
> > This seems all kind of wrong. You don't add a hack to a single demuxer
> > just because a single decoder can't handle unusual things in "some"
> > files. You don't add it as option either. (If this is a "fix my problem
> > the easiest way" hack, you should probably keep it in your own ffmpeg
> > branch.)
> >
> > It was the way I found to avoid the initial frames without a preceding
> keyframe (marked with pts < 0) that RTMP wowza server sends in live
> streams, just cover flv format case :/. And yes yes, you're right, this is
> a hack because of I was not able to patch QSV decoder.
>
> h264_qsv decoder -> h264_qsv encoder produces a video delayed output
> h264_qsv decoder -> libx264 encoder produces a video delayed output
> libx264 decoder -> libx264 encoder produces a right output
There's no libx264 decoder - I assume you mean ffmpeg's native decoder.
> h264_qsv is the source of my issues. I was passing -itsoffset CONSTANT(0.5
> in my case) as workaround but it works 90% of the time and I just want a
> definitive solution.
Did you check whether there's some obvious cause, like due to how qsv
represents timestamps? Also there is no reason to use the qsv
_decoder_. The native ffmpeg decoder + hwaccel will do getter. Anyway,
still legitimate to want to fix qsv, of course.
> Maybe this option do not deserve be part of master but, maybe useful for
> people trying to work with QSV transcoding
>
> Why do the negative CTS happen, and what are their semantics?
> >
> > Context: https://patches.libav.org/patch/56714/
>
> "Some streaming servers (such as wowza) send all preceding packets in
> the current GOP (to allow starting decoding immediately, instead of
> waiting for the next keyframe)"
>
> Is this just the audio delay?
>
>
> Video delay, audio goes first
That link is helpful. So in theory these frames with negative cts
should be decoded, and then discarded. I'd really look into somehow
checking if qsv can't be made to take these timestamps somehow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listin
