[FFmpeg-devel] [PATCH] fate: add aac id3v2 demux test

2018-02-03 Thread rshaffer 
From: Richard Shaffer 

A basic test for demuxing raw AAC (ADTS) with ID3v2 tags.
---
This is related to the patch 'libavformat/aac: Parse ID3 tags between ADTS
frames', and will fail without it. The test file contains an ID3 tag at the
beginning as well as a second tag between frames. While the test doesn't check
that the tags' data have been parsed correctly, without the aforementioned
patch, the demuxing will fail on the second tag and return an invalid data
error.

The sample will be attached in a separate email.

Thanks,

-Richard

 tests/fate/demux.mak|   3 +-
 tests/ref/fate/adts-id3v2-demux | 240 
 2 files changed, 242 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/adts-id3v2-demux

diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak
index 9427ac30c8..306904b9de 100644
--- a/tests/fate/demux.mak
+++ b/tests/fate/demux.mak
@@ -1,9 +1,10 @@
 FATE_SAMPLES_DEMUX-$(call DEMDEC, AVI, FRAPS) += fate-avio-direct
 fate-avio-direct: CMD = framecrc -avioflags direct -i 
$(TARGET_SAMPLES)/fraps/fraps-v5-bouncing-balls-partial.avi -avioflags direct
 
-FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux 
fate-adts-id3v1-demux
+FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux 
fate-adts-id3v1-demux fate-adts-id3v2-demux
 fate-adts-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/ct_faac-adts.aac -c:a copy
 fate-adts-id3v1-demux: CMD = framecrc -f aac -i 
$(TARGET_SAMPLES)/aac/id3v1.aac -c:a copy
+fate-adts-id3v2-demux: CMD = framecrc -f aac -i 
$(TARGET_SAMPLES)/aac/id3v2.aac -c:a copy
 
 FATE_SAMPLES_DEMUX-$(CONFIG_AEA_DEMUXER) += fate-aea-demux
 fate-aea-demux: CMD = crc -i $(TARGET_SAMPLES)/aea/chirp.aea -c:a copy
diff --git a/tests/ref/fate/adts-id3v2-demux b/tests/ref/fate/adts-id3v2-demux
new file mode 100644
index 00..db00e3b81e
--- /dev/null
+++ b/tests/ref/fate/adts-id3v2-demux
@@ -0,0 +1,240 @@
+#tb 0: 1/28224000
+#media_type 0: audio
+#codec_id 0: aac
+#sample_rate 0: 48000
+#channel_layout 0: 4
+#channel_layout_name 0: mono
+0,  0,  0,   602112,  126, 0x639a3a5b
+0, 602112, 602112,   602112,  135, 0x5b1f3ced
+0,1204224,1204224,   602112,  123, 0xfcb73863
+0,1806336,1806336,   602112,  126, 0x639a3a5b
+0,2408448,2408448,   602112,  135, 0x5b1f3ced
+0,3010560,3010560,   602112,  123, 0xfcb73863
+0,3612672,3612672,   602112,  144, 0xa0434540
+0,4214784,4214784,   602112,  119, 0x45053cc1
+0,4816896,4816896,   602112,  111, 0x23043aaf
+0,5419008,5419008,   602112,  126, 0x693a3a67
+0,6021120,6021120,   602112,  149, 0x31304a34
+0,6623232,6623232,   602112,  111, 0x21603aab
+0,7225344,7225344,   602112,  132, 0xe42d43b3
+0,7827456,7827456,   602112,  135, 0x5b1f3ced
+0,8429568,8429568,   602112,  123, 0xfe8b3867
+0,9031680,9031680,   602112,  144, 0xa26b4544
+0,9633792,9633792,   602112,  129, 0xf7de3bc7
+0,   10235904,   10235904,   602112,  111, 0x1fbc3aa7
+0,   10838016,   10838016,   602112,  126, 0x657a3a5f
+0,   11440128,   11440128,   602112,  140, 0xdb6542ec
+0,   12042240,   12042240,   602112,  123, 0xfcb73863
+0,   12644352,   12644352,   602112,  138, 0xad7e44b6
+0,   13246464,   13246464,   602112,  119, 0x46c93cc5
+0,   13848576,   13848576,   602112,  123, 0xfe8b3867
+0,   14450688,   14450688,   602112,  144, 0xa26b4544
+0,   15052800,   15052800,   602112,  129, 0xf7de3bc7
+0,   15654912,   15654912,   602112,  111, 0x1fbc3aa7
+0,   16257024,   16257024,   602112,  126, 0x657a3a5f
+0,   16859136,   16859136,   602112,  140, 0xdb6542ec
+0,   17461248,   17461248,   602112,  123, 0xfcb73863
+0,   18063360,   18063360,   602112,  138, 0xad7e44b6
+0,   18665472,   18665472,   602112,  119, 0x46c93cc5
+0,   19267584,   19267584,   602112,  123, 0xfe8b3867
+0,   19869696,   19869696,   602112,  144, 0xa26b4544
+0,   20471808,   20471808,   602112,  129, 0xf7de3bc7
+0,   21073920,   21073920,   602112,  111, 0x1fbc3aa7
+0,   21676032,   21676032,   602112,  126, 0x657a3a5f
+0,   22278144,   22278144,   602112,  140, 0xdb6542ec
+0,   22880256,   22880256,   602112,  123, 0xfcb73863
+0,   23482368,   23482368,   602112,  138, 0xad7e44b6
+0,   24084480,   24084480,   602112,  119, 0x488d3cc9
+0,   24686592,   24686592,   602112,  123, 0xfe8b3867
+0,   25288704,   25288704,   602112,  144, 0xa26b4544
+0,   25890816,   25890816,   602112,  129, 0xf7de3bc7
+0,   26492928,   26492928,   602112,  111, 0x1fbc3aa7
+0,   27095040,   27095040,   602112,  126, 0x657a3a5f
+0,   27697152,   27697152,   602112,  140, 0xdb6542ec
+0,   28299264,   28299264,   602112,  123, 0xfcb73863
+0,   28901376,   28901376,   602112,  126, 0x639a3a5b
+0,   29503488,

Re: [FFmpeg-devel] [PATCH] fate: add aac id3v2 demux test

2018-02-03 Thread Richard Shaffer 
Attaching sample file for the test.

-Richard

