[FFmpeg-devel] [PATCH] fate: fix mpeg2-ticket6677 faillures on some platforms

2017-10-24 Thread Zhong Li 
Signed-off-by: Zhong Li 
---
 tests/fate/video.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index 51678078a3..c7f2dcea9e 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -258,7 +258,7 @@ FATE_VIDEO-$(call DEMDEC, MPEGPS, MPEG2VIDEO) += 
fate-mpeg2-ticket6024
 fate-mpeg2-ticket6024: CMD = framecrc -flags +bitexact -idct simple -flags 
+truncated -i $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg -an
 
 FATE_VIDEO-$(call DEMDEC, MPEGVIDEO, MPEG2VIDEO) += fate-mpeg2-ticket6677
-fate-mpeg2-ticket6677: CMD = framecrc -vsync drop -i 
$(TARGET_SAMPLES)/mpeg2/sony-ct3.bs
+fate-mpeg2-ticket6677: CMD = framecrc -flags +bitexact -idct simple -vsync 
drop -i $(TARGET_SAMPLES)/mpeg2/sony-ct3.bs
 
 FATE_VIDEO-$(call DEMDEC, MV, MVC1) += fate-mv-mvc1
 fate-mv-mvc1: CMD = framecrc -i $(TARGET_SAMPLES)/mv/posture.mv -an -frames 25 
-pix_fmt rgb555le
-- 
2.11.0

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

[FFmpeg-devel] NVENC - HEVC + WP

2017-10-24 Thread Yogender Gupta 
One of the users had recently complained about encoding problems with HEVC 
encoding with WP (Weighted Prediction). This is a driver issue that has been 
identified, and shows up when using HEVC + WP + (PictureTimingSEI messages and 
or buffering period SEI messages).

Recently the PictureTiming SEI message was turned on by default in the NVENC 
code in ffmpeg and the issue shows up when doing HEVC encodes with WP turned on.

We have a driver fix that will come up in a later release, and users would be 
suggested to not enable weighted prediction with HEVC till a fixed driver 
version is available.

Regards,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add a test for mpeg2 issue of ticket #6677

2017-10-24 Thread Li, Zhong 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Wednesday, October 25, 2017 10:09 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] fate: add a test for mpeg2 issue of
> ticket #6677
> 
> On 10/24/2017 6:50 PM, Michael Niedermayer wrote:
> > On Mon, Oct 23, 2017 at 03:18:12PM +0800, Zhong Li wrote:
> >> Signed-off-by: Zhong Li 
> >> ---
> >>  tests/fate/video.mak|  3 +++
> >>  tests/ref/fate/mpeg2-ticket6677 | 12 
> >>  2 files changed, 15 insertions(+)
> >>  create mode 100644 tests/ref/fate/mpeg2-ticket6677
> >
> > will apply
> >
> > thanks
> 
> This seems to be failing on msvc (x86_32 at least), and on PowerPC Big
> Endian. Both give two different sets of frame hashes.

It should be caused by different idct ways. Will update, thanks for report this.

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

Re: [FFmpeg-devel] [PATCH] fate: add a test for mpeg2 issue of ticket #6677

2017-10-24 Thread James Almer 
On 10/24/2017 6:50 PM, Michael Niedermayer wrote:
> On Mon, Oct 23, 2017 at 03:18:12PM +0800, Zhong Li wrote:
>> Signed-off-by: Zhong Li 
>> ---
>>  tests/fate/video.mak|  3 +++
>>  tests/ref/fate/mpeg2-ticket6677 | 12 
>>  2 files changed, 15 insertions(+)
>>  create mode 100644 tests/ref/fate/mpeg2-ticket6677
> 
> will apply
> 
> thanks

This seems to be failing on msvc (x86_32 at least), and on PowerPC Big
Endian. Both give two different sets of frame hashes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] (no subject)

2017-10-24 Thread Thierry Foucu 
Michael,

the following patch seems to work. I restricted the change to N_VOP (from xvid) 
frame.
I tried to match it with what the xvidcore decoder does for such packets.

What do you think? 

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

[FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

2017-10-24 Thread Thierry Foucu 
Changed the return value when no VOD were encoded in Mpeg4 bistream.
And if we do have already a decoded frames and we are not in xvid_packed
mode, output the existing decoded frame instead of nothing.
---
 libavcodec/h263dec.c   | 9 -
 libavcodec/mpeg4videodec.c | 2 +-
 libavcodec/mpegutils.h | 1 +
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index c7cf4bc0c2..394a366f9c 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -506,8 +506,15 @@ retry:
 s->height= avctx->coded_height;
 }
 }
-if (ret == FRAME_SKIPPED)
+if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
+if (s->next_picture_ptr && ret == FRAME_NOT_CODED && !s->divx_packed) {
+if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0) {
+return ret;
+}
+*got_frame = 1;
+}
 return get_consumed_bytes(s, buf_size);
+}
 
 /* skip if the header was thrashed */
 if (ret < 0) {
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 82c4f8fc8c..3a9ed12971 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext *ctx, 
GetBitContext *gb)
 if (get_bits1(gb) != 1) {
 if (s->avctx->debug & FF_DEBUG_PICT_INFO)
 av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
-return FRAME_SKIPPED;
+return FRAME_NOT_CODED;
 }
 if (ctx->new_pred)
 decode_new_pred(ctx, gb);
diff --git a/libavcodec/mpegutils.h b/libavcodec/mpegutils.h
index 1bf73fea02..97786135c6 100644
--- a/libavcodec/mpegutils.h
+++ b/libavcodec/mpegutils.h
@@ -32,6 +32,7 @@
  * Return value for header parsers if frame is not coded.
  * */
 #define FRAME_SKIPPED 100
+#define FRAME_NOT_CODED 101
 
 /* picture type */
 #define PICT_TOP_FIELD 1
-- 
2.15.0.rc0.271.g36b669edcc-goog

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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

2017-10-24 Thread Thierry Foucu 
Michael,

what do you think of this patch?

I tried to reflect what the xvid decoder does for those N_VOP frame and in
case it is not packed.



On Tue, Oct 24, 2017 at 6:42 PM, Thierry Foucu  wrote:

> Changed the return value when no VOD were encoded in Mpeg4 bistream.
> And if we do have already a decoded frames and we are not in xvid_packed
> mode, output the existing decoded frame instead of nothing.
> ---
>  libavcodec/h263dec.c   | 9 -
>  libavcodec/mpeg4videodec.c | 2 +-
>  libavcodec/mpegutils.h | 1 +
>  3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index c7cf4bc0c2..394a366f9c 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -506,8 +506,15 @@ retry:
>  s->height= avctx->coded_height;
>  }
>  }
> -if (ret == FRAME_SKIPPED)
> +if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
> +if (s->next_picture_ptr && ret == FRAME_NOT_CODED &&
> !s->divx_packed) {
> +if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0) {
> +return ret;
> +}
> +*got_frame = 1;
> +}
>  return get_consumed_bytes(s, buf_size);
> +}
>
>  /* skip if the header was thrashed */
>  if (ret < 0) {
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index 82c4f8fc8c..3a9ed12971 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext *ctx,
> GetBitContext *gb)
>  if (get_bits1(gb) != 1) {
>  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
>  av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
> -return FRAME_SKIPPED;
> +return FRAME_NOT_CODED;
>  }
>  if (ctx->new_pred)
>  decode_new_pred(ctx, gb);
> diff --git a/libavcodec/mpegutils.h b/libavcodec/mpegutils.h
> index 1bf73fea02..97786135c6 100644
> --- a/libavcodec/mpegutils.h
> +++ b/libavcodec/mpegutils.h
> @@ -32,6 +32,7 @@
>   * Return value for header parsers if frame is not coded.
>   * */
>  #define FRAME_SKIPPED 100
> +#define FRAME_NOT_CODED 101
>
>  /* picture type */
>  #define PICT_TOP_FIELD 1
> --
> 2.15.0.rc0.271.g36b669edcc-goog
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] avformat/mpegts: opus muxing & demuxing for mapping family 255

2017-10-24 Thread Michael Niedermayer 
On Thu, Sep 14, 2017 at 06:48:33PM +0200, pkv.stream wrote:
> Thanks for your comments Moritz.
> Corrected patch in attachment.
> Regards
> 
> Le 14/09/2017 à 5:46 PM, Moritz Barsnick a écrit :
> >On Fri, Sep 08, 2017 at 01:46:38 +0200, pkv.stream wrote:
> >>-avpriv_request_sample(fc, "Opus in MPEG-TS - 
> >>channel_config_code > 0x8");
> >[...]
> >>+avpriv_request_sample(fc, "Opus in MPEG-TS - 
> >>channel_config_code");
> >You probably need to mention the channel_config_code in the new
> >message.
> >
> >>+for (j = 0; j < channels; j++) {
> >>+opus_channel_map255[j] = j;
> >>+}
> >Misplaced closing bracket.
> >
> >Moritz
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 

>  mpegts.c|   64 
> +---
>  mpegtsenc.c |   19 -
>  2 files changed, 74 insertions(+), 9 deletions(-)
> d2e34a72c7152584ae9423174f254d5d761325c3  
> 0001-avformat-mpegts-opus-muxing-demuxing-expanded.patch
> From 9175cb61dabce42417199cc6d6272d8290c39a5c Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Fri, 8 Sep 2017 01:34:22 +0200
> Subject: [PATCH] avformat/mpegts: opus muxing & demuxing expanded
> 
> Support for opus in mpegts demuxer was brought by commit
> 9cfa68c560bdec82d2d5ec079f9c5b0f9ca37af0 (Kieran Kunhya).
> Support for opus in mpegts muxer was then added by commit
> 01509cdf9287b975eced1fd609a8201fbd1438e3 (S. Droge).
> Later commit 37941878f193a2316c514bd5ba55bfe9d2dfdfcf by Michael Graczyk
> added support of mapping_family encoder parameter which allows for up to
> 255 audio channels (for family 255).
> While matroska muxer & demuxer readily accepts mapping_family, it is not
> the case for mpegts muxer & demuxer for all the range of the parameter
> (family 255 and also part of family 1 with channel_config_code > 0x81
> unsupported).
> This commit brings such a support.
> ---
>  libavformat/mpegts.c| 64 
> ++---
>  libavformat/mpegtsenc.c | 19 ++-
>  2 files changed, 74 insertions(+), 9 deletions(-)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 4d2f5c6..8d8977b 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -1633,7 +1633,7 @@ static const uint8_t opus_stream_cnt[9] = {
>  1, 1, 1, 2, 2, 3, 4, 4, 5,
>  };
>  
> -static const uint8_t opus_channel_map[8][8] = {
> +static const uint8_t opus_channel_map_a[8][8] = {
>  { 0 },
>  { 0,1 },
>  { 0,2,1 },
> @@ -1644,6 +1644,17 @@ static const uint8_t opus_channel_map[8][8] = {
>  { 0,6,1,2,3,4,5,7 },
>  };
>  
> +static const uint8_t opus_channel_map_b[8][8] = {
> +{ 0 },
> +{ 0,1 },
> +{ 0,1,2 },
> +{ 0,1,2,3 },
> +{ 0,1,2,3,4 },
> +{ 0,1,2,3,4,5 },
> +{ 0,1,2,3,4,5,6 },
> +{ 0,1,2,3,4,5,6,7 },
> +};
> +
>  int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int 
> stream_type,
>const uint8_t **pp, const uint8_t 
> *desc_list_end,
>Mp4Descr *mp4_descr, int mp4_descr_count, int 
> pid,
> @@ -1887,9 +1898,56 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
>  st->codecpar->extradata[18] = channel_config_code ? 
> (channels > 2) : /* Dual Mono */ 255;
>  st->codecpar->extradata[19] = 
> opus_stream_cnt[channel_config_code];
>  st->codecpar->extradata[20] = 
> opus_coupled_stream_cnt[channel_config_code];
> -memcpy(>codecpar->extradata[21], 
> opus_channel_map[channels - 1], channels);
> +memcpy(>codecpar->extradata[21], 
> opus_channel_map_a[channels - 1], channels);
>  } else {
> -avpriv_request_sample(fc, "Opus in MPEG-TS - 
> channel_config_code > 0x8");
> +if (channel_config_code == 0x81) {
> +channels = get8(pp, desc_end);
> +st->codecpar->extradata_size = 22 + channels;
> +size_t extradata_size;
> +extradata_size = (22 + channels) * sizeof(uint8_t);
> +uint8_t *extradata;

this produces warnings:
libavformat/mpegts.c:1906:25: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]


> +extradata = av_malloc(extradata_size);
> +if (!extradata)
> +return AVERROR(ENOMEM);

> +for (i = 0; i <= (22+channels); i++) {

the extradata_size expression is repeated 3 times, code duplication
should be avoided


> +if (i < 9) {
> +

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-10-24 Thread Michael Niedermayer 
On Tue, Oct 24, 2017 at 12:40:22PM -0400, Bjorn Roche wrote:
> Support for transparencies in animated gifs requires modifying both
> libavcodec/gif.c and libavformat/gif.c because both the graphics
> control extension (handled by libavformat/gif.c) and the raw frame data
> (handled by libavcodec/gif.c) must be changed. This is because
> transparencies in GIF can be used both to create a transparent image,
> and to provide optimization.
> 
> How transparencies are interpreted in a given frame is controlled by
> the “disposal method”, which must be set appropriately in the graphics
> control extension.
> 
>  The “in place” disposal method is used when transparency indicates
> optimization, and the “background” disposal method is used when
> transparency is intended to be preserved. In order to support both
> disposal methods, libavcodec/gif.c must signal to libavformat/gif.c
> which disposal method is required for every frame. This is done with a
> new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a
> change to avcodec.h
> 
> Unfortunately, the addition of a new side data type causes some of the
> FATE tests to fail. This is not addressed here.
> 
> This patch assumes paletteuse has already been patched to support
> transparency. (e.g. lavfi/paletteuse: fix to support transparency)
> 
> Feedback I definitely need:
> - I’ve done a fair bit of testing, but I’m sure I missed some important
> cases.
> - I don’t know if/how to update the FATE tests.
> ---
>  libavcodec/avcodec.h |   6 ++
>  libavcodec/gif.c | 196 
> +--
>  libavformat/gif.c|  16 -
>  3 files changed, 212 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 52cc5b0ca0..82a5328ce1 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1599,6 +1599,12 @@ enum AVPacketSideDataType {
>   */
>  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
>  
> +/**
> + * The disposal method that should be used with the frame. If missing,
> + * the frame will not be disposed. This contains exactly one byte.
> + */
> +AV_PKT_DATA_GIF_FRAME_DISPOSAL,
> +
>  /**
>   * ATSC A53 Part 4 Closed Captions. This metadata should be associated 
> with
>   * a video stream. A53 CC bitstream is stored as uint8_t in 
> AVPacketSideData.data.

you cannot add values in the middle of a public enum, that would
change the ABI

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

2017-10-24 Thread Michael Niedermayer 
On Tue, Oct 24, 2017 at 04:15:01PM +0200, Nicolas George wrote:
> Le primidi 1er brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> > But this is the whole problem. We're stuck in a stalemate between nothing
> > and nobody. As with ffserver, we'll keep postponing this forever more until
> > the stalemate is broken.
> > 
> > What incentive is there for anyone to write a replacement for this feature?
> > And stack that incentive against the pool of available developers that have
> > time and interest in this feature, and what are you left with?
> > 
> > Nothing.
> 
> The problem we have here is a lack of leadership.

I think the problem is primarely a mismatch of supply and demand.
There is more demand on "cleanup" than volunteers willing/able to do
said cleanup.

I also doubt that adding artifical pain like threatened removials
will attract any manpower, quite the contrary i think it will make
the gap wider in the long run.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] vaapi_h264: Add workaround for bad SEI in old Intel drivers

2017-10-24 Thread Mark Thompson 
On 25/10/17 00:32, Mark Thompson wrote:
> With pre-2.0 Intel drivers in CBR mode, if an explicit SEI message with
> the old (now deprecated) type is not included, the driver generates and
> inserts some timing SEI which is almost certainly invlaid.  Before
> 7a4fac5e91789b73e07bd4ad20493cfde028df76 we always inserted our own SEI

* 2e29ca2a9f19ba9a5b189f322f38497d2e2e3db0

> so this would not be visible, but since then it has been possible to
> disable that.  We would also like to avoid using the deprecated type,
> and using the new type, while working in old drivers, does not suppress
> the spurious message like the old type does.
> 
> Therefore, suppress the bad SEI insertion by providing a zero-length
> buffer with the old type, which the driver can insert harmlessly.
> ---
>  libavcodec/vaapi_encode_h264.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 1d43e934ef..5fd0bf7796 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -82,6 +82,7 @@ typedef struct VAAPIEncodeH264Context {
>  CodedBitstreamFragment current_access_unit;
>  int aud_needed;
>  int sei_needed;
> +int sei_cbr_workaround_needed;
>  } VAAPIEncodeH264Context;
>  
>  typedef struct VAAPIEncodeH264Options {
> @@ -258,6 +259,19 @@ static int 
> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>  
>  *type = VAEncPackedHeaderRawData;
>  return 0;
> +
> +#if !CONFIG_VAAPI_1
> +} else if (priv->sei_cbr_workaround_needed) {
> +// Insert a zero-length header using the old SEI type.  This is
> +// required to avoid triggering broken behaviour on Intel platforms
> +// in CBR mode where an invalid SEI message is generated by the
> +// driver and inserted into the stream.
> +*data_len = 0;
> +*type = VAEncPackedHeaderH264_SEI;
> +priv->sei_cbr_workaround_needed = 0;
> +return 0;
> +#endif
> +
>  } else {
>  return AVERROR_EOF;
>  }
> @@ -614,6 +628,10 @@ static int 
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>  
>  if (opt->sei & SEI_IDENTIFIER && pic->encode_order == 0)
>  priv->sei_needed = 1;
> +#if !CONFIG_VAAPI_1
> +if (ctx->va_rc_mode == VA_RC_CBR)
> +priv->sei_cbr_workaround_needed = 1;
> +#endif
>  
>  if (opt->sei & SEI_TIMING) {
>  memset(>pic_timing, 0, sizeof(priv->pic_timing));
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vaapi_h264: Add workaround for bad SEI in old Intel drivers

2017-10-24 Thread Mark Thompson 
With pre-2.0 Intel drivers in CBR mode, if an explicit SEI message with
the old (now deprecated) type is not included, the driver generates and
inserts some timing SEI which is almost certainly invlaid.  Before
7a4fac5e91789b73e07bd4ad20493cfde028df76 we always inserted our own SEI
so this would not be visible, but since then it has been possible to
disable that.  We would also like to avoid using the deprecated type,
and using the new type, while working in old drivers, does not suppress
the spurious message like the old type does.

Therefore, suppress the bad SEI insertion by providing a zero-length
buffer with the old type, which the driver can insert harmlessly.
---
 libavcodec/vaapi_encode_h264.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 1d43e934ef..5fd0bf7796 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -82,6 +82,7 @@ typedef struct VAAPIEncodeH264Context {
 CodedBitstreamFragment current_access_unit;
 int aud_needed;
 int sei_needed;
+int sei_cbr_workaround_needed;
 } VAAPIEncodeH264Context;
 
 typedef struct VAAPIEncodeH264Options {
@@ -258,6 +259,19 @@ static int 
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
 
 *type = VAEncPackedHeaderRawData;
 return 0;
+
+#if !CONFIG_VAAPI_1
+} else if (priv->sei_cbr_workaround_needed) {
+// Insert a zero-length header using the old SEI type.  This is
+// required to avoid triggering broken behaviour on Intel platforms
+// in CBR mode where an invalid SEI message is generated by the
+// driver and inserted into the stream.
+*data_len = 0;
+*type = VAEncPackedHeaderH264_SEI;
+priv->sei_cbr_workaround_needed = 0;
+return 0;
+#endif
+
 } else {
 return AVERROR_EOF;
 }
@@ -614,6 +628,10 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 
 if (opt->sei & SEI_IDENTIFIER && pic->encode_order == 0)
 priv->sei_needed = 1;
+#if !CONFIG_VAAPI_1
+if (ctx->va_rc_mode == VA_RC_CBR)
+priv->sei_cbr_workaround_needed = 1;
+#endif
 
 if (opt->sei & SEI_TIMING) {
 memset(>pic_timing, 0, sizeof(priv->pic_timing));
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] fix minor leak in id3v2 parsing

2017-10-24 Thread Moritz Barsnick 
On Tue, Oct 24, 2017 at 19:38:58 -0300, James Almer wrote:
> > Subject: [PATCH] Fix minor ffmpeg memory leak in id3v2 parsing.
> > 
> > Reviewed-on: https://chromium-review.googlesource.com/439405
> > Reviewed-by: Dale Curtis 
[...]
> This doesn't seem to apply to git head, or even the recently cut 3.4
> branch. Was this patch made for the 3.3 branch?

This code was changed/fixed on master 20 days ago by
1fd80106be3dca9fa0ea13fb364c8d221bd27c15, even before 3.4 was branched.

The fix may be valid for < 3.4 nonetheless. Is Chromium not using
master?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading

2017-10-24 Thread Mark Thompson 
On 24/10/17 23:34, Carl Eugen Hoyos wrote:
> 2017-10-25 0:29 GMT+02:00 Mark Thompson :
>> On 24/10/17 23:14, Carl Eugen Hoyos wrote:
>>> 2017-10-25 0:09 GMT+02:00 Mark Thompson :
 ffmpeg | branch: master | Mark Thompson  | Tue Oct 24 
 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] | 
 committer: Mark Thompson

 cbs_mpeg2: Fix type for marker_bit reading

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22
 ---

  libavcodec/cbs_mpeg2.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
 index d137762227..0cac29733e 100644
 --- a/libavcodec/cbs_mpeg2.c
 +++ b/libavcodec/cbs_mpeg2.c
 @@ -54,7 +54,7 @@
  xui(width, name, current->name)

  #define marker_bit() do { \
 -av_unused int one = 1; \
 +av_unused uint32_t one; \
  CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", , 1, 
 1)); \
>>>
>>> The commit message doesn't match the change / is this defined behaviour?
>>
>> It's only written and never read, so the initialisation isn't doing anything.
> 
> I asked because I believe it was reported once that a static analyzer 
> protested
> on passing uninitialized stuff - that was never going to be used - as
> a parameter.
> (But that may have been an uninitialized variable that was never used,
> not a pointer.)

I don't think pointers in general can be complained about in C without 
knowledge of the target function - consider that there are destination pointers 
all over the standard library which need not be initialised, like memcpy() or 
scanf().

If a static analyser looks inside the called function it will find:

"""
int ff_cbs_read_unsigned(CodedBitstreamContext *ctx, GetBitContext *gbc,
 int width, const char *name, uint32_t *write_to,
 uint32_t range_min, uint32_t range_max)
{
... stuff not involving write_to ...

*write_to = value;
return 0;
}
"""

which is I think reasonably clear-cut :)

Thanks,

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

Re: [FFmpeg-devel] fix minor leak in id3v2 parsing

2017-10-24 Thread James Almer 
On 10/24/2017 7:33 PM, Fredrik Hubinette wrote:
> From a6a79bda55868f7faee0f183a45191d3251fb5f1 Mon Sep 17 00:00:00 2001
> From: Fredrik Hubinette 
> Date: Tue, 7 Feb 2017 12:19:38 -0800
> Subject: [PATCH] Fix minor ffmpeg memory leak in id3v2 parsing.
> 
> Reviewed-on: https://chromium-review.googlesource.com/439405
> Reviewed-by: Dale Curtis 
> ---
>  libavformat/id3v2.c | 4 ++--
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index 9969d7a6ca..b3036d2f87 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
> @@ -688,9 +688,9 @@ static void read_chapter(AVFormatContext *s,
> AVIOContext *pb, int len, const cha
>  }
> 
>  if (decode_str(s, pb, 0, , ) < 0)
> -return;
> +  goto end;
>  if (len < 16)
> -return;
> +  goto end;
> 
>  start = avio_rb32(pb);
>  end   = avio_rb32(pb);
> 

This doesn't seem to apply to git head, or even the recently cut 3.4
branch. Was this patch made for the 3.3 branch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading

2017-10-24 Thread Carl Eugen Hoyos 
2017-10-25 0:29 GMT+02:00 Mark Thompson :
> On 24/10/17 23:14, Carl Eugen Hoyos wrote:
>> 2017-10-25 0:09 GMT+02:00 Mark Thompson :
>>> ffmpeg | branch: master | Mark Thompson  | Tue Oct 24 
>>> 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] | 
>>> committer: Mark Thompson
>>>
>>> cbs_mpeg2: Fix type for marker_bit reading
>>>
 http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22
>>> ---
>>>
>>>  libavcodec/cbs_mpeg2.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>>> index d137762227..0cac29733e 100644
>>> --- a/libavcodec/cbs_mpeg2.c
>>> +++ b/libavcodec/cbs_mpeg2.c
>>> @@ -54,7 +54,7 @@
>>>  xui(width, name, current->name)
>>>
>>>  #define marker_bit() do { \
>>> -av_unused int one = 1; \
>>> +av_unused uint32_t one; \
>>>  CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", , 1, 1)); 
>>> \
>>
>> The commit message doesn't match the change / is this defined behaviour?
>
> It's only written and never read, so the initialisation isn't doing anything.

I asked because I believe it was reported once that a static analyzer protested
on passing uninitialized stuff - that was never going to be used - as
a parameter.
(But that may have been an uninitialized variable that was never used,
not a pointer.)

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

[FFmpeg-devel] fix minor leak in id3v2 parsing

2017-10-24 Thread Fredrik Hubinette 
From a6a79bda55868f7faee0f183a45191d3251fb5f1 Mon Sep 17 00:00:00 2001
From: Fredrik Hubinette 
Date: Tue, 7 Feb 2017 12:19:38 -0800
Subject: [PATCH] Fix minor ffmpeg memory leak in id3v2 parsing.

Reviewed-on: https://chromium-review.googlesource.com/439405
Reviewed-by: Dale Curtis 
---
 libavformat/id3v2.c | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index 9969d7a6ca..b3036d2f87 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -688,9 +688,9 @@ static void read_chapter(AVFormatContext *s,
AVIOContext *pb, int len, const cha
 }

 if (decode_str(s, pb, 0, , ) < 0)
-return;
+  goto end;
 if (len < 16)
-return;
+  goto end;

 start = avio_rb32(pb);
 end   = avio_rb32(pb);
-- 
2.15.0.rc0.271.g36b669edcc-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading

2017-10-24 Thread Mark Thompson 
On 24/10/17 23:14, Carl Eugen Hoyos wrote:
> 2017-10-25 0:09 GMT+02:00 Mark Thompson :
>> ffmpeg | branch: master | Mark Thompson  | Tue Oct 24 
>> 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] | committer: 
>> Mark Thompson
>>
>> cbs_mpeg2: Fix type for marker_bit reading
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22
>> ---
>>
>>  libavcodec/cbs_mpeg2.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>> index d137762227..0cac29733e 100644
>> --- a/libavcodec/cbs_mpeg2.c
>> +++ b/libavcodec/cbs_mpeg2.c
>> @@ -54,7 +54,7 @@
>>  xui(width, name, current->name)
>>
>>  #define marker_bit() do { \
>> -av_unused int one = 1; \
>> +av_unused uint32_t one; \
>>  CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", , 1, 1)); \
> 
> The commit message doesn't match the change / is this defined behaviour?

It's only written and never read, so the initialisation isn't doing anything.  
(Hence also the av_unused.)

The type change is fixing a warning on DJGPP (16-bit int is not compatible with 
uint32_t), the other part is a trivial cleanup but should probably still have 
been mentioned.

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

Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting.

2017-10-24 Thread Mark Thompson 
On 24/10/17 07:02, Jun Zhao wrote:
> From 24b8e1c70fd4bf4eb76404fd9e2020fe3bbd90cb Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 24 Oct 2017 13:25:21 +0800
> Subject: [PATCH V2] lavc/vaapi_encode_h264: correct VUI
>  max_dec_frame_buffering setting.
> 
> vseq.max_num_ref_frames not init before the VUI
> max_dec_frame_buffering setting, so use sps.max_num_ref_frames
> in this case.
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 
> ---
>  libavcodec/vaapi_encode_h264.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 9a4bd53da1..1d43e934ef 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -441,7 +441,7 @@ static int 
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>  sps->vui.log2_max_mv_length_horizontal = 16;
>  sps->vui.log2_max_mv_length_vertical   = 16;
>  sps->vui.max_num_reorder_frames= (ctx->b_per_p > 0);
> -sps->vui.max_dec_frame_buffering   = vseq->max_num_ref_frames;
> +sps->vui.max_dec_frame_buffering   = sps->max_num_ref_frames;
>  
>  pps->nal_unit_header.nal_ref_idc = 3;
>  pps->nal_unit_header.nal_unit_type = H264_NAL_PPS;
> -- 
> 2.14.1
> 

LGTM, applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings when decoding DolbyVision

2017-10-24 Thread Carl Eugen Hoyos 
2017-10-23 14:40 GMT+02:00 James Almer :
> On 10/23/2017 5:09 AM, Carl Eugen Hoyos wrote:
>> 2017-10-23 5:22 GMT+02:00 James Almer :
>>> On 10/21/2017 9:31 PM, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch silences the many warnings shown when decoding streams
 with DolbyVision content.

 Please comment, Carl Eugen


 0001-lavc-hevcdec-Silence-warnings-when-decoding-DolbyVis.patch


 From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
 From: Carl Eugen Hoyos 
 Date: Sun, 22 Oct 2017 02:17:27 +0200
 Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.

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

 diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
 index 2e4add2..d5ed9f5 100644
 --- a/libavcodec/hevcdec.c
 +++ b/libavcodec/hevcdec.c
 @@ -2933,6 +2933,8 @@ static int decode_nal_unit(HEVCContext *s, const 
 H2645NAL *nal)
  break;
  case HEVC_NAL_AUD:
  case HEVC_NAL_FD_NUT:
 +case 62: // unspecified, used by DolbyVision
 +case 63: // unspecified, used by DolbyVision
>>>
>>> No, the log message should be set to verbose level instead, like
>>> inff_hevc_decode_extradata(). It's something of little value for the
>>> info level and effectively just spams stderr when trying to decode files
>>> with unofficial or currently unsupported NAL units.
>>
>> Don't we want users to upload such samples?
>
> Nothing in the current log messages hints the user to provide
> us with samples.

Experience indicates that users provide us with samples
that spam stderr.

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

Re: [FFmpeg-devel] [PATCH v4 2/2] rtp: rfc4175: add handler for YCbCr-4:2:2

2017-10-24 Thread Kieran Kunhya 
>
> Hi,
>
> I am surprised to see no mention on this work in changelog [1].
>
> I would put: "partial support of SMPTE 2110-20 (RFC4175)".
>
> Thanks,
>
> Eloi
>
> [1]: https://github.com/FFmpeg/FFmpeg/blob/master/Changelog


As an open source project we cannot cite unpublished documents.

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

Re: [FFmpeg-devel] [PATCH] fate: add a test for mpeg2 issue of ticket #6677

2017-10-24 Thread Michael Niedermayer 
On Mon, Oct 23, 2017 at 03:18:12PM +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li 
> ---
>  tests/fate/video.mak|  3 +++
>  tests/ref/fate/mpeg2-ticket6677 | 12 
>  2 files changed, 15 insertions(+)
>  create mode 100644 tests/ref/fate/mpeg2-ticket6677

will apply

thanks

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

2017-10-24 Thread Michael Niedermayer 
On Mon, Oct 23, 2017 at 04:18:28PM -0700, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c   | 15 +++-
>  tests/fate/mov.mak  |  4 ++
>  tests/ref/fate/mov-invalid-elst-entry-count | 57 
> +
>  3 files changed, 75 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/mov-invalid-elst-entry-count
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b22a116140..424293ad93 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4597,6 +4597,7 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  {
>  MOVStreamContext *sc;
>  int i, edit_count, version;
> +int64_t elst_entry_size;
>  
>  if (c->fc->nb_streams < 1 || c->ignore_editlist)
>  return 0;
> @@ -4605,6 +4606,15 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  version = avio_r8(pb); /* version */
>  avio_rb24(pb); /* flags */
>  edit_count = avio_rb32(pb); /* entries */
> +atom.size -= 8;
> +
> +elst_entry_size = version == 1 ? 20 : 12;
> +if (atom.size != edit_count * elst_entry_size &&
> +c->fc->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
> +av_log(c->fc, AV_LOG_ERROR, "Invalid edit list entry_count: %d for 
> elst atom of size: %"PRId64" bytes.\n",
> +   edit_count, atom.size + 8);
> +return AVERROR_INVALIDDATA;
> +}
>  
>  if (!edit_count)
>  return 0;
> @@ -4617,17 +4627,20 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return AVERROR(ENOMEM);
>  
>  av_log(c->fc, AV_LOG_TRACE, "track[%u].edit_count = %i\n", 
> c->fc->nb_streams - 1, edit_count);
> -for (i = 0; i < edit_count && !pb->eof_reached; i++) {
> +for (i = 0; i < edit_count && atom.size > 0 && !pb->eof_reached; i++) {
>  MOVElst *e = >elst_data[i];
>  
>  if (version == 1) {
>  e->duration = avio_rb64(pb);
>  e->time = avio_rb64(pb);
> +atom.size -= 16;
>  } else {
>  e->duration = avio_rb32(pb); /* segment duration */
>  e->time = (int32_t)avio_rb32(pb); /* media time */
> +atom.size -= 8;
>  }
>  e->rate = avio_rb32(pb) / 65536.0;
> +atom.size -= 4;
>  av_log(c->fc, AV_LOG_TRACE, "duration=%"PRId64" time=%"PRId64" 
> rate=%f\n",
> e->duration, e->time, e->rate);

it would be simpler to adjust edit_count in case of ineqality.
you already compute the elst_entry_size
this would also avoid allocating a larger than needed array


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-10-24 Thread Bjorn Roche 
On Tue, Oct 24, 2017 at 4:24 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-24 18:40 GMT+02:00 Bjorn Roche :
>
> > This patch assumes paletteuse has already been patched to support
> > transparency. (e.g. lavfi/paletteuse: fix to support transparency)
>
> Which should - imo - be unrelated to this patch and indeed, transcoding
> a pal8 apng (produced with your paletteuse patch) produces a good gif
> with this patch.
> I don't know if this is the best approach though.
>

Ah, okay, then my comment is wrong -- I just didn't see a way to test it
without paletteuse being fixed, but a pal8 apng makes sense.

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [PATCHv3] avformat/mpegts: opus muxing & demuxing for mapping family 255

2017-10-24 Thread pkv.stream 

Le 14/09/2017 à 6:48 PM, pkv.stream a écrit :

Thanks for your comments Moritz.
Corrected patch in attachment.
Regards

Le 14/09/2017 à 5:46 PM, Moritz Barsnick a écrit :

On Fri, Sep 08, 2017 at 01:46:38 +0200, pkv.stream wrote:
- avpriv_request_sample(fc, "Opus in MPEG-TS - channel_config_code > 
0x8");

[...]

+ avpriv_request_sample(fc, "Opus in MPEG-TS - channel_config_code");

You probably need to mention the channel_config_code in the new
message.


+    for (j = 0; j < channels; j++) {
+    opus_channel_map255[j] = j;
+    }

Misplaced closing bracket.

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




ping

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

Re: [FFmpeg-devel] [PATCH] libopus: Add channel mapping 2 support in libopusdec

2017-10-24 Thread Michael Niedermayer 
On Tue, Mar 28, 2017 at 12:35:29AM +, Felicia Lim wrote:
> Hi all,
> 
> Here is another patch to decode Opus ambisonics files using channel mapping
> 2 [1], this time in libopusdec.c.
> 
> Please let me know if there are any concerns.
> 
> Thanks,
> Felicia
> 
> [1] 
> *https://trac.tools.ietf.org/html/draft-ietf-codec-ambisonics-02#section-3.1
> *

>  libopusdec.c |   39 +--
>  1 file changed, 29 insertions(+), 10 deletions(-)
> b84e04c55997e5edfceff91fa7e57f85dd0f1141  
> 0001-libopus-Add-channel-mapping-2-support-in-libopusdec.patch
> From 6607c6f8cff64771cdf34faa6e318271f5a48ac2 Mon Sep 17 00:00:00 2001
> From: Felicia Lim 
> Date: Mon, 27 Mar 2017 16:21:20 -0700
> Subject: [PATCH] libopus: Add channel mapping 2 support in libopusdec
> 
> Enables demuxing of Ambisonics content coded with channel mapping 2
> ---
>  libavcodec/libopusdec.c | 39 +--
>  1 file changed, 29 insertions(+), 10 deletions(-)

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

[FFmpeg-devel] [PATCH]lavf/rtpenc: Add support for 24 bit pcm encoding

2017-10-24 Thread Carl Eugen Hoyos 
Hi!

Attached patch allows sending pcm_s24be over rtp, defined in rfc 3190.

Please comment, Carl Eugen
From 488a5065dac2ab04d03694b9086fd329421840cc Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 24 Oct 2017 23:03:02 +0200
Subject: [PATCH] lavf/rtpenc: Add support for 24 bit pcm encoding as defined
 by RFC 3190.

Fixes ticket #6770.
---
 libavformat/rtpenc.c  |3 +++
 libavformat/sdp.c |6 ++
 libavformat/version.h |2 +-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavformat/rtpenc.c b/libavformat/rtpenc.c
index 573593f..63047be 100644
--- a/libavformat/rtpenc.c
+++ b/libavformat/rtpenc.c
@@ -66,6 +66,7 @@ static int is_supported(enum AVCodecID id)
 case AV_CODEC_ID_PCM_S8:
 case AV_CODEC_ID_PCM_S16BE:
 case AV_CODEC_ID_PCM_S16LE:
+case AV_CODEC_ID_PCM_S24BE:
 case AV_CODEC_ID_PCM_U16BE:
 case AV_CODEC_ID_PCM_U16LE:
 case AV_CODEC_ID_PCM_U8:
@@ -544,6 +545,8 @@ static int rtp_write_packet(AVFormatContext *s1, AVPacket *pkt)
 case AV_CODEC_ID_PCM_S16BE:
 case AV_CODEC_ID_PCM_S16LE:
 return rtp_send_samples(s1, pkt->data, size, 16 * st->codecpar->channels);
+case AV_CODEC_ID_PCM_S24BE:
+return rtp_send_samples(s1, pkt->data, size, 24 * st->codecpar->channels);
 case AV_CODEC_ID_ADPCM_G722:
 /* The actual sample size is half a byte per sample, but since the
  * stream clock rate is 8000 Hz while the sample rate is 16000 Hz,
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 0242ca3..e714916 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -584,6 +584,12 @@ static char *sdp_write_media_attributes(char *buff, int size, AVStream *st, int
  payload_type,
  p->sample_rate, p->channels);
 break;
+case AV_CODEC_ID_PCM_S24BE:
+if (payload_type >= RTP_PT_PRIVATE)
+av_strlcatf(buff, size, "a=rtpmap:%d L24/%d/%d\r\n",
+ payload_type,
+ p->sample_rate, p->channels);
+break;
 case AV_CODEC_ID_PCM_MULAW:
 if (payload_type >= RTP_PT_PRIVATE)
 av_strlcatf(buff, size, "a=rtpmap:%d PCMU/%d/%d\r\n",
diff --git a/libavformat/version.h b/libavformat/version.h
index 0feb788..8ae091f 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR   0
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/dvbsub: Allow 256 colour encoding

2017-10-24 Thread Carl Eugen Hoyos 
2017-10-24 22:11 GMT+02:00 Michael Niedermayer :
> On Tue, Oct 24, 2017 at 02:04:28AM +0200, Carl Eugen Hoyos wrote:

>> Subject: [PATCH] lavc/dvbsub: Allow 256 colour encoding.
>>
>> Fixes ticket #6769.
>
> probably ok

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-10-24 Thread Carl Eugen Hoyos 
2017-10-24 18:40 GMT+02:00 Bjorn Roche :

[...]

The patch adds two warnings here on compilation of gif.c,
they should be fixed at some point:

libavcodec/gif.c:164:5: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement]
 uint8_t *frame_disposal = av_packet_new_side_data(pkt,
AV_PKT_DATA_GIF_FRAME_DISPOSAL, 1);
 ^~~
libavcodec/gif.c: In function ‘gif_image_write_translucent’:
libavcodec/gif.c:333:5: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement]
 uint8_t *frame_disposal = av_packet_new_side_data(pkt,
AV_PKT_DATA_GIF_FRAME_DISPOSAL, 1);
 ^~~

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-10-24 Thread Carl Eugen Hoyos 
2017-10-24 18:40 GMT+02:00 Bjorn Roche :

> This patch assumes paletteuse has already been patched to support
> transparency. (e.g. lavfi/paletteuse: fix to support transparency)

Which should - imo - be unrelated to this patch and indeed, transcoding
a pal8 apng (produced with your paletteuse patch) produces a good gif
with this patch.
I don't know if this is the best approach though.

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

[FFmpeg-devel] Don't use _tzcnt instrinics with clang for windows w/o BMI.

2017-10-24 Thread Dale Curtis 
Technically _tzcnt* intrinsics are only available when the BMI
instruction set is present. However the instruction encoding
degrades to "rep bsf" on older processors.

Clang for Windows debatably restricts the _tzcnt* instrinics behind
the __BMI__ architecture define, so check for its presence or
exclude the usage of these intrinics when clang is present.

See also:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html
https://bugs.llvm.org/show_bug.cgi?id=30506
http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html

Signed-off-by: Dale Curtis 
From 123a60bdcf99cab6b6e6bd31a463a29bc49598f0 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 24 Oct 2017 13:03:59 -0700
Subject: [PATCH] Don't use _tzcnt instrinics with clang for windows w/o BMI.

Technically _tzcnt* intrinsics are only available when the BMI
instruction set is present. However the instruction encoding
degrades to "rep bsf" on older processors.

Clang for Windows debatably restricts the _tzcnt* instrinics behind
the __BMI__ architecture define, so check for its presence or
exclude the usage of these intrinics when clang is present.

See also:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html
https://bugs.llvm.org/show_bug.cgi?id=30506
http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html

Signed-off-by: Dale Curtis 
---
 libavutil/x86/intmath.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index e83971c084..40743fd13e 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -47,7 +47,8 @@ static av_always_inline av_const int ff_log2_x86(unsigned int v)
 #   endif
 #   define ff_log2_16bit av_log2
 
-#if defined(__INTEL_COMPILER) || (defined(_MSC_VER) && (_MSC_VER >= 1700))
+#if defined(__INTEL_COMPILER) || (defined(_MSC_VER) && (_MSC_VER >= 1700) && \
+  (defined(__BMI__) || !defined(__clang__)))
 #   define ff_ctz(v) _tzcnt_u32(v)
 
 #   if ARCH_X86_64
-- 
2.15.0.rc0.271.g36b669edcc-goog

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

Re: [FFmpeg-devel] R: [PATCH] MXF format fix for Sony Station compatibility

2017-10-24 Thread Thomas Mundt 
2017-10-24 12:35 GMT+02:00 :

> >From 2a657145a9b6bc2c1beb450100fe2d4d80ee Mon Sep 17 00:00:00 2001
> From: "Axel Technology" 
> Date: Mon, 23 Oct 2017 18:02:58 +0200
> Subject: [PATCH] Sony XDCAM Fix
>
> Signed-off-by: Axel Technology 
> ---
>  libavformat/mxfenc.c | 112 
> ++-
>  1 file changed, 66 insertions(+), 46 deletions(-)
>
>  [...]

> -// MPEG video Descriptor
> -{ 0x8000, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0B,0x00,0x00}},
>  /* BitRate */
> -{ 0x8007, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
>  /* ProfileAndLevel */
> +{ 0x8003, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x05,0x00,0x00}},
>  /* LowDelay */
> +{ 0x8004, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x06,0x00,0x00}},
>  /* ClosedGOP */
> +{ 0x8006, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
>  /* MaxGOP */
> +{ 0x8007, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
>  /* BPictureCount */
> +{ 0x8008, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
>  /* ProfileAndLevel*/
> +{ 0x8009, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0B,0x00,0x00}},
>  /* BitRate */
>
>
You modified the tags for BitRate and ProfileAndLevel, but didn´t adapt the
mxf_write_mpegvideo_desc function. The other UIDs you added aren´t used
elsewhere.
They could be used within the mxf_write_mpegvideo_desc function function,
as Maksym did in his patch.

@@ -1823,7 +1838,6 @@ static const struct {
>  int profile;
>  uint8_t interlaced;
>  } mxf_h264_codec_uls[] = {
> -{{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
>  },  0,  66, 0 }, // AVC Baseline, Unconstrained Coding
>
>
This seems unrelated. In any case AVC Baseline support should not be
dropped.

@@ -2254,6 +2273,7 @@ static void mxf_write_system_item(AVFormatContext *s)
>  avio_w8(pb, 0x00); // content package type
>  avio_wb16(pb, 0x00); // channel handle
>  avio_wb16(pb, (mxf->tc.start + frame) & 0x); // continuity count, 
> supposed to overflow
> +avio_wb16(pb, mxf->last_indexed_edit_unit + mxf->edit_units_count); // 
> continuity count
>
>
This looks wrong to me. Is it intended to write continuity count twice?

But I´m not an mxf expert.
Someone with more experience should have a look at this patch.

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

Re: [FFmpeg-devel] [PATCH]lavc/dvbsub: Allow 256 colour encoding

2017-10-24 Thread Michael Niedermayer 
On Tue, Oct 24, 2017 at 02:04:28AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Trying to encode 256-colour subtitles to dvbsub currently fails in the
> "region" section, a hunk of Joolz' patch was not committed six years
> ago.
> Attached patch has two hunks: The forgotten hunk from the original
> patch and further up a fix that I created now (to be committed
> separately):
> The line separator from the ETSI DVB blue book was missing for rle8 encodings.
> 
> Please comment, Carl Eugen

>  dvbsub.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 66361a461f9ed49d55b7f753243ffd585b647e23  
> 0001-lavc-dvbsub-Allow-256-colour-encoding.patch
> From 06fd4904b6aa04c3ab8e056ef4f6be4a89093a1c Mon Sep 17 00:00:00 2001
> From: JULIAN GARDNER 
> Date: Tue, 24 Oct 2017 01:59:51 +0200
> Subject: [PATCH] lavc/dvbsub: Allow 256 colour encoding.
> 
> Fixes ticket #6769.

probably ok

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom 
On Tue, Oct 24, 2017 at 10:43 PM, James Almer  wrote:
> Maybe first ask what the workaround Nicolas mentioned is about?

This was not meant to push anything on anyone. Just wanted to let him
know what had been come up with elsewhere.

> And preferably don't quote me on this subject. This is not my area of
> expertise and i simply gave a suggestion to keep the old behavior at
> least for a while, assuming this is an API break. And my suggestion was
> in fact the opposite of what everyone else agreed on in the end.

Sorry. It's just that I finally got people talking about it, which as
you can see by this thread is not something happening as much here.
Will not do again. And yes, but you seemed to agree at the end. That
might have just been my misunderstanding.

And yes, I am not an expert on this either. I just knew about the
general breakage and the fact that no actions were yet taken regarding
it, so I tried to start a discussion about alternatives of handling
this.

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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Nicolas George 
Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> You might be very true, but funny enough I just checked the AVIO
> example doc/examples/avio_reading.c, and the read function there does
> not seem to utilize AVERROR_EOF either :) .

The examples are not exempt from mistakes.

> Just for your information, I decided to call people out a bit on the
> IRC channel to see what people would prefer, and it seems like James,
> BtbN and Martin voiced their opinion that they would like a flag that
> would let you enable the 0 != EOF behavior. Additionally, a warning
> would be given out if zero is returned and the flag is unset. Quote
> follows:

> Any opinions?

These people have obviously not thought this through.

As I said, I will try to find time to implement a correct workaround
tomorrow.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread James Almer 
On 10/24/2017 4:37 PM, Jan Ekstrom wrote:
> On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George  wrote:
>> Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
>> I do not consider this a public API change because 0 was never
>> documented as a valid return value for a read_packet callback, while
>> AVERROR_EOF has been around for a long time.
>>
> 
> You might be very true, but funny enough I just checked the AVIO
> example doc/examples/avio_reading.c, and the read function there does
> not seem to utilize AVERROR_EOF either :) .
> 
>> But my goal is not to break existing code on purpose. Fortunately, there
>> is a rather simple workaround, I will try to implement it tomorrow.
>> Still, lacking a simple test case, I will not be able to test it.
>>
> 
> Just for your information, I decided to call people out a bit on the
> IRC channel to see what people would prefer, and it seems like James,
> BtbN and Martin voiced their opinion that they would like a flag that
> would let you enable the 0 != EOF behavior. Additionally, a warning
> would be given out if zero is returned and the flag is unset.

Maybe first ask what the workaround Nicolas mentioned is about?

And preferably don't quote me on this subject. This is not my area of
expertise and i simply gave a suggestion to keep the old behavior at
least for a while, assuming this is an API break. And my suggestion was
in fact the opposite of what everyone else agreed on in the end.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom 
On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> I do not consider this a public API change because 0 was never
> documented as a valid return value for a read_packet callback, while
> AVERROR_EOF has been around for a long time.
>

You might be very true, but funny enough I just checked the AVIO
example doc/examples/avio_reading.c, and the read function there does
not seem to utilize AVERROR_EOF either :) .

> But my goal is not to break existing code on purpose. Fortunately, there
> is a rather simple workaround, I will try to implement it tomorrow.
> Still, lacking a simple test case, I will not be able to test it.
>

Just for your information, I decided to call people out a bit on the
IRC channel to see what people would prefer, and it seems like James,
BtbN and Martin voiced their opinion that they would like a flag that
would let you enable the 0 != EOF behavior. Additionally, a warning
would be given out if zero is returned and the flag is unset. Quote
follows:

> <+JEEB> can anyone else chime on the EOF thing, if we want to
> either A) leave things as they are and just break old
> clients with an API behavior change B) add an option for
> the new behavior , or C) revert the 0 != EOF thing
> <+JEEB> because while those people that are on IRC have most
> likely adapted their stuff, we will have quite a bit of
> breakage due to this :P
> <+JEEB> I'd probably go for B but I'm not sure how many places I'd
> have to poke to add the option
> < jamrial> maybe a temporary option to recover the old behavior
>should be added for the usual period of ~2 years, and a
>notice about it being removed eventually added
> < jamrial> basically, deprecating the old behavior and leaving a
>compat mode for it
> <+JEEB> yes
> < jamrial> library users will nontheless have to update their code
>to enable said option
> < jamrial> then again to remove it two years from now :p
> < jamrial> so dunno
> < jamrial> is this change, unintended breakage aside, a good one?
>because if it doesn't really bring any worthwile
>benefit maybe we should just revert it
> <+JEEB> the requirement for the change was zero-byte UDP packets
> which seem to be valid. originally the code was added into
> the UDP lavf module, but then it was requested to be moved
> into lavf general
> <+JEEB> which thus broke the API behavior
> <@nevcairiel> jamrial: i have always questioned the usefulness of
>   the change, but apparently there is obscure  crazy
>   things that might use it
> <+JEEB> yes, most users don't find that stuff on their networks
> <@nevcairiel> and re: flag, if anything it should be inverted, or
>   its still an API break =p
> <+JEEB> well flag to have the NEW behavior
> <+JEEB> so that the default behavior is the old one
> <+JEEB> that's what I meant
> < jamrial> yeah, probably
> <@BtbN> It should behave as it used to, which is imo a bit broken,
> with some flag somewhere to flip it to sane behaviour
> <+JEEB> BtbN: agreed
> <@BtbN> And it should throw a depercation warning if the flag is
> unset
> <@wbs> alternatively, only throw a warning if the flag is unset
>_and_ you return 0?
> <@wbs> then you can write code that uses AVERROR_EOF for older
>lavf versions without any ifdefs for the new flag, while
>still running without warnings on the new lavf as well

Any opinions?


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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Nicolas George 
Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> The base idea was grasped rather quickly though, which seems to be
> that all API clients utilizing their own IO seem to now require an
> update to their code to return AVERROR_EOF if EOF was hit instead of
> being able to return the number of read bytes, as usual.

I had not considered the case of custom callbacks, indeed.

I do not consider this a public API change because 0 was never
documented as a valid return value for a read_packet callback, while
AVERROR_EOF has been around for a long time.

But my goal is not to break existing code on purpose. Fortunately, there
is a rather simple workaround, I will try to implement it tomorrow.
Still, lacking a simple test case, I will not be able to test it.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom 
On Tue, Oct 24, 2017 at 9:18 PM, Jan Ekstrom  wrote:
> This is a public API change, and I'm not sure if we were planning on
> this. I am not against the fact that zero is no longer implictly EOF,
> but this might have been worth a bit more notice as this does indeed
> break quite a few API clients as noted by nevcairiel as well. If it is
> considered that no further changes are required then I think we at the
> very least want to mention this in the change log as well as the
> doc/APIchanges file.
>

Also as another alternative we might put the new behavior under an
option. Thus those clients that want this behavior can get it, and
otherwise old clients don't just break. Then we can properly deprecate
the option and change the default then. If this makes any darn sense.
Because the final option is a revert and I don't think anyone here
wants that.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

2017-10-24 Thread Pavel Koshevoy 

On 10/24/2017 11:04 AM, Kyle Swanson wrote:

Hi,

On Sun, Sep 4, 2016 at 2:34 PM, Thomas Volkert  wrote:


Hi,

Some guys at the VDD asked for FFmpeg T-shirts.
I'd like to do a new T-shirt order. The shirts could be given to
multimedia devs who stop at one of our next booths.

My idea is to order 25 shirts:

1*S
5*M
10*L
7*XL
2*XXL

Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
So, we are talking about a maximum price of 562,50 Euro (excluding
delivery costs).

If you like or don't like this idea, feel free to leave a comment here.

Best regards,
Thomas.


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


Can I order one too? I wear a size medium. How should I pay you?

Thanks,
Kyle



I've been wondering the same thing.  I'm not a core developer, but I would like 
to purchase a T-shirt with an ffmpeg logo.


Pavel.

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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Jan Ekstrom 
On Tue, Oct 24, 2017 at 8:57 PM, Nicolas George  wrote:
> Le duodi 2 brumaire, an CCXXVI, James Almer a écrit :
>> https://trac.ffmpeg.org/ticket/6767
>
> I do not see in this ticket anything that allows to reproduce the issue
> without a huge amount of foreign code.
>
> Regards,

Hi,

The base idea was grasped rather quickly though, which seems to be
that all API clients utilizing their own IO seem to now require an
update to their code to return AVERROR_EOF if EOF was hit instead of
being able to return the number of read bytes, as usual.

See https://github.com/mpv-player/mpv/pull/5033/files , for example.

This is a public API change, and I'm not sure if we were planning on
this. I am not against the fact that zero is no longer implictly EOF,
but this might have been worth a bit more notice as this does indeed
break quite a few API clients as noted by nevcairiel as well. If it is
considered that no further changes are required then I think we at the
very least want to mention this in the change log as well as the
doc/APIchanges file.

Best regards,
Jan Ekström
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

2017-10-24 Thread Nicolas George 
Le duodi 2 brumaire, an CCXXVI, James Almer a écrit :
> https://trac.ffmpeg.org/ticket/6767

I do not see in this ticket anything that allows to reproduce the issue
without a huge amount of foreign code.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] order T-shirts

2017-10-24 Thread Kyle Swanson 
Hi,

On Sun, Sep 4, 2016 at 2:34 PM, Thomas Volkert  wrote:

> Hi,
>
> Some guys at the VDD asked for FFmpeg T-shirts.
> I'd like to do a new T-shirt order. The shirts could be given to
> multimedia devs who stop at one of our next booths.
>
> My idea is to order 25 shirts:
>
> 1*S
> 5*M
> 10*L
> 7*XL
> 2*XXL
>
> Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
> So, we are talking about a maximum price of 562,50 Euro (excluding
> delivery costs).
>
> If you like or don't like this idea, feel free to leave a comment here.
>
> Best regards,
> Thomas.
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Can I order one too? I wear a size medium. How should I pay you?

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

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

2017-10-24 Thread Bjorn Roche 
On Mon, Oct 23, 2017 at 7:17 PM, Bjorn Roche  wrote:

> On Sat, Oct 21, 2017 at 4:00 PM, Clément Bœsch  wrote:
>
>> On Sat, Oct 21, 2017 at 09:47:47PM +0200, Carl Eugen Hoyos wrote:
>> > 2017-10-21 21:43 GMT+02:00 Clément Bœsch :
>> > > On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
>> > >> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
>> > >>
>> > >> > Aside from these nitpicks, I'm still concerned about how it's going
>> > >> > to conflict with GIF encoding where the transparent color is
>> actually
>> > >> > used as a mean of not updating pixels from previous frames.
>> > >>
>> > >> But is this really related to this patch?
>> > >
>> > > Maybe not, but we need to keep that in mind and not make a
>> > > hasty decision wrt how we handle the transparency, because
>> > > it might makes future related development much harder.
>> >
>> > Given that this is a libavfilter-only patch and we can reproduce
>> > the issue without using libavfilter, I am not completely
>> > convinced, but this is of course your decision.
>> >
>>
>> Yes it should be fine, I just want to be sure that using
>> palettegen/paletteuse will not create input streams that the limited GIF
>> encoder does not handle well because it doesn't make a difference between
>> "transparency flavours". If paletteuse starts inserting transparent colors
>> that are not meant to be used for the frame-diff system it could become a
>> problem.
>>
>
> There is a bug in the GIF encoder. I have a fix for that issue as well.
>

Okay, I've submitted that as well. Still need some feedback, but I believe
it's close.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-10-24 Thread Bjorn Roche 
Support for transparencies in animated gifs requires modifying both
libavcodec/gif.c and libavformat/gif.c because both the graphics
control extension (handled by libavformat/gif.c) and the raw frame data
(handled by libavcodec/gif.c) must be changed. This is because
transparencies in GIF can be used both to create a transparent image,
and to provide optimization.

How transparencies are interpreted in a given frame is controlled by
the “disposal method”, which must be set appropriately in the graphics
control extension.

 The “in place” disposal method is used when transparency indicates
optimization, and the “background” disposal method is used when
transparency is intended to be preserved. In order to support both
disposal methods, libavcodec/gif.c must signal to libavformat/gif.c
which disposal method is required for every frame. This is done with a
new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a
change to avcodec.h

Unfortunately, the addition of a new side data type causes some of the
FATE tests to fail. This is not addressed here.

This patch assumes paletteuse has already been patched to support
transparency. (e.g. lavfi/paletteuse: fix to support transparency)

Feedback I definitely need:
- I’ve done a fair bit of testing, but I’m sure I missed some important
cases.
- I don’t know if/how to update the FATE tests.
---
 libavcodec/avcodec.h |   6 ++
 libavcodec/gif.c | 196 +--
 libavformat/gif.c|  16 -
 3 files changed, 212 insertions(+), 6 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0ca0..82a5328ce1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1599,6 +1599,12 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
 
+/**
+ * The disposal method that should be used with the frame. If missing,
+ * the frame will not be disposed. This contains exactly one byte.
+ */
+AV_PKT_DATA_GIF_FRAME_DISPOSAL,
+
 /**
  * ATSC A53 Part 4 Closed Captions. This metadata should be associated with
  * a video stream. A53 CC bitstream is stored as uint8_t in 
AVPacketSideData.data.
diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index d9c99d52cf..6c839d99d2 100644
--- a/libavcodec/gif.c
+++ b/libavcodec/gif.c
@@ -74,11 +74,35 @@ static int pick_palette_entry(const uint8_t *buf, int 
linesize, int w, int h)
 return -1;
 }
 
-static int gif_image_write_image(AVCodecContext *avctx,
- uint8_t **bytestream, uint8_t *end,
- const uint32_t *palette,
- const uint8_t *buf, const int linesize,
- AVPacket *pkt)
+// returns true if any of the pixels are transparent
+static int is_image_translucent(AVCodecContext *avctx,
+const uint32_t *palette,
+const uint8_t *buf, const int linesize)
+{
+GIFContext *s = avctx->priv_data;
+int trans = s->transparent_index;
+int p;
+const int m = avctx->width * avctx->height ;
+
+if (trans < 0) {
+return 0;
+}
+
+for (p=0; ppriv_data;
 int len = 0, height = avctx->height, width = avctx->width, x, y;
@@ -137,6 +161,11 @@ static int gif_image_write_image(AVCodecContext *avctx,
width, height, x_start, y_start, avctx->width, avctx->height);
 }
 
+uint8_t *frame_disposal = av_packet_new_side_data(pkt, 
AV_PKT_DATA_GIF_FRAME_DISPOSAL, 1);
+if (!frame_disposal)
+return AVERROR(ENOMEM);
+*frame_disposal = GCE_DISPOSAL_INPLACE;
+
 /* image block */
 bytestream_put_byte(bytestream, GIF_IMAGE_SEPARATOR);
 bytestream_put_le16(bytestream, x_start);
@@ -214,6 +243,163 @@ static int gif_image_write_image(AVCodecContext *avctx,
 return 0;
 }
 
+// wrtites an image that may contain transparency
+// this should work for opaque images as well, but will be less optimized.
+static int gif_image_write_translucent(AVCodecContext *avctx,
+   uint8_t **bytestream, uint8_t *end,
+   const uint32_t *palette,
+   const uint8_t *buf, const int linesize,
+   AVPacket *pkt)
+{
+GIFContext *s = avctx->priv_data;
+int len = 0, height =

Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?

2017-10-24 Thread 21naown 

Hello,


Simply to tell you that I no longer support my/this thread, especially 
because as Tobias said it is for an “aesthetic reason”.


wm4 has mentioned “EBML elements”, there is no such element in the 
specifications (if I am not wrong):

https://www.matroska.org/technical/specs/tagging/index.html


I will unsubscribe from this mailing list in one month after the last 
reply to this thread (so I will no longer receive messages from all the 
threads if I am not wrong) since I was here mainly for that.



Best regards.



Le 19/06/2017 à 11:37, Tobias Rapp a écrit :

On 19.06.2017 10:28, wm4 wrote:

On Mon, 19 Jun 2017 09:38:19 +0200
Tobias Rapp  wrote:


On 19.06.2017 02:04, 21na...@gmail.com wrote:

Le 18/06/2017 à 00:57, Sasi Inguva a écrit :

Hi,

I was the one who made that change. We needed a way to obtain 
individual
stream durations from a  Matroska file without reading the entire 
file. I
don't think it adds to the file size greatly (< 50 bytes) compared 
to the

size of video and audio data, hence I didn't hide it under an option.
However if u really need it I can add an option.



Hello,

Yes the size required for the tag “DURATION” is insignificant, but 
it is

preferable to have a choice with this tag like mkvmerge partially does
(because by default “--enable-durations” is enabled, maybe because 
it is

a part of “statistics-tags”, but we can disable them with
“--disable-track-statistics-tags”) and because the end user and his
software do not require it.

Yes if you can move the tag “DURATION” as an optional tag—so an 
argument

is needed to enable it, I will be grateful to you.


I disagree to this tag writing being opt-in. It requires marginal
runtime and storage space resources to write a duration field. The
application used for playback might change or even a new version of the
same application might make use of the tag. So it would be better to
enable it by default.

And for the tag writing being opt-out: Maintaining code also has some
cost. As far as I understand this option would just be required for 
some

aesthetic reason, thus I don't think it's worth adding that maintenance
cost by implementing code to make this tag opt-out.


But there's also this argument that writing these tags is silly, and
that mkvmerge should never have started it. Instead, there should be
proper EBML elements for this.


If there are proper fields for it in the container and they are 
supported by most applications, then yes: it makes no sense to 
duplicate the value into some metadata tag.


Regards,
Tobias


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


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

Re: [FFmpeg-devel] [PATCH v4 2/2] rtp: rfc4175: add handler for YCbCr-4:2:2

2017-10-24 Thread Éloi Bail 
- On Apr 5, 2017, at 6:11 PM, Rostislav Pehlivanov  
wrote: 

> On 31 March 2017 at 16:36, Damien Riegel  > wrote:

> > This adds partial support for the RFC 4175 (raw video over RTP). The
> > only supported formats are the YCbCr-4:2:2 8 bit because it's natively
> > supported by FFmpeg with pixel format UYVY, and 10 bit which requires
> > the vrawdepay codec to convert the payload in a format handled by
> > FFmpeg.

> > Signed-off-by: Damien Riegel 
> > ---
> > Changes in v4:
> > - use strncmp for string comparisons
> > - use AVERROR_INVALIDDATA instead of custom error codes

> > Changes in v3:
> > - rename rawvideo to rfc4175
> > - set pixel format in codec parameters
> > - add additional check to prevent buffer overflow

> > libavformat/Makefile | 1 +
> > libavformat/rtpdec.c | 1 +
> > libavformat/rtpdec_formats.h | 1 +
> > libavformat/rtpdec_rfc4175.c | 236 ++
> > +
> > 4 files changed, 239 insertions(+)
> > create mode 100644 libavformat/rtpdec_rfc4175.c

> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index f56ef16532..a1dae894fe 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -55,6 +55,7 @@ OBJS-$(CONFIG_RTPDEC) += rdt.o
> > \
> > rtpdec_qcelp.o \
> > rtpdec_qdm2.o \
> > rtpdec_qt.o \
> > + rtpdec_rfc4175.o \
> > rtpdec_svq3.o \
> > rtpdec_vc2hq.o \
> > rtpdec_vp8.o \
> > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> > index 53cdad7396..4acb1ca629 100644
> > --- a/libavformat/rtpdec.c
> > +++ b/libavformat/rtpdec.c
> > @@ -114,6 +114,7 @@ void ff_register_rtp_dynamic_payload_handlers(void)
> > ff_register_dynamic_payload_handler(_qt_rtp_vid_handler);
> > ff_register_dynamic_payload_handler(_quicktime_rtp_aud_handler);
> > ff_register_dynamic_payload_handler(_quicktime_rtp_vid_handler);
> > + ff_register_dynamic_payload_handler(_rfc4175_rtp_handler);
> > ff_register_dynamic_payload_handler(_svq3_dynamic_handler);
> > ff_register_dynamic_payload_handler(_theora_dynamic_handler);
> > ff_register_dynamic_payload_handler(_vc2hq_dynamic_handler);
> > diff --git a/libavformat/rtpdec_formats.h b/libavformat/rtpdec_formats.h
> > index 3292a3d265..a436c9d62c 100644
> > --- a/libavformat/rtpdec_formats.h
> > +++ b/libavformat/rtpdec_formats.h
> > @@ -82,6 +82,7 @@ extern RTPDynamicProtocolHandler ff_qt_rtp_aud_handler;
> > extern RTPDynamicProtocolHandler ff_qt_rtp_vid_handler;
> > extern RTPDynamicProtocolHandler ff_quicktime_rtp_aud_handler;
> > extern RTPDynamicProtocolHandler ff_quicktime_rtp_vid_handler;
> > +extern RTPDynamicProtocolHandler ff_rfc4175_rtp_handler;
> > extern RTPDynamicProtocolHandler ff_svq3_dynamic_handler;
> > extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;
> > extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler;
> > diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> > new file mode 100644
> > index 00..498381dfd3
> > --- /dev/null
> > +++ b/libavformat/rtpdec_rfc4175.c
> > @@ -0,0 +1,236 @@
> > +/*
> > + * RTP Depacketization of RAW video (TR-03)
> > + * Copyright (c) 2016 Savoir-faire Linux, Inc
> > + *
> > + * 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
> > + */
> > +
> > +/* Development sponsored by CBC/Radio-Canada */
> > +
> > +#include "avio_internal.h"
> > +#include "rtpdec_formats.h"
> > +#include "libavutil/avstring.h"
> > +#include "libavutil/pixdesc.h"
> > +
> > +struct PayloadContext {
> > + char *sampling;
> > + int depth;
> > + int width;
> > + int height;
> > +
> > + uint8_t *frame;
> > + unsigned int frame_size;
> > + unsigned int pgroup; /* size of the pixel group in bytes */
> > + unsigned int xinc;
> > +
> > + uint32_t timestamp;
> > +};
> > +
> > +static int rfc4175_parse_format(AVStream *stream, PayloadContext *data)
> > +{
> > + enum AVPixelFormat pixfmt = AV_PIX_FMT_NONE;
> > + int bits_per_sample = 0;
> > + int tag = 0;
> > +
> > + if (!strncmp(data->sampling, "YCbCr-4:2:2", 11)) {
> > + tag = MKTAG('U', 'Y', 'V', 'Y');
> > + data->xinc = 2;
> > +
> > + if (data->depth == 8) {
> > + data->pgroup = 4;
> > + bits_per_sample = 16;
> > + pixfmt =

Re: [FFmpeg-devel] [PATCH]lavf/concatdec: Allocate the filenames on the heap

2017-10-24 Thread Nicolas George 
> 2017-10-21 18:29 GMT+02:00 Nicolas George :
> > Yes, exactly. This limitation was the reason I did not bother handling
> > longer lines. I would like to understand how it makes a difference.

The answer is: the filename field in AVFormatContext is not used to open
the file, only the argument to avformat_open_input().

Le decadi 30 vendémiaire, an CCXXVI, Carl Eugen Hoyos a écrit :
> New patch attached, please comment.

It is the same patch, with the memory leak fixed.

What Marton was saying, and I agree with him, is that 50002 is not less
arbitrary than 4096. It seems quite more so, in fact.

You cannot pretend you fixed the issue if you just raised the limit. I
do not oppose this patch per se, but you cannot close ticket #6761,
because if you do so, anybody will provide a concat file that requires
50003 and reopen.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

2017-10-24 Thread Nicolas George 
Le primidi 1er brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> But this is the whole problem. We're stuck in a stalemate between nothing
> and nobody. As with ffserver, we'll keep postponing this forever more until
> the stalemate is broken.
> 
> What incentive is there for anyone to write a replacement for this feature?
> And stack that incentive against the pool of available developers that have
> time and interest in this feature, and what are you left with?
> 
> Nothing.

The problem we have here is a lack of leadership.

We all work on the parts of the code and features that are of interest
to us, but there is nobody with the authority to demand work on the
boring tasks.

It is the kind of problems that grow at an accelerating rate, which is
the reason we did not see much for ~6 years and they are now popping all
over the place. For example, the recent discussion about the output of
statistics filters also showed a lack of leadership.

Note that I am not proposing myself as a leader, by far. A leader should
know the whole code well and have good human skills, and I fail both
conditions.

But we need to start looking for a solution, because otherwise this
project will eventually stagnate and bitrot.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] order T-shirts

2017-10-24 Thread Nicolas George 
Le decadi 30 vendémiaire, an CCXXVI, Thilo Borgmann a écrit :
> Black/white shirts were preferred by the people wearing them during
> CLT for the past few years.
> We had a bright-green/white before that. Dark-green/white might also
> look good. The question of colors is of course all open. However, to
> my experience black is the most favored shirt color for stuff like
> that.

White-on-black, and more generally anything-on-black makes the majority
of nerdish t-shirts out there. A more colorful scheme would stand out
more. But that is only my opinion.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 11, 31, 13 and 33 msa functions

2017-10-24 Thread Manojkumar Bhosale 
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, October 24, 2017 12:39 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 11, 31, 13 and 
33 msa functions

From: Kaustubh Raste 

Remove loops and unroll as block sizes are known.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c |  400 
 1 file changed, 240 insertions(+), 160 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c 
index f11fce8..fcccb98 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -171,23 +171,27 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 out0_m; \
 } )
 
-static void avc_luma_hv_qrt_4w_msa(const uint8_t *src_x, const uint8_t *src_y,
-   int32_t src_stride, uint8_t *dst,
-   int32_t dst_stride, int32_t height)
+static void avc_luma_hv_qrt_4x4_msa(const uint8_t *src_x, const uint8_t *src_y,
+uint8_t *dst, int32_t stride)
 {
-uint32_t loop_cnt;
-v16i8 src_hz0, src_hz1, src_hz2, src_hz3;
-v16i8 src_vt0, src_vt1, src_vt2, src_vt3, src_vt4;
-v16i8 src_vt5, src_vt6, src_vt7, src_vt8;
-v16i8 mask0, mask1, mask2;
-v8i16 hz_out0, hz_out1, vert_out0, vert_out1;
-v8i16 out0, out1;
+const int16_t filt_const0 = 0xfb01;
+const int16_t filt_const1 = 0x1414;
+const int16_t filt_const2 = 0x1fb;
 v16u8 out;
+v16i8 src_hz0, src_hz1, src_hz2, src_hz3, src_vt7, src_vt8;
+v16i8 src_vt0, src_vt1, src_vt2, src_vt3, src_vt4, src_vt5, src_vt6;
+v16i8 src_vt10_r, src_vt32_r, src_vt54_r, src_vt76_r;
+v16i8 mask0, mask1, mask2, filt0, filt1, filt2;
+v8i16 hz_out0, hz_out1, vt_out0, vt_out1, out0, out1;
+
+filt0 = (v16i8) __msa_fill_h(filt_const0);
+filt1 = (v16i8) __msa_fill_h(filt_const1);
+filt2 = (v16i8) __msa_fill_h(filt_const2);
 
 LD_SB3(_mask_arr[48], 16, mask0, mask1, mask2);
 
-LD_SB5(src_y, src_stride, src_vt0, src_vt1, src_vt2, src_vt3, src_vt4);
-src_y += (5 * src_stride);
+LD_SB5(src_y, stride, src_vt0, src_vt1, src_vt2, src_vt3, src_vt4);
+src_y += (5 * stride);
 
 src_vt0 = (v16i8) __msa_insve_w((v4i32) src_vt0, 1, (v4i32) src_vt1);
 src_vt1 = (v16i8) __msa_insve_w((v4i32) src_vt1, 1, (v4i32) src_vt2); @@ 
-196,149 +200,237 @@ static void avc_luma_hv_qrt_4w_msa(const uint8_t *src_x, 
const uint8_t *src_y,
 
 XORI_B4_128_SB(src_vt0, src_vt1, src_vt2, src_vt3);
 
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src_x, src_stride, src_hz0, src_hz1, src_hz2, src_hz3);
-src_x += (4 * src_stride);
-
-XORI_B4_128_SB(src_hz0, src_hz1, src_hz2, src_hz3);
-
-hz_out0 = AVC_XOR_VSHF_B_AND_APPLY_6TAP_HORIZ_FILT_SH(src_hz0,
-  src_hz1, mask0,
-  mask1, mask2);
-hz_out1 = AVC_XOR_VSHF_B_AND_APPLY_6TAP_HORIZ_FILT_SH(src_hz2,
-  src_hz3, mask0,
-  mask1, mask2);
-
-SRARI_H2_SH(hz_out0, hz_out1, 5);
-SAT_SH2_SH(hz_out0, hz_out1, 7);
-
-LD_SB4(src_y, src_stride, src_vt5, src_vt6, src_vt7, src_vt8);
-src_y += (4 * src_stride);
-
-src_vt4 = (v16i8) __msa_insve_w((v4i32) src_vt4, 1, (v4i32) src_vt5);
-src_vt5 = (v16i8) __msa_insve_w((v4i32) src_vt5, 1, (v4i32) src_vt6);
-src_vt6 = (v16i8) __msa_insve_w((v4i32) src_vt6, 1, (v4i32) src_vt7);
-src_vt7 = (v16i8) __msa_insve_w((v4i32) src_vt7, 1, (v4i32) src_vt8);
-
-XORI_B4_128_SB(src_vt4, src_vt5, src_vt6, src_vt7);
+LD_SB4(src_x, stride, src_hz0, src_hz1, src_hz2, src_hz3);
+XORI_B4_128_SB(src_hz0, src_hz1, src_hz2, src_hz3);
+hz_out0 = AVC_HORZ_FILTER_SH(src_hz0, src_hz1, mask0, mask1, mask2);
+hz_out1 = AVC_HORZ_FILTER_SH(src_hz2, src_hz3, mask0, mask1, 
+ mask2);
 
-/* filter calc */
-vert_out0 = AVC_CALC_DPADD_B_6PIX_2COEFF_R_SH(src_vt0, src_vt1,
-  src_vt2, src_vt3,
-  src_vt4, src_vt5);
-vert_out1 = AVC_CALC_DPADD_B_6PIX_2COEFF_R_SH(src_vt2, src_vt3,
-  src_vt4, src_vt5,
-  src_vt6, src_vt7);
+SRARI_H2_SH(hz_out0, hz_out1, 5);
+SAT_SH2_SH(hz_out0, hz_out1, 7);
 
-SRARI_H2_SH(vert_out0, vert_out1, 5);
-SAT_SH2_SH(vert_out0, vert_out1, 7);
+LD_SB4(src_y, stride, src_vt5, src_vt6,

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted hv mc msa functions

2017-10-24 Thread Manojkumar Bhosale 
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, October 24, 2017 12:42 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted hv mc 
msa functions

From: Kaustubh Raste 

Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_biw_msa.c   |  706 ++-
 libavutil/mips/generic_macros_msa.h |   35 ++
 2 files changed, 489 insertions(+), 252 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_biw_msa.c 
b/libavcodec/mips/hevc_mc_biw_msa.c
index 05a28ec..458e73d 100644
--- a/libavcodec/mips/hevc_mc_biw_msa.c
+++ b/libavcodec/mips/hevc_mc_biw_msa.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015 Manojkumar Bhosale (manojkumar.bhos...@imgtec.com)
+ * Copyright (c) 2015 - 2017 Manojkumar Bhosale 
+ (manojkumar.bhos...@imgtec.com)
  *
  * This file is part of FFmpeg.
  *
@@ -22,6 +22,12 @@
 #include "libavcodec/mips/hevcdsp_mips.h"
 #include "libavcodec/mips/hevc_macros_msa.h"
 
+static const uint8_t ff_hevc_mask_arr[16 * 2] __attribute__((aligned(0x40))) = 
{
+/* 8 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
+0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+
 #define HEVC_BIW_RND_CLIP2(in0, in1, vec0, vec1, wgt, rnd, offset,  \
out0_r, out1_r, out0_l, out1_l)  \
 {   \
@@ -1831,23 +1837,23 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 int32_t rnd_val)  {
 uint32_t loop_cnt;
-int32_t offset;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
-v8i16 in0, in1;
+uint64_t tp0, tp1;
+int32_t offset, weight;
+v16u8 out;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8, src9, src10;
+v8i16 in0 = { 0 }, in1 = { 0 };
 v8i16 filt0, filt1, filt2, filt3;
-v4i32 filt_h0, filt_h1, filt_h2, filt_h3;
+v8i16 filt_h0, filt_h1, filt_h2, filt_h3;
 v16i8 mask1, mask2, mask3;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec, weight_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
 v16i8 vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15;
 v8i16 dst30, dst41, dst52, dst63, dst66, dst87;
-v4i32 dst0_r, dst1_r;
-v4i32 tmp1, tmp2;
-v4i32 weight_vec0, weight_vec1, offset_vec, rnd_vec;
-v8i16 dst10_r, dst32_r, dst54_r, dst76_r;
-v8i16 dst21_r, dst43_r, dst65_r, dst87_r;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
-v8u16 mask4 = { 0, 4, 1, 5, 2, 6, 3, 7 };
+v8i16 tmp0, tmp1, tmp2, tmp3;
+v8i16 dst10, dst32, dst54, dst76;
+v8i16 dst21, dst43, dst65, dst97, dst108, dst109, dst98;
+v4i32 offset_vec, rnd_vec, const_vec, dst0, dst1, dst2, dst3;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 
 src0_ptr -= ((3 * src_stride) + 3);
 
@@ -1855,10 +1861,9 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 SPLATI_H4_SH(filter_vec, 0, 1, 2, 3, filt0, filt1, filt2, filt3);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W4_SW(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
+SPLATI_W4_SH(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
 
 mask1 = mask0 + 2;
 mask2 = mask0 + 4;
@@ -1866,13 +1871,14 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 
 offset = (offset0 + offset1) << rnd_val;
 weight0 = weight0 & 0x;
+weight = weight0 | (weight1 << 16);
 
-const_vec = __msa_ldi_h(128);
+const_vec = __msa_fill_w((128 * weight1));
 const_vec <<= 6;
 offset_vec = __msa_fill_w(offset);
-weight_vec0 = __msa_fill_w(weight0);
-weight_vec1 = __msa_fill_w(weight1);
 rnd_vec = __msa_fill_w(rnd_val + 1);
+offset_vec += const_vec;
+weight_vec = (v8i16) __msa_fill_w(weight);
 
 LD_SB7(src0_ptr, src_stride, src0, src1, src2, src3, src4, src5, src6);
 src0_ptr += (7 * src_stride);
@@ -1886,70 +1892,77 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 VSHF_B4_SB(src3, src6, mask0, mask1, mask2, mask3,
vec12, vec13, vec14, vec15);
 
-dst30 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst30, dst30, dst30, dst30);
-dst41 = const_vec;
-DPADD_SB4_SH(vec4, vec5, vec6, vec7, filt0, filt1, filt2, filt3,
- dst41, dst41, dst41, dst41);
-dst52 = const_vec;
-DPADD_SB4_SH(vec8, vec9, vec10, vec11, filt0, filt1, filt2, filt3,
- dst52, dst52, dst52, dst52);
-dst63 = const_vec;
-DPADD_SB4_SH(vec12,

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma copy and avg vert mc msa functions

2017-10-24 Thread Manojkumar Bhosale 
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, October 24, 2017 12:41 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma copy and avg 
vert mc msa functions

From: Kaustubh Raste 

Replace generic with block size specific function.
Load the specific destination bytes instead of MSA load and pack.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264chroma_msa.c |  627 +-
 1 file changed, 275 insertions(+), 352 deletions(-)

diff --git a/libavcodec/mips/h264chroma_msa.c b/libavcodec/mips/h264chroma_msa.c
index 2a54675..a5c3334 100644
--- a/libavcodec/mips/h264chroma_msa.c
+++ b/libavcodec/mips/h264chroma_msa.c
@@ -1124,24 +1124,25 @@ static void avc_chroma_hz_and_aver_dst_8w_msa(uint8_t 
*src, uint8_t *dst,
 }
 }
 
-static void avc_chroma_vt_and_aver_dst_2x2_msa(uint8_t *src, int32_t 
src_stride,
-   uint8_t *dst, int32_t 
dst_stride,
-   uint32_t coeff0, uint32_t 
coeff1)
+static void avc_chroma_vt_and_aver_dst_2x2_msa(uint8_t *src, uint8_t *dst,
+   int32_t stride, uint32_t coeff0,
+   uint32_t coeff1)
 {
 uint16_t out0, out1;
-uint32_t load0, load1;
 v16i8 src0, src1, src2, tmp0, tmp1, res;
 v16u8 dst_data = { 0 };
+v8i16 out;
 v8u16 res_r;
 v16i8 coeff_vec0 = __msa_fill_b(coeff0);
 v16i8 coeff_vec1 = __msa_fill_b(coeff1);
 v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
 
-LD_SB3(src, src_stride, src0, src1, src2);
-load0 = LW(dst);
-load1 = LW(dst + dst_stride);
+LD_SB3(src, stride, src0, src1, src2);
+out0 = LH(dst);
+out1 = LH(dst + stride);
 
-INSERT_W2_UB(load0, load1, dst_data);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 0, out0);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 2, out1);
 
 ILVR_B2_SB(src1, src0, src2, src1, tmp0, tmp1);
 
@@ -1151,20 +1152,20 @@ static void avc_chroma_vt_and_aver_dst_2x2_msa(uint8_t 
*src, int32_t src_stride,
 res_r = (v8u16) __msa_srari_h((v8i16) res_r, 6);
 res_r = __msa_sat_u_h(res_r, 7);
 res = __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
-dst_data = __msa_aver_u_b((v16u8) res, dst_data);
-out0 = __msa_copy_u_h((v8i16) dst_data, 0);
-out1 = __msa_copy_u_h((v8i16) dst_data, 2);
+out = (v8i16) __msa_aver_u_b((v16u8) res, dst_data);
+out0 = __msa_copy_u_h(out, 0);
+out1 = __msa_copy_u_h(out, 2);
 
 SH(out0, dst);
-dst += dst_stride;
+dst += stride;
 SH(out1, dst);
 }
 
-static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t *src, int32_t 
src_stride,
-   uint8_t *dst, int32_t 
dst_stride,
-   uint32_t coeff0, uint32_t 
coeff1)
+static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t *src, uint8_t *dst,
+   int32_t stride, uint32_t coeff0,
+   uint32_t coeff1)
 {
-uint32_t load0, load1;
+uint16_t tp0, tp1, tp2, tp3;
 v16i8 src0, src1, src2, src3, src4;
 v16u8 tmp0, tmp1, tmp2, tmp3;
 v8u16 res_r;
@@ -1174,19 +1175,16 @@ static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t 
*src, int32_t src_stride,
 v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
 v16u8 dst_data = { 0 };
 
-LD_SB5(src, src_stride, src0, src1, src2, src3, src4);
-
-load0 = LW(dst);
-load1 = LW(dst + dst_stride);
-
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 0, load0);
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 1, load1);
+LD_SB5(src, stride, src0, src1, src2, src3, src4);
 
-load0 = LW(dst + 2 * dst_stride);
-load1 = LW(dst + 3 * dst_stride);
-
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 2, load0);
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 3, load1);
+tp0 = LH(dst);
+tp1 = LH(dst + stride);
+tp2 = LH(dst + 2 * stride);
+tp3 = LH(dst + 3 * stride);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 0, tp0);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 1, tp1);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 2, tp2);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 3, tp3);
 
 ILVR_B4_UB(src1, src0, src2, src1, src3, src2, src4, src3,
tmp0, tmp1, tmp2, tmp3); @@ -1202,102 +1200,26 @@ static void 
avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t *src, int32_t src_stride,
 res = (v8i16) __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
 res = (v8i16) __msa_aver_u_b((v16u8) res, dst_data);
 
-ST2x4_UB(res, 0, dst, dst_stride);
-dst += (4 *

[FFmpeg-devel] HEVC parser - few small bugs and style issues

2017-10-24 Thread Eran Kornblau 
Hi all,

I did some work around parsing HEVC headers, and while looking at ffmpeg's 
implementation, I noticed
a few bugs and a few style issues. I'm not submitting a patch, since my 
familiarity with the decoder is
very limited, but hopefully the maintainers will go over the list below and 
change what is needed.
I marked the two items I find most important with '>>>'.

hevc_ps.c
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_ps.c#L117
 k1 is unused

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_ps.c#L142
  rps_ridx = >st_rps[rps - sps->st_rps - 1];
 this is equivalent to simply rps_ridx = sps - 1;

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_ps.c#L156
  use_delta_flag = get_bits1(gb);
>>>  missing else use_delta_flag = 1 (according to the 
>>> spec, this is the default value of this field)

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_ps.c#L182
  if (rps->num_delta_pocs != 0) {
 the if is redundant, the for loop won't enter 
anyway

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_ps.c#L198
  if ((rps->num_negative_pics >> 1) != 0) {
 the if is redundant, the for loop won't enter 
anyway

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_ps.c#L234
  prev -= delta_poc;
 prev is unsigned and initialized to 0, so it will 
become negative here
 type should probably be changed to int

hevc_refs.c
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc_refs.c#L522
for (i = 0; i < rps->num_negative_pics; i++)
ret += !!rps->used[i];
for (; i < rps->num_delta_pocs; i++)
ret += !!rps->used[i];
 can combine to a single for loop 
(rps->num_delta_pocs = rps->num_negative_pics + nb_positive_pics;)
 also, 'used' is always coming from get_bits1(gb) 
so the !! seems unneeded

hevcdec.c
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevcdec.c#L604
  sh->short_term_rps = >ps.sps->st_rps[rps_idx];
>>>  need to return error in case rps_idx >= 
>>> s->ps.sps->nb_st_rps
 (don't think if it can overflow the array, but it 
can reference an uninitialized rps)

Thanks

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

2017-10-24 Thread Michael Niedermayer 
On Mon, Oct 23, 2017 at 10:36:21PM -0300, James Almer wrote:
> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
> > On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
> >> On 24/10/17 00:52, Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
>  On 23/10/17 03:56, Michael Niedermayer wrote:
> > the initialization should be thread safe as it never writes a different
> > value in the same spot
> 
>  This is not true; please be very careful with assumptions like this.
> 
>  The C standard calls this a data race and it is undefined behaviour.
> >>>
> >>> Thats interresting, we definitly do not want undefined behavior
> >>> can you quote the relevant parts of the C standard
> >>> which make writing the same value, a data race ?
> >>>
> >>> I was not aware of this if its true.
> >>> Also i dont immedeatly see this in the "latest" draft i am looking at
> >>> atm
> >>>
> >>> What i see is this:
> >>> 4 Two expression evaluations conflict if one of them modifies a memory 
> >>> location and the
> >>>   other one reads or modifies the same memory location.
> >>> ...
> >>> 25 The execution of a program contains a data race if it contains two 
> >>> conflicting actions in
> >>>different threads, at least one of which is not atomic, and neither 
> >>> happens before the
> >>>other. Any such data race results in undefined behavior.
> >>>
> >>> This seems carefully worded to not include writing the same value.
> >>> As "modification" implies change which does not occur when writing the
> >>> same value.
> >>
> >> All writes are modifications.
> >>
> >> See section 3.1 note 2:
> >> """
> >> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored 
> >> is the same as the previous value.
> >> """
> > 
> > That resolves the difference between our interpretation
> > 
> > thanks
> 
> Should i push this, or does someone want to give ff_thread_once() a try?

If ff_thread_once() is used outside init code, it should be benchmarked
as it may be a bad idea speed wise.
During init speed doesnt matter so ff_thread_once() there would be fine
but would require more changes to move it to init.

I have no oppinion about ff_thread_once() vs hardcoding ATM

thx

[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] R: [PATCH] MXF format fix for Sony Station compatibility

2017-10-24 Thread Maksym Veremeyenko 

24.10.2017 13:35, developm...@axeltechnology.com пише:

The patch contains trailing whitespace and tabs, both cannot be committed to 
the FFmpeg repository.
You can use tools/patcheck to find the issues.


Cleaned up the spaces/tabs and added braces around else statemens.


similar patchset was proposed early (with more descriptors):
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193395.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/194829.html

--
Maksym Veremeyenko

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

[FFmpeg-devel] R: [PATCH] MXF format fix for Sony Station compatibility

2017-10-24 Thread Development 
>The patch contains trailing whitespace and tabs, both cannot be committed to 
>the FFmpeg repository.
>You can use tools/patcheck to find the issues.

Cleaned up the spaces/tabs and added braces around else statemens.


> +mxf_write_local_tag(pb, 4, 0x3308);
> +if (st->codec->pix_fmt == AV_PIX_FMT_YUV420P)
> +avio_wb32(pb, 2);
> +else
> +avio_wb32(pb, 1);

>This looks a little suspicious:
>What does "2" mean, what does "1" mean?

Added v_chroma_sub_sample variable instead of '1' and '2' as you suggested.


>Is there a reason why this patch does not name an author?

We are a team of developers and worked together on this patch


>Thank you, Carl Eugen

Thank you for your time
Axel Technology development team




0001-Sony-XDCAM-Fix.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value

2017-10-24 Thread Tobias Rapp 
According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.

Fix the issue by writing the "unknown" value (-1) for now until the
feature is implemented correctly.

Previous version reviewed-by: Peter Bubestinger 
Signed-off-by: Tobias Rapp 
---
v2:
 - added version micro bump
 - more code clean-up

 libavformat/version.h|  2 +-
 libavformat/wavenc.c | 11 +--
 tests/ref/lavf/wav_peak  |  2 +-
 tests/ref/lavf/wav_peak_only |  2 +-
 4 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/libavformat/version.h b/libavformat/version.h
index 0feb788..8ae091f 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR   0
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index adb20cb..159119d 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -74,8 +74,6 @@ typedef struct WAVMuxContext {
 uint32_t peak_num_frames;
 uint32_t peak_outbuf_size;
 uint32_t peak_outbuf_bytes;
-uint32_t peak_pos_pop;
-uint16_t peak_pop;
 uint8_t *peak_output;
 int last_duration;
 int write_bext;
@@ -195,7 +193,6 @@ static void peak_write_frame(AVFormatContext *s)
 {
 WAVMuxContext *wav = s->priv_data;
 AVCodecParameters *par = s->streams[0]->codecpar;
-int peak_of_peaks;
 int c;
 
 if (!wav->peak_output)
@@ -213,12 +210,6 @@ static void peak_write_frame(AVFormatContext *s)
 wav->peak_maxpos[c] =
 FFMAX(wav->peak_maxpos[c], wav->peak_maxneg[c]);
 
-peak_of_peaks = FFMAX3(wav->peak_maxpos[c], wav->peak_maxneg[c],
-   wav->peak_pop);
-if (peak_of_peaks > wav->peak_pop)
-wav->peak_pos_pop = wav->peak_num_frames;
-wav->peak_pop = peak_of_peaks;
-
 if (wav->peak_outbuf_size - wav->peak_outbuf_bytes <
 wav->peak_format * wav->peak_ppv) {
 wav->peak_outbuf_size += PEAK_BUFFER_SIZE;
@@ -287,7 +278,7 @@ static int peak_write_chunk(AVFormatContext *s)
 avio_wl32(pb, wav->peak_block_size);/* frames per value */
 avio_wl32(pb, par->channels);   /* number of channels */
 avio_wl32(pb, wav->peak_num_frames);/* number of peak frames */
-avio_wl32(pb, wav->peak_pos_pop);   /* audio sample frame index */
+avio_wl32(pb, -1);  /* audio sample frame position 
(not implemented) */
 avio_wl32(pb, 128); /* equal to size of header */
 avio_write(pb, timestamp, 28);  /* ASCII time stamp */
 ffio_fill(pb, 0, 60);
diff --git a/tests/ref/lavf/wav_peak b/tests/ref/lavf/wav_peak
index aa7e5fc..861b246 100644
--- a/tests/ref/lavf/wav_peak
+++ b/tests/ref/lavf/wav_peak
@@ -1,3 +1,3 @@
-35148d1f6e66b0080893851d917ecbf4 *./tests/data/lavf/lavf.peak.wav
+105805963fb767d00da056f42f32d9f3 *./tests/data/lavf/lavf.peak.wav
 89094 ./tests/data/lavf/lavf.peak.wav
 ./tests/data/lavf/lavf.peak.wav CRC=0x3a1da17e
diff --git a/tests/ref/lavf/wav_peak_only b/tests/ref/lavf/wav_peak_only
index dccd0e7..b203d03 100644
--- a/tests/ref/lavf/wav_peak_only
+++ b/tests/ref/lavf/wav_peak_only
@@ -1,2 +1,2 @@
-b609a363e6d490710ed52231a8d09d3c *./tests/data/lavf/lavf.peak_only.wav
+f1a8aeeae8069f3992c4d780436c3d23 *./tests/data/lavf/lavf.peak_only.wav
 832 ./tests/data/lavf/lavf.peak_only.wav
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

2017-10-24 Thread Muhammad Faiz 
On Tue, Oct 24, 2017 at 8:36 AM, James Almer  wrote:
> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
>> On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
>>> On 24/10/17 00:52, Michael Niedermayer wrote:
 Hi

 On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
> On 23/10/17 03:56, Michael Niedermayer wrote:
>> the initialization should be thread safe as it never writes a different
>> value in the same spot
>
> This is not true; please be very careful with assumptions like this.
>
> The C standard calls this a data race and it is undefined behaviour.

 Thats interresting, we definitly do not want undefined behavior
 can you quote the relevant parts of the C standard
 which make writing the same value, a data race ?

 I was not aware of this if its true.
 Also i dont immedeatly see this in the "latest" draft i am looking at
 atm

 What i see is this:
 4 Two expression evaluations conflict if one of them modifies a memory 
 location and the
   other one reads or modifies the same memory location.
 ...
 25 The execution of a program contains a data race if it contains two 
 conflicting actions in
different threads, at least one of which is not atomic, and neither 
 happens before the
other. Any such data race results in undefined behavior.

 This seems carefully worded to not include writing the same value.
 As "modification" implies change which does not occur when writing the
 same value.
>>>
>>> All writes are modifications.
>>>
>>> See section 3.1 note 2:
>>> """
>>> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored is 
>>> the same as the previous value.
>>> """
>>
>> That resolves the difference between our interpretation
>>
>> thanks
>
> Should i push this, or does someone want to give ff_thread_once() a try?

I've posted a patch.

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

[FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

2017-10-24 Thread Muhammad Faiz 
Fix tsan warnings.

Signed-off-by: Muhammad Faiz 
---
 libavutil/crc.c | 49 +
 1 file changed, 29 insertions(+), 20 deletions(-)

diff --git a/libavutil/crc.c b/libavutil/crc.c
index 495732b163..d44550c9c0 100644
--- a/libavutil/crc.c
+++ b/libavutil/crc.c
@@ -20,6 +20,8 @@
 
 #include "config.h"
 
+#include "thread.h"
+#include "avassert.h"
 #include "bswap.h"
 #include "common.h"
 #include "crc.h"
@@ -291,20 +293,24 @@ static const AVCRC av_crc_table[AV_CRC_MAX][257] = {
 #else
 #define CRC_TABLE_SIZE 1024
 #endif
-static struct {
-uint8_t  le;
-uint8_t  bits;
-uint32_t poly;
-} av_crc_table_params[AV_CRC_MAX] = {
-[AV_CRC_8_ATM]  = { 0,  8,   0x07 },
-[AV_CRC_16_ANSI]= { 0, 16, 0x8005 },
-[AV_CRC_16_CCITT]   = { 0, 16, 0x1021 },
-[AV_CRC_24_IEEE]= { 0, 24,   0x864CFB },
-[AV_CRC_32_IEEE]= { 0, 32, 0x04C11DB7 },
-[AV_CRC_32_IEEE_LE] = { 1, 32, 0xEDB88320 },
-[AV_CRC_16_ANSI_LE] = { 1, 16, 0xA001 },
-};
 static AVCRC av_crc_table[AV_CRC_MAX][CRC_TABLE_SIZE];
+
+#define DECLARE_CRC_INIT_TABLE_ONCE(id, le, bits, poly)
   \
+static AVOnce id ## _once_control = AV_ONCE_INIT;  
   \
+static void id ## _init_table_once(void)   
   \
+{  
   \
+av_assert0(av_crc_init(av_crc_table[id], le, bits, poly, 
sizeof(av_crc_table[id])) >= 0); \
+}
+
+#define CRC_INIT_TABLE_ONCE(id) ff_thread_once( ## _once_control, id ## 
_init_table_once)
+
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_8_ATM,  0,  8,   0x07)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI,0, 16, 0x8005)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_CCITT,   0, 16, 0x1021)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_24_IEEE,0, 24,   0x864CFB)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE,0, 32, 0x04C11DB7)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE_LE, 1, 32, 0xEDB88320)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI_LE, 1, 16, 0xA001)
 #endif
 
 int av_crc_init(AVCRC *ctx, int le, int bits, uint32_t poly, int ctx_size)
@@ -343,13 +349,16 @@ int av_crc_init(AVCRC *ctx, int le, int bits, uint32_t 
poly, int ctx_size)
 const AVCRC *av_crc_get_table(AVCRCId crc_id)
 {
 #if !CONFIG_HARDCODED_TABLES
-if (!av_crc_table[crc_id][FF_ARRAY_ELEMS(av_crc_table[crc_id]) - 1])
-if (av_crc_init(av_crc_table[crc_id],
-av_crc_table_params[crc_id].le,
-av_crc_table_params[crc_id].bits,
-av_crc_table_params[crc_id].poly,
-sizeof(av_crc_table[crc_id])) < 0)
-return NULL;
+switch (crc_id) {
+case AV_CRC_8_ATM:  CRC_INIT_TABLE_ONCE(AV_CRC_8_ATM); break;
+case AV_CRC_16_ANSI:CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI); break;
+case AV_CRC_16_CCITT:   CRC_INIT_TABLE_ONCE(AV_CRC_16_CCITT); break;
+case AV_CRC_24_IEEE:CRC_INIT_TABLE_ONCE(AV_CRC_24_IEEE); break;
+case AV_CRC_32_IEEE:CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE); break;
+case AV_CRC_32_IEEE_LE: CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE_LE); break;
+case AV_CRC_16_ANSI_LE: CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI_LE); break;
+default: av_assert0(0);
+}
 #endif
 return av_crc_table[crc_id];
 }
-- 
2.13.2

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

[FFmpeg-devel] [PATCH 1/2] swscale: fix dithers table for DITHER_COPY macro

2017-10-24 Thread Mateusz 
The Bayer matrix 8x8 used in DITHER_COPY macro is table dithers[5].
Remaining dithers[] matrixes are generated from this matrix by
downshift or upshift.

This patch fixes dithers[6] and dithers[7] matrixes -- they were
too dark.

Signed-off-by: Mateusz Brzostek 
---
 libswscale/swscale_unscaled.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 5d81cd5af9..6ffde1ec59 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -90,15 +90,6 @@ DECLARE_ALIGNED(8, static const uint8_t, dithers)[8][8][8]={
   {  48,  0, 60, 12, 51,  3, 63, 15,},
   {  24, 40, 20, 36, 27, 43, 23, 39,},
   {  56,  8, 52,  4, 59, 11, 55,  7,},
-},{
-  {  18, 34, 30, 46, 17, 33, 29, 45,},
-  {  50,  2, 62, 14, 49,  1, 61, 13,},
-  {  26, 42, 22, 38, 25, 41, 21, 37,},
-  {  58, 10, 54,  6, 57,  9, 53,  5,},
-  {  16, 32, 28, 44, 19, 35, 31, 47,},
-  {  48,  0, 60, 12, 51,  3, 63, 15,},
-  {  24, 40, 20, 36, 27, 43, 23, 39,},
-  {  56,  8, 52,  4, 59, 11, 55,  7,},
 },{
   {  36, 68, 60, 92, 34, 66, 58, 90,},
   { 100,  4,124, 28, 98,  2,122, 26,},
@@ -108,6 +99,15 @@ DECLARE_ALIGNED(8, static const uint8_t, dithers)[8][8][8]={
   {  96,  0,120, 24,102,  6,126, 30,},
   {  48, 80, 40, 72, 54, 86, 46, 78,},
   { 112, 16,104,  8,118, 22,110, 14,},
+},{
+  {  72,136,120,184, 68,132,116,180,},
+  { 200,  8,248, 56,196,  4,244, 52,},
+  { 104,168, 88,152,100,164, 84,148,},
+  { 232, 40,216, 24,228, 36,212, 20,},
+  {  64,128,112,176, 76,140,124,188,},
+  { 192,  0,240, 48,204, 12,252, 60,},
+  {  96,160, 80,144,108,172, 92,156,},
+  { 224, 32,208, 16,236, 44,220, 28,},
 }};
 
 
