Re: [FFmpeg-devel] order T-shirts

[Lou Logan]

On Sat, Oct 28, 2017, at 03:41 AM, Thilo Borgmann wrote:
> Both designs come for 12€ each! Lou's design doesn't have a printing on
> the neck. I'd choosen the green for our logo by their color chart - it
> looks good color-wise to me.

Looks good to me too. Thanks for all of your work on this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc/avrndec: remove AV_CODEC_CAP_DR1, as it's broken

[James Almer]

On 10/13/2017 1:59 PM, wm4 wrote:
> In the is_mjpeg case, the user's get_buffer2 callback is not called,
> thus completely breaking the API.
> ---
>  libavcodec/avrndec.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/avrndec.c b/libavcodec/avrndec.c
> index c37f99661b..104ff2d904 100644
> --- a/libavcodec/avrndec.c
> +++ b/libavcodec/avrndec.c
> @@ -168,7 +168,6 @@ AVCodec ff_avrn_decoder = {
>  .init   = init,
>  .close  = end,
>  .decode = decode_frame,
> -.capabilities   = AV_CODEC_CAP_DR1,
>  .max_lowres = 3,
>  .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
>  };

Applied this since it's not part of the currently-blocked stuff.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] decode: avoid leaks on failure in ff_get_buffer()

[James Almer]

On 10/13/2017 1:59 PM, wm4 wrote:
> From: Anton Khirnov 
> 
> If the get_buffer() call fails, the frame might have some side data
> already set. Make sure it gets freed.
> 
> CC: libav-sta...@libav.org
> 
> Merges Libav commit de77671438c24ffea93398c8dc885d4dd04477de.
> ---
>  libavcodec/decode.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 1337ffb527..437b848248 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1658,6 +1658,9 @@ end:
>  frame->height = avctx->height;
>  }
>  
> +if (ret < 0)
> +av_frame_unref(frame);
> +
>  return ret;
>  }

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

Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: use calculated dts offset when seeking in streams

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 12:11:39PM +0100, Peter Große wrote:
> From: Jonas Licht 
> 
> Subtract the calculated dts offset from the requested timestamp before
> seeking. This fixes an error "Error while filtering: Operation not
> permitted" observed with a short file which contains only one key frame
> and starts with negative timestamps.
> 
> Then, av_index_search_timestamp() returns a valid negative timestamp,
> but mov_seek_stream bails out with AVERROR_INVALIDDATA.
> 
> Fixes ticket #6139.
> 
> Signed-off-by: Jonas Licht 
> Signed-off-by: Peter Große 
> ---
> 
> Compared to the other seek results in this test, the values are not
> that far off.
> 
>  libavformat/mov.c|  6 --
>  tests/ref/seek/extra-mp4 | 16 
>  2 files changed, 12 insertions(+), 10 deletions(-)

will apply
thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH] movenc: add m4b to ipod format extensions

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 11:35:57AM +0100, Lukas Stabe wrote:
> m4b is commonly used as extension for m4a audiobook files.
> The format is exactly the same. The only thing that differs
> is the extension.
> ---
>  libavformat/movenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thanks

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

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] checkasm/llviddsp : add tests for other func of the dsp

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 06:07:09PM +0100, Martin Vignali wrote:
> Hello,
> 
> in attach patch to add a checkasm test for the uncover func of the dsp
> 
> add_median_pred
> 
> add_left_pred
> for this one i add two tests : one with acc = 0 (used in several decoders)
> and one with random acc
> 
> add_left_pred16
> 
> 
> Martin

>  llviddsp.c |  116 
> -
>  1 file changed, 108 insertions(+), 8 deletions(-)
> 928380cd1fe1a82e269dde4ef3dda20d2f12ae3f  
> 0002-checkasm-llviddsp-add-test-for-other-dsp-func.patch
> From f2ca22c720e75f8de9fe7d83a28dfea8431f2f97 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sun, 29 Oct 2017 18:01:30 +0100
> Subject: [PATCH 2/2] checkasm/llviddsp : add test for other dsp func
> 
> add_median_pred
> add_left_pred : add two func one with acc 0, and one with random acc
> add_left_pred16

tested on mingw32/64 linux32/64 x86, arm qemu linux

should be ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: October 29, 2017 5:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> On 29/10/17 20:48, Mironov, Mikhail wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Mark Thompson
> >> Sent: October 29, 2017 3:36 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> >> encoding for AMD GPUs based on AMF SDK
> >>
> >> On 29/10/17 18:39, Mironov, Mikhail wrote:
> 
> > +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> 
>  D3D11 surfaces need not be NV12.  The actual format is in
>  AVHWFramesContext.sw_format - if you only support 8-bit then
>  something nasty probably happens if you give it P010 surfaces.
> 
> >>>
> >>> Agreed, but how should I define D3D11 NV12 as input format if I only
> >>> have
> >> AV_PIX_FMT_D3D11?
> >>
> >> Check sw_format afterwards.
> >>
> >
> > sw_format is part of AVHWFramesContext in hwcodec.h But how should I
> > define pix_fmt array in AVCodec? For example, In nvenc.c is done via
> > AV_PIX_FMT_CUDA. Is it wrong?
> 
> NVENC checks sw_format at init time - see
>  16de39cfefa41432105aed91f0d4e93a154;hb=HEAD#l1408>.  I think you want
> to do the same thing.
> 
> (I agree this result isn't ideal with just the pix_fmt array, but there isn't
> currently a way to check sw_format as well from the outside.  Checking it at
> init time and failing if it isn't usable is the best we can do.)
> 

Sure, will add checking at initialization.

> > +
> > +// try to reuse existing DX device
> > +
> > +if (avctx->hw_frames_ctx) {
> > +AVHWFramesContext *device_ctx =
> > + (AVHWFramesContext*)avctx-
> > hw_frames_ctx->data;
> > +if (device_ctx->device_ctx->type ==
> >> AV_HWDEVICE_TYPE_D3D11VA){
> > +if (device_ctx->device_ctx->hwctx) {
> > +AVD3D11VADeviceContext *device_d3d11 =
>  (AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
> > +res = ctx->context->pVtbl->InitDX11(ctx->context,
> > + device_d3d11-
> > device, AMF_DX11_1);
> > +if (res == AMF_OK) {
> > +ctx->hw_frames_ctx = av_buffer_ref(avctx-
> >hw_frames_ctx);
> > +} else {
> > +av_log(avctx, AV_LOG_INFO, "amf_shared:
> > + avctx-
> > hw_frames_ctx has non-AMD device, switching to default");
> 
>  I'm not sure this is going to act sensibly - if the user has D3D11
>  frames input on another device, does it work?
> 
> >>>
> >>> If device is not AMD's the code is trying to create another device
> >>> - the
> >> compatible one .
> >>> In these cases the submission will be via system memory.
> >>
> >> And that works with D3D11 frames as hw_frames_ctx on another device?
> >
> > Why not? AMF will be initialized with a different device, in
> > submission code it is detected, surface with system (host) memory is
> > allocated, data will be copied using av_image_copy() and host memory will
> be submitted to AMF.
> 
> It won't be copied externally if it's already in a D3D11 surface for the other
> device.  At the moment it looks like it silently encodes an empty frame
> because the conditions in ff_amf_encode_frame() make it call
> amf_copy_surface(), but av_image_copy() doesn't support copying from
> hardware surfaces and has no way to indicate that failure.
> 
> I think the easiest way to solve this is to fail at init time if the given
> hw_frames_ctx is on an unusable device.  The hw_device_ctx case matters
> less, because the user input is not going to be in D3D11 frames in that case.

I though that in multi-GPU situation it is still good to support encoding. 
I could force HW frame to be copied into system memory and consume it in 
encoder:
 transfer_data_to(). Should it be better then fail at initialization?

> 
> > +} else {
> > +surface->pVtbl->Release(surface);
> > +surface = NULL;
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
>  AVERROR_UNKNOWN, "SubmitInput() failed with error %d", res);
> > +submitted = 1;
> > +}
> > +}
> > +// poll results
> > +if (!data) {
> > +res = ctx->encoder->pVtbl->QueryOutput(ctx->encoder,
> );
> > +if (data) {
> > +AMFBuffer* buffer;
> > +AMFGuid guid = IID_AMFBuffer();
> > +data->pVtbl->QueryInterface(data, ,
> > + (void**)); //
>  query for buffer interface
> > +

[FFmpeg-devel] [PATCH v5 1/2 ] avformat/mpegts: opus muxing for mapping family 255

[pkv.stream]

Le 29/10/2017 à 4:44 PM, Michael Niedermayer a écrit :

On Sat, Oct 28, 2017 at 03:49:13AM +0200, pkv.stream wrote:


  mpegtsenc.c |   67 
+---
  1 file changed, 60 insertions(+), 7 deletions(-)
1423a193788547952e3c4cdcb424b4724b0f1157  
0001-libavf-mpegts-opus-muxing-for-mapping-family-255.patch
 From 105f20b8af8ce5376165ca30a81276dae2e61e40 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sat, 28 Oct 2017 02:48:08 +0200
Subject: [PATCH 1/2] libavf/mpegts: opus muxing for mapping family 255

Adds to mpegts muxer the capability  to mux libopus with mapping family
255, following the provisional spec for opus in mepg-ts
(https://people.xiph.org/~tterribe/opus/ETSI_TS_opus-v0.1.3-draft.doc).

Signed-off-by: pkviet 
---
  libavformat/mpegtsenc.c | 67 +++--
  1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fdfa544..a31663c 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -28,6 +28,7 @@
  #include "libavutil/opt.h"
  
  #include "libavcodec/internal.h"

+#include "libavcodec/put_bits.h"
  
  #include "avformat.h"

  #include "avio_internal.h"
@@ -291,6 +292,9 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  MpegTSWrite *ts = s->priv_data;
  uint8_t data[SECTION_LENGTH], *q, *desc_length_ptr, 
*program_info_length_ptr;
  int val, stream_type, i, err = 0;
+uint8_t channel_count, stream_count, coupled_stream_count, *buf;
+PutBitContext pbc;
+size_t buf_size;
  
  q = data;

  put16(, 0xe000 | service->pcr_pid);
@@ -421,8 +425,8 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  *q++ = 'D';
  }
  if (st->codecpar->codec_id==AV_CODEC_ID_OPUS) {
-/* 6 bytes registration descriptor, 4 bytes Opus audio 
descriptor */
-if (q - data > SECTION_LENGTH - 6 - 4) {
+/* 6 bytes registration descriptor, 6 bytes Opus audio 
descriptor */
+if (q - data > SECTION_LENGTH - 6 - 6) {
  err = 1;
  break;
  }
@@ -435,8 +439,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  *q++ = 's';
  
  *q++ = 0x7f; /* DVB extension descriptor */

-*q++ = 2;
-*q++ = 0x80;
+/* descriptor_length */
+if (st->codecpar->extradata[18] == 255) {
+/* dual mono */
+if (st->codecpar->channels == 2) {
+*q++ = 2;
+} else {
+/* channel_config_code 0x81 */
+*q++ = st->codecpar->channels + 6;
+}
+} else {
+*q++ = 2;
+}
+*q++ = 0x80; /* descriptor_tag_extension */
  
  if (st->codecpar->extradata && st->codecpar->extradata_size >= 19) {

  if (st->codecpar->extradata[18] == 0 && 
st->codecpar->channels <= 2) {
@@ -483,9 +498,47 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  *q++ = 0xff;
  }
  } else {
-/* Unsupported */
-av_log(s, AV_LOG_ERROR, "Unsupported Opus channel mapping for 
family %d", st->codecpar->extradata[18]);
-*q++ = 0xff;
+/* mapping family 255 , set channel_config_code to 
0x81 except for dual-mono */
+if (st->codecpar->extradata[18] == 255) {
+/* dual mono */
+if (st->codecpar->channels == 2 && 
st->codecpar->extradata[19] == 1) {
+*q++ = 0x00;
+} else if (st->codecpar->channels == 2 && 
st->codecpar->extradata[19] == 2) {
+*q++ = 0x80;
+} else {
+/* application defined channel configuration */
+*q++ = 0x81;
+*q++ = st->codecpar->channels;
+*q++ = st->codecpar->extradata[18];
+channel_count = st->codecpar->channels;
+stream_count = st->codecpar->extradata[19];
+coupled_stream_count = 
st->codecpar->extradata[20];
+buf = av_mallocz_array( st->codecpar->channels 
+ 2 , sizeof(uint8_t));

Hello Michael
thanks again for your reviews.


+if (!buf) {
+av_freep(buf);

that looks wrong



right; fixed.

Re: [FFmpeg-devel] [PATCH]fate: Add bitexact and idct simple to the mov-invalid-edst test

[Carl Eugen Hoyos]

2017-10-29 22:48 GMT+01:00 Sasi Inguva :
> looks good to me. Thanks for the fix.

Patch applied.

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

[FFmpeg-devel] [PATCH v5 2/2 ] avformat/mpegts: opus demuxing for mapping family 255

[pkv.stream]

minor change, adding a test for number of channels for mapping_family 1 
when channel_config_code is > 0x82

Passes fate + patcheck.
Regards
pkv
From 2e0504728b81e0f35ba856c24cff14fa70680d8b Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sun, 29 Oct 2017 22:57:25 +0100
Subject: [PATCH 2/2] libavf/mpegts: opus demuxing for mapping family 255

Adds to mpegts muxer the capability  to demux libopus with mapping
family 255, following the provisional spec for opus in mepg-ts
(https://people.xiph.org/~tterribe/opus/ETSI_TS_opus-v0.1.3-draft.doc).

Signed-off-by: pkviet 
---
 libavformat/mpegts.c | 84 +++-
 1 file changed, 70 insertions(+), 14 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 53cbcfb..3aa06f0 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,7 @@
 #include "avio_internal.h"
 #include "mpeg.h"
 #include "isom.h"
+#include "math.h"
 
 /* maximum size in which we look for synchronization if
  * synchronization is lost */
@@ -1633,7 +1634,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,13 +1645,25 @@ 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,
   MpegTSContext *ts)
 {
 const uint8_t *desc_end;
-int desc_len, desc_tag, desc_es_id, ext_desc_tag, channels, 
channel_config_code;
+int desc_len, desc_tag, desc_es_id, ext_desc_tag, channels, 
channel_config_code, channel_count, mapping_family, stream_count, 
coupled_stream_count;
+GetBitContext gb;
 char language[252];
 int i;
 
@@ -1660,6 +1673,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 desc_len = get8(pp, desc_list_end);
 if (desc_len < 0)
 return AVERROR_INVALIDDATA;
+
 desc_end = *pp + desc_len;
 if (desc_end > desc_list_end)
 return AVERROR_INVALIDDATA;
@@ -1871,26 +1885,68 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 if (st->codecpar->codec_id == AV_CODEC_ID_OPUS &&
 ext_desc_tag == 0x80) { /* User defined (provisional Opus) */
 if (!st->codecpar->extradata) {
-st->codecpar->extradata = 
av_mallocz(sizeof(opus_default_extradata) +
- 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
-
-st->codecpar->extradata_size = sizeof(opus_default_extradata);
-memcpy(st->codecpar->extradata, opus_default_extradata, 
sizeof(opus_default_extradata));
-
 channel_config_code = get8(pp, desc_end);
 if (channel_config_code < 0)
 return AVERROR_INVALIDDATA;
+
+if (channel_config_code != 0x81) {
+st->codecpar->extradata = 
av_mallocz(sizeof(opus_default_extradata) +
+AV_INPUT_BUFFER_PADDING_SIZE);
+if (!st->codecpar->extradata)
+return AVERROR(ENOMEM);
+st->codecpar->extradata_size = 
sizeof(opus_default_extradata);
+memcpy(st->codecpar->extradata, opus_default_extradata, 
sizeof(opus_default_extradata));
+}
+
 if (channel_config_code <= 0x8) {
 st->codecpar->extradata[9]  = channels = 
channel_config_code ? channel_config_code : 2;
 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);
-} else {
-avpriv_request_sample(fc, "Opus in MPEG-TS - 
channel_config_code > 0x8");
-}
+memcpy(>codecpar->extradata[21], 
opus_channel_map_a[channels - 1], channels);
+} else if (channel_config_code == 0x81) {
+channel_count = get8(pp, desc_end);
+mapping_family = get8(pp, desc_end);
+

Re: [FFmpeg-devel] [PATCH]fate: Add bitexact and idct simple to the mov-invalid-edst test

[Sasi Inguva]

looks good to me. Thanks for the fix.

On Sun, Oct 29, 2017 at 2:11 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-29 22:03 GMT+01:00 Carl Eugen Hoyos :
> > Hi!
> >
> > Attached patch fixes a fate test here on a ppc system.
>
> The following is sufficient: -flags +bitexact
> The idct option is not necessary.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 29/10/17 20:48, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: October 29, 2017 3:36 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
>> encoding for AMD GPUs based on AMF SDK
>>
>> On 29/10/17 18:39, Mironov, Mikhail wrote:

> +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },

 D3D11 surfaces need not be NV12.  The actual format is in
 AVHWFramesContext.sw_format - if you only support 8-bit then
 something nasty probably happens if you give it P010 surfaces.

>>>
>>> Agreed, but how should I define D3D11 NV12 as input format if I only have
>> AV_PIX_FMT_D3D11?
>>
>> Check sw_format afterwards.
>>
> 
> sw_format is part of AVHWFramesContext in hwcodec.h 
> But how should I define pix_fmt array in AVCodec? For example, In nvenc.c 
> is done via AV_PIX_FMT_CUDA. Is it wrong?

NVENC checks sw_format at init time - see 
.
  I think you want to do the same thing.

(I agree this result isn't ideal with just the pix_fmt array, but there isn't 
currently a way to check sw_format as well from the outside.  Checking it at 
init time and failing if it isn't usable is the best we can do.)

> +
> +// try to reuse existing DX device
> +
> +if (avctx->hw_frames_ctx) {
> +AVHWFramesContext *device_ctx = (AVHWFramesContext*)avctx-
> hw_frames_ctx->data;
> +if (device_ctx->device_ctx->type ==
>> AV_HWDEVICE_TYPE_D3D11VA){
> +if (device_ctx->device_ctx->hwctx) {
> +AVD3D11VADeviceContext *device_d3d11 =
 (AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
> +res = ctx->context->pVtbl->InitDX11(ctx->context,
> + device_d3d11-
> device, AMF_DX11_1);
> +if (res == AMF_OK) {
> +ctx->hw_frames_ctx = 
> av_buffer_ref(avctx->hw_frames_ctx);
> +} else {
> +av_log(avctx, AV_LOG_INFO, "amf_shared: avctx-
> hw_frames_ctx has non-AMD device, switching to default");

 I'm not sure this is going to act sensibly - if the user has D3D11
 frames input on another device, does it work?

>>>
>>> If device is not AMD's the code is trying to create another device  - the
>> compatible one .
>>> In these cases the submission will be via system memory.
>>
>> And that works with D3D11 frames as hw_frames_ctx on another device?
> 
> Why not? AMF will be initialized with a different device, 
> in submission code it is detected, surface with system (host) memory is 
> allocated,  
> data will be copied using av_image_copy() and host memory will be submitted 
> to AMF.

It won't be copied externally if it's already in a D3D11 surface for the other 
device.  At the moment it looks like it silently encodes an empty frame because 
the conditions in ff_amf_encode_frame() make it call amf_copy_surface(), but 
av_image_copy() doesn't support copying from hardware surfaces and has no way 
to indicate that failure.

I think the easiest way to solve this is to fail at init time if the given 
hw_frames_ctx is on an unusable device.  The hw_device_ctx case matters less, 
because the user input is not going to be in D3D11 frames in that case.

> +} else {
> +surface->pVtbl->Release(surface);
> +surface = NULL;
> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
 AVERROR_UNKNOWN, "SubmitInput() failed with error %d", res);
> +submitted = 1;
> +}
> +}
> +// poll results
> +if (!data) {
> +res = ctx->encoder->pVtbl->QueryOutput(ctx->encoder, );
> +if (data) {
> +AMFBuffer* buffer;
> +AMFGuid guid = IID_AMFBuffer();
> +data->pVtbl->QueryInterface(data, ,
> + (void**)); //
 query for buffer interface
> +ret = amf_copy_buffer(avctx, pkt, buffer);
> +if (!ret)
> +*got_packet = 1;
> +buffer->pVtbl->Release(buffer);
> +data->pVtbl->Release(data);
> +if (ctx->eof) {
> +submitted = true; // we are in the drain state - no
>> submissions
> +}
> +} else if (res == AMF_EOF) {
> +submitted = true; // drain complete
> +} else {
> +if (!submitted) {
> +av_usleep(1000); // wait and poll again
> +}
> +}
> +}
> +}

 I suspect this setup is not actually going to follow the 

Re: [FFmpeg-devel] [PATCH] avfilter/zscale: add explanation for error 3074

[Dxfhgwet]

> Original Message 
>Subject: Re: [FFmpeg-devel] [PATCH] avfilter/zscale: add explanation for error 
>3074
>Local Time: October 29, 2017 6:50 AM
>UTC Time: October 29, 2017 1:50 PM
>From: barsn...@gmx.net
>To: FFmpeg development discussions and patches 
>
>On Sat, Oct 28, 2017 at 20:54:02 -0400, Dxfhgwet wrote:
> - av_log(ctx, AV_LOG_ERROR, "code %d: %s\n", err_code, err_msg);
> - if (err_code == ZIMG_ERROR_NO_COLORSPACE_CONVERSION) {
> -av_log(ctx, AV_LOG_ERROR, "code %d: %s. Try specifying 
> matrix/transfer/primaries.\n";
>
> - } else {
> -av_log(ctx, AV_LOG_ERROR, "code %d: %s\n", err_code, err_msg);
>
> - }
>
> I didn't try your patch, but I'm extremely sure it doesn't compile. You
> forgot a lot of stuff in the first av_log() call line.
>
> Please, when creating a patch:
> - branch locally from master
> - do your edits
> - try to compile
> - fix by editing again
> - compile
> - test your change
> - repeat if necessary
> - commit locally
> - create a patch from this commit with git format-patch
> - submit the patch.
>
> And please fix your email address when committing.
>
> Moritz
>
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Sent with ProtonMail Secure Email.

0001-avfilter-zscale-add-explanation-for-error-3074.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]fate: Add bitexact and idct simple to the mov-invalid-edst test

[Carl Eugen Hoyos]

2017-10-29 22:03 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes a fate test here on a ppc system.

The following is sufficient: -flags +bitexact
The idct option is not necessary.

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: October 29, 2017 5:01 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> 2017-10-29 21:48 GMT+01:00 Mironov, Mikhail
> :
> 
> > VAAPI on Linux is available in open source driver. AMF version will be
> > implemented via Vulkan and will follow Vulkan implementation  in the
> driver and in open source policy.
> 
> Does that mean that at least in theory, the driver may also work on big-
> endian?
> 
> If yes, you have to be extra-careful about how to define the RGB colour-
> spaces (and how to map them to pix_fmts).
> 
OK, will keep it in mind.

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

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

[FFmpeg-devel] [PATCH]fate: Add bitexact and idct simple to the mov-invalid-edst test

[Carl Eugen Hoyos]

Hi!

Attached patch fixes a fate test here on a ppc system.

Please comment, Carl Eugen
From 35a19a80efe319bc99c2efb8a8b79c5e865ab47f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 29 Oct 2017 22:01:40 +0100
Subject: [PATCH] fate: Add bitexact and idct simple to the invalid-elst test.

Fixes fate-mov-invalid-elst-entry-count on a ppc system.
---
 tests/fate/mov.mak  |2 +-
 tests/ref/fate/mov-invalid-elst-entry-count |   86 +--
 2 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 604703e..ccfa02e 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -45,7 +45,7 @@ fate-mov-2elist-elist1-ends-bframe: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/mov-
 fate-mov-440hz-10ms: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/440hz-10ms.m4a
 
 # Makes sure that we handle invalid edit list entry count correctly.
-fate-mov-invalid-elst-entry-count: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/invalid_elst_entry_count.mov
+fate-mov-invalid-elst-entry-count: CMD = framemd5 -flags +bitexact -idct simple -i $(TARGET_SAMPLES)/mov/invalid_elst_entry_count.mov
 
 fate-mov-aac-2048-priming: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_packets -print_format compact $(TARGET_SAMPLES)/mov/aac-2048-priming.mov
 
diff --git a/tests/ref/fate/mov-invalid-elst-entry-count b/tests/ref/fate/mov-invalid-elst-entry-count
index 13b5758..ac1e02e 100644
--- a/tests/ref/fate/mov-invalid-elst-entry-count
+++ b/tests/ref/fate/mov-invalid-elst-entry-count
@@ -8,50 +8,50 @@
 #sar 0: 1/1
 #stream#, dts,pts, duration, size, hash
 0,  0,  0,1,   460800, 549730883a0b56e6accaf021903daecf
-0,  1,  1,1,   460800, 783389b4342d4be925fc5244791e760a
-0,  2,  2,1,   460800, 8384af6426d94a2077930c93013e09ad
-0,  3,  3,1,   460800, 9380a1d9ecacf5b3105383c1c8083188
-0,  4,  4,1,   460800, eb28174acfceb868b9058757bed049c5
-0,  5,  5,1,   460800, 9732bd4a58884dbf2be48d819433130f
+0,  1,  1,1,   460800, d5fc844d512a1decb0814b8692914d60
+0,  2,  2,1,   460800, 69753185911f99aa38bd9d9ee0ff24f7
+0,  3,  3,1,   460800, 2a985178c8b24e97708c6d33142f18a9
+0,  4,  4,1,   460800, a23818e43bdf4ee77291e0f74051d0bf
+0,  5,  5,1,   460800, f2c927b11350b9822065bec5f06b65d9
 0,  6,  6,1,   460800, 0c553fb530cf042eb84f5b13817a96a6
-0,  7,  7,1,   460800, 621f02aded5e35fa1f373afd3ed283bd
-0,  8,  8,1,   460800, c76167c6bda91f657708c88252ea315d
-0,  9,  9,1,   460800, 872df2d8c522e2440ddd04bca7dce497
-0, 10, 10,1,   460800, 6ee9154e48c5132ad4ba122b255bd2bb
-0, 11, 11,1,   460800, 362e61629795702ebe9183ce3786d7f2
+0,  7,  7,1,   460800, a2be429b570ce30a7471b901f2ea5bcc
+0,  8,  8,1,   460800, b4f4a3b1988404b35c57688755beb8b9
+0,  9,  9,1,   460800, 2778b931d5e1570e1b809a87b1c45491
+0, 10, 10,1,   460800, 4eb341ebf32006d8bce13f1d132d84b2
+0, 11, 11,1,   460800, c39a34287300ee52547752198afc
 0, 12, 12,1,   460800, f3ec59e6fc4e3c2e75f42bef34ca73b5
-0, 13, 13,1,   460800, 68d9caea8697736dd716cba43b614919
-0, 14, 14,1,   460800, 4a4efb0201a64236db4330725758c139
-0, 15, 15,1,   460800, f32f8997dcdd87ad910dea886a0de17d
-0, 16, 16,1,   460800, 51a8549d7b4aaacaf6050bc07a82b440
-0, 17, 17,1,   460800, 5145aa05bbb0c3faab40fc8fa233af1d
-0, 18, 18,1,   460800, bbfcbe3c9600b2a0f413057d7959e9e7
-0, 19, 19,1,   460800, 02cfd4a350fa274e12fce8352001bf21
-0, 20, 20,1,   460800, 20dd372da9e656add433f31e3e9c1fb8
-0, 21, 21,1,   460800, 3b885593f8b42676ce40c329a63f62bf
-0, 22, 22,1,   460800, c38b453b56c3ea14f7d8691d83752486
-0, 23, 23,1,   460800, 79643132988dabc9dc1ba3af0aeaebc5
+0, 13, 13,1,   460800, 3f0e6116a94fefe890b79d1e94c156c6
+0, 14, 14,1,   460800, 0a8a597c0806818112bf8351f53d350a
+0, 15, 15,1,   460800, ab5c10023712ea21d595f5f856f53c66
+0, 16, 16,1,   460800, d4e218051ef32e68e3df58c8c3d6a1ab
+0, 17, 17,1,   460800, 24082fa9a277123a65398a36cb1b06af
+0, 18, 18,1,   460800, 4c6da38c984496fb514d5e4d8ebb13f8
+0, 19, 19,1,   460800, 5354435f662e80a47e1460d3ba020133
+0, 20,   

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-10-29 21:48 GMT+01:00 Mironov, Mikhail :

> VAAPI on Linux is available in open source driver. AMF version will be 
> implemented via
> Vulkan and will follow Vulkan implementation  in the driver and in open 
> source policy.

Does that mean that at least in theory, the driver may also work on big-endian?

If yes, you have to be extra-careful about how to define the RGB colour-spaces
(and how to map them to pix_fmts).

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: October 29, 2017 3:49 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> On 29/10/17 14:54, Mironov, Mikhail wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Carl Eugen Hoyos
> >> Sent: October 28, 2017 3:19 PM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> >> encoding for AMD GPUs based on AMF SDK
> >>
> >> 2017-10-27 20:09 GMT+02:00 mmironov :
> >>> +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> >>> +AV_PIX_FMT_NV12,
> >>
> >>> +AV_PIX_FMT_BGRA,
> >>> +AV_PIX_FMT_ARGB,
> >>> +AV_PIX_FMT_RGBA,
> >>
> >> This is wrong, your encoders do not convert transparency information,
> >> there are 32 rgb formats without alpha channel.
> >>
> >>> +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
> >>> +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> >>
> >> Just curious: Can you explain this in simple words?
> >>
> >> I will try not to comment on the headers you sent, Carl Eugen
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > Sure: the native format for the encoder is NV12. It can work via D3D11 and
> accept DXGI_FORMAT_NV12 texture or via D3D9  accepting
> (D3DFORMAT)MAKEFOURCC('N', 'V', '1', '2') surface. AMF surfaces are
> wrappers around these objects and converters from system memory. In
> addition, the encoder has built-in shader-based color converter. It can accept
> BGRA and RGBA formats and convert them into NV12 dropping alpha
> channel. This is why I added these entries. Granted, the conversion lacks
> parameters and to support more options AMF has a separate color space
> component, also shader-based. Once encoder is integrated I planned to ask
> FFmpeg team opinion if it is needed or not.
> > I made the FFmpeg encoder accepting DX objects from other FFmpeg
> components if available.
> 
> If you're going to do the colour conversion here then please pass the
> necessary colour information
> (AVFrame.color_primaries|color_trc|colorspace) so that non-BT.709 (I'm
> guessing...) has some chance of being correct.

Currently 709 or 601 is decided based on frame size. It is crude but works for 
folks 
who don’t want to deal with a separate AMF component. I am thinking of adding 
these 
parameters to the encoder in the driver and to AMF API. But so far it was low 
priority 
because of the separate component which has these parameters.

> 
> (Though I'd say in general it's preferable not to have the encoder do this,
> because it becomes confused with actual encoding of RGB.  A separate
> D3D11 shader implementation to do it as a filter would definitely be
> welcome...)

As I said, I would be glad to work on this or ask someone in my team to do it 
once the encoder is in place. 

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

Thanks, Mikhail

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: October 29, 2017 3:36 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> On 29/10/17 18:39, Mironov, Mikhail wrote:
> >>>  REGISTER_ENCODER(H263_V4L2M2M,  h263_v4l2m2m);
> >>>  REGISTER_ENCDEC (LIBOPENH264,   libopenh264);
> >>> +REGISTER_ENCODER(H264_AMF,  h264_amf);
> >>> + REGISTER_ENCODER(H264_AMF,  h264_amf_d3d11va);
> >>
> >> No tabs.  Why is the d3d11 version separate?  The encoder should be
> >> able to accept multiple pixfmts.
> >>
> >
> > It does accept multiple formants but there is a code that searches for
> > accelerator name in the encoder name and unless it is present disables
> > passing accelerator to encoder. See hw_device_setup_for_encode().
> 
> That code is a temporary hack, please don't assume it.  A setup something
> like  October/085223.html> is intended to replace it (not yet done for encode),
> which will not require that sort of nastiness.  (Feel free to comment on 
> that.)

OK, this would be way better. I also didn’t like the codec duplication. 
So for now I will remove it and mark the codec as HW when available.

> 
> I'm not sure how much you want an implicit device here anyway - you get a
> device from hw_frames_ctx for D3D11 input, and otherwise it doesn't
> matter?
> 
> >>> +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
> >>> +{ AV_PIX_FMT_BGRA,   AMF_SURFACE_BGRA },
> >>> +{ AV_PIX_FMT_ARGB,   AMF_SURFACE_ARGB },
> >>> +{ AV_PIX_FMT_RGBA,   AMF_SURFACE_RGBA },
> >>> +{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
> >>> +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
> >>> +{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },
> >>> +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YV12 },
> >>> +{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
> >>
> >> Do all of these formats actually work?
> >
> > This is just a translation table. Actual support is in
> > AVCodec::rix_fmts
> 
> You answered some of the actual question responding to Carl, I'll reply there.
> 
> >>
> >>> +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> >>
> >> D3D11 surfaces need not be NV12.  The actual format is in
> >> AVHWFramesContext.sw_format - if you only support 8-bit then
> >> something nasty probably happens if you give it P010 surfaces.
> >>
> >
> > Agreed, but how should I define D3D11 NV12 as input format if I only have
> AV_PIX_FMT_D3D11?
> 
> Check sw_format afterwards.
> 

sw_format is part of AVHWFramesContext in hwcodec.h 
But how should I define pix_fmt array in AVCodec? For example, In nvenc.c 
is done via AV_PIX_FMT_CUDA. Is it wrong?

> >>> +};
> >>> +
> >>> +static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum
> >> AVPixelFormat fmt)
> >>> +{
> >>> +for (int i = 0; i < amf_countof(format_map); i++) {
> >>> +if (format_map[i].av_format == fmt) {
> >>> +return format_map[i].amf_format;
> >>> +}
> >>> +}
> >>> +return AMF_SURFACE_UNKNOWN;
> >>> +}
> >>> +
> >>> +// virtual functions decalred
> >>
> >> What does this comment mean?
> >>
> >
> > These functions are virtual functions put in real virtual table.
> 
> IMO the comment is useless.  If you want to keep it, at least fix the typo.

I can remove it, no problem. Just wanted to explain.
 
> 
> >>> +
> >>> +version_fun(>version);
> >>> +init_fun(AMF_FULL_VERSION, >factory);
> >>> +ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
> >>> +ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
> >>
> >> Do all of these functions necessarily succeed?
> >>
> >
> > Yes.
> 
> Even in possible future API versions?  Why aren't they void, then?

Good question, I guess for consistency of in API. I will add error checking.

> 
> >>> +
> >>> +// try to reuse existing DX device
> >>> +
> >>> +if (avctx->hw_frames_ctx) {
> >>> +AVHWFramesContext *device_ctx = (AVHWFramesContext*)avctx-
> >>> hw_frames_ctx->data;
> >>> +if (device_ctx->device_ctx->type ==
> AV_HWDEVICE_TYPE_D3D11VA){
> >>> +if (device_ctx->device_ctx->hwctx) {
> >>> +AVD3D11VADeviceContext *device_d3d11 =
> >> (AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
> >>> +res = ctx->context->pVtbl->InitDX11(ctx->context,
> >>> + device_d3d11-
> >>> device, AMF_DX11_1);
> >>> +if (res == AMF_OK) {
> >>> +ctx->hw_frames_ctx = 
> >>> av_buffer_ref(avctx->hw_frames_ctx);
> >>> +} else {
> >>> +av_log(avctx, AV_LOG_INFO, "amf_shared: avctx-
> >>> hw_frames_ctx has non-AMD device, switching to default");
> >>
> >> I'm not sure this is going to act sensibly - if the user has D3D11
> >> frames input on another device, does it work?
> >>
> >
> > If device is 

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()

[Peter Große]

On Sun, 29 Oct 2017 21:33:10 +0100
Michael Niedermayer  wrote:

> seems this doesnt apply
> 

Yeah, it depends on the patch I started the thread with.

I can swap the order of the two patches if you want, so that the
style fix can go in first. But they will depend on each other either way, since
their contexts overlap.

Regards
Peter


pgpSF5H4zdVVN.pgp
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 03:09:13PM +0100, Peter Große wrote:
> On Sun, 29 Oct 2017 14:56:20 +0100
> Moritz Barsnick  wrote:
> 
> > On Sun, Oct 29, 2017 at 12:08:05 +0100, Peter Große wrote:
> > >  } else duration = 1;  
> > 
> > For style/readability, the statement should be on a new line, perhaps
> > even with brackets. (Not necessarily as part of this patch though.)
> 
> Sure.
> 
> Regards
> Peter

>  ffmpeg.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> ad25b12935744d7c3a6b169bb7585c89f4f70c4d  
> 0001-ffmpeg.c-fix-code-style-in-seek_to_start.patch
> From 14032f4185a0824b819b062068f5777a33057ece Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Peter=20Gro=C3=9Fe?= 
> Date: Sun, 29 Oct 2017 15:07:12 +0100
> Subject: [PATCH] ffmpeg.c: fix code style in seek_to_start
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> To: ffmpeg-devel@ffmpeg.org
> 
> Signed-off-by: Peter Große 
> ---
>  fftools/ffmpeg.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

seems this doesnt apply

Applying: ffmpeg.c: fix code style in seek_to_start
error: sha1 information is lacking or useless (fftools/ffmpeg.c).
error: could not build fake ancestor
Patch failed at 0001 ffmpeg.c: fix code style in seek_to_start
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH] swscale: Reduce verbosity of misalignment reporting

[Michael Niedermayer]

On Sun, Oct 22, 2017 at 11:47:55AM +0200, Henrik Gramner wrote:
> It's a bit overzealous to complain about misalignment with AV_LOG_WARNING,
> especially since memory bandwidth is much more likely to be the bottleneck
> compared to data alignment which the user may not even have control over.
> ---
>  libswscale/swscale.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/libswscale/swscale.c b/libswscale/swscale.c
> index 7f3e22355f..4eca79edc2 100644
> --- a/libswscale/swscale.c
> +++ b/libswscale/swscale.c
> @@ -307,26 +307,14 @@ static int swscale(SwsContext *c, const uint8_t *src[],
>  DEBUG_BUFFERS("vLumFilterSize: %d vChrFilterSize: %d\n",
>vLumFilterSize, vChrFilterSize);
>  
> -if (dstStride[0]&15 || dstStride[1]&15 ||
> -dstStride[2]&15 || dstStride[3]&15) {
> -static int warnedAlready = 0; // FIXME maybe move this into the 
> context
> -if (flags & SWS_PRINT_INFO && !warnedAlready) {
> -av_log(c, AV_LOG_WARNING,
> -   "Warning: dstStride is not aligned!\n"
> -   " ->cannot do aligned memory accesses anymore\n");
> -warnedAlready = 1;
> -}
> -}
> -
>  if (   (uintptr_t)dst[0]&15 || (uintptr_t)dst[1]&15 || 
> (uintptr_t)dst[2]&15
>  || (uintptr_t)src[0]&15 || (uintptr_t)src[1]&15 || 
> (uintptr_t)src[2]&15
>  || dstStride[0]&15 || dstStride[1]&15 || dstStride[2]&15 || 
> dstStride[3]&15
>  || srcStride[0]&15 || srcStride[1]&15 || srcStride[2]&15 || 
> srcStride[3]&15
>  ) {
> -static int warnedAlready=0;
> -int cpu_flags = av_get_cpu_flags();
> -if (HAVE_MMXEXT && (cpu_flags & AV_CPU_FLAG_SSE2) && !warnedAlready){
> -av_log(c, AV_LOG_WARNING, "Warning: data is not aligned! This 
> can lead to a speed loss\n");
> +static int warnedAlready=0; // FIXME maybe move this into the context
> +if (flags & SWS_PRINT_INFO && !warnedAlready) {
> +av_log(c, AV_LOG_VERBOSE, "Data is misaligned, this may reduce 
> performance.\n");
>  warnedAlready=1;
>  }
>  }
> -- 

This patch changes more than the log level as suggested by the
commit message.

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] fate/fits: add new test & gen few samples automatically

[Carl Eugen Hoyos]

2017-08-27 7:45 GMT+02:00 Paras Chadha :
> Signed-off-by: Paras Chadha 
> ---
> All other FITS patches need to be applied before this one.
>
>  tests/fate/demux.mak|  3 +-
>  tests/fate/fits.mak | 57 
> ++---
>  tests/ref/fate/fitsdec-bitpix-32|  6 
>  tests/ref/fate/fitsdec-bitpix-64|  6 
>  tests/ref/fate/fitsdec-blank_bitpix32   |  6 
>  tests/ref/fate/fitsdec-ext_data_min_max |  6 
>  6 files changed, 72 insertions(+), 12 deletions(-)
>  create mode 100644 tests/ref/fate/fitsdec-bitpix-32
>  create mode 100644 tests/ref/fate/fitsdec-bitpix-64
>  create mode 100644 tests/ref/fate/fitsdec-blank_bitpix32
>  create mode 100644 tests/ref/fate/fitsdec-ext_data_min_max
>
> diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak
> index 66e26ed..261b004 100644
> --- a/tests/fate/demux.mak
> +++ b/tests/fate/demux.mak
> @@ -37,7 +37,8 @@ FATE_SAMPLES_DEMUX-$(CONFIG_EA_DEMUXER) += 
> fate-d-eavp6-demux
>  fate-d-eavp6-demux: CMD = framecrc -i $(TARGET_SAMPLES)/ea-vp6/SmallRing.vp6 
> -map 0 -vcodec copy
>
>  FATE_SAMPLES_DEMUX-$(CONFIG_FITS_DEMUXER) += fate-fits-demux
> -fate-fits-demux: CMD = framecrc -i $(TARGET_SAMPLES)/fits/fits-multi.fits 
> -vcodec copy
> +fate-fits-demux: tests/data/fits-multi.fits
> +fate-fits-demux: CMD = framecrc -i $(TARGET_PATH)/tests/data/fits-multi.fits 
> -vcodec copy
>
>  FATE_SAMPLES_DEMUX-$(CONFIG_FLV_DEMUXER) += fate-flv-demux
>  fate-flv-demux: CMD = framecrc -i 
> $(TARGET_SAMPLES)/flv/Enigma_Principles_of_Lust-part.flv -codec copy
> diff --git a/tests/fate/fits.mak b/tests/fate/fits.mak
> index 8202870..983946d 100644
> --- a/tests/fate/fits.mak
> +++ b/tests/fate/fits.mak
> @@ -1,25 +1,60 @@
> -FATE_FITS += fate-fitsdec-multi
> -fate-fitsdec-multi: CMD = framecrc -i $(TARGET_SAMPLES)/fits/fits-multi.fits 
> -pix_fmt gbrap
> +tests/data/fits-multi.fits: TAG = GEN
> +tests/data/fits-multi.fits: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> +   $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
> +-i $(TARGET_SAMPLES)/gif/m4nb.gif \
> +-y $(TARGET_PATH)/$(@) 2>/dev/null
> +
> +#mapping of fits file formats to png filenames
> +map.tests/data/lena-gray.fits:= gray8
> +map.tests/data/lena-gray16.fits  := gray16
> +map.tests/data/lena-gbrp.fits:= rgb24
> +map.tests/data/lena-gbrp16.fits  := rgb48
> +map.tests/data/lena-gbrap16.fits := rgba64
> +
> +tests/data/lena%.fits: TAG = GEN
> +tests/data/lena%.fits: NAME = $(map.$(@))
> +tests/data/lena%.fits: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> +   $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
> +-i $(TARGET_SAMPLES)/png1/lena-$(map.$(@)).png \
> +-y $(TARGET_PATH)/$(@) 2>/dev/null

> +FATE_FITS_DEC-$(call DEMDEC, FITS, FITS) += fate-fitsdec-ext_data_min_max
> +fate-fitsdec-ext_data_min_max: CMD = framecrc -i 
> $(TARGET_SAMPLES)/fits/x0cj010ct_d0h.fit -pix_fmt gray16
> +
> +FATE_FITS_DEC-$(call DEMDEC, FITS, FITS) += fate-fitsdec-blank_bitpix32
> +fate-fitsdec-blank_bitpix32: CMD = framecrc -blank_value 65535 -i 
> $(TARGET_SAMPLES)/fits/file008.fits -pix_fmt gray16
> +
> +FATE_FITS_DEC-$(call DEMDEC, FITS, FITS) += fate-fitsdec-bitpix-32
> +fate-fitsdec-bitpix-32: CMD = framecrc -i 
> $(TARGET_SAMPLES)/fits/tst0005.fits -pix_fmt gray16
> +
> +FATE_FITS_DEC-$(call DEMDEC, FITS, FITS) += fate-fitsdec-bitpix-64
> +fate-fitsdec-bitpix-64: CMD = framecrc -i 
> $(TARGET_SAMPLES)/fits/tst0006.fits -pix_fmt gray16

I fixed those.

> +FATE_FITS_DEC-$(call DEMDEC, FITS, FITS) += fate-fitsdec-multi
> +fate-fitsdec-multi: tests/data/fits-multi.fits
> +fate-fitsdec-multi: CMD = framecrc -i 
> $(TARGET_PATH)/tests/data/fits-multi.fits -pix_fmt gbrap

>  fate-fitsdec%: PIXFMT = $(word 3, $(subst -, ,$(@)))
> -fate-fitsdec%: SRC = $(TARGET_SAMPLES)/fits/lena-$(PIXFMT).fits
> +fate-fitsdec%: SRC = $(TARGET_PATH)/tests/data/lena-$(PIXFMT).fits
>  fate-fitsdec%: CMD = framecrc -i $(SRC) -pix_fmt $(PIXFMT)

Not sure how to fix this great idea.
I would be glad if somebody would send a patch (or even better,
push), if not I may be doing something silly.

Note that the choice of source apparently wasn't ideal:
The gbrp16 test does not fail on big-endian, it works
for both endianesses, imo indicating that it is not a
good test.
gbrap16 fails.

>  FATE_FITS_DEC_PIXFMT = gray gray16 gbrp gbrp16 gbrap16
> -FATE_FITS += $(FATE_FITS_DEC_PIXFMT:%=fate-fitsdec-%)
> +$(FATE_FITS_DEC_PIXFMT:%=fate-fitsdec-%): fate-fitsdec-%: 
> tests/data/lena-%.fits
> +FATE_FITS_DEC-$(call DEMDEC, FITS, FITS) += 
> $(FATE_FITS_DEC_PIXFMT:%=fate-fitsdec-%)

Is there no big-endian fate instance left?

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 29/10/17 14:54, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: October 28, 2017 3:19 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
>> encoding for AMD GPUs based on AMF SDK
>>
>> 2017-10-27 20:09 GMT+02:00 mmironov :
>>> +const enum AVPixelFormat ff_amf_pix_fmts[] = {
>>> +AV_PIX_FMT_NV12,
>>
>>> +AV_PIX_FMT_BGRA,
>>> +AV_PIX_FMT_ARGB,
>>> +AV_PIX_FMT_RGBA,
>>
>> This is wrong, your encoders do not convert transparency information, there
>> are 32 rgb formats without alpha channel.
>>
>>> +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
>>> +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
>>
>> Just curious: Can you explain this in simple words?
>>
>> I will try not to comment on the headers you sent, Carl Eugen
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> Sure: the native format for the encoder is NV12. It can work via D3D11 and 
> accept DXGI_FORMAT_NV12 texture or via D3D9  accepting 
> (D3DFORMAT)MAKEFOURCC('N', 'V', '1', '2') surface. AMF surfaces are wrappers 
> around these objects and converters from system memory. In addition, the 
> encoder has built-in shader-based color converter. It can accept BGRA and 
> RGBA formats and convert them into NV12 dropping alpha channel. This is why I 
> added these entries. Granted, the conversion lacks parameters and to support 
> more options AMF has a separate color space component, also shader-based. 
> Once encoder is integrated I planned to ask FFmpeg team opinion if it is 
> needed or not. 
> I made the FFmpeg encoder accepting DX objects from other FFmpeg components 
> if available.

If you're going to do the colour conversion here then please pass the necessary 
colour information (AVFrame.color_primaries|color_trc|colorspace) so that 
non-BT.709 (I'm guessing...) has some chance of being correct.

(Though I'd say in general it's preferable not to have the encoder do this, 
because it becomes confused with actual encoding of RGB.  A separate D3D11 
shader implementation to do it as a filter would definitely be welcome...)

Thanks,

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 29/10/17 18:39, Mironov, Mikhail wrote:
>>>  REGISTER_ENCODER(H263_V4L2M2M,  h263_v4l2m2m);
>>>  REGISTER_ENCDEC (LIBOPENH264,   libopenh264);
>>> +REGISTER_ENCODER(H264_AMF,  h264_amf);
>>> +   REGISTER_ENCODER(H264_AMF,  h264_amf_d3d11va);
>>
>> No tabs.  Why is the d3d11 version separate?  The encoder should be able to
>> accept multiple pixfmts.
>>
> 
> It does accept multiple formants but there is a code that searches for 
> accelerator name in the encoder name and unless it is present disables 
> passing accelerator to encoder. See hw_device_setup_for_encode().

That code is a temporary hack, please don't assume it.  A setup something like 
 is 
intended to replace it (not yet done for encode), which will not require that 
sort of nastiness.  (Feel free to comment on that.)

I'm not sure how much you want an implicit device here anyway - you get a 
device from hw_frames_ctx for D3D11 input, and otherwise it doesn't matter?

>>> +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
>>> +{ AV_PIX_FMT_BGRA,   AMF_SURFACE_BGRA },
>>> +{ AV_PIX_FMT_ARGB,   AMF_SURFACE_ARGB },
>>> +{ AV_PIX_FMT_RGBA,   AMF_SURFACE_RGBA },
>>> +{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
>>> +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
>>> +{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },
>>> +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YV12 },
>>> +{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
>>
>> Do all of these formats actually work?
> 
> This is just a translation table. Actual support is in AVCodec::rix_fmts 

You answered some of the actual question responding to Carl, I'll reply there.

>>
>>> +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
>>
>> D3D11 surfaces need not be NV12.  The actual format is in
>> AVHWFramesContext.sw_format - if you only support 8-bit then something
>> nasty probably happens if you give it P010 surfaces.
>>
> 
> Agreed, but how should I define D3D11 NV12 as input format if I only have 
> AV_PIX_FMT_D3D11?

Check sw_format afterwards.

>>> +};
>>> +
>>> +static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum
>> AVPixelFormat fmt)
>>> +{
>>> +for (int i = 0; i < amf_countof(format_map); i++) {
>>> +if (format_map[i].av_format == fmt) {
>>> +return format_map[i].amf_format;
>>> +}
>>> +}
>>> +return AMF_SURFACE_UNKNOWN;
>>> +}
>>> +
>>> +// virtual functions decalred
>>
>> What does this comment mean?
>>
> 
> These functions are virtual functions put in real virtual table.  

IMO the comment is useless.  If you want to keep it, at least fix the typo.

>>> +
>>> +version_fun(>version);
>>> +init_fun(AMF_FULL_VERSION, >factory);
>>> +ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
>>> +ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
>>
>> Do all of these functions necessarily succeed?
>>
> 
> Yes.

Even in possible future API versions?  Why aren't they void, then?

>>> +
>>> +// try to reuse existing DX device
>>> +
>>> +if (avctx->hw_frames_ctx) {
>>> +AVHWFramesContext *device_ctx = (AVHWFramesContext*)avctx-
>>> hw_frames_ctx->data;
>>> +if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA){
>>> +if (device_ctx->device_ctx->hwctx) {
>>> +AVD3D11VADeviceContext *device_d3d11 =
>> (AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
>>> +res = ctx->context->pVtbl->InitDX11(ctx->context, 
>>> device_d3d11-
>>> device, AMF_DX11_1);
>>> +if (res == AMF_OK) {
>>> +ctx->hw_frames_ctx = 
>>> av_buffer_ref(avctx->hw_frames_ctx);
>>> +} else {
>>> +av_log(avctx, AV_LOG_INFO, "amf_shared: avctx-
>>> hw_frames_ctx has non-AMD device, switching to default");
>>
>> I'm not sure this is going to act sensibly - if the user has D3D11 frames 
>> input
>> on another device, does it work?
>>
> 
> If device is not AMD's the code is trying to create another device  - the 
> compatible one . 
> In these cases the submission will be via system memory.

And that works with D3D11 frames as hw_frames_ctx on another device?

>>> +surface->pVtbl->SetPts(surface, frame->pts);
>>
>> Does this accept the same range as frame->pts, including AV_NOPTS_VALUE?
>>
> 
> Yes, encoder doesn’t use pts, just passes the value through for convenience.

What does it do with them, then?

>>> +
>>> +int ff_amf_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
>>> +const AVFrame *frame, int *got_packet)
>>> +{
>>> +int ret = 0;
>>> +AMF_RESULT  res = AMF_OK;
>>> +AmfContext *ctx = avctx->priv_data;
>>> +AMFSurface *surface = 0;
>>> +AMFData*data = 0;
>>> +amf_bool   submitted = false;
>>> +
>>> +while (!submitted) {
>>> +if (!frame) { // submit drain
>>> +if 

[FFmpeg-devel] [PATCH] avcodec/avcodec.h: remove doxy from the old bsf API functions

[James Almer]

Make it clear that these are deprecated and the new API should be
used instead.

As a side effect, this slightly reduces differences with libav.

Signed-off-by: James Almer 
---
 libavcodec/avcodec.h | 70 +++-
 1 file changed, 14 insertions(+), 56 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ee7834c8a2..c4134424f0 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5407,81 +5407,39 @@ typedef struct AVBitStreamFilter {
 
 #if FF_API_OLD_BSF
 /**
- * Register a bitstream filter.
- *
- * The filter will be accessible to the application code through
- * av_bitstream_filter_next() or can be directly initialized with
- * av_bitstream_filter_init().
- *
- * @see avcodec_register_all()
+ * @deprecated the old bitstream filtering API (using AVBitStreamFilterContext)
+ * is deprecated. Use the new bitstream filtering API (using AVBSFContext).
  */
 attribute_deprecated
 void av_register_bitstream_filter(AVBitStreamFilter *bsf);
-
 /**
- * Create and initialize a bitstream filter context given a bitstream
- * filter name.
- *
- * The returned context must be freed with av_bitstream_filter_close().
- *
- * @param namethe name of the bitstream filter
- * @return a bitstream filter context if a matching filter was found
- * and successfully initialized, NULL otherwise
+ * @deprecated the old bitstream filtering API (using AVBitStreamFilterContext)
+ * is deprecated. Use av_bsf_get_by_name(), av_bsf_alloc(), and av_bsf_init()
+ * from the new bitstream filtering API (using AVBSFContext).
  */
 attribute_deprecated
 AVBitStreamFilterContext *av_bitstream_filter_init(const char *name);
-
 /**
- * Filter bitstream.
- *
- * This function filters the buffer buf with size buf_size, and places the
- * filtered buffer in the buffer pointed to by poutbuf.
- *
- * The output buffer must be freed by the caller.
- *
- * @param bsfcbitstream filter context created by 
av_bitstream_filter_init()
- * @param avctx   AVCodecContext accessed by the filter, may be NULL.
- *If specified, this must point to the encoder context 
of the
- *output stream the packet is sent to.
- * @param argsarguments which specify the filter configuration, 
may be NULL
- * @param poutbuf pointer which is updated to point to the filtered 
buffer
- * @param poutbuf_sizepointer which is updated to the filtered buffer size 
in bytes
- * @param buf buffer containing the data to filter
- * @param buf_sizesize in bytes of buf
- * @param keyframeset to non-zero if the buffer to filter corresponds 
to a key-frame packet data
- * @return >= 0 in case of success, or a negative error code in case of failure
- *
- * If the return value is positive, an output buffer is allocated and
- * is available in *poutbuf, and is distinct from the input buffer.
- *
- * If the return value is 0, the output buffer is not allocated and
- * should be considered identical to the input buffer, or in case
- * *poutbuf was set it points to the input buffer (not necessarily to
- * its starting address). A special case is if *poutbuf was set to NULL and
- * *poutbuf_size was set to 0, which indicates the packet should be dropped.
+ * @deprecated the old bitstream filtering API (using AVBitStreamFilterContext)
+ * is deprecated. Use av_bsf_send_packet() and av_bsf_receive_packet() from the
+ * new bitstream filtering API (using AVBSFContext).
  */
 attribute_deprecated
 int av_bitstream_filter_filter(AVBitStreamFilterContext *bsfc,
AVCodecContext *avctx, const char *args,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe);
-
 /**
- * Release bitstream filter context.
- *
- * @param bsf the bitstream filter context created with
- * av_bitstream_filter_init(), can be NULL
+ * @deprecated the old bitstream filtering API (using AVBitStreamFilterContext)
+ * is deprecated. Use av_bsf_free() from the new bitstream filtering API (using
+ * AVBSFContext).
  */
 attribute_deprecated
 void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
-
 /**
- * If f is NULL, return the first registered bitstream filter,
- * if f is non-NULL, return the next registered bitstream filter
- * after f, or NULL if f is the last one.
- *
- * This function can be used to iterate over all registered bitstream
- * filters.
+ * @deprecated the old bitstream filtering API (using AVBitStreamFilterContext)
+ * is deprecated. Use av_bsf_next() from the new bitstream filtering API (using
+ * AVBSFContext).
  */
 attribute_deprecated
 const AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f);
-- 
2.14.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avcodec/avcodec.h: remove doxy from the old bsf API functions

[Derek Buitenhuis]

On 10/29/2017 3:49 PM, James Almer wrote:
> Make it clear that these are deprecated and the new API should be
> used instead.
> 
> As a side effect, this reduces differences with libav.
> 
> Signed-off-by: James Almer 
> ---
> With this, existing users will get an extra incentive to migrate, and
> potential new users will not start using the old one by mistake.

I think it's a mistake to not at least leave some sort of "use $thing instead"
in the doxy for each, instead of just one.

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> >  REGISTER_ENCODER(H263_V4L2M2M,  h263_v4l2m2m);
> >  REGISTER_ENCDEC (LIBOPENH264,   libopenh264);
> > +REGISTER_ENCODER(H264_AMF,  h264_amf);
> > +   REGISTER_ENCODER(H264_AMF,  h264_amf_d3d11va);
> 
> No tabs.  Why is the d3d11 version separate?  The encoder should be able to
> accept multiple pixfmts.
> 

It does accept multiple formants but there is a code that searches for 
accelerator name in the encoder name and unless it is present disables 
passing accelerator to encoder. See hw_device_setup_for_encode().

> > +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
> > +{ AV_PIX_FMT_BGRA,   AMF_SURFACE_BGRA },
> > +{ AV_PIX_FMT_ARGB,   AMF_SURFACE_ARGB },
> > +{ AV_PIX_FMT_RGBA,   AMF_SURFACE_RGBA },
> > +{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
> > +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
> > +{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },
> > +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YV12 },
> > +{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
> 
> Do all of these formats actually work?

This is just a translation table. Actual support is in AVCodec::rix_fmts 

> 
> > +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> 
> D3D11 surfaces need not be NV12.  The actual format is in
> AVHWFramesContext.sw_format - if you only support 8-bit then something
> nasty probably happens if you give it P010 surfaces.
> 

Agreed, but how should I define D3D11 NV12 as input format if I only have 
AV_PIX_FMT_D3D11?

> > +};
> > +
> > +static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum
> AVPixelFormat fmt)
> > +{
> > +for (int i = 0; i < amf_countof(format_map); i++) {
> > +if (format_map[i].av_format == fmt) {
> > +return format_map[i].amf_format;
> > +}
> > +}
> > +return AMF_SURFACE_UNKNOWN;
> > +}
> > +
> > +// virtual functions decalred
> 
> What does this comment mean?
> 

These functions are virtual functions put in real virtual table.  

> > +
> > +version_fun(>version);
> > +init_fun(AMF_FULL_VERSION, >factory);
> > +ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
> > +ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
> 
> Do all of these functions necessarily succeed?
> 

Yes.

 
> > +
> > +// try to reuse existing DX device
> > +
> > +if (avctx->hw_frames_ctx) {
> > +AVHWFramesContext *device_ctx = (AVHWFramesContext*)avctx-
> >hw_frames_ctx->data;
> > +if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA){
> > +if (device_ctx->device_ctx->hwctx) {
> > +AVD3D11VADeviceContext *device_d3d11 =
> (AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
> > +res = ctx->context->pVtbl->InitDX11(ctx->context, 
> > device_d3d11-
> >device, AMF_DX11_1);
> > +if (res == AMF_OK) {
> > +ctx->hw_frames_ctx = 
> > av_buffer_ref(avctx->hw_frames_ctx);
> > +} else {
> > +av_log(avctx, AV_LOG_INFO, "amf_shared: avctx-
> >hw_frames_ctx has non-AMD device, switching to default");
> 
> I'm not sure this is going to act sensibly - if the user has D3D11 frames 
> input
> on another device, does it work?
> 

If device is not AMD's the code is trying to create another device  - the 
compatible one . 
In these cases the submission will be via system memory.

> > +surface->pVtbl->SetPts(surface, frame->pts);
> 
> Does this accept the same range as frame->pts, including AV_NOPTS_VALUE?
> 

Yes, encoder doesn’t use pts, just passes the value through for convenience.

> > +
> > +int ff_amf_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> > +const AVFrame *frame, int *got_packet)
> > +{
> > +int ret = 0;
> > +AMF_RESULT  res = AMF_OK;
> > +AmfContext *ctx = avctx->priv_data;
> > +AMFSurface *surface = 0;
> > +AMFData*data = 0;
> > +amf_bool   submitted = false;
> > +
> > +while (!submitted) {
> > +if (!frame) { // submit drain
> > +if (!ctx->eof) { // submit drain onre time only
> > +res = ctx->encoder->pVtbl->Drain(ctx->encoder);
> > +if (res == AMF_INPUT_FULL) {
> > +av_usleep(1000); // input queue is full: wait, poll 
> > and submit
> Drain again
> > + // need to get some output and try 
> > again
> > +} else if (res == AMF_OK) {
> > +ctx->eof = true; // drain started
> > +submitted = true;
> > +}
> > +}
> > +} else { // submit frame
> > +if (surface == 0) { // prepare surface from frame one time only
> > +if (frame->hw_frames_ctx && ( // HW frame detected
> > +  // check if the same 
> > hw_frames_ctx as used in
> initialization
> > +

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avio: temporarily accept 0 as EOF.

[Jan Ekstrom]

On Fri, Oct 27, 2017 at 9:56 PM, Jan Ekstrom  wrote:
> On Fri, Oct 27, 2017 at 9:46 PM, Nicolas George  wrote:
>> Print a warning to let applicatios fix their use.
>> After a deprecation period, check with a low-level assert.
>> Also make the constraint explicit in the doxygen comment.
>
> Difference to the previous version:
>> -av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream 
>> protocol\n");
>> +av_log(NULL, AV_LOG_WARNING, "Invalid return value 0 for stream 
>> protocol\n");
>
> Thus LGTM.
>
> Jan

The patch set has been applied.


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

Re: [FFmpeg-devel] [PATCH 7/7] dashenc: copy stream frame rate to output stream

[Michael Niedermayer]

On Thu, Oct 26, 2017 at 05:58:40PM +0200, Peter Große wrote:
> Leads to setting of DefaultDuration in Matroska muxer based on frame rate 
> instead of timebase.
> Fixes playback in Chrome.
> 
> Signed-off-by: Peter Große 
> ---
>  libavformat/dashenc.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH v2 6/7] dashenc: Don't output frameRates at both AS and Representation-level. Only output maxFrameRate at AS-level.

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 04:10:35PM +0100, Peter Große wrote:
> From: Anton Schubert 
> 
> Fix conformance regarding section "3.2.4. Presence of Attributes and
> Element" of the "Guidelines for Implementation: DASH-IF Interoperability
> Points V4.1" (http://dashif.org/guidelines/)
> 
> Signed-off-by: Anton Schubert 
> Signed-off-by: Peter Große 
> ---
> v2: extended commit message

will apply

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH 5/7] dashenc: allow AdaptationSets to have different average frame rates

[Michael Niedermayer]

On Thu, Oct 26, 2017 at 06:17:31PM +0200, Peter Große wrote:
> Signed-off-by: Peter Große 
> ---
>  libavformat/dashenc.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)

will apply

thanks

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH 4/7] dashenc: don't write header data before the first packet arrives

[Michael Niedermayer]

On Thu, Oct 26, 2017 at 05:58:37PM +0200, Peter Große wrote:
> Fixes: 1b8ef01f04ab ("dashenc: add webm support")
> Signed-off-by: Peter Große 
> ---
>  libavformat/dashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thanks

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

[Devin Heitmueller]

> On Oct 25, 2017, at 2:23 PM, Marton Balint  wrote:
> 
> 
> On Fri, 6 Oct 2017, Devin Heitmueller wrote:
> 
>> From: Devin Heitmueller > >
>> 
>> Hook in libklvanc and use it for output of EIA-708 captions over
>> SDI.  The bulk of this patch is just general support for ancillary
>> data for the Decklink SDI module - the real work for construction
>> of the EIA-708 CDP and VANC line construction is done by libklvanc.
>> 
>> Libklvanc can be found at: https://github.com/stoth68000/libklvanc 
>> 
> 
> Sorry for the delay, I had little time lately. In general I think it is OK to 
> put VANC functionality into a library, but libklvanc does not seem like a 
> very mature one, it has some pretty generic function names without 
> namespacing, e.g. "generate_vanc_line". Or it is using simple printf for the 
> dumper functions. You plan to work on these kind of issues to make it more 
> like a "stable" generic library?

Yeah, the name spacing and logging are known issues and have been on my todo 
list for a while.  The focus has been on the core functionality for VANC 
management and protocol support, and there clearly needs a bit more polish on 
some of the peripheral areas.

Thanks for providing feedback.  I will incorporate your suggestions and submit 
a revised patch this week.

Regards,

Devin

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

[FFmpeg-devel] checkasm/llviddsp : add tests for other func of the dsp

[Martin Vignali]

Hello,

in attach patch to add a checkasm test for the uncover func of the dsp

add_median_pred

add_left_pred
for this one i add two tests : one with acc = 0 (used in several decoders)
and one with random acc

add_left_pred16


Martin


0002-checkasm-llviddsp-add-test-for-other-dsp-func.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/7] dashenc: set DASH related options for the subsequent matroska muxer when using webm

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 04:10:36PM +0100, Peter Große wrote:
> This patch is inspired by the ffmpeg webm_chunk muxer and fixes that all 
> resulting
> tracks have the same track number.
> 
> Signed-off-by: Peter Große 
> ---
> v2: extended commit message
> 
>  libavformat/dashenc.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

thx

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

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


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

Re: [FFmpeg-devel] [PATCH v2 1/7] dashenc: fix bitrate estimation with correct scaling

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 04:10:34PM +0100, Peter Große wrote:
> From: Anton Schubert 
> 
> Signed-off-by: Anton Schubert 
> Signed-off-by: Peter Große 
> ---
> v2: Fixed double rescaling.
> 
>  libavformat/dashenc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

will apply

thx

[...]
-- 
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]lavfi/palettegen: Allow setting the background colour

[Clément Bœsch]

On Sun, Oct 29, 2017 at 01:47:03AM +0200, Carl Eugen Hoyos wrote:
> 2017-10-28 23:50 GMT+02:00 Clément Bœsch :
> > On Sat, Oct 28, 2017 at 10:57:32PM +0200, Carl Eugen Hoyos wrote:
> >> 2017-10-17 23:42 GMT+02:00 Carl Eugen Hoyos :
> >>
> >> > Attached patch is useful in combination with the transparency patch
> >> > for paletteuse.
> >>
> >> > +{ "background", "set a background color for transparency", 
> >> > OFFSET(background), AV_OPT_TYPE_COLOR, {.str="white"}, CHAR_MIN, 
> >> > CHAR_MAX, FLAGS },
> >>
> >> Locally changed to "lime" to make sure fate stays unchanged.
> >>
> >
> > Please use "transparency_color" as option name (and field struct).
> 
> I liked "background";-(
> 

But it's not a background color, it's a reference color code typically
used for the transparency optimization. It's a reserved entry such that
the encoder can perform a good compression.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpeglsdec: Check ilv for being a supported value

[Michael Niedermayer]

On Thu, Oct 26, 2017 at 12:02:56AM +0200, Michael Niedermayer wrote:
> Fixes: 1773/clusterfuzz-testcase-minimized-4832523987189760
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/jpeglsdec.c | 4 
>  1 file changed, 4 insertions(+)

will apply patchset


[...]
-- 
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] fate/utvideo add test for decoding and encoding V2

[Michael Niedermayer]

On Sat, Oct 28, 2017 at 02:13:26PM +0200, Martin Vignali wrote:
> Hello,
> 
> New patch in attach, with more samples, in order to test most of the not
> covered case
> 
> Sample can be found here
> https://we.tl/EV2lBmOXk0
> 
> And need to be put inside ./fate-suite/utvideo
> 
> Decoding test add :
> - interlace median/gradient (YUV420, YUV422, YUV444, RGB)
> - gradient (YUV420, YUV422, YUV444, RGB)
> - median, Left (YUV 444) : (other pred already have test)
> 
> Samples have been generate using the UTVideoSuite on windows
> 
> 
> Encoding test add :
> - YUV 444 (median, left, none)
> 
> can be test with
> 
> make fate-utvideoenc
> make fate-utvideo SAMPLES=fate-suite/
> 
> Tested on os X (X86_64)
> 
> Martin

>  fate/utvideo.mak |   48 
>  ref/fate/utvideo_rgb_int_gradient|6 +++
>  ref/fate/utvideo_rgb_int_median  |6 +++
>  ref/fate/utvideo_rgba_gradient   |6 +++
>  ref/fate/utvideo_yuv420_gradient |6 +++
>  ref/fate/utvideo_yuv420_int_gradient |6 +++
>  ref/fate/utvideo_yuv420_int_median   |6 +++
>  ref/fate/utvideo_yuv422_gradient |6 +++
>  ref/fate/utvideo_yuv422_int_gradient |6 +++
>  ref/fate/utvideo_yuv422_int_median   |6 +++
>  ref/fate/utvideo_yuv444_709_gradient |6 +++
>  ref/fate/utvideo_yuv444_709_int_gradient |6 +++
>  ref/fate/utvideo_yuv444_709_int_median   |6 +++
>  ref/fate/utvideo_yuv444_709_median   |6 +++
>  ref/fate/utvideoenc_yuv444_left  |   60 
> +++
>  ref/fate/utvideoenc_yuv444_median|   60 
> +++
>  ref/fate/utvideoenc_yuv444_none  |   60 
> +++
>  17 files changed, 306 insertions(+)

LGTM

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-10-29 16:43 GMT+01:00 Mironov, Mikhail :

>> >> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
>> >> > +AV_PIX_FMT_NV12,
>> >>
>> >> > +AV_PIX_FMT_BGRA,
>> >> > +AV_PIX_FMT_ARGB,
>> >> > +AV_PIX_FMT_RGBA,
>> >>
>> >> This is wrong, your encoders do not convert transparency information,
>> >> there are 32 rgb formats without alpha channel.
>>
>> > In addition, the encoder has built-in shader-based color converter. It
>> > can accept BGRA and RGBA formats and convert them into NV12
>>
>> Yes, I understood.
>>
>> > dropping alpha channel.
>>
>> Which is why using AV_PIX_FMT_BGRA is wrong, use AV_PIX_FMT_BGR0
>> (and friends).

> Got it, will do. This is my first contribution to FFmpeg. Should I resubmit 
> with
> this change or wait for some time for more comments and resubmit all-together?

While my comment does not justify a new submission,
Mark's clearly does.
(There was more than one sentence in his review.)

Please cut your quotes, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/avcodec.h: remove doxy from the old bsf API functions

[James Almer]

Make it clear that these are deprecated and the new API should be
used instead.

As a side effect, this reduces differences with libav.

Signed-off-by: James Almer 
---
With this, existing users will get an extra incentive to migrate, and
potential new users will not start using the old one by mistake.

 libavcodec/avcodec.h | 66 ++--
 1 file changed, 2 insertions(+), 64 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ee7834c8a2..5a65ed1067 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5407,82 +5407,20 @@ typedef struct AVBitStreamFilter {
 
 #if FF_API_OLD_BSF
 /**
- * Register a bitstream filter.
- *
- * The filter will be accessible to the application code through
- * av_bitstream_filter_next() or can be directly initialized with
- * av_bitstream_filter_init().
- *
- * @see avcodec_register_all()
+ * @deprecated the old bitstream filtering API (using AVBitStreamFilterContext)
+ * is deprecated. Use the new bitstream filtering API (using AVBSFContext).
  */
 attribute_deprecated
 void av_register_bitstream_filter(AVBitStreamFilter *bsf);
-
-/**
- * Create and initialize a bitstream filter context given a bitstream
- * filter name.
- *
- * The returned context must be freed with av_bitstream_filter_close().
- *
- * @param namethe name of the bitstream filter
- * @return a bitstream filter context if a matching filter was found
- * and successfully initialized, NULL otherwise
- */
 attribute_deprecated
 AVBitStreamFilterContext *av_bitstream_filter_init(const char *name);
-
-/**
- * Filter bitstream.
- *
- * This function filters the buffer buf with size buf_size, and places the
- * filtered buffer in the buffer pointed to by poutbuf.
- *
- * The output buffer must be freed by the caller.
- *
- * @param bsfcbitstream filter context created by 
av_bitstream_filter_init()
- * @param avctx   AVCodecContext accessed by the filter, may be NULL.
- *If specified, this must point to the encoder context 
of the
- *output stream the packet is sent to.
- * @param argsarguments which specify the filter configuration, 
may be NULL
- * @param poutbuf pointer which is updated to point to the filtered 
buffer
- * @param poutbuf_sizepointer which is updated to the filtered buffer size 
in bytes
- * @param buf buffer containing the data to filter
- * @param buf_sizesize in bytes of buf
- * @param keyframeset to non-zero if the buffer to filter corresponds 
to a key-frame packet data
- * @return >= 0 in case of success, or a negative error code in case of failure
- *
- * If the return value is positive, an output buffer is allocated and
- * is available in *poutbuf, and is distinct from the input buffer.
- *
- * If the return value is 0, the output buffer is not allocated and
- * should be considered identical to the input buffer, or in case
- * *poutbuf was set it points to the input buffer (not necessarily to
- * its starting address). A special case is if *poutbuf was set to NULL and
- * *poutbuf_size was set to 0, which indicates the packet should be dropped.
- */
 attribute_deprecated
 int av_bitstream_filter_filter(AVBitStreamFilterContext *bsfc,
AVCodecContext *avctx, const char *args,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe);
-
-/**
- * Release bitstream filter context.
- *
- * @param bsf the bitstream filter context created with
- * av_bitstream_filter_init(), can be NULL
- */
 attribute_deprecated
 void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
-
-/**
- * If f is NULL, return the first registered bitstream filter,
- * if f is non-NULL, return the next registered bitstream filter
- * after f, or NULL if f is the last one.
- *
- * This function can be used to iterate over all registered bitstream
- * filters.
- */
 attribute_deprecated
 const AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f);
 #endif
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH v4 1/2 ] avformat/mpegts: opus muxing for mapping family 255

[Michael Niedermayer]

On Sat, Oct 28, 2017 at 03:49:13AM +0200, pkv.stream wrote:
> 
> 

>  mpegtsenc.c |   67 
> +---
>  1 file changed, 60 insertions(+), 7 deletions(-)
> 1423a193788547952e3c4cdcb424b4724b0f1157  
> 0001-libavf-mpegts-opus-muxing-for-mapping-family-255.patch
> From 105f20b8af8ce5376165ca30a81276dae2e61e40 Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Sat, 28 Oct 2017 02:48:08 +0200
> Subject: [PATCH 1/2] libavf/mpegts: opus muxing for mapping family 255
> 
> Adds to mpegts muxer the capability  to mux libopus with mapping family
> 255, following the provisional spec for opus in mepg-ts
> (https://people.xiph.org/~tterribe/opus/ETSI_TS_opus-v0.1.3-draft.doc).
> 
> Signed-off-by: pkviet 
> ---
>  libavformat/mpegtsenc.c | 67 
> +++--
>  1 file changed, 60 insertions(+), 7 deletions(-)
> 
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index fdfa544..a31663c 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -28,6 +28,7 @@
>  #include "libavutil/opt.h"
>  
>  #include "libavcodec/internal.h"
> +#include "libavcodec/put_bits.h"
>  
>  #include "avformat.h"
>  #include "avio_internal.h"
> @@ -291,6 +292,9 @@ static int mpegts_write_pmt(AVFormatContext *s, 
> MpegTSService *service)
>  MpegTSWrite *ts = s->priv_data;
>  uint8_t data[SECTION_LENGTH], *q, *desc_length_ptr, 
> *program_info_length_ptr;
>  int val, stream_type, i, err = 0;
> +uint8_t channel_count, stream_count, coupled_stream_count, *buf;
> +PutBitContext pbc;
> +size_t buf_size;
>  
>  q = data;
>  put16(, 0xe000 | service->pcr_pid);
> @@ -421,8 +425,8 @@ static int mpegts_write_pmt(AVFormatContext *s, 
> MpegTSService *service)
>  *q++ = 'D';
>  }
>  if (st->codecpar->codec_id==AV_CODEC_ID_OPUS) {
> -/* 6 bytes registration descriptor, 4 bytes Opus audio 
> descriptor */
> -if (q - data > SECTION_LENGTH - 6 - 4) {
> +/* 6 bytes registration descriptor, 6 bytes Opus audio 
> descriptor */
> +if (q - data > SECTION_LENGTH - 6 - 6) {
>  err = 1;
>  break;
>  }
> @@ -435,8 +439,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
> MpegTSService *service)
>  *q++ = 's';
>  
>  *q++ = 0x7f; /* DVB extension descriptor */
> -*q++ = 2;
> -*q++ = 0x80;
> +/* descriptor_length */
> +if (st->codecpar->extradata[18] == 255) {
> +/* dual mono */
> +if (st->codecpar->channels == 2) {
> +*q++ = 2;
> +} else {
> +/* channel_config_code 0x81 */
> +*q++ = st->codecpar->channels + 6;
> +}
> +} else {
> +*q++ = 2;
> +}
> +*q++ = 0x80; /* descriptor_tag_extension */
>  
>  if (st->codecpar->extradata && st->codecpar->extradata_size 
> >= 19) {
>  if (st->codecpar->extradata[18] == 0 && 
> st->codecpar->channels <= 2) {
> @@ -483,9 +498,47 @@ static int mpegts_write_pmt(AVFormatContext *s, 
> MpegTSService *service)
>  *q++ = 0xff;
>  }
>  } else {
> -/* Unsupported */
> -av_log(s, AV_LOG_ERROR, "Unsupported Opus channel 
> mapping for family %d", st->codecpar->extradata[18]);
> -*q++ = 0xff;
> +/* mapping family 255 , set channel_config_code to 
> 0x81 except for dual-mono */
> +if (st->codecpar->extradata[18] == 255) {
> +/* dual mono */
> +if (st->codecpar->channels == 2 && 
> st->codecpar->extradata[19] == 1) {
> +*q++ = 0x00;
> +} else if (st->codecpar->channels == 2 && 
> st->codecpar->extradata[19] == 2) {
> +*q++ = 0x80;
> +} else {
> +/* application defined channel configuration */
> +*q++ = 0x81;
> +*q++ = st->codecpar->channels;
> +*q++ = st->codecpar->extradata[18];
> +channel_count = st->codecpar->channels;
> +stream_count = st->codecpar->extradata[19];
> +coupled_stream_count = 
> st->codecpar->extradata[20];
> +buf = av_mallocz_array( 
> st->codecpar->channels + 2 , sizeof(uint8_t));

> +if 

Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'

[James Almer]

On 10/29/2017 12:04 PM, Carl Eugen Hoyos wrote:
> 2017-10-12 2:22 GMT+02:00 Michael Niedermayer :
>> On Wed, Oct 11, 2017 at 09:26:18PM +, James Almer wrote:
>>> ffmpeg | branch: master | James Almer  | Wed Oct 11 
>>> 17:55:25 2017 -0300| [6dfcbd80ad446ff163b47f2bf432bbf706436ea8] | 
>>> committer: James Almer
>>>
>>> Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'
>>>
>>> * commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63':
>>>   build: Fine-grained link-time dependency settings
>>>
>>> Also included are bug fix commits 5ff3b5cafcc685b6936d16602b0f80aa09a95870,
>>> d9da7151eef7fc469787e7298196cea291acfd82 and
>>> 5e27ef800bfa2be17a6353ddedac6b7400e4624f.
>>>
>>> Merged-by: James Almer 
>>>
 http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6dfcbd80ad446ff163b47f2bf432bbf706436ea8
>>> ---
>>>
>>>  Makefile|   3 +-
>>>  configure   | 297 
>>> +---
>>>  ffbuild/common.mak  |   2 +-
>>>  ffbuild/library.mak |   2 +-
>>>  tests/checkasm/Makefile |   2 +-
>>>  5 files changed, 187 insertions(+), 119 deletions(-)
>>
>> This breaks build here (linux x86-64)
>>
>> ./configure --enable-libxavs --enable-gpl
> 
> The commit broke aix, configure does not terminate now.
> 
> Carl Eugen

It should terminate just fine, but it may take a while on some systems
given the recursive dependency checks configure does since this commit.

It's fast on Linux but slow on Windows, for example.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: October 29, 2017 11:00 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> 2017-10-29 15:54 GMT+01:00 Mironov, Mikhail
> :
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Carl Eugen Hoyos
> >> Sent: October 28, 2017 3:19 PM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> >> encoding for AMD GPUs based on AMF SDK
> >>
> >> 2017-10-27 20:09 GMT+02:00 mmironov :
> >> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> >> > +AV_PIX_FMT_NV12,
> >>
> >> > +AV_PIX_FMT_BGRA,
> >> > +AV_PIX_FMT_ARGB,
> >> > +AV_PIX_FMT_RGBA,
> >>
> >> This is wrong, your encoders do not convert transparency information,
> >> there are 32 rgb formats without alpha channel.
> 
> > In addition, the encoder has built-in shader-based color converter. It
> > can accept BGRA and RGBA formats and convert them into NV12
> 
> Yes, I understood.
> 
> > dropping alpha channel.
> 
> Which is why using AV_PIX_FMT_BGRA is wrong, use AV_PIX_FMT_BGR0
> (and friends).
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Got it, will do. This is my first contribution to FFmpeg. Should I resubmit 
with this change or wait for some time for more comments and resubmit 
all-together?
Mikhail 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/7] dashenc: set DASH related options for the subsequent matroska muxer when using webm

[Peter Große]

This patch is inspired by the ffmpeg webm_chunk muxer and fixes that all 
resulting
tracks have the same track number.

Signed-off-by: Peter Große 
---
v2: extended commit message

 libavformat/dashenc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index e25a660fbe..0ca7cf5aa3 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -778,6 +778,9 @@ static int dash_init(AVFormatContext *s)
 } else {
 av_dict_set_int(, "cluster_time_limit", c->min_seg_duration / 
1000, 0);
 av_dict_set_int(, "cluster_size_limit", 5 * 1024 * 1024, 0); 
// set a large cluster size limit
+av_dict_set_int(, "dash", 1, 0);
+av_dict_set_int(, "dash_track_number", i + 1, 0);
+av_dict_set_int(, "live", 1, 0);
 }
 if ((ret = avformat_write_header(ctx, )) < 0)
 return ret;
-- 
2.13.6

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

[FFmpeg-devel] [PATCH v2 6/7] dashenc: Don't output frameRates at both AS and Representation-level. Only output maxFrameRate at AS-level.

[Peter Große]

From: Anton Schubert 

Fix conformance regarding section "3.2.4. Presence of Attributes and
Element" of the "Guidelines for Implementation: DASH-IF Interoperability
Points V4.1" (http://dashif.org/guidelines/)

Signed-off-by: Anton Schubert 
Signed-off-by: Peter Große 
---
v2: extended commit message

 libavformat/dashenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index c55106c11d..82381b67a9 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -393,8 +393,8 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 
 avio_printf(out, "\t\tid, as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : 
"audio");
-if (as->media_type == AVMEDIA_TYPE_VIDEO && as->max_frame_rate.num && 
!as->ambiguous_frame_rate)
-avio_printf(out, " %s=\"%d/%d\"", (av_cmp_q(as->min_frame_rate, 
as->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate", 
as->max_frame_rate.num, as->max_frame_rate.den);
+if (as->media_type == AVMEDIA_TYPE_VIDEO && as->max_frame_rate.num && 
!as->ambiguous_frame_rate && av_cmp_q(as->min_frame_rate, as->max_frame_rate) < 
0)
+avio_printf(out, " maxFrameRate=\"%d/%d\"", as->max_frame_rate.num, 
as->max_frame_rate.den);
 lang = av_dict_get(as->metadata, "language", NULL, 0);
 if (lang)
 avio_printf(out, " lang=\"%s\"", lang->value);
-- 
2.13.6

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

[FFmpeg-devel] [PATCH v2 1/7] dashenc: fix bitrate estimation with correct scaling

[Peter Große]

From: Anton Schubert 

Signed-off-by: Anton Schubert 
Signed-off-by: Peter Große 
---
v2: Fixed double rescaling.

 libavformat/dashenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 04b0fd99e6..e25a660fbe 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -947,6 +947,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
+AVStream *st = s->streams[i];
 char filename[1024] = "", full_path[1024], temp_path[1024];
 int range_length, index_length = 0;
 
@@ -1001,7 +1002,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 
 if (!os->bit_rate) {
 // calculate average bitrate of first segment
-int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
(os->max_pts - os->start_pts);
+int64_t bitrate = (int64_t) range_length * 8 / ((os->max_pts - 
os->start_pts) * av_q2d(st->time_base));
 if (bitrate >= 0) {
 os->bit_rate = bitrate;
 snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
-- 
2.13.6

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

Re: [FFmpeg-devel] fate/utvideo add test for decoding and encoding V2

[Michael Niedermayer]

On Sat, Oct 28, 2017 at 02:13:26PM +0200, Martin Vignali wrote:
> Hello,
> 
> New patch in attach, with more samples, in order to test most of the not
> covered case
> 
> Sample can be found here
> https://we.tl/EV2lBmOXk0

uploaded

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'

[Carl Eugen Hoyos]

2017-10-12 2:22 GMT+02:00 Michael Niedermayer :
> On Wed, Oct 11, 2017 at 09:26:18PM +, James Almer wrote:
>> ffmpeg | branch: master | James Almer  | Wed Oct 11 
>> 17:55:25 2017 -0300| [6dfcbd80ad446ff163b47f2bf432bbf706436ea8] | committer: 
>> James Almer
>>
>> Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'
>>
>> * commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63':
>>   build: Fine-grained link-time dependency settings
>>
>> Also included are bug fix commits 5ff3b5cafcc685b6936d16602b0f80aa09a95870,
>> d9da7151eef7fc469787e7298196cea291acfd82 and
>> 5e27ef800bfa2be17a6353ddedac6b7400e4624f.
>>
>> Merged-by: James Almer 
>>
>> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6dfcbd80ad446ff163b47f2bf432bbf706436ea8
>> ---
>>
>>  Makefile|   3 +-
>>  configure   | 297 
>> +---
>>  ffbuild/common.mak  |   2 +-
>>  ffbuild/library.mak |   2 +-
>>  tests/checkasm/Makefile |   2 +-
>>  5 files changed, 187 insertions(+), 119 deletions(-)
>
> This breaks build here (linux x86-64)
>
> ./configure --enable-libxavs --enable-gpl

The commit broke aix, configure does not terminate now.

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-10-29 15:54 GMT+01:00 Mironov, Mikhail :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: October 28, 2017 3:19 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
>> encoding for AMD GPUs based on AMF SDK
>>
>> 2017-10-27 20:09 GMT+02:00 mmironov :
>> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
>> > +AV_PIX_FMT_NV12,
>>
>> > +AV_PIX_FMT_BGRA,
>> > +AV_PIX_FMT_ARGB,
>> > +AV_PIX_FMT_RGBA,
>>
>> This is wrong, your encoders do not convert transparency information, there
>> are 32 rgb formats without alpha channel.

> In addition, the encoder has built-in shader-based color converter. It can
> accept BGRA and RGBA formats and convert them into NV12

Yes, I understood.

> dropping alpha channel.

Which is why using AV_PIX_FMT_BGRA is wrong, use AV_PIX_FMT_BGR0
(and friends).

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

[FFmpeg-devel] [PATCH] tests/checkasm/float_dsp: Increase allowed difference for float_dsp.vector_dmul

[Michael Niedermayer]

The choosen value is the lowest power of 2 that allows 1000 iterations of 
fate-checkasm-float_dsp
to pass on x86-32

Signed-off-by: Michael Niedermayer 
---
 tests/checkasm/float_dsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/float_dsp.c b/tests/checkasm/float_dsp.c
index 9b0a221c25..676c341f45 100644
--- a/tests/checkasm/float_dsp.c
+++ b/tests/checkasm/float_dsp.c
@@ -165,7 +165,7 @@ static void test_vector_dmul_scalar(const double *src0, 
const double *src1)
 call_ref(cdst, src0, src1[0], LEN);
 call_new(odst, src0, src1[0], LEN);
 for (i = 0; i < LEN; i++) {
-if (!double_near_abs_eps(cdst[i], odst[i], DBL_EPSILON)) {
+if (!double_near_abs_eps(cdst[i], odst[i], 256*DBL_EPSILON)) {
 fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n", i,
 cdst[i], odst[i], cdst[i] - odst[i]);
 fail();
-- 
2.14.2

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

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: October 28, 2017 5:29 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> On 27/10/17 19:09, mmironov wrote:
> > From b1b697aed459947cfa04bccdca0f7cfb5c8be72c Mon Sep 17 00:00:00
> 2001
> > From: mmironov 
> > Date: Fri, 27 Oct 2017 13:03:15 -0400
> > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
> AMD GPUs
> >  based on AMF SDK
> 
> There isn't any sense in which this is "accelerated" is there?  Just say it's 
> a
> hardware encoder (as you already do in the changelog).

OK, will do next time. 
Mikhail

> >
> > Signed-off-by: mmironov 
> > ---
> >  Changelog|3 +-
> >  compat/amd/amfsdkenc.h   | 1750
> ++
> >  configure|   28 +
> >  libavcodec/Makefile  |4 +
> >  libavcodec/allcodecs.c   |4 +
> >  libavcodec/amfenc.c  |  463 
> >  libavcodec/amfenc.h  |  131 
> >  libavcodec/amfenc_h264.c |  467 +
> >  libavcodec/amfenc_hevc.c |  354 ++
> >  libavcodec/version.h |4 +-
> >  10 files changed, 3205 insertions(+), 3 deletions(-)
> >  create mode 100644 compat/amd/amfsdkenc.h
> >  create mode 100644 libavcodec/amfenc.c
> >  create mode 100644 libavcodec/amfenc.h
> >  create mode 100644 libavcodec/amfenc_h264.c
> >  create mode 100644 libavcodec/amfenc_hevc.c
> >
> > diff --git a/Changelog b/Changelog
> > index 6592d86..f0d22fa 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -6,7 +6,8 @@ version :
> >  - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG
> now
> >requires 2.1 (or later) and pkg-config.
> >  - VDA dropped (use VideoToolbox instead)
> > -
> > +- AMF H.264 encoder
> > +- AMF HEVC encoder
> >
> >  version 3.4:
> >  - deflicker video filter
> > diff --git a/compat/amd/amfsdkenc.h b/compat/amd/amfsdkenc.h
> > new file mode 100644
> > index 000..a640c17
> > --- /dev/null
> > +++ b/compat/amd/amfsdkenc.h
> 
> (Ignoring the header, will consider this separately.)
> 
> > diff --git a/configure b/configure
> > index 0e1ccaa..229443f 100755
> > --- a/configure
> > +++ b/configure
> > @@ -304,6 +304,7 @@ External library support:
> >
> >The following libraries provide various hardware acceleration features:
> >--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
> > +  --disable-amfdisable AMF video encoding code [autodetect]
> >--disable-cuda   disable dynamically linked Nvidia CUDA code
> [autodetect]
> >--enable-cuda-sdkenable CUDA features that require the CUDA SDK
> [no]
> >--disable-cuvid  disable Nvidia CUVID support [autodetect]
> > @@ -1643,6 +1644,7 @@ EXTERNAL_LIBRARY_LIST="
> >  HWACCEL_AUTODETECT_LIBRARY_LIST="
> >  audiotoolbox
> >  crystalhd
> > +   amf
> >  cuda
> >  cuvid
> >  d3d11va
> 
> Lists in configure should be kept in alphabetical order.
> 
> > @@ -2785,12 +2787,16 @@ scale_npp_filter_deps="cuda libnpp"
> >  scale_cuda_filter_deps="cuda_sdk"
> >  thumbnail_cuda_filter_deps="cuda_sdk"
> >
> > +amf_deps_any="dlopen LoadLibrary"
> > +amf_encoder_deps="amf"
> > +
> >  nvenc_deps="cuda"
> >  nvenc_deps_any="libdl LoadLibrary"
> >  nvenc_encoder_deps="nvenc"
> >
> >  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
> >  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
> > +h264_amf_encoder_deps="amf"
> >  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf
> h264_parser"
> >  h264_cuvid_decoder_deps="cuda cuvid"
> >  h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
> > @@ -2809,6 +2815,7 @@
> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
> >  h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
> >  h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
> >  h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
> > +hevc_amf_encoder_deps="amf"
> >  hevc_cuvid_decoder_deps="cuda cuvid"
> >  hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
> >  hevc_mediacodec_decoder_deps="mediacodec"
> > @@ -2830,6 +2837,8 @@ mjpeg_vaapi_encoder_select="vaapi_encode
> jpegtables"
> >  mpeg1_cuvid_decoder_deps="cuda cuvid"
> >  mpeg1_v4l2m2m_decoder_deps="v4l2_m2m mpeg1_v4l2_m2m"
> >  mpeg2_crystalhd_decoder_select="crystalhd"
> > +amf_h264_encoder_select="h264_amf_encoder"
> > +amf_hevc_encoder_select="hevc_amf_encoder"
> 
> These names aren't mentioned anywhere else.
> 
> >  mpeg2_cuvid_decoder_deps="cuda cuvid"
> >  mpeg2_mmal_decoder_deps="mmal"
> >  mpeg2_mediacodec_decoder_deps="mediacodec"
> > @@ -6305,6 +6314,18 @@ else
> >  disable cuda cuvid nvenc
> >  fi
> >
> > +if enabled x86; then
> > +case $target_os in
> > +mingw32*|mingw64*|win32|win64|cygwin*)
> > +;;
> > +*)
> > +disable  

Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: October 28, 2017 3:19 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> 2017-10-27 20:09 GMT+02:00 mmironov :
> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> > +AV_PIX_FMT_NV12,
> 
> > +AV_PIX_FMT_BGRA,
> > +AV_PIX_FMT_ARGB,
> > +AV_PIX_FMT_RGBA,
> 
> This is wrong, your encoders do not convert transparency information, there
> are 32 rgb formats without alpha channel.
> 
> > +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
> > +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> 
> Just curious: Can you explain this in simple words?
> 
> I will try not to comment on the headers you sent, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Sure: the native format for the encoder is NV12. It can work via D3D11 and 
accept DXGI_FORMAT_NV12 texture or via D3D9  accepting 
(D3DFORMAT)MAKEFOURCC('N', 'V', '1', '2') surface. AMF surfaces are wrappers 
around these objects and converters from system memory. In addition, the 
encoder has built-in shader-based color converter. It can accept BGRA and RGBA 
formats and convert them into NV12 dropping alpha channel. This is why I added 
these entries. Granted, the conversion lacks parameters and to support more 
options AMF has a separate color space component, also shader-based. Once 
encoder is integrated I planned to ask FFmpeg team opinion if it is needed or 
not. 
I made the FFmpeg encoder accepting DX objects from other FFmpeg components if 
available.
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Paul B Mahol]

On 10/29/17, Carl Eugen Hoyos  wrote:
> 2017-10-24 23:10 GMT+02:00 Carl Eugen Hoyos :
>> Hi!
>>
>> Attached patch allows sending pcm_s24be over rtp, defined in rfc 3190.
>
> Patch applied, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

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

[Carl Eugen Hoyos]

2017-10-24 23:10 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch allows sending pcm_s24be over rtp, defined in rfc 3190.

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

Re: [FFmpeg-devel] libavcodec/bswapdsp : add AVX2 for bswap_buf

[James Darnley]

On 2017-10-28 17:57, Martin Vignali wrote:

>>> For this, i follow Henrik Gramner's code, in the discussion
>>> libavcodec/exr : add x86 SIMD for predictor.
>>
>> That's fine.  I will look at that on my own time.  I don't want to hold
>> up applying the patch.  Would you like me to push it for you?
>>
>>
>> Yes please push it if you can.
> Thanks !
> 
> Martin

Done, at last, with only a ~22 hour delay.




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

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()

[Peter Große]

On Sun, 29 Oct 2017 14:56:20 +0100
Moritz Barsnick  wrote:

> On Sun, Oct 29, 2017 at 12:08:05 +0100, Peter Große wrote:
> >  } else duration = 1;  
> 
> For style/readability, the statement should be on a new line, perhaps
> even with brackets. (Not necessarily as part of this patch though.)

Sure.

Regards
Peter
From 14032f4185a0824b819b062068f5777a33057ece Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Peter=20Gro=C3=9Fe?= 
Date: Sun, 29 Oct 2017 15:07:12 +0100
Subject: [PATCH] ffmpeg.c: fix code style in seek_to_start
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To: ffmpeg-devel@ffmpeg.org

Signed-off-by: Peter Große 
---
 fftools/ffmpeg.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 17b594bac8..1e43b959da 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4140,14 +4140,17 @@ static int seek_to_start(InputFile *ifile, AVFormatContext *is)
 AVRational sample_rate = {1, avctx->sample_rate};
 
 duration = av_rescale_q(ist->nb_samples, sample_rate, ist->st->time_base);
-} else
+} else {
 continue;
+}
 } else {
 if (ist->framerate.num) {
 duration = av_rescale_q(1, av_inv_q(ist->framerate), ist->st->time_base);
 } else if (ist->st->avg_frame_rate.num) {
 duration = av_rescale_q(1, av_inv_q(ist->st->avg_frame_rate), ist->st->time_base);
-} else duration = 1;
+} else {
+duration = 1;
+}
 }
 if (!ifile->duration)
 ifile->time_base = ist->st->time_base;
-- 
2.13.6

___
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.

[Carl Eugen Hoyos]

2017-10-29 13:39 GMT+01:00 Michael Niedermayer :
> On Sat, Oct 28, 2017 at 08:26:16PM +0200, Michael Niedermayer wrote:
>> On Thu, Oct 26, 2017 at 08:51:50PM -0700, Sasi Inguva wrote:

>> >  libavformat/mov.c   |   21 +-
>> >  tests/fate/mov.mak  |4 +
>> >  tests/ref/fate/mov-invalid-elst-entry-count |   57 
>> > 
>> >  3 files changed, 81 insertions(+), 1 deletion(-)
>> > c553340f66797876d039f408f83574a40c54d17b  
>> > 0001-lavf-mov.c-Fix-parsing-of-edit-list-atoms-with-inval.patch
>> > From 188602e662868a79c7f85e9193e9aedc9ba1a170 Mon Sep 17 00:00:00 2001
>> > From: Sasi Inguva 
>> > Date: Wed, 18 Oct 2017 20:11:16 -0700
>> > Subject: [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid 
>> > elst
>> >  entry count.
>>
>> applied
>
> It seems this fails on ARM qemu

Fails differently here on ppc64be:

--- ./tests/ref/fate/mov-invalid-elst-entry-count   2017-10-28
22:32:57.766024470 +
+++ tests/data/fate/mov-invalid-elst-entry-count2017-10-29
14:04:35.227325635 +
@@ -7,51 +7,51 @@
 #dimensions 0: 640x480
 #sar 0: 1/1
 #stream#, dts,pts, duration, size, hash
-0,  0,  0,1,   460800, 549730883a0b56e6accaf021903daecf
-0,  1,  1,1,   460800, 783389b4342d4be925fc5244791e760a
-0,  2,  2,1,   460800, 8384af6426d94a2077930c93013e09ad
-0,  3,  3,1,   460800, 9380a1d9ecacf5b3105383c1c8083188
-0,  4,  4,1,   460800, eb28174acfceb868b9058757bed049c5
-0,  5,  5,1,   460800, 9732bd4a58884dbf2be48d819433130f
-0,  6,  6,1,   460800, 0c553fb530cf042eb84f5b13817a96a6
-0,  7,  7,1,   460800, 621f02aded5e35fa1f373afd3ed283bd
-0,  8,  8,1,   460800, c76167c6bda91f657708c88252ea315d
-0,  9,  9,1,   460800, 872df2d8c522e2440ddd04bca7dce497
-0, 10, 10,1,   460800, 6ee9154e48c5132ad4ba122b255bd2bb
-0, 11, 11,1,   460800, 362e61629795702ebe9183ce3786d7f2
-0, 12, 12,1,   460800, f3ec59e6fc4e3c2e75f42bef34ca73b5
-0, 13, 13,1,   460800, 68d9caea8697736dd716cba43b614919
-0, 14, 14,1,   460800, 4a4efb0201a64236db4330725758c139
-0, 15, 15,1,   460800, f32f8997dcdd87ad910dea886a0de17d
-0, 16, 16,1,   460800, 51a8549d7b4aaacaf6050bc07a82b440
-0, 17, 17,1,   460800, 5145aa05bbb0c3faab40fc8fa233af1d
-0, 18, 18,1,   460800, bbfcbe3c9600b2a0f413057d7959e9e7
-0, 19, 19,1,   460800, 02cfd4a350fa274e12fce8352001bf21
-0, 20, 20,1,   460800, 20dd372da9e656add433f31e3e9c1fb8
-0, 21, 21,1,   460800, 3b885593f8b42676ce40c329a63f62bf
-0, 22, 22,1,   460800, c38b453b56c3ea14f7d8691d83752486
-0, 23, 23,1,   460800, 79643132988dabc9dc1ba3af0aeaebc5
-0, 24, 24,1,   460800, 60a099be31244b2f69ca6107cdbd7e06
-0, 25, 25,1,   460800, 1de6ff4e0aa81216e4b7b1c8e74fb143
-0, 26, 26,1,   460800, 5223a81e6964c28cf42593f259397aa1
-0, 27, 27,1,   460800, 2dfcf01c86aa712cd6f1c7656eeb17db
-0, 28, 28,1,   460800, 8c86ee0f02fabccaed8d8fc8babd031e
-0, 29, 29,1,   460800, b3ea1983f7efeec11306445d9ae5d477
-0, 30, 30,1,   460800, 86a4cc9fa7db5ff5ca2be69ad191179f
-0, 31, 31,1,   460800, 8194715afe23ae34a019797a53a6ee2c
-0, 32, 32,1,   460800, 447a153f1c6bb703eff62edfd14e08e0
-0, 33, 33,1,   460800, 092257082789b898dbb14d1f19e79347
-0, 34, 34,1,   460800, d6320d204a119cfeef5645a4118bc600
-0, 35, 35,1,   460800, 2ee710deae4bb0d156528797ad1c4981
-0, 36, 36,1,   460800, 1256eac030985c04c4501ad5a72e9d66
-0, 37, 37,1,   460800, f16ad8c1aa572be7666c7907ce4aebbc
-0, 38, 38,1,   460800, 865088cbd47d0151b62a45d5426c8216
-0, 39, 39,1,   460800, 26c78ca43d93c6da153f3dea5d945e0e
-0, 40, 40,1,   460800, d775d6705c965401ccc143d5ae432938
-0, 41, 41,1,   460800, f9837d514753c59e6776452d9043524f
-0, 42, 42,1,   460800, 8463f5172914828abcc770f888bfd183
-0, 43, 43,1,   460800, 3108557748cfb7965b33b16b35359de0
-0, 44, 44,1,   460800, 477d596944e028dd72c207bb6e6b22de
-0, 45, 45,1,   460800, 69e4ffbd600c8d8bc070d7d7324ee2b1
-0, 46, 

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()

[Moritz Barsnick]

On Sun, Oct 29, 2017 at 12:08:05 +0100, Peter Große wrote:
>  } else duration = 1;

For style/readability, the statement should be on a new line, perhaps
even with brackets. (Not necessarily as part of this patch though.)

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

Re: [FFmpeg-devel] [PATCH] avfilter/zscale: add explanation for error 3074

[Moritz Barsnick]

On Sat, Oct 28, 2017 at 20:54:02 -0400, Dxfhgwet wrote:
-av_log(ctx, AV_LOG_ERROR, "code %d: %s\n", err_code, err_msg);
+if (err_code == ZIMG_ERROR_NO_COLORSPACE_CONVERSION) {
+av_log(ctx, AV_LOG_ERROR, "code %d: %s. Try specifying 
matrix/transfer/primaries.\n";
+} else {
+av_log(ctx, AV_LOG_ERROR, "code %d: %s\n", err_code, err_msg);
+}

I didn't try your patch, but I'm extremely sure it doesn't compile. You
forgot a lot of stuff in the first av_log() call line.

Please, when creating a patch:
- branch locally from master
- do your edits
- try to compile
- fix by editing again
- compile
- test your change
- repeat if necessary
- commit locally
- create a patch from this commit with git format-patch
- submit the patch.

And please fix your email address when committing.

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

Re: [FFmpeg-devel] [PATCH] Fix signed integer overflow in mov_write_single_packet Detected with clang and -fsanitize=signed-integer-overflow

[Moritz Barsnick]

On Sat, Oct 28, 2017 at 21:36:10 -0700, Vitaly Buka wrote:
> ping

You didn't respond to Carl Eugen's review.

Furthermore, the second line of your commit message ("Detected...")
should be separated from the first with an empty line.

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

Re: [FFmpeg-devel] [PATCH] avutil/frame: deprecate getters and setters for AVFrame fields

[James Almer]

On 10/28/2017 5:16 AM, Paul B Mahol wrote:
> On 10/28/17, James Almer  wrote:
>> On 10/23/2017 11:13 AM, James Almer wrote:
>>> The fields can be accessed directly, so these are not needed anymore.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavutil/frame.c   |  2 ++
>>>  libavutil/frame.h   | 26 ++
>>>  libavutil/version.h |  3 +++
>>>  3 files changed, 31 insertions(+)
>>>
>>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>>> index 09dd98a6b5..982fbb5c81 100644
>>> --- a/libavutil/frame.c
>>> +++ b/libavutil/frame.c
>>> @@ -31,6 +31,7 @@ static AVFrameSideData *frame_new_side_data(AVFrame
>>> *frame,
>>>  enum AVFrameSideDataType
>>> type,
>>>  AVBufferRef *buf);
>>>
>>> +#if FF_API_FRAME_GET_SET
>>>  MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
>>>  MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
>>>  MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_pos)
>>> @@ -42,6 +43,7 @@ MAKE_ACCESSORS(AVFrame, frame, int,
>>> decode_error_flags)
>>>  MAKE_ACCESSORS(AVFrame, frame, int, pkt_size)
>>>  MAKE_ACCESSORS(AVFrame, frame, enum AVColorSpace, colorspace)
>>>  MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, color_range)
>>> +#endif
>>>
>>>  #define CHECK_CHANNELS_CONSISTENCY(frame) \
>>>  av_assert2(!(frame)->channel_layout || \
>>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>>> index fef558ea2f..0c6aab1c02 100644
>>> --- a/libavutil/frame.h
>>> +++ b/libavutil/frame.h
>>> @@ -565,36 +565,62 @@ typedef struct AVFrame {
>>>   */
>>>  } AVFrame;
>>>
>>> +#if FF_API_FRAME_GET_SET
>>>  /**
>>>   * Accessors for some AVFrame fields. These used to be provided for ABI
>>>   * compatibility, and do not need to be used anymore.
>>>   */
>>> +attribute_deprecated
>>>  int64_t av_frame_get_best_effort_timestamp(const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_best_effort_timestamp(AVFrame *frame, int64_t val);
>>> +attribute_deprecated
>>>  int64_t av_frame_get_pkt_duration (const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_pkt_duration (AVFrame *frame, int64_t val);
>>> +attribute_deprecated
>>>  int64_t av_frame_get_pkt_pos  (const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_pkt_pos  (AVFrame *frame, int64_t val);
>>> +attribute_deprecated
>>>  int64_t av_frame_get_channel_layout   (const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_channel_layout   (AVFrame *frame, int64_t val);
>>> +attribute_deprecated
>>>  int av_frame_get_channels (const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_channels (AVFrame *frame, int val);
>>> +attribute_deprecated
>>>  int av_frame_get_sample_rate  (const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_sample_rate  (AVFrame *frame, int val);
>>> +attribute_deprecated
>>>  AVDictionary *av_frame_get_metadata   (const AVFrame *frame);
>>> +attribute_deprecated
>>>  void  av_frame_set_metadata   (AVFrame *frame, AVDictionary
>>> *val);
>>> +attribute_deprecated
>>>  int av_frame_get_decode_error_flags   (const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_decode_error_flags   (AVFrame *frame, int val);
>>> +attribute_deprecated
>>>  int av_frame_get_pkt_size(const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_pkt_size(AVFrame *frame, int val);
>>>  #if FF_API_FRAME_QP
>>> +attribute_deprecated
>>>  int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type);
>>> +attribute_deprecated
>>>  int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int
>>> type);
>>>  #endif
>>> +attribute_deprecated
>>>  enum AVColorSpace av_frame_get_colorspace(const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_colorspace(AVFrame *frame, enum AVColorSpace val);
>>> +attribute_deprecated
>>>  enum AVColorRange av_frame_get_color_range(const AVFrame *frame);
>>> +attribute_deprecated
>>>  voidav_frame_set_color_range(AVFrame *frame, enum AVColorRange val);
>>> +#endif
>>>
>>>  /**
>>>   * Get the name of a colorspace.
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>> index aa56ad2fbd..7b4ae9beab 100644
>>> --- a/libavutil/version.h
>>> +++ b/libavutil/version.h
>>> @@ -136,6 +136,9 @@
>>>  #ifndef FF_API_CRYPTO_SIZE_T
>>>  #define FF_API_CRYPTO_SIZE_T(LIBAVUTIL_VERSION_MAJOR < 57)
>>>  #endif
>>> +#ifndef FF_API_FRAME_GET_SET
>>> +#define FF_API_FRAME_GET_SET(LIBAVUTIL_VERSION_MAJOR < 57)
>>> +#endif
>>>
>>>
>>>  /**
>>
>> Ping.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> lgtm

Pushed, 

Re: [FFmpeg-devel] [PATCH 1/2] avformat: move public AVStream fields up in the struct

[James Almer]

On 10/28/2017 4:17 AM, Paul B Mahol wrote:
> On 10/23/17, James Almer  wrote:
>> Remove the silly second notice.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/avformat.h | 65
>> ++
>>  1 file changed, 28 insertions(+), 37 deletions(-)
>>
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index ece1b179f3..7594277f06 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -980,6 +980,34 @@ typedef struct AVStream {
>>  int event_flags;
>>  #define AVSTREAM_EVENT_FLAG_METADATA_UPDATED 0x0001 ///< The call resulted
>> in updated metadata.
>>
>> +/**
>> + * Real base framerate of the stream.
>> + * This is the lowest framerate with which all timestamps can be
>> + * represented accurately (it is the least common multiple of all
>> + * framerates in the stream). Note, this value is just a guess!
>> + * For example, if the time base is 1/9 and all frames have either
>> + * approximately 3600 or 1800 timer ticks, then r_frame_rate will be
>> 50/1.
>> + */
>> +AVRational r_frame_rate;
>> +
>> +/**
>> + * String containing paris of key and values describing recommended
>> encoder configuration.
>> + * Paris are separated by ','.
> 
> Pairs

Fixed and pushed. Thanks.
___
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.

[Michael Niedermayer]

On Sat, Oct 28, 2017 at 08:26:16PM +0200, Michael Niedermayer wrote:
> On Thu, Oct 26, 2017 at 08:51:50PM -0700, Sasi Inguva wrote:
> > On Tue, Oct 24, 2017 at 2:48 PM, Michael Niedermayer  > > wrote:
> > 
> > > 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
> > >
> > > Done. Attaching the corrected patch.
> > 
> > >
> > > [...]
> > >
> > > --
> > > 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.
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
> 
> >  libavformat/mov.c   |   21 +-
> >  tests/fate/mov.mak  |4 +
> >  tests/ref/fate/mov-invalid-elst-entry-count |   57 
> > 
> >  3 files changed, 81 insertions(+), 1 deletion(-)
> > c553340f66797876d039f408f83574a40c54d17b  
> > 0001-lavf-mov.c-Fix-parsing-of-edit-list-atoms-with-inval.patch
> > From 188602e662868a79c7f85e9193e9aedc9ba1a170 Mon Sep 17 00:00:00 2001
> > From: Sasi Inguva 
> > Date: Wed, 18 Oct 2017 20:11:16 -0700
> > Subject: [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid 
> > elst
> >  entry count.
> 
> applied

It seems this fails on ARM qemu

TESTmov-invalid-elst-entry-count
--- tests/ref/fate/mov-invalid-elst-entry-count 2017-10-29 13:26:29.180224127 
+0100
+++ tests/data/fate/mov-invalid-elst-entry-count2017-10-29 
13:38:18.536239072 +0100
@@ -8,50 +8,50 @@
 #sar 0: 1/1
 #stream#, dts,pts, duration, size, hash
 0,  0,  0,1,   460800, 549730883a0b56e6accaf021903daecf
-0,  1,  1,

[FFmpeg-devel] [PATCH] libavformat/mov.c: use calculated dts offset when seeking in streams

[Peter Große]

From: Jonas Licht 

Subtract the calculated dts offset from the requested timestamp before
seeking. This fixes an error "Error while filtering: Operation not
permitted" observed with a short file which contains only one key frame
and starts with negative timestamps.

Then, av_index_search_timestamp() returns a valid negative timestamp,
but mov_seek_stream bails out with AVERROR_INVALIDDATA.

Fixes ticket #6139.

Signed-off-by: Jonas Licht 
Signed-off-by: Peter Große 
---

Compared to the other seek results in this test, the values are not
that far off.

 libavformat/mov.c|  6 --
 tests/ref/seek/extra-mp4 | 16 
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2ee67561e4..60a0f4ccf4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6882,10 +6882,12 @@ static int mov_seek_fragment(AVFormatContext *s, 
AVStream *st, int64_t timestamp
 static int mov_seek_stream(AVFormatContext *s, AVStream *st, int64_t 
timestamp, int flags)
 {
 MOVStreamContext *sc = st->priv_data;
-int sample, time_sample;
+int sample, time_sample, ret;
 unsigned int i;
 
-int ret = mov_seek_fragment(s, st, timestamp);
+timestamp -= sc->time_offset;
+
+ret = mov_seek_fragment(s, st, timestamp);
 if (ret < 0)
 return ret;
 
diff --git a/tests/ref/seek/extra-mp4 b/tests/ref/seek/extra-mp4
index c25544c095..c17ce4003c 100644
--- a/tests/ref/seek/extra-mp4
+++ b/tests/ref/seek/extra-mp4
@@ -28,10 +28,10 @@ ret: 0 st: 0 flags:0 dts: 50.63 pts: 50.73 
pos:5926157 size:  13
 ret: 0 st: 0 flags:0 dts: 50.67 pts: 50.67 pos:5927464 size:   
150
 ret: 0 st: 0 flags:0 dts: 50.70 pts: 50.70 pos:5927614 size:   
176
 ret: 0 st:-1 flags:1  ts: 153.470835
-ret: 0 st: 0 flags:1 dts: 153.47 pts: 153.50 pos:15867700 
size: 96169
-ret: 0 st: 0 flags:0 dts: 153.50 pts: 153.53 pos:15963869 
size:   785
-ret: 0 st: 0 flags:0 dts: 153.53 pts: 153.63 pos:15964654 
size:  3135
-ret: 0 st: 0 flags:0 dts: 153.57 pts: 153.57 pos:15967789 
size:   859
+ret: 0 st: 0 flags:1 dts: 151.97 pts: 152.00 pos:15705355 
size:146924
+ret: 0 st: 0 flags:0 dts: 152.00 pts: 152.10 pos:15852279 
size:  1355
+ret: 0 st: 0 flags:0 dts: 152.03 pts: 152.03 pos:15853634 
size:   211
+ret: 0 st: 0 flags:0 dts: 152.07 pts: 152.07 pos:15853845 
size:   217
 ret: 0 st: 0 flags:0  ts: 76.365000
 ret: 0 st: 0 flags:1 dts: 77.83 pts: 77.87 pos:8659657 size: 
41182
 ret: 0 st: 0 flags:0 dts: 77.87 pts: 77.97 pos:8700839 size:  
4197
@@ -83,10 +83,10 @@ ret: 0 st: 0 flags:0 dts: 101.33 pts: 
101.43 pos:11049548 size:
 ret: 0 st: 0 flags:0 dts: 101.37 pts: 101.37 pos:11053072 
size:   562
 ret: 0 st: 0 flags:0 dts: 101.40 pts: 101.40 pos:11053634 
size:   599
 ret: 0 st:-1 flags:0  ts: 25.306672
-ret: 0 st: 0 flags:1 dts: 27.40 pts: 27.43 pos:2674605 
size:127383
-ret: 0 st: 0 flags:0 dts: 27.43 pts: 27.47 pos:2801988 size:   
 68
-ret: 0 st: 0 flags:0 dts: 27.47 pts: 27.50 pos:2802268 size:  
1754
-ret: 0 st: 0 flags:0 dts: 27.50 pts: 27.53 pos:2804022 size:  
4071
+ret: 0 st: 0 flags:1 dts: 25.30 pts: 25.33 pos:2607246 size: 
40273
+ret: 0 st: 0 flags:0 dts: 25.33 pts: 25.43 pos:2647519 size:  
2959
+ret: 0 st: 0 flags:0 dts: 25.37 pts: 25.37 pos:2650478 size:   
197
+ret: 0 st: 0 flags:0 dts: 25.40 pts: 25.40 pos:2650675 size:   
230
 ret: 0 st:-1 flags:1  ts: 128.200839
 ret: 0 st: 0 flags:1 dts: 127.83 pts: 127.87 pos:13514072 
size: 67382
 ret: 0 st: 0 flags:0 dts: 127.87 pts: 127.97 pos:13581454 
size:  2936
-- 
2.13.6

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

[FFmpeg-devel] [PATCH] ffmpeg.c: fix calculation of input file duration in seek_to_start()

[Peter Große]

Fixes looping files without audio or when using stream_copy, where
ist->nb_samples is not set since no decoding is done.

This fixes ticket #5719 and also fixes an endless loop with the sample
in ticket #6139.

Signed-off-by: Peter Große 
---
 fftools/ffmpeg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index cabc6864e7..17b594bac8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4144,9 +4144,9 @@ static int seek_to_start(InputFile *ifile, 
AVFormatContext *is)
 continue;
 } else {
 if (ist->framerate.num) {
-duration = av_rescale_q(1, ist->framerate, ist->st->time_base);
+duration = av_rescale_q(1, av_inv_q(ist->framerate), 
ist->st->time_base);
 } else if (ist->st->avg_frame_rate.num) {
-duration = av_rescale_q(1, ist->st->avg_frame_rate, 
ist->st->time_base);
+duration = av_rescale_q(1, av_inv_q(ist->st->avg_frame_rate), 
ist->st->time_base);
 } else duration = 1;
 }
 if (!ifile->duration)
-- 
2.13.6

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

[FFmpeg-devel] [PATCH] movenc: add m4b to ipod format extensions

[Lukas Stabe]

m4b is commonly used as extension for m4a audiobook files.
The format is exactly the same. The only thing that differs
is the extension.
---
 libavformat/movenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a34987a7dc..a920eb7c8f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6664,7 +6664,7 @@ AVOutputFormat ff_ipod_muxer = {
 .name  = "ipod",
 .long_name = NULL_IF_CONFIG_SMALL("iPod H.264 MP4 (MPEG-4 Part 
14)"),
 .mime_type = "video/mp4",
-.extensions= "m4v,m4a",
+.extensions= "m4v,m4a,m4b",
 .priv_data_size= sizeof(MOVMuxContext),
 .audio_codec   = AV_CODEC_ID_AAC,
 .video_codec   = AV_CODEC_ID_H264,
-- 
2.14.3

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

Re: [FFmpeg-devel] [PATCH] swscale: Reduce verbosity of misalignment reporting

[Henrik Gramner]

On Sun, Oct 22, 2017 at 11:47 AM, Henrik Gramner  wrote:
> It's a bit overzealous to complain about misalignment with AV_LOG_WARNING,
> especially since memory bandwidth is much more likely to be the bottleneck
> compared to data alignment which the user may not even have control over.

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

[FFmpeg-devel] [PATCH] lavf/img2enc: remove redundant option 'updatefirst'

[Gyan Doshi]

'updatefirst' is an undocumented option redundant to older option 'update'.

Since it doesn't serve as a shorthand, this patch removes it.

Regards,
Gyan
From e845a4cc2d885db6bc27e3f69fbd7940b6131f52 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sun, 29 Oct 2017 13:23:18 +0530
Subject: [PATCH] lavf/img2enc: remove redundant option 'updatefirst'

'updatefirst' is an undocumented option redundant to older option 'update'. 
Since it doesn't serve as a shorthand, this patch removes it.
---
 libavformat/img2enc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index d793807b33..7d64659340 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -104,7 +104,7 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
   AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 
0 &&
img->img_number > 1) {
 av_log(s, AV_LOG_ERROR,
-   "Could not get frame filename number %d from pattern '%s' 
(either set updatefirst or use a pattern like %%03d within the filename 
pattern)\n",
+   "Could not get frame filename number %d from pattern '%s' 
(either set update or use a pattern like %%03d within the filename pattern)\n",
img->img_number, img->path);
 return AVERROR(EINVAL);
 }
@@ -203,7 +203,6 @@ static int query_codec(enum AVCodecID id, int 
std_compliance)
 #define OFFSET(x) offsetof(VideoMuxData, x)
 #define ENC AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption muxoptions[] = {
-{ "updatefirst",  "continuously overwrite one file", OFFSET(update),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,   1, ENC },
 { "update",   "continuously overwrite one file", OFFSET(update),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,   1, ENC },
 { "start_number", "set first number in the sequence", OFFSET(img_number), 
AV_OPT_TYPE_INT,  { .i64 = 1 }, 0, INT_MAX, ENC },
 { "strftime", "use strftime for filename", OFFSET(use_strftime),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
-- 
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel