date:20190418

Re: [FFmpeg-devel] [PATCH] avutil/colorspace: add macros for RGB->YUV BT.709

2019-04-18 Thread Gyan




On 19-04-2019 01:04 AM, Gyan wrote:



On 17-04-2019 11:30 PM, Gyan wrote:



On 17-04-2019 11:11 PM, Vittorio Giovara wrote:

On Wed, Apr 17, 2019 at 12:26 AM Gyan  wrote:



On 13-04-2019 05:23 PM, Gyan wrote:

Will be helpful for correct result in filters that paint like
fillborders/drawbox or those using drawutils.

Ping.


these seem to only work for 8 bit content, is that their only intended
usecase?
if so, could there be at least a comment mentioning that please?
Yes, the existing macros use Rec.601 co-efficients, but most data is 
709 now.

Will add a note.


With note.


Will apply soon.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavf/img2enc: add support for option strftime_source

2019-04-18 Thread Jun Li

On Wed, Apr 17, 2019 at 6:23 PM Carl Eugen Hoyos  wrote:

> 2019-04-18 2:02 GMT+02:00, Jun Li :
> > On Wed, Apr 17, 2019 at 3:11 PM Carl Eugen Hoyos 
> wrote:
> >
> >> 2019-04-15 8:43 GMT+02:00, Jun Li :
> >> > Currently the strftime option generate timestamp based on generation
> >> > time. The new option would calcualte timestamp from source's
> >> > start_realtime and pkt->pts, try to generate a timestamp matches the
> >> > source starting time.
> >>
> >> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> >> > index 8349840c96..16bb143ca6 100644
> >> > --- a/libavformat/rtsp.c
> >> > +++ b/libavformat/rtsp.c
> >> > @@ -2253,6 +2253,7 @@ redo:
> >> >  (uint64_t)
> >> > rtpctx->st->time_base.num * 100,
> >> >
> >> > rtpctx->st->time_base.den);
> >> >  }
> >> > +av_dict_set_int(>metadata, "start_realtime",
> >> > s->start_time_realtime, 0);
> >>
> >> Is this change related?
>
> > Thanks Carl for review !
>
> > Yes, it is related.
>
> But the change should be separate unless something gets broken.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Thanks Carl for review. Updated the version here:
https://patchwork.ffmpeg.org/patch/12805/
I re-thinked about the feature, it can be and should be separated into two
different tasks, one for img2 genrating timestamp from output timebase, the
other for passing input start_time_realtime to output. They actually donot
have direct connections.

Best Regards,
Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] lavf/img2enc: add support for option strftime_start_realtime

2019-04-18 Thread Jun Li

Currently the strftime option generate timestamp based on generation
time. The new option would calcualte timestamp from start_time_realtime
and pkt->pts, based on output's timescale.
---
 doc/muxers.texi   |  5 +
 libavformat/img2enc.c | 34 ++
 2 files changed, 39 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 83ae017d6c..ee99ef621e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1193,6 +1193,11 @@ overwritten with new images. Default value is 0.
 @item strftime
 If set to 1, expand the filename with date and time information from
 @code{strftime()}. Default value is 0.
+
+@item strftime_start_realtime
+If set to 1, expand the filename with date and time information from
+@code{strftime()}, starting from start_time_realtime and calcualted
+from pkt->pts in UTC time. Default value is 0.
 @end table
 
 The image muxer supports the .Y.U.V image file format. This format is
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index bec4bf81dd..0f27e5ceaf 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -26,6 +26,7 @@
 #include "libavutil/log.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
 #include "libavutil/time_internal.h"
 #include "avformat.h"
 #include "avio_internal.h"
@@ -45,6 +46,7 @@ typedef struct VideoMuxData {
 int frame_pts;
 const char *muxer;
 int use_rename;
+int strftime_start_realtime;
 } VideoMuxData;
 
 static int write_header(AVFormatContext *s)
@@ -105,6 +107,37 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the 
frames.");
 return AVERROR(EINVAL);
 }
+} else if (img->strftime_start_realtime) {
+int64_t start_realtime = s->start_time_realtime;
+int64_t timestamp = 0; 
+struct tm *tm;
+time_t sec = 0;
+
+if (start_realtime == 0 || start_realtime == AV_NOPTS_VALUE) {
+// the value is not set by either user or encoder, try use 
creation_time
+if (ff_parse_creation_time_metadata(s, _realtime, 0) != 
0)
+av_log(s, AV_LOG_INFO, "Use creation_time as 
start_realtime.\n");
+
+if (start_realtime == 0 || start_realtime == AV_NOPTS_VALUE) {
+av_log(s, AV_LOG_WARNING, "Could not get 
start_time_realtime, set value to now.\n");
+timestamp = av_gettime();
+s->start_time_realtime = timestamp;
+} else {
+s->start_time_realtime = start_realtime;
+}
+}
+
+if (!timestamp) {
+int64_t offset = av_rescale_q(pkt->pts, 
s->streams[0]->time_base, AV_TIME_BASE_Q);
+timestamp = s->start_time_realtime + offset;
+}
+
+sec = timestamp / AV_TIME_BASE;
+tm = gmtime();
+if (!strftime(filename, sizeof(filename), img->path, tm)) {
+av_log(s, AV_LOG_ERROR, "Could not get frame filename with 
strftime\n");
+return AVERROR(EINVAL);
+}
 } else if (av_get_frame_filename2(filename, sizeof(filename), 
img->path,
   img->img_number,
   AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 
0 &&
@@ -215,6 +248,7 @@ static const AVOption muxoptions[] = {
 { "strftime", "use strftime for filename", OFFSET(use_strftime),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { "frame_pts","use current frame pts for filename", OFFSET(frame_pts), 
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { "atomic_writing", "write files atomically (using temporary files and 
renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
+{ "strftime_start_realtime", "use strftime for filename and timestamp 
calculated from start_time_realtime", OFFSET(strftime_start_realtime), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { NULL },
 };
 
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/apetag: tag values are unsigned

2019-04-18 Thread Dan Sanders via ffmpeg-devel

> > +#define APE_TAG_FLAG_CONTAINS_HEADER  (1U << 31)
>
> Isn't it enough with this one only?

Yes, only APE_TAG_FLAG_CONTAINS_HEADER is problematic. I changed all
of them because the tags are only used in unsigned contexts anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] New API usage example (it converts, encodes, muxes a raw audio file and shows how to use a custom callback for muxing, with an allocated I/O context)

2019-04-18 Thread Carl Eugen Hoyos

2019-04-19 2:34 GMT+02:00, Paolo Prete :

> diff --git a/doc/examples/Makefile b/doc/examples/Makefile
> index 2935424e54..7b7855fa27 100644
> --- a/doc/examples/Makefile
> +++ b/doc/examples/Makefile
> @@ -1,26 +1,27 @@
> -EXAMPLES-$(CONFIG_AVIO_DIR_CMD_EXAMPLE)  += avio_dir_cmd
> -EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE)  += avio_reading
> -EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE)  += decode_audio
> -EXAMPLES-$(CONFIG_DECODE_VIDEO_EXAMPLE)  += decode_video
> -EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE) += demuxing_decoding
> -EXAMPLES-$(CONFIG_ENCODE_AUDIO_EXAMPLE)  += encode_audio
> -EXAMPLES-$(CONFIG_ENCODE_VIDEO_EXAMPLE)  += encode_video
> -EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE)   += extract_mvs
> -EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE)  += filter_audio
> -EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE)   += filtering_audio
> -EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE)   += filtering_video
> -EXAMPLES-$(CONFIG_HTTP_MULTICLIENT_EXAMPLE)  += http_multiclient
> -EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE) += hw_decode
> -EXAMPLES-$(CONFIG_METADATA_EXAMPLE)  += metadata
> -EXAMPLES-$(CONFIG_MUXING_EXAMPLE)+= muxing
> -EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)+= qsvdec
> -EXAMPLES-$(CONFIG_REMUXING_EXAMPLE)  += remuxing
> -EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += resampling_audio
> -EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
> -EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
> -EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
> -EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
> -EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE)   += vaapi_transcode
> +EXAMPLES-$(CONFIG_AVIO_DIR_CMD_EXAMPLE) += avio_dir_cmd
> +EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE) += avio_reading
> +EXAMPLES-$(CONFIG_CONVERT_ENCODE_MUX_AUDIO_EXAMPLE) +=
> convert_encode_mux_audio
> +EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE) += decode_audio
> +EXAMPLES-$(CONFIG_DECODE_VIDEO_EXAMPLE) += decode_video
> +EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE)+= demuxing_decoding
> +EXAMPLES-$(CONFIG_ENCODE_AUDIO_EXAMPLE) += encode_audio
> +EXAMPLES-$(CONFIG_ENCODE_VIDEO_EXAMPLE) += encode_video
> +EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE)  += extract_mvs
> +EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE) += filter_audio
> +EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE)  += filtering_audio
> +EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE)  += filtering_video
> +EXAMPLES-$(CONFIG_HTTP_MULTICLIENT_EXAMPLE) += http_multiclient
> +EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE)+= hw_decode
> +EXAMPLES-$(CONFIG_METADATA_EXAMPLE) += metadata
> +EXAMPLES-$(CONFIG_MUXING_EXAMPLE)   += muxing
> +EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)   += qsvdec
> +EXAMPLES-$(CONFIG_REMUXING_EXAMPLE) += remuxing
> +EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) += resampling_audio
> +EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE)+= scaling_video
> +EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE)+= transcode_aac
> +EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)  += transcoding
> +EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
> +EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE)  += vaapi_transcode

Please do not mix functional and cosmetic changes of this size
in a patch.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] New API usage example (it converts, encodes, muxes a raw audio file and shows how to use a custom callback for muxing, with an allocated I/O context)

2019-04-18 Thread Paolo Prete

I think this example can be useful for showing all the above tasks in an 
ordered,
easy and strictly sequential way, with a kind of input close to the user's 
needings.

Signed-off-by: Paolo Prete 
---
 configure   |   2 +
 doc/examples/Makefile   |  47 ++--
 doc/examples/Makefile.example   |   1 +
 doc/examples/convert_encode_mux_audio.c | 349 
 4 files changed, 376 insertions(+), 23 deletions(-)
 create mode 100644 doc/examples/convert_encode_mux_audio.c

diff --git a/configure b/configure
index e10e2c2c46..1ae62ebdd5 100755
--- a/configure
+++ b/configure
@@ -1653,6 +1653,7 @@ COMPONENT_LIST="
 EXAMPLE_LIST="
 avio_dir_cmd_example
 avio_reading_example
+convert_encode_mux_audio_example
 decode_audio_example
 decode_video_example
 demuxing_decoding_example
@@ -3539,6 +3540,7 @@ yadif_cuda_filter_deps="ffnvcodec cuda_nvcc"
 # examples
 avio_dir_cmd_deps="avformat avutil"
 avio_reading_deps="avformat avcodec avutil"
+convert_encode_mux_audio_example_deps="avformat avcodec swresample"
 decode_audio_example_deps="avcodec avutil"
 decode_video_example_deps="avcodec avutil"
 demuxing_decoding_example_deps="avcodec avformat avutil"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 2935424e54..7b7855fa27 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -1,26 +1,27 @@
-EXAMPLES-$(CONFIG_AVIO_DIR_CMD_EXAMPLE)  += avio_dir_cmd
-EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE)  += avio_reading
-EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE)  += decode_audio
-EXAMPLES-$(CONFIG_DECODE_VIDEO_EXAMPLE)  += decode_video
-EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE) += demuxing_decoding
-EXAMPLES-$(CONFIG_ENCODE_AUDIO_EXAMPLE)  += encode_audio
-EXAMPLES-$(CONFIG_ENCODE_VIDEO_EXAMPLE)  += encode_video
-EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE)   += extract_mvs
-EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE)  += filter_audio
-EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE)   += filtering_audio
-EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE)   += filtering_video
-EXAMPLES-$(CONFIG_HTTP_MULTICLIENT_EXAMPLE)  += http_multiclient
-EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE) += hw_decode
-EXAMPLES-$(CONFIG_METADATA_EXAMPLE)  += metadata
-EXAMPLES-$(CONFIG_MUXING_EXAMPLE)+= muxing
-EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)+= qsvdec
-EXAMPLES-$(CONFIG_REMUXING_EXAMPLE)  += remuxing
-EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += resampling_audio
-EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
-EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
-EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
-EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
-EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE)   += vaapi_transcode
+EXAMPLES-$(CONFIG_AVIO_DIR_CMD_EXAMPLE) += avio_dir_cmd
+EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE) += avio_reading
+EXAMPLES-$(CONFIG_CONVERT_ENCODE_MUX_AUDIO_EXAMPLE) += convert_encode_mux_audio
+EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE) += decode_audio
+EXAMPLES-$(CONFIG_DECODE_VIDEO_EXAMPLE) += decode_video
+EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE)+= demuxing_decoding
+EXAMPLES-$(CONFIG_ENCODE_AUDIO_EXAMPLE) += encode_audio
+EXAMPLES-$(CONFIG_ENCODE_VIDEO_EXAMPLE) += encode_video
+EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE)  += extract_mvs
+EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE) += filter_audio
+EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE)  += filtering_audio
+EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE)  += filtering_video
+EXAMPLES-$(CONFIG_HTTP_MULTICLIENT_EXAMPLE) += http_multiclient
+EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE)+= hw_decode
+EXAMPLES-$(CONFIG_METADATA_EXAMPLE) += metadata
+EXAMPLES-$(CONFIG_MUXING_EXAMPLE)   += muxing
+EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)   += qsvdec
+EXAMPLES-$(CONFIG_REMUXING_EXAMPLE) += remuxing
+EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) += resampling_audio
+EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE)+= scaling_video
+EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE)+= transcode_aac
+EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)  += transcoding
+EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
+EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE)  += vaapi_transcode
 
 EXAMPLES   := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
 EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/Makefile.example b/doc/examples/Makefile.example