-- 
2.14.2.windows.3

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

[FFmpeg-devel] [PATCH 2/2] swscale: use dithering in DITHER_COPY only if not set -sws_dither none

2017-10-24 Thread Mateusz 
This patch uses dithering in DITHER_COPY macro only if
it was not used option '-sws_dither none'.
With option '-sws_dither none' it uses downshift.

For human eye dithering is OK, for video codecs not necessarily.
If user don't want to use dithering, we should respect that.

Signed-off-by: Mateusz Brzostek 
---
 libswscale/swscale_unscaled.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 6ffde1ec59..01d6d653bc 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1485,7 +1485,25 @@ static int packedCopyWrapper(SwsContext *c, const 
uint8_t *src[],
 
 #define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
 unsigned shift= src_depth-dst_depth, tmp;\
-if (shiftonly) {\
+if (c->dither == SWS_DITHER_NONE) {\
+for (i = 0; i < height; i++) {\
+for (j = 0; j < length-7; j+=8) {\
+dst[j+0] = dbswap(bswap(src[j+0])>>shift);\
+dst[j+1] = dbswap(bswap(src[j+1])>>shift);\
+dst[j+2] = dbswap(bswap(src[j+2])>>shift);\
+dst[j+3] = dbswap(bswap(src[j+3])>>shift);\
+dst[j+4] = dbswap(bswap(src[j+4])>>shift);\
+dst[j+5] = dbswap(bswap(src[j+5])>>shift);\
+dst[j+6] = dbswap(bswap(src[j+6])>>shift);\
+dst[j+7] = dbswap(bswap(src[j+7])>>shift);\
+}\
+for (; j < length; j++) {\
+dst[j] = dbswap(bswap(src[j])>>shift);\
+}\
+dst += dstStride;\
+src += srcStride;\
+}\
+} else if (shiftonly) {\
 for (i = 0; i < height; i++) {\
 const uint8_t *dither= dithers[shift-1][i&7];\
 for (j = 0; j < length-7; j+=8) {\
-- 
2.14.2.windows.3

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-10-24 Thread Li, Zhong 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Liu Steven
> Sent: Tuesday, October 24, 2017 3:28 PM
> To: and patches development discussions FFmpeg
> 
> Cc: Liu Steven 
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant
> streams with master playlist in a single hlsenc instance
> 
> 
> > 在 2017年10月24日，下午2:00，Dixit, Vishwanath 
> 写道：
> >
> >> On 10/22/17, 1:28 PM, "Liu Steven"  wrote:
> >> Two patches should be ok, add FATE cases please :)
> > I am not familiar with FATE and I could not find any sample hlsenc FATE
> cases in ffmpeg workspace. Could you please help me with this? If some
> basic hlsenc tests are available, I can extend them further for variant stream
> creation and master playlist creation.
> 
> tests/fate/filter-audio.mak
> reference it

Not sure this can help or not: https://trac.ffmpeg.org/wiki/FATE/AddingATest 

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-10-24 Thread Liu Steven 

> 在 2017年10月24日，下午2:00，Dixit, Vishwanath  写道：
> 
>> On 10/22/17, 1:28 PM, "Liu Steven"  wrote:
>> Two patches should be ok, add FATE cases please :)
> I am not familiar with FATE and I could not find any sample hlsenc FATE cases 
> in ffmpeg workspace. Could you please help me with this? If some basic hlsenc 
> tests are available, I can extend them further for variant stream creation 
> and master playlist creation.

tests/fate/filter-audio.mak
reference it
> 
> Regards,
> Vishwanath
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

[FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted hv mc msa functions

2017-10-24 Thread kaustubh.raste 
From: Kaustubh Raste 

Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_biw_msa.c   |  706 ++-
 libavutil/mips/generic_macros_msa.h |   35 ++
 2 files changed, 489 insertions(+), 252 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_biw_msa.c 
b/libavcodec/mips/hevc_mc_biw_msa.c
index 05a28ec..458e73d 100644
--- a/libavcodec/mips/hevc_mc_biw_msa.c
+++ b/libavcodec/mips/hevc_mc_biw_msa.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015 Manojkumar Bhosale (manojkumar.bhos...@imgtec.com)
+ * Copyright (c) 2015 - 2017 Manojkumar Bhosale (manojkumar.bhos...@imgtec.com)
  *
  * This file is part of FFmpeg.
  *
@@ -22,6 +22,12 @@
 #include "libavcodec/mips/hevcdsp_mips.h"
 #include "libavcodec/mips/hevc_macros_msa.h"
 
+static const uint8_t ff_hevc_mask_arr[16 * 2] __attribute__((aligned(0x40))) = 
{
+/* 8 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
+0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
+};
+
 #define HEVC_BIW_RND_CLIP2(in0, in1, vec0, vec1, wgt, rnd, offset,  \
out0_r, out1_r, out0_l, out1_l)  \
 {   \
@@ -1831,23 +1837,23 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 int32_t rnd_val)
 {
 uint32_t loop_cnt;
-int32_t offset;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
-v8i16 in0, in1;
+uint64_t tp0, tp1;
+int32_t offset, weight;
+v16u8 out;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8, src9, src10;
+v8i16 in0 = { 0 }, in1 = { 0 };
 v8i16 filt0, filt1, filt2, filt3;
-v4i32 filt_h0, filt_h1, filt_h2, filt_h3;
+v8i16 filt_h0, filt_h1, filt_h2, filt_h3;
 v16i8 mask1, mask2, mask3;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec, weight_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
 v16i8 vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15;
 v8i16 dst30, dst41, dst52, dst63, dst66, dst87;
-v4i32 dst0_r, dst1_r;
-v4i32 tmp1, tmp2;
-v4i32 weight_vec0, weight_vec1, offset_vec, rnd_vec;
-v8i16 dst10_r, dst32_r, dst54_r, dst76_r;
-v8i16 dst21_r, dst43_r, dst65_r, dst87_r;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
-v8u16 mask4 = { 0, 4, 1, 5, 2, 6, 3, 7 };
+v8i16 tmp0, tmp1, tmp2, tmp3;
+v8i16 dst10, dst32, dst54, dst76;
+v8i16 dst21, dst43, dst65, dst97, dst108, dst109, dst98;
+v4i32 offset_vec, rnd_vec, const_vec, dst0, dst1, dst2, dst3;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 
 src0_ptr -= ((3 * src_stride) + 3);
 
@@ -1855,10 +1861,9 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 SPLATI_H4_SH(filter_vec, 0, 1, 2, 3, filt0, filt1, filt2, filt3);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W4_SW(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
+SPLATI_W4_SH(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
 
 mask1 = mask0 + 2;
 mask2 = mask0 + 4;
@@ -1866,13 +1871,14 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 
 offset = (offset0 + offset1) << rnd_val;
 weight0 = weight0 & 0x;
+weight = weight0 | (weight1 << 16);
 
-const_vec = __msa_ldi_h(128);
+const_vec = __msa_fill_w((128 * weight1));
 const_vec <<= 6;
 offset_vec = __msa_fill_w(offset);
-weight_vec0 = __msa_fill_w(weight0);
-weight_vec1 = __msa_fill_w(weight1);
 rnd_vec = __msa_fill_w(rnd_val + 1);
+offset_vec += const_vec;
+weight_vec = (v8i16) __msa_fill_w(weight);
 
 LD_SB7(src0_ptr, src_stride, src0, src1, src2, src3, src4, src5, src6);
 src0_ptr += (7 * src_stride);
@@ -1886,70 +1892,77 @@ static void hevc_hv_biwgt_8t_4w_msa(uint8_t *src0_ptr,
 VSHF_B4_SB(src3, src6, mask0, mask1, mask2, mask3,
vec12, vec13, vec14, vec15);
 
-dst30 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst30, dst30, dst30, dst30);
-dst41 = const_vec;
-DPADD_SB4_SH(vec4, vec5, vec6, vec7, filt0, filt1, filt2, filt3,
- dst41, dst41, dst41, dst41);
-dst52 = const_vec;
-DPADD_SB4_SH(vec8, vec9, vec10, vec11, filt0, filt1, filt2, filt3,
- dst52, dst52, dst52, dst52);
-dst63 = const_vec;
-DPADD_SB4_SH(vec12, vec13, vec14, vec15, filt0, filt1, filt2, filt3,
- dst63, dst63, dst63, dst63);
-
-ILVR_H3_SH(dst41, dst30, dst52, dst41, dst63, dst52,
-   dst10_r, dst21_r, dst32_r);
-dst43_r = __msa_ilvl_h(dst41, dst30);
-dst54_r = __msa_ilvl_h(dst52, dst41);
-dst65_r =

[FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma copy and avg vert mc msa functions

2017-10-24 Thread kaustubh.raste 
From: Kaustubh Raste 

Replace generic with block size specific function.
Load the specific destination bytes instead of MSA load and pack.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264chroma_msa.c |  627 +-
 1 file changed, 275 insertions(+), 352 deletions(-)

diff --git a/libavcodec/mips/h264chroma_msa.c b/libavcodec/mips/h264chroma_msa.c
index 2a54675..a5c3334 100644
--- a/libavcodec/mips/h264chroma_msa.c
+++ b/libavcodec/mips/h264chroma_msa.c
@@ -1124,24 +1124,25 @@ static void avc_chroma_hz_and_aver_dst_8w_msa(uint8_t 
*src, uint8_t *dst,
 }
 }
 
-static void avc_chroma_vt_and_aver_dst_2x2_msa(uint8_t *src, int32_t 
src_stride,
-   uint8_t *dst, int32_t 
dst_stride,
-   uint32_t coeff0, uint32_t 
coeff1)
+static void avc_chroma_vt_and_aver_dst_2x2_msa(uint8_t *src, uint8_t *dst,
+   int32_t stride, uint32_t coeff0,
+   uint32_t coeff1)
 {
 uint16_t out0, out1;
-uint32_t load0, load1;
 v16i8 src0, src1, src2, tmp0, tmp1, res;
 v16u8 dst_data = { 0 };
+v8i16 out;
 v8u16 res_r;
 v16i8 coeff_vec0 = __msa_fill_b(coeff0);
 v16i8 coeff_vec1 = __msa_fill_b(coeff1);
 v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
 
-LD_SB3(src, src_stride, src0, src1, src2);
-load0 = LW(dst);
-load1 = LW(dst + dst_stride);
+LD_SB3(src, stride, src0, src1, src2);
+out0 = LH(dst);
+out1 = LH(dst + stride);
 
-INSERT_W2_UB(load0, load1, dst_data);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 0, out0);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 2, out1);
 
 ILVR_B2_SB(src1, src0, src2, src1, tmp0, tmp1);
 
@@ -1151,20 +1152,20 @@ static void avc_chroma_vt_and_aver_dst_2x2_msa(uint8_t 
*src, int32_t src_stride,
 res_r = (v8u16) __msa_srari_h((v8i16) res_r, 6);
 res_r = __msa_sat_u_h(res_r, 7);
 res = __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
-dst_data = __msa_aver_u_b((v16u8) res, dst_data);
-out0 = __msa_copy_u_h((v8i16) dst_data, 0);
-out1 = __msa_copy_u_h((v8i16) dst_data, 2);
+out = (v8i16) __msa_aver_u_b((v16u8) res, dst_data);
+out0 = __msa_copy_u_h(out, 0);
+out1 = __msa_copy_u_h(out, 2);
 
 SH(out0, dst);
-dst += dst_stride;
+dst += stride;
 SH(out1, dst);
 }
 
-static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t *src, int32_t 
src_stride,
-   uint8_t *dst, int32_t 
dst_stride,
-   uint32_t coeff0, uint32_t 
coeff1)
+static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t *src, uint8_t *dst,
+   int32_t stride, uint32_t coeff0,
+   uint32_t coeff1)
 {
-uint32_t load0, load1;
+uint16_t tp0, tp1, tp2, tp3;
 v16i8 src0, src1, src2, src3, src4;
 v16u8 tmp0, tmp1, tmp2, tmp3;
 v8u16 res_r;
@@ -1174,19 +1175,16 @@ static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t 
*src, int32_t src_stride,
 v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
 v16u8 dst_data = { 0 };
 
-LD_SB5(src, src_stride, src0, src1, src2, src3, src4);
-
-load0 = LW(dst);
-load1 = LW(dst + dst_stride);
-
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 0, load0);
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 1, load1);
+LD_SB5(src, stride, src0, src1, src2, src3, src4);
 
-load0 = LW(dst + 2 * dst_stride);
-load1 = LW(dst + 3 * dst_stride);
-
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 2, load0);
-dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 3, load1);
+tp0 = LH(dst);
+tp1 = LH(dst + stride);
+tp2 = LH(dst + 2 * stride);
+tp3 = LH(dst + 3 * stride);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 0, tp0);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 1, tp1);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 2, tp2);
+dst_data = (v16u8) __msa_insert_h((v8i16) dst_data, 3, tp3);
 
 ILVR_B4_UB(src1, src0, src2, src1, src3, src2, src4, src3,
tmp0, tmp1, tmp2, tmp3);
@@ -1202,102 +1200,26 @@ static void avc_chroma_vt_and_aver_dst_2x4_msa(uint8_t 
*src, int32_t src_stride,
 res = (v8i16) __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
 res = (v8i16) __msa_aver_u_b((v16u8) res, dst_data);
 
-ST2x4_UB(res, 0, dst, dst_stride);
-dst += (4 * dst_stride);
-}
-
-static void avc_chroma_vt_and_aver_dst_2x8_msa(uint8_t *src, int32_t 
src_stride,
-   uint8_t *dst, int32_t 
dst_stride,
-   uint32_t coeff0, uint32_t 
coeff1)
-{
-uint32_t load0, load1, load2, load3;
-v16i8 src0,

[FFmpeg-devel] lavf/img2enc: updatefirst

2017-10-24 Thread Gyan Doshi 
The doc for image2 muxer makes mention of only the 'update' option but 
the muxer contains a 'updatefirst' option as well that effects the same 
behaviour. Obviously, the latter isn't a shorthand for the former.


Should 'updatefirst' be removed, or documented?

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

[FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 11, 31, 13 and 33 msa functions

2017-10-24 Thread kaustubh.raste 
From: Kaustubh Raste 

Remove loops and unroll as block sizes are known.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c |  400 
 1 file changed, 240 insertions(+), 160 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index f11fce8..fcccb98 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -171,23 +171,27 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 out0_m; \
 } )
 
-static void avc_luma_hv_qrt_4w_msa(const uint8_t *src_x, const uint8_t *src_y,
-   int32_t src_stride, uint8_t *dst,
-   int32_t dst_stride, int32_t height)
+static void avc_luma_hv_qrt_4x4_msa(const uint8_t *src_x, const uint8_t *src_y,
+uint8_t *dst, int32_t stride)
 {
-uint32_t loop_cnt;
-v16i8 src_hz0, src_hz1, src_hz2, src_hz3;
-v16i8 src_vt0, src_vt1, src_vt2, src_vt3, src_vt4;
-v16i8 src_vt5, src_vt6, src_vt7, src_vt8;
-v16i8 mask0, mask1, mask2;
-v8i16 hz_out0, hz_out1, vert_out0, vert_out1;
-v8i16 out0, out1;
+const int16_t filt_const0 = 0xfb01;
+const int16_t filt_const1 = 0x1414;
+const int16_t filt_const2 = 0x1fb;
 v16u8 out;
+v16i8 src_hz0, src_hz1, src_hz2, src_hz3, src_vt7, src_vt8;
+v16i8 src_vt0, src_vt1, src_vt2, src_vt3, src_vt4, src_vt5, src_vt6;
+v16i8 src_vt10_r, src_vt32_r, src_vt54_r, src_vt76_r;
+v16i8 mask0, mask1, mask2, filt0, filt1, filt2;
+v8i16 hz_out0, hz_out1, vt_out0, vt_out1, out0, out1;
+
+filt0 = (v16i8) __msa_fill_h(filt_const0);
+filt1 = (v16i8) __msa_fill_h(filt_const1);
+filt2 = (v16i8) __msa_fill_h(filt_const2);
 
 LD_SB3(_mask_arr[48], 16, mask0, mask1, mask2);
 
-LD_SB5(src_y, src_stride, src_vt0, src_vt1, src_vt2, src_vt3, src_vt4);
-src_y += (5 * src_stride);
+LD_SB5(src_y, stride, src_vt0, src_vt1, src_vt2, src_vt3, src_vt4);
+src_y += (5 * stride);
 
 src_vt0 = (v16i8) __msa_insve_w((v4i32) src_vt0, 1, (v4i32) src_vt1);
 src_vt1 = (v16i8) __msa_insve_w((v4i32) src_vt1, 1, (v4i32) src_vt2);
@@ -196,149 +200,237 @@ static void avc_luma_hv_qrt_4w_msa(const uint8_t 
*src_x, const uint8_t *src_y,
 
 XORI_B4_128_SB(src_vt0, src_vt1, src_vt2, src_vt3);
 
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src_x, src_stride, src_hz0, src_hz1, src_hz2, src_hz3);
-src_x += (4 * src_stride);
-
-XORI_B4_128_SB(src_hz0, src_hz1, src_hz2, src_hz3);
-
-hz_out0 = AVC_XOR_VSHF_B_AND_APPLY_6TAP_HORIZ_FILT_SH(src_hz0,
-  src_hz1, mask0,
-  mask1, mask2);
-hz_out1 = AVC_XOR_VSHF_B_AND_APPLY_6TAP_HORIZ_FILT_SH(src_hz2,
-  src_hz3, mask0,
-  mask1, mask2);
-
-SRARI_H2_SH(hz_out0, hz_out1, 5);
-SAT_SH2_SH(hz_out0, hz_out1, 7);
-
-LD_SB4(src_y, src_stride, src_vt5, src_vt6, src_vt7, src_vt8);
-src_y += (4 * src_stride);
-
-src_vt4 = (v16i8) __msa_insve_w((v4i32) src_vt4, 1, (v4i32) src_vt5);
-src_vt5 = (v16i8) __msa_insve_w((v4i32) src_vt5, 1, (v4i32) src_vt6);
-src_vt6 = (v16i8) __msa_insve_w((v4i32) src_vt6, 1, (v4i32) src_vt7);
-src_vt7 = (v16i8) __msa_insve_w((v4i32) src_vt7, 1, (v4i32) src_vt8);
-
-XORI_B4_128_SB(src_vt4, src_vt5, src_vt6, src_vt7);
+LD_SB4(src_x, stride, src_hz0, src_hz1, src_hz2, src_hz3);
+XORI_B4_128_SB(src_hz0, src_hz1, src_hz2, src_hz3);
+hz_out0 = AVC_HORZ_FILTER_SH(src_hz0, src_hz1, mask0, mask1, mask2);
+hz_out1 = AVC_HORZ_FILTER_SH(src_hz2, src_hz3, mask0, mask1, mask2);
 
-/* filter calc */
-vert_out0 = AVC_CALC_DPADD_B_6PIX_2COEFF_R_SH(src_vt0, src_vt1,
-  src_vt2, src_vt3,
-  src_vt4, src_vt5);
-vert_out1 = AVC_CALC_DPADD_B_6PIX_2COEFF_R_SH(src_vt2, src_vt3,
-  src_vt4, src_vt5,
-  src_vt6, src_vt7);
+SRARI_H2_SH(hz_out0, hz_out1, 5);
+SAT_SH2_SH(hz_out0, hz_out1, 7);
 
-SRARI_H2_SH(vert_out0, vert_out1, 5);
-SAT_SH2_SH(vert_out0, vert_out1, 7);
+LD_SB4(src_y, stride, src_vt5, src_vt6, src_vt7, src_vt8);
 
-out0 = __msa_srari_h((hz_out0 + vert_out0), 1);
-out1 = __msa_srari_h((hz_out1 + vert_out1), 1);
+src_vt4 = (v16i8) __msa_insve_w((v4i32) src_vt4, 1, (v4i32) src_vt5);
+src_vt5 = (v16i8) __msa_insve_w((v4i32) src_vt5, 1, (v4i32) src_vt6);
+src_vt6 = (v16i8)

[FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting.

2017-10-24 Thread Jun Zhao 

From 24b8e1c70fd4bf4eb76404fd9e2020fe3bbd90cb Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 24 Oct 2017 13:25:21 +0800
Subject: [PATCH V2] lavc/vaapi_encode_h264: correct VUI
 max_dec_frame_buffering setting.

vseq.max_num_ref_frames not init before the VUI
max_dec_frame_buffering setting, so use sps.max_num_ref_frames
in this case.

Signed-off-by: Jun Zhao 
Signed-off-by: Wang, Yi A 
---
 libavcodec/vaapi_encode_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 9a4bd53da1..1d43e934ef 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -441,7 +441,7 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 sps->vui.log2_max_mv_length_horizontal = 16;
 sps->vui.log2_max_mv_length_vertical   = 16;
 sps->vui.max_num_reorder_frames= (ctx->b_per_p > 0);
-sps->vui.max_dec_frame_buffering   = vseq->max_num_ref_frames;
+sps->vui.max_dec_frame_buffering   = sps->max_num_ref_frames;
 
 pps->nal_unit_header.nal_ref_idc = 3;
 pps->nal_unit_header.nal_unit_type = H264_NAL_PPS;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-10-24 Thread Dixit, Vishwanath 
>On 10/22/17, 1:28 PM, "Liu Steven"  wrote:
>Two patches should be ok, add FATE cases please :)
I am not familiar with FATE and I could not find any sample hlsenc FATE cases 
in ffmpeg workspace. Could you please help me with this? If some basic hlsenc 
tests are available, I can extend them further for variant stream creation and 
master playlist creation.

Regards,
Vishwanath
 
 

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting.

2017-10-24 Thread Jun Zhao 


On 2017/10/24 13:42, Jun Zhao wrote:
The commit comment is wrong, will re-submit V2 to fix the typo.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel