date:20170804

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-08-04 Thread Rostislav Pehlivanov

On 4 August 2017 at 23:58, Ivan Kalvachev  wrote:

>
> >> I had it mixed before, but I changed it to be consistent.
> >> Some new avx instruction are not overloaded or
> >> available without their "v-" prefix.
> >> e.g. x86util uses vpbroadcastw in SPLATW.
> >
> > Every instruction that has both a legacy encoding and a VEX-encoding
> > will be automatically converted to VEX in AVX functions when written
> > without the v-prefix. There is no legacy encoding for newer
> > instructions so there's no reason for x86inc to overload those.
>
> That's great, but it doesn't address the original problem.
> Do you insist on removing the "v-" prefix from AVX only instructions?
>
>
I insist.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] libaf/hlsenc: allow dynamic encryption key rotation

2017-08-04 Thread Steven Liu

2017-08-05 11:36 GMT+08:00 DeHackEd :
> Makes behaviour of 805ce25b1d2f optional, re-enables
> HLS key rotation feature
>
> Signed-off-by: DHE 
> ---
>  doc/muxers.texi  | 7 ++-
>  libavformat/hlsenc.c | 4 +++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> v1->v2: Actually works this time
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 94472ce..a7324a4 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -551,7 +551,7 @@ format. The optional third line specifies the 
> initialization vector (IV) as a
>  hexadecimal string to be used instead of the segment sequence number 
> (default)
>  for encryption. Changes to @var{key_info_file} will result in segment
>  encryption with the new key/IV and an entry in the playlist for the new key
> -URI/IV.
> +URI/IV if @code{hls_flags periodic_rekey} is enabled.
>
>  Key info file format:
>  @example
> @@ -665,6 +665,11 @@ first segment's information.
>  @item omit_endlist
>  Do not append the @code{EXT-X-ENDLIST} tag at the end of the playlist.
>
> +@item periodic_rekey
> +The file specified by @code{hls_key_info} will be checked periodically and
> +detect updates to the encryption info. Be sure to replace this file 
> atomically,
> +including the file containing the AES encryption key.
> +
>  @item split_by_time
>  Allow segments to start on frames other than keyframes. This improves
>  behavior on some players when the time between keyframes is inconsistent,
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5cf8c89..74a3249 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -85,6 +85,7 @@ typedef enum HLSFlags {
>  HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment 
> duration (microsec) in segment filenames when use_localtime  e.g.: %%09t
>  HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size 
> (bytes) in segment filenames when use_localtime  e.g.: %%014s
>  HLS_TEMP_FILE = (1 << 11),
> +HLS_PERIODIC_REKEY = (1 << 12),
>  } HLSFlags;
>
>  typedef enum {
> @@ -1236,7 +1237,7 @@ static int hls_start(AVFormatContext *s)
>" will use -hls_key_info_file priority\n");
>  }
>
> -if (c->number <= 1) {
> +if (c->number <= 1 || (c->flags & HLS_PERIODIC_REKEY)) {
>  if (c->key_info_file) {
>  if ((err = hls_encryption_start(s)) < 0)
>  goto fail;
> @@ -1804,6 +1805,7 @@ static const AVOption options[] = {
>  {"second_level_segment_index", "include segment index in segment 
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
> HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX,   E, "flags"},
>  {"second_level_segment_duration", "include segment duration in segment 
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
> HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX,   E, "flags"},
>  {"second_level_segment_size", "include segment size in segment filenames 
> when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
> HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX,   E, "flags"},
> +{"periodic_rekey", "reload keyinfo file periodically for re-keying", 0, 
> AV_OPT_TYPE_CONST, {.i64 = HLS_PERIODIC_REKEY }, 0, UINT_MAX,   E, "flags"},
>  {"use_localtime", "set filename expansion with strftime at segment 
> creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  {"use_localtime_mkdir", "create last directory component in 
> strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
> {.i64 = 0 }, 0, 1, E },
>  {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
> AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
> "pl_type" },
> --
> 1.8.4.1
> ___
> 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

[FFmpeg-devel] [PATCH v2] libaf/hlsenc: allow dynamic encryption key rotation

2017-08-04 Thread DeHackEd

Makes behaviour of 805ce25b1d2f optional, re-enables
HLS key rotation feature

Signed-off-by: DHE 
---
 doc/muxers.texi  | 7 ++-
 libavformat/hlsenc.c | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

v1->v2: Actually works this time

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 94472ce..a7324a4 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -551,7 +551,7 @@ format. The optional third line specifies the 
initialization vector (IV) as a
 hexadecimal string to be used instead of the segment sequence number (default)
 for encryption. Changes to @var{key_info_file} will result in segment
 encryption with the new key/IV and an entry in the playlist for the new key
-URI/IV.
+URI/IV if @code{hls_flags periodic_rekey} is enabled.

 Key info file format:
 @example
@@ -665,6 +665,11 @@ first segment's information.
 @item omit_endlist
 Do not append the @code{EXT-X-ENDLIST} tag at the end of the playlist.

+@item periodic_rekey
+The file specified by @code{hls_key_info} will be checked periodically and
+detect updates to the encryption info. Be sure to replace this file atomically,
+including the file containing the AES encryption key.
+
 @item split_by_time
 Allow segments to start on frames other than keyframes. This improves
 behavior on some players when the time between keyframes is inconsistent,
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5cf8c89..74a3249 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -85,6 +85,7 @@ typedef enum HLSFlags {
 HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
 HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
 HLS_TEMP_FILE = (1 << 11),
+HLS_PERIODIC_REKEY = (1 << 12),
 } HLSFlags;

 typedef enum {
@@ -1236,7 +1237,7 @@ static int hls_start(AVFormatContext *s)
   " will use -hls_key_info_file priority\n");
 }

-if (c->number <= 1) {
+if (c->number <= 1 || (c->flags & HLS_PERIODIC_REKEY)) {
 if (c->key_info_file) {
 if ((err = hls_encryption_start(s)) < 0)
 goto fail;
@@ -1804,6 +1805,7 @@ static const AVOption options[] = {
 {"second_level_segment_index", "include segment index in segment filenames 
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX,   E, "flags"},
 {"second_level_segment_duration", "include segment duration in segment 
filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX,   E, "flags"},
 {"second_level_segment_size", "include segment size in segment filenames 
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX,   E, "flags"},
+{"periodic_rekey", "reload keyinfo file periodically for re-keying", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_PERIODIC_REKEY }, 0, UINT_MAX,   E, "flags"},
 {"use_localtime", "set filename expansion with strftime at segment 
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 {"use_localtime_mkdir", "create last directory component in 
strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
{.i64 = 0 }, 0, 1, E },
 {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
"pl_type" },
-- 
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libaf/hlsenc: allow dynamic encryption key rotation

2017-08-04 Thread DeHackEd

On 08/04/2017 10:36 PM, Steven Liu wrote:
> 2017-08-05 8:17 GMT+08:00 DeHackEd :
>> Signed-off-by: DHE 
>> ---
>>  doc/muxers.texi  | 7 ++-
>>  libavformat/hlsenc.c | 4 +++-
>>  2 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 94472ce..a7324a4 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -551,7 +551,7 @@ format. The optional third line specifies the 
>> initialization vector (IV) as a
>>  hexadecimal string to be used instead of the segment sequence number 
>> (default)
>>  for encryption. Changes to @var{key_info_file} will result in segment
>>  encryption with the new key/IV and an entry in the playlist for the new key
>> -URI/IV.
>> +URI/IV if @code{hls_flags periodic_rekey} is enabled.
>>
>>  Key info file format:
>>  @example
>> @@ -665,6 +665,11 @@ first segment's information.
>>  @item omit_endlist
>>  Do not append the @code{EXT-X-ENDLIST} tag at the end of the playlist.
>>
>> +@item periodic_rekey
>> +The file specified by @code{hls_key_info} will be checked periodically and
>> +detect updates to the encryption info. Be sure to replace this file 
>> atomically,
>> +including the file containing the AES encryption key.
>> +
>>  @item split_by_time
>>  Allow segments to start on frames other than keyframes. This improves
>>  behavior on some players when the time between keyframes is inconsistent,
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 5cf8c89..4d2e7fb 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -85,6 +85,7 @@ typedef enum HLSFlags {
>>  HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment 
>> duration (microsec) in segment filenames when use_localtime  e.g.: %%09t
>>  HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size 
>> (bytes) in segment filenames when use_localtime  e.g.: %%014s
>>  HLS_TEMP_FILE = (1 << 11),
>> +HLS_PERIODIC_REKEY = (1 << 12),
>>  } HLSFlags;
>>
>>  typedef enum {
>> @@ -1236,7 +1237,7 @@ static int hls_start(AVFormatContext *s)
>>" will use -hls_key_info_file priority\n");
>>  }
>>
>> -if (c->number <= 1) {
>> +if (c->number <= 1 && !(c->flags & HLS_PERIODIC_REKEY)) {
> it will always false when use HLS_PERIODIC_REKEY, then will not enable
> hls encryption.

Oops. Yeah I screwed that up pretty bad. I'll redo it.

>>  if (c->key_info_file) {
>>  if ((err = hls_encryption_start(s)) < 0)
>>  goto fail;
>> @@ -1804,6 +1805,7 @@ static const AVOption options[] = {
>>  {"second_level_segment_index", "include segment index in segment 
>> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
>> HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX,   E, "flags"},
>>  {"second_level_segment_duration", "include segment duration in segment 
>> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
>> HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX,   E, "flags"},
>>  {"second_level_segment_size", "include segment size in segment 
>> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
>> HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX,   E, "flags"},
>> +{"periodic_rekey", "reload keyinfo file periodically for re-keying", 0, 
>> AV_OPT_TYPE_CONST, {.i64 = HLS_PERIODIC_REKEY }, 0, UINT_MAX,   E, "flags"},
>>  {"use_localtime", "set filename expansion with strftime at segment 
>> creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>>  {"use_localtime_mkdir", "create last directory component in 
>> strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
>> {.i64 = 0 }, 0, 1, E },
>>  {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
>> AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
>> "pl_type" },
>> --
>> 1.8.4.1
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] libaf/hlsenc: allow dynamic encryption key rotation

2017-08-04 Thread Steven Liu

2017-08-05 8:17 GMT+08:00 DeHackEd :
> Signed-off-by: DHE 
> ---
>  doc/muxers.texi  | 7 ++-
>  libavformat/hlsenc.c | 4 +++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 94472ce..a7324a4 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -551,7 +551,7 @@ format. The optional third line specifies the 
> initialization vector (IV) as a
>  hexadecimal string to be used instead of the segment sequence number 
> (default)
>  for encryption. Changes to @var{key_info_file} will result in segment
>  encryption with the new key/IV and an entry in the playlist for the new key
> -URI/IV.
> +URI/IV if @code{hls_flags periodic_rekey} is enabled.
>
>  Key info file format:
>  @example
> @@ -665,6 +665,11 @@ first segment's information.
>  @item omit_endlist
>  Do not append the @code{EXT-X-ENDLIST} tag at the end of the playlist.
>
> +@item periodic_rekey
> +The file specified by @code{hls_key_info} will be checked periodically and
> +detect updates to the encryption info. Be sure to replace this file 
> atomically,
> +including the file containing the AES encryption key.
> +
>  @item split_by_time
>  Allow segments to start on frames other than keyframes. This improves
>  behavior on some players when the time between keyframes is inconsistent,
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5cf8c89..4d2e7fb 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -85,6 +85,7 @@ typedef enum HLSFlags {
>  HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment 
> duration (microsec) in segment filenames when use_localtime  e.g.: %%09t
>  HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size 
> (bytes) in segment filenames when use_localtime  e.g.: %%014s
>  HLS_TEMP_FILE = (1 << 11),
> +HLS_PERIODIC_REKEY = (1 << 12),
>  } HLSFlags;
>
>  typedef enum {
> @@ -1236,7 +1237,7 @@ static int hls_start(AVFormatContext *s)
>" will use -hls_key_info_file priority\n");
>  }
>
> -if (c->number <= 1) {
> +if (c->number <= 1 && !(c->flags & HLS_PERIODIC_REKEY)) {
it will always false when use HLS_PERIODIC_REKEY, then will not enable
hls encryption.
>  if (c->key_info_file) {
>  if ((err = hls_encryption_start(s)) < 0)
>  goto fail;
> @@ -1804,6 +1805,7 @@ static const AVOption options[] = {
>  {"second_level_segment_index", "include segment index in segment 
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
> HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX,   E, "flags"},
>  {"second_level_segment_duration", "include segment duration in segment 
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
> HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX,   E, "flags"},
>  {"second_level_segment_size", "include segment size in segment filenames 
> when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
> HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX,   E, "flags"},
> +{"periodic_rekey", "reload keyinfo file periodically for re-keying", 0, 
> AV_OPT_TYPE_CONST, {.i64 = HLS_PERIODIC_REKEY }, 0, UINT_MAX,   E, "flags"},
>  {"use_localtime", "set filename expansion with strftime at segment 
> creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  {"use_localtime_mkdir", "create last directory component in 
> strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
> {.i64 = 0 }, 0, 1, E },
>  {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
> AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
> "pl_type" },
> --
> 1.8.4.1
> ___
> 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 07/14] lavfi/vf_overlay: use framesync2 options.

2017-08-04 Thread Michael Niedermayer

On Wed, Aug 02, 2017 at 08:06:37AM +0200, Nicolas George wrote:
> Le quintidi 15 thermidor, an CCXXV, Michael Niedermayer a écrit :
> > removing these elements causes command lines using them to fail
> > for example:
> > 
> > ./ffmpeg -i matrixbench_mpeg2.mpg -i lena.pnm -filter_complex 
> > 'overlay=10:main_h-overlay_h-10:pass' -qscale 2 -t 1 file.avi
> 
> Oh, the shorthand notation. The order of the non-essential options has
> changed in the past, including recently, and does not match the
> documentation,

The documentation says
@section overlay
[...]
@table @option
@item x
@item y
[...]
@item eof_action

Thats the order used in the example

Also either way
A user should be able to write a command line with filters from the
documentation and know if it will be supported in the future before
the future occurs and she finds out it stopped working.


> I have always considered it undocumented and as such
> unspecified.

> Moreover, with a separate object like that, keeping the order will be
> impossible: options added to the filter in the future will always come
> before the options in the framesync object.
> 
> Therefore, I consider this minor break of compatibility acceptable. I
> should have mentioned it, but I forgot, sorry.
> 
> What do other think?
> 
> Regards,
> 
> -- 
>   Nicolas George



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


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH] libaf/hlsenc: allow dynamic encryption key rotation

2017-08-04 Thread DeHackEd

Signed-off-by: DHE 
---
 doc/muxers.texi  | 7 ++-
 libavformat/hlsenc.c | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 94472ce..a7324a4 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -551,7 +551,7 @@ format. The optional third line specifies the 
initialization vector (IV) as a
 hexadecimal string to be used instead of the segment sequence number (default)
 for encryption. Changes to @var{key_info_file} will result in segment
 encryption with the new key/IV and an entry in the playlist for the new key
-URI/IV.
+URI/IV if @code{hls_flags periodic_rekey} is enabled.

 Key info file format:
 @example
@@ -665,6 +665,11 @@ first segment's information.
 @item omit_endlist
 Do not append the @code{EXT-X-ENDLIST} tag at the end of the playlist.

+@item periodic_rekey
+The file specified by @code{hls_key_info} will be checked periodically and
+detect updates to the encryption info. Be sure to replace this file atomically,
+including the file containing the AES encryption key.
+
 @item split_by_time
 Allow segments to start on frames other than keyframes. This improves
 behavior on some players when the time between keyframes is inconsistent,
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5cf8c89..4d2e7fb 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -85,6 +85,7 @@ typedef enum HLSFlags {
 HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
 HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
 HLS_TEMP_FILE = (1 << 11),
+HLS_PERIODIC_REKEY = (1 << 12),
 } HLSFlags;

 typedef enum {
@@ -1236,7 +1237,7 @@ static int hls_start(AVFormatContext *s)
   " will use -hls_key_info_file priority\n");
 }

-if (c->number <= 1) {
+if (c->number <= 1 && !(c->flags & HLS_PERIODIC_REKEY)) {
 if (c->key_info_file) {
 if ((err = hls_encryption_start(s)) < 0)
 goto fail;
@@ -1804,6 +1805,7 @@ static const AVOption options[] = {
 {"second_level_segment_index", "include segment index in segment filenames 
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX,   E, "flags"},
 {"second_level_segment_duration", "include segment duration in segment 
filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX,   E, "flags"},
 {"second_level_segment_size", "include segment size in segment filenames 
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX,   E, "flags"},
+{"periodic_rekey", "reload keyinfo file periodically for re-keying", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_PERIODIC_REKEY }, 0, UINT_MAX,   E, "flags"},
 {"use_localtime", "set filename expansion with strftime at segment 
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 {"use_localtime_mkdir", "create last directory component in 
strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
{.i64 = 0 }, 0, 1, E },
 {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
"pl_type" },
-- 
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

2017-08-04 Thread Rodger Combs

+sc->ctts_data = av_fast_realloc(sc->ctts_data, 
>ctts_allocated_size, request_size);
^ this line is incorrect; setting realloc's first arg to its return value leaks 
the existing allocation in the OOM case. Since you're doing your own 
calculation for the desired new size here, you may want to use av_reallocp 
(which frees the original allocation on failure).

When reading a trun that requires this sort of realloc, is it common for there 
to be any existing entries in the range we're writing? Would it be safe to 
remove+replace them? Could we do a single realloc + single memmove, and then 
fill the newly-opened space, rather than repeating the memmove for each entry?

> On Aug 4, 2017, at 18:02, Dale Curtis  wrote:
> 
> Any comments here? +rodger who wrote the original sidx processing for review.
> 
> - dale
> 
> On Mon, Jul 31, 2017 at 3:01 PM, Dale Curtis  > wrote:
> Whoops, that patch accidentally reverted to an earlier version. Here's the 
> fixed one that works with the mpg sample mentioned above.
> 
> - dale
> 
> On Mon, Jul 31, 2017 at 2:29 PM, Dale Curtis  > wrote:
> Here's an updated patch with a fate test attached. You'll need to add 
> http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 
>  to the 
> fate-suite/mov for this test. This is licensed under creative commons 
> attribution, so it should be fine for tests: https://peach.blender.org/about/ 
>  I tried to use the existing samples, but 
> you need a clip long enough that the entire index isn't generated from the 
> start.
> 
> - dale
> 
> On Tue, Jul 25, 2017 at 1:03 PM, Michael Niedermayer  > wrote:
> On Mon, Jul 24, 2017 at 02:32:41PM -0700, Dale Curtis wrote:
> > On Thu, Jul 20, 2017 at 5:00 AM, Michael Niedermayer  > > wrote:
> >
> > > Hi
> > >
> > > On Wed, Jul 19, 2017 at 07:30:01PM -0700, Dale Curtis wrote:
> > > > Thanks will take a look. Is this test not part of fate? make fate passed
> > >
> > > no, we should have tests for all (fixed) tickets in fate ideally
> > > but in reality most tickets lack a corresponding test
> > > I tried both in outreachy and as well in GSoC to improve this situation
> > > with student projects but both only moved this forward by a small
> > > step. Its a large amount of work to create robust, portable and
> > > practical tests for "all" tickets and everything else.
> > > The way out to get this actually done would be to pay a developer to
> > > create tests for "all" tickets in fate. I belive carl would be the
> > > ideal one to do this work as he has since a very long time always tested
> > > and kept track of all our tickets.
> > > I did suggest a while ago to someone at google that funding such
> > > project would make sense but IIRC i never heared back.
> > > if some company would fund something like this, i belive this would be
> > > very usefull in the long run for code quality
> > >
> >
> > I think it'd be pretty hard to get someone to go through and create tests
> > for every issue ever seen. Even Chromium has trouble with this, but making
> 
> yes, unless theres someone who enjoys doing this kind of work.
> 
> 
> > it part of the culture helps. I.e. reviewers should ask for every change to
> > include a test.
> 
> yes though theres already
> 1.8 patch submission checklist
> ...
> 26. Consider adding a regression test for your code.
> on http://ffmpeg.org/developer.html 
> 
> 
> > I'm happy to add one to fate for this change. Or can do so
> > in a followup patch if you prefer.
> 
> please do (any variant is fine)
> 
> thx
> 
> >
> > Does anyone have comments on this change specifically? We've already rolled
> > this into Chrome and it's working fine and passing all regression tests.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org 
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> > 
> 
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
> 
> ___
> 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] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

2017-08-04 Thread Michael Niedermayer

On Mon, Jul 31, 2017 at 02:29:29PM -0700, Dale Curtis wrote:
> Here's an updated patch with a fate test attached. You'll need to add
> http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to the
> fate-suite/mov for this test. This is licensed under creative commons
> attribution, so it should be fine for tests:
> https://peach.blender.org/about/ I tried to use the existing samples, but
> you need a clip long enough that the entire index isn't generated from the
> start.

so theres no easy way to create a smaller file then 64mb ?

iam trying to keep the size of the fate samples small,
imagening 64mb * thousands of tests and each fate client needs a copy
of this...


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

2017-08-04 Thread Dale Curtis

Any comments here? +rodger who wrote the original sidx processing for
review.

- dale

On Mon, Jul 31, 2017 at 3:01 PM, Dale Curtis 
wrote:

> Whoops, that patch accidentally reverted to an earlier version. Here's the
> fixed one that works with the mpg sample mentioned above.
>
> - dale
>
> On Mon, Jul 31, 2017 at 2:29 PM, Dale Curtis 
> wrote:
>
>> Here's an updated patch with a fate test attached. You'll need to add
>> http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to the
>> fate-suite/mov for this test. This is licensed under creative commons
>> attribution, so it should be fine for tests: https://peach.blender.o
>> rg/about/ I tried to use the existing samples, but you need a clip long
>> enough that the entire index isn't generated from the start.
>>
>> - dale
>>
>> On Tue, Jul 25, 2017 at 1:03 PM, Michael Niedermayer <
>> mich...@niedermayer.cc> wrote:
>>
>>> On Mon, Jul 24, 2017 at 02:32:41PM -0700, Dale Curtis wrote:
>>> > On Thu, Jul 20, 2017 at 5:00 AM, Michael Niedermayer
>>> >> > > wrote:
>>> >
>>> > > Hi
>>> > >
>>> > > On Wed, Jul 19, 2017 at 07:30:01PM -0700, Dale Curtis wrote:
>>> > > > Thanks will take a look. Is this test not part of fate? make fate
>>> passed
>>> > >
>>> > > no, we should have tests for all (fixed) tickets in fate ideally
>>> > > but in reality most tickets lack a corresponding test
>>> > > I tried both in outreachy and as well in GSoC to improve this
>>> situation
>>> > > with student projects but both only moved this forward by a small
>>> > > step. Its a large amount of work to create robust, portable and
>>> > > practical tests for "all" tickets and everything else.
>>> > > The way out to get this actually done would be to pay a developer to
>>> > > create tests for "all" tickets in fate. I belive carl would be the
>>> > > ideal one to do this work as he has since a very long time always
>>> tested
>>> > > and kept track of all our tickets.
>>> > > I did suggest a while ago to someone at google that funding such
>>> > > project would make sense but IIRC i never heared back.
>>> > > if some company would fund something like this, i belive this would
>>> be
>>> > > very usefull in the long run for code quality
>>> > >
>>> >
>>> > I think it'd be pretty hard to get someone to go through and create
>>> tests
>>> > for every issue ever seen. Even Chromium has trouble with this, but
>>> making
>>>
>>> yes, unless theres someone who enjoys doing this kind of work.
>>>
>>>
>>> > it part of the culture helps. I.e. reviewers should ask for every
>>> change to
>>> > include a test.
>>>
>>> yes though theres already
>>> 1.8 patch submission checklist
>>> ...
>>> 26. Consider adding a regression test for your code.
>>> on http://ffmpeg.org/developer.html
>>>
>>>
>>> > I'm happy to add one to fate for this change. Or can do so
>>> > in a followup patch if you prefer.
>>>
>>> please do (any variant is fine)
>>>
>>> thx
>>>
>>> >
>>> > Does anyone have comments on this change specifically? We've already
>>> rolled
>>> > this into Chrome and it's working fine and passing all regression
>>> tests.
>>> > ___
>>> > ffmpeg-devel mailing list
>>> > ffmpeg-devel@ffmpeg.org
>>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> --
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> Breaking DRM is a little like attempting to break through a door even
>>> though the window is wide open and the only thing in the house is a bunch
>>> of things you dont want and which you would get tomorrow for free anyway
>>>
>>> ___
>>> 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] [mov] Bail when invalid sample data is present.

2017-08-04 Thread Dale Curtis

Sample sent privately. I didn't find any non-fuzzer samples that no longer
demux in our Chrome test corpus or in fate.

- dale

On Wed, Aug 2, 2017 at 1:43 PM, Carl Eugen Hoyos  wrote:

> 2017-07-31 23:40 GMT+02:00 Dale Curtis :
> > [mov] Bail when invalid sample data is present.
>
> Could you provide such a sample?
>
> Could the patch stop demuxing samples that are
> supported so far?
>
> Carl Eugen
> ___
> 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 2/2] Inserted check on codeblock size, added limits on codeblock size Modified according to Niedermayer suggestions

2017-08-04 Thread Michael Niedermayer

On Fri, Aug 04, 2017 at 04:21:35PM +0200, france...@bltitalia.com wrote:
> From: Francesco Cuzzocrea 
> 
> ---
>  libavcodec/j2kenc.c | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)

patches should be against git master not on top of the previous patches
revission


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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-08-04 Thread Ivan Kalvachev

On 8/4/17, Henrik Gramner  wrote:
> On Thu, Aug 3, 2017 at 11:36 PM, Ivan Kalvachev 
> wrote:
>>> 1234_1234_1234_123
>>> VBROADCASTSS ym1, xm1
>>> BLENDVPS  m1, m2, m3
>>>
>>> is the most commonly used alignment.
>>
>> I see that a lot of .asm files use different alignments.
>> I'll try to pick something similar that I find good looking.
>>
>> I also see that different function/macro can have
>> different position for the first comma.
>> This could be quite useful, to visually separate
>> the macros.
>
> Things like indentation can be a bit inconsistent at times, yes. Cody
> by different authors written over the span of many year etc.
>
> It's normal to diverge from "standard alignment" in cases when macro
> names (or memory addresses) are fairly long. Otherwise the amount of
> whitespace between instructions and operands would easily get too
> large to be practical.

I tried different things. The one space after comma indeed looks best.
I used 2 spaces after instruction.

>>> Now that I think about it I believe that part wasn't merged because
>>> smartalign is broken on some older nasm versions (which is another
>>> reason for avoiding things like this in individual files) and FFmpeg
>>> doesn't enforce any specific version requirements. I guess it could be
>>> worked around with some version checking ifdeffery if we know which
>>> versions are affected.
>>
>> I don't see anything relevant in here:
>> http://repo.or.cz/nasm.git/history/HEAD:/macros/smartalign.mac
>> I also didn't notice anything similar in the changelog.
> http://repo.or.cz/nasm.git/commit/f29123b936b1751c6d72dad86b05eb293cca5c6c
> https://bugzilla.nasm.us/show_bug.cgi?id=3392319

This would break generation of dependencies?
I think that FFmpeg uses combined mode with nasm,
so it should not call preprocessor only mode,
unless DBG=1 is used.

I'll investigate this further.
(revert the nasm fix, try building ffmpeg dependencies ...)

>> I had it mixed before, but I changed it to be consistent.
>> Some new avx instruction are not overloaded or
>> available without their "v-" prefix.
>> e.g. x86util uses vpbroadcastw in SPLATW.
>
> Every instruction that has both a legacy encoding and a VEX-encoding
> will be automatically converted to VEX in AVX functions when written
> without the v-prefix. There is no legacy encoding for newer
> instructions so there's no reason for x86inc to overload those.

That's great, but it doesn't address the original problem.
Do you insist on removing the "v-" prefix from AVX only instructions?

You said that this is purely cosmetic and
I think that it would make compilation a bit slower,
because of unnecessary macro expansions. ;)

>> Isn't one of the selling points for x86inc that
>> it would warn if unsupported instructions are used?
>
> Not really, no. It's done in a small subset of cases as a part of the
> aforementioned auto legacy/VEX conversion because it was trivial to
> add that functionality, but correctly tracking every single x86
> instruction in existence would be a whole different thing.
>
> Some instructions requires different instruction sets not just
> depending on the vector width but the operand types as well (for
> example, pextrw from mm to gpr requires mmx2, from xmm to gpr requires
> sse2, from xmm to memory requires sse4.1) and there's no generic way
> to handle every special corner case which would make things fairly
> complex. I'm guessing doing so would also cause a significant
> reduction in compilation speed which I'm sure some people would
> dislike.

There is already check for register size and integer operations,
because SSE1 does not have 128bit xmm integer operations.
It should be just few lines of code to add the same check for
AVX1 and 256bit ymm integer operations.
(I'm not confident enough to mess with that code, yet.)

As for the immediate task:
The "error" message stays.

Maybe I should also add "use PBROADCASTD instead" to it?


>>> Add your improvements to the existing x86util macro (can be done in
>>> the same patch) and then use that.
>>
>> FFmpeg guidelines request that it is a separate patch in separate mail.
>
> Doesn't really seem to be followed historically by looking at the git
> history, but doing things by the book is never wrong so making it a
> separate commit might be the correct choice.

Will do.

>> Just renaming it is not enough, because SPLATD
>> works differently (it can broadcast second, third or forth element too)
>> and it is already used in existing code.
>> Maybe PBROADCASTD macro could use SPLATD internally.
>
> SPLATD is hardcoded to broadcast the lowest element.
>
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/x86/x86util.asm;h=cc7d272cada6d73e5ddc42ae359491086a206743;hb=HEAD#l782
>
> Ideally the SSE branch of SPLATD should be also removed and any float
> code using it should be changed to use the BROADCASTSS macro instead,
> but that's perhaps going a bit off-topic.

[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

2017-08-04 Thread Sasi Inguva

According to 
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
 and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3

Signed-off-by: Sasi Inguva 
---
 libavformat/movenc.c| 70 +
 tests/ref/fate/adtstoasc_ticket3715 |  4 +--
 tests/ref/fate/copy-psp |  4 +--
 tests/ref/fate/movenc   | 12 +++
 4 files changed, 49 insertions(+), 41 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 0e5b45d150..10b959ad02 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2208,39 +2208,47 @@ static int mov_preroll_write_stbl_atoms(AVIOContext 
*pb, MOVTrack *track)
 (AVRational){1, 1000},
 (AVRational){1, 48000});
 
-if (track->entry) {
-sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
-if (!sgpd_entries)
-return AVERROR(ENOMEM);
-}
+if (!track->entry)
+return 0;
 
-av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS);
+sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
+if (!sgpd_entries)
+return AVERROR(ENOMEM);
 
-for (i = 0; i < track->entry; i++) {
-int roll_samples_remaining = roll_samples;
-int distance = 0;
-for (j = i - 1; j >= 0; j--) {
-roll_samples_remaining -= get_cluster_duration(track, j);
-distance++;
-if (roll_samples_remaining <= 0)
-break;
-}
-/* We don't have enough preceeding samples to compute a valid
-   roll_distance here, so this sample can't be independently
-   decoded. */
-if (roll_samples_remaining > 0)
-distance = 0;
-/* Verify distance is a minimum of 2 (60ms) packets and a maximum of
-   32 (2.5ms) packets. */
-av_assert0(distance == 0 || (distance >= 2 && distance <= 32));
-if (i && distance == sgpd_entries[entries].roll_distance) {
-sgpd_entries[entries].count++;
-} else {
-entries++;
-sgpd_entries[entries].count = 1;
-sgpd_entries[entries].roll_distance = distance;
-sgpd_entries[entries].group_description_index = distance ? ++group 
: 0;
+av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS || 
track->par->codec_id == AV_CODEC_ID_AAC);
+
+if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+for (i = 0; i < track->entry; i++) {
+int roll_samples_remaining = roll_samples;
+int distance = 0;
+for (j = i - 1; j >= 0; j--) {
+roll_samples_remaining -= get_cluster_duration(track, j);
+distance++;
+if (roll_samples_remaining <= 0)
+break;
+}
+/* We don't have enough preceeding samples to compute a valid
+   roll_distance here, so this sample can't be independently
+   decoded. */
+if (roll_samples_remaining > 0)
+distance = 0;
+/* Verify distance is a minimum of 2 (60ms) packets and a maximum 
of
+   32 (2.5ms) packets. */
+av_assert0(distance == 0 || (distance >= 2 && distance <= 32));
+if (i && distance == sgpd_entries[entries].roll_distance) {
+sgpd_entries[entries].count++;
+} else {
+entries++;
+sgpd_entries[entries].count = 1;
+sgpd_entries[entries].roll_distance = distance;
+sgpd_entries[entries].group_description_index = distance ? 
++group : 0;
+}
 }
+} else {
+entries++;
+sgpd_entries[entries].count = track->sample_count;
+sgpd_entries[entries].roll_distance = 1;
+sgpd_entries[entries].group_description_index = ++group;
 }
 entries++;
 
@@ -2304,7 +2312,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 if (track->cenc.aes_ctr) {
 ff_mov_cenc_write_stbl_atoms(>cenc, pb);
 }
-if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+if (track->par->codec_id == AV_CODEC_ID_OPUS || track->par->codec_id == 
AV_CODEC_ID_AAC) {
 mov_preroll_write_stbl_atoms(pb, track);
 }
 return update_size(pb, pos);
diff --git a/tests/ref/fate/adtstoasc_ticket3715 
b/tests/ref/fate/adtstoasc_ticket3715
index 949b565c2f..96795a2ca3 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -1,5 +1,5 @@
-ef8ce3cbd1d86113e7c991a816086068 *tests/data/fate/adtstoasc_ticket3715.mov
-33270 tests/data/fate/adtstoasc_ticket3715.mov
+0221e04333e6ac432fa42960502f0d5a *tests/data/fate/adtstoasc_ticket3715.mov
+33324 tests/data/fate/adtstoasc_ticket3715.mov
 #extradata 0:2, 0x00340022
 #tb 0: 1/44100
 #media_type 0: audio
diff --git

[FFmpeg-devel] [PATCH] avfilter/vf_premultiply: add inplace mode

2017-08-04 Thread Paul B Mahol

Hi,

patch attached.


0001-avfilter-vf_premultiply-add-inplace-mode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-08-04 Thread Henrik Gramner

On Thu, Aug 3, 2017 at 11:36 PM, Ivan Kalvachev  wrote:
>> 1234_1234_1234_123
>> VBROADCASTSS ym1, xm1
>> BLENDVPS  m1, m2, m3
>>
>> is the most commonly used alignment.
>
> I see that a lot of .asm files use different alignments.
> I'll try to pick something similar that I find good looking.
>
> I also see that different function/macro can have
> different position for the first comma.
> This could be quite useful, to visually separate
> the macros.

Things like indentation can be a bit inconsistent at times, yes. Cody
by different authors written over the span of many year etc.

It's normal to diverge from "standard alignment" in cases when macro
names (or memory addresses) are fairly long. Otherwise the amount of
whitespace between instructions and operands would easily get too
large to be practical.

>> Now that I think about it I believe that part wasn't merged because
>> smartalign is broken on some older nasm versions (which is another
>> reason for avoiding things like this in individual files) and FFmpeg
>> doesn't enforce any specific version requirements. I guess it could be
>> worked around with some version checking ifdeffery if we know which
>> versions are affected.
>
> I don't see anything relevant in here:
> http://repo.or.cz/nasm.git/history/HEAD:/macros/smartalign.mac
> I also didn't notice anything similar in the changelog.

http://repo.or.cz/nasm.git/commit/f29123b936b1751c6d72dad86b05eb293cca5c6c
https://bugzilla.nasm.us/show_bug.cgi?id=3392319

> I had it mixed before, but I changed it to be consistent.
> Some new avx instruction are not overloaded or
> available without their "v-" prefix.
> e.g. x86util uses vpbroadcastw in SPLATW.

Every instruction that has both a legacy encoding and a VEX-encoding
will be automatically converted to VEX in AVX functions when written
without the v-prefix. There is no legacy encoding for newer
instructions so there's no reason for x86inc to overload those.

> Isn't one of the selling points for x86inc that
> it would warn if unsupported instructions are used?

Not really, no. It's done in a small subset of cases as a part of the
aforementioned auto legacy/VEX conversion because it was trivial to
add that functionality, but correctly tracking every single x86
instruction in existence would be a whole different thing.

Some instructions requires different instruction sets not just
depending on the vector width but the operand types as well (for
example, pextrw from mm to gpr requires mmx2, from xmm to gpr requires
sse2, from xmm to memory requires sse4.1) and there's no generic way
to handle every special corner case which would make things fairly
complex. I'm guessing doing so would also cause a significant
reduction in compilation speed which I'm sure some people would
dislike.

>> Add your improvements to the existing x86util macro (can be done in
>> the same patch) and then use that.
>
> FFmpeg guidelines request that it is a separate patch in separate mail.

Doesn't really seem to be followed historically by looking at the git
history, but doing things by the book is never wrong so making it a
separate commit might be the correct choice.

> Just renaming it is not enough, because SPLATD
> works differently (it can broadcast second, third or forth element too)
> and it is already used in existing code.
> Maybe PBROADCASTD macro could use SPLATD internally.

SPLATD is hardcoded to broadcast the lowest element.

http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/x86/x86util.asm;h=cc7d272cada6d73e5ddc42ae359491086a206743;hb=HEAD#l782

Ideally the SSE branch of SPLATD should be also removed and any float
code using it should be changed to use the BROADCASTSS macro instead,
but that's perhaps going a bit off-topic.

> "cmpps" is not scalar, but it is handled by x86inc macros and converted
> to "vcmpps", so no SSE penalties are possible with it.
>
> Read again what I wrote previously.

'cmpps' is packed, not scalar (hence the 'p' instead of 's') so it
obviously shouldn't be used in scalar code. I believe you misread my
initial comment which said to use 'cmpss' instead of 'cmpless'.

>> One could of course argue whether or not x86inc should deal with
>> psuedo-instructions but right now it doesn't so it will cause AVX
>> state transitions if INIT_YMM is used since it wont be VEX-encoded.
>
> Let's say that using a number for selecting comparison mode
> is NOT developer friendly.

I did indeed say one can argue about it. I can see if there's any
clean way of handling it that doesn't require a hundred lines of code.

>> Doing PIC-mangling optimally will in many cases be context-dependent
>> which is probably why it doesn't already exist. For example if you
>> need to do multiple complex PIC-loads you should do a single lea and
>> reuse it which is harder to convey as a generic macro.
>
> I think that this macro can help with that too:
> e.g.
> SET_PIC_BASE lea,  r5, const_1
> movapsm1,

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

2017-08-04 Thread Derek Buitenhuis

On 8/4/2017 8:50 PM, Sasi Inguva wrote:
> [...]

Thanks for the reference, please add the section numbers alongside the QTFF doc 
in the
commit message.

> This patch sets the sgpd and sbgp atoms irrespective of whether it's
> fragmented or not. So the byte addresses for some atoms will change for all
> MP4 files .

Sure. I just wanted to confirm that is all that's changing in those tests.

- Derek

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

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

2017-08-04 Thread Sasi Inguva

From ISO-IEC-14496-12
*10 Sample Groups*
*10.1 Random Access Recovery Points*
*10.1.1.1*
*Definition*
*class AudioRollRecoveryEntry() extends AudioSampleGroupEntry (’roll’)*
*{*
*signed int(16) roll_distance;*
*}*


*An AudioRollRecoveryEntry documents the pre‐roll distance required in
audio streams in whichevery sample can be independently decoded, but the
decoder output is only assured to be correct afterpre‐rolling by the
indicated number of samples.*








*10.1.1.3roll_distance is a signed integer that gives the number of samples
that must be decoded inorder for a sample to be decoded correctly. A
positive value indicates the number of samplesafter the sample that is a
group member that must be decoded such that at the last of theserecovery is
complete, i.e. the last sample is correct. A negative value indicates the
number ofsamples before the sample that is a group member that must be
decoded in order for recoveryto be complete at the marked sample. The value
zero must not be used; the sync sample tabledocuments random access points
for which no recovery roll is needed.*


This patch sets the sgpd and sbgp atoms irrespective of whether it's
fragmented or not. So the byte addresses for some atoms will change for all
MP4 files .

On Fri, Aug 4, 2017 at 12:11 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 8/4/2017 7:46 PM, Sasi Inguva wrote:
> > According to https://developer.apple.com/library/content/documentation/
> QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> >
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/movenc.c| 70 +-
> ---
> >  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
> >  tests/ref/fate/copy-psp |  4 +--
> >  tests/ref/fate/movenc   | 12 +++
> >  4 files changed, 49 insertions(+), 41 deletions(-)
>
> Is there a reference for ISOBMFF too? Because this changes mp4 output as
> well mov.
>
> > diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
> > index 09e603aeb7..47bcf9d515 100644
> > --- a/tests/ref/fate/movenc
> > +++ b/tests/ref/fate/movenc
> > @@ -1,18 +1,18 @@
> >  write_data len 36, time nopts, type header atom ftyp
> > -write_data len 2335, time nopts, type header atom -
> > +write_data len 2389, time nopts, type header atom -
> >  write_data len 788, time 100, type sync atom moof
> >  write_data len 110, time nopts, type trailer atom -
> > -214242e9c7c93171d2f47f5b47776559 3269 non-empty-moov
> > +17a37691eba8b858cf15e60aa9a7dbf7 3323 non-empty-moov
> >  write_data len 36, time nopts, type header atom ftyp
> > -write_data len 2667, time nopts, type header atom -
> > +write_data len 2721, time nopts, type header atom -
> >  write_data len 908, time 97, type sync atom moof
> >  write_data len 110, time nopts, type trailer atom -
> > -44467d568a3cc38d414fd8ed4b2a968f 3721 non-empty-moov-elst
> > +0026ffe059c06c592021f972bf2c5e79 3775 non-empty-moov-elst
> >  write_data len 36, time nopts, type header atom ftyp
> > -write_data len 2575, time nopts, type header atom -
> > +write_data len 2629, time nopts, type header atom -
> >  write_data len 908, time 100, type sync atom moof
> >  write_data len 110, time nopts, type trailer atom -
> > -de22b98a3885f9b4b83cdd48ff46aeb9 3629 non-empty-moov-no-elst
> > +c184e168ac1e5bb3d9c70e580ab6179c 3683 non-empty-moov-no-elst
> >  write_data len 20, time nopts, type header atom ftyp
> >  write_data len 1171, time nopts, type header atom -
> >  write_data len 728, time 0, type sync atom moof
> >
>
> Can you confirm what exactly changes in these fragmented MP4 API tests?
>
> - Derek
> ___
> 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 07/14] lavfi/vf_overlay: use framesync2 options.

2017-08-04 Thread Paul B Mahol

On 8/4/17, Paul B Mahol  wrote:
> On 8/2/17, Nicolas George  wrote:
>> Le quintidi 15 thermidor, an CCXXV, Michael Niedermayer a écrit :
>>> removing these elements causes command lines using them to fail
>>> for example:
>>>
>>> ./ffmpeg -i matrixbench_mpeg2.mpg -i lena.pnm -filter_complex
>>> 'overlay=10:main_h-overlay_h-10:pass' -qscale 2 -t 1 file.avi
>>
>> Oh, the shorthand notation. The order of the non-essential options has
>> changed in the past, including recently, and does not match the
>> documentation, I have always considered it undocumented and as such
>> unspecified.
>>
>> Moreover, with a separate object like that, keeping the order will be
>> impossible: options added to the filter in the future will always come
>> before the options in the framesync object.
>>
>> Therefore, I consider this minor break of compatibility acceptable. I
>> should have mentioned it, but I forgot, sorry.
>>
>> What do other think?
>>
>
> We should move forward, no need to keep shorthand compatibility for
> those options.
>

Also what about to porting one of simple filter(just filter_frame
call) to activate API,
i can not do it myself unless someone show me how.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

2017-08-04 Thread Derek Buitenhuis

On 8/4/2017 7:46 PM, Sasi Inguva wrote:
> According to 
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> 
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/movenc.c| 70 
> +
>  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
>  tests/ref/fate/copy-psp |  4 +--
>  tests/ref/fate/movenc   | 12 +++
>  4 files changed, 49 insertions(+), 41 deletions(-)

Is there a reference for ISOBMFF too? Because this changes mp4 output as well 
mov.

> diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
> index 09e603aeb7..47bcf9d515 100644
> --- a/tests/ref/fate/movenc
> +++ b/tests/ref/fate/movenc
> @@ -1,18 +1,18 @@
>  write_data len 36, time nopts, type header atom ftyp
> -write_data len 2335, time nopts, type header atom -
> +write_data len 2389, time nopts, type header atom -
>  write_data len 788, time 100, type sync atom moof
>  write_data len 110, time nopts, type trailer atom -
> -214242e9c7c93171d2f47f5b47776559 3269 non-empty-moov
> +17a37691eba8b858cf15e60aa9a7dbf7 3323 non-empty-moov
>  write_data len 36, time nopts, type header atom ftyp
> -write_data len 2667, time nopts, type header atom -
> +write_data len 2721, time nopts, type header atom -
>  write_data len 908, time 97, type sync atom moof
>  write_data len 110, time nopts, type trailer atom -
> -44467d568a3cc38d414fd8ed4b2a968f 3721 non-empty-moov-elst
> +0026ffe059c06c592021f972bf2c5e79 3775 non-empty-moov-elst
>  write_data len 36, time nopts, type header atom ftyp
> -write_data len 2575, time nopts, type header atom -
> +write_data len 2629, time nopts, type header atom -
>  write_data len 908, time 100, type sync atom moof
>  write_data len 110, time nopts, type trailer atom -
> -de22b98a3885f9b4b83cdd48ff46aeb9 3629 non-empty-moov-no-elst
> +c184e168ac1e5bb3d9c70e580ab6179c 3683 non-empty-moov-no-elst
>  write_data len 20, time nopts, type header atom ftyp
>  write_data len 1171, time nopts, type header atom -
>  write_data len 728, time 0, type sync atom moof
> 

Can you confirm what exactly changes in these fragmented MP4 API tests?

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

[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

2017-08-04 Thread Sasi Inguva

According to 
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

Signed-off-by: Sasi Inguva 
---
 libavformat/movenc.c| 70 +
 tests/ref/fate/adtstoasc_ticket3715 |  4 +--
 tests/ref/fate/copy-psp |  4 +--
 tests/ref/fate/movenc   | 12 +++
 4 files changed, 49 insertions(+), 41 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 0e5b45d150..10b959ad02 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2208,39 +2208,47 @@ static int mov_preroll_write_stbl_atoms(AVIOContext 
*pb, MOVTrack *track)
 (AVRational){1, 1000},
 (AVRational){1, 48000});
 
-if (track->entry) {
-sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
-if (!sgpd_entries)
-return AVERROR(ENOMEM);
-}
+if (!track->entry)
+return 0;
 
-av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS);
+sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
+if (!sgpd_entries)
+return AVERROR(ENOMEM);
 
-for (i = 0; i < track->entry; i++) {
-int roll_samples_remaining = roll_samples;
-int distance = 0;
-for (j = i - 1; j >= 0; j--) {
-roll_samples_remaining -= get_cluster_duration(track, j);
-distance++;
-if (roll_samples_remaining <= 0)
-break;
-}
-/* We don't have enough preceeding samples to compute a valid
-   roll_distance here, so this sample can't be independently
-   decoded. */
-if (roll_samples_remaining > 0)
-distance = 0;
-/* Verify distance is a minimum of 2 (60ms) packets and a maximum of
-   32 (2.5ms) packets. */
-av_assert0(distance == 0 || (distance >= 2 && distance <= 32));
-if (i && distance == sgpd_entries[entries].roll_distance) {
-sgpd_entries[entries].count++;
-} else {
-entries++;
-sgpd_entries[entries].count = 1;
-sgpd_entries[entries].roll_distance = distance;
-sgpd_entries[entries].group_description_index = distance ? ++group 
: 0;
+av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS || 
track->par->codec_id == AV_CODEC_ID_AAC);
+
+if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+for (i = 0; i < track->entry; i++) {
+int roll_samples_remaining = roll_samples;
+int distance = 0;
+for (j = i - 1; j >= 0; j--) {
+roll_samples_remaining -= get_cluster_duration(track, j);
+distance++;
+if (roll_samples_remaining <= 0)
+break;
+}
+/* We don't have enough preceeding samples to compute a valid
+   roll_distance here, so this sample can't be independently
+   decoded. */
+if (roll_samples_remaining > 0)
+distance = 0;
+/* Verify distance is a minimum of 2 (60ms) packets and a maximum 
of
+   32 (2.5ms) packets. */
+av_assert0(distance == 0 || (distance >= 2 && distance <= 32));
+if (i && distance == sgpd_entries[entries].roll_distance) {
+sgpd_entries[entries].count++;
+} else {
+entries++;
+sgpd_entries[entries].count = 1;
+sgpd_entries[entries].roll_distance = distance;
+sgpd_entries[entries].group_description_index = distance ? 
++group : 0;
+}
 }
+} else {
+entries++;
+sgpd_entries[entries].count = track->sample_count;
+sgpd_entries[entries].roll_distance = 1;
+sgpd_entries[entries].group_description_index = ++group;
 }
 entries++;
 
@@ -2304,7 +2312,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 if (track->cenc.aes_ctr) {
 ff_mov_cenc_write_stbl_atoms(>cenc, pb);
 }
-if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+if (track->par->codec_id == AV_CODEC_ID_OPUS || track->par->codec_id == 
AV_CODEC_ID_AAC) {
 mov_preroll_write_stbl_atoms(pb, track);
 }
 return update_size(pb, pos);
diff --git a/tests/ref/fate/adtstoasc_ticket3715 
b/tests/ref/fate/adtstoasc_ticket3715
index 949b565c2f..96795a2ca3 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -1,5 +1,5 @@
-ef8ce3cbd1d86113e7c991a816086068 *tests/data/fate/adtstoasc_ticket3715.mov
-33270 tests/data/fate/adtstoasc_ticket3715.mov
+0221e04333e6ac432fa42960502f0d5a *tests/data/fate/adtstoasc_ticket3715.mov
+33324 tests/data/fate/adtstoasc_ticket3715.mov
 #extradata 0:2, 0x00340022
 #tb 0: 1/44100
 #media_type 0: audio
diff --git a/tests/ref/fate/copy-psp b/tests/ref/fate/copy-psp
index

Re: [FFmpeg-devel] [PATCH 07/14] lavfi/vf_overlay: use framesync2 options.

2017-08-04 Thread Paul B Mahol

On 8/2/17, Nicolas George  wrote:
> Le quintidi 15 thermidor, an CCXXV, Michael Niedermayer a écrit :
>> removing these elements causes command lines using them to fail
>> for example:
>>
>> ./ffmpeg -i matrixbench_mpeg2.mpg -i lena.pnm -filter_complex
>> 'overlay=10:main_h-overlay_h-10:pass' -qscale 2 -t 1 file.avi
>
> Oh, the shorthand notation. The order of the non-essential options has
> changed in the past, including recently, and does not match the
> documentation, I have always considered it undocumented and as such
> unspecified.
>
> Moreover, with a separate object like that, keeping the order will be
> impossible: options added to the filter in the future will always come
> before the options in the framesync object.
>
> Therefore, I consider this minor break of compatibility acceptable. I
> should have mentioned it, but I forgot, sorry.
>
> What do other think?
>

We should move forward, no need to keep shorthand compatibility for
those options.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] EVS

2017-08-04 Thread Bob Kirnum

Before I attempt to come up with and attempt to submit a patch only to be
rejected and subsequently ignored, is there any interest in adding support
for EVS?  Specifically, EVS files and EVS coded audio in 3GP containers.
This would not include the EVS codec as that costs $$.

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

Re: [FFmpeg-devel] [WIP] libcodec2 wrapper + de/muxer in FFmpeg

2017-08-04 Thread Tomas Härdin

On Thu, 2017-08-03 at 22:24 +0200, Reimar Döffinger wrote:
> On Thu, Aug 03, 2017 at 12:40:04AM +0200, Tomas Härdin wrote:
> 
> > 
> > +//statically assert the size of avpriv_codec2_header
> > +//putting it here because all codec2 things depend on
> > codec2utils
> > +switch(0) {
> > +case 0:
> > +case sizeof(avpriv_codec2_header) == 7: //if false then the
> > compiler will complain
> > +break;
> > +}
> I was pretty sure we had some kind of static assert already,
> based on negative array size in a struct (so it can work outside
> functions)...
> But doesn't matter due to next comments...
> 
> > 
> > +*((avpriv_codec2_header*)avctx->extradata) =
> > avpriv_codec2_make_header(mode);
> I am pretty sure this is a strict aliasing violation.
> Even ignoring the ugliness and performance issues with
> returning structs and assigning them causing lots of
> pointless copies.
> Also, since all struct elements are bytes, it isn't
> really any more readable than just assigning to the
> byte array, with the names you not have in the struct
> in comments instead.
> And that is without going into all the ways someone could
> change that struct (e.g. in case of new features) that
> would completely break this kind of code due to endianness,
> alignment, ...
> Even just supporting both the current and a potential future version
> that changes any of the fields would be hard with this kind of code.

Aliasing violation is a good point, but it also doesn't matter here.
extradata isn't used anywhere else in the function.

The struct is mostly a handy way of getting names for all the bytes, so
a enum with offsets could work just as well:

enum avpriv_codec2_header_bytes {
  AVPRIV_CODEC2_MAGIC0 = 0,
  AVPRIV_CODEC2_MAGIC1,
  AVPRIV_CODEC2_MAGIC2,
  AVPRIV_CODEC2_VERSION_MAJOR,
  ...
};

Endianness is also not an issue since it's all bytes. But: one nice way
to do this is perhaps a pair of functions for parsing / creating the
struct out of the byte array and vice versa.

> > 
> > +if (avctx->extradata_size != sizeof(avpriv_codec2_header))
> > {
> > +av_log(avctx, AV_LOG_ERROR, "must have exactly %zu
> > bytes of extradata (got %i)\n",
> > +   sizeof(avpriv_codec2_header), avctx-
> > >extradata_size);
> > +}
> I would think at least if it is less you wouldn't want to just
> continue? Even if extradata is required to be padded (is it?),
> blindly selecting 0 as mode doesn't seem very likely to be right.

This has been fixed in the updated patchset

> > 
> > +output = (int16_t *)frame->data[0];
> The codec2 documentation seems pretty non-existant, so I
> assume you are right that this is always in native endianness.
> However from what I can see codec2 actually uses the "short" type,
> not int16_t.
> While it shouldn't make a difference in practice, if casting anyway
> I'd suggest using the type matching the API.

Some kind of static assert for sizeof(short) == sizeof(int16_t) would
be nicest I think. If someone's on a platform with non-16-bit shorts
and they want --enable-libcodec2 to work then they can probably write
and submit a patch.

> > 
> > +if (nframes > 0) {
> > +*got_frame_ptr = 1;
> > +}
> Not just *got_frame_ptr = nframes > 0; ?

Sure.

> > 
> > +int16_t *samples = (int16_t *)frame->data[0];
> You are casting the const away.
> Did they just forget to add the const to the API?
> If so, can you suggest it to be added?
> Otherwise if it's intentional you need to make a copy.

No const in the API, but adding it is of course easy enough. That won't
get into Debian for some time however, so users would have to build
their own libcodec2.

Version #defines in  could help with this, currently
there are none so that's one way to detect the non-const API. I'll have
to run that past the other guys.

> > +int ret;
> > +
> > +if ((ret = ff_alloc_packet2(avctx, avpkt, avctx->block_align,
> > 0)) < 0) {
> If you merge the declaration and assignment it you would get
> for free not having the assignment inside the if, which I
> still think is just horrible style. :)

Fair enough. I use this style in a few places when stacking a bunch of
inits and checks for ENOMEM and such. doc/developer.html doesn't seem
to have a preference, and I've seen the style used elsewhere in FFmpeg.
I went with splitting the assignments and testing in all the ifs in the
updated patchset

> > 
> > +//file starts wih 0xC0DEC2
> > +if (p->buf[0] == 0xC0 && p->buf[1] == 0xDE && p->buf[2] ==
> > 0xC2) {
> > +return AVPROBE_SCORE_MAX;
> > +}
> As mentioned, try to find a few more bits and reduce the score.
> If only these 3 bytes match, I would suggest a rather low score.
> (I doubt there are enough useful bits in this header to allow
> reaching MAX score, it's a shame they didn't invest a byte or
> 2 more, especially considering that while 0xC0DEC2 might look
> clever it doesn't exactly get maximum entropy out of those 3 bytes).

Re: [FFmpeg-devel] [PATCH] JPEG2000 encoding with variable codeblock size

2017-08-04 Thread Aaron Boxer

On Fri, Aug 4, 2017 at 12:23 PM, Francesco, Cuzzocrea <
france...@bltitalia.com> wrote:

> Sorry. I intend 32x128



OK, that sounds better :)




>
>
> On 04/08/2017 10.21, Francesco, Cuzzocrea wrote:
>
>> The standard ISO/IEC FCD15444-1 specify limits for the exponent values
>> and their sum. That is codeblock
>>
>> size xcb and ycb are defined as:
>>
>> xcb = 2^(xvalue+2)  and ycb = 2^(yvalue+2)
>>
>> with values that ranges from a minimum of 2 and a maximum of 10. Moreover
>>
>> the sum should be less or equal to 12 ( xvalue + yvalue <=12). So 64x128
>> are allowed because
>>
>> xvalue = 4 and yvalue = 5.
>>
>>
>>
>> On 03/08/2017 19.24, Aaron Boxer wrote:
>>
>>> On Aug 3, 2017 9:58 AM,  wrote:
>>>
>>> From: Francesco Cuzzocrea 
>>>
>>> Hi to all
>>> I've made some simple changes tha allow encoding with variable codeblock
>>> size.  Default value are the same as previous (16X16) but now setting
>>> them
>>> to 64x128 make generated codestream compatible with Analog Devices ADV212
>>> video codec.
>>>
>>>
>>> Interesting - as far as I  aware, part 1 of standard only allows
>>> codeblock
>>> of max size 4096, so 64x128 would not be legal.
>>>
>>>
>>>
>>> ---
>>>   libavcodec/j2kenc.c | 22 +-
>>>   1 file changed, 13 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
>>> index c8d3861..1bd4fbd 100644
>>> --- a/libavcodec/j2kenc.c
>>> +++ b/libavcodec/j2kenc.c
>>> @@ -1178,17 +1178,21 @@ static int j2kenc_destroy(AVCodecContext *avctx)
>>>   // taken from the libopenjpeg wraper so it matches
>>>
>>>   #define OFFSET(x) offsetof(Jpeg2000EncoderContext, x)
>>> +#define OFFSET1(x) offsetof(Jpeg2000CodingStyle, x)
>>> +
>>> +
>>>   #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>>>   static const AVOption options[] = {
>>> -{ "format","Codec Format",  OFFSET(format),
>>> AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K, CODEC_JP2,   VE,
>>> "format"  },
>>> -{ "j2k",   NULL,0,
>>>   AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0, 0,   VE,
>>> "format"  },
>>> -{ "jp2",   NULL,0,
>>>   AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0, 0,   VE,
>>> "format"  },
>>> -{ "tile_width","Tile Width",OFFSET(tile_width),
>>> AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
>>> -{ "tile_height",   "Tile Height", OFFSET(tile_height),
>>>   AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
>>> -{ "pred",  "DWT Type",  OFFSET(pred),
>>> AV_OPT_TYPE_INT,   { .i64 = 0   }, 0, 1,   VE,
>>> "pred"},
>>> -{ "dwt97int",  NULL,0,
>>>   AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE,
>>> "pred"},
>>> -{ "dwt53", NULL,0,
>>>   AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE,
>>> "pred"},
>>> -
>>> +{ "format",   "Codec Format",   OFFSET(format),
>>> AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K,
>>> CODEC_JP2,   VE, "format"  },
>>> +{ "j2k",   NULL,0,
>>>  AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0,
>>>   0,   VE, "format"  },
>>> +{ "jp2",   NULL,0,
>>>  AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0,
>>>   0,   VE, "format"  },
>>> +{ "tile_width","Tile Width", OFFSET(tile_width),
>>> AV_OPT_TYPE_INT,   { .i64 = 256 }, 1,
>>>   1<<30,   VE, },
>>> +{ "tile_height",   "Tile Height", OFFSET(tile_height),
>>>  AV_OPT_TYPE_INT,   { .i64 = 256 }, 1,
>>>   1<<30,   VE, },
>>> +{ "pred",  "DWT Type",  OFFSET(pred),
>>> AV_OPT_TYPE_INT,   { .i64 = 0   }, 0,
>>>   1,   VE, "pred"},
>>> +{ "dwt97int",  NULL,0,
>>>  AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN,
>>> INT_MAX,   VE, "pred"},
>>> +{ "dwt53", NULL,0,
>>>  AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN,
>>> INT_MAX,   VE, "pred"},
>>> +{ "log2_cblk_width",   "Codeblock Width",
>>>   (OFFSET(codsty)+OFFSET1(log2_cblk_width)), AV_OPT_TYPE_INT,   { .i64 =
>>> 4   }, 1, 1<<30,   VE, },
>>> +{ "log2_cblk_height",  "Codeblock Height",
>>> (OFFSET(codsty)+OFFSET1(log2_cblk_height)),   AV_OPT_TYPE_INT, { .i64 =
>>> 4   }, 1, 1<<30,   VE, },
>>>   { NULL }
>>>   };
>>>
>>> --
>>> 2.1.4
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>>

Re: [FFmpeg-devel] [DISCUSSION] Motion Estimation API/Library

2017-08-04 Thread Alex Giladi

I like the idea -- it will be then possible to link to hardware
acceleration.

I don't think R-D optimization (including taking VLC / CABAC into account)
belongs to the library -- this, as well as figuring out partitions, should
be up to the actual encoder.

On Thu, Aug 3, 2017 at 4:09 PM, Ronald S. Bultje  wrote:

> Hi,
>
> On Thu, Aug 3, 2017 at 5:32 PM, Davinder Singh 
> wrote:
>
> > On Tue, Aug 1, 2017 at 7:40 AM Davinder Singh 
> wrote:
> >
> > > [...]
> > >
> >
> > Keeping where the code lives, aside,
> >
> > main thing is API, so we need to talk about it.
>
>
> You're assuming that we know in advance what the API will have to do. I
> don't think that's the case.
>
> For example, what block sizes does it operate on? me_cc doesn't work for
> 64x64 blocks in HEVC, VP9 (and AV1?).
>
> Or what if we don't use VLC coding, but some arithmetic variation? Like all
> H.264, VP8-9, HEVC (and AV1?). Where perhaps the arithmetic coding can
> depend not just on intra/inter, but also on transform size, chroma/luma,
> etc.
>
> What if qscale is not uniform and allows per-coefficient matrix variations?
> How many sub-types of such variations will exist?
>
> My point is: designing it in advance for everything like this is insane.
> Just copy what is there, and prepare for the API to change _all the time_
> while we're molding it to fit in other problem shapes.
>
> Ronald
> ___
> 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] JPEG2000 encoding with variable codeblock size

2017-08-04 Thread Francesco, Cuzzocrea


Sorry. I intend 32x128


On 04/08/2017 10.21, Francesco, Cuzzocrea wrote:
The standard ISO/IEC FCD15444-1 specify limits for the exponent values 
and their sum. That is codeblock


size xcb and ycb are defined as:

xcb = 2^(xvalue+2)  and ycb = 2^(yvalue+2)

with values that ranges from a minimum of 2 and a maximum of 10. Moreover

the sum should be less or equal to 12 ( xvalue + yvalue <=12). So 
64x128 are allowed because


xvalue = 4 and yvalue = 5.



On 03/08/2017 19.24, Aaron Boxer wrote:

On Aug 3, 2017 9:58 AM,  wrote:

From: Francesco Cuzzocrea 

Hi to all
I've made some simple changes tha allow encoding with variable codeblock
size.  Default value are the same as previous (16X16) but now setting 
them
to 64x128 make generated codestream compatible with Analog Devices 
ADV212

video codec.


Interesting - as far as I  aware, part 1 of standard only allows 
codeblock

of max size 4096, so 64x128 would not be legal.



---
  libavcodec/j2kenc.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index c8d3861..1bd4fbd 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1178,17 +1178,21 @@ static int j2kenc_destroy(AVCodecContext *avctx)
  // taken from the libopenjpeg wraper so it matches

  #define OFFSET(x) offsetof(Jpeg2000EncoderContext, x)
+#define OFFSET1(x) offsetof(Jpeg2000CodingStyle, x)
+
+
  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
  static const AVOption options[] = {
-{ "format","Codec Format",  OFFSET(format),
AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K, CODEC_JP2,   VE,
"format"  },
-{ "j2k",   NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0, 0,   VE,
"format"  },
-{ "jp2",   NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0, 0,   VE,
"format"  },
-{ "tile_width","Tile Width",OFFSET(tile_width),
AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
-{ "tile_height",   "Tile Height", OFFSET(tile_height),
  AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
-{ "pred",  "DWT Type",  OFFSET(pred),
AV_OPT_TYPE_INT,   { .i64 = 0   }, 0, 1,   VE,
"pred"},
-{ "dwt97int",  NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE,
"pred"},
-{ "dwt53", NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE,
"pred"},
-
+{ "format",   "Codec Format",   OFFSET(format),
AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, 
CODEC_J2K,

CODEC_JP2,   VE, "format"  },
+{ "j2k",   NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0,
  0,   VE, "format"  },
+{ "jp2",   NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0,
  0,   VE, "format"  },
+{ "tile_width","Tile Width", OFFSET(tile_width),
AV_OPT_TYPE_INT,   { .i64 = 256 }, 1,
  1<<30,   VE, },
+{ "tile_height",   "Tile Height", OFFSET(tile_height),
 AV_OPT_TYPE_INT,   { .i64 = 256 }, 1,
  1<<30,   VE, },
+{ "pred",  "DWT Type",  OFFSET(pred),
AV_OPT_TYPE_INT,   { .i64 = 0   }, 0,
  1,   VE, "pred"},
+{ "dwt97int",  NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN,
INT_MAX,   VE, "pred"},
+{ "dwt53", NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN,
INT_MAX,   VE, "pred"},
+{ "log2_cblk_width",   "Codeblock Width",
  (OFFSET(codsty)+OFFSET1(log2_cblk_width)), AV_OPT_TYPE_INT,   { .i64 =
4   }, 1, 1<<30,   VE, },
+{ "log2_cblk_height",  "Codeblock Height",
(OFFSET(codsty)+OFFSET1(log2_cblk_height)),   AV_OPT_TYPE_INT, { .i64 =
4   }, 1, 1<<30,   VE, },
  { NULL }
  };

--
2.1.4

___
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




--
/***\
*Ing. Francesco  Cuzzocrea
*company:BLT Italia srlweb:  http://www.blt.it
*address:via Rosselli, 91 city:  Lido di CAMAIORE
*country:ITALY zip:  55043-i
*  Tel. :+39 0584 904788   Fax:  +39 0584 904789
* e-mail:

Re: [FFmpeg-devel] [PATCH v2] doc/libav-merge: remove the hls merge TODO

2017-08-04 Thread Steven Liu

2017-07-27 18:25 GMT+08:00 Steven Liu :
> This TODO is done.
> See 5caaa3a49e76b084ff8a9840d541bad64d96d7f7
>
> Signed-off-by: Steven Liu 
> ---
>  doc/libav-merge.txt | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
> index 690c4ef97f..96b008b71b 100644
> --- a/doc/libav-merge.txt
> +++ b/doc/libav-merge.txt
> @@ -105,7 +105,6 @@ Collateral damage that needs work locally:
>  - Merge proresdec2.c and proresdec_lgpl.c
>  - Merge proresenc_anatoliy.c and proresenc_kostya.c
>  - Fix MIPS AC3 downmix
> -- hlsenc encryption support may need some adjustment (see edc43c571d)
>
>  Extra changes needed to be aligned with Libav:
>  --
> --
> 2.11.0 (Apple Git-81)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/2] Inserted check on codeblock size, added limits on codeblock size Modified according to Niedermayer suggestions

2017-08-04 Thread francesco

From: Francesco Cuzzocrea 

---
 libavcodec/j2kenc.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 1bd4fbd..20dda87 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1121,8 +1121,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 memset(codsty->log2_prec_heights, 15, sizeof(codsty->log2_prec_heights));
 codsty->nreslevels2decode=
 codsty->nreslevels   = 7;
-codsty->log2_cblk_width  = 4;
-codsty->log2_cblk_height = 4;
 codsty->transform= s->pred ? FF_DWT53 : FF_DWT97_INT;
 
 qntsty->nguardbits   = 1;
@@ -1131,6 +1129,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
 (s->tile_height & (s->tile_height-1))) {
 av_log(avctx, AV_LOG_WARNING, "Tile dimension not a power of 2\n");
 }
+i = codsty->log2_cblk_width + codsty->log2_cblk_height -4;
+if ( i > 12 )
+{
+  av_log(avctx, AV_LOG_ERROR, "Invalid values for codeblocks size\n");
+  return -1;
+}
+
 
 if (codsty->transform == FF_DWT53)
 qntsty->quantsty = JPEG2000_QSTY_NONE;
@@ -1178,21 +1183,20 @@ static int j2kenc_destroy(AVCodecContext *avctx)
 // taken from the libopenjpeg wraper so it matches
 
 #define OFFSET(x) offsetof(Jpeg2000EncoderContext, x)
-#define OFFSET1(x) offsetof(Jpeg2000CodingStyle, x)
 
 
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
-{ "format",   "Codec Format",   OFFSET(format),
   AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K, CODEC_JP2, 
  VE, "format"  },
-{ "j2k",   NULL,0, 
   AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0, 0, 
  VE, "format"  },
-{ "jp2",   NULL,0, 
   AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0, 0, 
  VE, "format"  },
-{ "tile_width","Tile Width",OFFSET(tile_width),
   AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30, 
  VE, },
-{ "tile_height",   "Tile Height",   OFFSET(tile_height),   
   AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30, 
  VE, },
-{ "pred",  "DWT Type",  OFFSET(pred),  
   AV_OPT_TYPE_INT,   { .i64 = 0   }, 0, 1, 
  VE, "pred"},
-{ "dwt97int",  NULL,0, 
   AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX, 
  VE, "pred"},
-{ "dwt53", NULL,0, 
   AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX, 
  VE, "pred"},
-{ "log2_cblk_width",   "Codeblock Width",   
(OFFSET(codsty)+OFFSET1(log2_cblk_width)),AV_OPT_TYPE_INT,   { .i64 = 4 
  }, 1, 1<<30,   VE, },
-{ "log2_cblk_height",  "Codeblock Height",  
(OFFSET(codsty)+OFFSET1(log2_cblk_height)),   AV_OPT_TYPE_INT,   { .i64 = 4 
  }, 1, 1<<30,   VE, },
+{ "format",   "Codec Format",   OFFSET(format),
AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K, CODEC_JP2,   VE, 
"format"  },
+{ "j2k",   NULL,0, 
AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0, 0,   VE, 
"format"  },
+{ "jp2",   NULL,0, 
AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0, 0,   VE, 
"format"  },
+{ "tile_width","Tile Width",OFFSET(tile_width),
AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
+{ "tile_height",   "Tile Height",   OFFSET(tile_height),   
AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
+{ "pred",  "DWT Type",  OFFSET(pred),  
AV_OPT_TYPE_INT,   { .i64 = 0   }, 0, 1,   VE, 
"pred"},
+{ "dwt97int",  NULL,0, 
AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE, 
"pred"},
+{ "dwt53", NULL,0, 
AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE, 
"pred"},
+{ "log2_cblk_width",   "Codeblock Width",   
OFFSET(codsty.log2_cblk_width),AV_OPT_TYPE_INT,   { .i64 = 4   }, 
0, 1<<10,   VE, },
+{ "log2_cblk_height",  "Codeblock Height",  
OFFSET(codsty.log2_cblk_height),   AV_OPT_TYPE_INT,   { .i64 = 4   }, 
0, 1<<10,   VE, },
 { NULL }
 };
 
-- 
2.1.4

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-04 Thread Mark Thompson

On 04/08/17 14:06, Jorge Ramirez wrote:
> On 08/04/2017 01:51 PM, Mark Thompson wrote:
>>> +if (ret)
>>> +return 0;
>>> +
>>> +return avpriv_v4l_dequeue(cap_pool, frame, NULL, timeout);
>>> +}
>> What happens to the decoder if some parameters like resolution change 
>> mid-stream?  (Try the stream h264/reinit-large_420_8-to-small_420_8.h264 in 
>> the fate samples.)
> 
> yes, it breaks - the player still shows and image but it is corrupted.
> I am not sure how to handle this situation to be honest...so need to look 
> into this.

There should be some way to detect it from the decoder, I think?  (I don't 
actually know how this works in V4L2.)

To compare, if you look at MMAL (perhaps the most similar API in current lavc) 
there is a special FORMAT_CHANGED return when dequeuing a frame, and the 
decoder is reconfigured with new buffers when that happens: 
.

>>
>> Also, are the frames returned here actually still used by the decoder 
>> internally as reference frames, or is the reference frame copied somewhere 
>> else? 
> 
> I think once the buffers are dequeued, the v4l2 decoder doesnt keep any 
> references to it.
>>  (Seems slightly unlikely that they would be copied given the additional 
>> memory requirements, but I know discrete desktop GPUs (which admittedly have 
>> 9001x the memory bandwidth and power budget) do do this to hide the possible 
>> issues.)  I think, though I'm not entirely sure because I haven't run it, 
>> that the returned buffers will only have the user reference, so will appear 
>> to be writable to following filters - if that ends up writing on reference 
>> frames then the decoder will break.
> 
> ack

Ok.  I'm a bit surprised because of the performance implications of writing 
everything twice, but if we don't have to think about it at all then whatever.

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

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: support fmp4 single file mode

2017-08-04 Thread Steven Liu

2017-08-04 20:49 GMT+08:00 Derek Buitenhuis :
> On 8/1/2017 4:57 PM, Steven Liu wrote:
>> add byterange mode of the hls fmp4
>>
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hlsenc.c | 83 
>> +---
>>  1 file changed, 53 insertions(+), 30 deletions(-)
>
> [...]
>
>> +if (hls->max_seg_size > 0) {
>> +av_log(s, AV_LOG_WARNING, "Have not support multiple fmp4 
>> byterange mode file in hls yet now\n");
>> +return AVERROR_PATCHWELCOME;
>> +}
>
> Not entirely sure what this message is trying to say?
>
> Is this accurate: "Multi-file byterange moe is currently unsupported in the 
> HLS muxer." ?
Ok, use your suggestion,
>
>> -int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || 
>> (hls->max_seg_size > 0);
>> +int byterange_mode = ((hls->flags & HLS_SINGLE_FILE) || 
>> (hls->max_seg_size > 0));
>
> Doesn't change anything, as far as I can tell?
reserve it for wait the specification :)
>
> Rest is OK, I think.
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

adopt suggestion and applied the patch.

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-04 Thread Jorge Ramirez


On 08/04/2017 01:51 PM, Mark Thompson wrote:

+if (ret)
+return 0;
+
+return avpriv_v4l_dequeue(cap_pool, frame, NULL, timeout);
+}

What happens to the decoder if some parameters like resolution change 
mid-stream?  (Try the stream h264/reinit-large_420_8-to-small_420_8.h264 in the 
fate samples.)


yes, it breaks - the player still shows and image but it is corrupted.
I am not sure how to handle this situation to be honest...so need to 
look into this.




Also, are the frames returned here actually still used by the decoder 
internally as reference frames, or is the reference frame copied somewhere else?


I think once the buffers are dequeued, the v4l2 decoder doesnt keep any 
references to it.

  (Seems slightly unlikely that they would be copied given the additional 
memory requirements, but I know discrete desktop GPUs (which admittedly have 
9001x the memory bandwidth and power budget) do do this to hide the possible 
issues.)  I think, though I'm not entirely sure because I haven't run it, that 
the returned buffers will only have the user reference, so will appear to be 
writable to following filters - if that ends up writing on reference frames 
then the decoder will break.


ack

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-04 Thread Jorge Ramirez


On 08/04/2017 01:51 PM, Mark Thompson wrote:

+REGISTER_ENCDEC (VP8_V4L2M2M,   vp8_v4l2m2m);
  REGISTER_DECODER(VP9,   vp9);
+REGISTER_DECODER(VP9_V4L2M2M,   vp9_v4l2m2m);
  REGISTER_DECODER(VQA,   vqa);
  REGISTER_DECODER(BITPACKED, bitpacked);
  REGISTER_DECODER(WEBP,  webp);

MPEG-2 is never mentioned at all in this configure change, so it will never 
even be compiled.  It might be best if you only add the decoders you can 
actually verify.




thanks. yes fixed in v4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: support fmp4 single file mode

2017-08-04 Thread Derek Buitenhuis

On 8/1/2017 4:57 PM, Steven Liu wrote:
> add byterange mode of the hls fmp4
> 
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 83 
> +---
>  1 file changed, 53 insertions(+), 30 deletions(-)

[...]

> +if (hls->max_seg_size > 0) {
> +av_log(s, AV_LOG_WARNING, "Have not support multiple fmp4 
> byterange mode file in hls yet now\n");
> +return AVERROR_PATCHWELCOME;
> +}

Not entirely sure what this message is trying to say?

Is this accurate: "Multi-file byterange moe is currently unsupported in the HLS 
muxer." ?

> -int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || 
> (hls->max_seg_size > 0);
> +int byterange_mode = ((hls->flags & HLS_SINGLE_FILE) || 
> (hls->max_seg_size > 0));

Doesn't change anything, as far as I can tell?

Rest is OK, I think.

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-04 Thread Mark Thompson

On 02/08/17 08:32, Jorge Ramirez-Ortiz wrote:
> diff --git a/configure b/configure
> index ed94de0..650c8fb 100755
> --- a/configure
> +++ b/configure
> @@ -10,7 +10,6 @@
>  # Prevent locale nonsense from breaking basic text processing.
>  LC_ALL=C
>  export LC_ALL
> -
>  # make sure we are running under a compatible shell
>  # try to make this part work with most shells
>  
> @@ -149,6 +148,7 @@ Component options:
>--disable-pixelutils disable pixel utils in libavutil
>  
>  Individual component options:
> +  --disable-v4l2_m2m   disable V4L2 mem2mem code [autodetect]
>--disable-everything disable all components listed below
>--disable-encoder=NAME   disable encoder NAME
>--enable-encoder=NAMEenable encoder NAME
> @@ -1432,6 +1432,7 @@ AVCODEC_COMPONENTS="
>  
>  AVDEVICE_COMPONENTS="
>  indevs
> +v4l2_m2m
>  outdevs
>  "
>  AVFILTER_COMPONENTS="
> @@ -2269,11 +2270,12 @@ map 'eval ${v}_inline_deps=inline_asm' 
> $ARCH_EXT_LIST_ARM
>  
>  loongson2_deps="mips"
>  loongson3_deps="mips"
> -v4l2_deps_any="linux_videodev2_h sys_videoio_h"
> +v4l2_m2m_select="v4l2"
>  mipsfpu_deps="mips"
>  mipsdsp_deps="mips"
>  mipsdspr2_deps="mips"
>  mips32r2_deps="mips"
> +vc1_v4l2m2m_decoder_deps="v4l2_m2m"
>  mips32r5_deps="mips"
>  mips32r6_deps="mips"
>  mips64r2_deps="mips"
> @@ -2284,6 +2286,9 @@ mmi_deps="mips"
>  altivec_deps="ppc"
>  dcbzl_deps="ppc"
>  ldbrx_deps="ppc"
> +vp8_v4l2m2m_decoder_deps="v4l2_m2m"
> +vp8_v4l2m2m_encoder_deps="v4l2_m2m"
> +vp9_v4l2m2m_decoder_deps="v4l2_m2m"
>  ppc4xx_deps="ppc"
>  vsx_deps="altivec"
>  power8_deps="vsx"
> @@ -2437,15 +2442,22 @@ h261_decoder_select="mpegvideo"
>  h261_encoder_select="aandcttables mpegvideoenc"
>  h263_decoder_select="h263_parser h263dsp mpegvideo qpeldsp"
>  h263_encoder_select="aandcttables h263dsp mpegvideoenc"
> +h263_v4l2m2m_decoder_deps="v4l2_m2m"
> +h263_v4l2m2m_encoder_deps="v4l2_m2m"
>  h263i_decoder_select="h263_decoder"
>  h263p_decoder_select="h263_decoder"
>  h263p_encoder_select="h263_encoder"
>  h264_decoder_select="cabac golomb h264chroma h264dsp h264parse h264pred 
> h264qpel videodsp"
>  h264_decoder_suggest="error_resilience"
> +h264_v4l2m2m_decoder_deps="v4l2_m2m"
> +h264_v4l2m2m_encoder_deps="v4l2_m2m"
>  hap_decoder_select="snappy texturedsp"
>  hap_encoder_deps="libsnappy"
>  hap_encoder_select="texturedspenc"
>  hevc_decoder_select="bswapdsp cabac golomb hevcparse videodsp"
> +hevc_encoder_select="hevc_v4l2m2m"
> +hevc_v4l2m2m_decoder_deps="v4l2_m2m"
> +hevc_v4l2m2m_encoder_deps="v4l2_m2m"
>  huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
>  huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llvidencdsp"
>  iac_decoder_select="imc_decoder"
> @@ -2482,6 +2494,7 @@ mpc7_decoder_select="bswapdsp mpegaudiodsp"
>  mpc8_decoder_select="mpegaudiodsp"
>  mpeg_xvmc_decoder_deps="X11_extensions_XvMClib_h"
>  mpeg_xvmc_decoder_select="mpeg2video_decoder"
> +mpeg1_v4l2m2m_decoder_deps="v4l2_m2m"
>  mpegvideo_decoder_select="mpegvideo"
>  mpeg1video_decoder_select="mpegvideo"
>  mpeg1video_encoder_select="aandcttables mpegvideoenc h263dsp"
> @@ -2489,6 +2502,8 @@ mpeg2video_decoder_select="mpegvideo"
>  mpeg2video_encoder_select="aandcttables mpegvideoenc h263dsp"
>  mpeg4_decoder_select="h263_decoder mpeg4video_parser"
>  mpeg4_encoder_select="h263_encoder"
> +mpeg4_v4l2m2m_decoder_deps="v4l2_m2m"
> +mpeg4_v4l2m2m_encoder_deps="v4l2_m2m"
>  msa1_decoder_select="mss34dsp"
>  mscc_decoder_select="zlib"
>  msmpeg4v1_decoder_select="h263_decoder"
> @@ -3042,7 +3057,6 @@ qtkit_indev_select="qtkit"
>  sdl2_outdev_deps="sdl2"
>  sndio_indev_deps="sndio"
>  sndio_outdev_deps="sndio"
> -v4l_indev_deps="linux_videodev_h"
>  v4l2_indev_select="v4l2"
>  v4l2_outdev_select="v4l2"
>  vfwcap_indev_deps="vfw32 vfwcap_defines"
> @@ -3592,7 +3606,7 @@ done
>  enable_weak audiotoolbox
>  
>  # Enable hwaccels by default.
> -enable_weak d3d11va dxva2 vaapi vda vdpau videotoolbox_hwaccel xvmc
> +enable_weak d3d11va dxva2 vaapi v4l2_m2m vda vdpau videotoolbox_hwaccel xvmc
>  enable_weak xlib
>  
>  enable_weak cuda cuvid nvenc vda_framework videotoolbox videotoolbox_encoder
> @@ -6058,12 +6072,10 @@ pod2man --help > /dev/null 2>&1 && enable pod2man 
>   || disable pod2man
>  rsync --help 2> /dev/null | grep -q 'contimeout' && enable rsync_contimeout 
> || disable rsync_contimeout
>  
>  check_header linux/fb.h
> -check_header linux/videodev.h
> -check_header linux/videodev2.h
> -check_code cc linux/videodev2.h "struct v4l2_frmsizeenum vfse; 
> vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete
>  
>  check_header sys/videoio.h
>  check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse; 
> vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete
> +add_cflags -I$source_path/compat/v4l2
>  
>  check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
>  check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
> diff --git a/libavcodec/Makefile

Re: [FFmpeg-devel] [PATCH] libavcodec/mips: Improve avc idct8 msa function

2017-08-04 Thread Kaustubh Raste

Ping.

-Original Message-
From: Manojkumar Bhosale 
Sent: Monday, July 31, 2017 3:43 PM
To: FFmpeg development discussions and patches
Cc: Kaustubh Raste
Subject: RE: [FFmpeg-devel] [PATCH] libavcodec/mips: Improve avc idct8 msa 
function

LGTM

thx

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Monday, July 31, 2017 12:07 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] libavcodec/mips: Improve avc idct8 msa function

From: Kaustubh Raste 

Replace memset call with msa stores.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264idct_msa.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mips/h264idct_msa.c b/libavcodec/mips/h264idct_msa.c 
index 861befe..1e1a5c8 100644
--- a/libavcodec/mips/h264idct_msa.c
+++ b/libavcodec/mips/h264idct_msa.c
@@ -120,11 +120,12 @@ static void avc_idct8_addblk_msa(uint8_t *dst, int16_t 
*src, int32_t dst_stride)
 v4i32 res0_r, res1_r, res2_r, res3_r, res4_r, res5_r, res6_r, res7_r;
 v4i32 res0_l, res1_l, res2_l, res3_l, res4_l, res5_l, res6_l, res7_l;
 v16i8 dst0, dst1, dst2, dst3, dst4, dst5, dst6, dst7;
-v16i8 zeros = { 0 };
+v8i16 zeros = { 0 };
 
 src[0] += 32;
 
 LD_SH8(src, 8, src0, src1, src2, src3, src4, src5, src6, src7);
+ST_SH8(zeros, zeros, zeros, zeros, zeros, zeros, zeros, zeros, src, 
+ 8);
 
 vec0 = src0 + src4;
 vec1 = src0 - src4;
@@ -318,7 +319,6 @@ void ff_h264_idct8_addblk_msa(uint8_t *dst, int16_t *src,
   int32_t dst_stride)  {
 avc_idct8_addblk_msa(dst, src, dst_stride);
-memset(src, 0, 64 * sizeof(dctcoef));
 }
 
 void ff_h264_idct4x4_addblk_dc_msa(uint8_t *dst, int16_t *src,
--
1.7.9.5

___
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] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-04 Thread Mark Thompson

On 04/08/17 09:46, Jorge Ramirez wrote:
> On 08/03/2017 01:53 AM, Mark Thompson wrote:
>>> +}
>>> +
>>> +ret = poll(, 1, timeout);
>> Can this poll be interrupted?
> yes. when that happens, we indicate no buffer available.
> I think the main program should set the necessary masks.

I was thinking this might violate the send/receive semantics without EINTR 
handling - consider a situation where send returns EAGAIN (e.g. by trying to 
send 9001 packets to a decoder all at once) so the caller does a receive but 
that then races with a signal such that poll returns EINTR, then receive would 
return EAGAIN as well which isn't allowed.

If you want to impose signal handling requirements on the caller then that 
would need to be documented somewhere.

>>> +if (ret <=  0)
>>> +return NULL;
>>> +
>>> +memset(, 0, sizeof(buf));
>>> +buf.memory = bp->memory;
>>> +buf.type = bp->type;
>>> +if (V4L2_TYPE_IS_MULTIPLANAR(bp->type)) {
>>> +memset(planes, 0, sizeof(planes));
>>> +buf.length = VIDEO_MAX_PLANES;
>>> +buf.m.planes = planes;
>>> +}
>>> +ret = ioctl(bp->fd, VIDIOC_DQBUF, );
>>> +if (ret) {
>>> +if (errno != EAGAIN && errno != EINVAL) {
>> EINVAL is considered ok?
> 
> no any ioctl that returns non zero is a fault condition.
> EINVAL (just as EAGAIN) is just not an unrecoverable error (we will just 
> return null indicating that there is no buffer available)

EINVAL usually indicates that the arguments were invalid somehow, but I think 
with this setup it's just going to call it again with pretty much arguments.  
In what case can EINVAL be recoverable?

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-04 Thread Jorge Ramirez


On 08/03/2017 01:53 AM, Mark Thompson wrote:

agree with all your previous comments up to here (will fix).


+case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+pfd.events = POLLOUT | POLLERR | POLLWRNORM;
+break;
+default:
+pfd.events = POLLIN | POLLERR | POLLRDNORM;

What hits this default case?


nothing, it can't happen will remove.



+}
+
+ret = poll(, 1, timeout);

Can this poll be interrupted?

yes. when that happens, we indicate no buffer available.
I think the main program should set the necessary masks.


+if (ret <=  0)
+return NULL;
+
+memset(, 0, sizeof(buf));
+buf.memory = bp->memory;
+buf.type = bp->type;
+if (V4L2_TYPE_IS_MULTIPLANAR(bp->type)) {
+memset(planes, 0, sizeof(planes));
+buf.length = VIDEO_MAX_PLANES;
+buf.m.planes = planes;
+}
+ret = ioctl(bp->fd, VIDIOC_DQBUF, );
+if (ret) {
+if (errno != EAGAIN && errno != EINVAL) {

EINVAL is considered ok?


no any ioctl that returns non zero is a fault condition.
EINVAL (just as EAGAIN) is just not an unrecoverable error (we will just 
return null indicating that there is no buffer available)



+av_log(bp->log_ctx, AV_LOG_DEBUG, "%s: VIDIOC_DQBUF, errno (%d)\n", 
bp->name, errno);
+bp->broken = errno;

errno can be overwritten by the av_log() call.


OK.




+}
+return NULL;
+}
+


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

Re: [FFmpeg-devel] [PATCH] JPEG2000 encoding with variable codeblock size

2017-08-04 Thread Francesco, Cuzzocrea

The standard ISO/IEC FCD15444-1 specify limits for the exponent values 
and their sum. That is codeblock


size xcb and ycb are defined as:

xcb = 2^(xvalue+2)  and ycb = 2^(yvalue+2)

with values that ranges from a minimum of 2 and a maximum of 10. Moreover

the sum should be less or equal to 12 ( xvalue + yvalue <=12). So 64x128 
are allowed because


xvalue = 4 and yvalue = 5.



On 03/08/2017 19.24, Aaron Boxer wrote:

On Aug 3, 2017 9:58 AM,  wrote:

From: Francesco Cuzzocrea 

Hi to all
I've made some simple changes tha allow encoding with variable codeblock
size.  Default value are the same as previous (16X16) but now setting them
to 64x128 make generated codestream compatible with Analog Devices ADV212
video codec.


Interesting - as far as I  aware, part 1 of standard only allows codeblock
of max size 4096, so 64x128 would not be legal.



---
  libavcodec/j2kenc.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index c8d3861..1bd4fbd 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1178,17 +1178,21 @@ static int j2kenc_destroy(AVCodecContext *avctx)
  // taken from the libopenjpeg wraper so it matches

  #define OFFSET(x) offsetof(Jpeg2000EncoderContext, x)
+#define OFFSET1(x) offsetof(Jpeg2000CodingStyle, x)
+
+
  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
  static const AVOption options[] = {
-{ "format","Codec Format",  OFFSET(format),
AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K, CODEC_JP2,   VE,
"format"  },
-{ "j2k",   NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0, 0,   VE,
"format"  },
-{ "jp2",   NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0, 0,   VE,
"format"  },
-{ "tile_width","Tile Width",OFFSET(tile_width),
AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
-{ "tile_height",   "Tile Height",   OFFSET(tile_height),
  AV_OPT_TYPE_INT,   { .i64 = 256 }, 1, 1<<30,   VE, },
-{ "pred",  "DWT Type",  OFFSET(pred),
AV_OPT_TYPE_INT,   { .i64 = 0   }, 0, 1,   VE,
"pred"},
-{ "dwt97int",  NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE,
"pred"},
-{ "dwt53", NULL,0,
  AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE,
"pred"},
-
+{ "format",   "Codec Format",   OFFSET(format),
AV_OPT_TYPE_INT,   { .i64 = CODEC_JP2   }, CODEC_J2K,
CODEC_JP2,   VE, "format"  },
+{ "j2k",   NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = CODEC_J2K   }, 0,
  0,   VE, "format"  },
+{ "jp2",   NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = CODEC_JP2   }, 0,
  0,   VE, "format"  },
+{ "tile_width","Tile Width",OFFSET(tile_width),
AV_OPT_TYPE_INT,   { .i64 = 256 }, 1,
  1<<30,   VE, },
+{ "tile_height",   "Tile Height",   OFFSET(tile_height),
 AV_OPT_TYPE_INT,   { .i64 = 256 }, 1,
  1<<30,   VE, },
+{ "pred",  "DWT Type",  OFFSET(pred),
AV_OPT_TYPE_INT,   { .i64 = 0   }, 0,
  1,   VE, "pred"},
+{ "dwt97int",  NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN,
INT_MAX,   VE, "pred"},
+{ "dwt53", NULL,0,
 AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN,
INT_MAX,   VE, "pred"},
+{ "log2_cblk_width",   "Codeblock Width",
  (OFFSET(codsty)+OFFSET1(log2_cblk_width)),AV_OPT_TYPE_INT,   { .i64 =
4   }, 1, 1<<30,   VE, },
+{ "log2_cblk_height",  "Codeblock Height",
(OFFSET(codsty)+OFFSET1(log2_cblk_height)),   AV_OPT_TYPE_INT,   { .i64 =
4   }, 1, 1<<30,   VE, },
  { NULL }
  };

--
2.1.4

___
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


--
/***\
*Ing. Francesco  Cuzzocrea
*company:BLT Italia srlweb:  http://www.blt.it
*address:via Rosselli, 91 city:  Lido di CAMAIORE
*country:ITALY zip:  55043-i
*  Tel. :+39 0584 904788   Fax:  +39 0584 904789
* e-mail:   france...@bltitalia.com

[FFmpeg-devel] [PATCH] avfilter/vf_overlay: fix alpha blending for planar formats with a transparent background

2017-08-04 Thread Marton Balint

When the background had an alpha channel, the old code in blend_plane
calculated premultiplied alpha from the destination plane colors instead of the
destination alpha.

Also the calculation of the output alpha should only happen after the color
planes are already finished.

Fixes output of:
ffplay -f lavfi "testsrc2=alpha=32[a];color=black[b];[b][a]overlay[out0]"

Signed-off-by: Marton Balint 
---
 libavfilter/vf_overlay.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index ad292a61c1..52f09fae1f 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -508,7 +508,7 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
 int dst_hp = AV_CEIL_RSHIFT(dst_h, vsub);
 int yp = y>>vsub;
 int xp = x>>hsub;
-uint8_t *s, *sp, *d, *dp, *a, *ap;
+uint8_t *s, *sp, *d, *dp, *dap, *a, *da, *ap;
 int jmax, j, k, kmax;
 
 j = FFMAX(-yp, 0);
@@ -517,12 +517,14 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
   + (yp+j)* dst->linesize[dst_plane]
   + dst_offset;
 ap = src->data[3] + (j<linesize[3];
+dap = dst->data[3] + ((yp+j) << vsub) * dst->linesize[3];
 
 for (jmax = FFMIN(-yp + dst_hp, src_hp); j < jmax; j++) {
 k = FFMAX(-xp, 0);
 d = dp + (xp+k) * dst_step;
 s = sp + k;
 a = ap + (k<linesize[3]] +
-   d[1] + d[src->linesize[3]+1]) >> 2;
+alpha_d = (da[0] + da[dst->linesize[3]] +
+   da[1] + da[dst->linesize[3]+1]) >> 2;
 } else if (hsub || vsub) {
 alpha_h = hsub && k+1 < src_wp ?
-(d[0] + d[1]) >> 1 : d[0];
+(da[0] + da[1]) >> 1 : da[0];
 alpha_v = vsub && j+1 < src_hp ?
-(d[0] + d[src->linesize[3]]) >> 1 : d[0];
+(da[0] + da[dst->linesize[3]]) >> 1 : da[0];
 alpha_d = (alpha_v + alpha_h) >> 1;
 } else
-alpha_d = d[0];
+alpha_d = da[0];
 alpha = UNPREMULTIPLY_ALPHA(alpha, alpha_d);
 }
 *d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
 s++;
 d += dst_step;
+da += 1 << hsub;
 a += 1 << hsub;
 }
 dp += dst->linesize[dst_plane];
 sp += src->linesize[i];
 ap += (1 << vsub) * src->linesize[3];
+dap += (1 << vsub) * dst->linesize[3];
 }
 }
 
@@ -622,15 +626,15 @@ static av_always_inline void 
blend_image_yuv(AVFilterContext *ctx,
 const int dst_w = dst->width;
 const int dst_h = dst->height;
 
-if (main_has_alpha)
-alpha_composite(src, dst, src_w, src_h, dst_w, dst_h, x, y);
-
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0,   0, x, 
y, main_has_alpha,
 s->main_desc->comp[0].plane, s->main_desc->comp[0].offset, 
s->main_desc->comp[0].step);
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 1, hsub, vsub, x, 
y, main_has_alpha,
 s->main_desc->comp[1].plane, s->main_desc->comp[1].offset, 
s->main_desc->comp[1].step);
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 2, hsub, vsub, x, 
y, main_has_alpha,
 s->main_desc->comp[2].plane, s->main_desc->comp[2].offset, 
s->main_desc->comp[2].step);
+
+if (main_has_alpha)
+alpha_composite(src, dst, src_w, src_h, dst_w, dst_h, x, y);
 }
 
 static av_always_inline void blend_image_planar_rgb(AVFilterContext *ctx,
@@ -645,15 +649,15 @@ static av_always_inline void 
blend_image_planar_rgb(AVFilterContext *ctx,
 const int dst_w = dst->width;
 const int dst_h = dst->height;
 
-if (main_has_alpha)
-alpha_composite(src, dst, src_w, src_h, dst_w, dst_h, x, y);
-
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0,   0, x, 
y, main_has_alpha,
 s->main_desc->comp[1].plane, s->main_desc->comp[1].offset, 
s->main_desc->comp[1].step);
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 1, hsub, vsub, x, 
y, main_has_alpha,
 s->main_desc->comp[2].plane, s->main_desc->comp[2].offset, 
s->main_desc->comp[2].step);
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 2, hsub, vsub, x, 
y, main_has_alpha,

[FFmpeg-devel] [PATCH V6] lavfi/scale_vaapi: add denoise/sharpness support.

2017-08-04 Thread Jun Zhao

V6 : - Re-work with current scale_vaapi and double check i965 have fix the 
sharpness issue.
   https://bugs.freedesktop.org/show_bug.cgi?id=96988
v5 : - fix the commit message as review(Mark Thompson and Moritz Barsnick)
 - change the magic filter numbers 8 with VAProcFilterCount
 - check multiple filters because multiple filters aren't supported in
   the driver now
v4 : - fix sharpless typo(sharpless -> sharpness)
 - when don't support denoise/sharpness, report the error and return
 - fix denoise/sharpness params buffer leak in error handle
v3 : fix sharpless mapping issue
v2 : fix filter support flag check logic issue
From 5a97b6c307480b59d27f3dc2aabdb0781912835d Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 4 Aug 2017 03:10:40 -0400
Subject: [PATCH V6] lavfi/scale_vaapi: add denoise/sharpness support.

add denoise/sharpness support, used scope [-1, 100] as the input
scope.

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_scale_vaapi.c | 107 +++
 1 file changed, 107 insertions(+)

diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 5f049a5d7b..cb5b03df61 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -58,6 +58,14 @@ typedef struct ScaleVAAPIContext {
 
 int output_width;  // computed width
 int output_height; // computed height
+
+VAProcFilterCap denoise_caps;
+int denoise; // enable denoise algo. level is the optional
+ // value from the interval [-1, 100], -1 means 
disabled
+
+VAProcFilterCap sharpness_caps;
+int sharpness;   // enable sharpness. level is the optional value
+ // from the interval [-1, 100], -1 means disabled
 } ScaleVAAPIContext;
 
 
@@ -126,6 +134,8 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
 AVVAAPIFramesContext *va_frames;
 VAStatus vas;
 int err, i;
+uint32_t num_denoise_caps = 1;
+uint32_t num_sharpness_caps = 1;
 
 scale_vaapi_pipeline_uninit(ctx);
 
@@ -240,6 +250,40 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
 goto fail;
 }
 
+// multiple filters aren't supported in the driver:
+// sharpness can't work with noise reduction(de-noise), deinterlacing
+// color balance, skin tone enhancement...
+if (ctx->denoise != -1 && ctx->sharpness != -1) {
+av_log(ctx, AV_LOG_ERROR, "Do not support multiply filters (sharpness "
+   "can't work with the other filters).\n");
+err = AVERROR(EINVAL);
+goto fail;
+}
+
+if (ctx->denoise != -1) {
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterNoiseReduction,
+ >denoise_caps, 
_denoise_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to query denoise caps "
+   "context: %d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+}
+
+if (ctx->sharpness != -1) {
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterSharpening,
+ >sharpness_caps, 
_sharpness_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to query sharpness caps "
+   "context: %d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+}
+
 av_freep();
 av_hwframe_constraints_free();
 return 0;
@@ -265,6 +309,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace 
av_cs)
 }
 }
 
+static float map_to_range(
+int input, int in_min, int in_max,
+float out_min, float out_max)
+{
+return (input - in_min) * (out_max - out_min) / (in_max - in_min) + 
out_min;
+}
+
+
 static int scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame *input_frame)
 {
 AVFilterContext *avctx = inlink->dst;
@@ -274,6 +326,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 VASurfaceID input_surface, output_surface;
 VAProcPipelineParameterBuffer params;
 VABufferID params_id;
+VABufferID denoise_id;
+VABufferID sharpness_id;
+VABufferID filter_bufs[VAProcFilterCount];
+int num_filter_bufs = 0;
 VARectangle input_region;
 VAStatus vas;
 int err;
@@ -300,6 +356,43 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 av_log(ctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
output_surface);
 
+if (ctx->denoise != -1) {
+VAProcFilterParameterBuffer denoise;
+denoise.type  = VAProcFilterNoiseReduction;
+denoise.value =  map_to_range(ctx->denoise, 0, 100,
+

41 matches

Mail list logo