index 6428154c51..04e5c902a8 100644
--- a/doc/examples/Makefile.example
+++ b/doc/examples/Makefile.example
@@ -15,6 +15,7 @@ EXAMPLES=   avio_dir_cmd   \
 avio_reading   \
 decode_audio

Re: [FFmpeg-devel] [PATCH] avformat/apetag: tag values are unsigned

2019-04-18 Thread James Almer

On 4/18/2019 9:12 PM, Dan Sanders via ffmpeg-devel wrote:
> Fixes: UBSan runtime error
> Found-by: Clusterfuzz
> ---
>  libavformat/apetag.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/apetag.c b/libavformat/apetag.c
> index cdc602e1a9..2991f57d5d 100644
> --- a/libavformat/apetag.c
> +++ b/libavformat/apetag.c
> @@ -29,10 +29,10 @@
>  #include "apetag.h"
>  #include "internal.h"
> 
> -#define APE_TAG_FLAG_CONTAINS_HEADER  (1 << 31)
> -#define APE_TAG_FLAG_LACKS_FOOTER (1 << 30)
> -#define APE_TAG_FLAG_IS_HEADER(1 << 29)
> -#define APE_TAG_FLAG_IS_BINARY(1 << 1)
> +#define APE_TAG_FLAG_CONTAINS_HEADER  (1U << 31)

Isn't it enough with this one only?

> +#define APE_TAG_FLAG_LACKS_FOOTER (1U << 30)
> +#define APE_TAG_FLAG_IS_HEADER(1U << 29)
> +#define APE_TAG_FLAG_IS_BINARY(1U << 1)
> 
>  static int ape_tag_read_field(AVFormatContext *s)
>  {
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/apetag: tag values are unsigned

2019-04-18 Thread Dan Sanders via ffmpeg-devel

Fixes: UBSan runtime error
Found-by: Clusterfuzz
---
 libavformat/apetag.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/apetag.c b/libavformat/apetag.c
index cdc602e1a9..2991f57d5d 100644
--- a/libavformat/apetag.c
+++ b/libavformat/apetag.c
@@ -29,10 +29,10 @@
 #include "apetag.h"
 #include "internal.h"

-#define APE_TAG_FLAG_CONTAINS_HEADER  (1 << 31)
-#define APE_TAG_FLAG_LACKS_FOOTER (1 << 30)
-#define APE_TAG_FLAG_IS_HEADER(1 << 29)
-#define APE_TAG_FLAG_IS_BINARY(1 << 1)
+#define APE_TAG_FLAG_CONTAINS_HEADER  (1U << 31)
+#define APE_TAG_FLAG_LACKS_FOOTER (1U << 30)
+#define APE_TAG_FLAG_IS_HEADER(1U << 29)
+#define APE_TAG_FLAG_IS_BINARY(1U << 1)

 static int ape_tag_read_field(AVFormatContext *s)
 {
-- 
2.21.0.392.gf8f6787159e-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Andreas Rheinhardt

Hello,

Gyan:
> 
> Patchwork can incorrectly assign ownership. See
> https://patchwork.ffmpeg.org/patch/12680/
> 
> The author is Sam John as identified by Message ID as well as the From
> field in the headers, yet Patchwork attributes this patch to "Oliver
> Collyer via ffmpeg-devel", a name which appears nowhere in the headers
> or in the submitted patch. The downloaded mbox patch shows the same
> wrong attribution. Does anyone know what's going on?
> 
> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

I just saw that I was affected by this: One of my commits
(18a851aca766ff8c7199c9e0c37d8fa642e41920) has a "via ffmpeg-devel"
author and the majority of patches attributed to Oliver Collyer via
ffmpeg-devel on patchwork are actually from me. I have now found out
that gmail.com and googlemail.com -- despite behaving as aliases in
lots of ways -- actually have different DMARC policies:
v=DMARC1; p=none; sp=quarantine;
rua=mailto:mailauth-repo...@google.com for gmail.com vs. v=DMARC1;
p=quarantine; sp=quarantine; rua=mailto:mailauth-repo...@google.com
for googlemail.com and have therefore switched my account to
gmail.com. Will hopefully work fine now. But now I am unsure whether I
should resend my patchsets?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] web/security: fix typos

2019-04-18 Thread Michael Niedermayer

On Wed, Apr 17, 2019 at 10:37:02PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  src/security | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply patchset

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]tests: Add EXESUF to program calls

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 3:39 GMT+02:00, Carl Eugen Hoyos :

> Attached patch fixes fate on Windows subsystem for Linux here.

Patch applied.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 23:17 GMT+02:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_aupsample.c | 159 +
>  libavfilter/allfilters.c   |   1 +
>  3 files changed, 161 insertions(+)
>  create mode 100644 libavfilter/af_aupsample.c
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 682df45ef5..a38bc35231 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -86,6 +86,7 @@ OBJS-$(CONFIG_ASTATS_FILTER) +=
> af_astats.o
>  OBJS-$(CONFIG_ASTREAMSELECT_FILTER)  += f_streamselect.o
> framesync.o
>  OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
>  OBJS-$(CONFIG_ATRIM_FILTER)  += trim.o
> +OBJS-$(CONFIG_AUPSAMPLE_FILTER)  += af_aupsample.o
>  OBJS-$(CONFIG_AZMQ_FILTER)   += f_zmq.o
>  OBJS-$(CONFIG_BANDPASS_FILTER)   += af_biquads.o
>  OBJS-$(CONFIG_BANDREJECT_FILTER) += af_biquads.o
> diff --git a/libavfilter/af_aupsample.c b/libavfilter/af_aupsample.c
> new file mode 100644
> index 00..ee35b9c0c6
> --- /dev/null
> +++ b/libavfilter/af_aupsample.c
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright (c) 2019 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/opt.h"
> +#include "libavutil/samplefmt.h"
> +#include "avfilter.h"
> +#include "audio.h"
> +#include "filters.h"
> +#include "internal.h"
> +
> +typedef struct AudioUpSampleContext {
> +const AVClass *class;
> +int factor;
> +
> +int64_t next_pts;
> +} AudioUpSampleContext;
> +
> +#define OFFSET(x) offsetof(AudioUpSampleContext, x)
> +#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +static const AVOption aupsample_options[] = {
> +{ "factor", "set upsampling factor", OFFSET(factor), AV_OPT_TYPE_INT,
> {.i64=1}, 1, 64, A },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(aupsample);
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +AudioUpSampleContext *s = ctx->priv;
> +AVFilterChannelLayouts *layouts;
> +AVFilterFormats *formats;
> +int sample_rates[] = { 44100, -1 };
> +static const enum AVSampleFormat sample_fmts[] = {
> +AV_SAMPLE_FMT_DBLP,
> +AV_SAMPLE_FMT_NONE
> +};
> +AVFilterFormats *avff;
> +int ret;
> +
> +if (!ctx->inputs[0]->in_samplerates ||
> +!ctx->inputs[0]->in_samplerates->nb_formats) {
> +return AVERROR(EAGAIN);
> +}
> +
> +layouts = ff_all_channel_counts();
> +if (!layouts)
> +return AVERROR(ENOMEM);
> +ret = ff_set_common_channel_layouts(ctx, layouts);
> +if (ret < 0)
> +return ret;
> +
> +formats = ff_make_format_list(sample_fmts);
> +if (!formats)
> +return AVERROR(ENOMEM);
> +ret = ff_set_common_formats(ctx, formats);
> +if (ret < 0)
> +return ret;
> +
> +avff = ctx->inputs[0]->in_samplerates;
> +sample_rates[0] = avff->formats[0];
> +if (!ctx->inputs[0]->out_samplerates)
> +if ((ret = ff_formats_ref(ff_make_format_list(sample_rates),
> +  >inputs[0]->out_samplerates)) < 0)
> +return ret;
> +
> +sample_rates[0] = avff->formats[0] * s->factor;
> +return ff_formats_ref(ff_make_format_list(sample_rates),
> + >outputs[0]->in_samplerates);
> +}
> +
> +static int config_input(AVFilterLink *inlink)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +AudioUpSampleContext *s = ctx->priv;
> +
> +s->next_pts = AV_NOPTS_VALUE;
> +
> +return 0;
> +}
> +
> +static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +AVFilterLink *outlink = ctx->outputs[0];
> +AudioUpSampleContext *s = ctx->priv;
> +const int factor = s->factor;
> +AVFrame *out;
> +
> +if (s->factor == 1)
> +return ff_filter_frame(outlink, in);
> +
> +out = ff_get_audio_buffer(outlink, in->nb_samples * s->factor);
> +if (!out) {
> +av_frame_free();
> +return AVERROR(ENOMEM);
> +}
> +
> +if (s->next_pts == AV_NOPTS_VALUE)
> +s->next_pts = in->pts;
> +
> +for (int c =

[FFmpeg-devel] [PATCH]configure: Fix libmfx detection

2019-04-18 Thread Carl Eugen Hoyos

Hi!

I needed attached patch to use libmfx.

Please comment, Carl Eugen
From 46bde1c4c314a5aad30632a18ae81a5dd8174722 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 19 Apr 2019 01:03:22 +0200
Subject: [PATCH] configure: Fix libmfx detection.

---
 configure |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index e10e2c2..cacefb1 100755
--- a/configure
+++ b/configure
@@ -6160,7 +6160,7 @@ enabled liblensfun&& require_pkg_config liblensfun lensfun lensfun.h lf_
 # pkg-config support.  Instead, users should make sure that the build
 # can find the libraries and headers through other means.
 enabled libmfx&& { check_pkg_config libmfx libmfx "mfx/mfxvideo.h" MFXInit ||
-   { require libmfx "mfx/mfxvideo.h" MFXInit "-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
+   { require libmfx "mfx/mfxvideo.h" MFXInit "-lmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
 enabled libmodplug&& require_pkg_config libmodplug libmodplug libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame $libm_extralibs
 enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h mysofa_load ||
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Lou Logan

On Thu, Apr 18, 2019, at 1:25 PM, Hendrik Leppkes wrote:
>
> Did you try the "wrap" option? As I understand it, it would preserve
> the original mail entirely, and rely on the mail client of the
> recipient (ie. us) to properly unwrap the MIME container.
> We've had various problems of authorship in patches getting mangled by
> this, so if that could prevent it, that would be useful.

I did not. At the time it seemed more problematic than munge, but I did not 
foresee the patchwork issue with munge.

But we can certainly give it a try if you like. I'm not sure how patchwork will 
handle it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] v210dec checkasm test and avx2 function

2019-04-18 Thread Paul B Mahol

On 4/18/19, James Darnley  wrote:
> On 2019-04-10 14:47, James Darnley wrote:
>> I am resending this my patches because I am not sure if I sent this
>> version in
>> the past.  I split my changes into two patches because they do separate
>> things.
>>
>> I also changed some tabs to spaces in Mike's AVX2 patch.
>>
>> James Darnley (2):
>>   avcodec/v210dec: move DSP function setting into dedicated function
>>   checkasm: add test for v210dec
>>
>> Michael Stoner (1):
>>   libavcodec Adding ff_v210_planar_unpack AVX2
>>
>>  libavcodec/v210dec.c   | 26 +
>>  libavcodec/v210dec.h   |  1 +
>>  libavcodec/x86/v210-init.c |  8 
>>  libavcodec/x86/v210.asm| 72 +++
>>  tests/checkasm/Makefile|  1 +
>>  tests/checkasm/checkasm.c  |  3 ++
>>  tests/checkasm/checkasm.h  |  1 +
>>  tests/checkasm/v210dec.c   | 77 ++
>>  8 files changed, 166 insertions(+), 23 deletions(-)
>>  create mode 100644 tests/checkasm/v210dec.c
>>
>
> Any objections to this patchset?  I have corrected the address of
> Michael's patch to the address I Cced.  I hope that the right one.


Just apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Hendrik Leppkes

On Thu, Apr 18, 2019 at 9:04 PM Lou Logan  wrote:
>
> On Thu, Apr 18, 2019, at 4:51 AM, Hendrik Leppkes wrote:
> >
> > Whoever setup this ML sender rewriting thing should probably look into
> > options to also re-write the patch content and add a "From:" line in
> > there with the original name and email to avoid issues.
>
> I enabled this due DMARC as Timo correctly pointed out. This was due to the 
> seemingly increasing number of rejected/bounced messages from certain domains 
> resulting in the recipient being automatically unsubscribed from the list. I 
> changed this relatively recently (last month?). I was unaware of the 
> patchwork issue.
>
> This was implemented with the "dmarc_moderation_action" option within 
> Mailman. It is currently set to "Munge from" and was previously set to 
> "Accept". More info:
>
> https://wiki.list.org/DEV/DMARC
>

Did you try the "wrap" option? As I understand it, it would preserve
the original mail entirely, and rely on the mail client of the
recipient (ie. us) to properly unwrap the MIME container.
We've had various problems of authorship in patches getting mangled by
this, so if that could prevent it, that would be useful.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Michael Niedermayer

On Thu, Apr 18, 2019 at 03:03:44PM -0400, Lou Logan wrote:
> On Thu, Apr 18, 2019, at 4:51 AM, Hendrik Leppkes wrote:
> >
> > Whoever setup this ML sender rewriting thing should probably look into
> > options to also re-write the patch content and add a "From:" line in
> > there with the original name and email to avoid issues.
> 
> I enabled this due DMARC as Timo correctly pointed out. This was due to the 
> seemingly increasing number of rejected/bounced messages from certain domains 
> resulting in the recipient being automatically unsubscribed from the list. I 
> changed this relatively recently (last month?). I was unaware of the 
> patchwork issue.
> 
> This was implemented with the "dmarc_moderation_action" option within 
> Mailman. It is currently set to "Munge from" and was previously set to 
> "Accept". More info:
> 
> https://wiki.list.org/DEV/DMARC
> 

> There is no perfect solution to the DMARC situation as far as I know.

There may be, but not trivial
0. Understand the problem
-> This appears that DMARC ignored the mailing list use case
1. decide on a way to do mailing lists in DMARC
2. get the RFCs updated
3. get the implementations updated

OR
1. decide on a way to do mailing lists around DMARC
2. write a spec
3. update relevant implementations to follow this spec

For example, one way that would mitigate the issue would be to
A. include the original "FROM:" in a new header or something (patch in mailman)
B. have the receiving side detect subscribed mailing lists do a maxumum of
   validity checks and undo the FROM change (patch in git, patchwork, MUAs or
   some other component that can undo the mess)

Iam sure there are issues and its more complex than this, but i dont think
it has to be as bad as it is currently if theres some crazy volunteer.

PS: also i did not look into existing efforts to resolve this, so quite
likely others have spend much more time on this and have found more
thought through redesigns ... I primarly just think that there is
some way that is better than what has to be done currently ...

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] rtsp: add pkt_size option

2019-04-18 Thread Tristan Matthews

On Mon, Apr 15, 2019 at 6:50 PM Tristan Matthews  wrote:
>
> This allows users to specify an upper limit on the size of outgoing packets
> when publishing via RTSP.
>
> Signed-off-by: Martin Storsjö 
> ---
>  libavformat/rtsp.c | 5 -
>  libavformat/rtsp.h | 1 +
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 8349840c96..c153cac88b 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -76,7 +76,8 @@
>
>  #define COMMON_OPTS() \
>  { "reorder_queue_size", "set number of packets to buffer for handling of 
> reordered packets", OFFSET(reordering_queue_size), AV_OPT_TYPE_INT, { .i64 = 
> -1 }, -1, INT_MAX, DEC }, \
> -{ "buffer_size","Underlying protocol send/receive buffer size",  
> OFFSET(buffer_size),   AV_OPT_TYPE_INT, { .i64 = -1 
> }, -1, INT_MAX, DEC|ENC } \
> +{ "buffer_size","Underlying protocol send/receive buffer size",  
> OFFSET(buffer_size),   AV_OPT_TYPE_INT, { .i64 = -1 
> }, -1, INT_MAX, DEC|ENC }, \
> +{ "pkt_size",   "Underlying protocol send packet size",  
> OFFSET(pkt_size),  AV_OPT_TYPE_INT, { .i64 = -1 
> }, -1, INT_MAX, ENC } \
>
>
>  const AVOption ff_rtsp_options[] = {
> @@ -132,6 +133,8 @@ static AVDictionary *map_to_opts(RTSPState *rt)
>
>  snprintf(buf, sizeof(buf), "%d", rt->buffer_size);
>  av_dict_set(, "buffer_size", buf, 0);
> +snprintf(buf, sizeof(buf), "%d", rt->pkt_size);
> +av_dict_set(, "pkt_size", buf, 0);
>
>  return opts;
>  }
> diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> index b49278fc20..54a9a30c16 100644
> --- a/libavformat/rtsp.h
> +++ b/libavformat/rtsp.h
> @@ -410,6 +410,7 @@ typedef struct RTSPState {
>
>  char default_lang[4];
>  int buffer_size;
> +int pkt_size;
>  } RTSPState;
>
>  #define RTSP_FLAG_FILTER_SRC  0x1/**< Filter incoming UDP packets -
> --
> 2.17.1
>

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] avfilter: add audio downsample filter

