[FFmpeg-devel] [PATCH] FATE: Add test for libavfilter/scale2ref
This new FATE test for the scale2ref filter makes use of the recently added scale2ref-specific variables to maintain the aspect ratio of a test input. Filtergraph explanation: [main] has an AR of 4:3. [ref] has an AR of 16:9. 640 / 4 = 160. So the new width for [main] is 160. 160 / ((320 / 240) * (1 / 1)) = 160 / (4 / 3) = 120. So the new height for [main] is 120. 160 / 120 = 4 / 3 so [main]'s aspect ratio has been maintained while using [ref]'s width as a reference point. [ref] is nullsink'd since it is left unchanged by scale2ref (and so shouldn't need to be tested). If we were to use "iw/4:-1" in place of "iw/4:ow/mdar": 640 / 4 = 160. So the new width for [main] would be 160. 360 / 4 = 90. So the new height for [main] would be 90. 160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref] which is probably what you do not want. This is currently the only test for scale2ref. Signed-off-by: Kevin Mark --- tests/fate/filter-video.mak | 4 tests/filtergraphs/scale2ref_keep_aspect| 5 + tests/ref/fate/filter-scale2ref_keep_aspect | 14 ++ 3 files changed, 23 insertions(+) create mode 100644 tests/filtergraphs/scale2ref_keep_aspect create mode 100644 tests/ref/fate/filter-scale2ref_keep_aspect diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 1ca29e8d32..53fc7a6528 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -413,6 +413,10 @@ fate-filter-scale200: CMD = video_filter "scale=w=200:h=200" FATE_FILTER_VSYNTH-$(CONFIG_SCALE_FILTER) += fate-filter-scale500 fate-filter-scale500: CMD = video_filter "scale=w=500:h=500" +FATE_FILTER_VSYNTH-$(CONFIG_SCALE2REF_FILTER) += fate-filter-scale2ref_keep_aspect +fate-filter-scale2ref_keep_aspect: tests/data/filtergraphs/scale2ref_keep_aspect +fate-filter-scale2ref_keep_aspect: CMD = framemd5 -frames:v 5 -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/scale2ref_keep_aspect -map "[main]" + FATE_FILTER_VSYNTH-$(CONFIG_SCALE_FILTER) += fate-filter-scalechroma fate-filter-scalechroma: tests/data/vsynth1.yuv fate-filter-scalechroma: CMD = framecrc -flags bitexact -s 352x288 -pix_fmt yuv444p -i tests/data/vsynth1.yuv -pix_fmt yuv420p -sws_flags +bitexact -vf scale=out_v_chr_pos=33:out_h_chr_pos=151 diff --git a/tests/filtergraphs/scale2ref_keep_aspect b/tests/filtergraphs/scale2ref_keep_aspect new file mode 100644 index 00..f407460ec7 --- /dev/null +++ b/tests/filtergraphs/scale2ref_keep_aspect @@ -0,0 +1,5 @@ +sws_flags=+accurate_rnd+bitexact; +testsrc=size=320x240 [main]; +testsrc=size=640x360 [ref]; +[main][ref] scale2ref=iw/4:ow/mdar [main][ref]; +[ref] nullsink diff --git a/tests/ref/fate/filter-scale2ref_keep_aspect b/tests/ref/fate/filter-scale2ref_keep_aspect new file mode 100644 index 00..ca03277446 --- /dev/null +++ b/tests/ref/fate/filter-scale2ref_keep_aspect @@ -0,0 +1,14 @@ +#format: frame checksums +#version: 2 +#hash: MD5 +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 160x120 +#sar 0: 4/3 +#stream#, dts,pts, duration, size, hash +0, 0, 0,1,57600, 9a19c23dc3a557786840d0098606d5f1 +0, 1, 1,1,57600, e6fbdabaf1bb0d28afc648ed4d27e9f0 +0, 2, 2,1,57600, 52924ed0a751214c50fb2e7a626c8cc5 +0, 3, 3,1,57600, 67d5fd6ee71793f1cf8794d1c27afdce +0, 4, 4,1,57600, 85f7775f7b01afd369fc8919dc759d30 -- 2.13.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input
On Thu, Jun 1, 2017 at 5:37 PM, Michael Niedermayer wrote: > applied > > can you add a fate test that uses the new identifers ? > > Thanks Certainly. Submitted a patch for a scale2ref-specific test. Thanks, Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FATE: Add test for libavfilter/scale2ref
On Sun, Jun 4, 2017 at 1:23 PM, Kevin Mark wrote: > > If we were to use "iw/4:-1" in place of "iw/4:ow/mdar": > 640 / 4 = 160. So the new width for [main] would be 160. > 360 / 4 = 90. So the new height for [main] would be 90. > 160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref] > which is probably what you do not want. > Now that this feature has been applied, it may be helpful to check if one of the W/H arguments is of the form '-n' and log a warning that this will force the ref's display aspect ratio. The warning should also convey the expression to use: 'oh*mdar' or 'ow/mdar' , as the case may be. Additionally, since the output SAR will be adjusted to force the ref's DAR, it would be helpful to add a warning for that (tell users to append setsar=1 after the scale) --or-- (ideally) patch the filter so that the main's DAR is preserved. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
Le sextidi 16 prairial, an CCXXV, Daniel Kucera a écrit :
> Signed-off-by: Daniel Kucera
> ---
> libavformat/avio.c| 2 +-
> libavformat/aviobuf.c | 20
> libavformat/cache.c | 4 ++--
> libavformat/file.c| 2 ++
> libavformat/subfile.c | 2 +-
> libavformat/wtvdec.c | 4 ++--
> 6 files changed, 20 insertions(+), 14 deletions(-)
I have several qualms about this patch.
Firs, there are several direct calls to read_packet, I am not sure it
addresses all of them. I think it would be better to have a single
low-level wrapper for read_packet and use only it.
Second, these changes do not handle packet protocols. For packet
protocols, read returning 0 means an empty packet, and that must be
returned to the application. It does not mean EOF.
I suggest the following check around read_packet :
av_assert2(ret || url->max_packet_size);
if (!ret && !url->max_packet_size)
ret = AVERROR_EOF;
The av_assert2() allows debug builds to crash whenever an invalid return
value happens, making it easier to detect them. The second check allows
normal builds to run, same as before. And of course, you should be
working and running FATE at assert level 2.
It leaves a small problem for stream protocols that are thin wrappers
around another protocol that may or may not be packet : they must all
check 0 and ignore it. Fortunately, we have only a handful of thin
wrappers.
See comments below for a few details.
>
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 1e79c9dd5c..bf803016b7 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -394,7 +394,7 @@ static inline int retry_transfer_wrapper(URLContext *h,
> uint8_t *buf,
> av_usleep(1000);
> }
> } else if (ret < 1)
> -return (ret < 0 && ret != AVERROR_EOF) ? ret : len;
> +return (ret < 0) ? ret : len;
> if (ret) {
> fast_retries = FFMAX(fast_retries, 2);
> wait_since = 0;
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 1667e9f08b..3705e406d9 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -556,13 +556,14 @@ static void fill_buffer(AVIOContext *s)
> if (s->read_packet)
> len = s->read_packet(s->opaque, dst, len);
> else
> -len = 0;
> -if (len <= 0) {
> +len = AVERROR_EOF;
> +if (len == AVERROR_EOF) {
> /* do not modify buffer if EOF reached so that a seek back can
> be done without rereading data */
> s->eof_reached = 1;
> -if (len < 0)
> -s->error = len;
> +} else if (len < 0) {
> +s->eof_reached = 1;
> +s->error= len;
> } else {
> s->pos += len;
> s->buf_ptr = dst;
> @@ -630,13 +631,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
> size)
> // bypass the buffer and read data directly into buf
> if(s->read_packet)
> len = s->read_packet(s->opaque, buf, size);
> -
> -if (len <= 0) {
> + else
> +len = AVERROR_EOF;
> +if (len == AVERROR_EOF) {
> /* do not modify buffer if EOF reached so that a seek
> back can
> be done without rereading data */
> s->eof_reached = 1;
> -if(len<0)
> -s->error= len;
> +break;
> +} else if (len < 0) {
> +s->eof_reached = 1;
> +s->error= len;
> break;
> } else {
> s->pos += len;
> diff --git a/libavformat/cache.c b/libavformat/cache.c
> index 6aabca2e78..66bbbf54c9 100644
> --- a/libavformat/cache.c
> +++ b/libavformat/cache.c
> @@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf,
> int size)
> }
>
> r = ffurl_read(c->inner, buf, size);
> -if (r == 0 && size>0) {
> +if (r == AVERROR_EOF && size>0) {
> c->is_true_eof = 1;
> av_assert0(c->end >= c->logical_pos);
> }
> @@ -263,7 +263,7 @@ resolve_eof:
> if (whence == SEEK_SET)
> size = FFMIN(sizeof(tmp), pos - c->logical_pos);
> ret = cache_read(h, tmp, size);
> -if (ret == 0 && whence == SEEK_END) {
> +if (ret == AVERROR_EOF && whence == SEEK_END) {
> av_assert0(c->is_true_eof);
> goto resolve_eof;
> }
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 264542a36a..1fb83851c0 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -112,6 +112,8 @@ static int file_read(URLContext *h, unsigned char *buf,
> int size)
> ret = read(c->fd, buf, size);
> if (ret == 0 && c->follow)
> return AVERROR(EAGAIN);
> +if (ret == 0)
>
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/utils: Fix several integer overflows.
Le quintidi 15 prairial, an CCXXV, James Almer a écrit : > On 6/3/2017 9:25 PM, Michael Niedermayer wrote: > I see EINVAL more fit as an error for example if src or dst are NULL, > something that would actually be an invalid argument. > We don't currently check that, for that matter. Maybe we should... This kind of case, I call "obviously invalid use of the API", and I think in these cases, an immediate crash is way better than an error code. The crash is already what happens here, since par and codec are immediately dereferenced. An av_assert0() would make it clearer. The same goes for every cases where passing NULL makes no sense, passing an invalid value where a small set of enumerated values / flags is expected (42 instead of SEEK_SET is an obvious example), or calling a amath function outside a simple interval. We may want to introduce something like av_assert_api() to have the failure message tell explicitly that the crash is caused by a bug in the application rather than the library. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls
Le quartidi 14 prairial, an CCXXV, Michael Niedermayer a écrit : > > Notice a pattern? > yes > Security issues are found, i post a fix and people complain, No. The pattern is: you rush to produce a bad fix. > If you knew a year and a half ago about a security issue and about a > great solution to it. > How far is it from completion ? > does this cover the hls vulnerability we discussed in > the last 2 days and Can you post a patch ? I said that WE needed to look for a solution. We, collective. I, individual, do not have a solution, I only know that one exists (Perl, Windows, web browsers all have a similar mechanism) and that "fixing" the individual issues rather than designing a global solution is a waste of time. > But the real question still is, how do people prefer us to deal with > this security issue here? This one ? Ignore it but take the opportunity to start designingⁿ: a proper solution would fix it anyway. If you do anything else, I will not object to you pushing, but only if you add "--author=Sysiphus" to your git commit command. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: Check file extensions
Le quintidi 15 prairial, an CCXXV, Hendrik Leppkes a écrit : > I object to breaking a functioning protocol in the name of some > obscure social-engineering attack. I agree, this issue is negligible. As was the issue about the concat protocol. But we obviously have many similar issues all over the place, and some of them are probably worth worrying. We need to start thinking NOW about a global solution to track the origin of data and prevent leakage. Maybe something similar to Perl's taint check, or to Windows's security zones (I know nothing about them except something like that exist), or toweb browsers anti-cross-site scripting mechanisms. And that was WE, not I. I am not competent to do it alone. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/utils: Fix several integer overflows.
Hi, On Sun, Jun 4, 2017 at 6:32 AM, Nicolas George wrote: > Le quintidi 15 prairial, an CCXXV, James Almer a écrit : > > On 6/3/2017 9:25 PM, Michael Niedermayer wrote: > > I see EINVAL more fit as an error for example if src or dst are NULL, > > something that would actually be an invalid argument. > > We don't currently check that, for that matter. Maybe we should... > > This kind of case, I call "obviously invalid use of the API", and I > think in these cases, an immediate crash is way better than an error > code. The crash is already what happens here, since par and codec are > immediately dereferenced. An av_assert0() would make it clearer. > > The same goes for every cases where passing NULL makes no sense, passing > an invalid value where a small set of enumerated values / flags is > expected (42 instead of SEEK_SET is an obvious example), or calling a > amath function outside a simple interval. > > We may want to introduce something like av_assert_api() to have the > failure message tell explicitly that the crash is caused by a bug in the > application rather than the library. This reminds me of g_return_val_if_fail in glib, and in some situations it's quite sensible and helpful. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: add a custom read_packet function
On Sat, Jun 03, 2017 at 06:14:12PM -0300, James Almer wrote:
> On 6/3/2017 5:16 PM, Michael Niedermayer wrote:
> > On Sat, Jun 03, 2017 at 12:33:33AM -0300, James Almer wrote:
> >> Atempt to read and propagate only full ADTS frames and not other data,
> >> like id3v1 or APETags at the end of the file.
> >>
> >> Fixes ticket #6439.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> libavformat/aacdec.c | 42 --
> >> 1 file changed, 40 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
> >> index 5ab5197e33..aee1efe03c 100644
> >> --- a/libavformat/aacdec.c
> >> +++ b/libavformat/aacdec.c
> >> @@ -23,10 +23,11 @@
> >> #include "libavutil/intreadwrite.h"
> >> #include "avformat.h"
> >> #include "internal.h"
> >> -#include "rawdec.h"
> >> #include "id3v1.h"
> >> #include "apetag.h"
> >>
> >> +#define ADTS_HEADER_SIZE 7
> >> +
> >> static int adts_aac_probe(AVProbeData *p)
> >> {
> >> int max_frames = 0, first_frames = 0;
> >> @@ -79,6 +80,7 @@ static int adts_aac_probe(AVProbeData *p)
> >> static int adts_aac_read_header(AVFormatContext *s)
> >> {
> >> AVStream *st;
> >> +uint16_t state;
> >>
> >> st = avformat_new_stream(s, NULL);
> >> if (!st)
> >> @@ -96,18 +98,54 @@ static int adts_aac_read_header(AVFormatContext *s)
> >> avio_seek(s->pb, cur, SEEK_SET);
> >> }
> >>
> >> +// skip data until the first ADTS frame is found
> >> +state = avio_r8(s->pb);
> >> +while (!avio_feof(s->pb)) {
> >> +state = (state << 8) | avio_r8(s->pb);
> >> +if ((state >> 4) != 0xFFF)
> >> +continue;
> >> +avio_seek(s->pb, -2, SEEK_CUR);
> >> +break;
> >> +}
> >
> > this would loop forever with /dev/zero as input
>
> How can i prevent this? Maybe checking a max of
> AVFormatContext.probesize or AVFormatContext.format_probesize bytes
> before bailing out? Which one if so?
id tend toward probesize, but anything will do.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: return impaired streams in av_find_best_stream if only those exist
On Sat, 3 Jun 2017, Michael Niedermayer wrote: On Fri, Jun 02, 2017 at 11:10:13PM +0200, Marton Balint wrote: Fixes ticket #6397. Signed-off-by: Marton Balint --- libavformat/utils.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) LGTM Thanks, pushed both patches. can you add a fate test for this ? Will work on it as time permits. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/options: disable flush_packets as default
It is a huge performance improvement for encoding files with small packets
(e.g. wav) over SMB/CIFS.
Signed-off-by: Marton Balint
---
libavformat/mux.c | 4 ++--
libavformat/options_table.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index e1e49a81be..540ac56c3f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -479,7 +479,7 @@ static int write_header_internal(AVFormatContext *s)
s->internal->write_header_ret = ret;
if (ret < 0)
return ret;
-if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
+if ((s->flush_packets || s->flags & AVFMT_FLAG_FLUSH_PACKETS) && s->pb
&& s->pb->error >= 0)
avio_flush(s->pb);
}
s->internal->header_written = 1;
@@ -772,7 +772,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
if (s->pb && ret >= 0) {
-if (s->flush_packets && s->flags & AVFMT_FLAG_FLUSH_PACKETS)
+if (s->flush_packets || s->flags & AVFMT_FLAG_FLUSH_PACKETS)
avio_flush(s->pb);
if (s->pb->error < 0)
ret = s->pb->error;
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 0c1915d6d4..b72f72b845 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -39,7 +39,7 @@ static const AVOption avformat_options[] = {
{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT64, {.i64
= 500 }, 32, INT64_MAX, D},
{"formatprobesize", "number of bytes to probe file format",
OFFSET(format_probesize), AV_OPT_TYPE_INT, {.i64 = PROBE_BUF_MAX}, 0,
INT_MAX-1, D},
{"packetsize", "set packet size", OFFSET(packet_size), AV_OPT_TYPE_INT, {.i64
= DEFAULT }, 0, INT_MAX, E},
-{"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 =
AVFMT_FLAG_FLUSH_PACKETS | AVFMT_FLAG_AUTO_BSF }, INT_MIN, INT_MAX, D|E,
"fflags"},
+{"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = AVFMT_FLAG_AUTO_BSF
}, INT_MIN, INT_MAX, D|E, "fflags"},
{"flush_packets", "reduce the latency by flushing out packets immediately", 0,
AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_FLUSH_PACKETS }, INT_MIN, INT_MAX, E,
"fflags"},
{"ignidx", "ignore index", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_IGNIDX },
INT_MIN, INT_MAX, D, "fflags"},
{"genpts", "generate pts", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_GENPTS },
INT_MIN, INT_MAX, D, "fflags"},
@@ -85,7 +85,7 @@ static const AVOption avformat_options[] = {
{"use_wallclock_as_timestamps", "use wallclock as timestamps",
OFFSET(use_wallclock_as_timestamps), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, D},
{"skip_initial_bytes", "set number of bytes to skip before reading header and
frames", OFFSET(skip_initial_bytes), AV_OPT_TYPE_INT64, {.i64 = 0}, 0,
INT64_MAX-1, D},
{"correct_ts_overflow", "correct single timestamp overflows",
OFFSET(correct_ts_overflow), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, D},
-{"flush_packets", "enable flushing of the I/O context after each packet",
OFFSET(flush_packets), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, E},
+{"flush_packets", "enable flushing of the I/O context after each packet",
OFFSET(flush_packets), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E},
{"metadata_header_padding", "set number of bytes to be written as padding in a
metadata header", OFFSET(metadata_header_padding), AV_OPT_TYPE_INT, {.i64 =
-1}, -1, INT_MAX, E},
{"output_ts_offset", "set output timestamp offset", OFFSET(output_ts_offset),
AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX, INT64_MAX, E},
{"max_interleave_delta", "maximum buffering duration for interleaving",
OFFSET(max_interleave_delta), AV_OPT_TYPE_INT64, { .i64 = 1000 }, 0,
INT64_MAX, E },
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avformat/aviobuf: fix flushing buffers after seeking backwards
In the past, aviobuf only flushed buffers until the current buffer position,
even if more data was written to it previously, and a backward seek was used
to reposition the IO context.
From now, aviobuf will keep track of the written data, so no explicit seek will
be required till the end of the buffer before flushing.
This fixes at least one regression, fate-vsynth3-flv was broken if
flush_packets option was set to false, an explicit seek was removed in
4e3cc4bdd8acedbcc703607ed0efbb64bb5c3cc4.
Signed-off-by: Marton Balint
---
libavformat/avio.h| 33 ++---
libavformat/aviobuf.c | 19 +--
libavformat/version.h | 4 ++--
3 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 525eb7129e..99709d5180 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -168,8 +168,9 @@ typedef struct AVIOContext {
const AVClass *av_class;
/*
- * The following shows the relationship between buffer, buf_ptr, buf_end,
buf_size,
- * and pos, when reading and when writing (since AVIOContext is used for
both):
+ * The following shows the relationship between buffer, buf_ptr,
+ * buf_ptr_max, buf_end, buf_size, and pos, when reading and when writing
+ * (since AVIOContext is used for both):
*
**
* READING
@@ -196,21 +197,22 @@ typedef struct AVIOContext {
* WRITING
**
*
- * | buffer_size
|
- *
|---|
- * |
|
+ * | buffer_size |
+ * |--|
+ * | |
*
- * buffer buf_ptr
buf_end
- *
+---+---+
- * |/ / / / / / / / / /|
|
- * write buffer: | / to be flushed / |
|
- * |/ / / / / / / / / /|
|
- *
+---+---+
+ *buf_ptr_max
+ * buffer (buf_ptr) buf_end
+ * +---+--+
+ * |/ / / / / / / / / / / /| |
+ * write buffer: | / / to be flushed / / | |
+ * |/ / / / / / / / / / / /| |
+ * +---+--+
*
- * pos
- *
+--+---+
- * output file: | |
|
- *
+--+---+
+ *pos
+ *
+-+--+
+ * output file: | |
|
+ *
+-+--+
*
*/
unsigned char *buffer; /**< Start of the buffer. */
@@ -329,6 +331,7 @@ typedef struct AVIOContext {
int (*short_seek_get)(void *opaque);
int64_t written;
+unsigned char *buf_ptr_max; /**< Maximum reached position in the write
buffer, used for flushing already written data */
} AVIOContext;
/**
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 1667e9f08b..7d1b385253 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -91,6 +91,7 @@ int ffio_init_context(AVIOContext *s,
s->orig_buffer_size =
s->buffer_size = buffer_size;
s->buf_ptr = buffer;
+s->buf_ptr_max = buffer;
s->opaque = opaque;
s->direct = 0;
@@ -171,15 +172,15 @@ static void writeout(AVIOContext *s, const uint8_t *data,
int len)
static void flush_buffer(AVIOContext *s)
{
-if (s->write_flag && s->buf_ptr > s->buffer) {
-writeout(s, s->buffer, s->buf_ptr - s->buffer);
+if (s->write_flag && s->buf_ptr_max > s->buffer) {
+writeout(s, s->buffer, s->buf_ptr_max - s->buffer);
if (s->update_checksum) {
s->checksum = s->update_chec
[FFmpeg-devel] [PATCH 3/3] avformat/aviobuf: increase buffer size to 128k
Another huge performance improvement when using SMB/CIFS as output. Signed-off-by: Marton Balint --- libavformat/aviobuf.c | 2 +- tests/ref/seek/lavf-alaw | 3 +-- tests/ref/seek/lavf-mulaw | 3 +-- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c index 7d1b385253..36eb093a3a 100644 --- a/libavformat/aviobuf.c +++ b/libavformat/aviobuf.c @@ -33,7 +33,7 @@ #include "url.h" #include -#define IO_BUFFER_SIZE 32768 +#define IO_BUFFER_SIZE 131072 /** * Do seeks within this distance ahead of the current buffer by skipping diff --git a/tests/ref/seek/lavf-alaw b/tests/ref/seek/lavf-alaw index 4b1f8fbc02..d8e99b6957 100644 --- a/tests/ref/seek/lavf-alaw +++ b/tests/ref/seek/lavf-alaw @@ -15,8 +15,7 @@ ret: 0 st: 0 flags:0 ts: 0.364989 ret: 0 st: 0 flags:1 dts: 0.364989 pts: 0.364989 pos: 8048 size: 1024 ret: 0 st: 0 flags:1 ts:-0.740816 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 0 size: 1024 -ret: 0 st:-1 flags:0 ts: 2.153336 -ret:-EOF +ret:-1 st:-1 flags:0 ts: 2.153336 ret: 0 st:-1 flags:1 ts: 1.047503 ret: 0 st: 0 flags:1 dts: 1.047483 pts: 1.047483 pos: 23097 size: 1024 ret: 0 st: 0 flags:0 ts:-0.058322 diff --git a/tests/ref/seek/lavf-mulaw b/tests/ref/seek/lavf-mulaw index 4b1f8fbc02..d8e99b6957 100644 --- a/tests/ref/seek/lavf-mulaw +++ b/tests/ref/seek/lavf-mulaw @@ -15,8 +15,7 @@ ret: 0 st: 0 flags:0 ts: 0.364989 ret: 0 st: 0 flags:1 dts: 0.364989 pts: 0.364989 pos: 8048 size: 1024 ret: 0 st: 0 flags:1 ts:-0.740816 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 0 size: 1024 -ret: 0 st:-1 flags:0 ts: 2.153336 -ret:-EOF +ret:-1 st:-1 flags:0 ts: 2.153336 ret: 0 st:-1 flags:1 ts: 1.047503 ret: 0 st: 0 flags:1 dts: 1.047483 pts: 1.047483 pos: 23097 size: 1024 ret: 0 st: 0 flags:0 ts:-0.058322 -- 2.12.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/vp9 ipred_dl_32x32_16 avx2 version
vp9_diag_downleft_32x32_8bpp_c: 580.2 vp9_diag_downleft_32x32_8bpp_sse2: 75.6 vp9_diag_downleft_32x32_8bpp_ssse3: 73.7 vp9_diag_downleft_32x32_8bpp_avx: 72.7 vp9_diag_downleft_32x32_10bpp_c: 1101.2 vp9_diag_downleft_32x32_10bpp_sse2: 145.4 vp9_diag_downleft_32x32_10bpp_ssse3: 137.5 vp9_diag_downleft_32x32_10bpp_avx: 134.8 vp9_diag_downleft_32x32_10bpp_avx2: 94.0 vp9_diag_downleft_32x32_12bpp_c: 1108.5 vp9_diag_downleft_32x32_12bpp_sse2: 145.5 vp9_diag_downleft_32x32_12bpp_ssse3: 137.3 vp9_diag_downleft_32x32_12bpp_avx: 135.2 vp9_diag_downleft_32x32_12bpp_avx2: 94.0 ~30% faster than avx --- libavcodec/x86/vp9dsp_init_16bpp.c| 4 +- libavcodec/x86/vp9intrapred_16bpp.asm | 75 +++ 2 files changed, 60 insertions(+), 19 deletions(-) diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c b/libavcodec/x86/vp9dsp_init_16bpp.c index 4e1f24f..d1b8fcd 100644 --- a/libavcodec/x86/vp9dsp_init_16bpp.c +++ b/libavcodec/x86/vp9dsp_init_16bpp.c @@ -52,7 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); decl_ipred_fns(dc_top, 16, mmxext, sse2); decl_ipred_fns(dc_left, 16, mmxext, sse2); decl_ipred_fn(dl, 16, 16, avx2); -decl_ipred_fn(dl, 32, 32, avx2); +decl_ipred_fn(dl, 32, 16, avx2); #define decl_ipred_dir_funcs(type) \ decl_ipred_fns(type, 16, sse2, sse2); \ @@ -136,7 +136,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp) init_fpel_func(1, 1, 64, avg, _16, avx2); init_fpel_func(0, 1, 128, avg, _16, avx2); init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); -init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 32, avx2); +init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); } #endif /* HAVE_YASM */ diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm b/libavcodec/x86/vp9intrapred_16bpp.asm index 2ec5381..10a0994 100644 --- a/libavcodec/x86/vp9intrapred_16bpp.asm +++ b/libavcodec/x86/vp9intrapred_16bpp.asm @@ -861,6 +861,7 @@ cglobal vp9_ipred_dl_16x16_16, 2, 4, 5, dst, stride, l, a DEFINE_ARGS dst, stride, stride3, cnt mov cntd, 2 lea stride3q, [strideq*3] + .loop: mova [dstq+strideq*0], m0 vpalignrm3, m2, m0, 2 @@ -887,24 +888,64 @@ cglobal vp9_ipred_dl_16x16_16, 2, 4, 5, dst, stride, l, a cglobal vp9_ipred_dl_32x32_16, 2, 6, 7, dst, stride, l, a movifnidn aq, amp -movam0, [aq+mmsize*0] ; abcdefghijklmnop -movam1, [aq+mmsize*1] ; qrstuvwxyz012345 -vpbroadcastw xm4, [aq+mmsize*1+30]; -vpalignrm2, m1, m0, 2 ; bcdefghijklmnopq -vpalignrm3, m1, m0, 4 ; cdefghijklmnopqr -vperm2i128 m5, m1, m4, q0201 ; yz012345 -LOWPASS 0, 2, 3 ; BCDEFGHIJKLMNOPQ -vpalignrm2, m5, m1, 2 ; rstuvwxyz0123455 -vpalignrm3, m5, m1, 4 ; stuvwxyz01234555 -LOWPASS 1, 2, 3 ; RSTUVWXYZ..5 -vperm2i128 m2, m1, m4, q0201 ; Z..5 +movam0, [aq+mmsize*0+ 0] ; abcdefghijklmnop +movam1, [aq+mmsize*1+ 0] ; qrstuvwxyz012345 +vpbroadcastw xm4, [aq+mmsize*1+30] ; +vperm2i128 m5, m0, m1, q0201 ; ijklmnopqrstuvwx +vpalignrm2, m5, m0, 2 ; bcdefghijklmnopq +vpalignrm3, m5, m0, 4 ; cdefghijklmnopqr +LOWPASS 0, 2, 3 ; BCDEFGHIJKLMNOPQ +vperm2i128 m5, m1, m4, q0201 ; yz012345 +vpalignrm2, m5, m1, 2 ; rstuvwxyz0123455 +vpalignrm3, m5, m1, 4 ; stuvwxyz01234555 +LOWPASS 1, 2, 3 ; RSTUVWXYZ..5 +vperm2i128 m2, m1, m4, q0201 ; Z..5 +vperm2i128 m5, m0, m1, q0201 ; JKLMNOPQRSTUVWXY +DEFINE_ARGS dst, stride, stride3, stride5, cnt +lea stride3q, [strideq*3] +lea stride5q, [strideq*5] +mov cntd, 4 -mova [dstq+strideq*0+0 ], m0 -mova [dstq+strideq*0+32], m1 -vpalignrm3, m1, m0, 2 -vpalignrm4, m2, m1, 2 -mova [dstq+strideq*1+0 ], m3 -mova [dstq+strideq*1+32], m4 +.loop: +mova [dstq+strideq*0 + 0], m0 +mova [dstq+strideq*0 +32], m1 +vpalignr m3, m5, m0, 2 +vpalignr m4, m2, m1, 2 +mova [dstq+strideq*1 + 0], m3 +mova [dstq+strideq*1 +32], m4 +vpalignr m3, m5, m0, 4 +vpalignr m4, m2, m1, 4 +mova [dstq+strideq*2 + 0], m3 +mova [dstq+strideq*2 +32], m4 +vpa
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: add a custom read_packet function
On 6/4/2017 8:44 AM, Michael Niedermayer wrote:
> On Sat, Jun 03, 2017 at 06:14:12PM -0300, James Almer wrote:
>> On 6/3/2017 5:16 PM, Michael Niedermayer wrote:
>>> On Sat, Jun 03, 2017 at 12:33:33AM -0300, James Almer wrote:
Atempt to read and propagate only full ADTS frames and not other data,
like id3v1 or APETags at the end of the file.
Fixes ticket #6439.
It's ticket 6437, sorry. Amended locally.
Signed-off-by: James Almer
---
libavformat/aacdec.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index 5ab5197e33..aee1efe03c 100644
--- a/libavformat/aacdec.c
+++ b/libavformat/aacdec.c
@@ -23,10 +23,11 @@
#include "libavutil/intreadwrite.h"
#include "avformat.h"
#include "internal.h"
-#include "rawdec.h"
#include "id3v1.h"
#include "apetag.h"
+#define ADTS_HEADER_SIZE 7
+
static int adts_aac_probe(AVProbeData *p)
{
int max_frames = 0, first_frames = 0;
@@ -79,6 +80,7 @@ static int adts_aac_probe(AVProbeData *p)
static int adts_aac_read_header(AVFormatContext *s)
{
AVStream *st;
+uint16_t state;
st = avformat_new_stream(s, NULL);
if (!st)
@@ -96,18 +98,54 @@ static int adts_aac_read_header(AVFormatContext *s)
avio_seek(s->pb, cur, SEEK_SET);
}
+// skip data until the first ADTS frame is found
+state = avio_r8(s->pb);
+while (!avio_feof(s->pb)) {
+state = (state << 8) | avio_r8(s->pb);
+if ((state >> 4) != 0xFFF)
+continue;
+avio_seek(s->pb, -2, SEEK_CUR);
+break;
+}
>>>
>>> this would loop forever with /dev/zero as input
>>
>> How can i prevent this? Maybe checking a max of
>> AVFormatContext.probesize or AVFormatContext.format_probesize bytes
>> before bailing out? Which one if so?
>
> id tend toward probesize, but anything will do.
>
> thx
Done and pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-04 12:25 GMT+02:00 Nicolas George :
> Le sextidi 16 prairial, an CCXXV, Daniel Kucera a écrit :
>> Signed-off-by: Daniel Kucera
>> ---
>> libavformat/avio.c| 2 +-
>> libavformat/aviobuf.c | 20
>> libavformat/cache.c | 4 ++--
>> libavformat/file.c| 2 ++
>> libavformat/subfile.c | 2 +-
>> libavformat/wtvdec.c | 4 ++--
>> 6 files changed, 20 insertions(+), 14 deletions(-)
>
> I have several qualms about this patch.
>
> Firs, there are several direct calls to read_packet, I am not sure it
> addresses all of them. I think it would be better to have a single
> low-level wrapper for read_packet and use only it.
>
> Second, these changes do not handle packet protocols. For packet
> protocols, read returning 0 means an empty packet, and that must be
> returned to the application. It does not mean EOF.
>
> I suggest the following check around read_packet :
>
> av_assert2(ret || url->max_packet_size);
> if (!ret && !url->max_packet_size)
> ret = AVERROR_EOF;
>
> The av_assert2() allows debug builds to crash whenever an invalid return
> value happens, making it easier to detect them. The second check allows
> normal builds to run, same as before. And of course, you should be
> working and running FATE at assert level 2.
>
> It leaves a small problem for stream protocols that are thin wrappers
> around another protocol that may or may not be packet : they must all
> check 0 and ignore it. Fortunately, we have only a handful of thin
> wrappers.
>
> See comments below for a few details.
>
>>
>> diff --git a/libavformat/avio.c b/libavformat/avio.c
>> index 1e79c9dd5c..bf803016b7 100644
>> --- a/libavformat/avio.c
>> +++ b/libavformat/avio.c
>> @@ -394,7 +394,7 @@ static inline int retry_transfer_wrapper(URLContext *h,
>> uint8_t *buf,
>> av_usleep(1000);
>> }
>> } else if (ret < 1)
>> -return (ret < 0 && ret != AVERROR_EOF) ? ret : len;
>> +return (ret < 0) ? ret : len;
>> if (ret) {
>> fast_retries = FFMAX(fast_retries, 2);
>> wait_since = 0;
>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
>> index 1667e9f08b..3705e406d9 100644
>> --- a/libavformat/aviobuf.c
>> +++ b/libavformat/aviobuf.c
>> @@ -556,13 +556,14 @@ static void fill_buffer(AVIOContext *s)
>> if (s->read_packet)
>> len = s->read_packet(s->opaque, dst, len);
>> else
>> -len = 0;
>> -if (len <= 0) {
>> +len = AVERROR_EOF;
>> +if (len == AVERROR_EOF) {
>> /* do not modify buffer if EOF reached so that a seek back can
>> be done without rereading data */
>> s->eof_reached = 1;
>> -if (len < 0)
>> -s->error = len;
>> +} else if (len < 0) {
>> +s->eof_reached = 1;
>> +s->error= len;
>> } else {
>> s->pos += len;
>> s->buf_ptr = dst;
>> @@ -630,13 +631,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
>> size)
>> // bypass the buffer and read data directly into buf
>> if(s->read_packet)
>> len = s->read_packet(s->opaque, buf, size);
>> -
>> -if (len <= 0) {
>> + else
>> +len = AVERROR_EOF;
>> +if (len == AVERROR_EOF) {
>> /* do not modify buffer if EOF reached so that a seek
>> back can
>> be done without rereading data */
>> s->eof_reached = 1;
>> -if(len<0)
>> -s->error= len;
>> +break;
>> +} else if (len < 0) {
>> +s->eof_reached = 1;
>> +s->error= len;
>> break;
>> } else {
>> s->pos += len;
>> diff --git a/libavformat/cache.c b/libavformat/cache.c
>> index 6aabca2e78..66bbbf54c9 100644
>> --- a/libavformat/cache.c
>> +++ b/libavformat/cache.c
>> @@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf,
>> int size)
>> }
>>
>> r = ffurl_read(c->inner, buf, size);
>> -if (r == 0 && size>0) {
>> +if (r == AVERROR_EOF && size>0) {
>> c->is_true_eof = 1;
>> av_assert0(c->end >= c->logical_pos);
>> }
>> @@ -263,7 +263,7 @@ resolve_eof:
>> if (whence == SEEK_SET)
>> size = FFMIN(sizeof(tmp), pos - c->logical_pos);
>> ret = cache_read(h, tmp, size);
>> -if (ret == 0 && whence == SEEK_END) {
>> +if (ret == AVERROR_EOF && whence == SEEK_END) {
>> av_assert0(c->is_true_eof);
>> goto resolve_eof;
>> }
>> diff --git a/libavformat/file.c b/libavformat/file.c
>> index 264542a36a..1fb83851c0 100644
>> --- a/libavformat/file.c
>> +++ b/libavformat/file.c
>> @@ -112,6 +112,8 @@ static
[FFmpeg-devel] [PATCH] fate: add fate-adts-id3v1-demux
This test the demuxer discarding non ADTS frames at the beginning and end of the input. As a side effect, this commit also enables fate-adts-demux, which was accidentally disabled in 324f0fbff1245f9e9e1dda29ecb03138a2de287d. Signed-off-by: James Almer --- Sample is in http://0x0.st/6gI.aac Should be renamed to id3v1.aac and placed in the aac folder. tests/fate/demux.mak| 3 ++- tests/ref/fate/adts-id3v1-demux | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/adts-id3v1-demux diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak index cf69e2fe2c..f3e054f90b 100644 --- a/tests/fate/demux.mak +++ b/tests/fate/demux.mak @@ -1,8 +1,9 @@ FATE_SAMPLES_DEMUX-$(call DEMDEC, AVI, FRAPS) += fate-avio-direct fate-avio-direct: CMD = framecrc -avioflags direct -i $(TARGET_SAMPLES)/fraps/fraps-v5-bouncing-balls-partial.avi -avioflags direct -FATE_SAMPLES_DEMUX-$(DEMDEC, AAC, AAC) += fate-adts-demux +FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux fate-adts-id3v1-demux fate-adts-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/ct_faac-adts.aac -acodec copy +fate-adts-id3v1-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/id3v1.aac -acodec copy FATE_SAMPLES_DEMUX-$(CONFIG_AEA_DEMUXER) += fate-aea-demux fate-aea-demux: CMD = crc -i $(TARGET_SAMPLES)/aea/chirp.aea -acodec copy diff --git a/tests/ref/fate/adts-id3v1-demux b/tests/ref/fate/adts-id3v1-demux new file mode 100644 index 00..f201d80bcd --- /dev/null +++ b/tests/ref/fate/adts-id3v1-demux @@ -0,0 +1 @@ +CRC=0x302a4a48 -- 2.13.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add test for the Dirac low delay profile
--- tests/fate/video.mak | 3 +++ tests/ref/fate/dirac-low-delay | 7 +++ 2 files changed, 10 insertions(+) create mode 100644 tests/ref/fate/dirac-low-delay diff --git a/tests/fate/video.mak b/tests/fate/video.mak index 5a64e6f9e4..d1d35335f2 100644 --- a/tests/fate/video.mak +++ b/tests/fate/video.mak @@ -108,6 +108,9 @@ fate-deluxepaint-anm: CMD = framecrc -i $(TARGET_SAMPLES)/deluxepaint-anm/INTRO1 FATE_VIDEO-$(call DEMDEC, DIRAC, DIRAC) += fate-dirac fate-dirac: CMD = framecrc -i $(TARGET_SAMPLES)/dirac/vts.profile-main.drc +FATE_VIDEO-$(call DEMDEC, DIRAC, DIRAC) += fate-dirac-low-delay +fate-dirac-low-delay: CMD = framecrc -i $(TARGET_SAMPLES)/dirac/vts.profile-vc2-low-delay.drc + FATE_DXA += fate-dxa-feeble fate-dxa-feeble: CMD = framecrc -i $(TARGET_SAMPLES)/dxa/meetsquid.dxa -t 2 -pix_fmt rgb24 -an diff --git a/tests/ref/fate/dirac-low-delay b/tests/ref/fate/dirac-low-delay new file mode 100644 index 00..13bf8e8517 --- /dev/null +++ b/tests/ref/fate/dirac-low-delay @@ -0,0 +1,7 @@ +#tb 0: 1/30 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 1/1 +0, 0, 0,1, 115200, 0x2599a172 +0, 1, 1,1, 115200, 0x08a8c08d -- 2.13.0.506.g27d5fe0cd ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/vp9: ipred_dl_32x32_16 avx2 implementation
vp9_diag_downleft_32x32_8bpp_c: 580.2 vp9_diag_downleft_32x32_8bpp_sse2: 75.6 vp9_diag_downleft_32x32_8bpp_ssse3: 73.7 vp9_diag_downleft_32x32_8bpp_avx: 72.7 vp9_diag_downleft_32x32_10bpp_c: 1101.2 vp9_diag_downleft_32x32_10bpp_sse2: 145.4 vp9_diag_downleft_32x32_10bpp_ssse3: 137.5 vp9_diag_downleft_32x32_10bpp_avx: 134.8 vp9_diag_downleft_32x32_10bpp_avx2: 94.0 vp9_diag_downleft_32x32_12bpp_c: 1108.5 vp9_diag_downleft_32x32_12bpp_sse2: 145.5 vp9_diag_downleft_32x32_12bpp_ssse3: 137.3 vp9_diag_downleft_32x32_12bpp_avx: 135.2 vp9_diag_downleft_32x32_12bpp_avx2: 94.0 ~30% faster than avx implementation --- libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++ libavcodec/x86/vp9intrapred_16bpp.asm | 63 +++ 2 files changed, 65 insertions(+) diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c b/libavcodec/x86/vp9dsp_init_16bpp.c index 4576ff1..d1b8fcd 100644 --- a/libavcodec/x86/vp9dsp_init_16bpp.c +++ b/libavcodec/x86/vp9dsp_init_16bpp.c @@ -52,6 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); decl_ipred_fns(dc_top, 16, mmxext, sse2); decl_ipred_fns(dc_left, 16, mmxext, sse2); decl_ipred_fn(dl, 16, 16, avx2); +decl_ipred_fn(dl, 32, 16, avx2); #define decl_ipred_dir_funcs(type) \ decl_ipred_fns(type, 16, sse2, sse2); \ @@ -135,6 +136,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp) init_fpel_func(1, 1, 64, avg, _16, avx2); init_fpel_func(0, 1, 128, avg, _16, avx2); init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); +init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); } #endif /* HAVE_YASM */ diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm b/libavcodec/x86/vp9intrapred_16bpp.asm index 212e413..5cd6a3e 100644 --- a/libavcodec/x86/vp9intrapred_16bpp.asm +++ b/libavcodec/x86/vp9intrapred_16bpp.asm @@ -861,6 +861,7 @@ cglobal vp9_ipred_dl_16x16_16, 2, 4, 5, dst, stride, l, a DEFINE_ARGS dst, stride, stride3, cnt mov cntd, 2 lea stride3q, [strideq*3] + .loop: mova [dstq+strideq*0], m0 vpalignrm3, m2, m0, 2 @@ -884,6 +885,68 @@ cglobal vp9_ipred_dl_16x16_16, 2, 4, 5, dst, stride, l, a dec cntd jg .loop RET + +cglobal vp9_ipred_dl_32x32_16, 2, 6, 7, dst, stride, l, a +movifnidn aq, amp +movam0, [aq+mmsize*0+ 0] ; abcdefghijklmnop +movam1, [aq+mmsize*1+ 0] ; qrstuvwxyz012345 +vpbroadcastw xm4, [aq+mmsize*1+30] ; +vperm2i128 m5, m0, m1, q0201 ; ijklmnopqrstuvwx +vpalignrm2, m5, m0, 2 ; bcdefghijklmnopq +vpalignrm3, m5, m0, 4 ; cdefghijklmnopqr +LOWPASS 0, 2, 3 ; BCDEFGHIJKLMNOPQ +vperm2i128 m5, m1, m4, q0201 ; yz012345 +vpalignrm2, m5, m1, 2 ; rstuvwxyz0123455 +vpalignrm3, m5, m1, 4 ; stuvwxyz01234555 +LOWPASS 1, 2, 3 ; RSTUVWXYZ..5 +vperm2i128 m2, m1, m4, q0201 ; Z..5 +vperm2i128 m5, m0, m1, q0201 ; JKLMNOPQRSTUVWXY +DEFINE_ARGS dst, stride, stride3, cnt +lea stride3q, [strideq*3] +mov cntd, 4 + +.loop: +mova [dstq+strideq*0 + 0], m0 +mova [dstq+strideq*0 +32], m1 +vpalignr m3, m5, m0, 2 +vpalignr m4, m2, m1, 2 +mova [dstq+strideq*1 + 0], m3 +mova [dstq+strideq*1 +32], m4 +vpalignr m3, m5, m0, 4 +vpalignr m4, m2, m1, 4 +mova [dstq+strideq*2 + 0], m3 +mova [dstq+strideq*2 +32], m4 +vpalignr m3, m5, m0, 6 +vpalignr m4, m2, m1, 6 +mova [dstq+stride3q*1+ 0], m3 +mova [dstq+stride3q*1+32], m4 +leadstq, [dstq+strideq*4] +vpalignr m3, m5, m0, 8 +vpalignr m4, m2, m1, 8 +mova [dstq+strideq*0 + 0], m3 +mova [dstq+strideq*0 +32], m4 +vpalignr m3, m5, m0, 10 +vpalignr m4, m2, m1, 10 +mova [dstq+strideq*1 + 0], m3 +mova [dstq+strideq*1 +32], m4 +vpalignr m3, m5, m0, 12 +vpalignr m4, m2, m1, 12 +mova [dstq+strideq*2+ 0], m3 +mova [dstq+strideq*2+32], m4 +vpalignr m3, m5, m0, 14 +vpalignr m4, m2, m1, 14 +mova [dstq+stride3q+ 0], m3 +mova [dstq+stride3q+ 32], m4 +vpalignr m3, m5, m0, 16 +vpalignr m4, m2, m1, 16 +vperm2i128 m5, m3, m4, q0201 +vperm2i128 m2, m4, m4, q0101 +mova m0, m3 +mova m1, m4 +
Re: [FFmpeg-devel] [PATCH] fate: add fate-adts-id3v1-demux
On 6/4/2017 1:08 PM, James Almer wrote: > This test the demuxer discarding non ADTS frames at the beginning and > end of the input. > > As a side effect, this commit also enables fate-adts-demux, which was > accidentally disabled in 324f0fbff1245f9e9e1dda29ecb03138a2de287d. > > Signed-off-by: James Almer > --- > Sample is in http://0x0.st/6gI.aac I could instead use a smaller sample (with say 10 or so frames) to use framecrc instead of crc and not end up with a huge ref file, but such a small sample with garbage data before the first adts frame ends up having a probing score of 1. According to lcov there's already a test with a file that also probes with a score of 1, so should i assume it's safe or would it be too fragile? Worst case I could just force the aac demuxer in the test i guess. > > Should be renamed to id3v1.aac and placed in the aac folder. > > tests/fate/demux.mak| 3 ++- > tests/ref/fate/adts-id3v1-demux | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/fate/adts-id3v1-demux > > diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak > index cf69e2fe2c..f3e054f90b 100644 > --- a/tests/fate/demux.mak > +++ b/tests/fate/demux.mak > @@ -1,8 +1,9 @@ > FATE_SAMPLES_DEMUX-$(call DEMDEC, AVI, FRAPS) += fate-avio-direct > fate-avio-direct: CMD = framecrc -avioflags direct -i > $(TARGET_SAMPLES)/fraps/fraps-v5-bouncing-balls-partial.avi -avioflags direct > > -FATE_SAMPLES_DEMUX-$(DEMDEC, AAC, AAC) += fate-adts-demux > +FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux > fate-adts-id3v1-demux > fate-adts-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/ct_faac-adts.aac -acodec > copy > +fate-adts-id3v1-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/id3v1.aac -acodec > copy > > FATE_SAMPLES_DEMUX-$(CONFIG_AEA_DEMUXER) += fate-aea-demux > fate-aea-demux: CMD = crc -i $(TARGET_SAMPLES)/aea/chirp.aea -acodec copy > diff --git a/tests/ref/fate/adts-id3v1-demux b/tests/ref/fate/adts-id3v1-demux > new file mode 100644 > index 00..f201d80bcd > --- /dev/null > +++ b/tests/ref/fate/adts-id3v1-demux > @@ -0,0 +1 @@ > +CRC=0x302a4a48 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/aviobuf: increase buffer size to 128k
On Sun, Jun 04, 2017 at 03:35:07PM +0200, Marton Balint wrote: > Another huge performance improvement when using SMB/CIFS as output. > > Signed-off-by: Marton Balint > --- > libavformat/aviobuf.c | 2 +- > tests/ref/seek/lavf-alaw | 3 +-- > tests/ref/seek/lavf-mulaw | 3 +-- > 3 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c > index 7d1b385253..36eb093a3a 100644 > --- a/libavformat/aviobuf.c > +++ b/libavformat/aviobuf.c > @@ -33,7 +33,7 @@ > #include "url.h" > #include > > -#define IO_BUFFER_SIZE 32768 > +#define IO_BUFFER_SIZE 131072 > this is changed for all protocols not just the ones tested. also i remember some patch that changes te buffer size for some protocols, not sure what happened to that. and theres the short_seek stuff, it might make sense to adjust that too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add test for the Dirac low delay profile
On Sun, Jun 04, 2017 at 06:03:36PM +0100, Rostislav Pehlivanov wrote: > --- > tests/fate/video.mak | 3 +++ > tests/ref/fate/dirac-low-delay | 7 +++ > 2 files changed, 10 insertions(+) > create mode 100644 tests/ref/fate/dirac-low-delay test passes on linux x86 32/64 arm, mips and mingw32/64 thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/aviobuf: increase buffer size to 128k
On Mon, 5 Jun 2017, Michael Niedermayer wrote: On Sun, Jun 04, 2017 at 03:35:07PM +0200, Marton Balint wrote: Another huge performance improvement when using SMB/CIFS as output. Signed-off-by: Marton Balint --- libavformat/aviobuf.c | 2 +- tests/ref/seek/lavf-alaw | 3 +-- tests/ref/seek/lavf-mulaw | 3 +-- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c index 7d1b385253..36eb093a3a 100644 --- a/libavformat/aviobuf.c +++ b/libavformat/aviobuf.c @@ -33,7 +33,7 @@ #include "url.h" #include -#define IO_BUFFER_SIZE 32768 +#define IO_BUFFER_SIZE 131072 this is changed for all protocols not just the ones tested. also i remember some patch that changes te buffer size for some protocols, not sure what happened to that. and theres the short_seek stuff, it might make sense to adjust that too A less intrusive approach is to set the buffer size for the file protocol only and only if a file is opened for writing. In that case, the fate test resuls will remain the same as well. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add fate-adts-id3v1-demux
On Sun, Jun 04, 2017 at 01:08:39PM -0300, James Almer wrote: > This test the demuxer discarding non ADTS frames at the beginning and > end of the input. > > As a side effect, this commit also enables fate-adts-demux, which was > accidentally disabled in 324f0fbff1245f9e9e1dda29ecb03138a2de287d. > > Signed-off-by: James Almer > --- > Sample is in http://0x0.st/6gI.aac uploaded, we can change it though if a smaller file is wanted before the test is pushed test passes on linux x86 32/64 arm, mips and mingw32/64 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FATE: Add test for libavfilter/scale2ref
On Sun, Jun 04, 2017 at 03:53:31AM -0400, Kevin Mark wrote: > This new FATE test for the scale2ref filter makes use of the recently > added scale2ref-specific variables to maintain the aspect ratio of a > test input. > > Filtergraph explanation: > [main] has an AR of 4:3. [ref] has an AR of 16:9. > 640 / 4 = 160. So the new width for [main] is 160. > 160 / ((320 / 240) * (1 / 1)) = 160 / (4 / 3) = 120. So the new > height for [main] is 120. > 160 / 120 = 4 / 3 so [main]'s aspect ratio has been maintained while > using [ref]'s width as a reference point. > > [ref] is nullsink'd since it is left unchanged by scale2ref (and so > shouldn't need to be tested). > > If we were to use "iw/4:-1" in place of "iw/4:ow/mdar": > 640 / 4 = 160. So the new width for [main] would be 160. > 360 / 4 = 90. So the new height for [main] would be 90. > 160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref] > which is probably what you do not want. > > This is currently the only test for scale2ref. > > Signed-off-by: Kevin Mark > --- > tests/fate/filter-video.mak | 4 > tests/filtergraphs/scale2ref_keep_aspect| 5 + > tests/ref/fate/filter-scale2ref_keep_aspect | 14 ++ > 3 files changed, 23 insertions(+) > create mode 100644 tests/filtergraphs/scale2ref_keep_aspect > create mode 100644 tests/ref/fate/filter-scale2ref_keep_aspect applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V2] lavc/golomb: Fix UE golomb overwrite issue.
V2: Add Add set_ue_golomb_long() to support 32bits UE golomb and update the
unit test.
From 6fe36e4e2a41f70e2a41c5eba90b5143b4eeba7b Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Fri, 2 Jun 2017 15:05:49 +0800
Subject: [PATCH V2] lavc/golomb: Fix UE golomb overwrite issue.
put_bits just support write up to 31 bits, when write 32 bit in
put_bits, it's will overwrite the bit buffer, because the default
assert level is 0, the av_assert2(n <= 31 && value < (1U << n))
in put_bits can not be trigger runtime. Add set_ue_golomb_long()
to support 32bits UE golomb.
Signed-off-by: Jun Zhao
---
libavcodec/golomb.h | 20 +++-
libavcodec/put_bits.h | 35 +++
libavcodec/tests/golomb.c | 19 +++
3 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 0833aff468..47ab884282 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -458,7 +458,7 @@ static inline int get_te(GetBitContext *s, int r, char
*file, const char *func,
#endif /* TRACE */
/**
- * write unsigned exp golomb code.
+ * write unsigned exp golomb code. 2^16-2 at most.
*/
static inline void set_ue_golomb(PutBitContext *pb, int i)
{
@@ -473,6 +473,24 @@ static inline void set_ue_golomb(PutBitContext *pb, int i)
}
/**
+ * write unsigned exp golomb code. 2^32-2 at most.
+ */
+static inline void set_ue_golomb_long(PutBitContext *pb, uint32_t i)
+{
+av_assert2(i <= (0x - 2));
+
+if (i < 256)
+put_bits(pb, ff_ue_golomb_len[i], i + 1);
+else {
+int e = av_log2(i + 1);
+if (e < 16)
+put_bits(pb, 2 * e + 1, i + 1);
+else
+put_bits64(pb, 2 * e + 1, i + 1);
+}
+}
+
+/**
* write truncated unsigned exp golomb code.
*/
static inline void set_te_golomb(PutBitContext *pb, int i, int range)
diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 68ed391195..06f0ebbeba 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -221,6 +221,41 @@ static void av_unused put_bits32(PutBitContext *s,
uint32_t value)
}
/**
+ * Write up to 64 bits into a bitstream.
+ */
+static inline void put_bits64(PutBitContext *s, int n, uint64_t value)
+{
+av_assert2(n <= 64 && value < (1UL << n));
+
+if (n < 32)
+put_bits(s, n, value);
+else if (n == 32)
+put_bits32(s, value);
+else if (n < 64) {
+uint32_t lo = value & 0x;
+uint32_t hi = value >> 32;
+#ifdef BITSTREAM_WRITER_LE
+put_bits32(s, lo);
+put_bits(s, n - 32, hi);
+#else
+put_bits(s, n - 32, hi);
+put_bits32(s, lo);
+#endif
+} else {
+uint32_t lo = value & 0x;
+uint32_t hi = value >> 32;
+#ifdef BITSTREAM_WRITER_LE
+put_bits32(s, lo);
+put_bits32(s, hi);
+#else
+put_bits32(s, hi);
+put_bits32(s, lo);
+#endif
+
+}
+}
+
+/**
* Return the pointer to the byte where the bitstream writer will put
* the next bit.
*/
diff --git a/libavcodec/tests/golomb.c b/libavcodec/tests/golomb.c
index 965367b7be..85b8a9390b 100644
--- a/libavcodec/tests/golomb.c
+++ b/libavcodec/tests/golomb.c
@@ -21,6 +21,7 @@
#include
#include
+#include "libavutil/internal.h"
#include "libavutil/mem.h"
#include "libavcodec/get_bits.h"
@@ -76,6 +77,24 @@ int main(void)
}
}
+#define EXTEND_L(i) ((i) << 4 | (i) & 15)
+init_put_bits(&pb, temp, SIZE);
+for (i = 0; i < COUNT; i++)
+set_ue_golomb_long(&pb, EXTEND_L(i));
+flush_put_bits(&pb);
+
+init_get_bits(&gb, temp, 8 * SIZE);
+for (i = 0; i < COUNT; i++) {
+int j, s = show_bits_long(&gb, 32);
+
+j = get_ue_golomb_long(&gb);
+if (j != EXTEND_L(i)) {
+fprintf(stderr, "get_ue_golomb_long: expected %d, got %d. "
+"bits: %8x\n", EXTEND_L(i), j, s);
+ret = 1;
+}
+}
+
init_put_bits(&pb, temp, SIZE);
for (i = 0; i < COUNT; i++)
set_se_golomb(&pb, i - COUNT / 2);
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls
Hi On Sun, Jun 04, 2017 at 12:46:18PM +0200, Nicolas George wrote: > Le quartidi 14 prairial, an CCXXV, Michael Niedermayer a écrit : > > > Notice a pattern? > > yes > > Security issues are found, i post a fix and people complain, > > No. The pattern is: you rush to produce a bad fix. thats "ad hominem" If theres an issue in a change, the center of the discussion should be the issue so it can be improved. looking at what you wrote, iam not even sure if you talk about whitelists, some patch here or something totally different that you call bad. Its just obvious at who you point not what you talk about or what you see bad in it. and that person (being me) is heavily constrained by the wishes of the rest of the team. also security issues need to be fixed quickly, the quick fix to stop an issue and the solution we work toward in the long term can be very different and a quick fix in the most general sense is likely quite shit compared to a long term solution. Still we own our users fixing sec issues quickly, its us who wrote the vulnerable mess in the first place. We should not let them wait until we design and implement the perfect long term solution. > > > If you knew a year and a half ago about a security issue and about a > > great solution to it. > > How far is it from completion ? > > does this cover the hls vulnerability we discussed in > > the last 2 days and Can you post a patch ? > > I said that WE needed to look for a solution. We, collective. > > I, individual, do not have a solution, I only know that one exists > (Perl, Windows, web browsers all have a similar mechanism) and that > "fixing" the individual issues rather than designing a global solution > is a waste of time. Iam happy to help and work together with you to design and implement this. Iam not sure what you have in mind though exactly and iam not sure if its able to fix this. Can you please explain what you have in mind ? > > > But the real question still is, how do people prefer us to deal with > > this security issue here? > > This one ? Ignore it but take the opportunity to start designingⁿ: a > proper solution would fix it anyway. > > If you do anything else, I will not object to you pushing, but only if > you add "--author=Sysiphus" to your git commit command. You dont need to convince me that the extension check or changes within just hls are not a complete solution. Iam quite well aware of this. This is intended to stop an existing exploit and variants of it in practice and do so quickly. A complete solution will also likely add some inconvenience that some developers object to. I feel that the security outweighs the inconvenience but others object to it. Its not the first issue with hls and it likely wont be the last, I think --author=Sysiphus is quite fitting in fact. Also its really a change guided by peoples objections ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: Check local file extensions
On Sat, Jun 03, 2017 at 09:20:04PM +0200, Michael Niedermayer wrote: > This reduces the attack surface of local file-system > information leaking. > > It prevents the existing exploit leading to an information leak. As > well as similar hypothetical attacks. > > Leaks of information from files and symlinks ending in common multimedia > extensions > are still possible. But files with sensitive information like private keys > and passwords > generally do not use common multimedia filename extensions. > It does not stop leaks via remote addresses in the LAN. > > The existing exploit depends on a specific decoder as well. > It does appear though that the exploit should be possible with any decoder. > The problem is that as long as sensitive information gets into the decoder, > the output of the decoder becomes sensitive as well. > The only obvious solution is to prevent access to sensitive information. Or to > disable hls or possibly some of its feature. More complex solutions like > checking the path to limit access to only subdirectories of the hls path may > work as an alternative. But such solutions are fragile and tricky to implement > portably and would not stop every possible attack nor would they work with all > valid hls files. > > Developers have expressed their dislike / objected to disabling hls by > default as well > as disabling hls with local files. There also where objections against > restricting > remote url file extensions. This here is a less robust but also lower > inconvenience solution. > It can be applied stand alone or together with other solutions. > > Found-by: Emil Lerner and Pavel Cheremushkin > Reported-by: Thierry Foucu > > Signed-off-by: Michael Niedermayer > --- > libavformat/hls.c | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) Applied with the author name joke suggested by nicolas Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FATE: Add test for libavfilter/scale2ref
On Sun, Jun 4, 2017 at 4:19 AM, Gyan wrote: > Now that this feature has been applied, it may be helpful to check if one > of the W/H arguments is of the form '-n' and log a warning that this will > force the ref's display aspect ratio. The warning should also convey the > expression to use: 'oh*mdar' or 'ow/mdar' , as the case may be. > > Additionally, since the output SAR will be adjusted to force the ref's DAR, > it would be helpful to add a warning for that (tell users to append > setsar=1 after the scale) --or-- (ideally) patch the filter so that the > main's DAR is preserved. I was thinking about this as well. The next step for improving the scale2ref filter is probably patching it to preserve main's DAR, as you mentioned. It's definitely easy enough to correct with the setsar filter but given scale2ref's purpose the current behavior still feels dramatically unintuitive. Perhaps I'm just being unimaginative when it comes to use-cases but it certainly seems like the vast majority of uses would involve keeping main's DAR. This would be a breaking change, unlike the previous patches. The warning for the "-n" stuff sounds helpful. I'll take a look at this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add test for the Dirac low delay profile
On 5 June 2017 at 00:44, Michael Niedermayer wrote: > On Sun, Jun 04, 2017 at 06:03:36PM +0100, Rostislav Pehlivanov wrote: > > --- > > tests/fate/video.mak | 3 +++ > > tests/ref/fate/dirac-low-delay | 7 +++ > > 2 files changed, 10 insertions(+) > > create mode 100644 tests/ref/fate/dirac-low-delay > > test passes on linux x86 32/64 arm, mips and mingw32/64 > > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. > User > questions about the command line tools should be sent to the ffmpeg-user > ML. > And questions about how to use libav* should be sent to the libav-user ML. > > ___ > 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] avformat/hls: Check local file extensions
Le septidi 17 prairial, an CCXXV, Michael Niedermayer a écrit : > Applied with the author name joke suggested by nicolas Despite Hendrik's objection? The joke name was nit an approval, and I had no authority to give it anyway. (On a phone and bad network, will reply to the other mail later.) -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
