Re: [FFmpeg-devel] [PATCH] avpacket: Set dst->side_data_elems to 0 within av_packet_copy_props.

[wm4]

On Wed, 14 Feb 2018 00:11:32 -0300
James Almer  wrote:

> > ---
> >  libavcodec/avpacket.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index 90b8215928..1a9be60e20 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -571,6 +571,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  dst->flags= src->flags;
> >  dst->stream_index = src->stream_index;
> >  
> > +dst->side_data_elems = 0;
> >  for (i = 0; i < src->side_data_elems; i++) {
> >   enum AVPacketSideDataType type = src->side_data[i].type;
> >   int size  = src->side_data[i].size;
> >   
> 
> Afaik, the intended behavior of this function was to merge the side data
> in dst with that of src, and this patch would break that.
> It's admittedly not really defined and can get confusing, especially
> when the old deprecated API (av_copy_packet, av_copy_packet_side_data,
> av_dup_packet) do seem to just completely overwrite rather than merge.
> 
> IMO, we should first define what should happen with side data in this
> function before we make any further changes to it.

If you ask me, merging the side data is under-defined at best. What
happens if there are side data elements of the same type in src and
dst? It looks like dst currently overwrites src. Does this even make
sense? You could as well argue that src should be preserved (because it
could mean that dst is supposed to provide fallbacks for missing info
in src). So in my opinion, code which requires "merging" needs to be
conscious about the required semantics and is best off doing it
manually.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/aviobuf: zero initialize the AVIOContext in ffio_init_context()

[wm4]

On Tue, 13 Feb 2018 22:27:49 -0300
James Almer  wrote:

> This makes sure no field is ever used uninitialized.
> 
> Signed-off-by: James Almer 
> ---
> I think i prefer this one.
> 
>  libavformat/aviobuf.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 86eb6579f4..d63db3897f 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -87,6 +87,8 @@ int ffio_init_context(AVIOContext *s,
>int (*write_packet)(void *opaque, uint8_t *buf, int 
> buf_size),
>int64_t (*seek)(void *opaque, int64_t offset, int whence))
>  {
> +memset(s, 0, sizeof(AVIOContext));
> +
>  s->buffer  = buffer;
>  s->orig_buffer_size =
>  s->buffer_size = buffer_size;
> @@ -135,7 +137,7 @@ AVIOContext *avio_alloc_context(
>int (*write_packet)(void *opaque, uint8_t *buf, int 
> buf_size),
>int64_t (*seek)(void *opaque, int64_t offset, int whence))
>  {
> -AVIOContext *s = av_mallocz(sizeof(AVIOContext));
> +AVIOContext *s = av_malloc(sizeof(AVIOContext));
>  if (!s)
>  return NULL;
>  ffio_init_context(s, buffer, buffer_size, write_flag, opaque,

There are a lot of calls to ffio_init_context() - is it sure that there
are no fields that must be preserved?

I'd probably prefer "*s = (AVIOContext){0};", but that's just me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: remove unnecessary calls to ff_init_buffer_info()

[wm4]

On Tue, 13 Feb 2018 21:18:00 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
> Tested with FATE using one and four threads, frame and slice.
> 
>  libavcodec/decode.c| 2 --
>  libavcodec/pthread_frame.c | 2 --
>  libavcodec/smvjpegdec.c| 1 -
>  3 files changed, 5 deletions(-)
> 
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 522720c07a..56be9f6064 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1916,8 +1916,6 @@ static int reget_buffer_internal(AVCodecContext *avctx, 
> AVFrame *frame)
>  av_frame_unref(frame);
>  }
>  
> -ff_init_buffer_info(avctx, frame);
> -
>  if (!frame->data[0])
>  return ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF);
>  
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 25aa3e2cd2..5104b1beba 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -886,8 +886,6 @@ static int thread_get_buffer_internal(AVCodecContext 
> *avctx, ThreadFrame *f, int
>  
>  f->owner[0] = f->owner[1] = avctx;
>  
> -ff_init_buffer_info(avctx, f->f);
> -
>  if (!(avctx->active_thread_type & FF_THREAD_FRAME))
>  return ff_get_buffer(avctx, f->f, flags);
>  
> diff --git a/libavcodec/smvjpegdec.c b/libavcodec/smvjpegdec.c
> index 018e135b30..0b05d19f7b 100644
> --- a/libavcodec/smvjpegdec.c
> +++ b/libavcodec/smvjpegdec.c
> @@ -193,7 +193,6 @@ static int smvjpeg_decode_frame(AVCodecContext *avctx, 
> void *data, int *data_siz
>  s->picture[1]->width = avctx->width;
>  s->picture[1]->height= avctx->height;
>  s->picture[1]->format= avctx->pix_fmt;
> -/* ff_init_buffer_info(avctx, >picture[1]); */
>  smv_img_pnt(s->picture[1]->data, mjpeg_data->data, 
> mjpeg_data->linesize,
>  avctx->pix_fmt, avctx->width, avctx->height, cur_frame);
>  for (i = 0; i < AV_NUM_DATA_POINTERS; i++)

Seems like these calls are indeed redundant (and one was commented).
So both patches LGTM. Maybe it'd actually be helpful to squash the two
commits, but no strong opinion. 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: remove av_codec_init_static()

[wm4]

On Wed, 14 Feb 2018 07:07:09 +0700
Muhammad Faiz  wrote:

> On Tue, Feb 13, 2018 at 3:57 AM, wm4  wrote:
> > On Mon, 12 Feb 2018 12:42:10 +0700
> > Muhammad Faiz  wrote:
> >  
> >> Modify the behavior of init_static_data().
> >>
> >> Signed-off-by: Muhammad Faiz 
> >> ---  
> >
> > Seems OK, but I'm also not sure about the benefit. The fundamental
> > problem that these codecs need to mutate AVCodec before the users sees
> > it won't go away.  
> 
> Actually, I'm too. Any idea how to remove init_static_data()?

The only way is to change the API somehow and deprecate
AVCodec.pix_fmts. Or we could define that entries in pix_fmts are not
always available at runtime, but this would still be an API break and
require deprecation and a replacement mechanism. Honestly I'm not
really sure how to do this - maybe the simplest possible replacement
would be fine, like avcodec_get_pix_fmts(AVCodec)?

For now it actually seems less trouble to just leave those maybe 3 or 4
AVCodecs mutable. At least there are no race anymore thanks to
init_once.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mpegenc - accept PCM_DVD streams

[Gyan Doshi]

On 2/14/2018 3:59 AM, Michael Niedermayer wrote:

On Mon, Jan 29, 2018 at 06:53:06PM +0530, Gyan Doshi wrote:


On 1/29/2018 3:47 PM, Carl Eugen Hoyos wrote:


How did you test this patch?


By remuxing with patched ffmpeg and then checking with ffprobe, but not
ffplay!


muxer side changes should be tested against something else than ffmpeg in
general, if possible.
Is there no other software available that supports this ?


Remuxed file plays well with other players like Windows Media Player and 
Potplayer. VLC too, though I'm not sure if it uses lavf demuxer.



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

Re: [FFmpeg-devel] [PATCH] avpacket: Set dst->side_data_elems to 0 within av_packet_copy_props.

[James Almer]

On 2/14/2018 12:22 AM, Yusuke Nakamura wrote:
> 2018-02-14 12:11 GMT+09:00 James Almer :
> 
>> On 2/13/2018 11:43 PM, Yusuke Nakamura wrote:
>>> This makes you need not call av_init_packet before av_packet_copy_props
>> like the following.
>>>
>>> AVPacket dst;
>>> av_packet_copy_props(, );
>>
>> In this scenario, dst->side_data is uninitialized, and bad things can
>> happen when av_packet_copy_props calls av_packet_new_side_data.
>>
>> For something like this, it's best to instead just zero initialize dst.
>> Also, av_packet_init should *always* be called before a packet stored on
>> stack is used, regardless of it being zero initialized or not.
>>
> 
> Ooops! Sorry, originally it is for the case using  av_packet_ref not
> av_packet_copy_props.
> av_packet_ref expects the dst packet is inited by av_packet_init?

It needs to be in a "clean" state, be it because it was just allocated
by av_packet_alloc, or right after having zero initialized it or called
av_packet_init or av_packet_unref, because otherwise dst->buf will be
either uninitialized or wrongly pointing to something (Apparently only
an issue if the source packet is not ref counted, though). Similarly,
what i said above regarding dst->side_data.

> If so, should be documented on
> av_packet_ref docs I think. I'm trapped that.

I don't know if this is the intended behavior, but that's how it
currently works. Maybe that should be fixed rather than the
documentation, after it's properly defined.

> 
> 
>>> ---
>>>  libavcodec/avpacket.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
>>> index 90b8215928..1a9be60e20 100644
>>> --- a/libavcodec/avpacket.c
>>> +++ b/libavcodec/avpacket.c
>>> @@ -571,6 +571,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>>  dst->flags= src->flags;
>>>  dst->stream_index = src->stream_index;
>>>
>>> +dst->side_data_elems = 0;
>>>  for (i = 0; i < src->side_data_elems; i++) {
>>>   enum AVPacketSideDataType type = src->side_data[i].type;
>>>   int size  = src->side_data[i].size;
>>>
>>
>> Afaik, the intended behavior of this function was to merge the side data
>> in dst with that of src, and this patch would break that.
>> It's admittedly not really defined and can get confusing, especially
>> when the old deprecated API (av_copy_packet, av_copy_packet_side_data,
>> av_dup_packet) do seem to just completely overwrite rather than merge.
>>
>> IMO, we should first define what should happen with side data in this
>> function before we make any further changes to it.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] avpacket: Set dst->side_data_elems to 0 within av_packet_copy_props.

[Yusuke Nakamura]

2018-02-14 12:11 GMT+09:00 James Almer :

> On 2/13/2018 11:43 PM, Yusuke Nakamura wrote:
> > This makes you need not call av_init_packet before av_packet_copy_props
> like the following.
> >
> > AVPacket dst;
> > av_packet_copy_props(, );
>
> In this scenario, dst->side_data is uninitialized, and bad things can
> happen when av_packet_copy_props calls av_packet_new_side_data.
>
> For something like this, it's best to instead just zero initialize dst.
> Also, av_packet_init should *always* be called before a packet stored on
> stack is used, regardless of it being zero initialized or not.
>

Ooops! Sorry, originally it is for the case using  av_packet_ref not
av_packet_copy_props.
av_packet_ref expects the dst packet is inited by av_packet_init? If so,
should be documented on
av_packet_ref docs I think. I'm trapped that.


> > ---
> >  libavcodec/avpacket.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index 90b8215928..1a9be60e20 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -571,6 +571,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  dst->flags= src->flags;
> >  dst->stream_index = src->stream_index;
> >
> > +dst->side_data_elems = 0;
> >  for (i = 0; i < src->side_data_elems; i++) {
> >   enum AVPacketSideDataType type = src->side_data[i].type;
> >   int size  = src->side_data[i].size;
> >
>
> Afaik, the intended behavior of this function was to merge the side data
> in dst with that of src, and this patch would break that.
> It's admittedly not really defined and can get confusing, especially
> when the old deprecated API (av_copy_packet, av_copy_packet_side_data,
> av_dup_packet) do seem to just completely overwrite rather than merge.
>
> IMO, we should first define what should happen with side data in this
> function before we make any further changes to it.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avpacket: Set dst->side_data_elems to 0 within av_packet_copy_props.

[James Almer]

On 2/13/2018 11:43 PM, Yusuke Nakamura wrote:
> This makes you need not call av_init_packet before av_packet_copy_props like 
> the following.
> 
> AVPacket dst;
> av_packet_copy_props(, );

In this scenario, dst->side_data is uninitialized, and bad things can
happen when av_packet_copy_props calls av_packet_new_side_data.

For something like this, it's best to instead just zero initialize dst.
Also, av_packet_init should *always* be called before a packet stored on
stack is used, regardless of it being zero initialized or not.

> ---
>  libavcodec/avpacket.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 90b8215928..1a9be60e20 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -571,6 +571,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  dst->flags= src->flags;
>  dst->stream_index = src->stream_index;
>  
> +dst->side_data_elems = 0;
>  for (i = 0; i < src->side_data_elems; i++) {
>   enum AVPacketSideDataType type = src->side_data[i].type;
>   int size  = src->side_data[i].size;
> 

Afaik, the intended behavior of this function was to merge the side data
in dst with that of src, and this patch would break that.
It's admittedly not really defined and can get confusing, especially
when the old deprecated API (av_copy_packet, av_copy_packet_side_data,
av_dup_packet) do seem to just completely overwrite rather than merge.

IMO, we should first define what should happen with side data in this
function before we make any further changes to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avpacket: Set dst->side_data_elems to 0 within av_packet_copy_props.

[Yusuke Nakamura]

This makes you need not call av_init_packet before av_packet_copy_props like 
the following.

AVPacket dst;
av_packet_copy_props(, );
---
 libavcodec/avpacket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 90b8215928..1a9be60e20 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -571,6 +571,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 dst->flags= src->flags;
 dst->stream_index = src->stream_index;
 
+dst->side_data_elems = 0;
 for (i = 0; i < src->side_data_elems; i++) {
  enum AVPacketSideDataType type = src->side_data[i].type;
  int size  = src->side_data[i].size;
-- 
2.16.1.windows.4

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add support for low-power encoding

[Xiang, Haihao]

>-Original Message-
>From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>Mark Thompson
>Sent: Wednesday, February 14, 2018 2:58 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add support
>for low-power encoding
>
>On 09/02/18 01:23, Xiang, Haihao wrote:
>>
>>> On 06/02/18 08:17, Haihao Xiang wrote:
 Although VAEntrypointEncSliceLP was added in old version of VAAPI,
 we never implemented it for VAAPI H265 encoder before. so it is
 reasonable to require VAAPI 1.0

 Signed-off-by: Haihao Xiang 
 ---
  libavcodec/vaapi_encode_h265.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

 diff --git a/libavcodec/vaapi_encode_h265.c
 b/libavcodec/vaapi_encode_h265.c index f3b4f6c7e26..efe1148127f
 100644
 --- a/libavcodec/vaapi_encode_h265.c
 +++ b/libavcodec/vaapi_encode_h265.c
 @@ -65,6 +65,7 @@ typedef struct VAAPIEncodeH265Options {
  int aud;
  int profile;
  int level;
 +int low_power;
  } VAAPIEncodeH265Options;


 @@ -914,7 +915,18 @@ static av_cold int
 vaapi_encode_h265_init(AVCodecContext *avctx)
 avctx->profile);
  return AVERROR(EINVAL);
  }
 -ctx->va_entrypoint = VAEntrypointEncSlice;
 +
 +if (opt->low_power) {
 +#if VA_CHECK_VERSION(1, 0, 0)
 +ctx->va_entrypoint = VAEntrypointEncSliceLP; #else
 +av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
 +   "supported with this VAAPI version.\n");
 +return AVERROR(EINVAL);
 +#endif
 +} else {
 +ctx->va_entrypoint = VAEntrypointEncSlice;
 +}

  if (avctx->bit_rate > 0) {
  if (avctx->rc_max_rate == avctx->bit_rate) @@ -986,6
 +998,10 @@ static const AVOption vaapi_encode_h265_options[] = {
  { LEVEL("6.2", 186) },
  #undef LEVEL

 +{ "low_power", "Use low-power encoding mode (experimental: only
 supported "
>>>
>>> Do you want to copy this comment?
>>>
>>
>> Actually I want to delete the comments in (), but the limitation for
>> HEVC low power encoding still exist. It would be better to add some
>> VAAPI attributes to query the capability/limitation etc.
>>
>>
 +  "on some platforms, does not support all features)",
 +  OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS
 + },
 +
  { NULL },
  };


>>>
>>> How can I test this (and the following patch)?  It doesn't appear to
>>> exist on any current platform/driver.
>>>
>>
>> Cannon Lake support HEVC low power encoding, do you have this
>> platform?  https:/ /github.com/intel/media-driver/ should support this
>> feature but it isn't ready in https://github.com/intel/intel-vaapi-driver.
>
>I do not have any board with this - where can I get one?
>
>>> I don't like how this code is being copied around, but I guess it
>>> would work for now.  I'll look into doing something more sensible here.
>>>
>>
>> I also dislike duplicated code. I wanted to add some common options
>> for VAAPI encoder in FFmpeg, such as QP. However low power encoding is
>> not available for some codecs, such as VP8, so I copied the code
>here.
>>
>> Another thing is a driver may not support both VAEntrypointEncSliceLP
>> and VAEntrypointEncSlice, so I want to change the value range of
>> low_power to -1, 0, 1. -1 means auto mode, FFmpeg-vaapi will select
>> the first applicable entrypoint, what is your comment for this proposal?
>
>Under what circumstances would a driver a provide low-power entrypoint but
>not a standard one?  If some hardware only supports one encoder I would
>expect it to regard that encoder as the standard one.
>

It is up to the driver, HW supports VAEntrypointEncSlice but the driver may not 
implement it. 
Because low-power encoding has some limitations, it will confuse users if 
regarding that encoder
as the standard one. 


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

[FFmpeg-devel] [PATCH] avformat/aviobuf: zero initialize the AVIOContext in ffio_init_context()

[James Almer]

This makes sure no field is ever used uninitialized.

Signed-off-by: James Almer 
---
I think i prefer this one.

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

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 86eb6579f4..d63db3897f 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -87,6 +87,8 @@ int ffio_init_context(AVIOContext *s,
   int (*write_packet)(void *opaque, uint8_t *buf, int 
buf_size),
   int64_t (*seek)(void *opaque, int64_t offset, int whence))
 {
+memset(s, 0, sizeof(AVIOContext));
+
 s->buffer  = buffer;
 s->orig_buffer_size =
 s->buffer_size = buffer_size;
@@ -135,7 +137,7 @@ AVIOContext *avio_alloc_context(
   int (*write_packet)(void *opaque, uint8_t *buf, int 
buf_size),
   int64_t (*seek)(void *opaque, int64_t offset, int whence))
 {
-AVIOContext *s = av_mallocz(sizeof(AVIOContext));
+AVIOContext *s = av_malloc(sizeof(AVIOContext));
 if (!s)
 return NULL;
 ffio_init_context(s, buffer, buffer_size, write_flag, opaque,
-- 
2.16.1

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

[FFmpeg-devel] [PATCH] avformat/aviobuf: initialize all checksum fields

[James Almer]

Calling ffio_ensure_seekback() right after initializing an AVIOContext
with ffio_init_context() would result in a use of uninitialised value.

Fixes fate-adts-id3v2-demux when using valgrind.

Signed-off-by: James Almer 
---
Maybe we should do a memset(s, 0, sizeof(*s)) at the beginning of
ffio_init_context() instead, to effectively initialize every field to
zero. Which is prefered?

 libavformat/aviobuf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 86eb6579f4..a5ce9b9bf2 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -106,6 +106,8 @@ int ffio_init_context(AVIOContext *s,
 s->seekable= seek ? AVIO_SEEKABLE_NORMAL : 0;
 s->min_packet_size = 0;
 s->max_packet_size = 0;
+s->checksum= 0;
+s->checksum_ptr= NULL;
 s->update_checksum = NULL;
 s->short_seek_threshold = SHORT_SEEK_THRESHOLD;
 
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 2/2] avcodec/decode: remove ff_init_buffer_info()

[James Almer]

It's a duplicate function.

This reduces differences with libav.

Signed-off-by: James Almer 
---
 libavcodec/decode.c   | 9 ++---
 libavcodec/internal.h | 6 --
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 56be9f6064..ea2168ad0c 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -130,7 +130,7 @@ static int extract_packet_props(AVCodecInternal *avci, 
const AVPacket *pkt)
 if (pkt) {
 ret = av_packet_copy_props(avci->last_pkt_props, pkt);
 if (!ret)
-avci->last_pkt_props->size = pkt->size; // HACK: Needed for 
ff_init_buffer_info().
+avci->last_pkt_props->size = pkt->size; // HACK: Needed for 
ff_decode_frame_props().
 }
 return ret;
 }
@@ -1661,7 +1661,7 @@ static int add_metadata_from_side_data(const AVPacket 
*avpkt, AVFrame *frame)
 return av_packet_unpack_dictionary(side_metadata, size, frame_md);
 }
 
-int ff_init_buffer_info(AVCodecContext *avctx, AVFrame *frame)
+int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame)
 {
 const AVPacket *pkt = avctx->internal->last_pkt_props;
 int i;
@@ -1769,11 +1769,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return 0;
 }
 
-int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame)
-{
-return ff_init_buffer_info(avctx, frame);
-}
-
 static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame *frame)
 {
 if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 16bd101284..bb92873d7b 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -235,12 +235,6 @@ int ff_match_2uint16(const uint16_t (*tab)[2], int size, 
int a, int b);
 
 unsigned int avpriv_toupper4(unsigned int x);
 
-/**
- * does needed setup of pkt_pts/pos and such for (re)get_buffer();
- */
-int ff_init_buffer_info(AVCodecContext *s, AVFrame *frame);
-
-
 void ff_color_frame(AVFrame *frame, const int color[4]);
 
 /**
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec: remove unnecessary calls to ff_init_buffer_info()

[James Almer]

Signed-off-by: James Almer 
---
Tested with FATE using one and four threads, frame and slice.

 libavcodec/decode.c| 2 --
 libavcodec/pthread_frame.c | 2 --
 libavcodec/smvjpegdec.c| 1 -
 3 files changed, 5 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 522720c07a..56be9f6064 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1916,8 +1916,6 @@ static int reget_buffer_internal(AVCodecContext *avctx, 
AVFrame *frame)
 av_frame_unref(frame);
 }
 
-ff_init_buffer_info(avctx, frame);
-
 if (!frame->data[0])
 return ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF);
 
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 25aa3e2cd2..5104b1beba 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -886,8 +886,6 @@ static int thread_get_buffer_internal(AVCodecContext 
*avctx, ThreadFrame *f, int
 
 f->owner[0] = f->owner[1] = avctx;
 
-ff_init_buffer_info(avctx, f->f);
-
 if (!(avctx->active_thread_type & FF_THREAD_FRAME))
 return ff_get_buffer(avctx, f->f, flags);
 
diff --git a/libavcodec/smvjpegdec.c b/libavcodec/smvjpegdec.c
index 018e135b30..0b05d19f7b 100644
--- a/libavcodec/smvjpegdec.c
+++ b/libavcodec/smvjpegdec.c
@@ -193,7 +193,6 @@ static int smvjpeg_decode_frame(AVCodecContext *avctx, void 
*data, int *data_siz
 s->picture[1]->width = avctx->width;
 s->picture[1]->height= avctx->height;
 s->picture[1]->format= avctx->pix_fmt;
-/* ff_init_buffer_info(avctx, >picture[1]); */
 smv_img_pnt(s->picture[1]->data, mjpeg_data->data, 
mjpeg_data->linesize,
 avctx->pix_fmt, avctx->width, avctx->height, cur_frame);
 for (i = 0; i < AV_NUM_DATA_POINTERS; i++)
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpdec*: Constify all RTPDynamicProtocolHandler

[Carl Eugen Hoyos]

2018-02-14 1:00 GMT+01:00 Muhammad Faiz :
> On Tue, Feb 13, 2018 at 4:22 AM, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch marks the RTPDynamicProtocolHandler as const.
>>
>> Please comment, Carl Eugen
>>
>> From e219322aa7396db6ecb6ab02fd5b42b42271f27f Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Mon, 12 Feb 2018 22:21:06 +0100
>> Subject: [PATCH] lavf/rtpdec*: Constify all RTPDynamicProtocolHandler.
>
>
>> +const extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;
>> +const extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler;
>> +const extern RTPDynamicProtocolHandler ff_vorbis_dynamic_handler;
>> +const extern RTPDynamicProtocolHandler ff_vp8_dynamic_handler;
>> +const extern RTPDynamicProtocolHandler ff_vp9_dynamic_handler;
>
> Cosmetics: probably extern const?
>
> Rest LGTM.

Applied with "extern const".

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

Re: [FFmpeg-devel] Fix stts_data memory allocation

[王消寒]

"unsigned" is perfectly fine. Just trying to be consistent with the line
above.

On Tue, Feb 13, 2018 at 4:06 PM, Carl Eugen Hoyos 
wrote:

> 2018-02-13 23:48 GMT+01:00 Xiaohan Wang (王消寒) :
>
> Thank you for the fix!
> (What's wrong with "unsigned"?)
>
> 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] Fix stts_data memory allocation

[Carl Eugen Hoyos]

2018-02-13 23:48 GMT+01:00 Xiaohan Wang (王消寒) :

Thank you for the fix!
(What's wrong with "unsigned"?)

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpdec*: Constify all RTPDynamicProtocolHandler

[Muhammad Faiz]

On Tue, Feb 13, 2018 at 4:22 AM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch marks the RTPDynamicProtocolHandler as const.
>
> Please comment, Carl Eugen
>
> From e219322aa7396db6ecb6ab02fd5b42b42271f27f Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 12 Feb 2018 22:21:06 +0100
> Subject: [PATCH] lavf/rtpdec*: Constify all RTPDynamicProtocolHandler.


> +const extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vorbis_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vp8_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vp9_dynamic_handler;

Cosmetics: probably extern const?

Rest LGTM.

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove av_codec_init_static()

[Muhammad Faiz]

On Tue, Feb 13, 2018 at 3:57 AM, wm4  wrote:
> On Mon, 12 Feb 2018 12:42:10 +0700
> Muhammad Faiz  wrote:
>
>> Modify the behavior of init_static_data().
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>
> Seems OK, but I'm also not sure about the benefit. The fundamental
> problem that these codecs need to mutate AVCodec before the users sees
> it won't go away.

Actually, I'm too. Any idea how to remove init_static_data()?

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove av_codec_init_static()

[Muhammad Faiz]

On Tue, Feb 13, 2018 at 2:40 AM, James Almer  wrote:
> On 2/12/2018 2:42 AM, Muhammad Faiz wrote:
>> Modify the behavior of init_static_data().
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavcodec/allcodecs.c | 16 
>>  libavcodec/avcodec.h   |  4 +++-
>>  libavcodec/libvpxdec.c | 15 ++-
>>  libavcodec/libvpxenc.c | 15 ++-
>>  libavcodec/libx264.c   | 11 ++-
>>  libavcodec/libx265.c   | 11 ++-
>>  6 files changed, 55 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index 774b78ef09..02910b5594 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -757,24 +757,16 @@ extern AVCodec ff_vp9_vaapi_encoder;
>>
>>  #include "libavcodec/codec_list.c"
>>
>> -static AVOnce av_codec_static_init = AV_ONCE_INIT;
>> -static void av_codec_init_static(void)
>> -{
>> -for (int i = 0; codec_list[i]; i++) {
>> -if (codec_list[i]->init_static_data)
>> -codec_list[i]->init_static_data((AVCodec*)codec_list[i]);
>> -}
>> -}
>> -
>>  const AVCodec *av_codec_iterate(void **opaque)
>>  {
>>  uintptr_t i = (uintptr_t)*opaque;
>>  const AVCodec *c = codec_list[i];
>>
>> -ff_thread_once(_codec_static_init, av_codec_init_static);
>> -
>> -if (c)
>> +if (c) {
>> +if (c->init_static_data)
>> +c->init_static_data();
>>  *opaque = (void*)(i + 1);
>> +}
>>
>>  return c;
>>  }
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index ad0b48a839..d89bf300fc 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3443,8 +3443,10 @@ typedef struct AVCodec {
>>   *
>>   * This is not intended for time consuming operations as it is
>>   * run for every codec regardless of that codec being used.
>> + * This may be called multiple times from different threads, the callee
>> + * has responsibility for thread synchronization.
>>   */
>> -void (*init_static_data)(struct AVCodec *codec);
>> +void (*init_static_data)(void);
>
> What's the benefit of removing the parameter?

It is unused because the callee should use ff_thread_once.


>
>>
>>  int (*init)(AVCodecContext *);
>>  int (*encode_sub)(AVCodecContext *, uint8_t *buf, int buf_size,
>> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
>> index 04f27d3396..f2003b836b 100644
>> --- a/libavcodec/libvpxdec.c
>> +++ b/libavcodec/libvpxdec.c
>> @@ -30,6 +30,7 @@
>>  #include "libavutil/common.h"
>>  #include "libavutil/imgutils.h"
>>  #include "libavutil/intreadwrite.h"
>> +#include "libavutil/thread.h"
>>  #include "avcodec.h"
>>  #include "internal.h"
>>  #include "libvpx.h"
>> @@ -299,6 +300,18 @@ static av_cold int vp9_init(AVCodecContext *avctx)
>>  return vpx_init(avctx, _codec_vp9_dx_algo, 0);
>>  }
>>
>> +static av_cold void vp9_init_static_once(void)
>> +{
>> +extern AVCodec ff_libvpx_vp9_decoder;
>> +ff_vp9_init_static(_libvpx_vp9_decoder);
>> +}
>> +
>> +static av_cold void vp9_init_static(void)
>> +{
>> +static AVOnce once = AV_ONCE_INIT;
>> +ff_thread_once(, vp9_init_static_once);
>> +}
>> +
>>  AVCodec ff_libvpx_vp9_decoder = {
>>  .name   = "libvpx-vp9",
>>  .long_name  = NULL_IF_CONFIG_SMALL("libvpx VP9"),
>> @@ -309,7 +322,7 @@ AVCodec ff_libvpx_vp9_decoder = {
>>  .close  = vpx_free,
>>  .decode = vpx_decode,
>>  .capabilities   = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
>> -.init_static_data = ff_vp9_init_static,
>> +.init_static_data = vp9_init_static,
>
> I think you can remove the init_static_data call to ff_vp9_init_static
> from the decoder altogether. It just sets AVCodec.pix_fmts, which afaics
> is only needed for the encoder.
>
> Doing it would also let us get rid of libvpx.c, as everything there can
> then be moved into libvpxenc.c

It should be in separate patch.


>
>>  .profiles   = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
>>  .wrapper_name   = "libvpx",
>>  };
>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>> index d0bd1e997a..086dd5defa 100644
>> --- a/libavcodec/libvpxenc.c
>> +++ b/libavcodec/libvpxenc.c
>> @@ -39,6 +39,7 @@
>>  #include "libavutil/intreadwrite.h"
>>  #include "libavutil/mathematics.h"
>>  #include "libavutil/opt.h"
>> +#include "libavutil/thread.h"
>>
>>  /**
>>   * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
>> @@ -1209,6 +1210,18 @@ static av_cold int vp9_init(AVCodecContext *avctx)
>>  return vpx_init(avctx, vpx_codec_vp9_cx());
>>  }
>>
>> +static av_cold void vp9_init_static_once(void)
>> +{
>> +extern AVCodec ff_libvpx_vp9_encoder;
>> +ff_vp9_init_static(_libvpx_vp9_encoder);
>> +}
>> +
>> +static av_cold void vp9_init_static(void)
>> +{
>> +static AVOnce once = AV_ONCE_INIT;
>> +ff_thread_once(, vp9_init_static_once);
>> +}
>> +
>>  static const AVClass class_vp9 = {
>>  

Re: [FFmpeg-devel] Abort early on decode_slice error

[Michael Niedermayer]

On Tue, Feb 13, 2018 at 12:24:41PM -0800, Xiaohan Wang (王消寒) wrote:
> New patch as discussed offline:
> 
> 
> 
> On Sat, Feb 3, 2018 at 2:29 AM, Xiaohan Wang (王消寒) 
> wrote:
> 
> >
> >

>  h264_cavlc.c |1 +
>  1 file changed, 1 insertion(+)
> a6bff5246e55cd4a75eff5ccaf5c8ecfd20c1cba  
> 0001-ffmpeg-Set-valid-qscale-value-in-ff_h264_decode_mb_c.patch
> From e8ad6159640c913773583a8b551ecebcff6b9c63 Mon Sep 17 00:00:00 2001
> From: Xiaohan Wang 
> Date: Sat, 3 Feb 2018 01:43:35 -0800
> Subject: [PATCH] ffmpeg: Set valid qscale value in ff_h264_decode_mb_cavlc()
> 
> When ff_h264_decode_mb_cavlc() failed due to wrong sl->qscale values,
> e.g. dquant out of range, set the qscale to be a valid value before
> returning -1 and exiting the function. The qscale value can be used
> later e.g. in loop filter.
> 
> BUG=806122
> ---
>  libavcodec/h264_cavlc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
> index 2421beed9d..a7e60676a0 100644
> --- a/libavcodec/h264_cavlc.c
> +++ b/libavcodec/h264_cavlc.c
> @@ -1110,6 +1110,7 @@ decode_intra_mb:
>  elsesl->qscale -= max_qp+1;
>  if (((unsigned)sl->qscale) > max_qp){
>  av_log(h->avctx, AV_LOG_ERROR, "dquant out of range (%d) at 
> %d %d\n", dquant, sl->mb_x, sl->mb_y);
> +sl->qscale = max_qp;

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] avcodec/h264_cabac: Tighten allowed coeff_abs range

[Michael Niedermayer]

Fixes: integer overflows
Reported-by: "Xiaohan Wang (王消寒)" 

Based on limits in "8.5 Transform coefficient decoding process and picture
construction process prior to deblocking  filter process"
---
 libavcodec/h264_cabac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264_cabac.c b/libavcodec/h264_cabac.c
index ec5fc74b9b..815149a501 100644
--- a/libavcodec/h264_cabac.c
+++ b/libavcodec/h264_cabac.c
@@ -1735,7 +1735,7 @@ decode_cabac_residual_internal(const H264Context *h, 
H264SliceContext *sl,
 \
 if( coeff_abs >= 15 ) { \
 int j = 0; \
-while (get_cabac_bypass(CC) && j < 30) { \
+while (get_cabac_bypass(CC) && j < 16+7) { \
 j++; \
 } \
 \
-- 
2.16.1

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

[FFmpeg-devel] Fix stts_data memory allocation

[王消寒]

From 241d5e45eb8750521d07d07aa55ea637359ab55d Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Tue, 13 Feb 2018 14:45:14 -0800
Subject: [PATCH] ffmpeg: Fix stts_data memory allocation

In this loop, |i| is the "index". And the memory allocated should be at
least the current "count", which is |i + 1|.

BUG=801821
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5adba52e08..1e02ffb445 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2882,7 +2882,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int sample_duration;
 unsigned int sample_count;
-unsigned min_entries = FFMIN(FFMAX(i, 1024 * 1024), entries);
+unsigned int min_entries = FFMIN(FFMAX(i + 1, 1024 * 1024), entries);
 MOVStts *stts_data = av_fast_realloc(sc->stts_data, _size,
  min_entries * sizeof(*sc->stts_data));
 if (!stts_data) {
-- 
2.16.1.291.g4437f3f132-goog

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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mpegenc - accept PCM_DVD streams

[Michael Niedermayer]

On Mon, Jan 29, 2018 at 06:53:06PM +0530, Gyan Doshi wrote:
> 
> On 1/29/2018 3:47 PM, Carl Eugen Hoyos wrote:
> 
> >How did you test this patch?
> 
> By remuxing with patched ffmpeg and then checking with ffprobe, but not
> ffplay!

muxer side changes should be tested against something else than ffmpeg in
general, if possible.
Is there no other software available that supports this ?

That said, i dont see anything wrong with the patch, its more that i dont
feel fully confident about all the PCM variants in mpeg to not miss something 
...

also if someone else feels this patch is ok and wants to apply this without
further tests iam 100% ok with that.


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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mpegenc - accept PCM_DVD streams

[Michael Niedermayer]

On Tue, Feb 13, 2018 at 12:36:15AM +0530, Gyan Doshi wrote:
> 
> On 2/3/2018 3:59 AM, Michael Niedermayer wrote:
> 
> >>Subject: [PATCH v2] avformat/mpegenc - accept PCM_DVD streams
> >>
> >>PCM_S16BE stream packets in MPEG-PS have a 3-byte header
> >>and recognized as PCM_DVD by the demuxer which prevents
> >>their proper remuxing in MPEG-1/2 PS.
> >
> >its probably a good idea to add a fate test for this too.
> >(could be in a seperate patch)
> >
> 
> FATE patch and sample file attached. Sample file should go into (new) mpegps
> directory in suite.
> 
> 
> Regards,
> Gyan

>  Makefile|1 +
>  fate/mpegps.mak |9 +
>  2 files changed, 10 insertions(+)
> 3141a186401509be875d81a64bcaf1bb598e1f65  
> 0001-fate-mpegps-add-fate-test-for-remux-of-16-bit-PCM_DV.patch
> From cbeb8915b4149abfc33936a94c3280cf6872d9e6 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Mon, 12 Feb 2018 23:59:09 +0530
> Subject: [PATCH] fate/mpegps: add fate test for remux of 16-bit PCM_DVD stream
>  in MPEG-PS
> 
> ---
>  tests/Makefile| 1 +
>  tests/fate/mpegps.mak | 9 +
>  2 files changed, 10 insertions(+)
>  create mode 100644 tests/fate/mpegps.mak
> 
> diff --git a/tests/Makefile b/tests/Makefile
> index 327e3f4420..f1ac610454 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -149,6 +149,7 @@ include $(SRC_PATH)/tests/fate/mov.mak
>  include $(SRC_PATH)/tests/fate/mp3.mak
>  include $(SRC_PATH)/tests/fate/mpc.mak
>  include $(SRC_PATH)/tests/fate/mpeg4.mak
> +include $(SRC_PATH)/tests/fate/mpegps.mak
>  include $(SRC_PATH)/tests/fate/mpegts.mak
>  include $(SRC_PATH)/tests/fate/mxf.mak
>  include $(SRC_PATH)/tests/fate/opus.mak
> diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak
> new file mode 100644
> index 00..56a88640bc
> --- /dev/null
> +++ b/tests/fate/mpegps.mak
> @@ -0,0 +1,9 @@
> +# This tests that the mpegps muxer supports a 16-bit pcm_dvd stream in 
> remuxing (-c:a copy)
> +FATE_MPEGPS-$(call DEMMUX, MPEGPS, MPEG1SYSTEM) += fate-mpegps-pcm_dvd-remux
> +fate-mpegps-pcm_dvd-remux: CMD = md5 -i $(TARGET_SAMPLES)/mpegps/pcm_aud.mpg 
> -vn -c copy -fflags +bitexact -f mpeg
> +fate-mpegps-pcm_dvd-remux: CMP = oneline
> +fate-mpegps-pcm_dvd-remux: REF = 28e5de42b1b00d7fa6f98df6a82d122c

testing with framecrc in addition to this might be usefull too
these single line md5s tend to be harder to interpret if they change

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] Abort early on decode_slice error

[王消寒]

New patch as discussed offline:



On Sat, Feb 3, 2018 at 2:29 AM, Xiaohan Wang (王消寒) 
wrote:

>
>
From e8ad6159640c913773583a8b551ecebcff6b9c63 Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Sat, 3 Feb 2018 01:43:35 -0800
Subject: [PATCH] ffmpeg: Set valid qscale value in ff_h264_decode_mb_cavlc()

When ff_h264_decode_mb_cavlc() failed due to wrong sl->qscale values,
e.g. dquant out of range, set the qscale to be a valid value before
returning -1 and exiting the function. The qscale value can be used
later e.g. in loop filter.

BUG=806122
---
 libavcodec/h264_cavlc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index 2421beed9d..a7e60676a0 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
@@ -1110,6 +1110,7 @@ decode_intra_mb:
 elsesl->qscale -= max_qp+1;
 if (((unsigned)sl->qscale) > max_qp){
 av_log(h->avctx, AV_LOG_ERROR, "dquant out of range (%d) at %d %d\n", dquant, sl->mb_x, sl->mb_y);
+sl->qscale = max_qp;
 return -1;
 }
 }
-- 
2.16.0.rc1.238.g530d649a79-goog

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Mark Thompson]

On 13/02/18 18:52, Mark Thompson wrote:
> On 13/02/18 08:24, Haihao Xiang wrote:
>> Recent Intel i965 driver commit strictly disallows application to set
>> unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not used
>> in Intel i965 driver, so application shouldn't pass this value to the
>> driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
>> driver doesn't support any packed header mode, so application also
>> shouldn't pass packed header to driver if a driver returns
>> VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
>> VAConfigAttribEncPackedHeaders set for this case.
>>
>> In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE make
>> thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
>> future. See https://github.com/intel/libva/issues/178 for more information.
>>
>> This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
>>
>> Signed-off-by: Haihao Xiang 
>> ---
>>  libavcodec/vaapi_encode.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index e371f5761ee..1d30aabed40 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -,6 +,10 @@ static av_cold int 
>> vaapi_encode_config_attributes(AVCodecContext *avctx)
>> ctx->va_packed_headers, attr[i].value);
>>  ctx->va_packed_headers &= attr[i].value;
>>  }
>> +
>> +if (!ctx->va_packed_headers)
>> +continue;
>> +
>>  ctx->config_attributes[ctx->nb_config_attributes++] =
>>  (VAConfigAttrib) {
>>  .type  = VAConfigAttribEncPackedHeaders,
>>
> 
> This seems wrong to me: the driver has indicated that packed headers are 
> supported, so the user is providing this attribute to indicate to the driver 
> that they will not use any of them.  Compare the VP8 case, where the driver 
> does not support them and says so - there we correctly don't provide the 
> attribute (though maybe the commentary could be clearer on that).

Right, I hadn't realised you had already made a change so that encoding is 
currently broken.  I've made 
 to revert the 
API/ABI-breaking part of the change.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 1/3] Add libcodec2 en/decoder

[Tomas Härdin]

tis 2018-02-13 klockan 19:02 +0100 skrev Michael Niedermayer:
> On Fri, Jan 12, 2018 at 11:32:30AM +0100, Tomas Härdin wrote:
> > ping?
> 
> breaks the recently (after teh patchset) added fate-codec_desc

Hrm, a good excuse to set up and dig into how FATE works. I want to add
some tests of my own anyway

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/pcm: decrease delay when reading PCM streams.

[Marton Balint]

On Tue, 13 Feb 2018, Philipp M. Scholl wrote:


The blocksize of the PCM decoder is hard-coded. This creates
unnecessary delay when reading low-rate (<100Hz) streams. This creates
issues when multiplexing multiple streams, since other inputs are only
opened/read after a low-rate input block was completely read.

This patch decreases the blocksize for low-rate inputs, so
approximately a block is read every 10ms. This decreases the startup
delay when multiplexing inputs with different rates.


Maybe it's just me, but I'd shoot for at least 40 ms instead of 10 ms, too 
small audio frames are ineffective, and some areas of the code limit the 
number of frames in buffers (e.g.: avfilter), or the number of packets in 
queues (e.g.: muxing queue), so having bigger audio frames by default 
makes it less probable for the user to reach these limits and get strange 
errors.


If you really need smaller frames than 40 ms, then I suggest add a tunable 
parameter for the demuxer.


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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add support for low-power encoding

[Mark Thompson]

On 09/02/18 01:23, Xiang, Haihao wrote:
> 
>> On 06/02/18 08:17, Haihao Xiang wrote:
>>> Although VAEntrypointEncSliceLP was added in old version of VAAPI, we
>>> never implemented it for VAAPI H265 encoder before. so it is reasonable
>>> to require VAAPI 1.0
>>>
>>> Signed-off-by: Haihao Xiang 
>>> ---
>>>  libavcodec/vaapi_encode_h265.c | 18 +-
>>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>>> index f3b4f6c7e26..efe1148127f 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -65,6 +65,7 @@ typedef struct VAAPIEncodeH265Options {
>>>  int aud;
>>>  int profile;
>>>  int level;
>>> +int low_power;
>>>  } VAAPIEncodeH265Options;
>>>  
>>>  
>>> @@ -914,7 +915,18 @@ static av_cold int
>>> vaapi_encode_h265_init(AVCodecContext *avctx)
>>> avctx->profile);
>>>  return AVERROR(EINVAL);
>>>  }
>>> -ctx->va_entrypoint = VAEntrypointEncSlice;
>>> +
>>> +if (opt->low_power) {
>>> +#if VA_CHECK_VERSION(1, 0, 0)
>>> +ctx->va_entrypoint = VAEntrypointEncSliceLP;
>>> +#else
>>> +av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
>>> +   "supported with this VAAPI version.\n");
>>> +return AVERROR(EINVAL);
>>> +#endif
>>> +} else {
>>> +ctx->va_entrypoint = VAEntrypointEncSlice;
>>> +}
>>>  
>>>  if (avctx->bit_rate > 0) {
>>>  if (avctx->rc_max_rate == avctx->bit_rate)
>>> @@ -986,6 +998,10 @@ static const AVOption vaapi_encode_h265_options[] = {
>>>  { LEVEL("6.2", 186) },
>>>  #undef LEVEL
>>>  
>>> +{ "low_power", "Use low-power encoding mode (experimental: only
>>> supported "
>>
>> Do you want to copy this comment?
>>
> 
> Actually I want to delete the comments in (), but the limitation for HEVC low
> power encoding still exist. It would be better to add some VAAPI attributes to
> query the capability/limitation etc.
> 
> 
>>> +  "on some platforms, does not support all features)",
>>> +  OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
>>> +
>>>  { NULL },
>>>  };
>>>  
>>>
>>
>> How can I test this (and the following patch)?  It doesn't appear to exist on
>> any current platform/driver.
>>
> 
> Cannon Lake support HEVC low power encoding, do you have this platform?  
> https:/
> /github.com/intel/media-driver/ should support this feature but it isn't ready
> in https://github.com/intel/intel-vaapi-driver. 

I do not have any board with this - where can I get one?

>> I don't like how this code is being copied around, but I guess it would work
>> for now.  I'll look into doing something more sensible here.
>>
> 
> I also dislike duplicated code. I wanted to add some common options for VAAPI
> encoder in FFmpeg, such as QP. However low power encoding is not available for
> some codecs, such as VP8, so I copied the code here. 
> 
> Another thing is a driver may not support both VAEntrypointEncSliceLP and
> VAEntrypointEncSlice, so I want to change the value range of low_power to -1, 
> 0,
> 1. -1 means auto mode, FFmpeg-vaapi will select the first applicable 
> entrypoint,
> what is your comment for this proposal?

Under what circumstances would a driver a provide low-power entrypoint but not 
a standard one?  If some hardware only supports one encoder I would expect it 
to regard that encoder as the standard one.

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Mark Thompson]

On 13/02/18 08:24, Haihao Xiang wrote:
> Recent Intel i965 driver commit strictly disallows application to set
> unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not used
> in Intel i965 driver, so application shouldn't pass this value to the
> driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
> driver doesn't support any packed header mode, so application also
> shouldn't pass packed header to driver if a driver returns
> VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
> VAConfigAttribEncPackedHeaders set for this case.
> 
> In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE make
> thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
> future. See https://github.com/intel/libva/issues/178 for more information.
> 
> This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/vaapi_encode.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index e371f5761ee..1d30aabed40 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -,6 +,10 @@ static av_cold int 
> vaapi_encode_config_attributes(AVCodecContext *avctx)
> ctx->va_packed_headers, attr[i].value);
>  ctx->va_packed_headers &= attr[i].value;
>  }
> +
> +if (!ctx->va_packed_headers)
> +continue;
> +
>  ctx->config_attributes[ctx->nb_config_attributes++] =
>  (VAConfigAttrib) {
>  .type  = VAConfigAttribEncPackedHeaders,
> 

This seems wrong to me: the driver has indicated that packed headers are 
supported, so the user is providing this attribute to indicate to the driver 
that they will not use any of them.  Compare the VP8 case, where the driver 
does not support them and says so - there we correctly don't provide the 
attribute (though maybe the commentary could be clearer on that).

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

Re: [FFmpeg-devel] [PATCH 1/3] mpegvideo_parser: implement parsing of the picture structure field

[Michael Niedermayer]

On Tue, Feb 13, 2018 at 08:39:09PM +0200, Jan Ekström wrote:
> On Tue, Feb 13, 2018 at 2:13 PM, Michael Niedermayer
>  wrote:
> > ...
> > If there are 2 fields in a packet that can be as 2 field pictures or
> > as a interlaced frame coded in a way thats inseperable. Then you have
> > 2 timestamps really and might have information associated with each
> > field in principle. Our API doesnt have a place to put the information
> > for the 2nd field anywhere. (which is together with picture_structure
> > what i meant with needing a better API ...)
> >
> 
> OK, so they are inseparable? Then it makes sense to pass them
> together. Until now I only had the information that the two pictures
> were in the same PES packet.
> 
> In that case the best thing we can do is set the field order correctly
> for the set by parsing both field pictures' information. I just
> wondered if the two field pictures are separately coded pictures, just
> like with PAFF in AVC or how interlacing is generally done with HEVC
> (which we even decode as separate fields right now).
> 
> Thus, I was just trying to query if the two field pictures were indeed
> two separate images, and thus could be properly tagged and passed
> through, without the latter picture apparently getting ignored. For
> that at this point of time no new APIs would be needed, only work with
> the parser.

interlaced video can be stored in more than one way, either in a inseperable
way or seperable field pictures.

Abother inseparable case is for example H263 PB frames, coding 2 frames
together. 
For all these cases parsers should idealy be able to output information
about both 


> 
> >
> > We have several decoders that can be fed with input at lower granularity
> > like slices since a long time ago. So iam not sure how any "new APIs" are
> > related here
> >
> 
> Yes, although I think the feed/receive APIs make it work both ways
> (you can feed more or receive more).
> 
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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/3] mpegvideo_parser: implement parsing of the picture structure field

[Jan Ekström]

On Tue, Feb 13, 2018 at 2:13 PM, Michael Niedermayer
 wrote:
> ...
> If there are 2 fields in a packet that can be as 2 field pictures or
> as a interlaced frame coded in a way thats inseperable. Then you have
> 2 timestamps really and might have information associated with each
> field in principle. Our API doesnt have a place to put the information
> for the 2nd field anywhere. (which is together with picture_structure
> what i meant with needing a better API ...)
>

OK, so they are inseparable? Then it makes sense to pass them
together. Until now I only had the information that the two pictures
were in the same PES packet.

In that case the best thing we can do is set the field order correctly
for the set by parsing both field pictures' information. I just
wondered if the two field pictures are separately coded pictures, just
like with PAFF in AVC or how interlacing is generally done with HEVC
(which we even decode as separate fields right now).

Thus, I was just trying to query if the two field pictures were indeed
two separate images, and thus could be properly tagged and passed
through, without the latter picture apparently getting ignored. For
that at this point of time no new APIs would be needed, only work with
the parser.

>
> We have several decoders that can be fed with input at lower granularity
> like slices since a long time ago. So iam not sure how any "new APIs" are
> related here
>

Yes, although I think the feed/receive APIs make it work both ways
(you can feed more or receive more).

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

Re: [FFmpeg-devel] [PATCH 1/3] Add libcodec2 en/decoder

[Michael Niedermayer]

On Fri, Jan 12, 2018 at 11:32:30AM +0100, Tomas Härdin wrote:
> ping?

breaks the recently (after teh patchset) added fate-codec_desc

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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

[FFmpeg-devel] [PATCH v3 6/8] lavfi/silencedetect: Fix missing log at eos

[Nicolas Gaullier]

From: nicolas gaullier 

 Fixes ticket #6968

---
 libavfilter/af_silencedetect.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
index 8973049fe5..723136c2a8 100644
--- a/libavfilter/af_silencedetect.c
+++ b/libavfilter/af_silencedetect.c
@@ -41,7 +41,9 @@ typedef struct SilenceDetectContext {
 int independant_channels;   ///< number of entries in following arrays 
(always 1 in mono mode)
 int64_t *nb_null_samples;   ///< (array) current number of continuous zero 
samples
 int64_t *start; ///< (array) if silence is detected, this 
value contains the time of the first zero sample (default/unset = INT64_MIN)
+int64_t frame_end;  ///< pts of the end of the current frame (used 
to compute duration of silence at EOS)
 int last_sample_rate;   ///< last sample rate to check for sample rate 
changes
+AVRational time_base;   ///< time_base
 
 void (*silencedetect)(struct SilenceDetectContext *s, AVFrame *insamples,
   int nb_samples, int64_t nb_samples_notify,
@@ -92,13 +94,16 @@ static av_always_inline void update(SilenceDetectContext 
*s, AVFrame *insamples,
 }
 } else {
 if (s->start[channel] > INT64_MIN) {
-int64_t end_pts = insamples->pts + av_rescale_q(current_sample / 
s->channels,
-(AVRational){ 1, s->last_sample_rate }, time_base);
+int64_t end_pts = insamples ? insamples->pts + 
av_rescale_q(current_sample / s->channels,
+(AVRational){ 1, s->last_sample_rate }, time_base)
+: s->frame_end;
 int64_t duration_ts = end_pts - s->start[channel];
-set_meta(insamples, s->mono ? channel + 1 : 0, "silence_end",
-av_ts2timestr(end_pts, _base));
-set_meta(insamples, s->mono ? channel + 1 : 0, "silence_duration",
-av_ts2timestr(duration_ts, _base));
+if (insamples) {
+set_meta(insamples, s->mono ? channel + 1 : 0, "silence_end",
+av_ts2timestr(end_pts, _base));
+set_meta(insamples, s->mono ? channel + 1 : 0, 
"silence_duration",
+av_ts2timestr(duration_ts, _base));
+}
 if (s->mono)
 av_log(s, AV_LOG_INFO, "channel: %d | ", channel);
 av_log(s, AV_LOG_INFO, "silence_end: %s | silence_duration: %s\n",
@@ -177,6 +182,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 s->nb_null_samples[c] = srate * s->nb_null_samples[c] / 
s->last_sample_rate;
 }
 s->last_sample_rate = srate;
+s->time_base = inlink->time_base;
+s->frame_end = insamples->pts + av_rescale_q(insamples->nb_samples,
+(AVRational){ 1, s->last_sample_rate }, inlink->time_base);
 
 // TODO: document metadata
 s->silencedetect(s, insamples, nb_samples, nb_samples_notify,
@@ -218,6 +226,18 @@ static int query_formats(AVFilterContext *ctx)
 return ff_set_common_samplerates(ctx, formats);
 }
 
+static av_cold void uninit(AVFilterContext *ctx)
+{
+SilenceDetectContext *s = ctx->priv;
+int c;
+
+for (c = 0; c < s->independant_channels; c++)
+if (s->start[c] > INT64_MIN)
+update(s, NULL, 0, c, 0, s->time_base);
+av_freep(>nb_null_samples);
+av_freep(>start);
+}
+
 static const AVFilterPad silencedetect_inputs[] = {
 {
 .name = "default",
@@ -241,6 +261,7 @@ AVFilter ff_af_silencedetect = {
 .description   = NULL_IF_CONFIG_SMALL("Detect silence."),
 .priv_size = sizeof(SilenceDetectContext),
 .query_formats = query_formats,
+.uninit= uninit,
 .inputs= silencedetect_inputs,
 .outputs   = silencedetect_outputs,
 .priv_class= _class,
-- 
2.14.1.windows.1

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

Re: [FFmpeg-devel] [PATCH v2 6/8] avfilter/silencedetect: fix for ticket 6968 Fix missing log of silence_end at end of stream

[Gaullier Nicolas]

> +av_ts2timestr(duration_ts, _base));
   ^ this does not build, 
and looks like a typo

Sorry, this is ugly, I had indeed replaced manually two occurrences 
(s->time_base => _base) at the last minute just before sending the email...
By the way, at the end of this set of patch, I am wondering if a "somewhat 
cosmetic" patch which would now remove some 'time_base' local arguments by 
using the s->time_base from the context would be interesting to have the code 
little more consistent.

I send right now the fixed patch as v3 including carl eugen's feedback on 
commit msg.

Thank you
Nicolas Gaullier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 6/8] avfilter/silencedetect: fix for ticket 6968 Fix missing log of silence_end at end of stream

[Michael Niedermayer]

On Mon, Feb 12, 2018 at 10:48:28AM +0100, Nicolas Gaullier wrote:
> From: nicolas gaullier 
> 
> ---
>  libavfilter/af_silencedetect.c | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
> index 8973049fe5..723136c2a8 100644
> --- a/libavfilter/af_silencedetect.c
> +++ b/libavfilter/af_silencedetect.c
> @@ -41,7 +41,9 @@ typedef struct SilenceDetectContext {
>  int independant_channels;   ///< number of entries in following arrays 
> (always 1 in mono mode)
>  int64_t *nb_null_samples;   ///< (array) current number of continuous 
> zero samples
>  int64_t *start; ///< (array) if silence is detected, this 
> value contains the time of the first zero sample (default/unset = INT64_MIN)
> +int64_t frame_end;  ///< pts of the end of the current frame 
> (used to compute duration of silence at EOS)
>  int last_sample_rate;   ///< last sample rate to check for sample 
> rate changes
> +AVRational time_base;   ///< time_base
>  
>  void (*silencedetect)(struct SilenceDetectContext *s, AVFrame *insamples,
>int nb_samples, int64_t nb_samples_notify,
> @@ -92,13 +94,16 @@ static av_always_inline void update(SilenceDetectContext 
> *s, AVFrame *insamples,
>  }
>  } else {
>  if (s->start[channel] > INT64_MIN) {
> -int64_t end_pts = insamples->pts + av_rescale_q(current_sample / 
> s->channels,
> -(AVRational){ 1, s->last_sample_rate }, time_base);
> +int64_t end_pts = insamples ? insamples->pts + 
> av_rescale_q(current_sample / s->channels,
> +(AVRational){ 1, s->last_sample_rate }, time_base)
> +: s->frame_end;
>  int64_t duration_ts = end_pts - s->start[channel];
> -set_meta(insamples, s->mono ? channel + 1 : 0, "silence_end",
> -av_ts2timestr(end_pts, _base));
> -set_meta(insamples, s->mono ? channel + 1 : 0, 
> "silence_duration",
> -av_ts2timestr(duration_ts, _base));
> +if (insamples) {
> +set_meta(insamples, s->mono ? channel + 1 : 0, "silence_end",

> +av_ts2timestr(end_pts, _base));
> +set_meta(insamples, s->mono ? channel + 1 : 0, 
> "silence_duration",
> +av_ts2timestr(duration_ts, _base));
   ^
this does not build, and looks like a typo

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

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



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

Re: [FFmpeg-devel] [PATCH] avformat/pcm: decrease delay when reading PCM streams.

[Tomas Härdin]

tis 2018-02-13 klockan 15:11 +0100 skrev Philipp M. Scholl:
>  The blocksize of the PCM decoder is hard-coded. This creates
>  unnecessary delay when reading low-rate (<100Hz) streams. This creates
> issues when multiplexing multiple streams, since other inputs are only
> opened/read after a low-rate input block was completely read.
> 
>  This patch decreases the blocksize for low-rate inputs, so
> approximately a block is read every 10ms. This decreases the startup
> delay when multiplexing inputs with different rates.
> 
> > Signed-off-by: Philipp M. Scholl 
> ---
> diff --git a/libavformat/pcm.c b/libavformat/pcm.c
> index 806f91b6b1..f0ea029633 100644
> --- a/libavformat/pcm.c
> +++ b/libavformat/pcm.c
> @@ -24,17 +24,48 @@
>  #include "internal.h"
>  #include "pcm.h"
>  
> -#define RAW_SAMPLES 1024
> +#define RAW_SAMPLES 1024

Please avoid mixing cosmetic and functional changes

> +
> +/*
> + * copied from 
> https://stackoverflow.com/questions/2679815/previous-power-of-2
> + * computes the previous power of two.
> + */

Got any idea what kind of license Hacker's Delight uses?

> +static uint32_t flp2 (uint32_t x)
> +{
> +x = x | (x >> 1);
> +x = x | (x >> 2);
> +x = x | (x >> 4);
> +x = x | (x >> 8);
> +x = x | (x >> 16);
> +x = x - (x >> 1);
> +return x + (x == 0); /* if x is zero, return 1 */
> +}

What's wrong with 1<  
>  int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
>  {
> -int ret, size;
> +int i, ret, strmsize, readsize = INT_MAX;
> +AVCodecParameters *codec;
> +
> + /*
> +  * recompute read size based on sample rate of the inputs, make sure
> +  * to complete a read every 10ms by selecting the smallest sample rate
> +  */
> +for (i=0; i < s->nb_streams; i++) {
> +  codec = s->streams[i]->codecpar;
> +  strmsize = codec->sample_rate / 100 * codec->block_align;

What if sample_rate < 100 Hz?

> +  readsize = FFMIN(readsize, strmsize);
> +}
> +
> +/*
> + * clamp to RAW_SAMPLES if larger, and to previous power of two.
> + */
> +readsize = flp2(FFMIN(readsize,
> +   RAW_SAMPLES * s->streams[0]->codecpar->block_align));

Any particular reason for previous power of two?

>  
> -size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
> -if (size <= 0)
> +if (readsize <= 0)
>  return AVERROR(EINVAL);

Might want to separate this into a check for block_align>0, then
FFMAX(readsize, block_align) so we always get something. That would
take care of the < 100 Hz issue

>  
> -ret= av_get_packet(s->pb, pkt, size);
> +ret = av_get_packet(s->pb, pkt, readsize);

Keeping the name as "size" removes the need for this hunk :)

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/pcm: decrease delay when reading PCM streams.

[Hendrik Leppkes]

On Tue, Feb 13, 2018 at 3:11 PM, Philipp M. Scholl  wrote:
>  The blocksize of the PCM decoder is hard-coded. This creates
>  unnecessary delay when reading low-rate (<100Hz) streams. This creates
> issues when multiplexing multiple streams, since other inputs are only
> opened/read after a low-rate input block was completely read.
>
>  This patch decreases the blocksize for low-rate inputs, so
> approximately a block is read every 10ms. This decreases the startup
> delay when multiplexing inputs with different rates.
>
> Signed-off-by: Philipp M. Scholl 
> ---
>  libavformat/pcm.c   | 41 +++
>  tests/Makefile  |  1 +
>  tests/ref/lavf/ast  |  4 +--
>  tests/ref/lavf/mov  | 24 +-
>  tests/ref/lavf/smjpeg   |  6 ++---
>  tests/ref/lavf/voc  |  4 +--
>  tests/ref/lavf/voc_s16  |  4 +--
>  tests/ref/seek/acodec-pcm-f32be | 54 
> -
>  tests/ref/seek/acodec-pcm-f64be | 54 
> -
>  tests/ref/seek/lavf-alaw| 44 -
>  tests/ref/seek/lavf-au  | 30 +++
>  tests/ref/seek/lavf-mov | 44 -
>  tests/ref/seek/lavf-mulaw   | 44 -
>  tests/ref/seek/lavf-voc | 22 -
>  14 files changed, 204 insertions(+), 172 deletions(-)
>
> diff --git a/libavformat/pcm.c b/libavformat/pcm.c
> index 806f91b6b1..f0ea029633 100644
> --- a/libavformat/pcm.c
> +++ b/libavformat/pcm.c
> @@ -24,17 +24,48 @@
>  #include "internal.h"
>  #include "pcm.h"
>
> -#define RAW_SAMPLES 1024
> +#define RAW_SAMPLES 1024
> +
> +/*
> + * copied from 
> https://stackoverflow.com/questions/2679815/previous-power-of-2
> + * computes the previous power of two.
> + */
> +static uint32_t flp2 (uint32_t x)
> +{
> +x = x | (x >> 1);
> +x = x | (x >> 2);
> +x = x | (x >> 4);
> +x = x | (x >> 8);
> +x = x | (x >> 16);
> +x = x - (x >> 1);
> +return x + (x == 0); /* if x is zero, return 1 */
> +}

I can't comment on the usefulness of the change as a whole, but we
have ff_clz for this.

>
>  int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
>  {
> -int ret, size;
> +int i, ret, strmsize, readsize = INT_MAX;
> +AVCodecParameters *codec;
> +
> + /*
> +  * recompute read size based on sample rate of the inputs, make sure
> +  * to complete a read every 10ms by selecting the smallest sample rate
> +  */
> +for (i=0; i < s->nb_streams; i++) {
> +  codec = s->streams[i]->codecpar;
> +  strmsize = codec->sample_rate / 100 * codec->block_align;
> +  readsize = FFMIN(readsize, strmsize);
> +}
> +
> +/*
> + * clamp to RAW_SAMPLES if larger, and to previous power of two.
> + */
> +readsize = flp2(FFMIN(readsize,
> +   RAW_SAMPLES * s->streams[0]->codecpar->block_align));
>
> -size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
> -if (size <= 0)
> +if (readsize <= 0)
>  return AVERROR(EINVAL);
>
> -ret= av_get_packet(s->pb, pkt, size);
> +ret = av_get_packet(s->pb, pkt, readsize);
>
>  pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
>  pkt->stream_index = 0;
> diff --git a/tests/Makefile b/tests/Makefile
> index 327e3f4420..9df0d7eff9 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -1,3 +1,4 @@
> +PROGSSUF = _g
>  THREADS = 1
>  VREF = tests/vsynth1/00.pgm
>  AREF = tests/data/asynth1.sw
> diff --git a/tests/ref/lavf/ast b/tests/ref/lavf/ast
> index 513c612e76..f01786720d 100644
> --- a/tests/ref/lavf/ast
> +++ b/tests/ref/lavf/ast
> @@ -1,3 +1,3 @@
> -07f5d23aa8bade984034f7005bd72947 *./tests/data/lavf/lavf.ast
> -177872 ./tests/data/lavf/lavf.ast
> +7b3e74233bb7399593316b9fced596fd *./tests/data/lavf/lavf.ast
> +182000 ./tests/data/lavf/lavf.ast
>  ./tests/data/lavf/lavf.ast CRC=0xe61e3bd0
> diff --git a/tests/ref/lavf/mov b/tests/ref/lavf/mov
> index 2e1f24dfc6..57324f73f7 100644
> --- a/tests/ref/lavf/mov
> +++ b/tests/ref/lavf/mov
> @@ -1,15 +1,15 @@
> -a10d50f2679df92264e1fc21cb8be630 *./tests/data/lavf/lavf.mov
> -366449 ./tests/data/lavf/lavf.mov
> -./tests/data/lavf/lavf.mov CRC=0xbb2b949b
> -6258f70f974e3c802e01d02ac33c7bbd *./tests/data/lavf/lavf.mov
> -357539 ./tests/data/lavf/lavf.mov
> -./tests/data/lavf/lavf.mov CRC=0xbb2b949b
> -ba3b8b49e420510a0d417400dbedfc2d *./tests/data/lavf/lavf.mov
> -366621 ./tests/data/lavf/lavf.mov
> -./tests/data/lavf/lavf.mov CRC=0xa9793231
> -fd0e4de8e7f6d0c8c0681d7020f00f50 *./tests/data/lavf/lavf.mov
> -356921 ./tests/data/lavf/lavf.mov
> -./tests/data/lavf/lavf.mov CRC=0xbb2b949b
> +fc5707661e4fbfec0613202feacdc005 *./tests/data/lavf/lavf.mov
> +371609 ./tests/data/lavf/lavf.mov
> +./tests/data/lavf/lavf.mov CRC=0x1e04949b
> +f901c132467eaaa3d0b0620418b8ce54 *./tests/data/lavf/lavf.mov

[FFmpeg-devel] [PATCH] avformat/pcm: decrease delay when reading PCM streams.

[Philipp M. Scholl]

 The blocksize of the PCM decoder is hard-coded. This creates
 unnecessary delay when reading low-rate (<100Hz) streams. This creates
issues when multiplexing multiple streams, since other inputs are only
opened/read after a low-rate input block was completely read.

 This patch decreases the blocksize for low-rate inputs, so
approximately a block is read every 10ms. This decreases the startup
delay when multiplexing inputs with different rates.

Signed-off-by: Philipp M. Scholl 
---
 libavformat/pcm.c   | 41 +++
 tests/Makefile  |  1 +
 tests/ref/lavf/ast  |  4 +--
 tests/ref/lavf/mov  | 24 +-
 tests/ref/lavf/smjpeg   |  6 ++---
 tests/ref/lavf/voc  |  4 +--
 tests/ref/lavf/voc_s16  |  4 +--
 tests/ref/seek/acodec-pcm-f32be | 54 -
 tests/ref/seek/acodec-pcm-f64be | 54 -
 tests/ref/seek/lavf-alaw| 44 -
 tests/ref/seek/lavf-au  | 30 +++
 tests/ref/seek/lavf-mov | 44 -
 tests/ref/seek/lavf-mulaw   | 44 -
 tests/ref/seek/lavf-voc | 22 -
 14 files changed, 204 insertions(+), 172 deletions(-)

diff --git a/libavformat/pcm.c b/libavformat/pcm.c
index 806f91b6b1..f0ea029633 100644
--- a/libavformat/pcm.c
+++ b/libavformat/pcm.c
@@ -24,17 +24,48 @@
 #include "internal.h"
 #include "pcm.h"
 
-#define RAW_SAMPLES 1024
+#define RAW_SAMPLES 1024
+
+/*
+ * copied from https://stackoverflow.com/questions/2679815/previous-power-of-2
+ * computes the previous power of two.
+ */
+static uint32_t flp2 (uint32_t x)
+{
+x = x | (x >> 1);
+x = x | (x >> 2);
+x = x | (x >> 4);
+x = x | (x >> 8);
+x = x | (x >> 16);
+x = x - (x >> 1);
+return x + (x == 0); /* if x is zero, return 1 */
+}
 
 int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
-int ret, size;
+int i, ret, strmsize, readsize = INT_MAX;
+AVCodecParameters *codec;
+
+ /*
+  * recompute read size based on sample rate of the inputs, make sure
+  * to complete a read every 10ms by selecting the smallest sample rate
+  */
+for (i=0; i < s->nb_streams; i++) {
+  codec = s->streams[i]->codecpar;
+  strmsize = codec->sample_rate / 100 * codec->block_align;
+  readsize = FFMIN(readsize, strmsize);
+}
+
+/*
+ * clamp to RAW_SAMPLES if larger, and to previous power of two.
+ */
+readsize = flp2(FFMIN(readsize,
+   RAW_SAMPLES * s->streams[0]->codecpar->block_align));
 
-size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
-if (size <= 0)
+if (readsize <= 0)
 return AVERROR(EINVAL);
 
-ret= av_get_packet(s->pb, pkt, size);
+ret = av_get_packet(s->pb, pkt, readsize);
 
 pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
 pkt->stream_index = 0;
diff --git a/tests/Makefile b/tests/Makefile
index 327e3f4420..9df0d7eff9 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -1,3 +1,4 @@
+PROGSSUF = _g
 THREADS = 1
 VREF = tests/vsynth1/00.pgm
 AREF = tests/data/asynth1.sw
diff --git a/tests/ref/lavf/ast b/tests/ref/lavf/ast
index 513c612e76..f01786720d 100644
--- a/tests/ref/lavf/ast
+++ b/tests/ref/lavf/ast
@@ -1,3 +1,3 @@
-07f5d23aa8bade984034f7005bd72947 *./tests/data/lavf/lavf.ast
-177872 ./tests/data/lavf/lavf.ast
+7b3e74233bb7399593316b9fced596fd *./tests/data/lavf/lavf.ast
+182000 ./tests/data/lavf/lavf.ast
 ./tests/data/lavf/lavf.ast CRC=0xe61e3bd0
diff --git a/tests/ref/lavf/mov b/tests/ref/lavf/mov
index 2e1f24dfc6..57324f73f7 100644
--- a/tests/ref/lavf/mov
+++ b/tests/ref/lavf/mov
@@ -1,15 +1,15 @@
-a10d50f2679df92264e1fc21cb8be630 *./tests/data/lavf/lavf.mov
-366449 ./tests/data/lavf/lavf.mov
-./tests/data/lavf/lavf.mov CRC=0xbb2b949b
-6258f70f974e3c802e01d02ac33c7bbd *./tests/data/lavf/lavf.mov
-357539 ./tests/data/lavf/lavf.mov
-./tests/data/lavf/lavf.mov CRC=0xbb2b949b
-ba3b8b49e420510a0d417400dbedfc2d *./tests/data/lavf/lavf.mov
-366621 ./tests/data/lavf/lavf.mov
-./tests/data/lavf/lavf.mov CRC=0xa9793231
-fd0e4de8e7f6d0c8c0681d7020f00f50 *./tests/data/lavf/lavf.mov
-356921 ./tests/data/lavf/lavf.mov
-./tests/data/lavf/lavf.mov CRC=0xbb2b949b
+fc5707661e4fbfec0613202feacdc005 *./tests/data/lavf/lavf.mov
+371609 ./tests/data/lavf/lavf.mov
+./tests/data/lavf/lavf.mov CRC=0x1e04949b
+f901c132467eaaa3d0b0620418b8ce54 *./tests/data/lavf/lavf.mov
+357443 ./tests/data/lavf/lavf.mov
+./tests/data/lavf/lavf.mov CRC=0x1e04949b
+0cb4720f248243fa7180a83b9aaa96d7 *./tests/data/lavf/lavf.mov
+366489 ./tests/data/lavf/lavf.mov
+./tests/data/lavf/lavf.mov CRC=0x10a43231
+8cd0311e2e080675db3913a312fce2ce *./tests/data/lavf/lavf.mov
+356825 ./tests/data/lavf/lavf.mov
+./tests/data/lavf/lavf.mov CRC=0x1e04949b
 ebca72c186a4f3ba9bb17d9cb5b74fef 

Re: [FFmpeg-devel] [PATCH] libavfilter : cuda linkage changed for vf_scale_cuda & vf_thumbnail_cuda

[Timo Rothenpieler]

On 13.02.2018 12:38, Hendrik Leppkes wrote:
> On Tue, Feb 13, 2018 at 12:31 PM, Roman Arzumanyan
>  wrote:
>> Please find attached the patch that introduces structure to store CUDA 
>> function pointers to be used within scale & thumbnail filters.
>>
> 
> The entire point of our dynlink_cuda.h was to not include the full
> cuda.h, and as such not require having the CUDA SDK installed.
> 
> - Hendrik

agreed.

This would only be interesting if it kept the ability to build without
cuda.h being present. Possibly optionally this would be ok, if the
original features would be kept intact. Then it would only avoid a hard
runtime dependency on the cuda libraries.

Keep in mind that in the not too distant future our cuda/nv header will
move out of the main ffmpeg repository to
http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary

So I'd say it's better to integrate the patch there, possibly
duplicating the dynlink_cuda header into one version that works without
cuda.h and one that uses it to offer a more complete dynloading.



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

Re: [FFmpeg-devel] [PATCH 1/3] Fix computation of vs->start_pos

[Michael Niedermayer]

On Mon, Feb 12, 2018 at 02:23:07PM +0530, Amit Kale wrote:
> Reset vs->start_pos when beginning a new file.
> ---
>  libavformat/hlsenc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index cc13c94e97..9970c4c575 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2227,7 +2227,10 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  ff_format_io_close(s, >out);
>  }
>  ret = hls_append_segment(s, hls, vs, vs->duration, vs->start_pos,
> vs->size);
> -    vs->start_pos = new_start_pos;

This patch is corrupted by a line break

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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/3] mpegvideo_parser: implement parsing of the picture structure field

[Michael Niedermayer]

Hi

On Mon, Feb 12, 2018 at 03:13:46AM +0200, Jan Ekström wrote:
> On Mon, Feb 12, 2018 at 12:23 AM, Michael Niedermayer
>  wrote:
> >
> > I think a better API is needed to export the picture_structure correctly.
> >
> 
> I might be misunderstanding the problem at hand, but I'm not sure if a
> better API is required right now in the sense that if we define that:

> * the demuxer and/or parser should return a decode'able coding unit

> (whether or not it can actually be decoded depends on the state of
> things). In case of field coded pictures this would be one coded
> field, if I understand correctly.

Whats a "decode'able coding unit" ?
A frame ? a field ? a slice ? an access unit ? a group of pictures ?

Should the user be able to choose at which level the parser should
split packets depening on her needs ?

currently and in the past the parser output was what was most convenient
to use for decoders and muxers internally, that was a "frame" when 
everything can be packetized as frames (no unpaired fields) or fields
when unpaired fields where possibly. In almost all parsers thats
also identical to an access unit.

If there are 2 fields in a packet that can be as 2 field pictures or
as a interlaced frame coded in a way thats inseperable. Then you have
2 timestamps really and might have information associated with each
field in principle. Our API doesnt have a place to put the information
for the 2nd field anywhere. (which is together with picture_structure
what i meant with needing a better API ...)

This exists more so if you would split at GOP level or wanted information
about slices from a parser returning fields.
(if a future API would support this)

spliting at slice level is for example usefull for network transmission
so that transmitted units are more aligned to slices.



> * and, if the decoder then needs two coded field pictures to generate
> a combed together "frame" - so be it. The new decoding/encoding APIs
> let you have a non-synchronized amount of input VS output.

We have several decoders that can be fed with input at lower granularity
like slices since a long time ago. So iam not sure how any "new APIs" are
related here


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] libavfilter : cuda linkage changed for vf_scale_cuda & vf_thumbnail_cuda

[Hendrik Leppkes]

On Tue, Feb 13, 2018 at 12:31 PM, Roman Arzumanyan
 wrote:
> Please find attached the patch that introduces structure to store CUDA 
> function pointers to be used within scale & thumbnail filters.
>

The entire point of our dynlink_cuda.h was to not include the full
cuda.h, and as such not require having the CUDA SDK installed.

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

Re: [FFmpeg-devel] fate/exr : add test for ticket 6994 (long name flag)

[Martin Vignali]

2018-02-09 9:22 GMT+01:00 Martin Vignali :

> Hello,
>
> Patch in attach add test for ticket 6994 (flag long name)
>
> Sample can be found here :
> https://we.tl/WBnt10VSA1
>
> and need to be put inside ./fate-suite/exr
>
> Can be test with :
> make fate-exr SAMPLES=fate-suite/
>
>
> Need to be apply after one of the patch in discussion : "lavc/exr: Ignore
> long names flag"
>
>
>
> Ping for upload

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

[FFmpeg-devel] [PATCH] libavfilter : cuda linkage changed for vf_scale_cuda & vf_thumbnail_cuda

[Roman Arzumanyan]

Please find attached the patch that introduces structure to store CUDA function 
pointers to be used within scale & thumbnail filters.

--
BR, Roman Arzumanyan


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-CUDA-linkage-changed-to-dynamic-loading-for-filters.patch
Description: 0001-CUDA-linkage-changed-to-dynamic-loading-for-filters.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Purely synthetic PTS and DTS...

[Tomas Härdin]

sön 2018-02-11 klockan 17:44 -0500 skrev Tony Di Croce:
> I have video frames in a buffer in memory... and I know their frame
> rate
> (and other information like resolution, etc)... I am attempting to
> mux this
> video into an mp4... But I don't know how to set PTS/DTS
> appropriately. I
> have two questions:
> 
> 1) What should I set AVStream->time_base to?
> 2) How do I compute PTS/DTS per frame (given only a framerate)?
> 
> Thanks in advance!

I don't think MP4 allows raw video. You probably mean MOV.

If your framerate is constant then I believe setting time_base to it
and just having PTS increase monotonically from zero is enough (ptr =
0, pts = 1, pts = 2 ...). There may also be some API for this, or lavf
may come up with some PTSes for you if you say AV_NOPTS_VALUE

/Tomas



signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] Add muxer/demuxer for raw codec2 and .c2 files

[Tomas Härdin]

fre 2018-02-09 klockan 11:29 +0100 skrev Carl Eugen Hoyos:
> 2018-01-15 22:36 GMT+01:00 Tomas Härdin :
> 
> > > +if (p->buf[4] >  EXPECTED_CODEC2_MINOR_VERSION) score -=
> > > AVPROBE_SCORE_MAX/5;
> > > +if (p->buf[5] >  AVPRIV_CODEC2_MODE_MAX)score -=
> > > AVPROBE_SCORE_MAX/5;
> > > +if (p->buf[6] != 0) score -=
> > > AVPROBE_SCORE_MAX/5;
> > > +return score;
> > > 
> > > Imo, this is too complicated:
> > > If the first 32bit are correct, return MAX/2, for 24bit, return
> > > less
> 
> This should have been AVPROBE_SCORE_EXTENSION + 1,
> sorry about my mistake.

Done.

> Please threaten to push this and push after a few days.

Alright, rebased. I'll push on Sunday if there's no objections

/TomasFrom 454d629bde4f167ad16b735956371f3980ce0e92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Tue, 8 Aug 2017 15:27:27 +0200
Subject: [PATCH 1/4] Add libcodec2 en/decoder

---
 Changelog|   1 +
 configure|   5 ++
 doc/general.texi |  20 +
 libavcodec/Makefile  |   2 +
 libavcodec/allcodecs.c   |   2 +
 libavcodec/avcodec.h |   1 +
 libavcodec/codec2utils.c |  80 ++
 libavcodec/codec2utils.h |  82 ++
 libavcodec/codec_desc.c  |   7 ++
 libavcodec/libcodec2.c   | 213 +++
 libavcodec/version.h |   4 +-
 11 files changed, 415 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/codec2utils.c
 create mode 100644 libavcodec/codec2utils.h
 create mode 100644 libavcodec/libcodec2.c

diff --git a/Changelog b/Changelog
index 2acdbbea30..4ca137c0ce 100644
--- a/Changelog
+++ b/Changelog
@@ -39,6 +39,7 @@ version :
 - Removed the ffmenc and ffmdec muxer and demuxer
 - VideoToolbox HEVC encoder and hwaccel
 - VAAPI-accelerated ProcAmp (color balance), denoise and sharpness filters
+- codec2 en/decoding via libcodec2
 
 
 version 3.4:
diff --git a/configure b/configure
index 99c53d482a..cad9d35457 100755
--- a/configure
+++ b/configure
@@ -224,6 +224,7 @@ External library support:
   --enable-libcaca enable textual display using libcaca [no]
   --enable-libcelt enable CELT decoding via libcelt [no]
   --enable-libcdio enable audio CD grabbing with libcdio [no]
+  --enable-libcodec2   enable codec2 en/decoding using libcodec2 [no]
   --enable-libdc1394   enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
   --enable-libfdk-aac  enable AAC de/encoding via libfdk-aac [no]
@@ -1603,6 +1604,7 @@ EXTERNAL_LIBRARY_LIST="
 libbs2b
 libcaca
 libcelt
+libcodec2
 libdc1394
 libdrm
 libflite
@@ -2940,6 +2942,8 @@ h264_videotoolbox_encoder_select="videotoolbox_encoder"
 hevc_videotoolbox_encoder_deps="pthreads"
 hevc_videotoolbox_encoder_select="videotoolbox_encoder"
 libcelt_decoder_deps="libcelt"
+libcodec2_decoder_deps="libcodec2"
+libcodec2_encoder_deps="libcodec2"
 libfdk_aac_decoder_deps="libfdk_aac"
 libfdk_aac_encoder_deps="libfdk_aac"
 libfdk_aac_encoder_select="audio_frame_queue"
@@ -5865,6 +5869,7 @@ enabled libcelt   && require libcelt celt/celt.h celt_decode -lcelt0 &&
  { check_lib libcelt celt/celt.h celt_decoder_create_custom -lcelt0 ||
die "ERROR: libcelt must be installed and version must be >= 0.11.0."; }
 enabled libcaca   && require_pkg_config libcaca caca caca.h caca_create_canvas
+enabled libcodec2 && require libcodec2 codec2/codec2.h codec2_create -lcodec2
 enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2 dc1394/dc1394.h dc1394_new
 enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h drmGetVersion
 enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac "fdk-aac/aacenc_lib.h" aacEncOpen ||
diff --git a/doc/general.texi b/doc/general.texi
index 9ddcccf041..63722f272d 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -85,6 +85,24 @@ Go to @url{http://www.twolame.org/} and follow the
 instructions for installing the library.
 Then pass @code{--enable-libtwolame} to configure to enable it.
 
+@section libcodec2 / codec2 general
+
+FFmpeg can make use of libcodec2 for codec2 encoding and decoding.
+There is currently no native decoder, so libcodec2 must be used for decoding.
+
+Go to @url{http://freedv.org/}, download "Codec 2 source archive".
+Build and install using CMake. Debian users can install the libcodec2-dev package instead.
+Once libcodec2 is installed you can pass @code{--enable-libcodec2} to configure to enable it.
+
+The easiest way to use codec2 is with .c2 files, since they contain the mode information required for decoding.
+To encode such a file, use a .c2 file extension and give the libcodec2 encoder the -mode option:
+@code{ffmpeg -i input.wav -mode 700C output.c2}.
+Playback is as simple as @code{ffplay 

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add support for low-power encoding

[Xiang, Haihao]

> > On 06/02/18 08:17, Haihao Xiang wrote:
> > > Although VAEntrypointEncSliceLP was added in old version of VAAPI, we
> > > never implemented it for VAAPI H265 encoder before. so it is reasonable
> > > to require VAAPI 1.0
> > > 
> > > Signed-off-by: Haihao Xiang 
> > > ---
> > >  libavcodec/vaapi_encode_h265.c | 18 +-
> > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > b/libavcodec/vaapi_encode_h265.c
> > > index f3b4f6c7e26..efe1148127f 100644
> > > --- a/libavcodec/vaapi_encode_h265.c
> > > +++ b/libavcodec/vaapi_encode_h265.c
> > > @@ -65,6 +65,7 @@ typedef struct VAAPIEncodeH265Options {
> > >  int aud;
> > >  int profile;
> > >  int level;
> > > +int low_power;
> > >  } VAAPIEncodeH265Options;
> > >  
> > >  
> > > @@ -914,7 +915,18 @@ static av_cold int
> > > vaapi_encode_h265_init(AVCodecContext *avctx)
> > > avctx->profile);
> > >  return AVERROR(EINVAL);
> > >  }
> > > -ctx->va_entrypoint = VAEntrypointEncSlice;
> > > +
> > > +if (opt->low_power) {
> > > +#if VA_CHECK_VERSION(1, 0, 0)
> > > +ctx->va_entrypoint = VAEntrypointEncSliceLP;
> > > +#else
> > > +av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
> > > +   "supported with this VAAPI version.\n");
> > > +return AVERROR(EINVAL);
> > > +#endif
> > > +} else {
> > > +ctx->va_entrypoint = VAEntrypointEncSlice;
> > > +}
> > >  
> > >  if (avctx->bit_rate > 0) {
> > >  if (avctx->rc_max_rate == avctx->bit_rate)
> > > @@ -986,6 +998,10 @@ static const AVOption vaapi_encode_h265_options[] = {
> > >  { LEVEL("6.2", 186) },
> > >  #undef LEVEL
> > >  
> > > +{ "low_power", "Use low-power encoding mode (experimental: only
> > > supported "
> > 
> > Do you want to copy this comment?
> > 
> 
> Actually I want to delete the comments in (), but the limitation for HEVC low
> power encoding still exist. It would be better to add some VAAPI attributes to
> query the capability/limitation etc.
> 
> 
> > > +  "on some platforms, does not support all features)",
> > > +  OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
> > > +
> > >  { NULL },
> > >  };
> > >  
> > > 
> > 
> > How can I test this (and the following patch)?  It doesn't appear to exist
> > on
> > any current platform/driver.
> > 
> 
> Cannon Lake support HEVC low power encoding, do you have this
> platform?  https:/
> /github.com/intel/media-driver/ should support this feature but it isn't ready
> in https://github.com/intel/intel-vaapi-driver. 
> 
> > I don't like how this code is being copied around, but I guess it would work
> > for now.  I'll look into doing something more sensible here.
> > 
> 
> I also dislike duplicated code. I wanted to add some common options for VAAPI
> encoder in FFmpeg, such as QP. However low power encoding is not available for
> some codecs, such as VP8, so I copied the code here. 
> 
> Another thing is a driver may not support both VAEntrypointEncSliceLP and
> VAEntrypointEncSlice, so I want to change the value range of low_power to -1,
> 0,
> 1. -1 means auto mode, FFmpeg-vaapi will select the first applicable
> entrypoint,
> what is your comment for this proposal?

Hi Mark,

Do you have any comment to the above proposal? https://github.com/xhaihao/media-
driver only supports VAEntrypointEncSliceLP for vp9 on Cannonlake. With the
above proposal, the end user doesn't need to know which entrypoint is supported
by the underly driver. 

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Haihao Xiang]

Recent Intel i965 driver commit strictly disallows application to set
unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not used
in Intel i965 driver, so application shouldn't pass this value to the
driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
driver doesn't support any packed header mode, so application also
shouldn't pass packed header to driver if a driver returns
VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
VAConfigAttribEncPackedHeaders set for this case.

In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE make
thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
future. See https://github.com/intel/libva/issues/178 for more information.

This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index e371f5761ee..1d30aabed40 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -,6 +,10 @@ static av_cold int 
vaapi_encode_config_attributes(AVCodecContext *avctx)
ctx->va_packed_headers, attr[i].value);
 ctx->va_packed_headers &= attr[i].value;
 }
+
+if (!ctx->va_packed_headers)
+continue;
+
 ctx->config_attributes[ctx->nb_config_attributes++] =
 (VAConfigAttrib) {
 .type  = VAConfigAttribEncPackedHeaders,
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: Return AVERROR(ENOSYS)

[Haihao Xiang]

The corresponding feature is not implemented for old versions of
VA-API, the returned value should be AVERROR(ENOSYS)

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index a7f9a602533..6e2db4af070 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -942,7 +942,7 @@ static av_cold int vaapi_encode_h264_init(AVCodecContext 
*avctx)
 #else
 av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
"supported with this VAAPI version.\n");
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
 #endif
 } else {
 ctx->va_entrypoint = VAEntrypointEncSlice;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove Libav ABI compatibility hacks

[Hendrik Leppkes]

On Tue, Feb 13, 2018 at 6:45 AM, wm4  wrote:
> On Tue, 13 Feb 2018 02:04:18 -0300
> James Almer  wrote:
>
>> On 2/13/2018 1:50 AM, wm4 wrote:
>> > On Tue, 13 Feb 2018 01:44:22 -0300
>> > James Almer  wrote:
>> >
>> >> On 2/13/2018 1:33 AM, wm4 wrote:
>> >>> ---
>> >>> If anyone knows of similar still remaining cases in the codebase, please
>> >>> tell me, and I'll send patches.
>> >>> ---
>> >>>  libavcodec/avcodec.h | 49 
>> >>> -
>> >>>  libavcodec/utils.c   |  5 -
>> >>>  libavcodec/version.h |  2 +-
>> >>>  3 files changed, 17 insertions(+), 39 deletions(-)
>> >>>
>> >>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> >>> index bc0eacd66b..b3dad5d614 100644
>> >>> --- a/libavcodec/avcodec.h
>> >>> +++ b/libavcodec/avcodec.h
>> >>> @@ -409,8 +409,7 @@ enum AVCodecID {
>> >>>  AV_CODEC_ID_DXV,
>> >>>  AV_CODEC_ID_SCREENPRESSO,
>> >>>  AV_CODEC_ID_RSCC,
>> >>> -
>> >>> -AV_CODEC_ID_Y41P = 0x8000,
>> >>> +AV_CODEC_ID_Y41P,
>> >>>  AV_CODEC_ID_AVRP,
>> >>>  AV_CODEC_ID_012V,
>> >>>  AV_CODEC_ID_AVUI,
>> >>> @@ -480,14 +479,11 @@ enum AVCodecID {
>> >>>  AV_CODEC_ID_PCM_S24LE_PLANAR,
>> >>>  AV_CODEC_ID_PCM_S32LE_PLANAR,
>> >>>  AV_CODEC_ID_PCM_S16BE_PLANAR,
>> >>> -
>> >>> -AV_CODEC_ID_PCM_S64LE = 0x10800,
>> >>> +AV_CODEC_ID_PCM_S64LE,
>> >>>  AV_CODEC_ID_PCM_S64BE,
>> >>>  AV_CODEC_ID_PCM_F16LE,
>> >>>  AV_CODEC_ID_PCM_F24LE,
>> >>> -
>> >>> -/* various ADPCM codecs */
>> >>> -AV_CODEC_ID_ADPCM_IMA_QT = 0x11000,
>> >>> +AV_CODEC_ID_ADPCM_IMA_QT,
>> >>
>> >> This is not an ABI compat offset. It's to separate PCM from ADPCM
>> >> codecs. It's also in libav's avcodec.h
>> >
>> > I could reword the commit message. Unless you argue we should keep the
>> > codec "categorization"; in that case entire patch dropped.
>>
>> I'd rather keep them, yes. At any point we could add any of the missing
>> PCM codecs, or new ADPCM codecs, just to give an example, and these
>> offsets will prevent having to dump them at the bottom of the list.
>
> I also removed the comments and empty lines that indicate the
> sectioning, so new codecs would always be appended at the end of the
> list of each codec type.
>

I like the sectioning as well, it keeps similar codecs grouped
together and there is no real practical improvement to get rid of them
either way.

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