2019-04-18 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  15 +++
 libavfilter/Makefile |   1 +
 libavfilter/af_adownsample.c | 171 +++
 libavfilter/allfilters.c |   1 +
 4 files changed, 188 insertions(+)
 create mode 100644 libavfilter/af_adownsample.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 465eeb4732..d6aac5730d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -714,6 +714,21 @@ Compute derivative/integral of audio stream.
 
 Applying both filters one after another produces original audio.
 
+@section adownsample, aupsample
+Downsample or upsample audio by integer factor.
+
+For downsampling only the first out of each factor samples is retained,
+the others are discarded
+For upsampling, factor-1 zero-value samples are inserted between each pair of 
input samples.
+As a result, the original spectrum is replicated into the new frequency space 
and attenuated.
+
+A description of the accepted parameters follows.
+
+@table @option
+@item factor
+Set factor of downsampling/upsampling. Default is @code{1}.
+@end table
+
 @section aecho
 
 Apply echoing to the input audio.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a38bc35231..ed36454f9e 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -43,6 +43,7 @@ OBJS-$(CONFIG_ADECLICK_FILTER)   += af_adeclick.o
 OBJS-$(CONFIG_ADECLIP_FILTER)+= af_adeclick.o
 OBJS-$(CONFIG_ADELAY_FILTER) += af_adelay.o
 OBJS-$(CONFIG_ADERIVATIVE_FILTER)+= af_aderivative.o
+OBJS-$(CONFIG_ADOWNSAMPLE_FILTER)+= af_adownsample.o
 OBJS-$(CONFIG_AECHO_FILTER)  += af_aecho.o
 OBJS-$(CONFIG_AEMPHASIS_FILTER)  += af_aemphasis.o
 OBJS-$(CONFIG_AEVAL_FILTER)  += aeval.o
diff --git a/libavfilter/af_adownsample.c b/libavfilter/af_adownsample.c
new file mode 100644
index 00..1ee661e383
--- /dev/null
+++ b/libavfilter/af_adownsample.c
@@ -0,0 +1,171 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/samplefmt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "filters.h"
+#include "internal.h"
+
+typedef struct AudioDownSampleContext {
+const AVClass *class;
+int factor;
+
+int64_t next_pts;
+} AudioDownSampleContext;
+
+#define OFFSET(x) offsetof(AudioDownSampleContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption adownsample_options[] = {
+{ "factor", "set downsampling factor", OFFSET(factor), AV_OPT_TYPE_INT, 
{.i64=1}, 1, 64, A },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(adownsample);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AudioDownSampleContext *s = ctx->priv;
+AVFilterChannelLayouts *layouts;
+AVFilterFormats *formats;
+int sample_rates[] = { 44100, -1 };
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_DBLP,
+AV_SAMPLE_FMT_NONE
+};
+AVFilterFormats *avff;
+int ret;
+
+if (!ctx->inputs[0]->in_samplerates ||
+!ctx->inputs[0]->in_samplerates->nb_formats) {
+return AVERROR(EAGAIN);
+}
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+avff = ctx->inputs[0]->in_samplerates;
+sample_rates[0] = avff->formats[0];
+if (!ctx->inputs[0]->out_samplerates)
+if ((ret = ff_formats_ref(ff_make_format_list(sample_rates),
+  >inputs[0]->out_samplerates)) < 0)
+return ret;
+
+sample_rates[0] = avff->formats[0] / s->factor;
+return ff_formats_ref(ff_make_format_list(sample_rates),
+ >outputs[0]->in_samplerates);
+}
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+AudioDownSampleContext *s = ctx->priv;
+
+s->next_pts = AV_NOPTS_VALUE;
+
+

[FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-18 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile   |   1 +
 libavfilter/af_aupsample.c | 159 +
 libavfilter/allfilters.c   |   1 +
 3 files changed, 161 insertions(+)
 create mode 100644 libavfilter/af_aupsample.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 682df45ef5..a38bc35231 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -86,6 +86,7 @@ OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
 OBJS-$(CONFIG_ASTREAMSELECT_FILTER)  += f_streamselect.o framesync.o
 OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
 OBJS-$(CONFIG_ATRIM_FILTER)  += trim.o
+OBJS-$(CONFIG_AUPSAMPLE_FILTER)  += af_aupsample.o
 OBJS-$(CONFIG_AZMQ_FILTER)   += f_zmq.o
 OBJS-$(CONFIG_BANDPASS_FILTER)   += af_biquads.o
 OBJS-$(CONFIG_BANDREJECT_FILTER) += af_biquads.o
diff --git a/libavfilter/af_aupsample.c b/libavfilter/af_aupsample.c
new file mode 100644
index 00..ee35b9c0c6
--- /dev/null
+++ b/libavfilter/af_aupsample.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/samplefmt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "filters.h"
+#include "internal.h"
+
+typedef struct AudioUpSampleContext {
+const AVClass *class;
+int factor;
+
+int64_t next_pts;
+} AudioUpSampleContext;
+
+#define OFFSET(x) offsetof(AudioUpSampleContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption aupsample_options[] = {
+{ "factor", "set upsampling factor", OFFSET(factor), AV_OPT_TYPE_INT, 
{.i64=1}, 1, 64, A },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(aupsample);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AudioUpSampleContext *s = ctx->priv;
+AVFilterChannelLayouts *layouts;
+AVFilterFormats *formats;
+int sample_rates[] = { 44100, -1 };
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_DBLP,
+AV_SAMPLE_FMT_NONE
+};
+AVFilterFormats *avff;
+int ret;
+
+if (!ctx->inputs[0]->in_samplerates ||
+!ctx->inputs[0]->in_samplerates->nb_formats) {
+return AVERROR(EAGAIN);
+}
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+avff = ctx->inputs[0]->in_samplerates;
+sample_rates[0] = avff->formats[0];
+if (!ctx->inputs[0]->out_samplerates)
+if ((ret = ff_formats_ref(ff_make_format_list(sample_rates),
+  >inputs[0]->out_samplerates)) < 0)
+return ret;
+
+sample_rates[0] = avff->formats[0] * s->factor;
+return ff_formats_ref(ff_make_format_list(sample_rates),
+ >outputs[0]->in_samplerates);
+}
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+AudioUpSampleContext *s = ctx->priv;
+
+s->next_pts = AV_NOPTS_VALUE;
+
+return 0;
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+AudioUpSampleContext *s = ctx->priv;
+const int factor = s->factor;
+AVFrame *out;
+
+if (s->factor == 1)
+return ff_filter_frame(outlink, in);
+
+out = ff_get_audio_buffer(outlink, in->nb_samples * s->factor);
+if (!out) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+
+if (s->next_pts == AV_NOPTS_VALUE)
+s->next_pts = in->pts;
+
+for (int c = 0; c < in->channels; c++) {
+const double *src = (const double *)in->extended_data[c];
+double *dst = (double *)out->extended_data[c];
+
+for (int n = 0; n < in->nb_samples; n++)
+dst[n*factor] = src[n];
+}
+
+out->pts = s->next_pts;
+s->next_pts += av_rescale_q(out->nb_samples,

[FFmpeg-devel] [PATCH 1/3] avfilter: add audio soft clip filter

2019-04-18 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  27 +
 libavfilter/Makefile   |   1 +
 libavfilter/af_asoftclip.c | 217 +
 libavfilter/allfilters.c   |   1 +
 4 files changed, 246 insertions(+)
 create mode 100644 libavfilter/af_asoftclip.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 4dd1a5de85..465eeb4732 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2104,6 +2104,33 @@ audio, the data is treated as if all the planes were 
concatenated.
 A list of Adler-32 checksums for each data plane.
 @end table
 
+@section asoftclip
+Apply audio soft clipping.
+
+Soft clipping is a type of distortion effect where the amplitude of a signal 
is saturated
+along a smooth curve, rather than the abrupt shape of hard-clipping.
+
+This filter accepts the following options:
+
+@table @option
+@item type
+Set type of soft-clipping.
+
+It accepts the following values:
+@table @option
+@item tanh
+@item atan
+@item cubic
+@item exp
+@item alg
+@item quintic
+@item sin
+@end table
+
+@item param
+Set additional parameter which controls sigmoid function.
+@end table
+
 @anchor{astats}
 @section astats
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..682df45ef5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -80,6 +80,7 @@ OBJS-$(CONFIG_ASETRATE_FILTER)   += af_asetrate.o
 OBJS-$(CONFIG_ASETTB_FILTER) += settb.o
 OBJS-$(CONFIG_ASHOWINFO_FILTER)  += af_ashowinfo.o
 OBJS-$(CONFIG_ASIDEDATA_FILTER)  += f_sidedata.o
+OBJS-$(CONFIG_ASOFTCLIP_FILTER)  += af_asoftclip.o
 OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
 OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
 OBJS-$(CONFIG_ASTREAMSELECT_FILTER)  += f_streamselect.o framesync.o
diff --git a/libavfilter/af_asoftclip.c b/libavfilter/af_asoftclip.c
new file mode 100644
index 00..239b1d6a6b
--- /dev/null
+++ b/libavfilter/af_asoftclip.c
@@ -0,0 +1,217 @@
+/*
+ * Copyright (c) 2019 The FFmpeg Project
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+enum ASoftClipTypes {
+ASC_TANH,
+ASC_ATAN,
+ASC_CUBIC,
+ASC_EXP,
+ASC_ALG,
+ASC_QUINTIC,
+ASC_SIN,
+NB_TYPES,
+};
+
+typedef struct ASoftClipContext {
+const AVClass *class;
+
+int type;
+double param;
+
+void (*filter)(struct ASoftClipContext *s, void **dst, const void **src,
+   int nb_samples, int channels);
+} ASoftClipContext;
+
+#define OFFSET(x) offsetof(ASoftClipContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption asoftclip_options[] = {
+{ "type", "set softclip type", OFFSET(type), AV_OPT_TYPE_INT,{.i64=0}, 
 0, NB_TYPES-1, A, "types" },
+{ "tanh",NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_TANH},   0,  0, A, "types" },
+{ "atan",NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_ATAN},   0,  0, A, "types" },
+{ "cubic",   NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_CUBIC},  0,  0, A, "types" },
+{ "exp", NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_EXP},0,  0, A, "types" },
+{ "alg", NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_ALG},0,  0, A, "types" },
+{ "quintic", NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_QUINTIC},0,  0, A, "types" },
+{ "sin", NULL,0, AV_OPT_TYPE_CONST,  
{.i64=ASC_SIN},0,  0, A, "types" },
+{ "param", "set softclip parameter", OFFSET(param), AV_OPT_TYPE_DOUBLE, 
{.dbl=1}, 0.01,3, A },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(asoftclip);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layouts = NULL;
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_DBLP,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+formats = ff_make_format_list(sample_fmts);
+

Re: [FFmpeg-devel] [PATCH] libavformat: improve logs with cur_dts

2019-04-18 Thread Michael Niedermayer

On Thu, Apr 18, 2019 at 07:46:43AM +, Andreas Håkon via ffmpeg-devel wrote:
> Hi,
> 
> This is the second part of my previous patch:
> https://patchwork.ffmpeg.org/patch/12783/
> 
> It improves the logs when the message "cur_dts is invalid" appears.
> If helps to identify which stream generates the trouble,
> and the status of the stream.
> A lot of users suffers with the message, and the origin varies.
> The improved message can help to discover the cause.
> 
> Regards.
> A.H.

> From af81338c21c67c0ef2c30ab2009c7094b32327f4 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andreas=20H=C3=A5kon?= 
> Date: Wed, 17 Apr 2019 21:22:43 +0100
> Subject: [PATCH] libavformat: input init fix mpegts filters

"git am" doesnt accept this patch

Applying: libavformat: input init fix mpegts filters
Using index info to reconstruct a base tree...
error: patch failed: libavformat/utils.c:1402
error: libavformat/utils.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0001 libavformat: input init fix mpegts filters
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Michael Niedermayer

On Thu, Apr 18, 2019 at 11:18:13AM +, Andreas Håkon via ffmpeg-devel wrote:
> 
> 
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 18 de April de 2019 13:14, Andreas Håkon 
>  wrote:
> 
> > > On Wed, Apr 17, 2019 at 08:28:39PM +, Andreas Håkon via ffmpeg-devel 
> > > wrote:
> > >
> > > > This patch solves the initialization of the inputs when using filters 
> > > > (a graph filter) with the mpegts muxer.
> > > > This bug seems to be generated by a simple forgetting to copy. The same 
> > > > code is repeated two times, but only in one case the variable 
> > > > “inputs_done” is initialized. Compare the two blocks:
> > >
> > > This text should be in the commit message.
> > > also a testcase would be usefull, a fate test even better
> >
> > Done!
> >
> > Regards.
> > A.H.
> >
> 
> Hi Michael,
> 
> Your request is now here:
> https://patchwork.ffmpeg.org/patch/12794/
> 
> Mark as superseded both:
> https://patchwork.ffmpeg.org/patch/12783/
> https://patchwork.ffmpeg.org/patch/12790/

better to automate such things, human time is limited
if you want you could send a patch to:
https://github.com/michaelni/patchwork-update-bot
so that split patches are detected and the parent superseded

thx

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Michael Niedermayer

On Thu, Apr 18, 2019 at 11:14:39AM +, Andreas Håkon via ffmpeg-devel wrote:
> 
> > On Wed, Apr 17, 2019 at 08:28:39PM +, Andreas Håkon via ffmpeg-devel 
> > wrote:
> >
> > > This patch solves the initialization of the inputs when using filters (a 
> > > graph filter) with the mpegts muxer.
> > > This bug seems to be generated by a simple forgetting to copy. The same 
> > > code is repeated two times, but only in one case the variable 
> > > “inputs_done” is initialized. Compare the two blocks:
> >
> > This text should be in the commit message.
> > also a testcase would be usefull, a fate test even better
> >
> 
> Done!
> 
> Regards.
> A.H.
> 
> 
> ---
> 

> From af81338c21c67c0ef2c30ab2009c7094b32327f4 Mon Sep 17 00:00:00 2001
> From: Andreas Hakon 
> Date: Wed, 17 Apr 2019 21:22:43 +0100
> Subject: [PATCH] libavformat: input init fix mpegts filters

fails to apply cleanly

Applying: libavformat: fix inputs initialization in mpegts muxer with filters
Using index info to reconstruct a base tree...
error: patch failed: fftools/ffmpeg.c:4613
error: fftools/ffmpeg.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0001 libavformat: fix inputs initialization in mpegts muxer 
with filters

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/colorspace: add macros for RGB->YUV BT.709

2019-04-18 Thread Gyan




On 17-04-2019 11:30 PM, Gyan wrote:



On 17-04-2019 11:11 PM, Vittorio Giovara wrote:

On Wed, Apr 17, 2019 at 12:26 AM Gyan  wrote:



On 13-04-2019 05:23 PM, Gyan wrote:

Will be helpful for correct result in filters that paint like
fillborders/drawbox or those using drawutils.

Ping.


these seem to only work for 8 bit content, is that their only intended
usecase?
if so, could there be at least a comment mentioning that please?
Yes, the existing macros use Rec.601 co-efficients, but most data is 
709 now.

Will add a note.


With note.
From 5443848d974e98f05b5601e9f1f0d0fd54aa54b8 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sat, 13 Apr 2019 17:01:09 +0530
Subject: [PATCH v2] avutil/colorspace: add macros for RGB->YUV BT.709

---
 libavutil/colorspace.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/libavutil/colorspace.h b/libavutil/colorspace.h
index d0be8cb99a..ef6f6107d6 100644
--- a/libavutil/colorspace.h
+++ b/libavutil/colorspace.h
@@ -119,4 +119,32 @@ static inline int C_JPEG_TO_CCIR(int y) {
 (((FIX(0.5) * r1 - FIX(0.41869) * g1 - \
FIX(0.08131) * b1 + (ONE_HALF) - 1) >> (SCALEBITS)) + 128)
 
+// Conversion macros for 8-bit RGB to YUV
+// Derived from ITU-R BT.709-6 (06/2015) Item 3.5
+// https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en
+
+#define RGB_TO_Y_BT709(r, g, b) \
+((FIX(0.21260*219.0/255.0) * (r) + FIX(0.71520*219.0/255.0) * (g) + \
+  FIX(0.07220*219.0/255.0) * (b) + (ONE_HALF + (16 << SCALEBITS))) >> 
SCALEBITS)
+
+#define RGB_TO_U_BT709(r1, g1, b1, shift)\
+(((- FIX(0.11457*224.0/255.0) * r1 - FIX(0.38543*224.0/255.0) * g1 + \
+ FIX(0.5*224.0/255.0) * b1 + (ONE_HALF << shift) - 1) >> (SCALEBITS + 
shift)) + 128)
+
+#define RGB_TO_V_BT709(r1, g1, b1, shift)\
+(((FIX(0.5*224.0/255.0) * r1 - FIX(0.45415*224.0/255.0) * g1 -   \
+   FIX(0.04585*224.0/255.0) * b1 + (ONE_HALF << shift) - 1) >> (SCALEBITS + 
shift)) + 128)
+
+#define RGB_TO_Y_BT709_FULL(r, g, b) \
+(FFMIN((FIX(0.21260) * (r) + FIX(0.71520) * (g) + \
+  FIX(0.07220) * (b) + (ONE_HALF)) >> SCALEBITS, 255))
+
+#define RGB_TO_U_BT709_FULL(r1, g1, b1)\
+(((- FIX(0.11457) * r1 - FIX(0.38543) * g1 + \
+ FIX(0.5) * b1 + (ONE_HALF) - 1) >> (SCALEBITS)) + 128)
+
+#define RGB_TO_V_BT709_FULL(r1, g1, b1)\
+(((FIX(0.5) * r1 - FIX(0.45415) * g1 - \
+   FIX(0.04585) * b1 + (ONE_HALF) - 1) >> (SCALEBITS)) + 128)
+
 #endif /* AVUTIL_COLORSPACE_H */
-- 
2.21.0___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [OT] Patchwork attribution

2019-04-18 Thread Lou Logan

On Thu, Apr 18, 2019, at 11:09 AM, Nicolas George wrote:
>
> In my not-so-humble opinion, mailing-list operators should have refused
> these bad compromises. "Sorry, you cannot use mailing-lists with
> $operator, that is not our fault, they broke it on purpose."

The mail admin on the other side probably applied the same reasoning before 
enabling their reject policy.

Go through the archives and look at how many potential contributions we may 
have missed out on if we add more barriers due to being hardasses. Most users 
of services that have a reject DMARC policy probably don't know about that, it 
may be out of their control, and they may not have a choice of which address 
they send from.

We are an open project, so we should be strive to be open to contributions 
despite the bad decisions of other mail admins.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [OT] Patchwork attribution

2019-04-18 Thread Nicolas George

Lou Logan (12019-04-18):
> I enabled this due DMARC as Timo correctly pointed out. This was due
> to the seemingly increasing number of rejected/bounced messages from
> certain domains resulting in the recipient being automatically
> unsubscribed from the list. I changed this relatively recently (last
> month?). I was unaware of the patchwork issue.

In my not-so-humble opinion, mailing-list operators should have refused
these bad compromises. "Sorry, you cannot use mailing-lists with
$operator, that is not our fault, they broke it on purpose."

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Lou Logan

On Thu, Apr 18, 2019, at 4:51 AM, Hendrik Leppkes wrote:
>
> Whoever setup this ML sender rewriting thing should probably look into
> options to also re-write the patch content and add a "From:" line in
> there with the original name and email to avoid issues.

I enabled this due DMARC as Timo correctly pointed out. This was due to the 
seemingly increasing number of rejected/bounced messages from certain domains 
resulting in the recipient being automatically unsubscribed from the list. I 
changed this relatively recently (last month?). I was unaware of the patchwork 
issue.

This was implemented with the "dmarc_moderation_action" option within Mailman. 
It is currently set to "Munge from" and was previously set to "Accept". More 
info:

https://wiki.list.org/DEV/DMARC

There is no perfect solution to the DMARC situation as far as I know.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] add tests/ref/fate/hls-segment-size for the fate test

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 17:44 GMT+02:00, Paul B Mahol :
> On 4/18/19, Carl Eugen Hoyos  wrote:
>> 2019-04-18 4:33 GMT+02:00, Steven Liu :
>>> Signed-off-by: Steven Liu 
>>> ---
>>>  tests/ref/fate/hls-segment-size | 772
>>> 
>>>  1 file changed, 772 insertions(+)
>>>  create mode 100644 tests/ref/fate/hls-segment-size
>>>
>>> diff --git a/tests/ref/fate/hls-segment-size
>>> b/tests/ref/fate/hls-segment-size
>>> new file mode 100644
>>> index 00..ee3c7b2c62
>>> --- /dev/null
>>> +++ b/tests/ref/fate/hls-segment-size
>>> @@ -0,0 +1,772 @@
>>
>> Why are you sending this patch?
>
> http://fate.ffmpeg.org/

http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242754.html

... instead of pushing it.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] add tests/ref/fate/hls-segment-size for the fate test

2019-04-18 Thread Paul B Mahol

On 4/18/19, Carl Eugen Hoyos  wrote:
> 2019-04-18 4:33 GMT+02:00, Steven Liu :
>> Signed-off-by: Steven Liu 
>> ---
>>  tests/ref/fate/hls-segment-size | 772
>> 
>>  1 file changed, 772 insertions(+)
>>  create mode 100644 tests/ref/fate/hls-segment-size
>>
>> diff --git a/tests/ref/fate/hls-segment-size
>> b/tests/ref/fate/hls-segment-size
>> new file mode 100644
>> index 00..ee3c7b2c62
>> --- /dev/null
>> +++ b/tests/ref/fate/hls-segment-size
>> @@ -0,0 +1,772 @@
>
> Why are you sending this patch?

http://fate.ffmpeg.org/


>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] add tests/ref/fate/hls-segment-size for the fate test

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 4:33 GMT+02:00, Steven Liu :
> Signed-off-by: Steven Liu 
> ---
>  tests/ref/fate/hls-segment-size | 772
> 
>  1 file changed, 772 insertions(+)
>  create mode 100644 tests/ref/fate/hls-segment-size
>
> diff --git a/tests/ref/fate/hls-segment-size
> b/tests/ref/fate/hls-segment-size
> new file mode 100644
> index 00..ee3c7b2c62
> --- /dev/null
> +++ b/tests/ref/fate/hls-segment-size
> @@ -0,0 +1,772 @@

