Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

[wm4]

On Thu, 16 Feb 2017 19:46:08 +
Mark Thompson  wrote:

> On 16/02/17 18:29, Aman Gupta wrote:
> > From: Aman Gupta 
> > 
> > This fixes playback of h264 streams with SPS changes. One such sample
> > is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> > It switches mid-stream from level 4.0 to level 3.2.
> > 
> > Previously, playing this sample with the VT hwaccel on iOS would crash.
> > After this patch, it plays back as expected.
> > 
> > On macOS however, feeding in new SPS into an existing decompression
> > session does not always work, so this patch is only a partial fix.
> > ---
> >  libavcodec/h264dec.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > index 41c0964..e521c52 100644
> > --- a/libavcodec/h264dec.c
> > +++ b/libavcodec/h264dec.c
> > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  break;
> >  case H264_NAL_SPS: {
> >  GetBitContext tmp_gb = nal->gb;
> > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> > AV_PIX_FMT_VIDEOTOOLBOX) {
> > +ret = avctx->hwaccel->decode_slice(avctx,
> > +   nal->data,
> > +   nal->size);
> > +if (ret < 0)
> > +goto end;
> > +}
> >  if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 
> > 0) >= 0)
> >  break;
> >  av_log(h->avctx, AV_LOG_DEBUG,
> >   
> 
> The SPS isn't a slice - calling decode_slice() on it is confusing.  I realise 
> you are really using it as "upload blob" and that does basically make sense, 
> but changes like this are moving it further away from being maintainable as a 
> hwaccel.  (Compare how many DXVA- or VAAPI-specific code paths currently 
> exist in the decoder outside the actual hwaccel functions.)  The previous 
> patches doing the same thing with the PPS and fiddling something funny inside 
> the reference picture lists are similar - in themselves not obviously 
> unreasonable, but making the code trickier in ways which may make things more 
> difficult later.
> 
> So, I think this needs a step back to consider whether this should actually 
> be implemented as a hwaccel at all if changes like this are needed:
> 
> It looks like you are now supplying it all video-significant packets - what 
> would need to be implemented to do this without being inside hwaccel 
> infrastructure?  (As a standalone full-bitstream decoder, but possibly 
> calling in to the existing H.264 code if that helps.)
> 
> On the other hand, if it is going to continue being a hwaccel, can we add 
> make some changes to the internal hwaccel API to avoid having to make changes 
> like this in the generic decoder?  (Also thinking of other codecs - you're 
> changing H.264 here, are other codecs going to run into similar issues, 
> particularly H.265 which is structurally very similar in these aspects?)

Yeah, it's not clear at all how this should be done. Clearly using it
as hwaccel has advantages, but is also a bit hacky. We also need to
consider things like deinterlacing (which VT does in the decoder), and
async API (needed to make it actually fast). At least it looks like
deinterlacing doesn't actually work, so we might not need to worry
about that one.

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/videotoolbox: restart decompression session on bad data errors

[wm4]

On Thu, 16 Feb 2017 10:29:38 -0800
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> On some platforms (observed on macOS Sierra with 12" macbook), the VT
> decoder will start returning errors when encountering an SPS change in
> the h264 bitstream. With this patch, the kVTVideoDecoderBadDataErr
> response from the decoder is caught and the decompression session is
> recreated with a new avcC. The "bad data" is then fed into the new
> decompression session so that it can be decoded correctly.
> 
> I discovered the underlying issue here by running ffmpeg with lldb,
> which causes macOS to display debug information from the VT hardware
> decoder on stderr. The following errors were shown, which indicated the
> need to restart the decoder session with a new SPS/avcC:
> 
>   ffmpeg[15127:4094995] GVA error: SPS mismatch ...
>   ffmpeg[15127:4094995] GVA error: AVF_PushMetaData, first field 
> kAVF_QT0_SPSPPSBoundaryMarker
>   ffmpeg[15127:4094995] GVA error: pushMetaData, submitNewJobs
>   ffmpeg[15127:4094995] GVA warning: OutputQueueReadyCallback status = 1, 
> buffer == 0x0
> 
> Tested with the following sample, which contains an SPS change midstream:
> http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts
> ---
>  libavcodec/videotoolbox.c | 28 
>  1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 9be7bee..159d98d 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -38,6 +38,9 @@
>  
>  #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
>  
> +static void videotoolbox_stop(AVCodecContext *avctx);
> +static int videotoolbox_start(AVCodecContext *avctx);
> +
>  static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
>  {
>  CVPixelBufferRef cv_buffer = (CVImageBufferRef)data;
> @@ -350,13 +353,25 @@ static int videotoolbox_common_end_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  int status;
>  AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
>  VTContext *vtctx = avctx->internal->hwaccel_priv_data;
> +int retry;
>  
>  av_buffer_unref(>buf[0]);
>  
>  if (!videotoolbox->session || !vtctx->bitstream)
>  return AVERROR_INVALIDDATA;
>  
> -status = videotoolbox_session_decode_frame(avctx);
> +for (retry = 0; retry < 2; retry++) {

Why retry?

> +status = videotoolbox_session_decode_frame(avctx);
> +
> +if (status == kVTVideoDecoderBadDataErr) {
> +av_log(avctx, AV_LOG_DEBUG, "vt decoder got bad data error, 
> restarting..\n");
> +videotoolbox_stop(avctx);
> +videotoolbox_start(avctx);

Wouldn't Bad Things happen if the session failed to create for some
reason?

> +continue;
> +} else {
> +break;
> +}
> +}
>  
>  if (status) {
>  av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%d)\n", status);
> @@ -506,7 +521,7 @@ static CMVideoFormatDescriptionRef 
> videotoolbox_format_desc_create(CMVideoCodecT
>  return cm_fmt_desc;
>  }
>  
> -static int videotoolbox_default_init(AVCodecContext *avctx)
> +static int videotoolbox_start(AVCodecContext *avctx)
>  {
>  AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
>  OSStatus status;
> @@ -587,7 +602,12 @@ static int videotoolbox_default_init(AVCodecContext 
> *avctx)
>  }
>  }
>  
> -static void videotoolbox_default_free(AVCodecContext *avctx)
> +static int videotoolbox_default_init(AVCodecContext *avctx)
> +{
> +return videotoolbox_start(avctx);
> +}
> +
> +static void videotoolbox_stop(AVCodecContext *avctx)
>  {
>  AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
>  if (!videotoolbox)
> @@ -696,7 +716,7 @@ int av_videotoolbox_default_init2(AVCodecContext *avctx, 
> AVVideotoolboxContext *
>  void av_videotoolbox_default_free(AVCodecContext *avctx)
>  {
>  
> -videotoolbox_default_free(avctx);
> +videotoolbox_stop(avctx);
>  av_freep(>hwaccel_context);
>  }
>  #endif /* CONFIG_VIDEOTOOLBOX */

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

[wm4]

On Thu, 16 Feb 2017 10:29:36 -0800
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> This fixes playback of h264 streams with SPS changes. One such sample
> is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> It switches mid-stream from level 4.0 to level 3.2.
> 
> Previously, playing this sample with the VT hwaccel on iOS would crash.
> After this patch, it plays back as expected.
> 
> On macOS however, feeding in new SPS into an existing decompression
> session does not always work, so this patch is only a partial fix.
> ---
>  libavcodec/h264dec.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 41c0964..e521c52 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  break;
>  case H264_NAL_SPS: {
>  GetBitContext tmp_gb = nal->gb;
> +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> AV_PIX_FMT_VIDEOTOOLBOX) {
> +ret = avctx->hwaccel->decode_slice(avctx,
> +   nal->data,
> +   nal->size);
> +if (ret < 0)
> +goto end;
> +}
>  if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 0) 
> >= 0)
>  break;
>  av_log(h->avctx, AV_LOG_DEBUG,

A bit ugly but ok IMHO. Maybe it would be better to add a new hwaccel
callback here, even if it's used by VT only.

You should probably wait for approval by michaelni.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/videotoolbox: cosmetic change to simplify code with early return

[wm4]

On Thu, 16 Feb 2017 10:29:37 -0800
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> ---
>  libavcodec/videotoolbox.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 1288aa5..9be7bee 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -590,15 +590,16 @@ static int videotoolbox_default_init(AVCodecContext 
> *avctx)
>  static void videotoolbox_default_free(AVCodecContext *avctx)
>  {
>  AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
> +if (!videotoolbox)
> +return;
>  
> -if (videotoolbox) {
> -if (videotoolbox->cm_fmt_desc)
> -CFRelease(videotoolbox->cm_fmt_desc);
> +if (videotoolbox->cm_fmt_desc)
> +CFRelease(videotoolbox->cm_fmt_desc);
>  
> -if (videotoolbox->session) {
> -VTDecompressionSessionInvalidate(videotoolbox->session);
> -CFRelease(videotoolbox->session);
> -}
> +if (videotoolbox->session) {
> +VTDecompressionSessionInvalidate(videotoolbox->session);
> +CFRelease(videotoolbox->session);
> +videotoolbox->session = NULL;
>  }
>  }
>  

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

[FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

[Thomas Turner]

The Chen-Shapiro(CS) test was used to test normality for
Lagged Fibonacci PRNG.

Normality Hypothesis Test:

The null hypothesis formally tests if the population
the sample represents is normally-distributed. For
CS, when the normality hypothesis is True, the
distribution of QH will have a mean close to 1.

Information on CS can be found here:

http://www.stata-journal.com/sjpdf.html?articlenum=st0264
http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm

Signed-off-by: Thomas Turner 
---
 libavutil/tests/lfg.c|  170 ++--
 tests/fate/libavutil.mak |4 +
 tests/ref/fate/lfg   | 1007 ++
 3 files changed, 1157 insertions(+), 24 deletions(-)
 create mode 100644 tests/ref/fate/lfg

diff --git a/libavutil/tests/lfg.c b/libavutil/tests/lfg.c
index 1425e02..93b102c 100644
--- a/libavutil/tests/lfg.c
+++ b/libavutil/tests/lfg.c
@@ -20,9 +20,88 @@
 #include "libavutil/timer.h"
 #include "libavutil/lfg.h"
 
+static const double Z_TABLE[31][10] = {
+{0.5000,  0.5040,  0.5080,  0.5120,  0.5160,  0.5199,  0.5239,  0.5279,  
0.5319,  0.5359},
+{0.5398,  0.5438,  0.5478,  0.5517,  0.5557,  0.5596,  0.5636,  0.5675,  
0.5714,  0.5753},
+{0.5793,  0.5832,  0.5871,  0.5910,  0.5948,  0.5987,  0.6026,  0.6064,  
0.6103,  0.6141},
+{0.6179,  0.6217,  0.6255,  0.6293,  0.6331,  0.6368,  0.6406,  0.6443,  
0.6480,  0.6517},
+{0.6554,  0.6591,  0.6628,  0.6664,  0.6700,  0.6736,  0.6772,  0.6808,  
0.6844,  0.6879},
+{0.6915,  0.6950,  0.6985,  0.7019,  0.7054,  0.7088,  0.7123,  0.7157,  
0.7190,  0.7224},
+{0.7257,  0.7291,  0.7324,  0.7357,  0.7389,  0.7422,  0.7454,  0.7486,  
0.7517,  0.7549},
+{0.7580,  0.7611,  0.7642,  0.7673,  0.7704,  0.7734,  0.7764,  0.7794,  
0.7823,  0.7852},
+{0.7881,  0.7910,  0.7939,  0.7967,  0.7995,  0.8023,  0.8051,  0.8078,  
0.8106,  0.8133},
+{0.8159,  0.8186,  0.8212,  0.8238,  0.8264,  0.8289,  0.8315,  0.8340,  
0.8365,  0.8389},
+{0.8413,  0.8438,  0.8461,  0.8485,  0.8508,  0.8531,  0.8554,  0.8577,  
0.8599,  0.8621},
+{0.8643,  0.8665,  0.8686,  0.8708,  0.8729,  0.8749,  0.8770,  0.8790,  
0.8810,  0.8830},
+{0.8849,  0.8869,  0.,  0.8907,  0.8925,  0.8944,  0.8962,  0.8980,  
0.8997,  0.9015},
+{0.9032,  0.9049,  0.9066,  0.9082,  0.9099,  0.9115,  0.9131,  0.9147,  
0.9162,  0.9177},
+{0.9192,  0.9207,  0.9222,  0.9236,  0.9251,  0.9265,  0.9279,  0.9292,  
0.9306,  0.9319},
+{0.9332,  0.9345,  0.9357,  0.9370,  0.9382,  0.9394,  0.9406,  0.9418,  
0.9429,  0.9441},
+{0.9452,  0.9463,  0.9474,  0.9484,  0.9495,  0.9505,  0.9515,  0.9525,  
0.9535,  0.9545},
+{0.9554,  0.9564,  0.9573,  0.9582,  0.9591,  0.9599,  0.9608,  0.9616,  
0.9625,  0.9633},
+{0.9641,  0.9649,  0.9656,  0.9664,  0.9671,  0.9678,  0.9686,  0.9693,  
0.9699,  0.9706},
+{0.9713,  0.9719,  0.9726,  0.9732,  0.9738,  0.9744,  0.9750,  0.9756,  
0.9761,  0.9767},
+{0.9772,  0.9778,  0.9783,  0.9788,  0.9793,  0.9798,  0.9803,  0.9808,  
0.9812,  0.9817},
+{0.9821,  0.9826,  0.9830,  0.9834,  0.9838,  0.9842,  0.9846,  0.9850,  
0.9854,  0.9857},
+{0.9861,  0.9864,  0.9868,  0.9871,  0.9875,  0.9878,  0.9881,  0.9884,  
0.9887,  0.9890},
+{0.9893,  0.9896,  0.9898,  0.9901,  0.9904,  0.9906,  0.9909,  0.9911,  
0.9913,  0.9916},
+{0.9918,  0.9920,  0.9922,  0.9925,  0.9927,  0.9929,  0.9931,  0.9932,  
0.9934,  0.9936},
+{0.9938,  0.9940,  0.9941,  0.9943,  0.9945,  0.9946,  0.9948,  0.9949,  
0.9951,  0.9952},
+{0.9953,  0.9955,  0.9956,  0.9957,  0.9959,  0.9960,  0.9961,  0.9962,  
0.9963,  0.9964},
+{0.9965,  0.9966,  0.9967,  0.9968,  0.9969,  0.9970,  0.9971,  0.9972,  
0.9973,  0.9974},
+{0.9974,  0.9975,  0.9976,  0.9977,  0.9977,  0.9978,  0.9979,  0.9979,  
0.9980,  0.9981},
+{0.9981,  0.9982,  0.9982,  0.9983,  0.9984,  0.9984,  0.9985,  0.9985,  
0.9986,  0.9986},
+{0.9987,  0.9987,  0.9987,  0.9988,  0.9988,  0.9989,  0.9989,  0.9989,  
0.9990,  0.9990} };
+
+// Inverse cumulative distribution function
+static double inv_cdf(double u)
+{
+const double a[4] = { 2.50662823884,
+ -18.61500062529,
+  41.39119773534,
+ -25.44106049637};
+
+const double b[4] = {-8.47351093090,
+  23.08336743743,
+ -21.06224101826,
+   3.13082909833};
+
+const double c[9] = {0.3374754822726147,
+  0.9761690190917186,
+  0.1607979714918209,
+  0.0276438810333863,
+  0.0038405729373609,
+  0.0003951896511919,
+  0.321767881768,
+  0.002888167364,
+  0.003960315187};
+
+double r;
+double x = u - 0.5;
+
+// Beasley-Springer
+ if (fabs(x) < 

Re: [FFmpeg-devel] [PATCH] tiff: fix leaking yuv_line

[Andreas Cadhalpun]

On 16.02.2017 03:15, Michael Niedermayer wrote:
> On Thu, Feb 16, 2017 at 12:23:28AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/tiff.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
>> index efbd9791a5..474ea90015 100644
>> --- a/libavcodec/tiff.c
>> +++ b/libavcodec/tiff.c
>> @@ -1386,6 +1386,7 @@ static av_cold int tiff_end(AVCodecContext *avctx)
>>  
>>  ff_lzw_decode_close(>lzw);
>>  av_freep(>deinvert_buf);
>> +av_freep(>yuv_line);
>>  return 0;
> 
> I assume we are missing a test in fate for the yuv case
> adding such test would be usefull

Indeed, I'll send a patch adding one.

> yuv_line_size should be reset to 0, not sure its ever needed but it
> feels more proper

It's in the close function, so it's unlikely to be needed, but I added
it now anyway. Updated patch is attached. 

Best regards,
Andreas
>From c9a5c531c1d0434c989998eab6cb1ac352200695 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Thu, 16 Feb 2017 00:07:24 +0100
Subject: [PATCH] tiff: fix leaking yuv_line

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/tiff.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index efbd9791a5..650a9d89ef 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1386,6 +1386,8 @@ static av_cold int tiff_end(AVCodecContext *avctx)
 
 ff_lzw_decode_close(>lzw);
 av_freep(>deinvert_buf);
+av_freep(>yuv_line);
+s->yuv_line_size = 0;
 return 0;
 }
 
-- 
2.11.0

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

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

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tests/fate/source-check.sh | 14 ++
 tests/ref/fate/source  |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
index ac2878d9f7..72e1511f0d 100755
--- a/tests/fate/source-check.sh
+++ b/tests/fate/source-check.sh
@@ -30,4 +30,18 @@ for f in `git ls-files | grep '\.h$'` ; do
 grep -L "^#define $macro$" $f
 done
 
+echo "Use of av_clip() where av_clip_uintp2 could be used:"
+git grep -E 'av_clip *\(.*, *0 *, 
*(3|7|15|31|63|127|255|511|1023|2047|4095|8191|'\
+'16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|'\
+'33554431|67108863|134217727|268435455|536870911|1073741823) *\)' | grep -v 
fate/source
+
+echo "Use of av_clip() where av_clip_intp2 could be used:"
+git grep -E 'av_clip *\(.*, *(-2 *, *1|-4 *, *3|-8 *, *7|-16 *, *15|-32 *, 
*31|-64'\
+' *, *63|-128 *, *127|-256 *, *255|-512 *, *511|-1024 *, *1023|-2048 *, 
*2047|-4096'\
+' *, *4095|-8192 *, *8191|-16384 *, *16383|-32768 *, *32767|-65536 *, 
*65535|-131072'\
+' *, *131071|-262144 *, *262143|-524288 *, *524287|-1048576 *, 
*1048575|-2097152 *,'\
+' *2097151|-4194304 *, *4194303|-8388608 *, *8388607|-16777216 *, 
*16777215|-33554432'\
+' *, *33554431|-67108864 *, *67108863|-134217728 *, *134217727|-268435456 *, 
*'\
+'268435455|-536870912 *, *536870911|-1073741824 *, *1073741823) *\)'| grep -v 
fate/source
+
 exit 0
diff --git a/tests/ref/fate/source b/tests/ref/fate/source
index 67906d1198..6a8f12f815 100644
--- a/tests/ref/fate/source
+++ b/tests/ref/fate/source
@@ -31,3 +31,5 @@ compat/cuda/dynlink_nvcuvid.h
 compat/float/float.h
 compat/float/limits.h
 compat/nvenc/nvEncodeAPI.h
+Use of av_clip() where av_clip_uintp2 could be used:
+Use of av_clip() where av_clip_intp2 could be used:
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] mpegaudiodec_template: fix leaking fdsp for mp3on4float

[Andreas Cadhalpun]

On 16.02.2017 03:12, Michael Niedermayer wrote:
> On Thu, Feb 16, 2017 at 12:39:17AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/mpegaudiodec_template.c | 3 +++
>>  1 file changed, 3 insertions(+)
> 
> should be ok

Pushed.

> why was this not detected by fate ?
> are we lacking a test for this ?

There is no fate test and since it uses float, it seems non-trivial to
add a platform-independent one.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] wmaprodec: fix leaking fdsp on init failure

[Andreas Cadhalpun]

On 16.02.2017 03:04, Michael Niedermayer wrote:
> On Thu, Feb 16, 2017 at 12:56:38AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/wmaprodec.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> should be ok

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH]lavc/avpacket: Initialize a variable in error path

[Michael Niedermayer]

On Fri, Feb 17, 2017 at 12:49:05AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch is said to fix undefined behaviour, see ticket #6153, I cannot 
> reproduce.
> 
> Please comment, Carl Eugen

patch is ok
the issue described is real but a bit hypothetical and probably has
no real world effect
i suggest to backport this too though because its likely easy to
backport

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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_vp8: Use VP8_MAX_QUANT instead of magic number

[Mark Thompson]

On 16/02/17 23:46, Michael Niedermayer wrote:
> On Thu, Feb 16, 2017 at 08:45:33PM +, Mark Thompson wrote:
>> ---
>> On 16/02/17 20:15, Michael Niedermayer wrote:
>>> On Thu, Feb 16, 2017 at 05:11:54PM +, Mark Thompson wrote:
 On 16/02/17 16:20, Michael Niedermayer wrote:
> Its used elsewhere for 2^p-1 cliping
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vaapi_encode_vp8.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> index 4a1c85e66c..3d3831c46d 100644
> --- a/libavcodec/vaapi_encode_vp8.c
> +++ b/libavcodec/vaapi_encode_vp8.c
> @@ -161,12 +161,12 @@ static av_cold int 
> vaapi_encode_vp8_configure(AVCodecContext *avctx)
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VAAPIEncodeVP8Context *priv = ctx->priv_data;
>  
> -priv->q_index_p = av_clip(avctx->global_quality, 0, 127);
> +priv->q_index_p = av_clip_uintp2(avctx->global_quality, 7);
>  if (avctx->i_quant_factor > 0.0)
> -priv->q_index_i = av_clip((avctx->global_quality *
> +priv->q_index_i = av_clip_uintp2((avctx->global_quality *
> avctx->i_quant_factor +
> avctx->i_quant_offset) + 0.5,
> -  0, 127);
> +  7);
>  else
>  priv->q_index_i = priv->q_index_p;

 IMO this makes the code less readable, not more.  It doesn't really matter 
 to anything, though, so commit it if you really want to.

 (If this is mainly objecting to the magic number being visible there then 
 please do introduce a constant to hide it rather than making the constant 
 smaller - VP8_QINDEX_RANGE, say, to match 
 .)
>>>
>>> I just suggested it because its the only case we have in the codebase
>>> that matches this:
>>> git grep -E 'av_clip *\(.*, *0 *, 
>>> *(3|7|15|31|63|127|255|511|1023|2047|4095|8191|16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|33554431|67108863|134217727|268435455|536870911|1073741823)
>>>  *\)'
>>>
>>> If we dont use the more optimized code everywhere then finding
>>> cases where it makes a difference and isnt used is harder and not
>>> something i would attempt.
>>>
>>> i can also move this into fate-source
>>> (there it might even be possible to keep track of exceptions)
>>> but previous additions to fate-source had opposition, so iam not
>>> doing that unless theres some positive feedback in that direction
>>> first ...
>>
>> That does make a lot of sense; I would be in favour of having automated 
>> checks like that in fate-source.
>>
>> To remove the issue here, how about this patch instead?  The constant 
>> already exists in the VP8 header, so we can just use it from there.
>>
>>
>>  libavcodec/vaapi_encode_vp8.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> patch LGTM

Ok, applied.

Thanks,

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

[FFmpeg-devel] [PATCH]lavc/avpacket: Initialize a variable in error path

[Carl Eugen Hoyos]

Hi!

Attached patch is said to fix undefined behaviour, see ticket #6153, I cannot 
reproduce.

Please comment, Carl Eugen
From 8bbd58c465deb28737586c9292d57ab75e3de32c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 17 Feb 2017 00:46:14 +0100
Subject: [PATCH] lavc/avpacket: Initialize a variable in error path.

Fixes ticket #6153.
---
 libavcodec/avpacket.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 24b4efb..8e028a2 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -348,6 +348,8 @@ uint8_t *av_packet_get_side_data(AVPacket *pkt, enum 
AVPacketSideDataType type,
 return pkt->side_data[i].data;
 }
 }
