date:20170220

Re: [FFmpeg-devel] [PATCH] hlsenc: don't use %s for strftime on msvc

2017-02-20 Thread Hendrik Leppkes

On Tue, Feb 21, 2017 at 8:24 AM, Hendrik Leppkes  wrote:
> MSVC doesn't support the %s time format, and instead of returning an
> error the invalid parameter handler is invoked which (by default)
> terminates the process.
> ---
>  libavformat/hlsenc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index e673f59710..cf2e3381c4 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1025,7 +1025,8 @@ static const char * 
> get_default_pattern_localtime_fmt(void)
>  struct tm *p, tmbuf;
>  p = localtime_r(, );
>  // no %s support when strftime returned error or left format string 
> unchanged
> -return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ? 
> "-%Y%m%d%H%M%S.ts" : "-%s.ts";
> +// also no %s support on MSVC, which invokes the invalid parameter 
> handler on unsupported format strings, instead of returning an error
> +return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || 
> !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts";
>  }
>
>  static int hls_write_header(AVFormatContext *s)
> --
> 2.11.0.windows.1
>

An alternative would be testing for %s support in configure somehow
and setting a config variable for that, instead of probing at runtime
here.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] hlsenc: don't use %s for strftime on msvc

2017-02-20 Thread Hendrik Leppkes

MSVC doesn't support the %s time format, and instead of returning an
error the invalid parameter handler is invoked which (by default)
terminates the process.
---
 libavformat/hlsenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e673f59710..cf2e3381c4 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1025,7 +1025,8 @@ static const char * 
get_default_pattern_localtime_fmt(void)
 struct tm *p, tmbuf;
 p = localtime_r(, );
 // no %s support when strftime returned error or left format string 
unchanged
-return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ? 
"-%Y%m%d%H%M%S.ts" : "-%s.ts";
+// also no %s support on MSVC, which invokes the invalid parameter handler 
on unsupported format strings, instead of returning an error
+return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || !strcmp(b, 
"%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts";
 }
 
 static int hls_write_header(AVFormatContext *s)
-- 
2.11.0.windows.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/buffersrc: fix directly setting channel layout

2017-02-20 Thread Rostislav Pehlivanov

When setting the channel layout directly using AVBufferSrcParameters
the channel layout was correctly set however the init function still
expected the old string format to set the number of channels (when it
hadn't already been specified).

Signed-off-by: Rostislav Pehlivanov 
---
 libavfilter/buffersrc.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 77fd174219..37d1992b50 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -341,14 +341,16 @@ static av_cold int init_audio(AVFilterContext *ctx)
 return AVERROR(EINVAL);
 }
 
-if (s->channel_layout_str) {
+if (s->channel_layout_str || s->channel_layout) {
 int n;
 
-s->channel_layout = av_get_channel_layout(s->channel_layout_str);
-if (!s->channel_layout) {
-av_log(ctx, AV_LOG_ERROR, "Invalid channel layout %s.\n",
-   s->channel_layout_str);
-return AVERROR(EINVAL);
+if (s->channel_layout_str) {
+s->channel_layout = av_get_channel_layout(s->channel_layout_str);
+if (!s->channel_layout) {
+av_log(ctx, AV_LOG_ERROR, "Invalid channel layout %s.\n",
+   s->channel_layout_str);
+return AVERROR(EINVAL);
+}
 }
 n = av_get_channel_layout_nb_channels(s->channel_layout);
 if (s->channels) {
-- 
2.12.0.rc1.440.g5b76565f74

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: drawtext options update

2017-02-20 Thread Mulvya V

Hi,

Revised patch to include basetime option.

Thanks,
mulvya

On Sun, Feb 19, 2017 at 10:00 PM, Mulvya V  wrote:

> Hi,
>
> Added entry for hitherto undocumented timecode wrap option. Removed
> bizarre entry for non-existent draw option.
>
> Haven't added entry for basetime option since it applies only in strftime
> expansion mode. Should it be documented?
>
> Thanks,
> mulvya
>


0002-doc-update-drawtext-options.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: drawtext options update

2017-02-20 Thread Lou Logan

Hi,

On Sun, Feb 19, 2017, at 07:30 AM, Mulvya V wrote:
> Haven't added entry for basetime option since it applies only in strftime
> expansion mode. Should it be documented?

If it still works, sure, as long as it is clear that it only applies to
the deprecated strftime mode. I think we should keep the documentation
in sync with existing options even if they are considered deprecated and
marked as such (and inform the user of what to use instead, if
possible). The documentation, in theory, can be updated when/if the
feature is finally removed.

Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mpeg: Initialize a stack variable

2017-02-20 Thread Carl Eugen Hoyos

2017-02-21 2:09 GMT+01:00 Michael Niedermayer :
> On Sun, Feb 19, 2017 at 04:18:16PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I cannot reproduce ticket #6160 and I wonder how memcmp() must be implemented
>> to reproduce it but attached patch is supposed to fix it.
>>
>> Please comment, Carl Eugen
>
>>  mpeg.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> c1f797e970fc296e35beb0b7701feb11e1d470f4  
>> 0001-lavf-mpeg-Initialize-a-stack-variable-used-by-memcmp.patch
>> From 0c3a72da0780682eb2899aee7ebe05a5e74a26eb Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sun, 19 Feb 2017 16:15:34 +0100
>> Subject: [PATCH] lavf/mpeg: Initialize a stack variable used by memcmp().
>>
>> Fixes ticket #6160.
>
> LGTM

Pushed and backported.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mpeg: Initialize a stack variable

2017-02-20 Thread Michael Niedermayer

On Sun, Feb 19, 2017 at 04:18:16PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> I cannot reproduce ticket #6160 and I wonder how memcmp() must be implemented 
> to reproduce it but attached patch is supposed to fix it.
> 
> Please comment, Carl Eugen

>  mpeg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> c1f797e970fc296e35beb0b7701feb11e1d470f4  
> 0001-lavf-mpeg-Initialize-a-stack-variable-used-by-memcmp.patch
> From 0c3a72da0780682eb2899aee7ebe05a5e74a26eb Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 19 Feb 2017 16:15:34 +0100
> Subject: [PATCH] lavf/mpeg: Initialize a stack variable used by memcmp().
> 
> Fixes ticket #6160.

LGTM

please also backport

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavd/opengl: Support BGR48

2017-02-20 Thread Carl Eugen Hoyos

Hi!

Will apply if I there are no objections.

Thank you, Carl Eugen
From 2ebd6b283c5c881bf57fa3b0fe7d352ef447f117 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 21 Feb 2017 02:06:06 +0100
Subject: [PATCH] lavd/opengl_enc: Support BGR48.

---
 libavdevice/opengl_enc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index 94259a2..3e643b0 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -261,6 +261,7 @@ static const struct OpenGLFormatDesc {
 { AV_PIX_FMT_RGB8,   _OPENGL_FRAGMENT_SHADER_RGB_PACKET,  GL_RGB, 
FF_GL_UNSIGNED_BYTE_3_3_2 },
 { AV_PIX_FMT_BGR8,   _OPENGL_FRAGMENT_SHADER_RGB_PACKET,  GL_RGB, 
FF_GL_UNSIGNED_BYTE_2_3_3_REV },
 { AV_PIX_FMT_RGB48,  _OPENGL_FRAGMENT_SHADER_RGB_PACKET,  GL_RGB, 
GL_UNSIGNED_SHORT },
+{ AV_PIX_FMT_BGR48,  _OPENGL_FRAGMENT_SHADER_RGB_PACKET,  GL_RGB, 
GL_UNSIGNED_SHORT },
 { AV_PIX_FMT_ARGB,   _OPENGL_FRAGMENT_SHADER_RGBA_PACKET, GL_RGBA, 
GL_UNSIGNED_BYTE },
 { AV_PIX_FMT_RGBA,   _OPENGL_FRAGMENT_SHADER_RGBA_PACKET, GL_RGBA, 
GL_UNSIGNED_BYTE },
 { AV_PIX_FMT_ABGR,   _OPENGL_FRAGMENT_SHADER_RGBA_PACKET, GL_RGBA, 
GL_UNSIGNED_BYTE },
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] add locale month names to av_small_strptime

2017-02-20 Thread Micah Galizia

Signed-off-by: Micah Galizia 
---
 libavutil/parseutils.c   | 28 
 libavutil/tests/parseutils.c |  7 +++
 tests/ref/fate/parseutils|  7 +++
 3 files changed, 42 insertions(+)

diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 86d3dac..7ca07b3 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -140,6 +140,11 @@ static const VideoRateAbbr video_rate_abbrs[]= {
 { "ntsc-film", { 24000, 1001 } },
 };
 
+static const char *months[12] = {
+"january", "february", "march", "april", "may", "june", "july", "august",
+"september", "october", "november", "december"
+};
+
 int av_parse_video_size(int *width_ptr, int *height_ptr, const char *str)
 {
 int i;
@@ -466,6 +471,21 @@ static int date_get_num(const char **pp,
 return val;
 }
 
+static int date_get_month(const char **pp) {
+int i = 0;
+for (; i < 12; i++) {
+if (!av_strncasecmp(*pp, months[i], 3)) {
+const char *mo_full = months[i] + 3;
+int len = strlen(mo_full);
+*pp += 3;
+if (len > 0 && !av_strncasecmp(*pp, mo_full, len))
+*pp += len;
+return i;
+}
+}
+return -1;
+}
+
 char *av_small_strptime(const char *p, const char *fmt, struct tm *dt)
 {
 int c, val;
@@ -525,6 +545,14 @@ char *av_small_strptime(const char *p, const char *fmt, 
struct tm *dt)
 if (!p)
 return NULL;
 break;
+case 'b':
+case 'B':
+case 'h':
+val = date_get_month();
+if (val == -1)
+return NULL;
+dt->tm_mon = val;
+break;
 case '%':
 if (*p++ != '%')
 return NULL;
diff --git a/libavutil/tests/parseutils.c b/libavutil/tests/parseutils.c
index 682b390..180f624 100644
--- a/libavutil/tests/parseutils.c
+++ b/libavutil/tests/parseutils.c
@@ -138,6 +138,13 @@ static void test_av_small_strptime(void)
 { "%Y - %m - %d","2012-12-21" },
 { "%Y-%m-%d %H:%M:%S",   "2012-12-21 20:12:21" },
 { "  %Y - %m - %d %H : %M : %S", "   2012 - 12 -  21   20 : 12 : 21" },
+{ "  %Y - %b - %d %H : %M : %S", "   2012 - nOV -  21   20 : 12 : 21" 
},
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - nOVemBeR -  21   20 : 12 : 
21" },
+{ "  %Y - %B%d %H : %M : %S", "   2012 - may21   20 : 12 : 21" },
+{ "  %Y - %B%d %H : %M : %S", "   2012 - mby21   20 : 12 : 21" },
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - JunE -  21   20 : 12 : 21" 
},
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - Jane -  21   20 : 12 : 21" 
},
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - January -  21   20 : 12 : 
21" },
 };
 
 av_log_set_level(AV_LOG_DEBUG);
diff --git a/tests/ref/fate/parseutils b/tests/ref/fate/parseutils
index 1aad5ec..568b6d2 100644
--- a/tests/ref/fate/parseutils
+++ b/tests/ref/fate/parseutils
@@ -68,6 +68,13 @@ fmt:'%Y-%m-%d' spec:'2012-12-21' -> 2012-12-21 00:00:00
 fmt:'%Y - %m - %d' spec:'2012-12-21' -> 2012-12-21 00:00:00
 fmt:'%Y-%m-%d %H:%M:%S' spec:'2012-12-21 20:12:21' -> 2012-12-21 20:12:21
 fmt:'  %Y - %m - %d %H : %M : %S' spec:'   2012 - 12 -  21   20 : 12 : 21' -> 
2012-12-21 20:12:21
+fmt:'  %Y - %b - %d %H : %M : %S' spec:'   2012 - nOV -  21   20 : 12 : 21' -> 
2012-11-21 20:12:21
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - nOVemBeR -  21   20 : 12 : 
21' -> 2012-11-21 20:12:21
+fmt:'  %Y - %B%d %H : %M : %S' spec:'   2012 - may21   20 : 12 : 21' -> 
2012-05-21 20:12:21
+fmt:'  %Y - %B%d %H : %M : %S' spec:'   2012 - mby21   20 : 12 : 21' -> error
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - JunE -  21   20 : 12 : 21' 
-> 2012-06-21 20:12:21
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - Jane -  21   20 : 12 : 21' 
-> error
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - January -  21   20 : 12 : 
21' -> 2012-01-21 20:12:21
 
 Testing av_parse_time()
 (now is 2012-03-17 09:14:13.2 +0100, local time is UTC+1)
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add locale month names to av_small_strptime

2017-02-20 Thread Micah Galizia

Sorry about that -- this actually makes sense now -- I thought it was a bit odd 
that the test program had no asserts or anything to validate the output...

I've addressed the fate issues in this patch -- thanks again for the review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add locale month names to av_small_strptime

2017-02-20 Thread Michael Niedermayer

On Mon, Feb 20, 2017 at 03:30:43PM -0500, Micah Galizia wrote:
> Signed-off-by: Micah Galizia 
> ---
>  libavutil/parseutils.c   | 28 
>  libavutil/tests/parseutils.c |  7 +++
>  2 files changed, 35 insertions(+)

breaks fate
--- ./tests/ref/fate/parseutils 2017-02-20 17:22:51.749108272 +0100
+++ tests/data/fate/parseutils  2017-02-21 01:04:00.337691174 +0100
@@ -68,6 +68,13 @@
 fmt:'%Y - %m - %d' spec:'2012-12-21' -> 2012-12-21 00:00:00
 fmt:'%Y-%m-%d %H:%M:%S' spec:'2012-12-21 20:12:21' -> 2012-12-21 20:12:21
 fmt:'  %Y - %m - %d %H : %M : %S' spec:'   2012 - 12 -  21   20 : 12 : 21' -> 
2012-12-21 20:12:21
+fmt:'  %Y - %b - %d %H : %M : %S' spec:'   2012 - nOV -  21   20 : 12 : 21' -> 
2012-11-21 20:12:21
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - nOVemBeR -  21   20 : 12 : 
21' -> 2012-11-21 20:12:21
+fmt:'  %Y - %B%d %H : %M : %S' spec:'   2012 - may21   20 : 12 : 21' -> 
2012-05-21 20:12:21
+fmt:'  %Y - %B%d %H : %M : %S' spec:'   2012 - mby21   20 : 12 : 21' -> error
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - JunE -  21   20 : 12 : 21' 
-> 2012-06-21 20:12:21
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - Jane -  21   20 : 12 : 21' 
-> error
+fmt:'  %Y - %B - %d %H : %M : %S' spec:'   2012 - January -  21   20 : 12 : 
21' -> 2012-01-21 20:12:21

 Testing av_parse_time()
 (now is 2012-03-17 09:14:13.2 +0100, local time is UTC+1)
Test parseutils failed. Look at tests/data/fate/parseutils.err for details.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] speedhq: fix decoding artifacts

2017-02-20 Thread Michael Niedermayer

On Sat, Feb 18, 2017 at 08:37:26PM +0100, Paul B Mahol wrote:
> On 2/18/17, Steinar H. Gunderson  wrote:
> > The quantization table is stored in the natural order, but when we
> > access it, we use an index that's in zigzag order, causing us to read
> > the wrong value. This causes artifacts, especially in areas with
> > horizontal or vertical edges. The artifacts look a lot like the
> > DCT ringing artifacts you'd expect to see from a low-bitrate file,
> > but when comparing to NewTek's own decoder, it's obvious they're not
> > supposed to be there.
> >
> > Fix by simply storing the scaled quantization table in zigzag order.
> > Performance is unchanged.
> > ---
> >  libavcodec/speedhq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
> > index 45ee37a4e6..60efb0222b 100644
> > --- a/libavcodec/speedhq.c
> > +++ b/libavcodec/speedhq.c
> > @@ -409,7 +409,7 @@ static int decode_speedhq_field(const SHQContext *s,
> > const uint8_t *buf, int buf
> >  static void compute_quant_matrix(int *output, int qscale)
> >  {
> >  int i;
> > -for (i = 0; i < 64; i++) output[i] = unscaled_quant_matrix[i] * qscale;
> > +for (i = 0; i < 64; i++) output[i] =
> > unscaled_quant_matrix[ff_zigzag_direct[i]] * qscale;
> >  }
> >
> >  static int speedhq_decode_frame(AVCodecContext *avctx,
> > --
> > 2.11.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> lgtm

applied

thx

[...]
-- 
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

[FFmpeg-devel] [PATCH] avcodec/lzwenc: Remove padding byte when writing gif

2017-02-20 Thread contact


Will Storey will at summercat.com wrote on Mon Feb 20 22:46:34 EET 2017:
No longer write a final 0x00 byte when flushing the LZW bitstream. 
There

is no mention of doing this in GIF89a specification to do this, and
decoders may not expect it.



Adding this byte for padding was added in commit
b4e2e03709996a0836f6a71535d48b50201338eb apparently to resolve an issue
with GIMP. I could not find any background about this issue. Possibly
the GIMP decoder had an issue (it appears to handle gifs without this
byte fine today).

Signed-off-by: William Storey 


In the past I've noticed that situation myself, as well, so I decided to
take a few minutes to look into the issue today.

Your change seems to work for the current state of the gif loader plugin
in the current versions of GIMP, which made me figure that perhaps this
(s->mode == FF_LZW_GIF) logic is no longer needed.

So I decided to look around at the GIMP code base, where I found the
following commit that seemed related to this:

https://github.com/GNOME/gimp/commit/f86655bb1fcf356524c1894096f4866633cc7666

The plugin code itself is a bit of heavy reading, so I could be 
mistaken,

but the impression I get from examining this code suggests that older
packages using pre-2013 versions of GIMP were likely affected by this 
bug.


I wonder if maybe the ffmpeg commit 
b4e2e03709996a0836f6a71535d48b50201338eb
was needed back then, possibly for users who had not yet upgraded to 
newer

versions of GIMP packages. So from that point of view, it made sense to
continue to perform that check, at least until that particular GIMP had
become more mainstreamed.

Now, given that GIMP no longer contains that out-of-input-bits 
condition,

and hasn't for a number of years, I think revisiting the arguments for
keeping this might be warranted.

Alternatively, if anyone knows any other application that behaves in a
manner requiring this code, or if there is some obscure-but-essential
reason, I suppose we could keep it. At this time, however, it appears
to me that only GIMP might have actually needed it.

-Robert Bisewski
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: add ScreenPressor decoder

2017-02-20 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavcodec/scpr.c   | 799 
 libavformat/riff.c  |   1 +
 6 files changed, 810 insertions(+)
 create mode 100644 libavcodec/scpr.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a1ce264..1bea44a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -509,6 +509,7 @@ OBJS-$(CONFIG_SAMI_DECODER)+= samidec.o ass.o 
htmlsubtitles.o
 OBJS-$(CONFIG_S302M_DECODER)   += s302m.o
 OBJS-$(CONFIG_S302M_ENCODER)   += s302menc.o
 OBJS-$(CONFIG_SANM_DECODER)+= sanm.o
+OBJS-$(CONFIG_SCPR_DECODER)+= scpr.o
 OBJS-$(CONFIG_SCREENPRESSO_DECODER)+= screenpresso.o
 OBJS-$(CONFIG_SDX2_DPCM_DECODER)   += dpcm.o
 OBJS-$(CONFIG_SGI_DECODER) += sgidec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f12a54d..eee322b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -307,6 +307,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(RV40,  rv40);
 REGISTER_ENCDEC (S302M, s302m);
 REGISTER_DECODER(SANM,  sanm);
+REGISTER_DECODER(SCPR,  scpr);
 REGISTER_DECODER(SCREENPRESSO,  screenpresso);
 REGISTER_DECODER(SDX2_DPCM, sdx2_dpcm);
 REGISTER_ENCDEC (SGI,   sgi);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5616fb0..925a8c7 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -415,6 +415,7 @@ enum AVCodecID {
 AV_CODEC_ID_PIXLET,
 AV_CODEC_ID_SPEEDHQ,
 AV_CODEC_ID_FMVC,
+AV_CODEC_ID_SCPR,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 35846c0..42935d7 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1360,6 +1360,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("FM Screen Capture Codec"),
 .props = AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_SCPR,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "scpr",
+.long_name = NULL_IF_CONFIG_SMALL("ScreenPressor"),
+.props = AV_CODEC_PROP_LOSSLESS | AV_CODEC_PROP_LOSSY,
+},
 
 /* image codecs */
 {
diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
new file mode 100644
index 000..e151e3a
--- /dev/null
+++ b/libavcodec/scpr.c
@@ -0,0 +1,799 @@
+/*
+ * ScreenPressor decoder
+ *
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+#define TOP  0x0100
+#define BOT0x01
+
+typedef struct RangeCoder {
+unsigned   code;
+unsigned   range;
+} RangeCoder;
+
+typedef struct SCPRContext {
+AVFrame*last_frame;
+AVFrame*current_frame;
+GetByteContext  gb;
+RangeCoder  rc;
+unsignedcn[3][4096 * 273];
+unsignedptype[6][7];
+unsignedn[6][257];
+unsignedxx[257];
+unsignedn2[257];
+unsignedbt[6];
+unsignedsxy[4][17];
+unsignedmv[2][513];
+unsignednbx, nby;
+unsignednbcount;
+unsigned   *bts;
+int cxshift;
+} SCPRContext;
+
+static void init_rangecoder(RangeCoder *rc, GetByteContext *gb)
+{
+rc->code  = 0;
+rc->range = 0xU;
+rc->code  = bytestream2_get_be32(gb);
+}
+
+static void reinit_tables(SCPRContext *s)
+{
+int comp, i, j;
+
+for (comp = 0; comp < 3; comp++) {
+for (j = 0; j < 4096; j++) {
+int p = j * 273;
+if (s->cn[comp][p + 16] != 256) {
+for (i = 0; i < 256; i++)
+s->cn[comp][p + i + 17] = 1;
+for (i = 0; i < 16; i++)
+s->cn[comp][p + i] = 16;
+s->cn[comp][p + 16] = 256;
+}

[FFmpeg-devel] [PATCH] avcodec/lzwenc: Remove padding byte when writing gif

2017-02-20 Thread Will Storey

No longer write a final 0x00 byte when flushing the LZW bitstream. There
is no mention of doing this in GIF89a specification to do this, and
decoders may not expect it.

Adding this byte for padding was added in commit
b4e2e03709996a0836f6a71535d48b50201338eb apparently to resolve an issue
with GIMP. I could not find any background about this issue. Possibly
the GIMP decoder had an issue (it appears to handle gifs without this
byte fine today).

Signed-off-by: William Storey 
---
 libavcodec/lzwenc.c |  2 --
 tests/ref/fate/gifenc-bgr4_byte | 64 -
 tests/ref/fate/gifenc-bgr8  | 60 +++---
 tests/ref/fate/gifenc-gray  | 56 ++--
 tests/ref/fate/gifenc-pal8  | 60 +++---
 tests/ref/fate/gifenc-rgb4_byte | 64 -
 tests/ref/fate/gifenc-rgb8  | 60 +++---
 7 files changed, 182 insertions(+), 184 deletions(-)

diff --git a/libavcodec/lzwenc.c b/libavcodec/lzwenc.c
index 03080ee587..f9021e1ca9 100644
--- a/libavcodec/lzwenc.c
+++ b/libavcodec/lzwenc.c
@@ -263,8 +263,6 @@ int ff_lzw_encode_flush(LZWEncodeState *s,
 if (s->last_code != -1)
 writeCode(s, s->last_code);
 writeCode(s, s->end_code);
-if (s->mode == FF_LZW_GIF)
-s->put_bits(>pb, 1, 0);
 
 lzw_flush_put_bits(>pb);
 s->last_code = -1;
diff --git a/tests/ref/fate/gifenc-bgr4_byte b/tests/ref/fate/gifenc-bgr4_byte
index 3495a8bbed..423572ac82 100644
--- a/tests/ref/fate/gifenc-bgr4_byte
+++ b/tests/ref/fate/gifenc-bgr4_byte
@@ -3,58 +3,58 @@
 #codec_id 0: gif
 #dimensions 0: 217x217
 #sar 0: 0/1
-0,  0,  0,1,  508, 0xa1b80fc0
+0,  0,  0,1,  507, 0x91080fbf
 0,  1,  1,1,  213, 0x4f554bd7, S=1, 1024, 
0xb6327c81
-0,  2,  2,1,  131, 0x283b2988, S=1, 1024, 
0xae3a7c81
+0,  2,  2,1,  130, 0xfe2d2987, S=1, 1024, 
0xae3a7c81
 0,  3,  3,1,  384, 0xc4fea72a, S=1, 1024, 
0xb6327c81
 0,  4,  4,1,  381, 0x050ba2b8, S=1, 1024, 
0x9e4a7c81
 0,  5,  5,1,  430, 0x00cfb2ae, S=1, 1024, 
0x9e4a7c81
-0,  6,  6,1,  518, 0xc8e5d827, S=1, 1024, 
0x9e4a7c81
+0,  6,  6,1,  517, 0xefb5d826, S=1, 1024, 
0x9e4a7c81
 0,  7,  7,1,  535, 0x326ce62a, S=1, 1024, 
0x9e4a7c81
-0,  8,  8,1,  438, 0x34d6b7c0, S=1, 1024, 
0xb6327c81
+0,  8,  8,1,  437, 0x7c5db7bf, S=1, 1024, 
0xb6327c81
 0,  9,  9,1,  923, 0x9fb1a37c, S=1, 1024, 
0xb6327c81
-0, 10, 10,1,  694, 0xf20449a5, S=1, 1024, 
0xb6327c81
+0, 10, 10,1,  693, 0xa7b549a4, S=1, 1024, 
0xb6327c81
 0, 11, 11,1, 1194, 0x67cd2ab5, S=1, 1024, 
0xb6327c81
 0, 12, 12,1, 1291, 0x1d23539d, S=1, 1024, 
0xb6327c81
 0, 13, 13,1, 1245, 0x065f32e6, S=1, 1024, 
0xb6327c81
 0, 14, 14,1, 1330, 0x83ec51a4, S=1, 1024, 
0xb6327c81
-0, 15, 15,1, 1276, 0x2acf38dc, S=1, 1024, 
0xb6327c81
-0, 16, 16,1, 1475, 0x4cd197ef, S=1, 1024, 
0xb6327c81
-0, 17, 17,1, 1784, 0xd1e84ae6, S=1, 1024, 
0xde0a7c81
+0, 15, 15,1, 1275, 0xf0f438db, S=1, 1024, 
0xb6327c81
+0, 16, 16,1, 1474, 0xb41c97ee, S=1, 1024, 
0xb6327c81
+0, 17, 17,1, 1783, 0x86164ae5, S=1, 1024, 
0xde0a7c81
 0, 18, 18,1, 1675, 0x092dfa86, S=1, 1024, 
0xde0a7c81
 0, 19, 19,1, 1509, 0x639aaa00, S=1, 1024, 
0xde0a7c81
 0, 20, 20,1, 1705, 0xfd3719d5, S=1, 1024, 
0xde0a7c81
 0, 21, 21,1, 1745, 0x8a761db4, S=1, 1024, 
0xde0a7c81
 0, 22, 22,1, 1642, 0x18830245, S=1, 1024, 
0xde0a7c81
-0, 23, 23,1, 1718, 0x3c8d1ebe, S=1, 1024, 
0xde0a7c81
+0, 23, 23,1, 1717, 0x1d251ebd, S=1, 1024, 
0xde0a7c81
 0, 24, 24,1, 1900, 0x2ea879d1, S=1, 1024, 
0xde0a7c81
-0, 25, 25,1, 1807, 0x02b35230, S=1, 1024, 
0xde0a7c81
+0, 25, 25,1, 1806, 0xb071522f, S=1, 1024, 
0xde0a7c81
 0, 26, 26,1, 1915, 0x22d48344, S=1, 1024, 
0xde0a7c81
 0, 27, 27,1, 2100, 0x55fcd063, S=1, 1024,

[FFmpeg-devel] [PATCH] add locale month names to av_small_strptime

2017-02-20 Thread Micah Galizia

Signed-off-by: Micah Galizia 
---
 libavutil/parseutils.c   | 28 
 libavutil/tests/parseutils.c |  7 +++
 2 files changed, 35 insertions(+)

diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 86d3dac..7ca07b3 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -140,6 +140,11 @@ static const VideoRateAbbr video_rate_abbrs[]= {
 { "ntsc-film", { 24000, 1001 } },
 };
 
+static const char *months[12] = {
+"january", "february", "march", "april", "may", "june", "july", "august",
+"september", "october", "november", "december"
+};
+
 int av_parse_video_size(int *width_ptr, int *height_ptr, const char *str)
 {
 int i;
@@ -466,6 +471,21 @@ static int date_get_num(const char **pp,
 return val;
 }
 
+static int date_get_month(const char **pp) {
+int i = 0;
+for (; i < 12; i++) {
+if (!av_strncasecmp(*pp, months[i], 3)) {
+const char *mo_full = months[i] + 3;
+int len = strlen(mo_full);
+*pp += 3;
+if (len > 0 && !av_strncasecmp(*pp, mo_full, len))
+*pp += len;
+return i;
+}
+}
+return -1;
+}
+
 char *av_small_strptime(const char *p, const char *fmt, struct tm *dt)
 {
 int c, val;
@@ -525,6 +545,14 @@ char *av_small_strptime(const char *p, const char *fmt, 
struct tm *dt)
 if (!p)
 return NULL;
 break;
+case 'b':
+case 'B':
+case 'h':
+val = date_get_month();
+if (val == -1)
+return NULL;
+dt->tm_mon = val;
+break;
 case '%':
 if (*p++ != '%')
 return NULL;
diff --git a/libavutil/tests/parseutils.c b/libavutil/tests/parseutils.c
index 682b390..180f624 100644
--- a/libavutil/tests/parseutils.c
+++ b/libavutil/tests/parseutils.c
@@ -138,6 +138,13 @@ static void test_av_small_strptime(void)
 { "%Y - %m - %d","2012-12-21" },
 { "%Y-%m-%d %H:%M:%S",   "2012-12-21 20:12:21" },
 { "  %Y - %m - %d %H : %M : %S", "   2012 - 12 -  21   20 : 12 : 21" },
+{ "  %Y - %b - %d %H : %M : %S", "   2012 - nOV -  21   20 : 12 : 21" 
},
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - nOVemBeR -  21   20 : 12 : 
21" },
+{ "  %Y - %B%d %H : %M : %S", "   2012 - may21   20 : 12 : 21" },
+{ "  %Y - %B%d %H : %M : %S", "   2012 - mby21   20 : 12 : 21" },
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - JunE -  21   20 : 12 : 21" 
},
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - Jane -  21   20 : 12 : 21" 
},
+{ "  %Y - %B - %d %H : %M : %S", "   2012 - January -  21   20 : 12 : 
21" },
 };
 
 av_log_set_level(AV_LOG_DEBUG);
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] avcodec/utils: do not reallocate packet buffer for AV_CODEC_ID_WRAPPED_AVFRAME

2017-02-20 Thread Marton Balint



On Sun, 19 Feb 2017, Hendrik Leppkes wrote:


On Sun, Feb 19, 2017 at 2:41 PM, wm4  wrote:

On Sun, 19 Feb 2017 14:35:42 +0100
Marton Balint  wrote:


Reallocating a wrapped avframe invalidates internal pointers, such as extended
data.

FFmpeg has another way of passing AVFrames to muxers, but it seems the API
(av_write_uncoded_frame) is not implemented in the ffmpeg CLI yet.

Signed-off-by: Marton Balint 
---
 libavcodec/utils.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f4085bf..184821a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1820,7 +1820,7 @@ int attribute_align_arg 
avcodec_encode_audio2(AVCodecContext *avctx,
 AVFrame *padded_frame = NULL;
 int ret;
 AVPacket user_pkt = *avpkt;
-int needs_realloc = !user_pkt.data;
+int needs_realloc = !user_pkt.data && avctx->codec_id != 
AV_CODEC_ID_WRAPPED_AVFRAME;

 *got_packet_ptr = 0;

@@ -1964,7 +1964,7 @@ int attribute_align_arg 
avcodec_encode_video2(AVCodecContext *avctx,
 {
 int ret;
 AVPacket user_pkt = *avpkt;
-int needs_realloc = !user_pkt.data;
+int needs_realloc = !user_pkt.data && avctx->codec_id != 
AV_CODEC_ID_WRAPPED_AVFRAME;

 *got_packet_ptr = 0;



I don't understand this logic in the first place. If nothing was
encoded (!ret), and avpkt->data is set (why is it set?), then the
AVPacket.buf is realllocated (why?) to the packet size (why???) - how
does it make sense?


ret = 0 indicates successfull encode, ie. not an error code. What
result code did you expect?
AFAIK the realloc is performed to shrink over-sized pre-allocated
packets down and save memory.



So is it OK to apply the patch?

Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate/source: Check for cases that could use av_clip_uintp2() and av_clip_intp2()

2017-02-20 Thread Michael Niedermayer

On Mon, Feb 20, 2017 at 12:34:36PM +0100, Clément Bœsch wrote:
> On Fri, Feb 17, 2017 at 01:59:08AM +0100, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  tests/fate/source-check.sh | 14 ++
> >  tests/ref/fate/source  |  2 ++
> >  2 files changed, 16 insertions(+)
> > 
> > diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
> > index ac2878d9f7..72e1511f0d 100755
> > --- a/tests/fate/source-check.sh
> > +++ b/tests/fate/source-check.sh
> > @@ -30,4 +30,18 @@ for f in `git ls-files | grep '\.h$'` ; do
> >  grep -L "^#define $macro$" $f
> >  done
> >  
> 
> > +echo "Use of av_clip() where av_clip_uintp2 could be used:"
> 
> the use of () is not consistent

fixed


> 
> > +git grep -E 'av_clip *\(.*, *0 *, 
> > *(3|7|15|31|63|127|255|511|1023|2047|4095|8191|'\
> > +'16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|'\
> > +'33554431|67108863|134217727|268435455|536870911|1073741823) *\)' | grep 
> > -v fate/source
> > +
> > +echo "Use of av_clip() where av_clip_intp2 could be used:"
> > +git grep -E 'av_clip *\(.*, *(-2 *, *1|-4 *, *3|-8 *, *7|-16 *, *15|-32 *, 
> > *31|-64'\
> > +' *, *63|-128 *, *127|-256 *, *255|-512 *, *511|-1024 *, *1023|-2048 *, 
> > *2047|-4096'\
> > +' *, *4095|-8192 *, *8191|-16384 *, *16383|-32768 *, *32767|-65536 *, 
> > *65535|-131072'\
> > +' *, *131071|-262144 *, *262143|-524288 *, *524287|-1048576 *, 
> > *1048575|-2097152 *,'\
> > +' *2097151|-4194304 *, *4194303|-8388608 *, *8388607|-16777216 *, 
> > *16777215|-33554432'\
> > +' *, *33554431|-67108864 *, *67108863|-134217728 *, *134217727|-268435456 
> > *, *'\
> > +'268435455|-536870912 *, *536870911|-1073741824 *, *1073741823) *\)'| grep 
> > -v fate/source
> > +
> 
> you could add support for the 0x forms:
> 
> libavcodec/g726.c:return av_clip(re_signal << 2, -0x, 0x);

-0x is not one of the supported cases of av_clip_intp2

will apply this patchset with my next push

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 1/4] vp8: Add hwaccel hooks

2017-02-20 Thread Michael Niedermayer

On Mon, Feb 20, 2017 at 12:28:55PM +0100, wm4 wrote:
> On Mon, 20 Feb 2017 11:20:48 +
> Mark Thompson  wrote:
> 
> > On 20/02/17 10:44, Michael Niedermayer wrote:
> > > On Mon, Feb 20, 2017 at 10:23:27AM +, Mark Thompson wrote:  
> > >> On 20/02/17 02:35, Michael Niedermayer wrote:  
> > >>> On Sun, Feb 19, 2017 at 09:29:33PM +, Mark Thompson wrote:  
> >  On 19/02/17 21:04, Ronald S. Bultje wrote:  
> > > Hi,
> > >
> > > On Sun, Feb 19, 2017 at 12:23 PM, Mark Thompson  
> > > wrote:
> > >  
> > >> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> > >>  
> > > [..]
> > >  
> > >> +avctx->get_format = webp_get_format;  
> > >
> > >
> > > Docs say:
> > > "decoding: Set by user, if not set the native format will be chosen."
> > > So I don't think decoders are supposed to set this.  
> > 
> >  The webp decoder does not support get_format.  I suppose the user 
> >  could technically store something there and then read it back, so save 
> >  and restore the value across the relevant calls?  
> > >>>
> > >>> This is quite ugly, why do you want to do that ?
> > >>>
> > >>> get_format is set by the user
> > >>> the get_format API requires the function to choose one of the caller
> > >>> provided formats and it can choose any.
> > >>> I dont know what your function does but its different from the API.
> > >>> It smells very much like a hack ...
> > >>>
> > >>> The one situation in which you can set get_format from libavcodec is
> > >>> when there is a seperate codec context you created, that is that you
> > >>> are its user.
> > >>>
> > >>> can you explain why this code messes with avctx->get_format ?
> > >>> and for example doesnt change the code that calls get_format so that
> > >>> it passes a correct pixel format list which then by any get_format()
> > >>> results in a correct format ?
> > >>> or am i missing something ?  
> > >>  
> > >   
> > >> The current WebP decoder calls the VP8 decoder /using the same 
> > >> AVCodecContext/.  
> > > 
> > > so they are kind of the same decoder
> > > 
> > >   
> > >> Previously the format was set directly on the VP8Context, but now that 
> > >> the VP8 decoder uses ff_get_format() that initial value is not used.  
> > >> This change adds a get_format() callback on the AVCodecContext used by 
> > >> the VP8 decoder to set the format appropriately.  
> > > 
> > > But this is semantically wrong, the formats supported by the decoder
> > > implementation are choosen by the code calling get_format().
> > > the get_format callback chooses amongth these formats depending on the
> > > users preferrance/usefullness.  
> > 
> > Yes.  It's a hack to make the VP8 decoder allocate a non-native frame 
> > format (YUVA420P) which is compatible with its native format (YUV420P) for 
> > any use it makes of it.  This is a hack which already exists, we are just 
> > moving it to a different place now that the VP8 decoder uses 
> > ff_get_format().
> > 
> > >> Now, because that is the same AVCodecContext as the one supplied by the 
> > >> user, the user could themselves have stored something into the 
> > >> get_format field (even though it isn't used by the WebP decoder) and 
> > >> expect to be able to read it back correctly later.  I think this would 
> > >> be madness, but is I suppose technically allowed; saving and restoring 
> > >> the value across the VP8 calls would fix that case.  
> > > 
> > > Why do you try to misuse the API ?  
> > 
> > To make the minimal modifications to existing hacks for fate to pass for 
> > WebP.  I do not care at all about WebP, but the existing hacks abusing the 
> > VP8 decoder block the other changes.
> > 
> > > i mean i think we agree that this violates the API. Making sure it
> > > works doesnt solve that it violates the API. And anyone working on
> > > the API would likely assume that code conforms to the API documentation.  
> > > -> the developer would think one thing and the code would do another  
> > > thats a recipe for creating bugs.
> > > 
> > > I think the code calling *get_format() should pass the correct list
> > > of formats to the callback and not some other part override the users
> > > get_format calback to work around that the list passed is wrong.  
> > 
> > The user's get_format callback is never used.  (There is only one output 
> > format possibility for each input, so it wouldn't do anything anyway.)
> > 
> > > am i missing something ?
> > > is what i suggested difficult to do or do you see a issue with that
> > > solution ?  
> > 
> > The list passed by the VP8 decoder to ff_get_format() is not wrong - the 
> > VP8 decoder does not support alpha so including YUVA420P would be incorrect.
> > 
> 
> Would it be possible to add some field to the private context which
> controls this instead?

thats what i was thinking of as well

thanks

[...]
-- 
Michael GnuPG fingerprint:

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Correct keyframe search in edit list to return the very first keyframe/frame with matching timestamp. Fixes ticket#5904

2017-02-20 Thread Michael Niedermayer

On Wed, Feb 15, 2017 at 12:07:55PM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c | 12 
>  1 file changed, 12 insertions(+)

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] avx functions for h264 chroma deblocking

2017-02-20 Thread James Almer

On 2/20/2017 12:33 PM, James Darnley wrote:
> 6 more functions which eke out a little more speed.
> 
> James Darnley (6):
>   avcodec/h264: add avx 8-bit chroma v deblock/loop filter
>   avcodec/h264: add avx 8-bit 4:2:0 chroma h deblock/loop filter
>   avcodec/h264: add avx 8-bit 4:2:2 chroma h deblock/loop filter
>   avcodec/h264: add avx 8-bit chroma v intra deblock/loop filter
>   avcodec/h264: add avx 8-bit 4:2:0 chroma h intra deblock/loop filter
>   avcodec/h264: add avx 8-bit 4:2:2 chroma h intra deblock/loop filter
> 
>  libavcodec/x86/h264_deblock.asm | 195 
> 
>  libavcodec/x86/h264dsp_init.c   |  10 +++
>  2 files changed, 205 insertions(+)

All of these can and should be SSE2 first and foremost, and AVX only if
there's any gain on top of it from using the three operand version of the
instructions.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/6] avcodec/h264: add avx 8-bit 4:2:2 chroma h deblock/loop filter

2017-02-20 Thread James Darnley

~1.21x faster (68 vs. 56 cycles) compared with mmxext function
---
 libavcodec/x86/h264_deblock.asm | 27 +++
 libavcodec/x86/h264dsp_init.c   |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 0465c9f..e2eb002 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1163,6 +1163,33 @@ cglobal deblock_h_chroma_8, 5, 7, 8, 0-16, pix_, 
stride_, alpha_, beta_, tc0_
 STORE_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
 RET
 
+cglobal deblock_h_chroma422_8, 5, 7, 8, 0-16, pix_, stride_, alpha_, beta_, 
tc0_,
+CHROMA_H_START_XMM r5, r6
+LOAD_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
+TRANSPOSE_8x4B_XMM
+movq [rsp], m0
+movq [rsp + 8], m3
+CHROMA_INTER_BODY_XMM 2
+movq m0, [rsp]
+movq m3, [rsp + 8]
+TRANSPOSE_4x8B_XMM
+STORE_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
+
+lea pix_q, [pix_q + 8*stride_q]
+lea r5,[r5+ 8*stride_q]
+add tc0_q,  2
+
+LOAD_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
+TRANSPOSE_8x4B_XMM
+movq [rsp], m0
+movq [rsp + 8], m3
+CHROMA_INTER_BODY_XMM 2
+movq m0, [rsp]
+movq m3, [rsp + 8]
+TRANSPOSE_4x8B_XMM
+STORE_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
+RET
+
 %endmacro ; DEBLOCK_CHROMA_XMM
 
 DEBLOCK_CHROMA_XMM avx
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 0b15471..6073932 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -321,6 +321,8 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_v_loop_filter_chroma   = ff_deblock_v_chroma_8_avx;
 if (chroma_format_idc <= 1) {
 c->h264_h_loop_filter_chroma   = ff_deblock_h_chroma_8_avx;
+} else {
+c->h264_h_loop_filter_chroma   = 
ff_deblock_h_chroma422_8_avx;
 }
 }
 } else if (bit_depth == 10) {
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/6] avcodec/h264: add avx 8-bit chroma v deblock/loop filter

2017-02-20 Thread James Darnley

~1.24x faster (101 vs. 81 cycles) compared with mmxext function
---
 libavcodec/x86/h264_deblock.asm | 38 ++
 libavcodec/x86/h264dsp_init.c   |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 93caa67..2e84ca3 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1059,6 +1059,44 @@ ff_chroma_intra_body_mmxext:
 paddb  m2, m6
 ret
 
+%macro CHROMA_INTER_BODY_XMM 1
+LOAD_MASK alpha_d, beta_d
+movd m6, [tc0_q]
+%rep %1
+punpcklbw m6, m6
+%endrep
+pand m7, m6
+DEBLOCK_P0_Q0
+%endmacro
+
+%macro CHROMA_V_START_XMM 1
+movsxdifnidn stride_q, stride_d
+dec alpha_d
+dec beta_d
+mov %1, pix_q
+sub %1, stride_q
+sub %1, stride_q
+%endmacro
+
+%macro DEBLOCK_CHROMA_XMM 1
+
+INIT_XMM %1
+
+cglobal deblock_v_chroma_8, 5, 6, 8, pix_, stride_, alpha_, beta_, tc0_
+CHROMA_V_START_XMM r5
+movq m0, [r5]
+movq m1, [r5 + stride_q]
+movq m2, [pix_q]
+movq m3, [pix_q + stride_q]
+CHROMA_INTER_BODY_XMM 1
+movq [r5 + stride_q], m1
+movq [pix_q], m2
+RET
+
+%endmacro ; DEBLOCK_CHROMA_XMM
+
+DEBLOCK_CHROMA_XMM avx
+
 ;-
 ; void ff_h264_loop_filter_strength(int16_t bs[2][4][4], uint8_t nnz[40],
 ;   int8_t ref[2][40], int16_t mv[2][40][2],
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 10f1940..6794aa5 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -317,6 +317,8 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 #if ARCH_X86_64
 c->h264_h_loop_filter_luma_mbaff = ff_deblock_h_luma_mbaff_8_avx;
 #endif
+
+c->h264_v_loop_filter_chroma   = ff_deblock_v_chroma_8_avx;
 }
 } else if (bit_depth == 10) {
 if (EXTERNAL_MMXEXT(cpu_flags)) {
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 5/6] avcodec/h264: add avx 8-bit 4:2:0 chroma h intra deblock/loop filter

2017-02-20 Thread James Darnley

~1.10x faster (69 vs. 63 cycles) compared to mmxext function
---
 libavcodec/x86/h264_deblock.asm | 9 +
 libavcodec/x86/h264dsp_init.c   | 1 +
 2 files changed, 10 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 1e6d822..2197608 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1223,6 +1223,15 @@ cglobal deblock_v_chroma_intra_8, 4, 5, 8, pix_, 
stride_, alpha_, beta_
 movq [pix_q], m2
 RET
 
+cglobal deblock_h_chroma_intra_8, 4, 6, 8, pix_, stride_, alpha_, beta_
+CHROMA_H_START_XMM r4, r5
+LOAD_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
+TRANSPOSE_8x4B_XMM
+CHROMA_INTRA_BODY_XMM
+TRANSPOSE_4x8B_XMM
+STORE_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
+RET
+
 %endmacro ; DEBLOCK_CHROMA_XMM
 
 DEBLOCK_CHROMA_XMM avx
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index cc86664..b1246d0 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -322,6 +322,7 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_8_avx;
 if (chroma_format_idc <= 1) {
 c->h264_h_loop_filter_chroma   = ff_deblock_h_chroma_8_avx;
+c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma_intra_8_avx;
 } else {
 c->h264_h_loop_filter_chroma   = 
ff_deblock_h_chroma422_8_avx;
 }
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/6] avcodec/h264: add avx 8-bit 4:2:0 chroma h deblock/loop filter

2017-02-20 Thread James Darnley

~1.14x faster (93 vs. 81 cycles) compared with mmxext function
---
 libavcodec/x86/h264_deblock.asm | 70 +
 libavcodec/x86/h264dsp_init.c   |  3 ++
 2 files changed, 73 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 2e84ca3..0465c9f 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1059,6 +1059,54 @@ ff_chroma_intra_body_mmxext:
 paddb  m2, m6
 ret
 
+%macro LOAD_8_ROWS 8
+movd m0, %1
+movd m1, %2
+movd m2, %3
+movd m3, %4
+movd m4, %5
+movd m5, %6
+movd m6, %7
+movd m7, %8
+%endmacro
+
+%macro STORE_8_ROWS 8
+movd %1, m0
+movd %2, m1
+movd %3, m2
+movd %4, m3
+movd %5, m4
+movd %6, m5
+movd %7, m6
+movd %8, m7
+%endmacro
+
+%macro TRANSPOSE_8x4B_XMM 0
+punpcklbw m0, m1
+punpcklbw m2, m3
+punpcklbw m4, m5
+punpcklbw m6, m7
+punpcklwd m0, m2
+punpcklwd m4, m6
+punpckhdq m2, m0, m4
+punpckldq m0, m4
+MOVHL m1, m0
+MOVHL m3, m2
+%endmacro
+
+%macro TRANSPOSE_4x8B_XMM 0
+punpcklbw m0, m1
+punpcklbw m2, m3
+punpckhwd m4, m0, m2
+punpcklwd m0, m2
+MOVHL m6, m4
+MOVHL m2, m0
+pshufd m1, m0, 1
+pshufd m3, m2, 1
+pshufd m5, m4, 1
+pshufd m7, m6, 1
+%endmacro
+
 %macro CHROMA_INTER_BODY_XMM 1
 LOAD_MASK alpha_d, beta_d
 movd m6, [tc0_q]
@@ -1078,6 +1126,15 @@ ff_chroma_intra_body_mmxext:
 sub %1, stride_q
 %endmacro
 
+%macro CHROMA_H_START_XMM 2
+movsxdifnidn stride_q, stride_d
+dec alpha_d
+dec beta_d
+lea %2, [3*stride_q]
+mov %1,  pix_q
+add %1,  %2
+%endmacro
+
 %macro DEBLOCK_CHROMA_XMM 1
 
 INIT_XMM %1
@@ -1093,6 +1150,19 @@ cglobal deblock_v_chroma_8, 5, 6, 8, pix_, stride_, 
alpha_, beta_, tc0_
 movq [pix_q], m2
 RET
 
+cglobal deblock_h_chroma_8, 5, 7, 8, 0-16, pix_, stride_, alpha_, beta_, tc0_
+CHROMA_H_START_XMM r5, r6
+LOAD_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
+TRANSPOSE_8x4B_XMM
+movq [rsp], m0
+movq [rsp + 8], m3
+CHROMA_INTER_BODY_XMM 1
+movq m0, [rsp]
+movq m3, [rsp + 8]
+TRANSPOSE_4x8B_XMM
+STORE_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
+RET
+
 %endmacro ; DEBLOCK_CHROMA_XMM
 
 DEBLOCK_CHROMA_XMM avx
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 6794aa5..0b15471 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -319,6 +319,9 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 #endif
 
 c->h264_v_loop_filter_chroma   = ff_deblock_v_chroma_8_avx;
+if (chroma_format_idc <= 1) {
+c->h264_h_loop_filter_chroma   = ff_deblock_h_chroma_8_avx;
+}
 }
 } else if (bit_depth == 10) {
 if (EXTERNAL_MMXEXT(cpu_flags)) {
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 6/6] avcodec/h264: add avx 8-bit 4:2:2 chroma h intra deblock/loop filter

2017-02-20 Thread James Darnley

~1.37x faster (147 vs. 108 cycles) compared to mmxext function
---
 libavcodec/x86/h264_deblock.asm | 18 ++
 libavcodec/x86/h264dsp_init.c   |  1 +
 2 files changed, 19 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 2197608..32aa3d3 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1232,6 +1232,24 @@ cglobal deblock_h_chroma_intra_8, 4, 6, 8, pix_, 
stride_, alpha_, beta_
 STORE_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
 RET
 
+cglobal deblock_h_chroma422_intra_8, 4, 6, 8, pix_, stride_, alpha_, beta_
+CHROMA_H_START_XMM r4, r5
+LOAD_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
+TRANSPOSE_8x4B_XMM
+CHROMA_INTRA_BODY_XMM
+TRANSPOSE_4x8B_XMM
+STORE_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
+
+lea pix_q, [pix_q + 8*stride_q]
+lea r4,[r4+ 8*stride_q]
+
+LOAD_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
+TRANSPOSE_8x4B_XMM
+CHROMA_INTRA_BODY_XMM
+TRANSPOSE_4x8B_XMM
+STORE_8_ROWS PASS8ROWS(pix_q - 2, r4 - 2, stride_q, r5)
+RET
+
 %endmacro ; DEBLOCK_CHROMA_XMM
 
 DEBLOCK_CHROMA_XMM avx
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index b1246d0..51082e8 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -325,6 +325,7 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma_intra_8_avx;
 } else {
 c->h264_h_loop_filter_chroma   = 
ff_deblock_h_chroma422_8_avx;
+c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma422_intra_8_avx;
 }
 }
 } else if (bit_depth == 10) {
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/6] avcodec/h264: add avx 8-bit chroma v intra deblock/loop filter

2017-02-20 Thread James Darnley

~1.14x faster (90 vs 78 cycles) compared with mmxext
---
 libavcodec/x86/h264_deblock.asm | 33 +
 libavcodec/x86/h264dsp_init.c   |  1 +
 2 files changed, 34 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index e2eb002..1e6d822 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1117,6 +1117,28 @@ ff_chroma_intra_body_mmxext:
 DEBLOCK_P0_Q0
 %endmacro
 
+%macro CHROMA_INTRA_BODY_XMM 0
+LOAD_MASK alpha_d, beta_d
+movam5,  m1
+movam6,  m2
+pxorm4,  m1, m3
+pandm4, [pb_1]
+pavgb   m1,  m3
+psubusb m1,  m4
+pavgb   m1,  m0
+pxorm4,  m2, m0
+pandm4, [pb_1]
+pavgb   m2,  m0
+psubusb m2,  m4
+pavgb   m2,  m3
+psubb   m1,  m5
+psubb   m2,  m6
+pandm1,  m7
+pandm2,  m7
+paddb   m1,  m5
+paddb   m2,  m6
+%endmacro
+
 %macro CHROMA_V_START_XMM 1
 movsxdifnidn stride_q, stride_d
 dec alpha_d
@@ -1190,6 +1212,17 @@ cglobal deblock_h_chroma422_8, 5, 7, 8, 0-16, pix_, 
stride_, alpha_, beta_, tc0_
 STORE_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6)
 RET
 
+cglobal deblock_v_chroma_intra_8, 4, 5, 8, pix_, stride_, alpha_, beta_
+CHROMA_V_START_XMM r4
+movq m0, [r4]
+movq m1, [r4 + stride_q]
+movq m2, [pix_q]
+movq m3, [pix_q + stride_q]
+CHROMA_INTRA_BODY_XMM
+movq [r4 + stride_q], m1
+movq [pix_q], m2
+RET
+
 %endmacro ; DEBLOCK_CHROMA_XMM
 
 DEBLOCK_CHROMA_XMM avx
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 6073932..cc86664 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -319,6 +319,7 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 #endif
 
 c->h264_v_loop_filter_chroma   = ff_deblock_v_chroma_8_avx;
+c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_8_avx;
 if (chroma_format_idc <= 1) {
 c->h264_h_loop_filter_chroma   = ff_deblock_h_chroma_8_avx;
 } else {
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/6] avx functions for h264 chroma deblocking

2017-02-20 Thread James Darnley

6 more functions which eke out a little more speed.

James Darnley (6):
  avcodec/h264: add avx 8-bit chroma v deblock/loop filter
  avcodec/h264: add avx 8-bit 4:2:0 chroma h deblock/loop filter
  avcodec/h264: add avx 8-bit 4:2:2 chroma h deblock/loop filter
  avcodec/h264: add avx 8-bit chroma v intra deblock/loop filter
  avcodec/h264: add avx 8-bit 4:2:0 chroma h intra deblock/loop filter
  avcodec/h264: add avx 8-bit 4:2:2 chroma h intra deblock/loop filter

 libavcodec/x86/h264_deblock.asm | 195 
 libavcodec/x86/h264dsp_init.c   |  10 +++
 2 files changed, 205 insertions(+)

-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

2017-02-20 Thread Tobias Rapp


On 20.02.2017 15:09, Mark Thompson wrote:

On 06/02/17 12:33, Tobias Rapp wrote:

Sets framerate field in output codec context if explicitly specified on
the command-line.

Signed-off-by: Tobias Rapp 
---
 ffmpeg_opt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6a47d32..3b532da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1535,6 +1535,8 @@ static OutputStream *new_video_stream(OptionsContext *o, 
AVFormatContext *oc, in
 av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", 
frame_rate);
 exit_program(1);
 }
+if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
+video_enc->framerate = ost->frame_rate;
 if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
 av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce invalid 
output files\n");




Is there a reason not to always set this, rather than only when it is specified 
explicitly on the command line as you have?

(Like 
,
 though that is after the current merge point and I don't know if it interacts with 
anything else.)


I just tried to be extra cautious. Merging Libav commit 
d10102d23c9467d4eb84f58e0cd12be284b982f6 would provide a more general 
solution and might be preferred.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

2017-02-20 Thread Mark Thompson

On 06/02/17 12:33, Tobias Rapp wrote:
> Sets framerate field in output codec context if explicitly specified on
> the command-line.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  ffmpeg_opt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 6a47d32..3b532da 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -1535,6 +1535,8 @@ static OutputStream *new_video_stream(OptionsContext 
> *o, AVFormatContext *oc, in
>  av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", 
> frame_rate);
>  exit_program(1);
>  }
> +if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
> +video_enc->framerate = ost->frame_rate;
>  if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
>  av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce 
> invalid output files\n");
>  
> 

Is there a reason not to always set this, rather than only when it is specified 
explicitly on the command line as you have?

(Like 
,
 though that is after the current merge point and I don't know if it interacts 
with anything else.)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

2017-02-20 Thread Tobias Rapp


On 13.02.2017 08:51, Tobias Rapp wrote:

On 06.02.2017 13:33, Tobias Rapp wrote:

Sets framerate field in output codec context if explicitly specified on
the command-line.

Signed-off-by: Tobias Rapp 
---
 ffmpeg_opt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6a47d32..3b532da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1535,6 +1535,8 @@ static OutputStream
*new_video_stream(OptionsContext *o, AVFormatContext *oc, in
 av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n",
frame_rate);
 exit_program(1);
 }
+if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
+video_enc->framerate = ost->frame_rate;
 if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
 av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce
invalid output files\n");



Ping on the patch series.


Ping. Having better bitrate estimation improves automatic AVI index 
space reservation (commit e65db4ce5966506d957032ef30545419801ae7dc) for 
non-constant bitrate use-cases.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] vp8: Add hwaccel hooks

2017-02-20 Thread wm4

On Mon, 20 Feb 2017 11:20:48 +
Mark Thompson  wrote:

> On 20/02/17 10:44, Michael Niedermayer wrote:
> > On Mon, Feb 20, 2017 at 10:23:27AM +, Mark Thompson wrote:  
> >> On 20/02/17 02:35, Michael Niedermayer wrote:  
> >>> On Sun, Feb 19, 2017 at 09:29:33PM +, Mark Thompson wrote:  
>  On 19/02/17 21:04, Ronald S. Bultje wrote:  
> > Hi,
> >
> > On Sun, Feb 19, 2017 at 12:23 PM, Mark Thompson  wrote:
> >  
> >> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> >>  
> > [..]
> >  
> >> +avctx->get_format = webp_get_format;  
> >
> >
> > Docs say:
> > "decoding: Set by user, if not set the native format will be chosen."
> > So I don't think decoders are supposed to set this.  
> 
>  The webp decoder does not support get_format.  I suppose the user could 
>  technically store something there and then read it back, so save and 
>  restore the value across the relevant calls?  
> >>>
> >>> This is quite ugly, why do you want to do that ?
> >>>
> >>> get_format is set by the user
> >>> the get_format API requires the function to choose one of the caller
> >>> provided formats and it can choose any.
> >>> I dont know what your function does but its different from the API.
> >>> It smells very much like a hack ...
> >>>
> >>> The one situation in which you can set get_format from libavcodec is
> >>> when there is a seperate codec context you created, that is that you
> >>> are its user.
> >>>
> >>> can you explain why this code messes with avctx->get_format ?
> >>> and for example doesnt change the code that calls get_format so that
> >>> it passes a correct pixel format list which then by any get_format()
> >>> results in a correct format ?
> >>> or am i missing something ?  
> >>  
> >   
> >> The current WebP decoder calls the VP8 decoder /using the same 
> >> AVCodecContext/.  
> > 
> > so they are kind of the same decoder
> > 
> >   
> >> Previously the format was set directly on the VP8Context, but now that the 
> >> VP8 decoder uses ff_get_format() that initial value is not used.  This 
> >> change adds a get_format() callback on the AVCodecContext used by the VP8 
> >> decoder to set the format appropriately.  
> > 
> > But this is semantically wrong, the formats supported by the decoder
> > implementation are choosen by the code calling get_format().
> > the get_format callback chooses amongth these formats depending on the
> > users preferrance/usefullness.  
> 
> Yes.  It's a hack to make the VP8 decoder allocate a non-native frame format 
> (YUVA420P) which is compatible with its native format (YUV420P) for any use 
> it makes of it.  This is a hack which already exists, we are just moving it 
> to a different place now that the VP8 decoder uses ff_get_format().
> 
> >> Now, because that is the same AVCodecContext as the one supplied by the 
> >> user, the user could themselves have stored something into the get_format 
> >> field (even though it isn't used by the WebP decoder) and expect to be 
> >> able to read it back correctly later.  I think this would be madness, but 
> >> is I suppose technically allowed; saving and restoring the value across 
> >> the VP8 calls would fix that case.  
> > 
> > Why do you try to misuse the API ?  
> 
> To make the minimal modifications to existing hacks for fate to pass for 
> WebP.  I do not care at all about WebP, but the existing hacks abusing the 
> VP8 decoder block the other changes.
> 
> > i mean i think we agree that this violates the API. Making sure it
> > works doesnt solve that it violates the API. And anyone working on
> > the API would likely assume that code conforms to the API documentation.  
> > -> the developer would think one thing and the code would do another  
> > thats a recipe for creating bugs.
> > 
> > I think the code calling *get_format() should pass the correct list
> > of formats to the callback and not some other part override the users
> > get_format calback to work around that the list passed is wrong.  
> 
> The user's get_format callback is never used.  (There is only one output 
> format possibility for each input, so it wouldn't do anything anyway.)
> 
> > am i missing something ?
> > is what i suggested difficult to do or do you see a issue with that
> > solution ?  
> 
> The list passed by the VP8 decoder to ff_get_format() is not wrong - the VP8 
> decoder does not support alpha so including YUVA420P would be incorrect.
> 

Would it be possible to add some field to the private context which
controls this instead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate/source: Check for cases that could use av_clip_uintp2() and av_clip_intp2()

2017-02-20 Thread Clément Bœsch

On Fri, Feb 17, 2017 at 01:59:08AM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/source-check.sh | 14 ++
>  tests/ref/fate/source  |  2 ++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
> index ac2878d9f7..72e1511f0d 100755
> --- a/tests/fate/source-check.sh
> +++ b/tests/fate/source-check.sh
> @@ -30,4 +30,18 @@ for f in `git ls-files | grep '\.h$'` ; do
>  grep -L "^#define $macro$" $f
>  done
>  

> +echo "Use of av_clip() where av_clip_uintp2 could be used:"

the use of () is not consistent

> +git grep -E 'av_clip *\(.*, *0 *, 
> *(3|7|15|31|63|127|255|511|1023|2047|4095|8191|'\
> +'16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|'\
> +'33554431|67108863|134217727|268435455|536870911|1073741823) *\)' | grep -v 
> fate/source
> +
> +echo "Use of av_clip() where av_clip_intp2 could be used:"
> +git grep -E 'av_clip *\(.*, *(-2 *, *1|-4 *, *3|-8 *, *7|-16 *, *15|-32 *, 
> *31|-64'\
> +' *, *63|-128 *, *127|-256 *, *255|-512 *, *511|-1024 *, *1023|-2048 *, 
> *2047|-4096'\
> +' *, *4095|-8192 *, *8191|-16384 *, *16383|-32768 *, *32767|-65536 *, 
> *65535|-131072'\
> +' *, *131071|-262144 *, *262143|-524288 *, *524287|-1048576 *, 
> *1048575|-2097152 *,'\
> +' *2097151|-4194304 *, *4194303|-8388608 *, *8388607|-16777216 *, 
> *16777215|-33554432'\
> +' *, *33554431|-67108864 *, *67108863|-134217728 *, *134217727|-268435456 *, 
> *'\
> +'268435455|-536870912 *, *536870911|-1073741824 *, *1073741823) *\)'| grep 
> -v fate/source
> +

you could add support for the 0x forms:

libavcodec/g726.c:return av_clip(re_signal << 2, -0x, 0x);

[...]

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] vp8: Add hwaccel hooks

2017-02-20 Thread Mark Thompson

On 20/02/17 10:44, Michael Niedermayer wrote:
> On Mon, Feb 20, 2017 at 10:23:27AM +, Mark Thompson wrote:
>> On 20/02/17 02:35, Michael Niedermayer wrote:
>>> On Sun, Feb 19, 2017 at 09:29:33PM +, Mark Thompson wrote:
 On 19/02/17 21:04, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Feb 19, 2017 at 12:23 PM, Mark Thompson  wrote:
>
>> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
>>
> [..]
>
>> +avctx->get_format = webp_get_format;
>
>
> Docs say:
> "decoding: Set by user, if not set the native format will be chosen."
> So I don't think decoders are supposed to set this.

 The webp decoder does not support get_format.  I suppose the user could 
 technically store something there and then read it back, so save and 
 restore the value across the relevant calls?
>>>
>>> This is quite ugly, why do you want to do that ?
>>>
>>> get_format is set by the user
>>> the get_format API requires the function to choose one of the caller
>>> provided formats and it can choose any.
>>> I dont know what your function does but its different from the API.
>>> It smells very much like a hack ...
>>>
>>> The one situation in which you can set get_format from libavcodec is
>>> when there is a seperate codec context you created, that is that you
>>> are its user.
>>>
>>> can you explain why this code messes with avctx->get_format ?
>>> and for example doesnt change the code that calls get_format so that
>>> it passes a correct pixel format list which then by any get_format()
>>> results in a correct format ?
>>> or am i missing something ?
>>
> 
>> The current WebP decoder calls the VP8 decoder /using the same 
>> AVCodecContext/.
> 
> so they are kind of the same decoder
> 
> 
>> Previously the format was set directly on the VP8Context, but now that the 
>> VP8 decoder uses ff_get_format() that initial value is not used.  This 
>> change adds a get_format() callback on the AVCodecContext used by the VP8 
>> decoder to set the format appropriately.
> 
> But this is semantically wrong, the formats supported by the decoder
> implementation are choosen by the code calling get_format().
> the get_format callback chooses amongth these formats depending on the
> users preferrance/usefullness.

Yes.  It's a hack to make the VP8 decoder allocate a non-native frame format 
(YUVA420P) which is compatible with its native format (YUV420P) for any use it 
makes of it.  This is a hack which already exists, we are just moving it to a 
different place now that the VP8 decoder uses ff_get_format().

>> Now, because that is the same AVCodecContext as the one supplied by the 
>> user, the user could themselves have stored something into the get_format 
>> field (even though it isn't used by the WebP decoder) and expect to be able 
>> to read it back correctly later.  I think this would be madness, but is I 
>> suppose technically allowed; saving and restoring the value across the VP8 
>> calls would fix that case.
> 
> Why do you try to misuse the API ?

To make the minimal modifications to existing hacks for fate to pass for WebP.  
I do not care at all about WebP, but the existing hacks abusing the VP8 decoder 
block the other changes.

> i mean i think we agree that this violates the API. Making sure it
> works doesnt solve that it violates the API. And anyone working on
> the API would likely assume that code conforms to the API documentation.
> -> the developer would think one thing and the code would do another
> thats a recipe for creating bugs.
> 
> I think the code calling *get_format() should pass the correct list
> of formats to the callback and not some other part override the users
> get_format calback to work around that the list passed is wrong.

The user's get_format callback is never used.  (There is only one output format 
possibility for each input, so it wouldn't do anything anyway.)

> am i missing something ?
> is what i suggested difficult to do or do you see a issue with that
> solution ?

The list passed by the VP8 decoder to ff_get_format() is not wrong - the VP8 
decoder does not support alpha so including YUVA420P would be incorrect.

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] vp8: Add hwaccel hooks

2017-02-20 Thread Hendrik Leppkes

On Mon, Feb 20, 2017 at 11:44 AM, Michael Niedermayer
 wrote:
> On Mon, Feb 20, 2017 at 10:23:27AM +, Mark Thompson wrote:
>> On 20/02/17 02:35, Michael Niedermayer wrote:
>> > On Sun, Feb 19, 2017 at 09:29:33PM +, Mark Thompson wrote:
>> >> On 19/02/17 21:04, Ronald S. Bultje wrote:
>> >>> Hi,
>> >>>
>> >>> On Sun, Feb 19, 2017 at 12:23 PM, Mark Thompson  wrote:
>> >>>
>>  diff --git a/libavcodec/webp.c b/libavcodec/webp.c
>> 
>> >>> [..]
>> >>>
>>  +avctx->get_format = webp_get_format;
>> >>>
>> >>>
>> >>> Docs say:
>> >>> "decoding: Set by user, if not set the native format will be chosen."
>> >>> So I don't think decoders are supposed to set this.
>> >>
>> >> The webp decoder does not support get_format.  I suppose the user could 
>> >> technically store something there and then read it back, so save and 
>> >> restore the value across the relevant calls?
>> >
>> > This is quite ugly, why do you want to do that ?
>> >
>> > get_format is set by the user
>> > the get_format API requires the function to choose one of the caller
>> > provided formats and it can choose any.
>> > I dont know what your function does but its different from the API.
>> > It smells very much like a hack ...
>> >
>> > The one situation in which you can set get_format from libavcodec is
>> > when there is a seperate codec context you created, that is that you
>> > are its user.
>> >
>> > can you explain why this code messes with avctx->get_format ?
>> > and for example doesnt change the code that calls get_format so that
>> > it passes a correct pixel format list which then by any get_format()
>> > results in a correct format ?
>> > or am i missing something ?
>>
>
>> The current WebP decoder calls the VP8 decoder /using the same 
>> AVCodecContext/.
>
> so they are kind of the same decoder
>
>
>> Previously the format was set directly on the VP8Context, but now that the 
>> VP8 decoder uses ff_get_format() that initial value is not used.  This 
>> change adds a get_format() callback on the AVCodecContext used by the VP8 
>> decoder to set the format appropriately.
>
> But this is semantically wrong, the formats supported by the decoder
> implementation are choosen by the code calling get_format().
> the get_format callback chooses amongth these formats depending on the
> users preferrance/usefullness.
>
>
>>
>> Now, because that is the same AVCodecContext as the one supplied by the 
>> user, the user could themselves have stored something into the get_format 
>> field (even though it isn't used by the WebP decoder) and expect to be able 
>> to read it back correctly later.  I think this would be madness, but is I 
>> suppose technically allowed; saving and restoring the value across the VP8 
>> calls would fix that case.
>
> Why do you try to misuse the API ?
> i mean i think we agree that this violates the API. Making sure it
> works doesnt solve that it violates the API. And anyone working on
> the API would likely assume that code conforms to the API documentation.
> -> the developer would think one thing and the code would do another
> thats a recipe for creating bugs.
>
> I think the code calling *get_format() should pass the correct list
> of formats to the callback and not some other part override the users
> get_format calback to work around that the list passed is wrong.
>
> am i missing something ?
> is what i suggested difficult to do or do you see a issue with that
> solution ?
>

The entire WebP alpha concept is a huge hack, because the vp8
bitstream or vp8 decoder know nothing of the alpha, its coded
separately.
However, to make room to store the alpha, the vp8 decoder needs to be
told to decode into an alpha-enabled format, so that the webp decoder
can fill it.

The vp8 decoder can't know its supposed to do this, unless someone
tells it externally - which is where get_format comes in.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add locale month names to av_small_strptime

2017-02-20 Thread Nicolas George

Le primidi 1er ventôse, an CCXXV, Micah Galizia a écrit :
> +static const char *mo_abr[] = { "jan", "feb", "mar", "apr", "may", "jun",
> +   "jul", "aug", "sep", "oct", "nov", "dec" };
> +
> +static const char *mo_full[] = { "uary", "ruary", "ch", "il", NULL, "e", "y",
> +"ust", "tember", "ober", "ember", "ember" };
> +

I do not have the time for a full review, but this was directly obvious
to me.

First, the indentation is strange.

Second, since you are using av_strncasecmp(3) anyway, no need to split
the words like that: month_name[i] will do fine for av_strncasecmp(3)
and month_name[i]+3 will do fine for your mo_full, which is a misnomer.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] vp8: Add hwaccel hooks

2017-02-20 Thread Michael Niedermayer

On Mon, Feb 20, 2017 at 10:23:27AM +, Mark Thompson wrote:
> On 20/02/17 02:35, Michael Niedermayer wrote:
> > On Sun, Feb 19, 2017 at 09:29:33PM +, Mark Thompson wrote:
> >> On 19/02/17 21:04, Ronald S. Bultje wrote:
> >>> Hi,
> >>>
> >>> On Sun, Feb 19, 2017 at 12:23 PM, Mark Thompson  wrote:
> >>>
>  diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> 
> >>> [..]
> >>>
>  +avctx->get_format = webp_get_format;
> >>>
> >>>
> >>> Docs say:
> >>> "decoding: Set by user, if not set the native format will be chosen."
> >>> So I don't think decoders are supposed to set this.
> >>
> >> The webp decoder does not support get_format.  I suppose the user could 
> >> technically store something there and then read it back, so save and 
> >> restore the value across the relevant calls?
> > 
> > This is quite ugly, why do you want to do that ?
> > 
> > get_format is set by the user
> > the get_format API requires the function to choose one of the caller
> > provided formats and it can choose any.
> > I dont know what your function does but its different from the API.
> > It smells very much like a hack ...
> > 
> > The one situation in which you can set get_format from libavcodec is
> > when there is a seperate codec context you created, that is that you
> > are its user.
> > 
> > can you explain why this code messes with avctx->get_format ?
> > and for example doesnt change the code that calls get_format so that
> > it passes a correct pixel format list which then by any get_format()
> > results in a correct format ?
> > or am i missing something ?
> 

> The current WebP decoder calls the VP8 decoder /using the same 
> AVCodecContext/.

so they are kind of the same decoder


> Previously the format was set directly on the VP8Context, but now that the 
> VP8 decoder uses ff_get_format() that initial value is not used.  This change 
> adds a get_format() callback on the AVCodecContext used by the VP8 decoder to 
> set the format appropriately.

But this is semantically wrong, the formats supported by the decoder
implementation are choosen by the code calling get_format().
the get_format callback chooses amongth these formats depending on the
users preferrance/usefullness.


> 
> Now, because that is the same AVCodecContext as the one supplied by the user, 
> the user could themselves have stored something into the get_format field 
> (even though it isn't used by the WebP decoder) and expect to be able to read 
> it back correctly later.  I think this would be madness, but is I suppose 
> technically allowed; saving and restoring the value across the VP8 calls 
> would fix that case.

Why do you try to misuse the API ?
i mean i think we agree that this violates the API. Making sure it
works doesnt solve that it violates the API. And anyone working on
the API would likely assume that code conforms to the API documentation.
-> the developer would think one thing and the code would do another
thats a recipe for creating bugs.

I think the code calling *get_format() should pass the correct list
of formats to the callback and not some other part override the users
get_format calback to work around that the list passed is wrong.

am i missing something ?
is what i suggested difficult to do or do you see a issue with that
solution ?

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] vp8: Add hwaccel hooks

2017-02-20 Thread Mark Thompson

On 20/02/17 02:35, Michael Niedermayer wrote:
> On Sun, Feb 19, 2017 at 09:29:33PM +, Mark Thompson wrote:
>> On 19/02/17 21:04, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Feb 19, 2017 at 12:23 PM, Mark Thompson  wrote:
>>>
 diff --git a/libavcodec/webp.c b/libavcodec/webp.c

>>> [..]
>>>
 +avctx->get_format = webp_get_format;
>>>
>>>
>>> Docs say:
>>> "decoding: Set by user, if not set the native format will be chosen."
>>> So I don't think decoders are supposed to set this.
>>
>> The webp decoder does not support get_format.  I suppose the user could 
>> technically store something there and then read it back, so save and restore 
>> the value across the relevant calls?
> 
> This is quite ugly, why do you want to do that ?
> 
> get_format is set by the user
> the get_format API requires the function to choose one of the caller
> provided formats and it can choose any.
> I dont know what your function does but its different from the API.
> It smells very much like a hack ...
> 
> The one situation in which you can set get_format from libavcodec is
> when there is a seperate codec context you created, that is that you
> are its user.
> 
> can you explain why this code messes with avctx->get_format ?
> and for example doesnt change the code that calls get_format so that
> it passes a correct pixel format list which then by any get_format()
> results in a correct format ?
> or am i missing something ?

The current WebP decoder calls the VP8 decoder /using the same AVCodecContext/. 
 Previously the format was set directly on the VP8Context, but now that the VP8 
decoder uses ff_get_format() that initial value is not used.  This change adds 
a get_format() callback on the AVCodecContext used by the VP8 decoder to set 
the format appropriately.

Now, because that is the same AVCodecContext as the one supplied by the user, 
the user could themselves have stored something into the get_format field (even 
though it isn't used by the WebP decoder) and expect to be able to read it back 
correctly later.  I think this would be madness, but is I suppose technically 
allowed; saving and restoring the value across the VP8 calls would fix that 
case.

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: fix cid 1401346 Dereferencing pointer error

2017-02-20 Thread Steven Liu

check if proto is null before av_strcasecmp
CID:  1401346

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e673f59..fad6cae 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -668,7 +668,7 @@ static void hls_free_segments(HLSSegment *p)
 static void set_http_options(AVFormatContext *s, AVDictionary **options, 
HLSContext *c)
 {
 const char *proto = avio_find_protocol_name(s->filename);
-int http_base_proto = !av_strcasecmp(proto, "http") || 
!av_strcasecmp(proto, "https");
+int http_base_proto = proto ? (!av_strcasecmp(proto, "http") || 
!av_strcasecmp(proto, "https")) : 0;
 
 if (c->method) {
 av_dict_set(options, "method", c->method, 0);
-- 
2.10.1.382.ga23ca1b.dirty



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

39 matches

Mail list logo