Why are you sending this patch?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] v210dec checkasm test and avx2 function

2019-04-18 Thread James Darnley

On 2019-04-10 14:47, James Darnley wrote:
> I am resending this my patches because I am not sure if I sent this version in
> the past.  I split my changes into two patches because they do separate 
> things.
> 
> I also changed some tabs to spaces in Mike's AVX2 patch.
> 
> James Darnley (2):
>   avcodec/v210dec: move DSP function setting into dedicated function
>   checkasm: add test for v210dec
> 
> Michael Stoner (1):
>   libavcodec Adding ff_v210_planar_unpack AVX2
> 
>  libavcodec/v210dec.c   | 26 +
>  libavcodec/v210dec.h   |  1 +
>  libavcodec/x86/v210-init.c |  8 
>  libavcodec/x86/v210.asm| 72 +++
>  tests/checkasm/Makefile|  1 +
>  tests/checkasm/checkasm.c  |  3 ++
>  tests/checkasm/checkasm.h  |  1 +
>  tests/checkasm/v210dec.c   | 77 ++
>  8 files changed, 166 insertions(+), 23 deletions(-)
>  create mode 100644 tests/checkasm/v210dec.c
> 

Any objections to this patchset?  I have corrected the address of
Michael's patch to the address I Cced.  I hope that the right one.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/alac: Make a variable unsigned

2019-04-18 Thread Lauri Kasanen

On Thu, 18 Apr 2019 15:07:03 +0200
Hendrik Leppkes  wrote:

> On Thu, Apr 18, 2019 at 2:54 PM Lauri Kasanen  wrote:
> >
> > On Thu, 18 Apr 2019 13:53:37 +0200
> > Carl Eugen Hoyos  wrote:
> >
> > > Hi!
> > >
> > > Attached patch silences a warning that is shown with some gcc versions.
> >
> > It pokes my style sense to have different things in the sizeof() and
> > the var. How about uint32_t in both?
> >
>
> Those two things are entirely unrelated types, though.

Indeed, my bad. Please ignore.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Gyan




On 18-04-2019 07:03 PM, Hendrik Leppkes wrote:

On Thu, Apr 18, 2019 at 3:31 PM Gyan  wrote:



On 18-04-2019 06:13 PM, Hendrik Leppkes wrote:


All of those patches with re-written senders are send from the same
email, ffmpeg-devel@ffmpeg.org
Presumably patchwork only sends the email itself, not the name, and as
such assumes this is the same person.


In git master of patchwork, I see that if a different name is provided
for the same email, this new name is updated in the Person db object and
used.

See
https://github.com/getpatchwork/patchwork/blob/c4eca471a4a2cc3a2438e3ee6061df8988a251a6/patchwork/parser.py#L365

Introduced in v2.1.1. Which version are we using?


This is still not tracked on a per-patch basis, but one global name
per email address, so it wouldn't really solve anything. It just
changes from first person to send a patch to latest person to do so -
altering all previously send patches as well.


Unfortunate. Need to be vigilant about patch headers now.

Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Hendrik Leppkes

On Thu, Apr 18, 2019 at 3:31 PM Gyan  wrote:
>
>
>
> On 18-04-2019 06:13 PM, Hendrik Leppkes wrote:
> > On Thu, Apr 18, 2019 at 12:41 PM Gyan  wrote:
> >> Ok.  Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author?
> >> It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly
> >> substituted here.
> >> This looks like a parser failure in Patchwork.
> >>
> > All of those patches with re-written senders are send from the same
> > email, ffmpeg-devel@ffmpeg.org
> > Presumably patchwork only sends the email itself, not the name, and as
> > such assumes this is the same person.
> >
>
> In git master of patchwork, I see that if a different name is provided
> for the same email, this new name is updated in the Person db object and
> used.
>
> See
> https://github.com/getpatchwork/patchwork/blob/c4eca471a4a2cc3a2438e3ee6061df8988a251a6/patchwork/parser.py#L365
>
> Introduced in v2.1.1. Which version are we using?
>

This is still not tracked on a per-patch basis, but one global name
per email address, so it wouldn't really solve anything. It just
changes from first person to send a patch to latest person to do so -
altering all previously send patches as well.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Gyan




On 18-04-2019 06:13 PM, Hendrik Leppkes wrote:

On Thu, Apr 18, 2019 at 12:41 PM Gyan  wrote:

Ok.  Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author?
It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly
substituted here.
This looks like a parser failure in Patchwork.


All of those patches with re-written senders are send from the same
email, ffmpeg-devel@ffmpeg.org
Presumably patchwork only sends the email itself, not the name, and as
such assumes this is the same person.



In git master of patchwork, I see that if a different name is provided 
for the same email, this new name is updated in the Person db object and 
used.


See 
https://github.com/getpatchwork/patchwork/blob/c4eca471a4a2cc3a2438e3ee6061df8988a251a6/patchwork/parser.py#L365


Introduced in v2.1.1. Which version are we using?


Gyan


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/alac: Make a variable unsigned

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 14:54 GMT+02:00, Lauri Kasanen :
> On Thu, 18 Apr 2019 13:53:37 +0200
> Carl Eugen Hoyos  wrote:
>
>> Hi!
>>
>> Attached patch silences a warning that is shown with some gcc versions.
>
> It pokes my style sense to have different things in the sizeof() and
> the var. How about uint32_t in both?

I believe the sizeof() is an unrelated issue, I don't need 32 bit for the
size, just a variable size the system likes in the 64k range.

I wonder if the sizeof() isn't wrong, it looks wrong because
it uses a type instead of a variable.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/alac: Make a variable unsigned

2019-04-18 Thread Hendrik Leppkes

On Thu, Apr 18, 2019 at 2:54 PM Lauri Kasanen  wrote:
>
> On Thu, 18 Apr 2019 13:53:37 +0200
> Carl Eugen Hoyos  wrote:
>
> > Hi!
> >
> > Attached patch silences a warning that is shown with some gcc versions.
>
> It pokes my style sense to have different things in the sizeof() and
> the var. How about uint32_t in both?
>

Those two things are entirely unrelated types, though.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/alac: Make a variable unsigned

2019-04-18 Thread Lauri Kasanen

On Thu, 18 Apr 2019 13:53:37 +0200
Carl Eugen Hoyos  wrote:

> Hi!
>
> Attached patch silences a warning that is shown with some gcc versions.

It pokes my style sense to have different things in the sizeof() and
the var. How about uint32_t in both?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Hendrik Leppkes

On Thu, Apr 18, 2019 at 12:41 PM Gyan  wrote:
>
>
>
> On 18-04-2019 03:25 PM, Timo Rothenpieler wrote:
> > On 18/04/2019 09:49, Gyan wrote:
> >>
> >> Patchwork can incorrectly assign ownership. See
> >> https://patchwork.ffmpeg.org/patch/12680/
> >>
> >> The author is Sam John as identified by Message ID as well as the
> >> From field in the headers, yet Patchwork attributes this patch to
> >> "Oliver Collyer via ffmpeg-devel", a name which appears nowhere in
> >> the headers or in the submitted patch. The downloaded mbox patch
> >> shows the same wrong attribution. Does anyone know what's going on?
> >>
> >> Gyan
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> > This happens due to Mailman having to rewrite peoples E-Mail addresses
> > if they have strong DKIM/DMARC configured on their sending Domain.
> > If that is the case, only the server of the actual Domain who owns the
> > right private key can send E-Mails under the name of that Domain.
> >
> > So for mailing lists to be able to send on the messages, they are
> > forced to change the sender address.
> > In the case of this list:
> > Sam John 
> > gets translated to.
> > Sam John via ffmpeg-devel 
> >
>
> Ok.  Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author?
> It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly
> substituted here.
> This looks like a parser failure in Patchwork.
>

All of those patches with re-written senders are send from the same
email, ffmpeg-devel@ffmpeg.org
Presumably patchwork only sends the email itself, not the name, and as
such assumes this is the same person.

Whoever setup this ML sender rewriting thing should probably look into
options to also re-write the patch content and add a "From:" line in
there with the original name and email to avoid issues.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Timo Rothenpieler

Ok.  Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author? 
It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly 
substituted here.

This looks like a parser failure in Patchwork.

Gyan


If the patch is sent with git send-email, the From: header of the E-Mail 
is where git puts the Author. So patchwork has no chance to correct this.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] aacdec: use float_dsp in apply_independent_coupling

2019-04-18 Thread Paul B Mahol

On 4/12/19, Lynne  wrote:
> Could not be used in apply_dependent_coupling because of alignment issues.
>
>

Probably OK
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/utils: Allow url credentials to contain a slash

2019-04-18 Thread Carl Eugen Hoyos

2019-03-28 19:35 GMT+01:00, Carl Eugen Hoyos :

> Attached patch fixes ticket #7816 for me.

I will push this patch if there are no comments.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavfi/fspp: Add a cast to silence a clang warning

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 12:16 GMT+02:00, Michael Niedermayer :
> On Tue, Apr 16, 2019 at 12:55:03AM +0200, Carl Eugen Hoyos wrote:
>> 2019-04-14 1:02 GMT+02:00, Michael Niedermayer :
>> > On Sat, Apr 13, 2019 at 07:25:54PM -0300, James Almer wrote:
>> >> On 4/13/2019 7:04 PM, Carl Eugen Hoyos wrote:
>> >> > Hi!
>> >> >
>> >> > Attached patch silences two warnings shown when compiling with
>> >> > clang:
>> >> > libavfilter/vf_fspp.h:51:42: warning: implicit conversion from 'int'
>> >> > to 'int16_t' (aka 'short') changes value from 44130 to -21406
>> >> >
>> >> > Please comment, Carl Eugen
>> >> >
>> >> >
>> >> > 0001-lavfi-vf_fspp-Use-the-intended-cast-to-int16_t.patch
>> >> >
>> >> > From d731e523d9c5854183d20d37fe921f49fb048498 Mon Sep 17 00:00:00
>> >> > 2001
>> >> > From: Carl Eugen Hoyos 
>> >> > Date: Sat, 13 Apr 2019 23:05:44 +0200
>> >> > Subject: [PATCH] lavfi/fspp: Add two casts to int16_t.
>> >> >
>> >> > Silences a warning with clang:
>> >> > warning: implicit conversion from 'int' to 'int16_t' (aka 'short')
>> >> > changes value from 44130 to -21406
>> >> > ---
>> >> >  libavfilter/vf_fspp.h |2 +-
>> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
>> >> > index 74a3447..e346439 100644
>> >> > --- a/libavfilter/vf_fspp.h
>> >> > +++ b/libavfilter/vf_fspp.h
>> >> > @@ -31,7 +31,7 @@
>> >> >  #define DCTSIZE 8
>> >> >  #define DCTSIZE_S "8"
>> >> >
>> >> > -#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
>> >> > +#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5) &
>> >> > (int16_t)0x)
>> >>
>> >> The "& 0x" is turning -21406 into 44130 since it zeroes all the
>> >> high
>> >> bits, and then that value gets converted back to -21406 when stored
>> >> into
>> >> an int16_t variable.
>> >>
>> >> Change the int cast into int16_t if you want since it doesn't hurt
>> >> (all
>> >> the values are safely within the int16_t range anyway), but remove the
>> >> "& 0x" altogether instead of casting it, to get rid of this
>> >> warning.
>> >>
>> >> >  #define C64(x)((uint64_t)((x) | (x) << 16)) <<32 | (uint64_t)(x)
>> >> > |
>> >> > (uint64_t)(x) << 16
>> >> >  #define FIX64(x,s)  C64(FIX(x,s))
>> >
>> > i think the C64 / FIX64 macros depend on the & 0x. They are maybe
>> > unused
>> > and just referenced in comments but having them not give correct values
>> > could still be confusing. The 0x if its removed should be added to
>> > the
>> > code / comments that refer to it in a way that needs it
>>
>> New patch attached.
>> Not sure if / where to add comments.
>>
>> Please comment, Carl Eugen
>
>>  vf_fspp.h |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 17e468ee43988ef39d3ce882774dc3e2d625c9e6
>> 0001-lavfi-fspp-Cast-float-values-to-int16_t-instead-of-i.patch
>> From dfda9d8a6714649015f252e0e0bf5e3e52ce1b5c Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Tue, 16 Apr 2019 00:50:50 +0200
>> Subject: [PATCH] lavfi/fspp: Cast float values to int16_t instead of int.
>>
>> Silences a warning with clang:
>> warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes
>> value from 44130 to -21406
>> ---
>>  libavfilter/vf_fspp.h |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
>> index 802db14..bdafe8e 100644
>> --- a/libavfilter/vf_fspp.h
>> +++ b/libavfilter/vf_fspp.h
>> @@ -31,7 +31,7 @@
>>  #define DCTSIZE 8
>>  #define DCTSIZE_S "8"
>>
>> -#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
>> +#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5))
>
> does it need the cast at all to avoid the warning ?

Attached patch also avoids the warning.

Thank you, Carl Eugen
From 69c7f0894acccf64438198cd8d01a9f3e9765a95 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 18 Apr 2019 14:05:21 +0200
Subject: [PATCH] lavfi/fspp: Simplify a macro.

Silences a warning with clang:
warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406
---
 libavfilter/vf_fspp.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
index 802db14..73d8c7c 100644
--- a/libavfilter/vf_fspp.h
+++ b/libavfilter/vf_fspp.h
@@ -31,7 +31,7 @@
 #define DCTSIZE 8
 #define DCTSIZE_S "8"
 
-#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
+#define FIX(x,s)  ((x) * (1 << s) + 0.5)
 
 #define MULTIPLY16H(x,k)   (((x) * (k)) >> 16)
 #define THRESHOLD(r,x,t) \
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] apedec: add ability to check CRC

2019-04-18 Thread Lynne

Apr 9, 2019, 2:56 PM by d...@lynne.ee:

>
>
>
> Apr 7, 2019, 12:56 AM by > mich...@niedermayer.cc 
> > :
>
>> On Sat, Apr 06, 2019 at 10:44:00AM +0200, Lynne wrote:
>>
>>> Apr 4, 2019, 10:30 AM by >>> mich...@niedermayer.cc 
>>> >>
>>> > On Wed, Mar 06, 2019 at 02:47:37PM +0100, Lynne wrote:
>>> >
>>> >> 6 Mar 2019, 11:22 by >> >>> d...@lynne.ee >> >> >> d...@lynne.ee >> :
>>> >>
>>> >> > The CRC flag is only signalled once every few minutes but CRC is still
>>> >> > always present so the patch uses the file version instead.
>>> >> > CRC on 24-bit files wants non-padded samples so skip such files.
>>> >> > Some corrupt samples may have been output before the final check
>>> >> > depending on the -max_samples setting.
>>> >> >
>>> >> v2 attached
>>> >>
>>> >> apedec.c |   26 +-
>>> >>  1 file changed, 25 insertions(+), 1 deletion(-)
>>> >> c0cc550d77927ee0349094a4976f73d0ef671ff6  
>>> >> 0001-apedec-add-ability-to-check-CRC-v2.patch
>>> >> From 68c25bb026761eacda3c276148e2beb34e8929fd Mon Sep 17 00:00:00 2001
>>> >> From: Lynne <>> >>> d...@lynne.ee > 
>>> >> d...@lynne.ee >> >
>>> >> Date: Wed, 6 Mar 2019 11:01:01 +
>>> >> Subject: [PATCH v2] apedec: add ability to check CRC
>>> >>
>>> >> The CRC flag is only signalled once every few minutes but CRC is still
>>> >> always present so the patch uses the file version instead.
>>> >> CRC on 24-bit files wants non-padded samples so skip such files.
>>> >> Some corrupt samples may have been output before the final check
>>> >> depending on the -max_samples setting.
>>> >> ---
>>> >>  libavcodec/apedec.c | 26 +-
>>> >>  1 file changed, 25 insertions(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
>>> >> index 15eb416ba4..a20d884606 100644
>>> >> --- a/libavcodec/apedec.c
>>> >> +++ b/libavcodec/apedec.c
>>> >> @@ -24,6 +24,7 @@
>>> >> 
>>> >>  #include "libavutil/avassert.h"
>>> >>  #include "libavutil/channel_layout.h"
>>> >> +#include "libavutil/crc.h"
>>> >>  #include "libavutil/opt.h"
>>> >>  #include "lossless_audiodsp.h"
>>> >>  #include "avcodec.h"
>>> >> @@ -147,7 +148,8 @@ typedef struct APEContext {
>>> >>  int fset;///< which filter set to use 
>>> >> (calculated from compression level)
>>> >>  int flags;   ///< global decoder flags
>>> >> 
>>> >> -uint32_t CRC;///< frame CRC
>>> >> +uint32_t CRC;///< signalled frame CRC
>>> >> +uint32_t CRC_state;  ///< accumulated CRC
>>> >>  int frameflags;  ///< frame flags
>>> >>  APEPredictor predictor;  ///< predictor used for final 
>>> >> reconstruction
>>> >> 
>>> >> @@ -730,6 +732,7 @@ static int init_entropy_decoder(APEContext *ctx)
>>> >> 
>>> >>  /* Read the frame flags if they exist */
>>> >>  ctx->frameflags = 0;
>>> >> +ctx->CRC_state = UINT32_MAX;
>>> >>  if ((ctx->fileversion > 3820) && (ctx->CRC & 0x8000)) {
>>> >>  ctx->CRC &= ~0x8000;
>>> >> 
>>> >> @@ -1548,6 +1551,27 @@ static int ape_decode_frame(AVCodecContext 
>>> >> *avctx, void *data,
>>> >> 
>>> >>  s->samples -= blockstodecode;
>>> >> 
>>> >> +if ((avctx->err_recognition & AV_EF_CRCCHECK) &&
>>> >>
>>> >> +(s->fileversion >= 3900) && (s->bps < 24)) {
>>> >>
>>> >
>>> > what about file versions other than this ? do they have no crc ?
>>> >
>>> They have a different CRC version which is poorly documented.
>>>
>>>
>>> >
>>> > what about othet bps ?
>>> >
>>> 24 bit CRC needs to ignore the zeroes padding each sample in 32 bits. I 
>>> couldn't find any 24-bit files so I left that for a future patch.
>>>
>>
>> can such a file not be generated ? or
>> maybe printing a note and asking for a sample in this case would be an option
>> if noone has one either ...
>>
>
> I think skipping the check for such files is okay for now. Its just for 
> verification purposes after all, and not all decoders implement the option 
> but silently skip it.
>

Ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] aacdec: use float_dsp in apply_independent_coupling

2019-04-18 Thread Lynne

Apr 12, 2019, 10:55 PM by d...@lynne.ee:

> Could not be used in apply_dependent_coupling because of alignment issues.
>

Ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavu/hwcontext_d3d: Cast a pointer calling av_image_copy()

2019-04-18 Thread Carl Eugen Hoyos

Hi!

Attached patch silences several warnings when compiling for win32.

Please comment, Carl Eugen
From e9f39015d5796dbbd59565a99df54eff31dc885f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 18 Apr 2019 13:55:29 +0200
Subject: [PATCH] lavu/hwcontext_d3d: Cast a pointer calling av_image_copy().
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Silences several warnings:
libavutil/hwcontext_d3d11va.c:413:49: warning: passing argument 3 of ‘av_image_copy’ from incompatible pointer type
libavutil/hwcontext_d3d11va.c:425:47: warning: passing argument 3 of ‘av_image_copy’ from incompatible pointer type
libavutil/hwcontext_dxva2.c:351:45: warning: passing argument 3 of ‘av_image_copy’ from incompatible pointer type
libavutil/hwcontext_dxva2.c:382:52: warning: passing argument 3 of ‘av_image_copy_uc_from’ from incompatible pointer type
---
 libavutil/hwcontext_d3d11va.c |4 ++--
 libavutil/hwcontext_dxva2.c   |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 41330f0..6670c47 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -410,7 +410,7 @@ static int d3d11va_transfer_data(AVHWFramesContext *ctx, AVFrame *dst,
 
 fill_texture_ptrs(map_data, map_linesize, ctx, , );
 
-av_image_copy(dst->data, dst->linesize, map_data, map_linesize,
+av_image_copy(dst->data, dst->linesize, (const uint8_t **)map_data, map_linesize,
   ctx->sw_format, w, h);
 
 ID3D11DeviceContext_Unmap(device_hwctx->device_context, staging, 0);
@@ -422,7 +422,7 @@ static int d3d11va_transfer_data(AVHWFramesContext *ctx, AVFrame *dst,
 
 fill_texture_ptrs(map_data, map_linesize, ctx, , );
 
-av_image_copy(map_data, map_linesize, src->data, src->linesize,
+av_image_copy(map_data, map_linesize, (const uint8_t **)src->data, src->linesize,
   ctx->sw_format, w, h);
 
 ID3D11DeviceContext_Unmap(device_hwctx->device_context, staging, 0);
diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4585f32..64366ce 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -348,7 +348,7 @@ static int dxva2_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
 if (ret < 0)
 goto fail;
 
-av_image_copy(map->data, map->linesize, src->data, src->linesize,
+av_image_copy(map->data, map->linesize, (const uint8_t **)src->data, src->linesize,
   ctx->sw_format, src->width, src->height);
 
 fail:
@@ -379,7 +379,7 @@ static int dxva2_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
 dst_linesize[i] = dst->linesize[i];
 src_linesize[i] = map->linesize[i];
 }
-av_image_copy_uc_from(dst->data, dst_linesize, map->data, src_linesize,
+av_image_copy_uc_from(dst->data, dst_linesize, (const uint8_t **)map->data, src_linesize,
   ctx->sw_format, src->width, src->height);
 fail:
 av_frame_free();
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavc/alac: Make a variable unsigned

2019-04-18 Thread Carl Eugen Hoyos

Hi!

Attached patch silences a warning that is shown with some gcc versions.

Please comment, Carl Eugen
From 6ed77b4c191028f47f48396a782619f2ba47b716 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 18 Apr 2019 13:51:07 +0200
Subject: [PATCH] lavc/alac: Make a variable unsigned.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes a bogus compiler warning (max_samples_per_frame is checked):
libavcodec/alac.c: In function ‘allocate_buffers’:
./libavutil/internal.h:142:9: warning: argument 1 value ‘18446744073709551552’ exceeds maximum object size 9223372036854775807
---
 libavcodec/alac.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index d6b87db..2f44340 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -486,7 +486,7 @@ static av_cold int alac_decode_close(AVCodecContext *avctx)
 static int allocate_buffers(ALACContext *alac)
 {
 int ch;
-int buf_size = alac->max_samples_per_frame * sizeof(int32_t);
+unsigned buf_size = alac->max_samples_per_frame * sizeof(int32_t);

 for (ch = 0; ch < 2; ch++) {
 alac->predict_error_buffer[ch]  = NULL;
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/encoders: Fix libvpx option name arnr-maxframes.

2019-04-18 Thread Carl Eugen Hoyos

2019-04-18 13:41 GMT+02:00, Carl Eugen Hoyos :
> ffmpeg | branch: master | Carl Eugen Hoyos  | Thu Apr 18
> 13:39:58 2019 +0200| [09f8b21deb16c545e8fe9cc531314284b92e8371] | committer:
> Carl Eugen Hoyos
>
> doc/encoders: Fix libvpx option name arnr-maxframes.
>
> Fixes ticket #7856.
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=09f8b21deb16c545e8fe9cc531314284b92e8371
> ---
>
>  doc/encoders.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 2c8d8bbb38..ef12c73ed5 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1817,7 +1817,7 @@ means unlimited.
>  @item auto-alt-ref
>  Enable use of alternate reference frames (2-pass only).
>  Values greater than 1 enable multi-layer alternate reference frames (VP9
> only).
> -@item arnr-max-frames
> +@item arnr-maxframes

I believe it would be great to harmonize the option names
in libvpx and libaom.
No opinion here which one to use.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Andreas Håkon via ffmpeg-devel



‐‐‐ Original Message ‐‐‐
On Thursday, 18 de April de 2019 13:14, Andreas Håkon 
 wrote:

> > On Wed, Apr 17, 2019 at 08:28:39PM +, Andreas Håkon via ffmpeg-devel 
> > wrote:
> >
> > > This patch solves the initialization of the inputs when using filters (a 
> > > graph filter) with the mpegts muxer.
> > > This bug seems to be generated by a simple forgetting to copy. The same 
> > > code is repeated two times, but only in one case the variable 
> > > “inputs_done” is initialized. Compare the two blocks:
> >
> > This text should be in the commit message.
> > also a testcase would be usefull, a fate test even better
>
> Done!
>
> Regards.
> A.H.
>

Hi Michael,

Your request is now here:
https://patchwork.ffmpeg.org/patch/12794/

Mark as superseded both:
https://patchwork.ffmpeg.org/patch/12783/
https://patchwork.ffmpeg.org/patch/12790/

And please review the second part:
https://patchwork.ffmpeg.org/patch/12791/

Regards.
A.H.


---

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Andreas Håkon via ffmpeg-devel


> On Wed, Apr 17, 2019 at 08:28:39PM +, Andreas Håkon via ffmpeg-devel 
> wrote:
>
> > This patch solves the initialization of the inputs when using filters (a 
> > graph filter) with the mpegts muxer.
> > This bug seems to be generated by a simple forgetting to copy. The same 
> > code is repeated two times, but only in one case the variable “inputs_done” 
> > is initialized. Compare the two blocks:
>
> This text should be in the commit message.
> also a testcase would be usefull, a fate test even better
>

Done!

Regards.
A.H.


---

From af81338c21c67c0ef2c30ab2009c7094b32327f4 Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Wed, 17 Apr 2019 21:22:43 +0100
Subject: [PATCH] libavformat: input init fix mpegts filters

This patch solves the initialization of the inputs when using filters 
(a graph filter) with the mpegts muxer.

This bug seems to be generated by a simple forgetting to copy. The same code is
repeated two times, but only in one case the variable inputs_done is 
initialized.

Testcase:
 $ ffmpeg -f mpegts -i mpeg.ts \ 
   -filter_complex "[i:100]fps=fps=25[out]" \
   -map "[out]" -c:v libx264 -f mpegts out.ts

Signed-off-by: Andreas Hakon 
---
 fftools/ffmpeg.c|8 ++--
 libavformat/utils.c |4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0f157d6..b74a209 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4613,9 +4613,10 @@ static int transcode_step(void)
 }
 if ((ret = transcode_from_filter(ost->filter->graph, )) < 0)
 return ret;
-if (!ist)
+if (!ist) {
+ost->inputs_done = 1;
 return 0;
+}
 } else if (ost->filter) {
 int i;
 for (i = 0; i < ost->filter->graph->nb_inputs; i++) {
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Gyan




On 18-04-2019 03:25 PM, Timo Rothenpieler wrote:

On 18/04/2019 09:49, Gyan wrote:


Patchwork can incorrectly assign ownership. See 
https://patchwork.ffmpeg.org/patch/12680/


The author is Sam John as identified by Message ID as well as the 
From field in the headers, yet Patchwork attributes this patch to 
"Oliver Collyer via ffmpeg-devel", a name which appears nowhere in 
the headers or in the submitted patch. The downloaded mbox patch 
shows the same wrong attribution. Does anyone know what's going on?


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


This happens due to Mailman having to rewrite peoples E-Mail addresses 
if they have strong DKIM/DMARC configured on their sending Domain.
If that is the case, only the server of the actual Domain who owns the 
right private key can send E-Mails under the name of that Domain.


So for mailing lists to be able to send on the messages, they are 
forced to change the sender address.

In the case of this list:
Sam John 
gets translated to.
Sam John via ffmpeg-devel 



Ok.  Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author? 
It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly 
substituted here.

This looks like a parser failure in Patchwork.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavfi/fspp: Add a cast to silence a clang warning

2019-04-18 Thread Michael Niedermayer

On Tue, Apr 16, 2019 at 12:55:03AM +0200, Carl Eugen Hoyos wrote:
> 2019-04-14 1:02 GMT+02:00, Michael Niedermayer :
> > On Sat, Apr 13, 2019 at 07:25:54PM -0300, James Almer wrote:
> >> On 4/13/2019 7:04 PM, Carl Eugen Hoyos wrote:
> >> > Hi!
> >> >
> >> > Attached patch silences two warnings shown when compiling with clang:
> >> > libavfilter/vf_fspp.h:51:42: warning: implicit conversion from 'int'
> >> > to 'int16_t' (aka 'short') changes value from 44130 to -21406
> >> >
> >> > Please comment, Carl Eugen
> >> >
> >> >
> >> > 0001-lavfi-vf_fspp-Use-the-intended-cast-to-int16_t.patch
> >> >
> >> > From d731e523d9c5854183d20d37fe921f49fb048498 Mon Sep 17 00:00:00 2001
> >> > From: Carl Eugen Hoyos 
> >> > Date: Sat, 13 Apr 2019 23:05:44 +0200
> >> > Subject: [PATCH] lavfi/fspp: Add two casts to int16_t.
> >> >
> >> > Silences a warning with clang:
> >> > warning: implicit conversion from 'int' to 'int16_t' (aka 'short')
> >> > changes value from 44130 to -21406
> >> > ---
> >> >  libavfilter/vf_fspp.h |2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
> >> > index 74a3447..e346439 100644
> >> > --- a/libavfilter/vf_fspp.h
> >> > +++ b/libavfilter/vf_fspp.h
> >> > @@ -31,7 +31,7 @@
> >> >  #define DCTSIZE 8
> >> >  #define DCTSIZE_S "8"
> >> >
> >> > -#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
> >> > +#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5) & (int16_t)0x)
> >>
> >> The "& 0x" is turning -21406 into 44130 since it zeroes all the high
> >> bits, and then that value gets converted back to -21406 when stored into
> >> an int16_t variable.
> >>
> >> Change the int cast into int16_t if you want since it doesn't hurt (all
> >> the values are safely within the int16_t range anyway), but remove the
> >> "& 0x" altogether instead of casting it, to get rid of this warning.
> >>
> >> >  #define C64(x)((uint64_t)((x) | (x) << 16)) <<32 | (uint64_t)(x) |
> >> > (uint64_t)(x) << 16
> >> >  #define FIX64(x,s)  C64(FIX(x,s))
> >
> > i think the C64 / FIX64 macros depend on the & 0x. They are maybe
> > unused
> > and just referenced in comments but having them not give correct values
> > could still be confusing. The 0x if its removed should be added to the
> > code / comments that refer to it in a way that needs it
> 
> New patch attached.
> Not sure if / where to add comments.
> 
> Please comment, Carl Eugen

>  vf_fspp.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 17e468ee43988ef39d3ce882774dc3e2d625c9e6  
> 0001-lavfi-fspp-Cast-float-values-to-int16_t-instead-of-i.patch
> From dfda9d8a6714649015f252e0e0bf5e3e52ce1b5c Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 16 Apr 2019 00:50:50 +0200
> Subject: [PATCH] lavfi/fspp: Cast float values to int16_t instead of int.
> 
> Silences a warning with clang:
> warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes 
> value from 44130 to -21406
> ---
>  libavfilter/vf_fspp.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
> index 802db14..bdafe8e 100644
> --- a/libavfilter/vf_fspp.h
> +++ b/libavfilter/vf_fspp.h
> @@ -31,7 +31,7 @@
>  #define DCTSIZE 8
>  #define DCTSIZE_S "8"
>  
> -#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
> +#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5))

does it need the cast at all to avoid the warning ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-18 Thread Tobias Rapp


On 18.04.2019 11:40, Michael Niedermayer wrote:

On Thu, Apr 18, 2019 at 10:30:49AM +0200, Paul B Mahol wrote:

On 4/18/19, Michael Niedermayer  wrote:

On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:

On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
  libavcodec/dvdec.c | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)


Is this intended to be 100% same output ?

I have a few cases that produce differences. Dont have a good testcase
though
./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi
produces different output.
oddly -f framecrc produces the same output
not sure this is a problem or not the input file may have issues


heres another testcase:
./ffmpeg -i ~/tickets/2390/dv_cut.dv aviavi2.avi

[...]


This is because audio is muxed differently.
This bug have nothing to do with this patch.


iam not sure thats the case. Looking at this again now in the morning
VPRP is different and the muxer receives a different par->field_order
(0 vs. 5). I dont think audio should afect the video field_order


That might be caused by frame-threading in general and not explicitly by 
the dv decoder. Have experienced field_order information not being 
reliably forwarded to the muxer in ffmpeg before. Seems sometimes the 
encoder settings are updated too late to be picked up by the muxer when 
writing header information.


Regards,
Tobias

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavcodec: QSV protect GPB code with CO3 define

2019-04-18 Thread Andreas Håkon via ffmpeg-devel

Hi,

In response to this ticket I provide the first part of the patch:
https://trac.ffmpeg.org/ticket/7839

This QSV_HAVE_GPB code needs to be protected by QSV_HAVE_CO3.

Regards.
A.H.

---From d43c81f5bba49e55ea867bd6afd2eef878dc0ad3 Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Thu, 18 Apr 2019 10:40:38 +0100
Subject: [PATCH] libavcodec: qsv protect gpb with co3

---
 libavcodec/qsvenc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index a03ab69..9583d62 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -267,10 +267,12 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #endif
 #endif
 
+#if QSV_HAVE_CO3
 #if QSV_HAVE_GPB
 if (avctx->codec_id == AV_CODEC_ID_HEVC)
 av_log(avctx, AV_LOG_VERBOSE,"GPB: %s\n", print_threestate(co3->GPB));
 #endif
+#endif
 
 if (avctx->codec_id == AV_CODEC_ID_H264) {
 av_log(avctx, AV_LOG_VERBOSE, "Entropy coding: %s; 
MaxDecFrameBuffering: %"PRIu16"\n",
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-18 Thread Paul B Mahol

On 4/18/19, Michael Niedermayer  wrote:
> On Thu, Apr 18, 2019 at 10:30:49AM +0200, Paul B Mahol wrote:
>> On 4/18/19, Michael Niedermayer  wrote:
>> > On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:
>> >> On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:
>> >> > Signed-off-by: Paul B Mahol 
>> >> > ---
>> >> >  libavcodec/dvdec.c | 19 ++-
>> >> >  1 file changed, 10 insertions(+), 9 deletions(-)
>> >>
>> >> Is this intended to be 100% same output ?
>> >>
>> >> I have a few cases that produce differences. Dont have a good testcase
>> >> though
>> >> ./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi
>> >> produces different output.
>> >> oddly -f framecrc produces the same output
>> >> not sure this is a problem or not the input file may have issues
>> >
>> > heres another testcase:
>> > ./ffmpeg -i ~/tickets/2390/dv_cut.dv aviavi2.avi
>> >
>> > -rw-r- 1 michael michael 112414 Apr 18 01:18 aviavi2.avi
>> > -rw-r- 1 michael michael 112446 Apr 18 01:18 aviavi.avi
>> > --- strings1   2019-04-18 01:19:42.472574387 +0200
>> > +++ strings2   2019-04-18 01:19:37.764574245 +0200
>> > @@ -1,4 +1,4 @@
>> > -RIFF6
>> > +RIFF
>> >  AVI LIST
>> >  hdrlavih8
>> >  LIST
>> > @@ -8,7 +8,7 @@
>> >  FMP4
>> >  JUNK
>> >  00dc
>> > -vprpd
>> > +vprpD
>> >  LIST
>> >  strlstrh8
>> >  auds
>>
>> This is because audio is muxed differently.
>> This bug have nothing to do with this patch.
>
> iam not sure thats the case. Looking at this again now in the morning
> VPRP is different and the muxer receives a different par->field_order
> (0 vs. 5). I dont think audio should afect the video field_order

Can't reproduce.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Democracy is the form of government in which you can choose your dictator
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Michael Niedermayer

On Wed, Apr 17, 2019 at 08:28:39PM +, Andreas Håkon via ffmpeg-devel wrote:
> This patch solves the initialization of the inputs when using filters (a 
> graph filter) with the mpegts muxer.
> 
> This bug seems to be generated by a simple forgetting to copy. The same code 
> is repeated two times, but only in one case the variable “inputs_done” is 
> initialized. Compare the two blocks:

This text should be in the commit message.
also a testcase would be usefull, a fate test even better

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] Fix sdp size check on fmtp integer parameters

2019-04-18 Thread Michael Niedermayer

On Mon, Apr 01, 2019 at 04:45:38PM +0200, Olivier Maignial wrote:
> RFC-4566 do not give any limit of size on interger parameters given in fmtp 
> line.
> By reading some more RFCs it is possible to find examples where some integers 
> parameters are greater than 32 (see RFC-6416, 7.4)
> 
> Instead I propose to check just check the eventual integer overflow.
> Using INT_MIN and INT_MAX ensure that it will work whatever the size of int 
> given by compiler
> 
> Signed-off-by: Olivier Maignial 
> ---
> 
> Changes v1 -> v2:
> - Removed line break at end of 'if' line before brace
> - Added Signed-Off-By line
> 
>  libavformat/rtpdec_mpeg4.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
> index 994ab49..14caa0a 100644
> --- a/libavformat/rtpdec_mpeg4.c
> +++ b/libavformat/rtpdec_mpeg4.c
> @@ -289,15 +289,23 @@ static int parse_fmtp(AVFormatContext *s,
>  for (i = 0; attr_names[i].str; ++i) {
>  if (!av_strcasecmp(attr, attr_names[i].str)) {
>  if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
> -int val = atoi(value);
> -if (val > 32) {
> +char *end_ptr = NULL;
> +long int val = strtol(value, _ptr, 10);
> +if (value[0] == '\n' || end_ptr[0] != '\0') {
>  av_log(s, AV_LOG_ERROR,
> -   "The %s field size is invalid (%d)\n",
> +   "The %s field value is not a number (%s)\n",
> +   attr, value);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (val > INT_MAX || val < INT_MIN) {

This test only works if LONG_MAX > INT_MAX otherwise it will not
detect out of range values

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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Timo Rothenpieler


On 18/04/2019 09:49, Gyan wrote:


Patchwork can incorrectly assign ownership. See 
https://patchwork.ffmpeg.org/patch/12680/


The author is Sam John as identified by Message ID as well as the From 
field in the headers, yet Patchwork attributes this patch to "Oliver 
Collyer via ffmpeg-devel", a name which appears nowhere in the headers 
or in the submitted patch. The downloaded mbox patch shows the same 
wrong attribution. Does anyone know what's going on?


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


This happens due to Mailman having to rewrite peoples E-Mail addresses 
if they have strong DKIM/DMARC configured on their sending Domain.
If that is the case, only the server of the actual Domain who owns the 
right private key can send E-Mails under the name of that Domain.


So for mailing lists to be able to send on the messages, they are forced 
to change the sender address.

In the case of this list:
Sam John 
gets translated to.
Sam John via ffmpeg-devel 

Nothing can be sensibly done about this, cause the alternative would be 
the message getting rejected by the majority of Mailservers.
It's unfortunate that this also messes with the patches. People who are 
affected should probably attach patches instead of using send-email.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-18 Thread Michael Niedermayer

On Thu, Apr 18, 2019 at 10:30:49AM +0200, Paul B Mahol wrote:
> On 4/18/19, Michael Niedermayer  wrote:
> > On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:
> >> On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:
> >> > Signed-off-by: Paul B Mahol 
> >> > ---
> >> >  libavcodec/dvdec.c | 19 ++-
> >> >  1 file changed, 10 insertions(+), 9 deletions(-)
> >>
> >> Is this intended to be 100% same output ?
> >>
> >> I have a few cases that produce differences. Dont have a good testcase
> >> though
> >> ./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi
> >> produces different output.
> >> oddly -f framecrc produces the same output
> >> not sure this is a problem or not the input file may have issues
> >
> > heres another testcase:
> > ./ffmpeg -i ~/tickets/2390/dv_cut.dv aviavi2.avi
> >
> > -rw-r- 1 michael michael 112414 Apr 18 01:18 aviavi2.avi
> > -rw-r- 1 michael michael 112446 Apr 18 01:18 aviavi.avi
> > --- strings12019-04-18 01:19:42.472574387 +0200
> > +++ strings22019-04-18 01:19:37.764574245 +0200
> > @@ -1,4 +1,4 @@
> > -RIFF6
> > +RIFF
> >  AVI LIST
> >  hdrlavih8
> >  LIST
> > @@ -8,7 +8,7 @@
> >  FMP4
> >  JUNK
> >  00dc
> > -vprpd
> > +vprpD
> >  LIST
> >  strlstrh8
> >  auds
> 
> This is because audio is muxed differently.
> This bug have nothing to do with this patch.

iam not sure thats the case. Looking at this again now in the morning
VPRP is different and the muxer receives a different par->field_order
(0 vs. 5). I dont think audio should afect the video field_order

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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavformat: fix copyts and muxrate in mpegts muxer

2019-04-18 Thread Andreas Håkon via ffmpeg-devel

Hi,

This patch resolves one very specific use case:

- When you use the mpegts muxer;
- And use the global parameter “-copyts”;
- And use the parameter “-muxrate” for the mpegts muxer;
- And use too the parameter “-mpegts_copyts”.

The problem is created because the member “first_pcr” of the MpegTSWrite struct 
isn’t initialized with a correct timestamp (so when copying the timestamps the 
initial value is 0). And in this case an infinite loop is created because the 
code never writes PES packets when the “mux_rate” isn’t VBR (equals to 1). See 
the block that creates the loop here (note the "continue" command at end):
https://github.com/FFmpeg/FFmpeg/blob/a0559fcd81f42f446c93357a943699f9d44eeb79/libavformat/mpegtsenc.c#L1211

So, this patch fixes the problem initializing the “first_pcr” with the first 
DTS value that comes when using the incoming timestamps.

Regards.
A.H.

---From 225f3de248625c588b2e8bb169cdff28705db8f5 Mon Sep 17 00:00:00 2001
From:  Andreas Hakon 
Date: Thu, 18 Apr 2019 09:53:30 +0100
Subject: [PATCH] libavformat: fix copyts with muxrate

---
 libavformat/mpegtsenc.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea22..7e94326 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -971,6 +971,9 @@ static int mpegts_init(AVFormatContext *s)
 
 if (ts->copyts < 1)
 ts->first_pcr = av_rescale(s->max_delay, PCR_TIME_BASE, 
AV_TIME_BASE);
+else
+ts->first_pcr = AV_NOPTS_VALUE;
+
 } else {
 /* Arbitrary values, PAT/PMT will also be written on video key frames 
*/
 ts->sdt_packet_period = 200;
@@ -1186,12 +1189,16 @@ static void mpegts_write_pes(AVFormatContext *s, 
AVStream *st,
 int64_t pcr = -1; /* avoid warning */
 int64_t delay = av_rescale(s->max_delay, 9, AV_TIME_BASE);
 int force_pat = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO && key && 
!ts_st->prev_payload_key;
+int last_payload_size = 0;
 
 av_assert0(ts_st->payload != buf || st->codecpar->codec_type != 
AVMEDIA_TYPE_VIDEO);
 if (ts->flags & MPEGTS_FLAG_PAT_PMT_AT_FRAMES && st->codecpar->codec_type 
== AVMEDIA_TYPE_VIDEO) {
 force_pat = 1;
 }
 
+if (ts->mux_rate > 1 && dts != AV_NOPTS_VALUE && ts->first_pcr == 
AV_NOPTS_VALUE)
+ts->first_pcr = (dts - 1) * 300;
+
 is_start = 1;
 while (payload_size > 0) {
 retransmit_si_info(s, force_pat, dts);
@@ -1209,12 +1216,13 @@ static void mpegts_write_pes(AVFormatContext *s, 
AVStream *st,
 }
 
 if (ts->mux_rate > 1 && dts != AV_NOPTS_VALUE &&
-(dts - get_pcr(ts, s->pb) / 300) > delay) {
+last_payload_size != payload_size && (dts - get_pcr(ts, s->pb) / 
300) > delay) {
 /* pcr insert gets priority over null packet insert */
 if (write_pcr)
 mpegts_insert_pcr_only(s, st);
 else
 mpegts_insert_null_packet(s);
+last_payload_size = payload_size;
 /* recalculate write_pcr and possibly retransmit si_info */
 continue;
 }
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-18 Thread Paul B Mahol

On 4/18/19, Michael Niedermayer  wrote:
> On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:
>> On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:
>> > Signed-off-by: Paul B Mahol 
>> > ---
>> >  libavcodec/dvdec.c | 19 ++-
>> >  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> Is this intended to be 100% same output ?
>>
>> I have a few cases that produce differences. Dont have a good testcase
>> though
>> ./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi
>> produces different output.
>> oddly -f framecrc produces the same output
>> not sure this is a problem or not the input file may have issues
>
> heres another testcase:
> ./ffmpeg -i ~/tickets/2390/dv_cut.dv aviavi2.avi
>
> -rw-r- 1 michael michael 112414 Apr 18 01:18 aviavi2.avi
> -rw-r- 1 michael michael 112446 Apr 18 01:18 aviavi.avi
> --- strings1  2019-04-18 01:19:42.472574387 +0200
> +++ strings2  2019-04-18 01:19:37.764574245 +0200
> @@ -1,4 +1,4 @@
> -RIFF6
> +RIFF
>  AVI LIST
>  hdrlavih8
>  LIST
> @@ -8,7 +8,7 @@
>  FMP4
>  JUNK
>  00dc
> -vprpd
> +vprpD
>  LIST
>  strlstrh8
>  auds

This is because audio is muxed differently.
This bug have nothing to do with this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Andreas Håkon via ffmpeg-devel


> Hi Carl,
>
> > Please split the patch.
> > Carl Eugen
>
> OK. Here the relevant part regargind the bug fix.
> I'll send another new with the log enhancement.
>
> Regards.
> A.H.
>

This supersedes my previous PATCH:
https://patchwork.ffmpeg.org/patch/12783/

So, please, mark it as superseded.


Regards.
A.H.


Note: The second part is that:
https://patchwork.ffmpeg.org/patch/12791/
Only as reference.


.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Patchwork attribution

2019-04-18 Thread Gyan



Patchwork can incorrectly assign ownership. See 
https://patchwork.ffmpeg.org/patch/12680/


The author is Sam John as identified by Message ID as well as the From 
field in the headers, yet Patchwork attributes this patch to "Oliver 
Collyer via ffmpeg-devel", a name which appears nowhere in the headers 
or in the submitted patch. The downloaded mbox patch shows the same 
wrong attribution. Does anyone know what's going on?


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavformat: improve logs with cur_dts

2019-04-18 Thread Andreas Håkon via ffmpeg-devel

Hi,

This is the second part of my previous patch:
https://patchwork.ffmpeg.org/patch/12783/

It improves the logs when the message "cur_dts is invalid" appears.
If helps to identify which stream generates the trouble,
and the status of the stream.
A lot of users suffers with the message, and the origin varies.
The improved message can help to discover the cause.

Regards.
A.H.From af81338c21c67c0ef2c30ab2009c7094b32327f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?= 
Date: Wed, 17 Apr 2019 21:22:43 +0100
Subject: [PATCH] libavformat: input init fix mpegts filters

---
 fftools/ffmpeg.c|8 ++--
 libavformat/utils.c |4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0f157d6..b74a209 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3875,7 +3875,9 @@ static OutputStream *choose_output(void)
av_rescale_q(ost->st->cur_dts, ost->st->time_base,
 AV_TIME_BASE_Q);
 if (ost->st->cur_dts == AV_NOPTS_VALUE)
-av_log(NULL, AV_LOG_DEBUG, "cur_dts is invalid (this is harmless 
if it occurs once at the start per stream)\n");
+av_log(NULL, AV_LOG_DEBUG,
+"cur_dts is invalid st:%d (%d) [init:%d i_done:%d finish:%d] 
(this is harmless if it occurs once at the start per stream)\n",
+ost->st->index, ost->st->id, ost->initialized, 
ost->inputs_done, ost->finished);
 
 if (!ost->initialized && !ost->inputs_done)
 return ost;
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9b3f0d2..6ef9423 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1402,9 +1402,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 st->cur_dts = pkt->dts;
 
 if (s->debug & FF_FDEBUG_TS)
-av_log(s, AV_LOG_DEBUG, "OUTdelayed:%d/%d pts:%s, dts:%s cur_dts:%s\n",
-presentation_delayed, delay, av_ts2str(pkt->pts), 
av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
+av_log(s, AV_LOG_DEBUG, "OUTdelayed:%d/%d pts:%s, dts:%s cur_dts:%s 
st:%d (%d)\n",
+presentation_delayed, delay, av_ts2str(pkt->pts), 
av_ts2str(pkt->dts), av_ts2str(st->cur_dts), st->index, st->id);
 
 /* update flags */
 if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA || 
is_intra_only(st->codecpar->codec_id))
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Updated the documentation for libaom encoder options.

2019-04-18 Thread Gyan




On 18-04-2019 12:47 AM, Gyan wrote:



On 18-04-2019 12:33 AM, Sam John via ffmpeg-devel wrote:

Hi,

Is there anything to be done for this patch ?


Just a tiny bit of formatting, which I'll do and push.


Added some details; fixed some formatting and

pushed as 88325f4b34dd927da680fe180d4ebdc5f8464e39

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-18 Thread Andreas Håkon via ffmpeg-devel

Hi Carl,

>
> Please split the patch.
>
> Carl Eugen
>

OK. Here the relevant part regargind the bug fix.
I'll send another new with the log enhancement.

Regards.
A.H.



From af81338c21c67c0ef2c30ab2009c7094b32327f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?= 
Date: Wed, 17 Apr 2019 21:22:43 +0100
Subject: [PATCH] libavformat: input init fix mpegts filters

---
 fftools/ffmpeg.c|8 ++--
 libavformat/utils.c |4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0f157d6..b74a209 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4613,9 +4613,10 @@ static int transcode_step(void)
 }
 if ((ret = transcode_from_filter(ost->filter->graph, )) < 0)
 return ret;
-if (!ist)
+if (!ist) {
+ost->inputs_done = 1;
 return 0;
+}
 } else if (ost->filter) {
 int i;
 for (i = 0; i < ost->filter->graph->nb_inputs; i++) {
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support

2019-04-18 Thread Fu, Linjie

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 08:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support
> 
> ---
>  libavcodec/vaapi_encode.c   | 128
> 
>  libavcodec/vaapi_encode.h   |  11 +++
>  libavcodec/vaapi_encode_h264.c  |   2 +
>  libavcodec/vaapi_encode_h265.c  |   2 +
>  libavcodec/vaapi_encode_mpeg2.c |   2 +
>  libavcodec/vaapi_encode_vp8.c   |   2 +
>  libavcodec/vaapi_encode_vp9.c   |   2 +
>  7 files changed, 149 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451882..03a7f5ce3e 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -143,6 +143,7 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>  int err, i;
>  char data[MAX_PARAM_BUFFER_SIZE];
>  size_t bit_len;
> +AVFrameSideData *sd;
> 
>  av_log(avctx, AV_LOG_DEBUG, "Issuing encode for
> pic %"PRId64"/%"PRId64" "
> "as type %s.\n", pic->display_order, pic->encode_order,
> @@ -412,6 +413,91 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>  }
>  }
> 
> +sd = av_frame_get_side_data(pic->input_image,
> +AV_FRAME_DATA_REGIONS_OF_INTEREST);
> +
> +#if VA_CHECK_VERSION(1, 0, 0)
> +if (sd && ctx->roi_allowed) {
> +const AVRegionOfInterest *roi;
> +int nb_roi;
> +VAEncMiscParameterBuffer param_misc = {
> +.type = VAEncMiscParameterTypeROI,
> +};
> +VAEncMiscParameterBufferROI param_roi;
> +// VAAPI requires the second structure to immediately follow the
> +// first in the parameter buffer, but they have different natural
> +// alignment on 64-bit architectures (4 vs. 8, since the ROI
> +// structure contains a pointer).  This means we can't make a
> +// single working structure, nor can we make the buffer
> +// separately and map it because dereferencing the second pointer
> +// would be undefined.  Therefore, construct the two parts
> +// separately and combine them into a single character buffer
> +// before uploading.
> +char param_buffer[sizeof(param_misc) + sizeof(param_roi)];
> +int i, v;

How about using packed attribute to cope with this? Like:
struct {
VAEncMiscParameterBuffer misc;
VAEncMiscParameterBufferROI param_roi;
 } __attribute__((packed)) mfs_params;

This happens a lot during vaapi feature development, like 
MaxFrameSize:
struct {
VAEncMiscParameterBuffer misc;
VAEncMiscParameterBufferMultiPassFrameSize mfs;
} __attribute__((packed)) mfs_params;
Trellis: (currently waiting for bug fix in libva)
 https://patchwork.ffmpeg.org/patch/11733/

Thanks,
Linjie

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

68 matches

Mail list logo