+if (size)
+*size = 0;
 return NULL;
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] vaapi_vp8: Use VP8_MAX_QUANT instead of magic number

[Michael Niedermayer]

On Thu, Feb 16, 2017 at 08:45:33PM +, Mark Thompson wrote:
> ---
> On 16/02/17 20:15, Michael Niedermayer wrote:
> > On Thu, Feb 16, 2017 at 05:11:54PM +, Mark Thompson wrote:
> >> On 16/02/17 16:20, Michael Niedermayer wrote:
> >>> Its used elsewhere for 2^p-1 cliping
> >>>
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/vaapi_encode_vp8.c | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> >>> index 4a1c85e66c..3d3831c46d 100644
> >>> --- a/libavcodec/vaapi_encode_vp8.c
> >>> +++ b/libavcodec/vaapi_encode_vp8.c
> >>> @@ -161,12 +161,12 @@ static av_cold int 
> >>> vaapi_encode_vp8_configure(AVCodecContext *avctx)
> >>>  VAAPIEncodeContext *ctx = avctx->priv_data;
> >>>  VAAPIEncodeVP8Context *priv = ctx->priv_data;
> >>>  
> >>> -priv->q_index_p = av_clip(avctx->global_quality, 0, 127);
> >>> +priv->q_index_p = av_clip_uintp2(avctx->global_quality, 7);
> >>>  if (avctx->i_quant_factor > 0.0)
> >>> -priv->q_index_i = av_clip((avctx->global_quality *
> >>> +priv->q_index_i = av_clip_uintp2((avctx->global_quality *
> >>> avctx->i_quant_factor +
> >>> avctx->i_quant_offset) + 0.5,
> >>> -  0, 127);
> >>> +  7);
> >>>  else
> >>>  priv->q_index_i = priv->q_index_p;
> >>
> >> IMO this makes the code less readable, not more.  It doesn't really matter 
> >> to anything, though, so commit it if you really want to.
> >>
> >> (If this is mainly objecting to the magic number being visible there then 
> >> please do introduce a constant to hide it rather than making the constant 
> >> smaller - VP8_QINDEX_RANGE, say, to match 
> >> .)
> > 
> > I just suggested it because its the only case we have in the codebase
> > that matches this:
> > git grep -E 'av_clip *\(.*, *0 *, 
> > *(3|7|15|31|63|127|255|511|1023|2047|4095|8191|16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|33554431|67108863|134217727|268435455|536870911|1073741823)
> >  *\)'
> > 
> > If we dont use the more optimized code everywhere then finding
> > cases where it makes a difference and isnt used is harder and not
> > something i would attempt.
> > 
> > i can also move this into fate-source
> > (there it might even be possible to keep track of exceptions)
> > but previous additions to fate-source had opposition, so iam not
> > doing that unless theres some positive feedback in that direction
> > first ...
> 
> That does make a lot of sense; I would be in favour of having automated 
> checks like that in fate-source.
> 
> To remove the issue here, how about this patch instead?  The constant already 
> exists in the VP8 header, so we can just use it from there.
> 
> 
>  libavcodec/vaapi_encode_vp8.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

patch LGTM

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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/vaapi_encode_vp8: Use av_clip_uintp2()

[Michael Niedermayer]

On Thu, Feb 16, 2017 at 05:50:58PM -0300, James Almer wrote:
> On 2/16/2017 5:15 PM, Michael Niedermayer wrote:
> > On Thu, Feb 16, 2017 at 05:11:54PM +, Mark Thompson wrote:
> >> On 16/02/17 16:20, Michael Niedermayer wrote:
> >>> Its used elsewhere for 2^p-1 cliping
> >>>
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/vaapi_encode_vp8.c | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> >>> index 4a1c85e66c..3d3831c46d 100644
> >>> --- a/libavcodec/vaapi_encode_vp8.c
> >>> +++ b/libavcodec/vaapi_encode_vp8.c
> >>> @@ -161,12 +161,12 @@ static av_cold int 
> >>> vaapi_encode_vp8_configure(AVCodecContext *avctx)
> >>>  VAAPIEncodeContext *ctx = avctx->priv_data;
> >>>  VAAPIEncodeVP8Context *priv = ctx->priv_data;
> >>>  
> >>> -priv->q_index_p = av_clip(avctx->global_quality, 0, 127);
> >>> +priv->q_index_p = av_clip_uintp2(avctx->global_quality, 7);
> >>>  if (avctx->i_quant_factor > 0.0)
> >>> -priv->q_index_i = av_clip((avctx->global_quality *
> >>> +priv->q_index_i = av_clip_uintp2((avctx->global_quality *
> >>> avctx->i_quant_factor +
> >>> avctx->i_quant_offset) + 0.5,
> >>> -  0, 127);
> >>> +  7);
> >>>  else
> >>>  priv->q_index_i = priv->q_index_p;
> >>
> >> IMO this makes the code less readable, not more.  It doesn't really matter 
> >> to anything, though, so commit it if you really want to.
> >>
> >> (If this is mainly objecting to the magic number being visible there then 
> >> please do introduce a constant to hide it rather than making the constant 
> >> smaller - VP8_QINDEX_RANGE, say, to match 
> >> .)
> > 
> > I just suggested it because its the only case we have in the codebase
> > that matches this:
> > git grep -E 'av_clip *\(.*, *0 *, 
> > *(3|7|15|31|63|127|255|511|1023|2047|4095|8191|16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|33554431|67108863|134217727|268435455|536870911|1073741823)
> >  *\)'
> > 
> > If we dont use the more optimized code everywhere then finding
> > cases where it makes a difference and isnt used is harder and not
> > something i would attempt.
> 
> These specialized integer av_clip* functions are optimized only for
> arm.

i am aware of that


> On x86 i don't think anyone ever did benchmarks to see if av_clip(),
> when the compiler properly uses cmov, isn't faster than all the
> arithmetical instructions from the alternatives. Especially intp2.

intp2 handles a subset of what av_clip handles, it should not be
slower, if it is slower it can directly be implemented with
av_clip(), i assume here that operations on constants are optimized
out. And i belive all? uses of (u)intp2 are with constants
Also you raise an important point, av_clip* should be benchmarked,
that might be tricky though as it would depend on the surrounding code


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

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


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

Re: [FFmpeg-devel] [PATCH] aacdec: When ignoring a PCE restore the previous config

[Carl Eugen Hoyos]