On Sat, Feb 3, 2018 at 11:24 PM,   wrote:
> From: Richard Shaffer 
>
> A basic test for demuxing raw AAC (ADTS) with ID3v2 tags.
> ---
> This is related to the patch 'libavformat/aac: Parse ID3 tags between ADTS
> frames', and will fail without it. The test file contains an ID3 tag at the
> beginning as well as a second tag between frames. While the test doesn't check
> that the tags' data have been parsed correctly, without the aforementioned
> patch, the demuxing will fail on the second tag and return an invalid data
> error.
>
> The sample will be attached in a separate email.
>
> Thanks,
>
> -Richard
>
>  tests/fate/demux.mak|   3 +-
>  tests/ref/fate/adts-id3v2-demux | 240 
> 
>  2 files changed, 242 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/adts-id3v2-demux
>
> diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak
> index 9427ac30c8..306904b9de 100644
> --- a/tests/fate/demux.mak
> +++ b/tests/fate/demux.mak
> @@ -1,9 +1,10 @@
>  FATE_SAMPLES_DEMUX-$(call DEMDEC, AVI, FRAPS) += fate-avio-direct
>  fate-avio-direct: CMD = framecrc -avioflags direct -i 
> $(TARGET_SAMPLES)/fraps/fraps-v5-bouncing-balls-partial.avi -avioflags direct
>
> -FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux 
> fate-adts-id3v1-demux
> +FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux 
> fate-adts-id3v1-demux fate-adts-id3v2-demux
>  fate-adts-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/ct_faac-adts.aac -c:a 
> copy
>  fate-adts-id3v1-demux: CMD = framecrc -f aac -i 
> $(TARGET_SAMPLES)/aac/id3v1.aac -c:a copy
> +fate-adts-id3v2-demux: CMD = framecrc -f aac -i 
> $(TARGET_SAMPLES)/aac/id3v2.aac -c:a copy
>
>  FATE_SAMPLES_DEMUX-$(CONFIG_AEA_DEMUXER) += fate-aea-demux
>  fate-aea-demux: CMD = crc -i $(TARGET_SAMPLES)/aea/chirp.aea -c:a copy
> diff --git a/tests/ref/fate/adts-id3v2-demux b/tests/ref/fate/adts-id3v2-demux
> new file mode 100644
> index 00..db00e3b81e
> --- /dev/null
> +++ b/tests/ref/fate/adts-id3v2-demux
> @@ -0,0 +1,240 @@
> +#tb 0: 1/28224000
> +#media_type 0: audio
> +#codec_id 0: aac
> +#sample_rate 0: 48000
> +#channel_layout 0: 4
> +#channel_layout_name 0: mono
> +0,  0,  0,   602112,  126, 0x639a3a5b
> +0, 602112, 602112,   602112,  135, 0x5b1f3ced
> +0,1204224,1204224,   602112,  123, 0xfcb73863
> +0,1806336,1806336,   602112,  126, 0x639a3a5b
> +0,2408448,2408448,   602112,  135, 0x5b1f3ced
> +0,3010560,3010560,   602112,  123, 0xfcb73863
> +0,3612672,3612672,   602112,  144, 0xa0434540
> +0,4214784,4214784,   602112,  119, 0x45053cc1
> +0,4816896,4816896,   602112,  111, 0x23043aaf
> +0,5419008,5419008,   602112,  126, 0x693a3a67
> +0,6021120,6021120,   602112,  149, 0x31304a34
> +0,6623232,6623232,   602112,  111, 0x21603aab
> +0,7225344,7225344,   602112,  132, 0xe42d43b3
> +0,7827456,7827456,   602112,  135, 0x5b1f3ced
> +0,8429568,8429568,   602112,  123, 0xfe8b3867
> +0,9031680,9031680,   602112,  144, 0xa26b4544
> +0,9633792,9633792,   602112,  129, 0xf7de3bc7
> +0,   10235904,   10235904,   602112,  111, 0x1fbc3aa7
> +0,   10838016,   10838016,   602112,  126, 0x657a3a5f
> +0,   11440128,   11440128,   602112,  140, 0xdb6542ec
> +0,   12042240,   12042240,   602112,  123, 0xfcb73863
> +0,   12644352,   12644352,   602112,  138, 0xad7e44b6
> +0,   13246464,   13246464,   602112,  119, 0x46c93cc5
> +0,   13848576,   13848576,   602112,  123, 0xfe8b3867
> +0,   14450688,   14450688,   602112,  144, 0xa26b4544
> +0,   15052800,   15052800,   602112,  129, 0xf7de3bc7
> +0,   15654912,   15654912,   602112,  111, 0x1fbc3aa7
> +0,   16257024,   16257024,   602112,  126, 0x657a3a5f
> +0,   16859136,   16859136,   602112,  140, 0xdb6542ec
> +0,   17461248,   17461248,   602112,  123, 0xfcb73863
> +0,   18063360,   18063360,   602112,  138, 0xad7e44b6
> +0,   18665472,   18665472,   602112,  119, 0x46c93cc5
> +0,   19267584,   19267584,   602112,  123, 0xfe8b3867
> +0,   19869696,   19869696,   602112,  144, 0xa26b4544
> +0,   20471808,   20471808,   602112,  129, 0xf7de3bc7
> +0,   21073920,   21073920,   602112,  111, 0x1fbc3aa7
> +0,   21676032,   21676032,   602112,  126, 0x657a3a5f
> +0,   22278144,   22278144,   602112,  140, 0xdb6542ec
> +0,   22880256,   22880256,   602112,  123, 0xfcb73863
> +0,   23482368,   23482368,   602112,  138, 0xad7e44b6
> +0,   24084480,   24084480,   602112,  119, 0x488d3cc9
> +0,   24686592,   24686592,   602112,  123, 0xfe8b3867
> +0,   25288704,   25288704,   602112,  144, 0xa26b4544
> +0,   25890816,   25890816,   602112,  129, 0xf7de3bc7
> +0,

[FFmpeg-devel] FriBidi Version 1.0.0 is released; any changes needed to ffmpeg ?

2018-02-03 Thread walshdcw 
I noticed that FriBidi Version 1.0.0 is released on git 
https://github.com/fribidi/fribidi/releases
and has a new api.  I wonder, does that mean ffmpeg needs any changes to match 
it ?

"Version 1.0.0 of FriBidi is a major update that adds support for all the 
changes
to the Unicode Bidirectional Algorithm that were introduced in UAX #9, version 
6.3,
and beyond. 
This library contains test code that validates the algorithm against the 
test-files
provided by the Unicode consortium, and have been verified to be 100% compliant
with version 10 of the unicode algorithm. 
Because of changes to the algorithm, the previous API have been deprecated
in favor of a new API that introduces another couple of parameters. 
But the old API has been retained, and will return the same results 
as before these algorithmic changes."
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/pafvideo: Check allocated frame size

2018-02-03 Thread Michael Niedermayer 
Fixes: OOM
Fixes: 5549/clusterfuzz-testcase-minimized-5390553567985664

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/pafvideo.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/pafvideo.c b/libavcodec/pafvideo.c
index 6980ae1b35..7c5861dfaf 100644
--- a/libavcodec/pafvideo.c
+++ b/libavcodec/pafvideo.c
@@ -78,6 +78,7 @@ static av_cold int paf_video_init(AVCodecContext *avctx)
 {
 PAFVideoDecContext *c = avctx->priv_data;
 int i;
+int ret;
 
 c->width  = avctx->width;
 c->height = avctx->height;
@@ -90,6 +91,9 @@ static av_cold int paf_video_init(AVCodecContext *avctx)
 }
 
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
+ret = av_image_check_size2(avctx->width, FFALIGN(avctx->height, 256), 
avctx->max_pixels, avctx->pix_fmt, 0, avctx);
+if (ret < 0)
+return ret;
 
 c->pic = av_frame_alloc();
 if (!c->pic)
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()

2018-02-03 Thread James Almer 
On 2/3/2018 7:51 PM, Muhammad Faiz wrote:
> Precalculate and constify ff_square_tab.
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavcodec/me_cmp.c  | 51 
> +---
>  libavcodec/me_cmp.h  |  4 +---
>  libavcodec/mpegvideo_enc.c   |  2 +-
>  libavcodec/mpegvideoencdsp.c |  2 +-
>  libavcodec/snowenc.c |  2 +-
>  libavcodec/utils.c   | 13 ---
>  6 files changed, 43 insertions(+), 31 deletions(-)
> 
> diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
> index 5e34a11593..67a5bb5c71 100644
> --- a/libavcodec/me_cmp.c
> +++ b/libavcodec/me_cmp.c
> @@ -22,6 +22,7 @@
>  
>  #include "libavutil/attributes.h"
>  #include "libavutil/internal.h"
> +#include "libavutil/thread.h"

Unused?

>  #include "avcodec.h"
>  #include "copy_block.h"
>  #include "simple_idct.h"
> @@ -29,13 +30,47 @@
>  #include "mpegvideo.h"
>  #include "config.h"
>  
> -uint32_t ff_square_tab[512] = { 0, };
> +/* (i - 256) * (i - 256) */
> +const uint32_t ff_square_tab[512] = {
> +65536, 65025, 64516, 64009, 63504, 63001, 62500, 62001, 61504, 61009, 
> 60516, 60025, 59536, 59049, 58564, 58081,
> +57600, 57121, 56644, 56169, 55696, 55225, 54756, 54289, 53824, 53361, 
> 52900, 52441, 51984, 51529, 51076, 50625,
> +50176, 49729, 49284, 48841, 48400, 47961, 47524, 47089, 46656, 46225, 
> 45796, 45369, 44944, 44521, 44100, 43681,
> +43264, 42849, 42436, 42025, 41616, 41209, 40804, 40401, 4, 39601, 
> 39204, 38809, 38416, 38025, 37636, 37249,
> +36864, 36481, 36100, 35721, 35344, 34969, 34596, 34225, 33856, 33489, 
> 33124, 32761, 32400, 32041, 31684, 31329,
> +30976, 30625, 30276, 29929, 29584, 29241, 28900, 28561, 28224, 27889, 
> 27556, 27225, 26896, 26569, 26244, 25921,
> +25600, 25281, 24964, 24649, 24336, 24025, 23716, 23409, 23104, 22801, 
> 22500, 22201, 21904, 21609, 21316, 21025,
> +20736, 20449, 20164, 19881, 19600, 19321, 19044, 18769, 18496, 18225, 
> 17956, 17689, 17424, 17161, 16900, 16641,
> +16384, 16129, 15876, 15625, 15376, 15129, 14884, 14641, 14400, 14161, 
> 13924, 13689, 13456, 13225, 12996, 12769,
> +12544, 12321, 12100, 11881, 11664, 11449, 11236, 11025, 10816, 10609, 
> 10404, 10201, 1,  9801,  9604,  9409,
> + 9216,  9025,  8836,  8649,  8464,  8281,  8100,  7921,  7744,  7569,  
> 7396,  7225,  7056,  6889,  6724,  6561,
> + 6400,  6241,  6084,  5929,  5776,  5625,  5476,  5329,  5184,  5041,  
> 4900,  4761,  4624,  4489,  4356,  4225,
> + 4096,  3969,  3844,  3721,  3600,  3481,  3364,  3249,  3136,  3025,  
> 2916,  2809,  2704,  2601,  2500,  2401,
> + 2304,  2209,  2116,  2025,  1936,  1849,  1764,  1681,  1600,  1521,  
> 1444,  1369,  1296,  1225,  1156,  1089,
> + 1024,   961,   900,   841,   784,   729,   676,   625,   576,   529,   
> 484,   441,   400,   361,   324,   289,
> +  256,   225,   196,   169,   144,   121,   100,81,64,49,
> 36,25,16, 9, 4, 1,
> +0, 1, 4, 9,16,25,36,49,64,81,   
> 100,   121,   144,   169,   196,   225,
> +  256,   289,   324,   361,   400,   441,   484,   529,   576,   625,   
> 676,   729,   784,   841,   900,   961,
> + 1024,  1089,  1156,  1225,  1296,  1369,  1444,  1521,  1600,  1681,  
> 1764,  1849,  1936,  2025,  2116,  2209,
> + 2304,  2401,  2500,  2601,  2704,  2809,  2916,  3025,  3136,  3249,  
> 3364,  3481,  3600,  3721,  3844,  3969,
> + 4096,  4225,  4356,  4489,  4624,  4761,  4900,  5041,  5184,  5329,  
> 5476,  5625,  5776,  5929,  6084,  6241,
> + 6400,  6561,  6724,  6889,  7056,  7225,  7396,  7569,  7744,  7921,  
> 8100,  8281,  8464,  8649,  8836,  9025,
> + 9216,  9409,  9604,  9801, 1, 10201, 10404, 10609, 10816, 11025, 
> 11236, 11449, 11664, 11881, 12100, 12321,
> +12544, 12769, 12996, 13225, 13456, 13689, 13924, 14161, 14400, 14641, 
> 14884, 15129, 15376, 15625, 15876, 16129,
> +16384, 16641, 16900, 17161, 17424, 17689, 17956, 18225, 18496, 18769, 
> 19044, 19321, 19600, 19881, 20164, 20449,
> +20736, 21025, 21316, 21609, 21904, 22201, 22500, 22801, 23104, 23409, 
> 23716, 24025, 24336, 24649, 24964, 25281,
> +25600, 25921, 26244, 26569, 26896, 27225, 27556, 27889, 28224, 28561, 
> 28900, 29241, 29584, 29929, 30276, 30625,
> +30976, 31329, 31684, 32041, 32400, 32761, 33124, 33489, 33856, 34225, 
> 34596, 34969, 35344, 35721, 36100, 36481,
> +36864, 37249, 37636, 38025, 38416, 38809, 39204, 39601, 4, 40401, 
> 40804, 41209, 41616, 42025, 42436, 42849,
> +43264, 43681, 44100, 44521, 44944, 45369, 45796, 46225, 46656, 47089, 
> 47524, 47961, 48400, 48841, 49284, 49729,
> +50176, 50625, 51076, 51529, 51984, 52441, 52900, 53361, 53824, 54289, 
> 54756, 55225, 55696, 56169, 56644, 57121,
> +57600, 58081, 58564, 59049, 59536, 60025, 60516, 61009, 61504, 62001, 
> 62500, 63001, 63504, 64009, 64516, 65025,
> +};
>  
>  static int

Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS

2018-02-03 Thread Muhammad Faiz 
On Sat, Feb 3, 2018 at 9:22 PM, Niklas Haas  wrote:
> From: Niklas Haas 
>
> Right now, the PTS always starts out as 0, which causes problems on a
> seek or when inserting this filter mid-stream.
>
> Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first
> frame instead if this is the case.
> ---
>  libavfilter/af_loudnorm.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
> index a7f11cbe6e..314b25fa39 100644
> --- a/libavfilter/af_loudnorm.c
> +++ b/libavfilter/af_loudnorm.c
> @@ -431,6 +431,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  av_frame_copy_props(out, in);
>  }
>
> +if (s->pts == AV_NOPTS_VALUE)
> +s->pts = in->pts;
> +
>  out->pts = s->pts;
>  src = (const double *)in->data[0];
>  dst = (double *)out->data[0];
> @@ -763,7 +766,7 @@ static int config_input(AVFilterLink *inlink)
>  inlink->partial_buf_size = frame_size(inlink->sample_rate, 3000);
>  }
>
> -s->pts =
> +s->pts = AV_NOPTS_VALUE;
>  s->buf_index =
>  s->prev_buf_index =
>  s->limiter_buf_index = 0;
> --
> 2.16.1

Output pts ideally should be based on input pts in all cases
(not only in the first pts case), because input pts may be non-monotonic.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: do not use init_static_data on some codecs

2018-02-03 Thread Muhammad Faiz 
On Sat, Feb 3, 2018 at 9:29 AM, Michael Niedermayer
 wrote:
> On Sat, Feb 03, 2018 at 01:36:37AM +0700, Muhammad Faiz wrote:
>> They don't modify AVCodec, no needs to call it at register. They will be
>> wasteful if these codecs are unused. Instead, call static data initialization
>> at codecs' init.
>>
>> Benchmark:
>> old: 51281340 decicycles in avcodec_register_all,   1 runs,  0 skips
>> new:  6738960 decicycles in avcodec_register_all,   1 runs,  0 skips
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavcodec/jpeg2000dec.c | 16 +---
>>  libavcodec/qdmc.c|  7 +--
>>  libavcodec/wmavoice.c|  7 +--
>>  3 files changed, 19 insertions(+), 11 deletions(-)
>
> LGTM

Applied.

>
> it would be better though if this would happen for all
> init_static_data() without the need for extra code per codec

As wm4 explained.

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

Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators

2018-02-03 Thread Muhammad Faiz 
On Sat, Feb 3, 2018 at 5:39 PM, wm4  wrote:
> On Fri,  2 Feb 2018 19:44:18 +
> Josh de Kock  wrote:
>
>> ---
>>  fftools/cmdutils.c |  2 +-
>>  libavcodec/avcodec.h   |  6 +-
>>  libavcodec/bitstream_filter.c  |  4 ++--
>>  libavcodec/bitstream_filters.c | 29 ++---
>>  4 files changed, 26 insertions(+), 15 deletions(-)
>>
>> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
>> index 9ecc51b..0b06ccc 100644
>> --- a/fftools/cmdutils.c
>> +++ b/fftools/cmdutils.c
>> @@ -1586,7 +1586,7 @@ int show_bsfs(void *optctx, const char *opt, const 
>> char *arg)
>>  void *opaque = NULL;
>>
>>  printf("Bitstream filters:\n");
>> -while ((bsf = av_bsf_next()))
>> +while ((bsf = av_bsf_iterate()))
>>  printf("%s\n", bsf->name);
>>  printf("\n");
>>  return 0;
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 99f5fb9..c41779a 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -5728,7 +5728,7 @@ attribute_deprecated
>>  void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
>>  /**
>>   * @deprecated the old bitstream filtering API (using 
>> AVBitStreamFilterContext)
>> - * is deprecated. Use av_bsf_next() from the new bitstream filtering API 
>> (using
>> + * is deprecated. Use av_bsf_iterate() from the new bitstream filtering API 
>> (using
>>   * AVBSFContext).
>>   */
>>  attribute_deprecated
>> @@ -5750,7 +5750,11 @@ const AVBitStreamFilter *av_bsf_get_by_name(const 
>> char *name);
>>   * @return the next registered bitstream filter or NULL when the iteration 
>> is
>>   * finished
>>   */
>> +const AVBitStreamFilter *av_bsf_iterate(void **opaque);
>> +#if FF_API_NEXT
>> +attribute_deprecated
>>  const AVBitStreamFilter *av_bsf_next(void **opaque);
>> +#endif
>>
>>  /**
>>   * Allocate a context for a given bitstream filter. The caller must fill in 
>> the
>> diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
>> index ed1cf33..ca11ed3 100644
>> --- a/libavcodec/bitstream_filter.c
>> +++ b/libavcodec/bitstream_filter.c
>> @@ -34,9 +34,9 @@ const AVBitStreamFilter *av_bitstream_filter_next(const 
>> AVBitStreamFilter *f)
>>  void *opaque = NULL;
>>
>>  while (filter != f)
>> -filter = av_bsf_next();
>> +filter = av_bsf_iterate();
>>
>> -return av_bsf_next();
>> +return av_bsf_iterate();
>>  }
>>
>>  void av_register_bitstream_filter(AVBitStreamFilter *bsf)
>> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
>> index 7b0cb50..338ef82 100644
>> --- a/libavcodec/bitstream_filters.c
>> +++ b/libavcodec/bitstream_filters.c
>> @@ -52,7 +52,7 @@ extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
>>
>>  #include "libavcodec/bsf_list.c"
>>
>> -const AVBitStreamFilter *av_bsf_next(void **opaque)
>> +const AVBitStreamFilter *av_bsf_iterate(void **opaque)
>>  {
>>  uintptr_t i = (uintptr_t)*opaque;
>>  const AVBitStreamFilter *f = bitstream_filters[i];
>> @@ -63,12 +63,18 @@ const AVBitStreamFilter *av_bsf_next(void **opaque)
>>  return f;
>>  }
>>
>> +#if FF_API_NEXT
>> +const AVBitStreamFilter *av_bsf_next(void **opaque) {
>> +return av_bsf_iterate(opaque);
>> +}
>> +#endif
>> +
>>  const AVBitStreamFilter *av_bsf_get_by_name(const char *name)
>>  {
>> -int i;
>> +const AVBitStreamFilter *f = NULL;
>> +void *i = 0;
>>
>> -for (i = 0; bitstream_filters[i]; i++) {
>> -const AVBitStreamFilter *f = bitstream_filters[i];
>> +while ((f = av_bsf_iterate())) {
>>  if (!strcmp(f->name, name))
>>  return f;
>>  }
>> @@ -78,19 +84,20 @@ const AVBitStreamFilter *av_bsf_get_by_name(const char 
>> *name)
>>
>>  const AVClass *ff_bsf_child_class_next(const AVClass *prev)
>>  {
>> -int i;
>> +const AVBitStreamFilter *f = NULL;
>> +void *i = 0;
>>
>>  /* find the filter that corresponds to prev */
>> -for (i = 0; prev && bitstream_filters[i]; i++) {
>> -if (bitstream_filters[i]->priv_class == prev) {
>> -i++;
>> +while (prev && (f = av_bsf_iterate())) {
>> +if (f->priv_class == prev) {
>>  break;
>>  }
>>  }
>>
>>  /* find next filter with priv options */
>> -for (; bitstream_filters[i]; i++)
>> -if (bitstream_filters[i]->priv_class)
>> -return bitstream_filters[i]->priv_class;
>> +while ((f = av_bsf_iterate())) {
>> +if (f->priv_class)
>> +return f->priv_class;
>> +}
>>  return NULL;
>>  }
>
> I like _next better than _iterate (as others have also said), but I
> think I can tolerate it. At least it'll be consistent across all those
> APIs.

What about av*iterate(int index)?
As you suggested in
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224702.html

Anyway av_bsf_iterate() previously didn't exist, so we can freely
choose how it will be called (with int index

[FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()

2018-02-03 Thread Muhammad Faiz 
Precalculate and constify ff_square_tab.

Signed-off-by: Muhammad Faiz 
---
 libavcodec/me_cmp.c  | 51 +---
 libavcodec/me_cmp.h  |  4 +---
 libavcodec/mpegvideo_enc.c   |  2 +-
 libavcodec/mpegvideoencdsp.c |  2 +-
 libavcodec/snowenc.c |  2 +-
 libavcodec/utils.c   | 13 ---
 6 files changed, 43 insertions(+), 31 deletions(-)

diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
index 5e34a11593..67a5bb5c71 100644
--- a/libavcodec/me_cmp.c
+++ b/libavcodec/me_cmp.c
@@ -22,6 +22,7 @@
 
 #include "libavutil/attributes.h"
 #include "libavutil/internal.h"
+#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "copy_block.h"
 #include "simple_idct.h"
@@ -29,13 +30,47 @@
 #include "mpegvideo.h"
 #include "config.h"
 
-uint32_t ff_square_tab[512] = { 0, };
+/* (i - 256) * (i - 256) */
+const uint32_t ff_square_tab[512] = {
+65536, 65025, 64516, 64009, 63504, 63001, 62500, 62001, 61504, 61009, 
60516, 60025, 59536, 59049, 58564, 58081,
+57600, 57121, 56644, 56169, 55696, 55225, 54756, 54289, 53824, 53361, 
52900, 52441, 51984, 51529, 51076, 50625,
+50176, 49729, 49284, 48841, 48400, 47961, 47524, 47089, 46656, 46225, 
45796, 45369, 44944, 44521, 44100, 43681,
+43264, 42849, 42436, 42025, 41616, 41209, 40804, 40401, 4, 39601, 
39204, 38809, 38416, 38025, 37636, 37249,
+36864, 36481, 36100, 35721, 35344, 34969, 34596, 34225, 33856, 33489, 
33124, 32761, 32400, 32041, 31684, 31329,
+30976, 30625, 30276, 29929, 29584, 29241, 28900, 28561, 28224, 27889, 
27556, 27225, 26896, 26569, 26244, 25921,
+25600, 25281, 24964, 24649, 24336, 24025, 23716, 23409, 23104, 22801, 
22500, 22201, 21904, 21609, 21316, 21025,
+20736, 20449, 20164, 19881, 19600, 19321, 19044, 18769, 18496, 18225, 
17956, 17689, 17424, 17161, 16900, 16641,
+16384, 16129, 15876, 15625, 15376, 15129, 14884, 14641, 14400, 14161, 
13924, 13689, 13456, 13225, 12996, 12769,
+12544, 12321, 12100, 11881, 11664, 11449, 11236, 11025, 10816, 10609, 
10404, 10201, 1,  9801,  9604,  9409,
+ 9216,  9025,  8836,  8649,  8464,  8281,  8100,  7921,  7744,  7569,  
7396,  7225,  7056,  6889,  6724,  6561,
+ 6400,  6241,  6084,  5929,  5776,  5625,  5476,  5329,  5184,  5041,  
4900,  4761,  4624,  4489,  4356,  4225,
+ 4096,  3969,  3844,  3721,  3600,  3481,  3364,  3249,  3136,  3025,  
2916,  2809,  2704,  2601,  2500,  2401,
+ 2304,  2209,  2116,  2025,  1936,  1849,  1764,  1681,  1600,  1521,  
1444,  1369,  1296,  1225,  1156,  1089,
+ 1024,   961,   900,   841,   784,   729,   676,   625,   576,   529,   
484,   441,   400,   361,   324,   289,
+  256,   225,   196,   169,   144,   121,   100,81,64,49,
36,25,16, 9, 4, 1,
+0, 1, 4, 9,16,25,36,49,64,81,   
100,   121,   144,   169,   196,   225,
+  256,   289,   324,   361,   400,   441,   484,   529,   576,   625,   
676,   729,   784,   841,   900,   961,
+ 1024,  1089,  1156,  1225,  1296,  1369,  1444,  1521,  1600,  1681,  
1764,  1849,  1936,  2025,  2116,  2209,
+ 2304,  2401,  2500,  2601,  2704,  2809,  2916,  3025,  3136,  3249,  
3364,  3481,  3600,  3721,  3844,  3969,
+ 4096,  4225,  4356,  4489,  4624,  4761,  4900,  5041,  5184,  5329,  
5476,  5625,  5776,  5929,  6084,  6241,
+ 6400,  6561,  6724,  6889,  7056,  7225,  7396,  7569,  7744,  7921,  
8100,  8281,  8464,  8649,  8836,  9025,
+ 9216,  9409,  9604,  9801, 1, 10201, 10404, 10609, 10816, 11025, 
11236, 11449, 11664, 11881, 12100, 12321,
+12544, 12769, 12996, 13225, 13456, 13689, 13924, 14161, 14400, 14641, 
14884, 15129, 15376, 15625, 15876, 16129,
+16384, 16641, 16900, 17161, 17424, 17689, 17956, 18225, 18496, 18769, 
19044, 19321, 19600, 19881, 20164, 20449,
+20736, 21025, 21316, 21609, 21904, 22201, 22500, 22801, 23104, 23409, 
23716, 24025, 24336, 24649, 24964, 25281,
+25600, 25921, 26244, 26569, 26896, 27225, 27556, 27889, 28224, 28561, 
28900, 29241, 29584, 29929, 30276, 30625,
+30976, 31329, 31684, 32041, 32400, 32761, 33124, 33489, 33856, 34225, 
34596, 34969, 35344, 35721, 36100, 36481,
+36864, 37249, 37636, 38025, 38416, 38809, 39204, 39601, 4, 40401, 
40804, 41209, 41616, 42025, 42436, 42849,
+43264, 43681, 44100, 44521, 44944, 45369, 45796, 46225, 46656, 47089, 
47524, 47961, 48400, 48841, 49284, 49729,
+50176, 50625, 51076, 51529, 51984, 52441, 52900, 53361, 53824, 54289, 
54756, 55225, 55696, 56169, 56644, 57121,
+57600, 58081, 58564, 59049, 59536, 60025, 60516, 61009, 61504, 62001, 
62500, 63001, 63504, 64009, 64516, 65025,
+};
 
 static int sse4_c(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2,
   ptrdiff_t stride, int h)
 {
 int s = 0, i;
-uint32_t *sq = ff_square_tab + 256;
+const uint32_t *sq = ff_square_tab + 256;
 
 for (i = 0; i < h; i++) {
 s+=

[FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS

2018-02-03 Thread Niklas Haas 
From: Niklas Haas 

Right now, the PTS always starts out as 0, which causes problems on a
seek or when inserting this filter mid-stream.

Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first
frame instead if this is the case.
---
 libavfilter/af_loudnorm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
index a7f11cbe6e..314b25fa39 100644
--- a/libavfilter/af_loudnorm.c
+++ b/libavfilter/af_loudnorm.c
@@ -431,6 +431,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 av_frame_copy_props(out, in);
 }
 
+if (s->pts == AV_NOPTS_VALUE)
+s->pts = in->pts;
+
 out->pts = s->pts;
 src = (const double *)in->data[0];
 dst = (double *)out->data[0];
@@ -763,7 +766,7 @@ static int config_input(AVFilterLink *inlink)
 inlink->partial_buf_size = frame_size(inlink->sample_rate, 3000);
 }
 
-s->pts =
+s->pts = AV_NOPTS_VALUE;
 s->buf_index =
 s->prev_buf_index =
 s->limiter_buf_index = 0;
-- 
2.16.1

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

Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-03 Thread Jean-Christophe Kummer 
Loooking to it from a pragmatic management point of view, there is a lot of 
open source unfriendly community from the EBU/SMPTE world which would have 
their opinion about a failed or even more delayed IETF spec finalisation.

I think - given the efforts which have been put into it, the beauty with what  
is ALREADY existing, 
coexistency of v4 work and finalisation of v3 work towards IETF standardization 
is the strategy which 
we should concentrate on.  

16bit in v3: Please go for it. And allow for v4 for other discussions. 

Not to forget about all video projects which would be happy to see that IETF 
and the community finalises v3 also for it´s  8/10bit formats which have an 
even higher representation in hundred thousands of archive hours already now. 


If there is something I can do please contact me.


Christophe
NOA




-Ursprüngliche Nachricht-
Von: Cellar [mailto:cellar-boun...@ietf.org] Im Auftrag von Michael Niedermayer
Gesendet: Samstag, 03. Februar 2018 14:48
An: Codec Encoding for LossLess Archiving and Realtime transmission 

Cc: ffmpeg-devel@ffmpeg.org
Betreff: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 
and GBRAP16

On Sat, Feb 03, 2018 at 01:58:10PM +0100, Reto Kromer wrote:
> Michael Niedermayer wrote:
> 
> >To clarify my suggestion,
> >the algorithm should be tuned for high bit depth before using it for 
> >long term storage. This would be v4 (or later).
> >Personally i would wait for v4 and not use v3 for high bit depth. 
> >Which is why i think its not smart to extend the v3 implementation 
> >with more high depth support.
> 
> The issue is that in the real world we need to use the format now. 
> Otherwise the film archives must use MXF/DPX instead of Матрёшка/FFV1. 
> That's the point!

Then using the v3 16bit is probably the most realistic option.
And jeromes patch should probably be applied

I hope this will not reduce interrest in working on a improved 9-16bit mode in 
v4.


[...]

> Last but not least, since almost two years now it's impossible
> to work on the development of FFV1 v4. It's always the wrong
> time and/or the wrong place every time I am doing something for
> this cause. Why? This is extremely frustrating.

I want to understand this too. IMO v4 development should be more
important than or at least equally to the v3 draft polishing and neither 
should block the other.


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mov: Move +1 in check to avoid hypothetical overflow in add_ctts_entry()

2018-02-03 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index d16b431e03..a9b9ec025f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3233,7 +3233,7 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 FFMAX(min_size_needed, 2 * (*allocated_size)) :
 min_size_needed;
 
-if((unsigned)(*ctts_count) + 1 >= UINT_MAX / sizeof(MOVStts))
+if((unsigned)(*ctts_count) >= UINT_MAX / sizeof(MOVStts) - 1)
 return -1;
 
 ctts_buf_new = av_fast_realloc(*ctts_data, allocated_size, requested_size);
-- 
2.16.1

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

Re: [FFmpeg-devel] Fix ctts_index calculation

2018-02-03 Thread Michael Niedermayer 
On Fri, Feb 02, 2018 at 05:55:38PM -0800, Xiaohan Wang (王消寒) wrote:
> 

>  mov.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 87157b4053de0e044e78db72ef13e8058075c235  
> 0001-Fix-ctts_index-calculation.patch
> From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00 2001
> From: Xiaohan Wang 
> Date: Fri, 2 Feb 2018 17:33:56 -0800
> Subject: [PATCH] Fix ctts_index calculation
> 
> An index should never be equal to the count. Hence we must make sure
> *ctts_index < ctts_count.
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

should be reviewed by sasi idealy, he wrote this

thx


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] Abort early on decode_slice error

2018-02-03 Thread Michael Niedermayer 
On Sat, Feb 03, 2018 at 02:29:00AM -0800, Xiaohan Wang (王消寒) wrote:
> 

>  h264_slice.c |   17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 7fc1e8d4e0df4223089d2466c5a76b12a9171003  
> 0001-ffmpeg-Abort-early-on-decode_slice-error.patch
> From 971866f88bba20d7e2a993b1125bde6a8a5228d9 Mon Sep 17 00:00:00 2001
> From: Xiaohan Wang 
> Date: Sat, 3 Feb 2018 01:43:35 -0800
> Subject: [PATCH] ffmpeg: Abort early on decode_slice error
> 
> When decode_slice() fails, it is possible that ff_h264_decode_mb_cavlc()
> failed due to wrong sl->qscale values, e.g. dquant out of range. In this
> case, we should abort early instead of continue. Otherwise, we could be
> using the wrong sl->qscale and cause access violations.
> 
> BUG=806122
> ---
>  libavcodec/h264_slice.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index e6b7998834..a638414688 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -2734,6 +2734,7 @@ int ff_h264_execute_decode_slices(H264Context *h)
>  H264SliceContext *sl;
>  int context_count = h->nb_slice_ctx_queued;
>  int ret = 0;
> +int *ret_array = NULL;
>  int i, j;
>  
>  h->slice_ctx[0].next_slice_idx = INT_MAX;
> @@ -2776,8 +2777,21 @@ int ff_h264_execute_decode_slices(H264Context *h)
>  sl->next_slice_idx = next_slice_idx;
>  }
>  
> +ret_array = av_malloc_array(context_count, sizeof(int));
> +if (!ret_array) {
> +ret = AVERROR(ENOMEM);
> +goto finish;
> +}
> +
>  avctx->execute(avctx, decode_slice, h->slice_ctx,
> -   NULL, context_count, sizeof(h->slice_ctx[0]));
> +   ret_array, context_count, sizeof(h->slice_ctx[0]));
> +
> +for (i = 0; i < context_count; i++) {
> +if (ret_array[i] < 0) {
> +ret = ret_array[i];
> +goto finish;
> +}
> +}

This will break error concealment as it skips some of the code
used for it
it also would skip loop filtering of the correctly decoded slices
in some cases


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] libavformat/hls: Support metadata updates from subdemuxers

2018-02-03 Thread Richard Shaffer 
On Saturday, February 3, 2018, wm4  wrote:

> On Fri,  2 Feb 2018 12:59:45 -0800
> rshaf...@tunein.com wrote:
>
> > From: Richard Shaffer 
> >
> > If a subdemuxer has the updated metadata event flag set, the metadata is
> copied
> > to the corresponding stream. The flag is cleared on the subdemuxer and
> the
> > appropriate event flag is set on the stream.
> > ---
> > This is iteration #2.
>
> You can pass "-v2" as argument to git send-email to automatically add
> "v2" to the subject.
>
> Oh, thanks. I guess I should have read the man page.

> >
> > In this version, we don't try to copy metadata from subdemuxer streams,
> only
> > from the AVFormatContext. The case where metadata is updated on a
> sub-demuxer
> > stream would have probably never happened.
>
> Oh, I thought it was the other way around.
>
> > The above change made the code that was previously in the
> > update_metadata_from_subdemuxer function a little simpler. That
> function was
> > also kind of ugly, because in one case it read and set flags, and in
> another it
> > didn't. It seemed simpler just to move the respective updates into
> read_header
> > and read_packet, respectively, so that's what I did.
> >
> > -Richard
> >
> >  libavformat/hls.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 9bd54c84cc..c578bf86e3 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -1062,6 +1062,7 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
> >  /* demuxer not yet opened, defer picture attachment */
> >  pls->id3_deferred_extra = extra_meta;
> >
> > +ff_id3v2_parse_priv_dict(, _meta);
> >  av_dict_copy(>ctx->metadata, metadata, 0);
> >  pls->id3_initial = metadata;
> >
> > @@ -1960,6 +1961,7 @@ static int hls_read_header(AVFormatContext *s)
> >  if (pls->id3_deferred_extra && pls->ctx->nb_streams == 1) {
> >  ff_id3v2_parse_apic(pls->ctx, >id3_deferred_extra);
> >  avformat_queue_attached_pictures(pls->ctx);
> > +ff_id3v2_parse_priv(pls->ctx, >id3_deferred_extra);
> >  ff_id3v2_free_extra_meta(>id3_deferred_extra);
> >  pls->id3_deferred_extra = NULL;
> >  }
> > @@ -1986,6 +1988,13 @@ static int hls_read_header(AVFormatContext *s)
> >  if (ret < 0)
> >  goto fail;
> >
> > +/*
> > + * Copy any metadata from playlist to main streams, but do not
> set
> > + * event flags.
> > + */
> > +if (pls->n_main_streams)
> > +av_dict_copy(>main_streams[0]->metadata,
> pls->ctx->metadata, 0);
> > +
> >  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_AUDIO);
> >  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_VIDEO);
> >  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_SUBTITLE);
> > @@ -2170,6 +2179,17 @@ static int hls_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> >  return ret;
> >  }
> >
> > +// If sub-demuxer reports updated metadata, copy it to the
> first stream
> > +// and set its AVSTREAM_EVENT_FLAG_METADATA_UPDATED flag.
> > +if (pls->ctx->event_flags & AVFMT_EVENT_FLAG_METADATA_UPDATED)
> {
> > +if (pls->n_main_streams) {
> > +st = pls->main_streams[0];
> > +av_dict_copy(>metadata, pls->ctx->metadata, 0);
> > +st->event_flags |= AVSTREAM_EVENT_FLAG_METADATA_
> UPDATED;
> > +}
> > +pls->ctx->event_flags &= ~AVFMT_EVENT_FLAG_METADATA_
> UPDATED;
> > +}
> > +
> >  /* check if noheader flag has been cleared by the subdemuxer */
> >  if (pls->has_noheader_flag && !(pls->ctx->ctx_flags &
> AVFMTCTX_NOHEADER)) {
> >  pls->has_noheader_flag = 0;
>
> Fine then. If it works ad nobody else has comments, I can push on Monday
> or so.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix crash in join filter

2018-02-03 Thread Michael Niedermayer 
On Sat, Feb 03, 2018 at 10:13:28AM +0100, Paul B Mahol wrote:
> On 2/3/18, Nikolas Bowe  wrote:
> > Previously if ff_outlink_frame_wanted() returned 0 it could dereference a
> > null pointer when trying to read nb_samples.
> > ---
> >  libavfilter/af_join.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavfilter/af_join.c b/libavfilter/af_join.c
> > index cf5131e8dc..4f86e13558 100644
> > --- a/libavfilter/af_join.c
> > +++ b/libavfilter/af_join.c
> > @@ -485,6 +485,9 @@ static int activate(AVFilterContext *ctx)
> >  return 0;
> >  }
> >  }
> > +if (!s->input_frames[0]) {
> > +return 0;
> > +}
> >  }
> >
> >  nb_samples = s->input_frames[0]->nb_samples;
> > --
> > 2.16.0.rc1.238.g530d649a79-goog
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> lgtm

will apply

thx

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideodec: Fix bytes left check in decode_frame()

2018-02-03 Thread Michael Niedermayer 
On Sat, Feb 03, 2018 at 10:16:07AM +0100, Paul B Mahol wrote:
> On 2/2/18, Michael Niedermayer  wrote:
> > Fixes: out of array read
> > Fixes: poc-2017.avi
> >
> > Found-by: GwanYeong Kim 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/utvideodec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
> > index 608c8c4998..1bcd14e74c 100644
> > --- a/libavcodec/utvideodec.c
> > +++ b/libavcodec/utvideodec.c
> > @@ -676,7 +676,7 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data, int *got_frame,
> >  for (j = 0; j < c->slices; j++) {
> >  slice_end   = bytestream2_get_le32u();
> >  if (slice_end < 0 || slice_end < slice_start ||
> > -bytestream2_get_bytes_left() < slice_end) {
> > +bytestream2_get_bytes_left() < slice_end + 1024LL) {
> >  av_log(avctx, AV_LOG_ERROR, "Incorrect slice size\n");
> >  return AVERROR_INVALIDDATA;
> >  }
> > --
> > 2.16.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> Why this magic number 1024LL ?

Because of the  line later:

bytestream2_skipu(, 1024);

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

[FFmpeg-devel] [PATCH] avcodec/scpr: Fix reading a pixel before the first

2018-02-03 Thread Michael Niedermayer 
Fixes: 5540/clusterfuzz-testcase-minimized-6122458273808384

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/scpr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
index cbe1bc40d9..ad6073dbf0 100644
--- a/libavcodec/scpr.c
+++ b/libavcodec/scpr.c
@@ -681,6 +681,8 @@ static int decompress_p(AVCodecContext *avctx,
 return AVERROR_INVALIDDATA;
 
 if (bx == 0) {
+if (by < 2)
+return AVERROR_INVALIDDATA;
 z = backstep;
 } else {
 z = 0;
@@ -710,6 +712,8 @@ static int decompress_p(AVCodecContext *avctx,
 return AVERROR_INVALIDDATA;
 
 if (bx == 0) {
+if (by < 2)
+return AVERROR_INVALIDDATA;
 z = backstep;
 } else {
 z = 0;
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/wavpack: Fix integer overflow in FFABS

2018-02-03 Thread Michael Niedermayer 
On Wed, Jan 31, 2018 at 03:17:36AM +0100, Michael Niedermayer wrote:
> Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to 
> an unsigned type to negate this value to itself
> Fixes: 5396/clusterfuzz-testcase-minimized-655829281536
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wavpack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-03 Thread Michael Niedermayer 
On Sat, Feb 03, 2018 at 01:58:10PM +0100, Reto Kromer wrote:
> Michael Niedermayer wrote:
> 
> >To clarify my suggestion,
> >the algorithm should be tuned for high bit depth before using
> >it for long term storage. This would be v4 (or later).
> >Personally i would wait for v4 and not use v3 for high bit
> >depth. Which is why i think its not smart to extend the v3
> >implementation with more high depth support.
> 
> The issue is that in the real world we need to use the format
> now. Otherwise the film archives must use MXF/DPX instead of
> Матрёшка/FFV1. That's the point!

Then using the v3 16bit is probably the most realistic option.
And jeromes patch should probably be applied

I hope this will not reduce interrest in working on a improved 
9-16bit mode in v4.


[...]

> Last but not least, since almost two years now it's impossible
> to work on the development of FFV1 v4. It's always the wrong
> time and/or the wrong place every time I am doing something for
> this cause. Why? This is extremely frustrating.

I want to understand this too. IMO v4 development should be more
important than or at least equally to the v3 draft polishing and neither 
should block the other.


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-03 Thread Reto Kromer 
Michael Niedermayer wrote:

>To clarify my suggestion,
>the algorithm should be tuned for high bit depth before using
>it for long term storage. This would be v4 (or later).
>Personally i would wait for v4 and not use v3 for high bit
>depth. Which is why i think its not smart to extend the v3
>implementation with more high depth support.

The issue is that in the real world we need to use the format
now. Otherwise the film archives must use MXF/DPX instead of
Матрёшка/FFV1. That's the point!

I presented to the industry this solution in August 2016 at "The
Reel Thing" technical symposium in Hollywood, and an article on
it was published in April 2017 in FIAF's "Journal of Film
Preservation". The archives cannot wait forever! And they are
indeed important users of FFmpeg, in my opinion.

I already paid EUR 7000 for the FFV1 use in the archival world,
and will pay EUR 5000 additionally in the next months.

>IIUC people created such files somehow beliving that the IMO
>clear warning somehow suggested that this was stable. And with
>that we are a bit stuck with this for v3

I presented last November at the "No Time to Wait" symposium
(nomen est omen) in Vienna - i.e. in your city - how we have to
work today and how we hope to modify container and codec during
the next data migration.

Last but not least, since almost two years now it's impossible
to work on the development of FFV1 v4. It's always the wrong
time and/or the wrong place every time I am doing something for
this cause. Why? This is extremely frustrating.

Best regards, Reto

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

Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-03 Thread Michael Niedermayer 
On Sat, Feb 03, 2018 at 10:57:44AM +0100, Jerome Martinez wrote:
> On 03/02/2018 00:10, Michael Niedermayer wrote:
> >On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote:
> >>Add support for 16-bit/component RGB with Alpha encoding and decoding in
> >>FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding.
> >>
> >>Resulting bitstream was tested about lossless encoding/decoding by the
> >>compression from DPX to FFV1 then decompression from FFV1 to DPX, see
> >>commands below (resulting framemd5 hashes are all same).
> >>Resulting bitstream is decodable by another decoder (with same resulting
> >>framemd5 hash).
> >>Resulting bitstream passed through a conformance checker compared to current
> >>FFV1 specification IETF draft.
> >>
> >>About the patch:
> >>- some modified lines are not used (the ones not used when f->use32bit is
> >>1), but it makes the code more coherent (especially because decode_rgb_frame
> >>signature is same for both 16-bit and 32-bit version) and prepares the
> >>support of RGBA with 10/12/14 bits/component.
> >>- GBRAP16 was chosen for decoding because GBRP16 is already used when no
> >>alpha, and the code is more prepared for planar pix_fmt when bit depth is
> >>>8.
> >>- "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;"
> >>is a copy of a line a bit above about the detection of transparency, I
> >>preferred to reuse it as is even if "YA" 16-bit/component is not (yet)
> >>supported.
> >>
> >>FFmpeg commands used for tests:
> >>./ffmpeg -i in.dpx -c:v ffv1 out.mkv
> >>./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv
> >>./ffmpeg -i out.mkv out.dpx
> >>
> >>./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5
> >>./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5
> >>./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5
> >>./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5
> >>
> >>Test file used (renamed to in.dpx):
> >>https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx
> >I would prefer if the algorithm would be tuned to 16bit data before
> >adding more formats to the encoder which require all decoders to support
> >them.
> >
> >Dont you agree that this would be the better strategy ?
> 
> ccing CELLAR.
> 
> My remarks are the same as with RGB48 support (including that the
> compression performance of RGB48 so RGBA64 is already very good without
> touching on the algorithm, and IMO tuning should be for v4 for all bit
> depths), with addition that since the last debate on that on ffmpeg-devel
> there was no patch proposal so no consensus on CELLAR for limiting the
> specifications to what exists in FFmpeg implementation (so current consensus
> is that FFV1 specs are for all bit depths for all supported color spaces),
> and since the last debate FFV1 specs draft were sent to IETF tracker so it
> is close to the end.
> 
> This patch is just adding the support of RGBA64 conforming to the current
> specs and without big changes (no complex stuff, just mapping to the right
> pix_fmt), and the current specs are the ones with very high chances to be
> the standard (up to now nobody suggested on CELLAR, the place for the spec,
> to limit the support to a set of bit depths / color spaces, and nobody
> suggested a tuning for some bit depths), with the main advantage that the
> specs are clear about all bit depths for all color spaces supported (it is
> good that it is generic). Will this patch be accepted after the IETF flags
> the current specs as stable if there is no changes on the wording about the
> support of all bit depths?
> 

> on my side, I can not spend time on FFV1 v4 R (tuning and more) when I
> spend time with such blocking (for me) issue about v3 (i.e. agreement in
> specs draft on all bit depths for all supported color spaces but no
> agreement in practice on all bit depths for all supported color spaces).
> 

> So for answering directly to the question, no I don't agree that changing v3
> bitstream with specific tuning of the bitstream depending of the bit depth
> is a better strategy,

That was not meant.
To clarify my suggestion,
the algorithm should be tuned for high bit depth before using it for long term
storage. This would be v4 (or later).
Personally i would wait for v4 and not use v3 for high bit depth. Which is
why i think its not smart to extend the v3 implementation with more high depth
support.


> actually this is the opposite (I think that the best
> strategy is to support as many bit depths as possible in implementations
> with current v3 specs and that all tuning should be in the version flagged
> as experimental, not the one flagged as stable even before working on IETF
> version, if we change a bitstream marked as stable we break the trust in the
> spec being stable, IMO any tuning of the bitstream should be done in v4, and
> any performance improvement without breaking the bitstream could be done
> after this patch without problem).

IIRC teh v3 draft was

Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators

2018-02-03 Thread wm4 
On Fri,  2 Feb 2018 19:44:18 +
Josh de Kock  wrote:

> ---
>  fftools/cmdutils.c |  2 +-
>  libavcodec/avcodec.h   |  6 +-
>  libavcodec/bitstream_filter.c  |  4 ++--
>  libavcodec/bitstream_filters.c | 29 ++---
>  4 files changed, 26 insertions(+), 15 deletions(-)
> 
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9ecc51b..0b06ccc 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -1586,7 +1586,7 @@ int show_bsfs(void *optctx, const char *opt, const char 
> *arg)
>  void *opaque = NULL;
>  
>  printf("Bitstream filters:\n");
> -while ((bsf = av_bsf_next()))
> +while ((bsf = av_bsf_iterate()))
>  printf("%s\n", bsf->name);
>  printf("\n");
>  return 0;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 99f5fb9..c41779a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5728,7 +5728,7 @@ attribute_deprecated
>  void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
>  /**
>   * @deprecated the old bitstream filtering API (using 
> AVBitStreamFilterContext)
> - * is deprecated. Use av_bsf_next() from the new bitstream filtering API 
> (using
> + * is deprecated. Use av_bsf_iterate() from the new bitstream filtering API 
> (using
>   * AVBSFContext).
>   */
>  attribute_deprecated
> @@ -5750,7 +5750,11 @@ const AVBitStreamFilter *av_bsf_get_by_name(const char 
> *name);
>   * @return the next registered bitstream filter or NULL when the iteration is
>   * finished
>   */
> +const AVBitStreamFilter *av_bsf_iterate(void **opaque);
> +#if FF_API_NEXT
> +attribute_deprecated
>  const AVBitStreamFilter *av_bsf_next(void **opaque);
> +#endif
>  
>  /**
>   * Allocate a context for a given bitstream filter. The caller must fill in 
> the
> diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
> index ed1cf33..ca11ed3 100644
> --- a/libavcodec/bitstream_filter.c
> +++ b/libavcodec/bitstream_filter.c
> @@ -34,9 +34,9 @@ const AVBitStreamFilter *av_bitstream_filter_next(const 
> AVBitStreamFilter *f)
>  void *opaque = NULL;
>  
>  while (filter != f)
> -filter = av_bsf_next();
> +filter = av_bsf_iterate();
>  
> -return av_bsf_next();
> +return av_bsf_iterate();
>  }
>  
>  void av_register_bitstream_filter(AVBitStreamFilter *bsf)
> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
> index 7b0cb50..338ef82 100644
> --- a/libavcodec/bitstream_filters.c
> +++ b/libavcodec/bitstream_filters.c
> @@ -52,7 +52,7 @@ extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
>  
>  #include "libavcodec/bsf_list.c"
>  
> -const AVBitStreamFilter *av_bsf_next(void **opaque)
> +const AVBitStreamFilter *av_bsf_iterate(void **opaque)
>  {
>  uintptr_t i = (uintptr_t)*opaque;
>  const AVBitStreamFilter *f = bitstream_filters[i];
> @@ -63,12 +63,18 @@ const AVBitStreamFilter *av_bsf_next(void **opaque)
>  return f;
>  }
>  
> +#if FF_API_NEXT
> +const AVBitStreamFilter *av_bsf_next(void **opaque) {
> +return av_bsf_iterate(opaque);
> +}
> +#endif
> +
>  const AVBitStreamFilter *av_bsf_get_by_name(const char *name)
>  {
> -int i;
> +const AVBitStreamFilter *f = NULL;
> +void *i = 0;
>  
> -for (i = 0; bitstream_filters[i]; i++) {
> -const AVBitStreamFilter *f = bitstream_filters[i];
> +while ((f = av_bsf_iterate())) {
>  if (!strcmp(f->name, name))
>  return f;
>  }
> @@ -78,19 +84,20 @@ const AVBitStreamFilter *av_bsf_get_by_name(const char 
> *name)
>  
>  const AVClass *ff_bsf_child_class_next(const AVClass *prev)
>  {
> -int i;
> +const AVBitStreamFilter *f = NULL;
> +void *i = 0;
>  
>  /* find the filter that corresponds to prev */
> -for (i = 0; prev && bitstream_filters[i]; i++) {
> -if (bitstream_filters[i]->priv_class == prev) {
> -i++;
> +while (prev && (f = av_bsf_iterate())) {
> +if (f->priv_class == prev) {
>  break;
>  }
>  }
>  
>  /* find next filter with priv options */
> -for (; bitstream_filters[i]; i++)
> -if (bitstream_filters[i]->priv_class)
> -return bitstream_filters[i]->priv_class;
> +while ((f = av_bsf_iterate())) {
> +if (f->priv_class)
> +return f->priv_class;
> +}
>  return NULL;
>  }

I like _next better than _iterate (as others have also said), but I
think I can tolerate it. At least it'll be consistent across all those
APIs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix crash in join filter

2018-02-03 Thread Paul B Mahol 
On 2/3/18, Nikolas Bowe  wrote:
> Previously if ff_outlink_frame_wanted() returned 0 it could dereference a
> null pointer when trying to read nb_samples.
> ---
>  libavfilter/af_join.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavfilter/af_join.c b/libavfilter/af_join.c
> index cf5131e8dc..4f86e13558 100644
> --- a/libavfilter/af_join.c
> +++ b/libavfilter/af_join.c
> @@ -485,6 +485,9 @@ static int activate(AVFilterContext *ctx)
>  return 0;
>  }
>  }
> +if (!s->input_frames[0]) {
> +return 0;
> +}
>  }
>
>  nb_samples = s->input_frames[0]->nb_samples;
> --
> 2.16.0.rc1.238.g530d649a79-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] avcodec: do not use init_static_data on some codecs

2018-02-03 Thread wm4 
On Sat, 3 Feb 2018 03:29:40 +0100
Michael Niedermayer  wrote:

> On Sat, Feb 03, 2018 at 01:36:37AM +0700, Muhammad Faiz wrote:
> > They don't modify AVCodec, no needs to call it at register. They will be
> > wasteful if these codecs are unused. Instead, call static data 
> > initialization
> > at codecs' init.
> > 
> > Benchmark:
> > old: 51281340 decicycles in avcodec_register_all,   1 runs,  0 skips
> > new:  6738960 decicycles in avcodec_register_all,   1 runs,  0 skips
> > 
> > Signed-off-by: Muhammad Faiz 
> > ---
> >  libavcodec/jpeg2000dec.c | 16 +---
> >  libavcodec/qdmc.c|  7 +--
> >  libavcodec/wmavoice.c|  7 +--
> >  3 files changed, 19 insertions(+), 11 deletions(-)  
> 
> LGTM
>  
> it would be better though if this would happen for all
> init_static_data() without the need for extra code per codec

AFAIK these are the only ones that use it, other than some encoder
wrappers which change AVCodec.pix_fmts (and thus need to be done it as
soon as the user could see the AVCodec pointer).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/hls: Support metadata updates from subdemuxers

2018-02-03 Thread wm4 
On Fri,  2 Feb 2018 12:59:45 -0800
rshaf...@tunein.com wrote:

> From: Richard Shaffer 
> 
> If a subdemuxer has the updated metadata event flag set, the metadata is 
> copied
> to the corresponding stream. The flag is cleared on the subdemuxer and the
> appropriate event flag is set on the stream.
> ---
> This is iteration #2.

You can pass "-v2" as argument to git send-email to automatically add
"v2" to the subject.

> 
> In this version, we don't try to copy metadata from subdemuxer streams, only
> from the AVFormatContext. The case where metadata is updated on a sub-demuxer
> stream would have probably never happened.

Oh, I thought it was the other way around.

> The above change made the code that was previously in the
> update_metadata_from_subdemuxer function a little simpler. That function was
> also kind of ugly, because in one case it read and set flags, and in another 
> it
> didn't. It seemed simpler just to move the respective updates into read_header
> and read_packet, respectively, so that's what I did.
> 
> -Richard
> 
>  libavformat/hls.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 9bd54c84cc..c578bf86e3 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1062,6 +1062,7 @@ static void handle_id3(AVIOContext *pb, struct playlist 
> *pls)
>  /* demuxer not yet opened, defer picture attachment */
>  pls->id3_deferred_extra = extra_meta;
>  
> +ff_id3v2_parse_priv_dict(, _meta);
>  av_dict_copy(>ctx->metadata, metadata, 0);
>  pls->id3_initial = metadata;
>  
> @@ -1960,6 +1961,7 @@ static int hls_read_header(AVFormatContext *s)
>  if (pls->id3_deferred_extra && pls->ctx->nb_streams == 1) {
>  ff_id3v2_parse_apic(pls->ctx, >id3_deferred_extra);
>  avformat_queue_attached_pictures(pls->ctx);
> +ff_id3v2_parse_priv(pls->ctx, >id3_deferred_extra);
>  ff_id3v2_free_extra_meta(>id3_deferred_extra);
>  pls->id3_deferred_extra = NULL;
>  }
> @@ -1986,6 +1988,13 @@ static int hls_read_header(AVFormatContext *s)
>  if (ret < 0)
>  goto fail;
>  
> +/*
> + * Copy any metadata from playlist to main streams, but do not set
> + * event flags.
> + */
> +if (pls->n_main_streams)
> +av_dict_copy(>main_streams[0]->metadata, 
> pls->ctx->metadata, 0);
> +
>  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_AUDIO);
>  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_VIDEO);
>  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_SUBTITLE);
> @@ -2170,6 +2179,17 @@ static int hls_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  return ret;
>  }
>  
> +// If sub-demuxer reports updated metadata, copy it to the first 
> stream
> +// and set its AVSTREAM_EVENT_FLAG_METADATA_UPDATED flag.
> +if (pls->ctx->event_flags & AVFMT_EVENT_FLAG_METADATA_UPDATED) {
> +if (pls->n_main_streams) {
> +st = pls->main_streams[0];
> +av_dict_copy(>metadata, pls->ctx->metadata, 0);
> +st->event_flags |= AVSTREAM_EVENT_FLAG_METADATA_UPDATED;
> +}
> +pls->ctx->event_flags &= ~AVFMT_EVENT_FLAG_METADATA_UPDATED;
> +}
> +
>  /* check if noheader flag has been cleared by the subdemuxer */
>  if (pls->has_noheader_flag && !(pls->ctx->ctx_flags & 
> AVFMTCTX_NOHEADER)) {
>  pls->has_noheader_flag = 0;

Fine then. If it works ad nobody else has comments, I can push on Monday
or so.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Abort early on decode_slice error

2018-02-03 Thread 王消寒 



0001-ffmpeg-Abort-early-on-decode_slice-error.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-03 Thread Jerome Martinez 

On 03/02/2018 00:10, Michael Niedermayer wrote:

On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote:

Add support for 16-bit/component RGB with Alpha encoding and decoding in
FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding.

Resulting bitstream was tested about lossless encoding/decoding by the
compression from DPX to FFV1 then decompression from FFV1 to DPX, see
commands below (resulting framemd5 hashes are all same).
Resulting bitstream is decodable by another decoder (with same resulting
framemd5 hash).
Resulting bitstream passed through a conformance checker compared to current
FFV1 specification IETF draft.

About the patch:
- some modified lines are not used (the ones not used when f->use32bit is
1), but it makes the code more coherent (especially because decode_rgb_frame
signature is same for both 16-bit and 32-bit version) and prepares the
support of RGBA with 10/12/14 bits/component.
- GBRAP16 was chosen for decoding because GBRP16 is already used when no
alpha, and the code is more prepared for planar pix_fmt when bit depth is

8.

- "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;"
is a copy of a line a bit above about the detection of transparency, I
preferred to reuse it as is even if "YA" 16-bit/component is not (yet)
supported.

FFmpeg commands used for tests:
./ffmpeg -i in.dpx -c:v ffv1 out.mkv
./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv
./ffmpeg -i out.mkv out.dpx

./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5
./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5
./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5
./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5

Test file used (renamed to in.dpx):
https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx

I would prefer if the algorithm would be tuned to 16bit data before
adding more formats to the encoder which require all decoders to support
them.

Dont you agree that this would be the better strategy ?


ccing CELLAR.

My remarks are the same as with RGB48 support (including that the 
compression performance of RGB48 so RGBA64 is already very good without 
touching on the algorithm, and IMO tuning should be for v4 for all bit 
depths), with addition that since the last debate on that on 
ffmpeg-devel there was no patch proposal so no consensus on CELLAR for 
limiting the specifications to what exists in FFmpeg implementation (so 
current consensus is that FFV1 specs are for all bit depths for all 
supported color spaces), and since the last debate FFV1 specs draft were 
sent to IETF tracker so it is close to the end.


This patch is just adding the support of RGBA64 conforming to the 
current specs and without big changes (no complex stuff, just mapping to 
the right pix_fmt), and the current specs are the ones with very high 
chances to be the standard (up to now nobody suggested on CELLAR, the 
place for the spec, to limit the support to a set of bit depths / color 
spaces, and nobody suggested a tuning for some bit depths), with the 
main advantage that the specs are clear about all bit depths for all 
color spaces supported (it is good that it is generic). Will this patch 
be accepted after the IETF flags the current specs as stable if there is 
no changes on the wording about the support of all bit depths?


on my side, I can not spend time on FFV1 v4 R (tuning and more) when I 
spend time with such blocking (for me) issue about v3 (i.e. agreement in 
specs draft on all bit depths for all supported color spaces but no 
agreement in practice on all bit depths for all supported color spaces).


So for answering directly to the question, no I don't agree that 
changing v3 bitstream with specific tuning of the bitstream depending of 
the bit depth is a better strategy, actually this is the opposite (I 
think that the best strategy is to support as many bit depths as 
possible in implementations with current v3 specs and that all tuning 
should be in the version flagged as experimental, not the one flagged as 
stable even before working on IETF version, if we change a bitstream 
marked as stable we break the trust in the spec being stable, IMO any 
tuning of the bitstream should be done in v4, and any performance 
improvement without breaking the bitstream could be done after this 
patch without problem).


Jérôme
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/utvideodec: Fix bytes left check in decode_frame()

2018-02-03 Thread Paul B Mahol 
On 2/2/18, Michael Niedermayer  wrote:
> Fixes: out of array read
> Fixes: poc-2017.avi
>
> Found-by: GwanYeong Kim 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utvideodec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
> index 608c8c4998..1bcd14e74c 100644
> --- a/libavcodec/utvideodec.c
> +++ b/libavcodec/utvideodec.c
> @@ -676,7 +676,7 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
>  for (j = 0; j < c->slices; j++) {
>  slice_end   = bytestream2_get_le32u();
>  if (slice_end < 0 || slice_end < slice_start ||
> -bytestream2_get_bytes_left() < slice_end) {
> +bytestream2_get_bytes_left() < slice_end + 1024LL) {
>  av_log(avctx, AV_LOG_ERROR, "Incorrect slice size\n");
>  return AVERROR_INVALIDDATA;
>  }
> --
> 2.16.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Why this magic number 1024LL ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-03 Thread Reto Kromer 
Michael Niedermayer wrote:

>I would prefer if the algorithm would be tuned to 16bit data
>before adding more formats to the encoder which require all
>decoders to support them.
>
>Dont you agree that this would be the better strategy ?

To my understanding FFV1 v3 is actually stable. Or am I missing
something?

Some of us are indeed trying to work on v4, but this is another
topic, I guess.

Best regards, Reto

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