[FFmpeg-devel] [PATCH]lavc/x264:Refuse RGB24 as input pix_fmt
Hi!
Attached patch works around ticket #4287 here.
Please comment, Carl Eugen
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9020a40..5736c6c 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -755,7 +755,6 @@ static const enum AVPixelFormat pix_fmts_8bit_rgb[] = {
#ifdef X264_CSP_BGR
AV_PIX_FMT_BGR0,
AV_PIX_FMT_BGR24,
-AV_PIX_FMT_RGB24,
#endif
AV_PIX_FMT_NONE
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] libavfilter/formats: Fix parsing of channel specifications with a trailing 'c'.
Fix an off-by-one in checking tail for trailing characters and ensure
that the parsing helper is only called for unknown channel layouts.
Note: This removes the check ensuring that the channel layout is > 0 and
< 63.
Signed-off-by: Simon Thelen
---
If the check ensuring 0 < chlayout < 63 is necessary, I can send a v2
adding it back
libavfilter/formats.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 4f9773b..2e00f30 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -637,20 +637,17 @@ int ff_parse_channel_layout(int64_t *ret, int *nret,
const char *arg,
void *log_ctx)
{
char *tail;
-int64_t chlayout, count;
-
-if (nret) {
-count = strtol(arg, &tail, 10);
-if (*tail == 'c' && !tail[1] && count > 0 && count < 63) {
-*nret = count;
-*ret = 0;
-return 0;
-}
-}
+int64_t chlayout;
+
chlayout = av_get_channel_layout(arg);
if (chlayout == 0) {
chlayout = strtol(arg, &tail, 10);
-if (*tail || chlayout == 0) {
+if (*(tail + 1) || chlayout == 0) {
+if (nret && *tail == 'c') {
+*nret = chlayout;
+*ret = 0;
+return 0;
+}
av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n",
arg);
return AVERROR(EINVAL);
}
--
2.4.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] Fix silent audio when channel layout specified with trailing c
When specifying the output channel layout with a trailing 'c' such as '1c' or '2c', the pad filter created silent output files. Leaving the trailing 'c' away resulted in correct output files, but generated a warning that the syntax was deprecated. The first patch fixes two bugs in ff_parse_channel_layout including an off-by-one and an issue in the parsing helper for unknown channel layouts. The second patch ensures that the channel layout is returned correctly when FF_API_GET_CHANNEL_LAYOUT_COMPAT is set. Simon Thelen (2): libavfilter/formats: Fix parsing of channel specifications with a trailing 'c'. libavutil/channel_layout: Correctly return layout when channel specification ends with a trailing 'c'. libavfilter/formats.c | 19 --- libavutil/channel_layout.c | 2 +- 2 files changed, 9 insertions(+), 12 deletions(-) -- 2.4.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavutil/channel_layout: Correctly return layout when channel specification ends with a trailing 'c'.
Return layout when FF_API_GET_CHANNEL_LAYOUT_COMPAT is set even if the
layout itself is not in the deprecated style.
Signed-off-by: Simon Thelen
---
libavutil/channel_layout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 4c0677f..cd5cf42 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -138,8 +138,8 @@ static uint64_t get_channel_layout_single(const char *name,
int name_len)
"switch to the syntax '%.*sc' otherwise it will be
interpreted as a "
"channel layout number in a later version\n",
name_len, name, name_len, name);
-return layout;
}
+return layout;
}
} else {
#endif
--
2.4.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/libopenjpegdec: Mark as experimental if <= 1.3
Signed-off-by: Michael Niedermayer
---
libavcodec/libopenjpegdec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 8fe7a50..7f28e87 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -433,6 +433,15 @@ done:
return ret;
}
+static av_cold void libopenjpeg_static_init(AVCodec *codec)
+{
+const char *version = opj_version();
+int major, minor;
+
+if (sscanf(version, "%d.%d", &major, &minor) == 2 && 1000*major + minor <=
1003)
+codec->capabilities |= CODEC_CAP_EXPERIMENTAL;
+}
+
#define OFFSET(x) offsetof(LibOpenJPEGContext, x)
#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
@@ -460,4 +469,5 @@ AVCodec ff_libopenjpeg_decoder = {
.capabilities = CODEC_CAP_DR1 | CODEC_CAP_FRAME_THREADS,
.max_lowres = 31,
.priv_class = &openjpeg_class,
+.init_static_data = libopenjpeg_static_init,
};
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/tls_securetransport: fix SNI support when not verifying
On Mon, Jun 08, 2015 at 04:59:32PM -0500, Rodger Combs wrote: > --- > libavformat/tls_securetransport.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- 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]Mark experimental j2k decoder as experimental if libopenjpeg is available
Michael Niedermayer gmx.at> writes: > it seems libopenjpeg is not able to decode the files > generated with libopenjpeg. > That is with the libopenjpeg from ubuntu 12.04 > (1.3+dfsg-4+squeeze2build0.12.04.1) > but ubuntu 14.04 ships a variant of 1.3 too > > test done with: > ./ffmpeg -threads 1 -i matrixbench_mpeg2.mpg -vframes 1 > -vcodec libopenjpeg -format j2k test.j2k > ./ffplay -vcodec libopenjpeg test.j2k Sorry, I seem to have missed this mail. I get bitexact output with libopenjpeg encoding and decoding. This is with libopenjpeg 1.5.0 which is from 2012 (afaiu). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Use libopenjpeg by default if it was enabled
On Mon, Jun 08, 2015 at 10:01:18PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #3619 for me. should have become unneeded [...] -- 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
[FFmpeg-devel] [PATCH] lavf/tls_securetransport: fix SNI support when not verifying
---
libavformat/tls_securetransport.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/tls_securetransport.c
b/libavformat/tls_securetransport.c
index c90eab7..cdc7953 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -273,13 +273,13 @@ static int tls_open(URLContext *h, const char *uri, int
flags, AVDictionary **op
if (s->ca_file) {
if ((ret = load_ca(h)) < 0)
goto fail;
-CHECK_ERROR(SSLSetSessionOption, c->ssl_context,
kSSLSessionOptionBreakOnServerAuth, true);
}
+if (s->ca_file || !s->verify)
+CHECK_ERROR(SSLSetSessionOption, c->ssl_context,
kSSLSessionOptionBreakOnServerAuth, true);
if (s->cert_file)
if ((ret = load_cert(h)) < 0)
goto fail;
-if (s->verify)
-CHECK_ERROR(SSLSetPeerDomainName, c->ssl_context, s->host,
strlen(s->host));
+CHECK_ERROR(SSLSetPeerDomainName, c->ssl_context, s->host,
strlen(s->host));
CHECK_ERROR(SSLSetIOFuncs, c->ssl_context, tls_read_cb, tls_write_cb);
CHECK_ERROR(SSLSetConnection, c->ssl_context, h);
while (1) {
--
2.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/tls_securetransport: fix SNI support when not verifying
---
libavformat/segment.c | 4 +++-
libavformat/tls_securetransport.c | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 953140f..66e28b2 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -113,6 +113,7 @@ typedef struct SegmentContext {
int64_t initial_offset;///< initial timestamps offset, expressed in
microseconds
char *reference_stream_specifier; ///< reference stream specifier
int reference_stream_index;
+int break_non_keyframes;
SegmentListEntry cur_entry;
SegmentListEntry *segment_list_entries;
@@ -910,7 +911,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
pkt->stream_index == seg->reference_stream_index ?
seg->frame_count : -1);
if (pkt->stream_index == seg->reference_stream_index &&
-pkt->flags & AV_PKT_FLAG_KEY &&
+(pkt->flags & AV_PKT_FLAG_KEY || seg->break_non_keyframes) &&
seg->segment_frame_count > 0 &&
(seg->cut_pending || seg->frame_count >= start_frame ||
(pkt->pts != AV_NOPTS_VALUE &&
@@ -1056,6 +1057,7 @@ static const AVOption options[] = {
{ "segment_start_number", "set the sequence number of the first segment",
OFFSET(segment_idx), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, E },
{ "segment_wrap_number", "set the number of wrap before the first
segment", OFFSET(segment_idx_wrap_nb), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX,
E },
{ "strftime", "set filename expansion with strftime at segment
creation", OFFSET(use_strftime), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 1, E },
+{ "break_non_keyframes", "allow breaking segments on non-keyframes",
OFFSET(break_non_keyframes), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, E },
{ "individual_header_trailer", "write header/trailer to each segment",
OFFSET(individual_header_trailer), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, E },
{ "write_header_trailer", "write a header to the first segment and a
trailer to the last one", OFFSET(write_header_trailer), AV_OPT_TYPE_INT, {.i64
= 1}, 0, 1, E },
diff --git a/libavformat/tls_securetransport.c
b/libavformat/tls_securetransport.c
index c90eab7..cdc7953 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -273,13 +273,13 @@ static int tls_open(URLContext *h, const char *uri, int
flags, AVDictionary **op
if (s->ca_file) {
if ((ret = load_ca(h)) < 0)
goto fail;
-CHECK_ERROR(SSLSetSessionOption, c->ssl_context,
kSSLSessionOptionBreakOnServerAuth, true);
}
+if (s->ca_file || !s->verify)
+CHECK_ERROR(SSLSetSessionOption, c->ssl_context,
kSSLSessionOptionBreakOnServerAuth, true);
if (s->cert_file)
if ((ret = load_cert(h)) < 0)
goto fail;
-if (s->verify)
-CHECK_ERROR(SSLSetPeerDomainName, c->ssl_context, s->host,
strlen(s->host));
+CHECK_ERROR(SSLSetPeerDomainName, c->ssl_context, s->host,
strlen(s->host));
CHECK_ERROR(SSLSetIOFuncs, c->ssl_context, tls_read_cb, tls_write_cb);
CHECK_ERROR(SSLSetConnection, c->ssl_context, h);
while (1) {
--
2.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] vp8: change mv_{min, max}.{x, y} type to int
On 08.06.2015 23:37, Ronald S. Bultje wrote:
> On Mon, Jun 8, 2015 at 5:33 PM, Clément Bœsch wrote:
>
>> On Mon, Jun 08, 2015 at 11:31:15PM +0200, Andreas Cadhalpun wrote:
>>> ffmpeg | branch: master | Andreas Cadhalpun <
>> andreas.cadhal...@googlemail.com> | Mon Jun 8 22:38:29 2015 +0200|
>> [6fdbaa2b7fb56623ab2163f861952bc1408c39b3] | committer: Andreas Cadhalpun
>>>
>>> vp8: change mv_{min,max}.{x,y} type to int
>>>
>>> If one of the dimensions is larger than 8176, s->mb_width or
>>> s->mb_height is larger than 511, leading to an int16_t overflow of
>>> s->mv_max.{x,y}. This then causes av_clip to be called with amin > amax.
>>>
>>> Changing the type to int avoids the overflow and has no negative
>>> effect, because s->mv_max is only used in clamp_mv for clipping.
>>> Since mv_max.{x,y} is positive and mv_min.{x,y} negative, av_clip can't
>>> increase the absolute value. The input to av_clip is an int16_t, and
>>> thus the output fits into int16_t as well.
>>>
>>> For additional safety, s->mv_{min,max}.{x,y} are clipped to int16_t range
>>> before use.
>>>
>>> Reviewed-by: Ronald S. Bultje
>>> Signed-off-by: Andreas Cadhalpun
>>>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6fdbaa2b7fb56623ab2163f861952bc1408c39b3
>>> ---
>>>
>>> libavcodec/vp8.c |6 --
>>> libavcodec/vp8.h |9 +++--
>>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
>>> index dbba568..becbb2c 100644
>>> --- a/libavcodec/vp8.c
>>> +++ b/libavcodec/vp8.c
>>> @@ -757,8 +757,10 @@ 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)
>>> {
>>> -dst->x = av_clip(src->x, s->mv_min.x, s->mv_max.x);
>>> -dst->y = av_clip(src->y, s->mv_min.y, s->mv_max.y);
>>> +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));
>>> +dst->y = av_clip(src->y, av_clip(s->mv_min.y, INT16_MIN, INT16_MAX),
>>> + av_clip(s->mv_max.y, INT16_MIN,
>> INT16_MAX));
>>
>> Sorry I might have missed something, but why not use av_clip_int16()?
I didn't know about that function. ;)
> Hm yeah I forgot about that, sorry. You could also consider clipping (into
> a second variable, since this one is used to increment in the main block
> decode loop) so that you only clip once per mb (horizontal) + once per row
> (vertical), instead of twice per mv, which might be 32x for a 4x4 block.
>
> (But I can submit a patch for that later.)
If you think these av_clip make it noticeably slower, I think it would be
better to just remove them, because they shouldn't be needed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] vp8: change mv_{min, max}.{x, y} type to int
On Mon, Jun 08, 2015 at 05:37:22PM -0400, Ronald S. Bultje wrote:
> On Mon, Jun 8, 2015 at 5:33 PM, Clément Bœsch wrote:
>
> > On Mon, Jun 08, 2015 at 11:31:15PM +0200, Andreas Cadhalpun wrote:
> > > ffmpeg | branch: master | Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> | Mon Jun 8 22:38:29 2015 +0200|
> > [6fdbaa2b7fb56623ab2163f861952bc1408c39b3] | committer: Andreas Cadhalpun
> > >
> > > vp8: change mv_{min,max}.{x,y} type to int
> > >
> > > If one of the dimensions is larger than 8176, s->mb_width or
> > > s->mb_height is larger than 511, leading to an int16_t overflow of
> > > s->mv_max.{x,y}. This then causes av_clip to be called with amin > amax.
> > >
> > > Changing the type to int avoids the overflow and has no negative
> > > effect, because s->mv_max is only used in clamp_mv for clipping.
> > > Since mv_max.{x,y} is positive and mv_min.{x,y} negative, av_clip can't
> > > increase the absolute value. The input to av_clip is an int16_t, and
> > > thus the output fits into int16_t as well.
> > >
> > > For additional safety, s->mv_{min,max}.{x,y} are clipped to int16_t range
> > > before use.
> > >
> > > Reviewed-by: Ronald S. Bultje
> > > Signed-off-by: Andreas Cadhalpun
> > >
> > > >
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6fdbaa2b7fb56623ab2163f861952bc1408c39b3
> > > ---
> > >
> > > libavcodec/vp8.c |6 --
> > > libavcodec/vp8.h |9 +++--
> > > 2 files changed, 11 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > > index dbba568..becbb2c 100644
> > > --- a/libavcodec/vp8.c
> > > +++ b/libavcodec/vp8.c
> > > @@ -757,8 +757,10 @@ 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)
> > > {
> > > -dst->x = av_clip(src->x, s->mv_min.x, s->mv_max.x);
> > > -dst->y = av_clip(src->y, s->mv_min.y, s->mv_max.y);
> > > +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));
> > > +dst->y = av_clip(src->y, av_clip(s->mv_min.y, INT16_MIN, INT16_MAX),
> > > + av_clip(s->mv_max.y, INT16_MIN,
> > INT16_MAX));
> >
> > Sorry I might have missed something, but why not use av_clip_int16()?
> >
>
> Hm yeah I forgot about that, sorry. You could also consider clipping (into
> a second variable, since this one is used to increment in the main block
> decode loop) so that you only clip once per mb (horizontal) + once per row
> (vertical), instead of twice per mv, which might be 32x for a 4x4 block.
>
I see some inline in this function and the av_clip* ones, so maybe the
compiler is smart enough to handle that. av_clip* functions are marked
with the av_const attribute to help that; if it's still not enough, maybe
adding av_pure to those would help.
> (But I can submit a patch for that later.)
>
> Ronald
--
Clément B.
pgp5cggwNfDnY.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] vp8: change mv_{min, max}.{x, y} type to int
On Mon, Jun 8, 2015 at 5:33 PM, Clément Bœsch wrote:
> On Mon, Jun 08, 2015 at 11:31:15PM +0200, Andreas Cadhalpun wrote:
> > ffmpeg | branch: master | Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> | Mon Jun 8 22:38:29 2015 +0200|
> [6fdbaa2b7fb56623ab2163f861952bc1408c39b3] | committer: Andreas Cadhalpun
> >
> > vp8: change mv_{min,max}.{x,y} type to int
> >
> > If one of the dimensions is larger than 8176, s->mb_width or
> > s->mb_height is larger than 511, leading to an int16_t overflow of
> > s->mv_max.{x,y}. This then causes av_clip to be called with amin > amax.
> >
> > Changing the type to int avoids the overflow and has no negative
> > effect, because s->mv_max is only used in clamp_mv for clipping.
> > Since mv_max.{x,y} is positive and mv_min.{x,y} negative, av_clip can't
> > increase the absolute value. The input to av_clip is an int16_t, and
> > thus the output fits into int16_t as well.
> >
> > For additional safety, s->mv_{min,max}.{x,y} are clipped to int16_t range
> > before use.
> >
> > Reviewed-by: Ronald S. Bultje
> > Signed-off-by: Andreas Cadhalpun
> >
> > >
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6fdbaa2b7fb56623ab2163f861952bc1408c39b3
> > ---
> >
> > libavcodec/vp8.c |6 --
> > libavcodec/vp8.h |9 +++--
> > 2 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > index dbba568..becbb2c 100644
> > --- a/libavcodec/vp8.c
> > +++ b/libavcodec/vp8.c
> > @@ -757,8 +757,10 @@ 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)
> > {
> > -dst->x = av_clip(src->x, s->mv_min.x, s->mv_max.x);
> > -dst->y = av_clip(src->y, s->mv_min.y, s->mv_max.y);
> > +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));
> > +dst->y = av_clip(src->y, av_clip(s->mv_min.y, INT16_MIN, INT16_MAX),
> > + av_clip(s->mv_max.y, INT16_MIN,
> INT16_MAX));
>
> Sorry I might have missed something, but why not use av_clip_int16()?
>
Hm yeah I forgot about that, sorry. You could also consider clipping (into
a second variable, since this one is used to increment in the main block
decode loop) so that you only clip once per mb (horizontal) + once per row
(vertical), instead of twice per mv, which might be 32x for a 4x4 block.
(But I can submit a patch for that later.)
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] vp8: change mv_{min, max}.{x, y} type to int
On Mon, Jun 08, 2015 at 11:31:15PM +0200, Andreas Cadhalpun wrote:
> ffmpeg | branch: master | Andreas Cadhalpun
> | Mon Jun 8 22:38:29 2015 +0200|
> [6fdbaa2b7fb56623ab2163f861952bc1408c39b3] | committer: Andreas Cadhalpun
>
> vp8: change mv_{min,max}.{x,y} type to int
>
> If one of the dimensions is larger than 8176, s->mb_width or
> s->mb_height is larger than 511, leading to an int16_t overflow of
> s->mv_max.{x,y}. This then causes av_clip to be called with amin > amax.
>
> Changing the type to int avoids the overflow and has no negative
> effect, because s->mv_max is only used in clamp_mv for clipping.
> Since mv_max.{x,y} is positive and mv_min.{x,y} negative, av_clip can't
> increase the absolute value. The input to av_clip is an int16_t, and
> thus the output fits into int16_t as well.
>
> For additional safety, s->mv_{min,max}.{x,y} are clipped to int16_t range
> before use.
>
> Reviewed-by: Ronald S. Bultje
> Signed-off-by: Andreas Cadhalpun
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6fdbaa2b7fb56623ab2163f861952bc1408c39b3
> ---
>
> libavcodec/vp8.c |6 --
> libavcodec/vp8.h |9 +++--
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index dbba568..becbb2c 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -757,8 +757,10 @@ 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)
> {
> -dst->x = av_clip(src->x, s->mv_min.x, s->mv_max.x);
> -dst->y = av_clip(src->y, s->mv_min.y, s->mv_max.y);
> +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));
> +dst->y = av_clip(src->y, av_clip(s->mv_min.y, INT16_MIN, INT16_MAX),
> + av_clip(s->mv_max.y, INT16_MIN, INT16_MAX));
Sorry I might have missed something, but why not use av_clip_int16()?
[...]
--
Clément B.
pgpJPhWjpFzV9.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] vp8: check for too large dimensions
Hi Ronald,
On 08.06.2015 23:18, Ronald S. Bultje wrote:
> On Mon, Jun 8, 2015 at 5:08 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 07.06.2015 22:39, Michael Niedermayer wrote:
>>> On Sun, Jun 07, 2015 at 04:27:42PM -0400, Ronald S. Bultje wrote:
So what happens when you change mv_max/min to be integers (instead of
int16_t) without further touching VP56mv, e.g. by making mv_max/min a
VP8intminmaxmv (a newly created type just for this purpose, using int
instead of int16_t)?
>>
>> This fixes the problem (but I chose the shorter name VP8intmv).
>> A patch implementing this is attached.
>>
>> It seems libvpx is actually also using int for this type of information,
>> although the implementation is different and instead of sv_{min,max}.{x,y}
>> uses mb_to_{left,right,bottom,top}_edge (at least if I understood the code
>> correctly). [1][2]
>>
>>> would this work with
>>> clamp_mv() ?
>>> it limits based in mv_max/min but writes into a VP56mv, so if these
>>> out of 16bit limits can actually be reached then the output of
>>> the clip would not fit in the 16bit destination ...
>>> but maybe this doesnt occur, ive not deeply investigated
>>
>> I think it doesn't happen, but for safety I clip s->mv_{min,max}.{x,y}
>> to int16_t range.
>>
>> Best regards,
>> Andreas
>>
>>
>> 1:
>> https://sources.debian.net/src/libvpx/1.4.0-3/vp8/common/reconinter.c/?hl=340#L340
>> 2:
>> https://sources.debian.net/src/libvpx/1.4.0-3/vp9/common/vp9_blockd.h/?hl=203#L203
>
>
> I think this should be ok, thanks for modifying it based on comments.
Pushed. Thanks a lot for the review.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpegdec: don't try to alloc an AVIOContext when probe is guaranteed to fail
On 08/06/15 6:23 PM, Michael Niedermayer wrote: > On Mon, Jun 08, 2015 at 05:40:55PM -0300, James Almer wrote: >> The first check is done without the AVIOContext, so alloc it only if said >> check succeeds >> >> Signed-off-by: James Almer >> --- >> libavformat/mpjpegdec.c | 7 +++ >> 1 file changed, 3 insertions(+), 4 deletions(-) > > LGTM > > thanks Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpegdec: don't try to alloc an AVIOContext when probe is guaranteed to fail
On Mon, Jun 08, 2015 at 05:40:55PM -0300, James Almer wrote: > The first check is done without the AVIOContext, so alloc it only if said > check succeeds > > Signed-off-by: James Almer > --- > libavformat/mpjpegdec.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] vp8: check for too large dimensions
Hi,
On Mon, Jun 8, 2015 at 5:08 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 07.06.2015 22:39, Michael Niedermayer wrote:
> > On Sun, Jun 07, 2015 at 04:27:42PM -0400, Ronald S. Bultje wrote:
> >> So what happens when you change mv_max/min to be integers (instead of
> >> int16_t) without further touching VP56mv, e.g. by making mv_max/min a
> >> VP8intminmaxmv (a newly created type just for this purpose, using int
> >> instead of int16_t)?
>
> This fixes the problem (but I chose the shorter name VP8intmv).
> A patch implementing this is attached.
>
> It seems libvpx is actually also using int for this type of information,
> although the implementation is different and instead of sv_{min,max}.{x,y}
> uses mb_to_{left,right,bottom,top}_edge (at least if I understood the code
> correctly). [1][2]
>
> > would this work with
> > clamp_mv() ?
> > it limits based in mv_max/min but writes into a VP56mv, so if these
> > out of 16bit limits can actually be reached then the output of
> > the clip would not fit in the 16bit destination ...
> > but maybe this doesnt occur, ive not deeply investigated
>
> I think it doesn't happen, but for safety I clip s->mv_{min,max}.{x,y}
> to int16_t range.
>
> Best regards,
> Andreas
>
>
> 1:
> https://sources.debian.net/src/libvpx/1.4.0-3/vp8/common/reconinter.c/?hl=340#L340
> 2:
> https://sources.debian.net/src/libvpx/1.4.0-3/vp9/common/vp9_blockd.h/?hl=203#L203
I think this should be ok, thanks for modifying it based on comments.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] vp8: check for too large dimensions
On 07.06.2015 22:39, Michael Niedermayer wrote:
> On Sun, Jun 07, 2015 at 04:27:42PM -0400, Ronald S. Bultje wrote:
>> So what happens when you change mv_max/min to be integers (instead of
>> int16_t) without further touching VP56mv, e.g. by making mv_max/min a
>> VP8intminmaxmv (a newly created type just for this purpose, using int
>> instead of int16_t)?
This fixes the problem (but I chose the shorter name VP8intmv).
A patch implementing this is attached.
It seems libvpx is actually also using int for this type of information,
although the implementation is different and instead of sv_{min,max}.{x,y}
uses mb_to_{left,right,bottom,top}_edge (at least if I understood the code
correctly). [1][2]
> would this work with
> clamp_mv() ?
> it limits based in mv_max/min but writes into a VP56mv, so if these
> out of 16bit limits can actually be reached then the output of
> the clip would not fit in the 16bit destination ...
> but maybe this doesnt occur, ive not deeply investigated
I think it doesn't happen, but for safety I clip s->mv_{min,max}.{x,y}
to int16_t range.
Best regards,
Andreas
1:
https://sources.debian.net/src/libvpx/1.4.0-3/vp8/common/reconinter.c/?hl=340#L340
2:
https://sources.debian.net/src/libvpx/1.4.0-3/vp9/common/vp9_blockd.h/?hl=203#L203
>From 0c18c05c3010eae7fc1b5e09367115e3ba0081a5 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Mon, 8 Jun 2015 22:38:29 +0200
Subject: [PATCH] vp8: change mv_{min,max}.{x,y} type to int
If one of the dimensions is larger than 8176, s->mb_width or
s->mb_height is larger than 511, leading to an int16_t overflow of
s->mv_max.{x,y}. This then causes av_clip to be called with amin > amax.
Changing the type to int avoids the overflow and has no negative
effect, because s->mv_max is only used in clamp_mv for clipping.
Since mv_max.{x,y} is positive and mv_min.{x,y} negative, av_clip can't
increase the absolute value. The input to av_clip is an int16_t, and
thus the output fits into int16_t as well.
For additional safety, s->mv_{min,max}.{x,y} is clipped to in16_t range
before use.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/vp8.c | 6 --
libavcodec/vp8.h | 9 +++--
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index dbba568..becbb2c 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -757,8 +757,10 @@ 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)
{
-dst->x = av_clip(src->x, s->mv_min.x, s->mv_max.x);
-dst->y = av_clip(src->y, s->mv_min.y, s->mv_max.y);
+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));
+dst->y = av_clip(src->y, av_clip(s->mv_min.y, INT16_MIN, INT16_MAX),
+ av_clip(s->mv_max.y, INT16_MIN, INT16_MAX));
}
/**
diff --git a/libavcodec/vp8.h b/libavcodec/vp8.h
index b650892..2135bd9 100644
--- a/libavcodec/vp8.h
+++ b/libavcodec/vp8.h
@@ -134,6 +134,11 @@ typedef struct VP8Frame {
AVBufferRef *seg_map;
} VP8Frame;
+typedef struct VP8intmv {
+int x;
+int y;
+} VP8intmv;
+
#define MAX_THREADS 8
typedef struct VP8Context {
VP8ThreadData *thread_data;
@@ -152,8 +157,8 @@ typedef struct VP8Context {
uint8_t deblock_filter;
uint8_t mbskip_enabled;
uint8_t profile;
-VP56mv mv_min;
-VP56mv mv_max;
+VP8intmv mv_min;
+VP8intmv mv_max;
int8_t sign_bias[4]; ///< one state [0, 1] per ref frame type
int ref_count[3];
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpjpegdec: don't try to alloc an AVIOContext when probe is guaranteed to fail
The first check is done without the AVIOContext, so alloc it only if said check
succeeds
Signed-off-by: James Almer
---
libavformat/mpjpegdec.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 56fe159..845e95c 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -83,13 +83,13 @@ static int mpjpeg_read_probe(AVProbeData *p)
char line[128] = { 0 };
int ret = 0;
+if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-')
+return 0;
+
pb = avio_alloc_context(p->buf, p->buf_size, 0, NULL, NULL, NULL, NULL);
if (!pb)
return AVERROR(ENOMEM);
-if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-')
-goto end;
-
while (!pb->eof_reached) {
ret = get_line(pb, line, sizeof(line));
if (ret < 0)
@@ -101,7 +101,6 @@ static int mpjpeg_read_probe(AVProbeData *p)
break;
}
}
-end:
av_free(pb);
--
2.4.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Use libopenjpeg by default if it was enabled
Hi! Attached patch fixes ticket #3619 for me. Please comment, Carl Eugen diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index ce97746..6f40b51 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -104,6 +104,9 @@ void avcodec_register_all(void) REGISTER_HWACCEL(WMV3_VAAPI,wmv3_vaapi); REGISTER_HWACCEL(WMV3_VDPAU,wmv3_vdpau); +/* libopenjpeg should be used by default if enabled */ +REGISTER_ENCDEC (LIBOPENJPEG, libopenjpeg); + /* video codecs */ REGISTER_ENCODER(A64MULTI, a64multi); REGISTER_ENCODER(A64MULTI5, a64multi5); @@ -528,7 +531,6 @@ void avcodec_register_all(void) REGISTER_ENCODER(LIBMP3LAME,libmp3lame); REGISTER_ENCDEC (LIBOPENCORE_AMRNB, libopencore_amrnb); REGISTER_DECODER(LIBOPENCORE_AMRWB, libopencore_amrwb); -REGISTER_ENCDEC (LIBOPENJPEG, libopenjpeg); REGISTER_ENCDEC (LIBOPUS, libopus); REGISTER_ENCDEC (LIBSCHROEDINGER, libschroedinger); REGISTER_ENCODER(LIBSHINE, libshine); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: change type of tile_size from unsigned to int64_t
On Mon, Jun 08, 2015 at 09:45:07PM +0200, Andreas Cadhalpun wrote:
> On 07.06.2015 22:30, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Jun 7, 2015 at 1:02 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> Otherwise the check 'tile_size < size' treats a negative size as
> >> unsigned, causing the check to pass. This subsequently leads to
> >> segmentation faults.
> >>
> >> This was originally fixed as part of Libav commit 72ca83, so the
> >> original author is one of the following developers:
> >> Anton Khirnov
> >> Diego Biurrun
> >> Luca Barbato
> >> Martin Storsjö
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >>
> >> Does someone still remember who authored this particular change,
> >> so that he can get proper attribution?
> >>
> >> ---
> >> libavcodec/vp9.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> >> index c4efd42..d5147e5 100644
> >> --- a/libavcodec/vp9.c
> >> +++ b/libavcodec/vp9.c
> >> @@ -4106,7 +4106,7 @@ static int vp9_decode_frame(AVCodecContext *ctx,
> >> void *frame,
> >> tile_row, s->tiling.log2_tile_rows,
> >> s->sb_rows);
> >> if (s->pass != 2) {
> >> for (tile_col = 0; tile_col < s->tiling.tile_cols;
> >> tile_col++) {
> >> -unsigned tile_size;
> >> +int64_t tile_size;
> >
> >
> > Hm... OK.
>
> Pushed.
>
For the record; we extracted and aknowledged that change at the time of
the merge, but we didn't figure out what it was actually fixing. Thanks
for looking into this. IIRC that was the only unmerged functional change.
> Best regards,
> Andreas
>
--
Clément B.
pgpVTViRpuk0b.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: change type of tile_size from unsigned to int64_t
On 07.06.2015 22:30, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jun 7, 2015 at 1:02 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> Otherwise the check 'tile_size < size' treats a negative size as
>> unsigned, causing the check to pass. This subsequently leads to
>> segmentation faults.
>>
>> This was originally fixed as part of Libav commit 72ca83, so the
>> original author is one of the following developers:
>> Anton Khirnov
>> Diego Biurrun
>> Luca Barbato
>> Martin Storsjö
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>>
>> Does someone still remember who authored this particular change,
>> so that he can get proper attribution?
>>
>> ---
>> libavcodec/vp9.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
>> index c4efd42..d5147e5 100644
>> --- a/libavcodec/vp9.c
>> +++ b/libavcodec/vp9.c
>> @@ -4106,7 +4106,7 @@ static int vp9_decode_frame(AVCodecContext *ctx,
>> void *frame,
>> tile_row, s->tiling.log2_tile_rows,
>> s->sb_rows);
>> if (s->pass != 2) {
>> for (tile_col = 0; tile_col < s->tiling.tile_cols;
>> tile_col++) {
>> -unsigned tile_size;
>> +int64_t tile_size;
>
>
> Hm... OK.
Pushed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: change type of tile_size from unsigned to int64_t
On 07.06.2015 21:03, Luca Barbato wrote: > On 07/06/15 19:02, Andreas Cadhalpun wrote: >> Otherwise the check 'tile_size < size' treats a negative size as >> unsigned, causing the check to pass. This subsequently leads to >> segmentation faults. >> >> This was originally fixed as part of Libav commit 72ca83, so the >> original author is one of the following developers: >> Anton Khirnov >> Diego Biurrun >> Luca Barbato >> Martin Storsjö >> >> Signed-off-by: Andreas Cadhalpun >> --- >> >> Does someone still remember who authored this particular change, >> so that he can get proper attribution? > > I'm not sure about the others but it is enough that you mention the > people involved and use your name for the commit to me. OK, I'll do that then. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] avcodec/apng: Add partial support for blending with PAL8 pixel format
On Mon, Jun 08, 2015 at 02:35:28PM +0200, Paul B Mahol wrote: > On 6/2/15, Donny Yang wrote: > > Currently restricted to blending pixels that only contain either > > 0 or 255 in their alpha components > > > > Signed-off-by: Donny Yang > > --- > > libavcodec/pngdec.c | 15 ++- > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > lgtm applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Test-please ignore
Test of address munging on new server -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] avcodec/apng: Add support for blending with GRAY8A pixel format
On Tue, Jun 02, 2015 at 08:21:36PM +0200, Paul B Mahol wrote:
> On 6/2/15, Donny Yang wrote:
> > On 3 June 2015 at 03:38, Paul B Mahol wrote:
> >
> >> Dana 2. 6. 2015. 17:50 osoba "Donny Yang" napisala je:
> >> >
> >> > Signed-off-by: Donny Yang
> >> > ---
> >> > libavcodec/pngdec.c | 8 +++-
> >> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> >> > index 1f5c433..1667530 100644
> >> > --- a/libavcodec/pngdec.c
> >> > +++ b/libavcodec/pngdec.c
> >> > @@ -891,7 +891,8 @@ static int handle_p_frame_apng(AVCodecContext
> >> > *avctx,
> >> PNGDecContext *s,
> >> > return AVERROR(ENOMEM);
> >> >
> >> > if (s->blend_op == APNG_BLEND_OP_OVER &&
> >> > -avctx->pix_fmt != AV_PIX_FMT_RGBA) {
> >> > +avctx->pix_fmt != AV_PIX_FMT_RGBA &&
> >> > +avctx->pix_fmt != AV_PIX_FMT_GRAY8A) {
> >> > avpriv_request_sample(avctx, "Blending with pixel format %s",
> >> >av_get_pix_fmt_name(avctx->pix_fmt));
> >> > return AVERROR_PATCHWELCOME;
> >> > @@ -935,6 +936,11 @@ static int handle_p_frame_apng(AVCodecContext
> >> *avctx, PNGDecContext *s,
> >> > foreground_alpha = foreground[3];
> >> > background_alpha = background[3];
> >> > break;
> >> > +
> >> > +case AV_PIX_FMT_GRAY8A:
> >> > +foreground_alpha = foreground[1];
> >> > +background_alpha = background[1];
> >> > +break;
> >> > }
> >> >
> >> > if (foreground_alpha == 0)
> >> > --
> >> > 2.4.0
> >>
> >> Is there actual sample?
> >>
> >
> > I have not actually found an apng sample using gray8a, but this is
> > implemented through reading the spec and firefox's source and understanding
> > that gray8a is treated the same as rgba, just with less bytes.
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> ok, patch lgtm
applied
thanks
[...]
--
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 4/6] avcodec/apng: Add blending support for non-alpha pixel formats
On Mon, Jun 08, 2015 at 02:38:39PM +0200, Paul B Mahol wrote: > On 6/2/15, Donny Yang wrote: > > Signed-off-by: Donny Yang > > --- > > libavcodec/pngdec.c | 15 +++ > > 1 file changed, 15 insertions(+) > > > > probably ok applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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/6] avcodec/apng: Dispose previous frame properly
On Mon, Jun 08, 2015 at 02:28:05PM +0200, Paul B Mahol wrote: > On 6/7/15, Donny Yang wrote: > > The spec specifies the dispose operation as how the current (i.e., > > currently > > being rendered) frame should be disposed when the next frame is blended onto > > it > > > > This is contrary to ffmpeg's current behaviour of interpreting the dispose > > operation as how the previous (i.e., already rendered) frame should be > > disposed > > > > This patch fixes ffmpeg's behaviour to match those of the spec, which > > involved > > a rewrite of the blending function > > > > Signed-off-by: Donny Yang > > --- > > libavcodec/pngdec.c | 179 > > +++- > > 1 file changed, 92 insertions(+), 87 deletions(-) > > > > lgtm applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/tls: let the user specify what name to verify against
On Mon, Jun 08, 2015 at 04:50:48AM -0500, Rodger Combs wrote: > This can be useful for debugging, or in scenarios where the user > doesn't want to use the system's DNS settings for whatever reason. > --- > libavformat/tls.c | 13 - > libavformat/tls.h | 7 +-- > 2 files changed, 13 insertions(+), 7 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- 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 4/6] avcodec/apng: Add blending support for non-alpha pixel formats
On 6/2/15, Donny Yang wrote: > Signed-off-by: Donny Yang > --- > libavcodec/pngdec.c | 15 +++ > 1 file changed, 15 insertions(+) > probably ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] avcodec/apng: Add partial support for blending with PAL8 pixel format
On 6/2/15, Donny Yang wrote: > Currently restricted to blending pixels that only contain either > 0 or 255 in their alpha components > > Signed-off-by: Donny Yang > --- > libavcodec/pngdec.c | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/6] avcodec/apng: Dispose previous frame properly
On 6/7/15, Donny Yang wrote: > The spec specifies the dispose operation as how the current (i.e., > currently > being rendered) frame should be disposed when the next frame is blended onto > it > > This is contrary to ffmpeg's current behaviour of interpreting the dispose > operation as how the previous (i.e., already rendered) frame should be > disposed > > This patch fixes ffmpeg's behaviour to match those of the spec, which > involved > a rewrite of the blending function > > Signed-off-by: Donny Yang > --- > libavcodec/pngdec.c | 179 > +++- > 1 file changed, 92 insertions(+), 87 deletions(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Allow overriding /manual setting of the signal standard
On Mon, Jun 08, 2015 at 09:48:33AM +0100, tim nicholson wrote:
> On 06/06/15 02:23, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mxfenc.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index c612747..f2a7f0a 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -316,6 +316,7 @@ typedef struct MXFContext {
> > uint32_t instance_number;
> > uint8_t umid[16];///< unique material identifier
> > int channel_count;
> > +int signal_standard;
> > uint32_t tagged_value_count;
> > AVRational audio_edit_rate;
> > } MXFContext;
> > @@ -2104,6 +2105,8 @@ static int mxf_write_header(AVFormatContext *s)
> >
> > sc->signal_standard = 1;
> > }
> > +if (mxf->signal_standard >= 0)
> > +sc->signal_standard = mxf->signal_standard;
> > } else if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO) {
> > if (st->codec->sample_rate != 48000) {
> > av_log(s, AV_LOG_ERROR, "only 48khz is implemented\n");
> > @@ -2627,7 +2630,12 @@ static int mxf_interleave(AVFormatContext *s,
> > AVPacket *out, AVPacket *pkt, int
> > mxf_interleave_get_packet,
> > mxf_compare_timestamps);
> > }
> >
> > +#define COMMON_OPTIONS \
>
> nit MXF_COMMON_OPTIONS ?
> feels more comfortable to me when grepping the code etc.
>
> > +{ "signal_standard", "Force/set Sigal Standard",\
> > + offsetof(MXFContext, signal_standard), AV_OPT_TYPE_INT, {.i64 = -1},
> > -1, 8, AV_OPT_FLAG_ENCODING_PARAM},
> > +
>
> Isn't 07h the largest valid value (G.2.3)? Or do I misunderstand the
> constraint values? (AVOPTION not my strong point)
>
> I thought numeric options were deprecated these days in favour of more
> understandable string values, or are the string values also too obscure
> to be useful in this case? (Just wondering what the current protocol was
> on this nowadays, not a real concern in this case)
changed
>
> > static const AVOption mxf_options[] = {
> > +COMMON_OPTIONS
> > { NULL },
> > };
> >
> > @@ -2641,6 +2649,7 @@ static const AVClass mxf_muxer_class = {
> > static const AVOption d10_options[] = {
> > { "d10_channelcount", "Force/set channelcount in generic sound essence
> > descriptor",
> >offsetof(MXFContext, channel_count), AV_OPT_TYPE_INT, {.i64 = -1},
> > -1, 8, AV_OPT_FLAG_ENCODING_PARAM},
> > +COMMON_OPTIONS
> > { NULL },
> > };
> >
> > @@ -2654,6 +2663,7 @@ static const AVClass mxf_d10_muxer_class = {
> > static const AVOption opatom_options[] = {
> > { "mxf_audio_edit_rate", "Audio edit rate for timecode",
> > offsetof(MXFContext, audio_edit_rate), AV_OPT_TYPE_RATIONAL,
> > {.dbl=25}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
> > +COMMON_OPTIONS
> > { NULL },
> > };
> >
> >
>
> otherwise LGTM.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Reenable GHA phase inversion in Atrac3+
On Mon, Jun 08, 2015 at 02:17:16AM +0200, Max Pole wrote: > Hello crews, > > I attached two simple patches reenabling a decoder feature been initially > disabled due to lack of real-world samples. > > I've recently got a couple of appropriate samples from the PPSSPP emulator > project so I coud test this feature extensively. > > The 2nd patch is a cosmetical one that renames the "phase_shift" variable > to "inverse_phase". This seems to give a better description of what's > actually going on (180° phase shift). patches applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Reenable GHA phase inversion in Atrac3+
On Mon, Jun 08, 2015 at 03:33:07AM +0200, Max Pole wrote: > > > > > > > I've recently got a couple of appropriate samples from the PPSSPP > > emulator > > > project so I coud test this feature extensively. > > > > where can i find these samples ? > > are they online somewhere? can you upload them ? > > > > I've just uploaded a folder named "atrac3p GHA phase inversion" to > upload.ffmpeg.org/incoming. Hopefully, it does contain everything you need. > > > > > > > Do we need to update FATE tests to include a test for this feature? > > > > a fate test might be interresting if its possible/reliable and > > not too hard to implement > > > > Unfortunately, I don't have no idea how to make FATE tests myself so any > help would be very appreciated! its probably not so important to make a fate test for this also atrac3p uses floats so there could be rounding issues that make this a bit harder if you want to try anyway, look at commits which added fate tests for other decoders. Also ideally we would like to avoid having to add a wav pcm reference to the fate samples, so hopefully one of the samples decodes bit identical between platforms (i can test a few if someone posts a patch adding a fate test) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/tls: let the user specify what name to verify against
This can be useful for debugging, or in scenarios where the user
doesn't want to use the system's DNS settings for whatever reason.
---
libavformat/tls.c | 13 -
libavformat/tls.h | 7 +--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/libavformat/tls.c b/libavformat/tls.c
index adbd7db..9802a70 100644
--- a/libavformat/tls.c
+++ b/libavformat/tls.c
@@ -67,7 +67,7 @@ int ff_tls_open_underlying(TLSShared *c, URLContext *parent,
const char *uri, AV
if (c->listen)
snprintf(opts, sizeof(opts), "?listen=1");
-av_url_split(NULL, 0, NULL, 0, c->host, sizeof(c->host), &port, NULL, 0,
uri);
+av_url_split(NULL, 0, NULL, 0, c->underlying_host,
sizeof(c->underlying_host), &port, NULL, 0, uri);
p = strchr(uri, '?');
@@ -78,16 +78,19 @@ int ff_tls_open_underlying(TLSShared *c, URLContext
*parent, const char *uri, AV
c->listen = 1;
}
-ff_url_join(buf, sizeof(buf), "tcp", NULL, c->host, port, "%s", p);
+ff_url_join(buf, sizeof(buf), "tcp", NULL, c->underlying_host, port, "%s",
p);
hints.ai_flags = AI_NUMERICHOST;
-if (!getaddrinfo(c->host, NULL, &hints, &ai)) {
+if (!getaddrinfo(c->underlying_host, NULL, &hints, &ai)) {
c->numerichost = 1;
freeaddrinfo(ai);
}
+if (!c->host && !(c->host = av_strdup(c->underlying_host)))
+return AVERROR(ENOMEM);
+
proxy_path = getenv("http_proxy");
-use_proxy = !ff_http_match_no_proxy(getenv("no_proxy"), c->host) &&
+use_proxy = !ff_http_match_no_proxy(getenv("no_proxy"),
c->underlying_host) &&
proxy_path && av_strstart(proxy_path, "http://";, NULL);
if (use_proxy) {
@@ -96,7 +99,7 @@ int ff_tls_open_underlying(TLSShared *c, URLContext *parent,
const char *uri, AV
av_url_split(NULL, 0, proxy_auth, sizeof(proxy_auth),
proxy_host, sizeof(proxy_host), &proxy_port, NULL, 0,
proxy_path);
-ff_url_join(dest, sizeof(dest), NULL, NULL, c->host, port, NULL);
+ff_url_join(dest, sizeof(dest), NULL, NULL, c->underlying_host, port,
NULL);
ff_url_join(buf, sizeof(buf), "httpproxy", proxy_auth, proxy_host,
proxy_port, "/%s", dest);
}
diff --git a/libavformat/tls.h b/libavformat/tls.h
index 959bada..2a36f34 100644
--- a/libavformat/tls.h
+++ b/libavformat/tls.h
@@ -35,7 +35,9 @@ typedef struct TLSShared {
char *key_file;
int listen;
-char host[200];
+char *host;
+
+char underlying_host[200];
int numerichost;
URLContext *tcp;
@@ -48,7 +50,8 @@ typedef struct TLSShared {
{"tls_verify", "Verify the peer certificate", offsetof(pstruct,
options_field . verify),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags =
TLS_OPTFL }, \
{"cert_file", "Certificate file",offsetof(pstruct,
options_field . cert_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
{"key_file", "Private key file",offsetof(pstruct,
options_field . key_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
-{"listen", "Listen for incoming connections", offsetof(pstruct,
options_field . listen),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags =
TLS_OPTFL }
+{"listen", "Listen for incoming connections", offsetof(pstruct,
options_field . listen),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags =
TLS_OPTFL }, \
+{"verifyhost", "Verify against a specific hostname", offsetof(pstruct,
options_field . host), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }
int ff_tls_open_underlying(TLSShared *c, URLContext *parent, const char *uri,
AVDictionary **options);
--
2.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Allow overriding /manual setting of the signal standard
On 06/06/15 02:23, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfenc.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index c612747..f2a7f0a 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -316,6 +316,7 @@ typedef struct MXFContext {
> uint32_t instance_number;
> uint8_t umid[16];///< unique material identifier
> int channel_count;
> +int signal_standard;
> uint32_t tagged_value_count;
> AVRational audio_edit_rate;
> } MXFContext;
> @@ -2104,6 +2105,8 @@ static int mxf_write_header(AVFormatContext *s)
>
> sc->signal_standard = 1;
> }
> +if (mxf->signal_standard >= 0)
> +sc->signal_standard = mxf->signal_standard;
> } else if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO) {
> if (st->codec->sample_rate != 48000) {
> av_log(s, AV_LOG_ERROR, "only 48khz is implemented\n");
> @@ -2627,7 +2630,12 @@ static int mxf_interleave(AVFormatContext *s, AVPacket
> *out, AVPacket *pkt, int
> mxf_interleave_get_packet,
> mxf_compare_timestamps);
> }
>
> +#define COMMON_OPTIONS \
nit MXF_COMMON_OPTIONS ?
feels more comfortable to me when grepping the code etc.
> +{ "signal_standard", "Force/set Sigal Standard",\
> + offsetof(MXFContext, signal_standard), AV_OPT_TYPE_INT, {.i64 = -1},
> -1, 8, AV_OPT_FLAG_ENCODING_PARAM},
> +
Isn't 07h the largest valid value (G.2.3)? Or do I misunderstand the
constraint values? (AVOPTION not my strong point)
I thought numeric options were deprecated these days in favour of more
understandable string values, or are the string values also too obscure
to be useful in this case? (Just wondering what the current protocol was
on this nowadays, not a real concern in this case)
> static const AVOption mxf_options[] = {
> +COMMON_OPTIONS
> { NULL },
> };
>
> @@ -2641,6 +2649,7 @@ static const AVClass mxf_muxer_class = {
> static const AVOption d10_options[] = {
> { "d10_channelcount", "Force/set channelcount in generic sound essence
> descriptor",
>offsetof(MXFContext, channel_count), AV_OPT_TYPE_INT, {.i64 = -1}, -1,
> 8, AV_OPT_FLAG_ENCODING_PARAM},
> +COMMON_OPTIONS
> { NULL },
> };
>
> @@ -2654,6 +2663,7 @@ static const AVClass mxf_d10_muxer_class = {
> static const AVOption opatom_options[] = {
> { "mxf_audio_edit_rate", "Audio edit rate for timecode",
> offsetof(MXFContext, audio_edit_rate), AV_OPT_TYPE_RATIONAL,
> {.dbl=25}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
> +COMMON_OPTIONS
> { NULL },
> };
>
>
otherwise LGTM.
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers and ICD loader
> -Original Message-
> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> boun...@ffmpeg.org] On Behalf Of Hendrik Leppkes
> Sent: Monday, June 08, 2015 1:00 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers
> and ICD loader
>
> On Mon, Jun 8, 2015 at 5:53 AM, Gupta, Maneesh
> wrote:
> >> -Original Message-
> >> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> >> boun...@ffmpeg.org] On Behalf Of James Almer
> >> Sent: Thursday, May 28, 2015 10:06 AM
> >> To: FFmpeg development discussions and patches
> >> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL
> >> headers and ICD loader
> >>
> >> On 28/05/15 12:28 AM, Gupta, Maneesh wrote:
> >> > Attached is a patch that enables configure to autodetect the
> >> > presence of
> >> OpenCL headers and ICD loader. If the necessary headers are found,
> >> the OpenCL infrastructure compilation is enabled as well. Note that
> >> this does not modify the runtime behavior in any way. Execution of
> >> the OpenCL code path still requires the user to explicitly enable it.
> >> >
> >> > Please review the patch and share your comments on the same.
> >> >
> >> > - Maneesh
> >>
> >> I personally don't agree OpenCL should be autodetected.
> >>
> >> Currently, only the so called "system" libs are autodetected (zlib,
> >> iconv, pthreads, the like). Open*L, decoding/encoding libraries, and
> >> other miscellaneous libraries are enabled only if explicitly requested.
> >> If we enable one by default, then there's no argument against
> >> enabling every other as well ("Why this one but not that other
> >> one?"), and suddenly default builds become bloated and automated
> >> scripts get potentially broken until adapted.
> >>
> >> Lets keep default builds as lightweight as possible, and allow people
> >> to explicitly enable the functionality they require.
> >
> > [Gupta, Maneesh] Apologize for the delayed response. However grep'ing
> the string "autodetect" in the configure script throws up several "non-
> system" libs including D3D11VA, DXVA2, VAAPI, VDA, VDPAU, sdl. Why are
> they turned on by default? Several of these non-system libs enable use of
> hardware acceleration. OpenCL is similar in nature with a key difference that
> it is more platform/OS agnostic and can run on both CPU as well as GPU.
>
> Most of those don't link against any library, ie. like DXVA2, it doesn't add
> any
> extra link dependencies which are not system libraries, so the resulting build
> is still perfectly portable.
> For the few exceptions that do add link deps, we suffer for that enough, we
> don't need any more "exceptions".
>
> - Hendrik
[Gupta, Maneesh] The OpenCL code only links against the ICD loader. Also x264
enables OpenCL code by default and the build is perfectly portable as far as I
have seen. I don't see how that is not possible in the case of ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil/doc: Changes in documentation due to changes to fixed_dsp
>> On Fri, Jun 05, 2015 at 08:05:33PM +0200, Michael Niedermayer wrote: >>> On Fri, Jun 05, 2015 at 07:59:47PM +0200, Michael Niedermayer wrote: On Fri, Jun 05, 2015 at 10:04:54AM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Jun 5, 2015 at 5:54 AM, Nedeljko Babic > wrote: > >> New functions are added to fixed_dsp, so the documentation is changed >> accordingly. >> >> Signed-off-by: Nedeljko Babic >> --- >> doc/APIchanges | 7 +++ >> libavutil/version.h | 2 +- >> 2 files changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/doc/APIchanges b/doc/APIchanges >> index 5c36dca..bcf4fe6 100644 >> --- a/doc/APIchanges >> +++ b/doc/APIchanges >> @@ -15,6 +15,13 @@ libavutil: 2014-08-09 >> >> API changes, most recent first: >> >> +2015-06-05 - xxx - lavu 54.27.101 - fixed_dsp.h >> + Add vector_fmul() >> + Add vector_fmul_reverse() >> + Add vector_fmul_add() >> + Add scalarproduct_fixed() >> + Add butterflies_fixed() > > > These functions are not part of our public API, are they? It appears that the header isnt installed currently, ill post a patch to correct that >>> >>> hmm, it seems thats not possible >>> it contains >>> #include "libavcodec/mathops.h" >>> which is not a public header and from libavcodec >>> >>> ill revert the addition to APIchanges >>> >>> nedeljko, can you fix that header so it can be installed or move the >>> content to libavcodec. Depending on what the people prefer >> >> or as james pointed out on IRC >> does it need to be installed for that matter? it's essentially the >> same as float_dsp, and that one has always been internal >> >> >> i wonder if it shouldnt be renamed to AVPrivFixedDSPContext in that >> case then though > >Considering other internal structs are called AVWhatever, including >AVFloatDSPContext, >a name change is probably not necessary. > >And unless there's an actual need for these functions to be used outside >libav*, lets >stop at removing the APIchanges lines that were wrongly added. Anything else >is just >making changes for no realgain. I wasn't checking mails during the weekend, so I am a bit late following on this... I made this to be as much similar to float_dsp as possible, so I think it should be handled in the same way. If some additional changes are needed, please let me know. Thanks, Nedeljko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers and ICD loader
On Mon, Jun 8, 2015 at 5:53 AM, Gupta, Maneesh wrote:
>> -Original Message-
>> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
>> boun...@ffmpeg.org] On Behalf Of James Almer
>> Sent: Thursday, May 28, 2015 10:06 AM
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers
>> and ICD loader
>>
>> On 28/05/15 12:28 AM, Gupta, Maneesh wrote:
>> > Attached is a patch that enables configure to autodetect the presence of
>> OpenCL headers and ICD loader. If the necessary headers are found, the
>> OpenCL infrastructure compilation is enabled as well. Note that this does not
>> modify the runtime behavior in any way. Execution of the OpenCL code path
>> still requires the user to explicitly enable it.
>> >
>> > Please review the patch and share your comments on the same.
>> >
>> > - Maneesh
>>
>> I personally don't agree OpenCL should be autodetected.
>>
>> Currently, only the so called "system" libs are autodetected (zlib, iconv,
>> pthreads, the like). Open*L, decoding/encoding libraries, and other
>> miscellaneous libraries are enabled only if explicitly requested.
>> If we enable one by default, then there's no argument against enabling
>> every other as well ("Why this one but not that other one?"), and suddenly
>> default builds become bloated and automated scripts get potentially broken
>> until adapted.
>>
>> Lets keep default builds as lightweight as possible, and allow people to
>> explicitly enable the functionality they require.
>
> [Gupta, Maneesh] Apologize for the delayed response. However grep'ing the
> string "autodetect" in the configure script throws up several "non-system"
> libs including D3D11VA, DXVA2, VAAPI, VDA, VDPAU, sdl. Why are they turned on
> by default? Several of these non-system libs enable use of hardware
> acceleration. OpenCL is similar in nature with a key difference that it is
> more platform/OS agnostic and can run on both CPU as well as GPU.
Most of those don't link against any library, ie. like DXVA2, it
doesn't add any extra link dependencies which are not system
libraries, so the resulting build is still perfectly portable.
For the few exceptions that do add link deps, we suffer for that
enough, we don't need any more "exceptions".
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