2017-02-16 22:13 GMT+01:00 Alex Converse :
> This is related to, but doesn't solve ticker 6152.
> ---
>  libavcodec/aacdec_template.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 4e0a9529e1..4367e74cf7 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -3036,6 +3036,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
> void *data,
>  if (pce_found) {
>  av_log(avctx, AV_LOG_ERROR,
> "Not evaluating a further program_config_element as 
> this construct is dubious at best.\n");
> +pop_output_configuration(ac);
>  } else {
>  err = output_configure(ac, layout_map, tags, OC_TRIAL_PCE, 
> 1);
>  if (!err)

I thought ticket #6152 was related to the else tree...

Anyway: Since this is your code, please wait a day or two
and push.

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

Re: [FFmpeg-devel] [PATCH]doc: correct-order-of-options-for-channelmap-filter

[Lou Logan]

On Fri, 17 Feb 2017 00:34:59 +0530, Mulvya V wrote:

> From fb16f34c7894d407be856e31081a750ab9426e1e Mon Sep 17 00:00:00 2001
> From: Mulvya 
> Date: Fri, 17 Feb 2017 00:27:32 +0530
> Subject: [PATCH] doc: correct order of options for channelmap filter
> 
> Signed-off-by: Mulvya 
> ---
>  doc/filters.texi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

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

Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties

[Aaron Colwell]

On Thu, Feb 16, 2017 at 11:09 AM Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> On Wed, Feb 15, 2017 at 2:54 PM, Aaron Colwell 
> wrote:
> > Hi Vittorio,
> >
> > This may not be a blocker for this patch, but one issue with converting
> the
> > bounds to pixels like you do here is that resizing a video could result
> in
> > incorrect metadata being generated when muxing. If you keep the bounds in
> > the 0.0-1.0 fixed point space this problem doesn't happen since it is a
> > resolution independent representation. If you still want to use pixels
> here
> > then the resizing filter will need to become aware of AVSphericalMapping
> and
> > adjust it accordingly. I think cubemap padding in pixels may have a
> similar
> > issue. This is no way intended to be a blocking comment. It is just
> meant to
> > raise awareness on something you might not have considered.
>
> Hi Aaron,
> this is an interesting point, but leaves up open questions. Do you
> foresee actual cases in which this is going to be a problem? It's not
> the first time we have fixed point fields exported, but it's also true
> that the conversion from a 0.32 system is not very common and could
> leave users puzzled. Regarding padding, is the specification going to
> be updated to fix this potential issue?
> Thank you
> --
> Vittorio
>

Hi Vittorio,

After sleeping on this, I think what you have will be fine. Resizing a
cubemap w/ padding is just going to have to be handled in a special way
because fractional pixel padding isn't going to work right on the GPU. You
really only want to waste a few pixels on padding, not a constant fraction
of the whole frame. Given that we have to handle cubemaps in a special way
for resizing, then my thoughts about resizing equirect aren't really a big
deal. I don't expect any spec changes will be needed for this.

I suppose this just a long way of saying "we will still need a followup for
resizing spherical videos properly, but this patch LGTM."

Thanks again for working on this.
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vaapi_encode_vp8: Use av_clip_uintp2()

[Michael Niedermayer]

On Thu, Feb 16, 2017 at 05:11:54PM +, Mark Thompson wrote:
> On 16/02/17 16:20, Michael Niedermayer wrote:
> > Its used elsewhere for 2^p-1 cliping
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vaapi_encode_vp8.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> > index 4a1c85e66c..3d3831c46d 100644
> > --- a/libavcodec/vaapi_encode_vp8.c
> > +++ b/libavcodec/vaapi_encode_vp8.c
> > @@ -161,12 +161,12 @@ static av_cold int 
> > vaapi_encode_vp8_configure(AVCodecContext *avctx)
> >  VAAPIEncodeContext *ctx = avctx->priv_data;
> >  VAAPIEncodeVP8Context *priv = ctx->priv_data;
> >  
> > -priv->q_index_p = av_clip(avctx->global_quality, 0, 127);
> > +priv->q_index_p = av_clip_uintp2(avctx->global_quality, 7);
> >  if (avctx->i_quant_factor > 0.0)
> > -priv->q_index_i = av_clip((avctx->global_quality *
> > +priv->q_index_i = av_clip_uintp2((avctx->global_quality *
> > avctx->i_quant_factor +
> > avctx->i_quant_offset) + 0.5,
> > -  0, 127);
> > +  7);
> >  else
> >  priv->q_index_i = priv->q_index_p;
> 
> IMO this makes the code less readable, not more.  It doesn't really matter to 
> anything, though, so commit it if you really want to.
> 
> (If this is mainly objecting to the magic number being visible there then 
> please do introduce a constant to hide it rather than making the constant 
> smaller - VP8_QINDEX_RANGE, say, to match 
> .)

I just suggested it because its the only case we have in the codebase
that matches this:
git grep -E 'av_clip *\(.*, *0 *, 
*(3|7|15|31|63|127|255|511|1023|2047|4095|8191|16383|32767|65535|131071|262143|524287|1048575|2097151|4194303|8388607|16777215|33554431|67108863|134217727|268435455|536870911|1073741823)
 *\)'

If we dont use the more optimized code everywhere then finding
cases where it makes a difference and isnt used is harder and not
something i would attempt.

i can also move this into fate-source
(there it might even be possible to keep track of exceptions)
but previous additions to fate-source had opposition, so iam not
doing that unless theres some positive feedback in that direction
first ...

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH v1 0/2] Add support for raw video over RTP

[Carl Eugen Hoyos]

2017-02-16 18:43 GMT+01:00 Damien Riegel :
> This patchset adds support for the RFC 4175: RTP Payload Format for
> Uncompressed Video. [1]
>
> It only supports progressive YCbCr 4:2:2 video format, with 8-bit and
> 10-bit samples.

How is the 10-bit payload expected to be sent?
Big- or little-endian?

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

[Mark Thompson]

On 16/02/17 18:29, Aman Gupta wrote:
> From: Aman Gupta 
> 
> This fixes playback of h264 streams with SPS changes. One such sample
> is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> It switches mid-stream from level 4.0 to level 3.2.
> 
> Previously, playing this sample with the VT hwaccel on iOS would crash.
> After this patch, it plays back as expected.
> 
> On macOS however, feeding in new SPS into an existing decompression
> session does not always work, so this patch is only a partial fix.
> ---
>  libavcodec/h264dec.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 41c0964..e521c52 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  break;
>  case H264_NAL_SPS: {
>  GetBitContext tmp_gb = nal->gb;
> +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> AV_PIX_FMT_VIDEOTOOLBOX) {
> +ret = avctx->hwaccel->decode_slice(avctx,
> +   nal->data,
> +   nal->size);
> +if (ret < 0)
> +goto end;
> +}
>  if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 0) 
> >= 0)
>  break;
>  av_log(h->avctx, AV_LOG_DEBUG,
> 

The SPS isn't a slice - calling decode_slice() on it is confusing.  I realise 
you are really using it as "upload blob" and that does basically make sense, 
but changes like this are moving it further away from being maintainable as a 
hwaccel.  (Compare how many DXVA- or VAAPI-specific code paths currently exist 
in the decoder outside the actual hwaccel functions.)  The previous patches 
doing the same thing with the PPS and fiddling something funny inside the 
reference picture lists are similar - in themselves not obviously unreasonable, 
but making the code trickier in ways which may make things more difficult later.

So, I think this needs a step back to consider whether this should actually be 
implemented as a hwaccel at all if changes like this are needed:

It looks like you are now supplying it all video-significant packets - what 
would need to be implemented to do this without being inside hwaccel 
infrastructure?  (As a standalone full-bitstream decoder, but possibly calling 
in to the existing H.264 code if that helps.)

On the other hand, if it is going to continue being a hwaccel, can we add make 
some changes to the internal hwaccel API to avoid having to make changes like 
this in the generic decoder?  (Also thinking of other codecs - you're changing 
H.264 here, are other codecs going to run into similar issues, particularly 
H.265 which is structurally very similar in these aspects?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-user] ffmpeg engineer

[Reuben Martin]

Well, I’m U.S. citizen, so visa stuff isn’t an issue, but I’ve never been 
impressed with JVM/JRE enough to take time to learn it.

Just FYI, for DASH, you will probably want somebody proficient in C who is 
somewhat familiar with the ffmpeg code base who can also develop patches for 
ffmpeg. The ffmpeg DASH implementation, while always being improved, is still 
not very well polished yet. Various samples provided by members of the Dash 
Industry Forum don’t play back correctly with ffmpeg, and vice versa. 
Especially with the live profile.

Good luck.

-Reuben

On Thursday, February 16, 2017 12:57:15 PM CST Batman wrote:
> This is a development role for sure - JVM knowledge is a must. (ideally
> Scala)
> 
> We could chat about re-lo, but it's a full-time role so visas would have to
> be in order already, I don't believe they're looking to sponsor.  I believe
> they're using DASH but not 100% sure.
> 
> (Mike Cohen - A.K.A. Batman)
> 
> *BatPhone:* 617.999.0818
> 
> 
> 
> 
>   
> 
> 
> 
> On Thu, Feb 16, 2017 at 12:55 PM, Reuben Martin  wrote:
> > On Thursday, February 16, 2017 11:05:09 AM CST Batman wrote:
> > > Hey All!  I'm helping Giphy (our favourite Gif Platform) find an a
> > > video-streaming engineer and they'd LOVE someone with some ffmpeg
> > > experience.
> > 
> > Riddle me this Batman... “video-streaming engineer” is a rather ambigious
> > title. Is this a development role (writing code to integrate streaming
> > with
> > their stack) or more of an operations role (running it and making it
> > function
> > correctly)? Or perhaps with a group that small it’s a bit of both? Curious
> > because if it’s the former, it would make a bit more sense to post this in
> > the
> > ffmpeg-dev list.
> > 
> > > NYC - Scala Stack - Pays very well - company has over $150M in funding
> > 
> > and
> > 
> > > just moved to an amazing new office (still under 70 people)
> > 
> > Does it require re-location? Does it require experience with Scala?
> > 
> > I’m EIC (Engineer-In-Charge) for the video crew of a live events
> > production
> > company that does several live streamed events per month with full
> > production
> > (lights, video, sound, set design, etc). I also build and maintain our
> > ffmpeg
> > based RTMP encoding-streaming servers and wrote the Ruby code that glues
> > all
> > the bits and pieces together. I’m _trying_ to find time to become
> > proficient
> > in Elixir.
> > 
> > Although, I’m not sure Giphy would have use for live streaming. More
> > likely
> > they are interested in a segmented format like HLS, DASH or even
> > SmoothStreaming?
> > 
> > -Reuben


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

Re: [FFmpeg-devel] [PATCH] libopus: decode ambisonics with non-diegetic sources

[Felicia Lim]

Hi all,

Just wanted to follow up this patch which allows decoding opus ambisonics
with an additional stereo stream at the end. Please let me know if there
are any changes I should make to it?

Thanks,
Felicia

On Fri, Feb 10, 2017 at 10:42 AM Felicia Lim  wrote:

> Hi all,
>
> The attached patch allows libavcodec/opus to decode ambisonics with
> non-diegetic stereo stream in an ogg/opus container, as is being added in
> this IETF standards draft [1].
>
> Please let me know if there are any concerns.
>
> Thanks,
> Felicia
>
> [1] https://tools.ietf.org/html/draft-ietf-codec-ambisonics-01#section-3.1
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

[Éloi Bail]

Hi, 

In november, we wrote on the mailing list about implementing support for TR-03 
in ffmpeg [1]. 
There were some doubts in the ffmpeg community about whether or not ffmpeg 
could handle demuxing 3gbps of RTP input without significantly modifying the 
RTP demuxer and/or doing kernel bypassing. 

CBC/Radio Canada contracted us to test what was possible and to try to 
implement TR-03 
in ffmpeg. Using 2 servers connected by 10gbps fibre optic connection and a 
switch we 
performed several tests with various tools which showed that it should be 
possible to 
receive and demux 3gbps of RTP raw video with a large enough RX queue in the 
NIC and the socket. We then patched ffmpeg to support depayloading 8 and 10 bit 
raw video [2] and process the input stream on a seperate thread [3]. This 
allowed us 
to succesfully receive a 3gbps raw video stream in ffmpeg and write the raw 
video to 
the disk. We were also able to transcode it into h264. 

Thus it seems to us that ffmpeg should be able to support TR-03 without 
significant 
modifications nor kernel bypassing. 

Bellow is a more detailed description of our testing and development process: 

1. In the Linux Kernel: Thanks to iperf tool, we tested that the Linux 
kernel is able to handle 3gbps of udp streams with a payload size of 800 to 
1450 bytes. 

2. Using a simple RTP demuxer, we ensured that a user space program is able 
to handle a 3gbps stream without dropping packets. When adding an 
increasing amount of processing per packet, we observed that eventually 
packets are dropped. We concluded that minimal processing per packet should 
be used to achieve the reception of 3 gbps video stream. 

3. We played with Gstreamer which already implements an RTP raw video muxer 
/ demuxer. We were able to send a 3gbps video stream without dropping any 
packets. In reception, we experienced around 20% packet drop with 3gbps 
video stream because the thread in charge of socket reading is taking 100% 
CPU. Gstreamer team is aware of that and have ideas to reduce significantly 
the CPU usage grouping the processing per packet with the recvmmsg syscall 

4. We implement an RTP demuxer compatible with RFC 4175 and pixel format 
422-8bits and 422-10bits [2] 

* Checking FFmpeg tool code, we saw that a separate input thread(s) is used 
only if there is more than one input. With a minimal pipeline which reads 
an RTP stream from a socket and writes the raw video into a file, we 
observed that packets were dropped because too much time was used for 
packet processing. 

We modified FFmpeg tool to force the use of a dedicated input thread. 

5. Several queues are used from packet reception to packet processing. 
Tunning each queue allowed us to have zero packet dropped: 

* In the NIC queue: thanks to ethtool, we increased the queue size from 453 
to its maximum (4078) to avoid packet dropped in the NIC queue 

* In the Kernel queue: we observed no packet dropped after increasing the 
queue size to 16 mo 

* In the jitter buffer queue (FFmpeg): By default the jitter buffer is 
sized for 500 packets. With 1080P raw videos (RFC4175), we calculated 
that a video frame would lead to around 3000 packets. 

To be more resilient to packets reordering, we could increase the size of 
the jitter buffer but we observed that using a big jitter buffer, a 
significant processing per packet is added and lead thus to packet dropped 
in the Kernel. In addition, RFC4175 adds a mechanism to be resiliant to packet 
reordering per video frame. 

Results: 
* With : 
- our test setup composed of 2 servers running Centos 7 linked by a 10gbps 
switch. 
- our modified FFmpeg to handle RFC4175 and to improve the reading 
performance, 
- NIC and Kernel queues tunned and FFmpeg jitter buffer disabled 

we were able to: 
- send a 3 gbps video stream with gstreamer 
- receive with FFmpeg a 3 gbps video stream 422-8 bits without dropping any 
packets nor having any video artifacts. 
* However, using pixel format 4.2.2 10bits (packed), we encountered a 
performance degradation. Indeed 4.2.2 10bits (packed) is not supported in 
FFmpeg. We decided to convert into a 4.2.2 10bits planar format. We 
believe that this conversion adds too much processing per packets and thus 
leads to packets dropped. 
We are able to stream (and live transcode) 1080p 60fps 42210-bits without 
dropping packets. In reception the 
bandwidth is around 2.2 gbps. 

[1]: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202554.html 
[2]: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207253.html 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties

[Vittorio Giovara]

On Wed, Feb 15, 2017 at 2:54 PM, Aaron Colwell  wrote:
> Hi Vittorio,
>
> This may not be a blocker for this patch, but one issue with converting the
> bounds to pixels like you do here is that resizing a video could result in
> incorrect metadata being generated when muxing. If you keep the bounds in
> the 0.0-1.0 fixed point space this problem doesn't happen since it is a
> resolution independent representation. If you still want to use pixels here
> then the resizing filter will need to become aware of AVSphericalMapping and
> adjust it accordingly. I think cubemap padding in pixels may have a similar
> issue. This is no way intended to be a blocking comment. It is just meant to
> raise awareness on something you might not have considered.

Hi Aaron,
this is an interesting point, but leaves up open questions. Do you
foresee actual cases in which this is going to be a problem? It's not
the first time we have fixed point fields exported, but it's also true
that the conversion from a 0.32 system is not very common and could
leave users puzzled. Regarding padding, is the specification going to
be updated to fix this potential issue?
Thank you
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avcodec/videotoolbox: restart decompression session on bad data errors

[Aman Gupta]

From: Aman Gupta 

On some platforms (observed on macOS Sierra with 12" macbook), the VT
decoder will start returning errors when encountering an SPS change in
the h264 bitstream. With this patch, the kVTVideoDecoderBadDataErr
response from the decoder is caught and the decompression session is
recreated with a new avcC. The "bad data" is then fed into the new
decompression session so that it can be decoded correctly.

I discovered the underlying issue here by running ffmpeg with lldb,
which causes macOS to display debug information from the VT hardware
decoder on stderr. The following errors were shown, which indicated the
need to restart the decoder session with a new SPS/avcC:

  ffmpeg[15127:4094995] GVA error: SPS mismatch ...
  ffmpeg[15127:4094995] GVA error: AVF_PushMetaData, first field 
kAVF_QT0_SPSPPSBoundaryMarker
  ffmpeg[15127:4094995] GVA error: pushMetaData, submitNewJobs
  ffmpeg[15127:4094995] GVA warning: OutputQueueReadyCallback status = 1, 
buffer == 0x0

Tested with the following sample, which contains an SPS change midstream:
http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts
---
 libavcodec/videotoolbox.c | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 9be7bee..159d98d 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -38,6 +38,9 @@
 
 #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
 
+static void videotoolbox_stop(AVCodecContext *avctx);
+static int videotoolbox_start(AVCodecContext *avctx);
+
 static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
 {
 CVPixelBufferRef cv_buffer = (CVImageBufferRef)data;
@@ -350,13 +353,25 @@ static int videotoolbox_common_end_frame(AVCodecContext 
*avctx, AVFrame *frame)
 int status;
 AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+int retry;
 
 av_buffer_unref(>buf[0]);
 
 if (!videotoolbox->session || !vtctx->bitstream)
 return AVERROR_INVALIDDATA;
 
-status = videotoolbox_session_decode_frame(avctx);
+for (retry = 0; retry < 2; retry++) {
+status = videotoolbox_session_decode_frame(avctx);
+
+if (status == kVTVideoDecoderBadDataErr) {
+av_log(avctx, AV_LOG_DEBUG, "vt decoder got bad data error, 
restarting..\n");
+videotoolbox_stop(avctx);
+videotoolbox_start(avctx);
+continue;
+} else {
+break;
+}
+}
 
 if (status) {
 av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%d)\n", status);
@@ -506,7 +521,7 @@ static CMVideoFormatDescriptionRef 
videotoolbox_format_desc_create(CMVideoCodecT
 return cm_fmt_desc;
 }
 
-static int videotoolbox_default_init(AVCodecContext *avctx)
+static int videotoolbox_start(AVCodecContext *avctx)
 {
 AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
 OSStatus status;
@@ -587,7 +602,12 @@ static int videotoolbox_default_init(AVCodecContext *avctx)
 }
 }
 
-static void videotoolbox_default_free(AVCodecContext *avctx)
+static int videotoolbox_default_init(AVCodecContext *avctx)
+{
+return videotoolbox_start(avctx);
+}
+
+static void videotoolbox_stop(AVCodecContext *avctx)
 {
 AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
 if (!videotoolbox)
@@ -696,7 +716,7 @@ int av_videotoolbox_default_init2(AVCodecContext *avctx, 
AVVideotoolboxContext *
 void av_videotoolbox_default_free(AVCodecContext *avctx)
 {
 
-videotoolbox_default_free(avctx);
+videotoolbox_stop(avctx);
 av_freep(>hwaccel_context);
 }
 #endif /* CONFIG_VIDEOTOOLBOX */
-- 
2.10.1 (Apple Git-78)

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

[FFmpeg-devel] [PATCH 2/3] avcodec/videotoolbox: cosmetic change to simplify code with early return

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/videotoolbox.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 1288aa5..9be7bee 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -590,15 +590,16 @@ static int videotoolbox_default_init(AVCodecContext 
*avctx)
 static void videotoolbox_default_free(AVCodecContext *avctx)
 {
 AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
+if (!videotoolbox)
+return;
 
-if (videotoolbox) {
-if (videotoolbox->cm_fmt_desc)
-CFRelease(videotoolbox->cm_fmt_desc);
+if (videotoolbox->cm_fmt_desc)
+CFRelease(videotoolbox->cm_fmt_desc);
 
-if (videotoolbox->session) {
-VTDecompressionSessionInvalidate(videotoolbox->session);
-CFRelease(videotoolbox->session);
-}
+if (videotoolbox->session) {
+VTDecompressionSessionInvalidate(videotoolbox->session);
+CFRelease(videotoolbox->session);
+videotoolbox->session = NULL;
 }
 }
 
-- 
2.10.1 (Apple Git-78)

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

Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

[Rostislav Pehlivanov]

On 16 February 2017 at 18:18, Rostislav Pehlivanov 
wrote:

>
>
> On 16 February 2017 at 17:43, Damien Riegel  savoirfairelinux.com> wrote:
>
>> Add a codec capable of decoding some formats of the RFC4175. For now
>> it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth.
>>
>> For 8-bit it's a simple pass-through, for 10-bit it depacks the stream
>> in the AV_PIX_FMT_YUV422P10 pixel format.
>> Change-Id: Id2184a6cee7031edbcb65a39a369623114c1783c
>>
>> Signed-off-by: Damien Riegel 
>> ---
>>  libavcodec/Makefile |   1 +
>>  libavcodec/allcodecs.c  |   1 +
>>  libavcodec/avcodec.h|   1 +
>>  libavcodec/codec_desc.c |   7 +++
>>  libavcodec/vrawdepay.c  | 113 ++
>> ++
>>  5 files changed, 123 insertions(+)
>>  create mode 100644 libavcodec/vrawdepay.c
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index a1ce264f25..e09dcc3c1b 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -614,6 +614,7 @@ OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuvid.o
>>  OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
>>  OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
>>  OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
>> +OBJS-$(CONFIG_VRAWDEPAY_DECODER)   += vrawdepay.o
>>  OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
>>  OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
>>  OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index f12a54df50..dcce291ba2 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -365,6 +365,7 @@ void avcodec_register_all(void)
>>  REGISTER_DECODER(VP8,   vp8);
>>  REGISTER_DECODER(VP9,   vp9);
>>  REGISTER_DECODER(VQA,   vqa);
>> +REGISTER_DECODER(VRAWDEPAY, vrawdepay);
>>  REGISTER_DECODER(WEBP,  webp);
>>  REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
>>  REGISTER_ENCDEC (WMV1,  wmv1);
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 5616fb01d6..aca4fe61e6 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -415,6 +415,7 @@ enum AVCodecID {
>>  AV_CODEC_ID_PIXLET,
>>  AV_CODEC_ID_SPEEDHQ,
>>  AV_CODEC_ID_FMVC,
>> +AV_CODEC_ID_VRAWDEPAY,
>>
>>  /* various PCM "codecs" */
>>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
>> the start of audio codecs
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index 35846c054e..8a3492adcf 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -1360,6 +1360,13 @@ static const AVCodecDescriptor codec_descriptors[]
>> = {
>>  .long_name = NULL_IF_CONFIG_SMALL("FM Screen Capture Codec"),
>>  .props = AV_CODEC_PROP_LOSSLESS,
>>  },
>> +{
>> +.id= AV_CODEC_ID_VRAWDEPAY,
>> +.type  = AVMEDIA_TYPE_VIDEO,
>> +.name  = "rfc4175",
>> +.long_name = NULL_IF_CONFIG_SMALL("RFC4175 video depayloader"),
>> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
>> +},
>>
>>  /* image codecs */
>>  {
>> diff --git a/libavcodec/vrawdepay.c b/libavcodec/vrawdepay.c
>> new file mode 100644
>> index 00..53a5c38bb3
>> --- /dev/null
>> +++ b/libavcodec/vrawdepay.c
>> @@ -0,0 +1,113 @@
>> +/*
>> + * Raw Video Depayloader (RFC4175)
>> + * Copyright (c) 2017 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 */
>> +
>> +/**
>> + * @file
>> + * Raw Video Depayloader (RFC4175)
>> + */
>> +
>> +#include 
>> +#include "avcodec.h"
>> +#include "internal.h"
>> +#include "get_bits.h"
>> +
>> +static av_cold int vrawdepay_init_decoder(AVCodecContext *avctx)
>> +{
>> +   if (!avctx->codec_tag || !avctx->width || !avctx->height)
>> +  return -1;
>> +
>> +   if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
>> +  if (avctx->bits_per_coded_sample == 16)
>> + avctx->pix_fmt = AV_PIX_FMT_UYVY422;
>> +  

Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

[Rostislav Pehlivanov]

On 16 February 2017 at 17:43, Damien Riegel <
damien.rie...@savoirfairelinux.com> wrote:

> Add a codec capable of decoding some formats of the RFC4175. For now
> it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth.
>
> For 8-bit it's a simple pass-through, for 10-bit it depacks the stream
> in the AV_PIX_FMT_YUV422P10 pixel format.
> Change-Id: Id2184a6cee7031edbcb65a39a369623114c1783c
>
> Signed-off-by: Damien Riegel 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +++
>  libavcodec/vrawdepay.c  | 113 ++
> ++
>  5 files changed, 123 insertions(+)
>  create mode 100644 libavcodec/vrawdepay.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index a1ce264f25..e09dcc3c1b 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -614,6 +614,7 @@ OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuvid.o
>  OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
>  OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
>  OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
> +OBJS-$(CONFIG_VRAWDEPAY_DECODER)   += vrawdepay.o
>  OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
>  OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
>  OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index f12a54df50..dcce291ba2 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -365,6 +365,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(VP8,   vp8);
>  REGISTER_DECODER(VP9,   vp9);
>  REGISTER_DECODER(VQA,   vqa);
> +REGISTER_DECODER(VRAWDEPAY, vrawdepay);
>  REGISTER_DECODER(WEBP,  webp);
>  REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
>  REGISTER_ENCDEC (WMV1,  wmv1);
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5616fb01d6..aca4fe61e6 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -415,6 +415,7 @@ enum AVCodecID {
>  AV_CODEC_ID_PIXLET,
>  AV_CODEC_ID_SPEEDHQ,
>  AV_CODEC_ID_FMVC,
> +AV_CODEC_ID_VRAWDEPAY,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 35846c054e..8a3492adcf 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1360,6 +1360,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("FM Screen Capture Codec"),
>  .props = AV_CODEC_PROP_LOSSLESS,
>  },
> +{
> +.id= AV_CODEC_ID_VRAWDEPAY,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "rfc4175",
> +.long_name = NULL_IF_CONFIG_SMALL("RFC4175 video depayloader"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
>
>  /* image codecs */
>  {
> diff --git a/libavcodec/vrawdepay.c b/libavcodec/vrawdepay.c
> new file mode 100644
> index 00..53a5c38bb3
> --- /dev/null
> +++ b/libavcodec/vrawdepay.c
> @@ -0,0 +1,113 @@
> +/*
> + * Raw Video Depayloader (RFC4175)
> + * Copyright (c) 2017 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 */
> +
> +/**
> + * @file
> + * Raw Video Depayloader (RFC4175)
> + */
> +
> +#include 
> +#include "avcodec.h"
> +#include "internal.h"
> +#include "get_bits.h"
> +
> +static av_cold int vrawdepay_init_decoder(AVCodecContext *avctx)
> +{
> +   if (!avctx->codec_tag || !avctx->width || !avctx->height)
> +  return -1;
> +
> +   if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
> +  if (avctx->bits_per_coded_sample == 16)
> + avctx->pix_fmt = AV_PIX_FMT_UYVY422;
> +  else if (avctx->bits_per_coded_sample == 20)
> + avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
> +  else
> + return -1;
> +   } else {
> +  return -1;
> +   }
> +
> +return 0;
> +}
> +
> 

[FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

[Damien Riegel]

Add a codec capable of decoding some formats of the RFC4175. For now
it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth.

For 8-bit it's a simple pass-through, for 10-bit it depacks the stream
in the AV_PIX_FMT_YUV422P10 pixel format.
Change-Id: Id2184a6cee7031edbcb65a39a369623114c1783c

Signed-off-by: Damien Riegel 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +++
 libavcodec/vrawdepay.c  | 113 
 5 files changed, 123 insertions(+)
 create mode 100644 libavcodec/vrawdepay.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a1ce264f25..e09dcc3c1b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -614,6 +614,7 @@ OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuvid.o
 OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
 OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
 OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
+OBJS-$(CONFIG_VRAWDEPAY_DECODER)   += vrawdepay.o
 OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
 OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
 OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f12a54df50..dcce291ba2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -365,6 +365,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(VP8,   vp8);
 REGISTER_DECODER(VP9,   vp9);
 REGISTER_DECODER(VQA,   vqa);
+REGISTER_DECODER(VRAWDEPAY, vrawdepay);
 REGISTER_DECODER(WEBP,  webp);
 REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
 REGISTER_ENCDEC (WMV1,  wmv1);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5616fb01d6..aca4fe61e6 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -415,6 +415,7 @@ enum AVCodecID {
 AV_CODEC_ID_PIXLET,
 AV_CODEC_ID_SPEEDHQ,
 AV_CODEC_ID_FMVC,
+AV_CODEC_ID_VRAWDEPAY,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 35846c054e..8a3492adcf 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1360,6 +1360,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("FM Screen Capture Codec"),
 .props = AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_VRAWDEPAY,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "rfc4175",
+.long_name = NULL_IF_CONFIG_SMALL("RFC4175 video depayloader"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
 
 /* image codecs */
 {
diff --git a/libavcodec/vrawdepay.c b/libavcodec/vrawdepay.c
new file mode 100644
index 00..53a5c38bb3
--- /dev/null
+++ b/libavcodec/vrawdepay.c
@@ -0,0 +1,113 @@
+/*
+ * Raw Video Depayloader (RFC4175)
+ * Copyright (c) 2017 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 */
+
+/**
+ * @file
+ * Raw Video Depayloader (RFC4175)
+ */
+
+#include 
+#include "avcodec.h"
+#include "internal.h"
+#include "get_bits.h"
+
+static av_cold int vrawdepay_init_decoder(AVCodecContext *avctx)
+{
+   if (!avctx->codec_tag || !avctx->width || !avctx->height)
+  return -1;
+
+   if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
+  if (avctx->bits_per_coded_sample == 16)
+ avctx->pix_fmt = AV_PIX_FMT_UYVY422;
+  else if (avctx->bits_per_coded_sample == 20)
+ avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
+  else
+ return -1;
+   } else {
+  return -1;
+   }
+
+return 0;
+}
+
+static av_cold int vrawdepay_close_decoder(AVCodecContext *avctx)
+{
+   return 0;
+}
+
+static int vrawdepay_decode(AVCodecContext *avctx, void *data, int *got_frame,
+  AVPacket *avpkt)
+{
+   const uint8_t *buf = avpkt->data;
+   int buf_size = avpkt->size;
+   AVFrame *frame = data;
+   int res;
+
+   frame->pict_type = 

[FFmpeg-devel] [PATCH v1 0/2] Add support for raw video over RTP

[Damien Riegel]

This patchset adds support for the RFC 4175: RTP Payload Format for
Uncompressed Video. [1]

It only supports progressive YCbCr 4:2:2 video format, with 8-bit and
10-bit samples.

[1] https://tools.ietf.org/html/rfc4175

Damien Riegel (2):
  codec: vrawdepay: add decoder for RFC4175
  rtp: rawvideo: add handler for YCbCr-4:2:2

 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/avcodec.h  |   1 +
 libavcodec/codec_desc.c   |   7 ++
 libavcodec/vrawdepay.c| 113 +
 libavformat/Makefile  |   1 +
 libavformat/rtpdec.c  |   1 +
 libavformat/rtpdec_formats.h  |   1 +
 libavformat/rtpdec_rawvideo.c | 226 ++
 9 files changed, 352 insertions(+)
 create mode 100644 libavcodec/vrawdepay.c
 create mode 100644 libavformat/rtpdec_rawvideo.c

-- 
2.11.1

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

[FFmpeg-devel] [PATCH v1 2/2] rtp: rawvideo: add handler for YCbCr-4:2:2

[Damien Riegel]

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 
---
 libavformat/Makefile  |   1 +
 libavformat/rtpdec.c  |   1 +
 libavformat/rtpdec_formats.h  |   1 +
 libavformat/rtpdec_rawvideo.c | 226 ++
 4 files changed, 229 insertions(+)
 create mode 100644 libavformat/rtpdec_rawvideo.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index fc2d76067b..e17ba95c23 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_rawvideo.o   \
 rtpdec_svq3.o   \
 rtpdec_vc2hq.o  \
 rtpdec_vp8.o\
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 53cdad7396..345318c32c 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(_rawvideo_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..fab12fd139 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_rawvideo_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_rawvideo.c b/libavformat/rtpdec_rawvideo.c
new file mode 100644
index 00..69a9532d76
--- /dev/null
+++ b/libavformat/rtpdec_rawvideo.c
@@ -0,0 +1,226 @@
+/*
+ * 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 raw_parse_format(AVStream *stream,
+PayloadContext *data)
+{
+int tag = 0;
+int bits_per_sample = 0;
+
+if (!strcmp(data->sampling, "YCbCr-4:2:2")) {
+tag = MKTAG('U', 'Y', 'V', 'Y');
+data->xinc = 2;
+
+if (data->depth == 8) {
+data->pgroup = 4;
+bits_per_sample = 16;
+} else if (data->depth == 10) {
+data->pgroup = 5;
+bits_per_sample = 20;
+} else {
+return -1;
+}
+} else {
+return -1;
+}
+
+stream->codecpar->codec_tag = tag;
+stream->codecpar->bits_per_coded_sample = bits_per_sample;
+data->frame_size = data->width * 

Re: [FFmpeg-devel] [PATCH v2 0/5] A native Opus encoder

[Rostislav Pehlivanov]

On 16 February 2017 at 13:08, Moritz Barsnick  wrote:

> On Tue, Feb 14, 2017 at 06:37:16 +, Rostislav Pehlivanov wrote:
> > Applied!
> > Thanks for all the people who commented on it
>
> This deserves a Changelog entry. (I missed that during the review
> process.)
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Thanks for the reminder, pushed an update to the Changelog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vaapi_encode_vp8: Use av_clip_uintp2()

[Mark Thompson]

On 16/02/17 16:20, Michael Niedermayer wrote:
> Its used elsewhere for 2^p-1 cliping
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vaapi_encode_vp8.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> index 4a1c85e66c..3d3831c46d 100644
> --- a/libavcodec/vaapi_encode_vp8.c
> +++ b/libavcodec/vaapi_encode_vp8.c
> @@ -161,12 +161,12 @@ static av_cold int 
> vaapi_encode_vp8_configure(AVCodecContext *avctx)
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VAAPIEncodeVP8Context *priv = ctx->priv_data;
>  
> -priv->q_index_p = av_clip(avctx->global_quality, 0, 127);
> +priv->q_index_p = av_clip_uintp2(avctx->global_quality, 7);
>  if (avctx->i_quant_factor > 0.0)
> -priv->q_index_i = av_clip((avctx->global_quality *
> +priv->q_index_i = av_clip_uintp2((avctx->global_quality *
> avctx->i_quant_factor +
> avctx->i_quant_offset) + 0.5,
> -  0, 127);
> +  7);
>  else
>  priv->q_index_i = priv->q_index_p;

IMO this makes the code less readable, not more.  It doesn't really matter to 
anything, though, so commit it if you really want to.

(If this is mainly objecting to the magic number being visible there then 
please do introduce a constant to hide it rather than making the constant 
smaller - VP8_QINDEX_RANGE, say, to match 
.)

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

Re: [FFmpeg-devel] aac_latm: SSR is not implemented

[Aman Gupta]

On Wed, Feb 1, 2017 at 9:12 AM Carl Eugen Hoyos  wrote:

> 2017-02-01 5:06 GMT+01:00 Aman Gupta :
> > I have a mpegts file with a HE-AAC audio track that cannot be decoded by
> > ffmpeg. I have uploaded a sample at the link below, as requested by the
> > decoder.
>
> Maybe ticket #4544, thank you for the sample!
>

Looks like that ticket was a separate issue, but I ended up leaving some
comments in there accidentally about SSR support.

Not sure if this list is the best place to ask, but I would be interested
in financially sponsoring the development of this feature. There is a
partial implementation availabile already in the gsoc svn repo that would
need to be rebased on to master.

If anyone is interested and has time, contact me off-list with a quote.

Thanks,
Aman


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

[FFmpeg-devel] [PATCH] avcodec/vaapi_encode_vp8: Use av_clip_uintp2()

[Michael Niedermayer]

Its used elsewhere for 2^p-1 cliping

Signed-off-by: Michael Niedermayer 
---
 libavcodec/vaapi_encode_vp8.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index 4a1c85e66c..3d3831c46d 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encode_vp8.c
@@ -161,12 +161,12 @@ static av_cold int 
vaapi_encode_vp8_configure(AVCodecContext *avctx)
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAAPIEncodeVP8Context *priv = ctx->priv_data;
 
-priv->q_index_p = av_clip(avctx->global_quality, 0, 127);
+priv->q_index_p = av_clip_uintp2(avctx->global_quality, 7);
 if (avctx->i_quant_factor > 0.0)
-priv->q_index_i = av_clip((avctx->global_quality *
+priv->q_index_i = av_clip_uintp2((avctx->global_quality *
avctx->i_quant_factor +
avctx->i_quant_offset) + 0.5,
-  0, 127);
+  7);
 else
 priv->q_index_i = priv->q_index_p;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 3/4] x86util: import MOVHL macro

[Paul B Mahol]

On 2/16/17, James Darnley  wrote:
> Originally committed to x264 in 1637239a by Henrik Gramner who has
> agreed to re-license it as LGPL.  Original commit message follows.
>
> x86: Avoid some bypass delays and false dependencies
>
> A bypass delay of 1-3 clock cycles may occur on some CPUs when
> transitioning
> between int and float domains, so try to avoid that if possible.
> ---
>  libavutil/x86/x86util.asm | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/libavutil/x86/x86util.asm b/libavutil/x86/x86util.asm
> index c063436..1408f0a 100644
> --- a/libavutil/x86/x86util.asm
> +++ b/libavutil/x86/x86util.asm
> @@ -876,3 +876,15 @@
>  psrlq   %1, 8*(%2)
>  %endif
>  %endmacro
> +
> +%macro MOVHL 2 ; dst, src
> +%ifidn %1, %2
> +punpckhqdq %1, %2
> +%elif cpuflag(avx)
> +punpckhqdq %1, %2, %2
> +%elif cpuflag(sse4)
> +pshufd %1, %2, q3232 ; pshufd is slow on some older CPUs, so only
> use it on more modern ones
> +%else
> +movhlps%1, %2; may cause an int/float domain transition and
> has a dependency on dst
> +%endif
> +%endmacro

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

[FFmpeg-devel] [PATCH 1/4] avcodec/x86: deduplicate PASS8ROWS macro

[James Darnley]

---
 libavcodec/x86/h264_deblock.asm   | 5 -
 libavcodec/x86/h264_deblock_10bit.asm | 5 -
 libavcodec/x86/hevc_deblock.asm   | 5 -
 libavutil/x86/x86util.asm | 5 +
 4 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index fe0ab20..435c8be 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -37,11 +37,6 @@ cextern pb_0
 cextern pb_1
 cextern pb_3
 
-; expands to [base],...,[base+7*stride]
-%define PASS8ROWS(base, base3, stride, stride3) \
-[base], [base+stride], [base+stride*2], [base3], \
-[base3+stride], [base3+stride*2], [base3+stride3], [base3+stride*4]
-
 %define PASS8ROWS(base, base3, stride, stride3, offset) \
 PASS8ROWS(base+offset, base3+offset, stride, stride3)
 
diff --git a/libavcodec/x86/h264_deblock_10bit.asm 
b/libavcodec/x86/h264_deblock_10bit.asm
index c295364..1af3257 100644
--- a/libavcodec/x86/h264_deblock_10bit.asm
+++ b/libavcodec/x86/h264_deblock_10bit.asm
@@ -843,11 +843,6 @@ DEBLOCK_LUMA_INTRA
 mova [r0+2*r1], m2
 %endmacro
 
-; expands to [base],...,[base+7*stride]
-%define PASS8ROWS(base, base3, stride, stride3) \
-[base], [base+stride], [base+stride*2], [base3], \
-[base3+stride], [base3+stride*2], [base3+stride3], [base3+stride*4]
-
 ; in: 8 rows of 4 words in %4..%11
 ; out: 4 rows of 8 words in m0..m3
 %macro TRANSPOSE4x8W_LOAD 8
diff --git a/libavcodec/x86/hevc_deblock.asm b/libavcodec/x86/hevc_deblock.asm
index 48a5975..85ee480 100644
--- a/libavcodec/x86/hevc_deblock.asm
+++ b/libavcodec/x86/hevc_deblock.asm
@@ -39,11 +39,6 @@ cextern pw_m1
 SECTION .text
 INIT_XMM sse2
 
-; expands to [base],...,[base+7*stride]
-%define PASS8ROWS(base, base3, stride, stride3) \
-[base], [base+stride], [base+stride*2], [base3], \
-[base3+stride], [base3+stride*2], [base3+stride3], [base3+stride*4]
-
 ; in: 8 rows of 4 bytes in %4..%11
 ; out: 4 rows of 8 words in m0..m3
 %macro TRANSPOSE4x8B_LOAD 8
diff --git a/libavutil/x86/x86util.asm b/libavutil/x86/x86util.asm
index 44ed750..c063436 100644
--- a/libavutil/x86/x86util.asm
+++ b/libavutil/x86/x86util.asm
@@ -29,6 +29,11 @@
 
 %include "libavutil/x86/x86inc.asm"
 
+; expands to [base],...,[base+7*stride]
+%define PASS8ROWS(base, base3, stride, stride3) \
+[base],   [base  + stride],   [base  + 2*stride], [base3], \
+[base3 + stride], [base3 + 2*stride], [base3 + stride3],  [base3 + 
stride*4]
+
 %macro SBUTTERFLY 4
 %ifidn %1, dqqq
 vperm2i128  m%4, m%2, m%3, q0301
-- 
2.8.3

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

[FFmpeg-devel] [PATCH 2/4] avcodec/h264: add named parameters to x86 function

[James Darnley]

---
 libavcodec/x86/h264_deblock.asm | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 435c8be..509a0db 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -282,18 +282,18 @@ cextern pb_3
 ;int8_t *tc0)
 ;-
 %macro DEBLOCK_LUMA 0
-cglobal deblock_v_luma_8, 5,5,10
+cglobal deblock_v_luma_8, 5,5,10, pix_, stride_, alpha_, beta_, base3_
 movdm8, [r4] ; tc0
-lea r4, [r1*3]
-dec r2d; alpha-1
+lea r4, [stride_q*3]
+dec alpha_d; alpha-1
 neg r4
-dec r3d; beta-1
-add r4, r0 ; pix-3*stride
+dec beta_d; beta-1
+add base3_q, pix_q ; pix-3*stride
 
-movam0, [r4+r1]   ; p1
-movam1, [r4+2*r1] ; p0
-movam2, [r0]  ; q0
-movam3, [r0+r1]   ; q1
+movam0, [base3_q + stride_q]   ; p1
+movam1, [base3_q + 2*stride_q] ; p0
+movam2, [pix_q]  ; q0
+movam3, [pix_q + stride_q]   ; q1
 LOAD_MASK r2d, r3d
 
 punpcklbw m8, m8
@@ -303,24 +303,24 @@ cglobal deblock_v_luma_8, 5,5,10
 pandn   m9, m7
 pandm8, m9
 
-movdqa  m3, [r4] ; p2
+movdqa  m3, [base3_q] ; p2
 DIFF_GT2 m1, m3, m5, m6, m7 ; |p2-p0| > beta-1
 pandm6, m9
 psubb   m7, m8, m6
 pandm6, m8
-LUMA_Q1 m0, m3, [r4], [r4+r1], m6, m4
+LUMA_Q1 m0, m3, [base3_q], [base3_q + stride_q], m6, m4
 
-movdqa  m4, [r0+2*r1] ; q2
+movdqa  m4, [pix_q + 2*stride_q] ; q2
 DIFF_GT2 m2, m4, m5, m6, m3 ; |q2-q0| > beta-1
 pandm6, m9
 pandm8, m6
 psubb   m7, m6
-movam3, [r0+r1]
-LUMA_Q1 m3, m4, [r0+2*r1], [r0+r1], m8, m6
+movam3, [pix_q + stride_q]
+LUMA_Q1 m3, m4, [pix_q + 2*stride_q], [pix_q + stride_q], m8, m6
 
 DEBLOCK_P0_Q0
-mova[r4+2*r1], m1
-mova[r0], m2
+mova[base3_q + 2*stride_q], m1
+mova[pix_q], m2
 RET
 
 ;-
-- 
2.8.3

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

[FFmpeg-devel] [PATCH 4/4] avcodec/h264: sse2, avx h luma mbaff deblock/loop filter

[James Darnley]

x86-64 only

Yorkfield:
- sse2: ~2.17x (434 vs. 200 cycles)

Nehalem:
- sse2: ~2.94x (409 vs. 139 cycles)

Skylake:
- sse2: ~3.10x (370 vs. 119 cycles)
- avx:  ~3.29x (370 vs. 112 cycles)
---
 libavcodec/x86/h264_deblock.asm | 89 +
 libavcodec/x86/h264dsp_init.c   | 10 +
 libavutil/x86/x86util.asm   | 19 +
 3 files changed, 118 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 509a0db..190f38e 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -377,10 +377,99 @@ cglobal deblock_h_luma_8, 5,9,0,0x60+16*WIN64
 RET
 %endmacro
 
+%macro DEBLOCK_H_LUMA_MBAFF 0
+
+cglobal deblock_h_luma_mbaff_8, 5, 9, 10, 8*16, pix_, stride_, alpha_, beta_, 
tc0_, base3_, stride3_
+movsxd stride_q,   stride_d
+decalpha_d
+decbeta_d
+movbase3_q,pix_q
+leastride3_q, [3*stride_q]
+addbase3_q,stride3_q
+
+movq m0, [pix_q - 4]
+movq m1, [pix_q + stride_q - 4]
+movq m2, [pix_q + 2*stride_q - 4]
+movq m3, [base3_q - 4]
+movq m4, [base3_q + stride_q - 4]
+movq m5, [base3_q + 2*stride_q - 4]
+movq m6, [base3_q + stride3_q - 4]
+movq m7, [base3_q + 4*stride_q - 4]
+
+TRANSPOSE_8X8B
+
+%assign i 0
+%rep 8
+movq [rsp + 16*i], m %+ i
+%assign i i+1
+%endrep
+
+; p2 = m1 [rsp + 16]
+; p1 = m2 [rsp + 32]
+; p0 = m3 [rsp + 48]
+; q0 = m4 [rsp + 64]
+; q1 = m5 [rsp + 80]
+; q2 = m6 [rsp + 96]
+
+SWAP 0, 2
+SWAP 1, 3
+SWAP 2, 4
+SWAP 3, 5
+
+LOAD_MASK alpha_d, beta_d
+movd m8, [tc0_q]
+punpcklbw m8, m8
+pcmpeqb m9, m9
+pcmpeqb m9, m8
+pandn   m9, m7
+pandm8, m9
+
+movdqa  m3, [rsp + 16] ; p2
+DIFF_GT2 m1, m3, m5, m6, m7 ; |p2-p0| > beta-1
+pandm6, m9
+psubb   m7, m8, m6
+pandm6, m8
+LUMA_Q1 m0, m3, [rsp + 16], [rsp + 32], m6, m4
+
+movdqa  m4, [rsp + 96] ; q2
+DIFF_GT2 m2, m4, m5, m6, m3 ; |q2-q0| > beta-1
+pandm6, m9
+pandm8, m6
+psubb   m7, m6
+movam3, [rsp + 80]
+LUMA_Q1 m3, m4, [rsp + 96], [rsp + 80], m8, m6
+
+DEBLOCK_P0_Q0
+SWAP 1, 3
+SWAP 2, 4
+movq m0, [rsp]
+movq m1, [rsp + 16]
+movq m2, [rsp + 32]
+movq m5, [rsp + 80]
+movq m6, [rsp + 96]
+movq m7, [rsp + 112]
+
+TRANSPOSE_8X8B
+movq [pix_q - 4], m0
+movq [pix_q + stride_q - 4], m1
+movq [pix_q + 2*stride_q - 4], m2
+movq [base3_q - 4], m3
+movq [base3_q + stride_q - 4], m4
+movq [base3_q + 2*stride_q - 4], m5
+movq [base3_q + stride3_q - 4], m6
+movq [base3_q + 4*stride_q - 4], m7
+
+RET
+
+%endmacro
+
 INIT_XMM sse2
+DEBLOCK_H_LUMA_MBAFF
 DEBLOCK_LUMA
+
 %if HAVE_AVX_EXTERNAL
 INIT_XMM avx
+DEBLOCK_H_LUMA_MBAFF
 DEBLOCK_LUMA
 %endif
 
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 7b3d17f..10f1940 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -137,6 +137,9 @@ LF_IFUNC(h, chroma422_intra, depth, avx)\
 LF_FUNC(v,  chroma,  depth, avx)\
 LF_IFUNC(v, chroma_intra,depth, avx)
 
+LF_FUNC(h, luma_mbaff, 8, sse2)
+LF_FUNC(h, luma_mbaff, 8, avx)
+
 LF_FUNCS(uint8_t,   8)
 LF_FUNCS(uint16_t, 10)
 
@@ -297,6 +300,10 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_h_loop_filter_luma   = ff_deblock_h_luma_8_sse2;
 c->h264_v_loop_filter_luma_intra = ff_deblock_v_luma_intra_8_sse2;
 c->h264_h_loop_filter_luma_intra = ff_deblock_h_luma_intra_8_sse2;
+
+#if ARCH_X86_64
+c->h264_h_loop_filter_luma_mbaff = ff_deblock_h_luma_mbaff_8_sse2;
+#endif
 }
 if (EXTERNAL_SSSE3(cpu_flags)) {
 c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_ssse3;
@@ -307,6 +314,9 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_h_loop_filter_luma   = ff_deblock_h_luma_8_avx;
 c->h264_v_loop_filter_luma_intra = ff_deblock_v_luma_intra_8_avx;
 c->h264_h_loop_filter_luma_intra = ff_deblock_h_luma_intra_8_avx;
+#if ARCH_X86_64
+c->h264_h_loop_filter_luma_mbaff = ff_deblock_h_luma_mbaff_8_avx;
+#endif
 }
 } else if (bit_depth == 10) {
 if (EXTERNAL_MMXEXT(cpu_flags)) {
diff --git a/libavutil/x86/x86util.asm b/libavutil/x86/x86util.asm
index 1408f0a..a562809 100644
--- a/libavutil/x86/x86util.asm
+++ b/libavutil/x86/x86util.asm
@@ -265,6 +265,25 @@
 SWAP   %12, %15
 %endmacro
 
+%macro TRANSPOSE_8X8B 8
+%if mmsize == 8
+%error "This macro does not support mmsize == 8"
+%endif
+punpcklbw m%1, m%2
+punpcklbw m%3, m%4
+punpcklbw m%5, m%6
+punpcklbw m%7, m%8
+TRANSPOSE4x4W %1, %3, %5, %7, %2
+MOVHL m%2, m%1
+MOVHL m%4, m%3
+MOVHL m%6, m%5
+MOVHL m%8, m%7
+%endmacro
+
+%macro 

Re: [FFmpeg-devel] [PATCH v2 0/5] A native Opus encoder

[Moritz Barsnick]

On Tue, Feb 14, 2017 at 06:37:16 +, Rostislav Pehlivanov wrote:
> Applied!
> Thanks for all the people who commented on it

This deserves a Changelog entry. (I missed that during the review
process.)

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

Re: [FFmpeg-devel] [PATCH] lavc/vda_h264_dec.c Fix NULL pointer dereference

[Michael Niedermayer]

On Wed, Feb 15, 2017 at 10:05:56AM -0700, Pavel Koshevoy wrote:
> On Thu, Feb 9, 2017 at 8:20 PM,   wrote:
> > From: Pavel Koshevoy 
> >
> > ps.sps_list entries may be NULL, so check before dereferencing
> > ---
> >  libavcodec/vda_h264_dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
> > index 92839e2..972bd6b 100644
> > --- a/libavcodec/vda_h264_dec.c
> > +++ b/libavcodec/vda_h264_dec.c
> > @@ -226,7 +226,7 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
> >  ctx->h264_initialized = 1;
> >
> >  for (i = 0; i < MAX_SPS_COUNT; i++) {
> > -const SPS *sps = (const SPS*)ctx->h264ctx.ps.sps_list[i]->data;
> > +const SPS *sps = ctx->h264ctx.ps.sps_list[i] ? (const 
> > SPS*)ctx->h264ctx.ps.sps_list[i]->data : NULL;
> >  if (sps && (sps->bit_depth_luma != 8 ||
> >  sps->chroma_format_idc == 2 ||
> >  sps->chroma_format_idc == 3)) {
> > --
> > 2.6.6
> >
> 
> 
> Ping.  This is a fix for a segfault I've actually run into.

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing

[Paul B Mahol]

On 2/15/17, Paul B Mahol  wrote:
> Fixes #5442.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mpl2dec.c | 8 
>  1 file changed, 8 insertions(+)
>

Will apply this shortly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel