[FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Michael Niedermayer]

This gives libavcodec a field that it can freely and safely use.
Avoiding the need of wraping of a users opaque_ref field and its issues.

Signed-off-by: Michael Niedermayer 
---
 libavutil/frame.c |  8 +++-
 libavutil/frame.h | 10 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 982fbb5c81..6ddaef1e74 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
 av_buffer_unref(&dst->opaque_ref);
+av_buffer_unref(&dst->avcodec_private_ref);
 if (src->opaque_ref) {
 dst->opaque_ref = av_buffer_ref(src->opaque_ref);
 if (!dst->opaque_ref)
 return AVERROR(ENOMEM);
 }
-
+if (src->avcodec_private_ref) {
+dst->avcodec_private_ref = av_buffer_ref(src->avcodec_private_ref);
+if (!dst->avcodec_private_ref)
+return AVERROR(ENOMEM);
+}
 return 0;
 }
 
@@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
 av_buffer_unref(&frame->hw_frames_ctx);
 
 av_buffer_unref(&frame->opaque_ref);
+av_buffer_unref(&frame->avcodec_private_ref);
 
 get_frame_defaults(frame);
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 0c6aab1c02..73b7d949a9 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -563,6 +563,16 @@ typedef struct AVFrame {
 /**
  * @}
  */
+/**
+ * AVBufferRef for free use by libavcodec. Code outside avcodec will never
+ * check or change the contents of the buffer ref. FFmpeg calls
+ * av_buffer_unref() on it when the frame is unreferenced.
+ * av_frame_copy_props() calls create a new reference with av_buffer_ref()
+ * for the target frame's avcodec_private_ref field.
+ *
+ * avcodec should never assign mutually incompatible types to this field.
+ */
+AVBufferRef *avcodec_private_ref;
 } AVFrame;
 
 #if FF_API_FRAME_GET_SET
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[James Almer]

On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
> This gives libavcodec a field that it can freely and safely use.
> Avoiding the need of wraping of a users opaque_ref field and its issues.

Could this perhaps be in an opaque internal struct instead, much like
AVCodecInternal and whatnot? As wm4 said in the relevant discussion,
this approach is nonoptimal and *will* snowball into a mess of fields if
other libav* libraries start requiring their own buffers in a frame.
An internal field of an opaque struct being in a public header is much
cleaner and easier to maintain than adding such specific fields that may
at some point in the future need to be removed.

No actual comments about the approach in question to solve the issue.
Will leave that to someone more knowledgeable. But at least I'm glad
something is being done about it.

> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/frame.c |  8 +++-
>  libavutil/frame.h | 10 ++
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 982fbb5c81..6ddaef1e74 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  
>  av_buffer_unref(&dst->opaque_ref);
> +av_buffer_unref(&dst->avcodec_private_ref);
>  if (src->opaque_ref) {
>  dst->opaque_ref = av_buffer_ref(src->opaque_ref);
>  if (!dst->opaque_ref)
>  return AVERROR(ENOMEM);
>  }
> -
> +if (src->avcodec_private_ref) {
> +dst->avcodec_private_ref = av_buffer_ref(src->avcodec_private_ref);
> +if (!dst->avcodec_private_ref)
> +return AVERROR(ENOMEM);
> +}
>  return 0;
>  }
>  
> @@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
>  av_buffer_unref(&frame->hw_frames_ctx);
>  
>  av_buffer_unref(&frame->opaque_ref);
> +av_buffer_unref(&frame->avcodec_private_ref);
>  
>  get_frame_defaults(frame);
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 0c6aab1c02..73b7d949a9 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -563,6 +563,16 @@ typedef struct AVFrame {
>  /**
>   * @}
>   */
> +/**
> + * AVBufferRef for free use by libavcodec. Code outside avcodec will 
> never
> + * check or change the contents of the buffer ref. FFmpeg calls
> + * av_buffer_unref() on it when the frame is unreferenced.
> + * av_frame_copy_props() calls create a new reference with 
> av_buffer_ref()
> + * for the target frame's avcodec_private_ref field.
> + *
> + * avcodec should never assign mutually incompatible types to this field.
> + */
> +AVBufferRef *avcodec_private_ref;
>  } AVFrame;
>  
>  #if FF_API_FRAME_GET_SET
> 

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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Hendrik Leppkes]

On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
 wrote:
> This gives libavcodec a field that it can freely and safely use.
> Avoiding the need of wraping of a users opaque_ref field and its issues.
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/frame.c |  8 +++-
>  libavutil/frame.h | 10 ++
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 982fbb5c81..6ddaef1e74 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>
>  av_buffer_unref(&dst->opaque_ref);
> +av_buffer_unref(&dst->avcodec_private_ref);
>  if (src->opaque_ref) {
>  dst->opaque_ref = av_buffer_ref(src->opaque_ref);
>  if (!dst->opaque_ref)
>  return AVERROR(ENOMEM);
>  }
> -
> +if (src->avcodec_private_ref) {
> +dst->avcodec_private_ref = av_buffer_ref(src->avcodec_private_ref);
> +if (!dst->avcodec_private_ref)
> +return AVERROR(ENOMEM);
> +}
>  return 0;
>  }
>
> @@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
>  av_buffer_unref(&frame->hw_frames_ctx);
>
>  av_buffer_unref(&frame->opaque_ref);
> +av_buffer_unref(&frame->avcodec_private_ref);
>
>  get_frame_defaults(frame);
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 0c6aab1c02..73b7d949a9 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -563,6 +563,16 @@ typedef struct AVFrame {
>  /**
>   * @}
>   */
> +/**
> + * AVBufferRef for free use by libavcodec. Code outside avcodec will 
> never
> + * check or change the contents of the buffer ref. FFmpeg calls
> + * av_buffer_unref() on it when the frame is unreferenced.
> + * av_frame_copy_props() calls create a new reference with 
> av_buffer_ref()
> + * for the target frame's avcodec_private_ref field.
> + *
> + * avcodec should never assign mutually incompatible types to this field.
> + */
> +AVBufferRef *avcodec_private_ref;
>  } AVFrame;
>
>  #if FF_API_FRAME_GET_SET

I would prefer if this field would not be library-specific, but
perhaps just "private_ref" which is not allowed to be touched by
users, and documented to only be valid while within one library - ie.
if you pass a frame from avcodec to avfilter, avfilter could take over
the field (and just free any info, if its still in there).
This would avoid any chances of adding a multitude of fields later,
and a single AVFrame instance is not going to be used in multiple
libraries at the same time anyway (the contents might, but not the
actual AVFrame struct)

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 30/10/17 19:51, Mark Thompson wrote:
> 
> Hi all,
> 
> The recent submission of AMD AMF patches including a builtin header prompted 
> me to think further about what external API headers should actually be 
> included in the tree.
> 
> For the AMD headers (like V4L2 previously), it seems entirely silly to 
> include them - they are available upstream in a free form which can easily be 
> packaged and available on any build machine to use.
> 
> However, there is the problem that this in some sense places them 
> second-class to the Nvidia implementation, which includes all headers in-tree 
> and automatically enables itself - any normal build for x86 will include 
> Nvidia support by default if the user doesn't explicitly disable it.  The 
> effect of that is essentially that the ffmpeg project is facilitating 
> Nvidia's anti-open behaviour by including the headers, which is I think 
> something we really shouldn't be doing.
> 
> So: can we please precisely codify under what circumstances external headers 
> should be included in the ffmpeg tree?
> 
> As an initial position for consideration, I propose "no external headers may 
> be included in the ffmpeg tree".  That is, the contents of the compat/ 
> directory should only be OS/compiler compatibility workarounds, not any 
> functional headers.
> 
> Would anyone like to propose an alternative position?  (Precisely defined - 
> "what we have now" would need some clarification of what that actually means 
> so that we can apply it consistently to future requests.)
> 
> I also ask that, whatever discussion here ends up with, the voting committee 
> should vote to ratify it so that we don't have to discuss it again every time 
> someone proposes including headers.

No alternatives were proposed, so I would like to call a vote on adopting the 
following clear policy:

"No external headers may be included in the ffmpeg tree."

(A corresponding documentation change is below, which tries to cover the 
related packaging point.)

Does anybody want to offer any other options to vote on?  I suggest starting 
the vote tomorrow, to run for one week.

Thanks,

- Mark


diff --git a/doc/developer.texi b/doc/developer.texi
index a7b4f1d737..3aeb727729 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -381,6 +381,15 @@ Never write to unallocated memory, never write over the 
end of arrays,
 always check values read from some untrusted source before using them
 as array index or other risky things.
 
+@subheading External headers
+Do not include external headers directly in FFmpeg.  Most packages provide
+suitable headers and linkable libraries when installed, and these should be
+used.  References to external packages in configure should use pkg-config
+if possible to find paths and options - ad-hoc build tests with hard-coded
+paths are to be avoided, but can be used if there is no other possibility.
+If an external package does not provide usable headers or libraries then
+please add directions for how to use it to the documentation.
+
 @subsection Documentation/Other
 @subheading Subscribe to the ffmpeg-cvslog mailing list.
 It is important to do this as the diffs of all commits are sent there and
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Michael Niedermayer]

On Sun, Nov 05, 2017 at 10:35:06AM -0300, James Almer wrote:
> On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
> > This gives libavcodec a field that it can freely and safely use.
> > Avoiding the need of wraping of a users opaque_ref field and its issues.
> 
> Could this perhaps be in an opaque internal struct instead, much like
> AVCodecInternal and whatnot?

We could do a AVFrameInternal but that would require some differenecs
to AVCodecInternal.

The AVBufferRef from the patch has its own reference counting and
destruction callback. (which avcodec can use for cleaning it up)

a straight AVFrameInternal (in AVCodecInternal style) would not have
that, we could place the AVFrameInternal inside a AVBufferRef or
provide seperate API / fields to make cleanup from libavcodec possible.


> As wm4 said in the relevant discussion,
> this approach is nonoptimal and *will* snowball into a mess of fields if
> other libav* libraries start requiring their own buffers in a frame.

I remember and i think i didnt reply there but this is not really
a plausible scenario.

If we added a field per lib we would have realistically 2 fields
one for libavcodec and one for libavfilter. Beyond that even with
constructed use cases it seems to become hard (at least to me ATM) to
see what else would be added. libswscale ? libavformat ? but what would
they do with their fields ?

But really i primarly want this to move forward, i have no real
preferrance as long as we dont cram muliple opaques in a single opaque
field with wraping or other.


> An internal field of an opaque struct being in a public header is much
> cleaner and easier to maintain than adding such specific fields that may
> at some point in the future need to be removed.
> 
> No actual comments about the approach in question to solve the issue.
> Will leave that to someone more knowledgeable. But at least I'm glad
> something is being done about it.
> 

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

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


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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Michael Niedermayer]

On Sun, Nov 05, 2017 at 02:52:50PM +0100, Hendrik Leppkes wrote:
> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
>  wrote:
> > This gives libavcodec a field that it can freely and safely use.
> > Avoiding the need of wraping of a users opaque_ref field and its issues.
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/frame.c |  8 +++-
> >  libavutil/frame.h | 10 ++
> >  2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 982fbb5c81..6ddaef1e74 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> >
> >  av_buffer_unref(&dst->opaque_ref);
> > +av_buffer_unref(&dst->avcodec_private_ref);
> >  if (src->opaque_ref) {
> >  dst->opaque_ref = av_buffer_ref(src->opaque_ref);
> >  if (!dst->opaque_ref)
> >  return AVERROR(ENOMEM);
> >  }
> > -
> > +if (src->avcodec_private_ref) {
> > +dst->avcodec_private_ref = av_buffer_ref(src->avcodec_private_ref);
> > +if (!dst->avcodec_private_ref)
> > +return AVERROR(ENOMEM);
> > +}
> >  return 0;
> >  }
> >
> > @@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
> >  av_buffer_unref(&frame->hw_frames_ctx);
> >
> >  av_buffer_unref(&frame->opaque_ref);
> > +av_buffer_unref(&frame->avcodec_private_ref);
> >
> >  get_frame_defaults(frame);
> >  }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 0c6aab1c02..73b7d949a9 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -563,6 +563,16 @@ typedef struct AVFrame {
> >  /**
> >   * @}
> >   */
> > +/**
> > + * AVBufferRef for free use by libavcodec. Code outside avcodec will 
> > never
> > + * check or change the contents of the buffer ref. FFmpeg calls
> > + * av_buffer_unref() on it when the frame is unreferenced.
> > + * av_frame_copy_props() calls create a new reference with 
> > av_buffer_ref()
> > + * for the target frame's avcodec_private_ref field.
> > + *
> > + * avcodec should never assign mutually incompatible types to this 
> > field.
> > + */
> > +AVBufferRef *avcodec_private_ref;
> >  } AVFrame;
> >
> >  #if FF_API_FRAME_GET_SET
> 
> I would prefer if this field would not be library-specific, but
> perhaps just "private_ref" which is not allowed to be touched by
> users, and documented to only be valid while within one library - ie.
> if you pass a frame from avcodec to avfilter, avfilter could take over
> the field (and just free any info, if its still in there).
> This would avoid any chances of adding a multitude of fields later,
> and a single AVFrame instance is not going to be used in multiple
> libraries at the same time anyway (the contents might, but not the
> actual AVFrame struct)

that should be easy to implement ...

a disadvantage is the slightly higher chance of mixing up types if
some codepath doesnt cleanup the field

question is what do most prefer ?
avcodec_private_ref ?   (that is one for each of the 2 libs)
private_ref ?
avframe_internal_ref ?  (that is a private struct defined in avutil 
similar to AVCodecInternal)


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

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



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

[FFmpeg-devel] [PATCH] lavu/timecode: clarify error msg for timecode_rate

[Gyan Doshi]

Prompted by an issue reported at StackExchange, patch changes error 
message for timecode_rate values below 1.


The user-supplied value for timecode_rate in drawtext is rounded
to nearest integer. So, a supplied value of 0.49 or lower is rounded to 
0. This throws a misleading error message which says "Timecode frame 
rate must be specified". Changed message to account for values under one.


Also noted supported framerates for drop TC.

Regards,
Gyan
From ef152e77da4d1ea40d452b9cc86dcc51df1e20a7 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sun, 5 Nov 2017 21:29:22 +0530
Subject: [PATCH] lavu/timecode: clarify error msg for timecode_rate

The user-supplied value for timecode_rate in drawtext is rounded
to nearest integer. So, a supplied value of 0.49 or lower is rounded to 0.
This throws a misleading error message which says "Timecode frame rate must be
specified". Changed message to account for values under one.

Also noted supported framerates for drop TC.
---
 doc/filters.texi | 4 +++-
 libavutil/timecode.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 6f6dfcff48..61e27fea6f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7365,7 +7365,9 @@ format. It can be used with or without text parameter. 
@var{timecode_rate}
 option must be specified.
 
 @item timecode_rate, rate, r
-Set the timecode frame rate (timecode only).
+Set the timecode frame rate (timecode only). Value will be rounded to nearest
+integer. Minimum value is "1".
+Drop-frame timecode is supported for frame rates 30 & 60.
 
 @item tc24hmax
 If set to 1, the output of the timecode option will wrap around at 24 hours.
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index c0c67c8478..e9d8504ee7 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -155,7 +155,7 @@ static int check_fps(int fps)
 static int check_timecode(void *log_ctx, AVTimecode *tc)
 {
 if ((int)tc->fps <= 0) {
-av_log(log_ctx, AV_LOG_ERROR, "Timecode frame rate must be 
specified\n");
+av_log(log_ctx, AV_LOG_ERROR, "Valid timecode frame rate must be 
specified. Minimum value is 1\n");
 return AVERROR(EINVAL);
 }
 if ((tc->flags & AV_TIMECODE_FLAG_DROPFRAME) && tc->fps != 30 && tc->fps 
!= 60) {
-- 
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/drawtext: change minimum value for timecode_rate

[Gyan Doshi]

Withdrawn. New patch sent.

On 11/2/2017 11:17 AM, Gyan Doshi wrote:
Prompted by an issue reported at StackExchange, patch changes minimum 
value for timecode_rate to 1.

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

Re: [FFmpeg-devel] [PATCH] web/template_head2: Prevent battleforthenet widget to show again after being clicked away

[Michael Niedermayer]

On Sat, Nov 04, 2017 at 05:48:57PM +0100, Michael Niedermayer wrote:
> Also ensure that the widget does not use google analytics.
> Iam not sure it actually did before, my box has too many layers that stop 
> this.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  src/template_head2 | 22 ++
>  1 file changed, 22 insertions(+)

will apply


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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH] avformat: move priv_pts from AVStream to an internal struct

[James Almer]

It has no reason to be in a public header, even if defined as private.

Signed-off-by: James Almer 
---
To be honest, none of the fields below the "not part of the API" notice
have any reason to be in the public struct, but this one is particularly
pointless and ugly to have there as FFFrac is defined in internal.h

 libavformat/avformat.h |  2 --
 libavformat/internal.h |  2 ++
 libavformat/mux.c  | 18 +-
 libavformat/utils.c|  6 +++---
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b36e2a3bd4..c068aa8009 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1200,8 +1200,6 @@ typedef struct AVStream {
  */
 AVRational display_aspect_ratio;
 
-struct FFFrac *priv_pts;
-
 /**
  * An opaque field for libavformat internal usage.
  * Must not be accessed in any way by callers.
diff --git a/libavformat/internal.h b/libavformat/internal.h
index d136c79bdd..fcd47840a5 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -196,6 +196,8 @@ struct AVStreamInternal {
  * Whether the internal avctx needs to be updated from codecpar (after a 
late change to codecpar)
  */
 int need_context_update;
+
+FFFrac *priv_pts;
 };
 
 #ifdef __GNUC__
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 1445e7dcd6..b1244c67f3 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -432,16 +432,16 @@ static int init_pts(AVFormatContext *s)
 break;
 }
 
-if (!st->priv_pts)
-st->priv_pts = av_mallocz(sizeof(*st->priv_pts));
-if (!st->priv_pts)
+if (!st->internal->priv_pts)
+st->internal->priv_pts = 
av_mallocz(sizeof(*st->internal->priv_pts));
+if (!st->internal->priv_pts)
 return AVERROR(ENOMEM);
 
 if (den != AV_NOPTS_VALUE) {
 if (den <= 0)
 return AVERROR_INVALIDDATA;
 
-frac_init(st->priv_pts, 0, 0, den);
+frac_init(st->internal->priv_pts, 0, 0, den);
 }
 }
 
@@ -601,7 +601,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 }
 pkt->dts =
 //pkt->pts= st->cur_dts;
-pkt->pts = st->priv_pts->val;
+pkt->pts = st->internal->priv_pts->val;
 }
 
 //calculate dts from pts
@@ -638,7 +638,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 av_ts2str(pkt->pts), av_ts2str(pkt->dts));
 
 st->cur_dts = pkt->dts;
-st->priv_pts->val = pkt->dts;
+st->internal->priv_pts->val = pkt->dts;
 
 /* update pts */
 switch (st->codecpar->codec_type) {
@@ -650,12 +650,12 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 /* HACK/FIXME, we skip the initial 0 size packets as they are most
  * likely equal to the encoder delay, but it would be better if we
  * had the real timestamps from the encoder */
-if (frame_size >= 0 && (pkt->size || st->priv_pts->num != 
st->priv_pts->den >> 1 || st->priv_pts->val)) {
-frac_add(st->priv_pts, (int64_t)st->time_base.den * frame_size);
+if (frame_size >= 0 && (pkt->size || st->internal->priv_pts->num != 
st->internal->priv_pts->den >> 1 || st->internal->priv_pts->val)) {
+frac_add(st->internal->priv_pts, (int64_t)st->time_base.den * 
frame_size);
 }
 break;
 case AVMEDIA_TYPE_VIDEO:
-frac_add(st->priv_pts, (int64_t)st->time_base.den * st->time_base.num);
+frac_add(st->internal->priv_pts, (int64_t)st->time_base.den * 
st->time_base.num);
 break;
 }
 return 0;
diff --git a/libavformat/utils.c b/libavformat/utils.c
index cbfb78bf4d..2b2411ffe7 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -123,8 +123,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 int64_t av_stream_get_end_pts(const AVStream *st)
 {
-if (st->priv_pts) {
-return st->priv_pts->val;
+if (st->internal->priv_pts) {
+return st->internal->priv_pts->val;
 } else
 return AV_NOPTS_VALUE;
 }
@@ -4263,6 +4263,7 @@ static void free_stream(AVStream **pst)
 av_bsf_free(&st->internal->bsfcs[i]);
 av_freep(&st->internal->bsfcs);
 }
+av_freep(&st->internal->priv_pts);
 av_bsf_free(&st->internal->extract_extradata.bsf);
 av_packet_free(&st->internal->extract_extradata.pkt);
 }
@@ -4282,7 +4283,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 av_freep(&st->info->duration_error);
 av_freep(&st->info);
 av_freep(&st->recommended_encoder_configuration);
-av_freep(&st->priv_pts);
 
 av_freep(pst);
 }
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Rostislav Pehlivanov]

On 5 November 2017 at 13:52, Hendrik Leppkes  wrote:

> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
>  wrote:
> > This gives libavcodec a field that it can freely and safely use.
> > Avoiding the need of wraping of a users opaque_ref field and its issues.
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/frame.c |  8 +++-
> >  libavutil/frame.h | 10 ++
> >  2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 982fbb5c81..6ddaef1e74 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> >
> >  av_buffer_unref(&dst->opaque_ref);
> > +av_buffer_unref(&dst->avcodec_private_ref);
> >  if (src->opaque_ref) {
> >  dst->opaque_ref = av_buffer_ref(src->opaque_ref);
> >  if (!dst->opaque_ref)
> >  return AVERROR(ENOMEM);
> >  }
> > -
> > +if (src->avcodec_private_ref) {
> > +dst->avcodec_private_ref = av_buffer_ref(src->avcodec_
> private_ref);
> > +if (!dst->avcodec_private_ref)
> > +return AVERROR(ENOMEM);
> > +}
> >  return 0;
> >  }
> >
> > @@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
> >  av_buffer_unref(&frame->hw_frames_ctx);
> >
> >  av_buffer_unref(&frame->opaque_ref);
> > +av_buffer_unref(&frame->avcodec_private_ref);
> >
> >  get_frame_defaults(frame);
> >  }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 0c6aab1c02..73b7d949a9 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -563,6 +563,16 @@ typedef struct AVFrame {
> >  /**
> >   * @}
> >   */
> > +/**
> > + * AVBufferRef for free use by libavcodec. Code outside avcodec
> will never
> > + * check or change the contents of the buffer ref. FFmpeg calls
> > + * av_buffer_unref() on it when the frame is unreferenced.
> > + * av_frame_copy_props() calls create a new reference with
> av_buffer_ref()
> > + * for the target frame's avcodec_private_ref field.
> > + *
> > + * avcodec should never assign mutually incompatible types to this
> field.
> > + */
> > +AVBufferRef *avcodec_private_ref;
> >  } AVFrame;
> >
> >  #if FF_API_FRAME_GET_SET
>
> I would prefer if this field would not be library-specific, but
> perhaps just "private_ref" which is not allowed to be touched by
> users, and documented to only be valid while within one library - ie.
> if you pass a frame from avcodec to avfilter, avfilter could take over
> the field (and just free any info, if its still in there).
> This would avoid any chances of adding a multitude of fields later,
> and a single AVFrame instance is not going to be used in multiple
> libraries at the same time anyway (the contents might, but not the
> actual AVFrame struct)
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


No, this would be horrible, lavfi should be able to use what's in the
avbufferref without reinitializing anything that it should contain. lavu
should handle anything that has to be initialized in the struct the
avbufferref backs so that all internal libraries can use it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Hendrik Leppkes]

On Sun, Nov 5, 2017 at 7:08 PM, Rostislav Pehlivanov
 wrote:
> On 5 November 2017 at 13:52, Hendrik Leppkes  wrote:
>
>> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
>>  wrote:
>> > This gives libavcodec a field that it can freely and safely use.
>> > Avoiding the need of wraping of a users opaque_ref field and its issues.
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavutil/frame.c |  8 +++-
>> >  libavutil/frame.h | 10 ++
>> >  2 files changed, 17 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavutil/frame.c b/libavutil/frame.c
>> > index 982fbb5c81..6ddaef1e74 100644
>> > --- a/libavutil/frame.c
>> > +++ b/libavutil/frame.c
>> > @@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> >  #endif
>> >
>> >  av_buffer_unref(&dst->opaque_ref);
>> > +av_buffer_unref(&dst->avcodec_private_ref);
>> >  if (src->opaque_ref) {
>> >  dst->opaque_ref = av_buffer_ref(src->opaque_ref);
>> >  if (!dst->opaque_ref)
>> >  return AVERROR(ENOMEM);
>> >  }
>> > -
>> > +if (src->avcodec_private_ref) {
>> > +dst->avcodec_private_ref = av_buffer_ref(src->avcodec_
>> private_ref);
>> > +if (!dst->avcodec_private_ref)
>> > +return AVERROR(ENOMEM);
>> > +}
>> >  return 0;
>> >  }
>> >
>> > @@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
>> >  av_buffer_unref(&frame->hw_frames_ctx);
>> >
>> >  av_buffer_unref(&frame->opaque_ref);
>> > +av_buffer_unref(&frame->avcodec_private_ref);
>> >
>> >  get_frame_defaults(frame);
>> >  }
>> > diff --git a/libavutil/frame.h b/libavutil/frame.h
>> > index 0c6aab1c02..73b7d949a9 100644
>> > --- a/libavutil/frame.h
>> > +++ b/libavutil/frame.h
>> > @@ -563,6 +563,16 @@ typedef struct AVFrame {
>> >  /**
>> >   * @}
>> >   */
>> > +/**
>> > + * AVBufferRef for free use by libavcodec. Code outside avcodec
>> will never
>> > + * check or change the contents of the buffer ref. FFmpeg calls
>> > + * av_buffer_unref() on it when the frame is unreferenced.
>> > + * av_frame_copy_props() calls create a new reference with
>> av_buffer_ref()
>> > + * for the target frame's avcodec_private_ref field.
>> > + *
>> > + * avcodec should never assign mutually incompatible types to this
>> field.
>> > + */
>> > +AVBufferRef *avcodec_private_ref;
>> >  } AVFrame;
>> >
>> >  #if FF_API_FRAME_GET_SET
>>
>> I would prefer if this field would not be library-specific, but
>> perhaps just "private_ref" which is not allowed to be touched by
>> users, and documented to only be valid while within one library - ie.
>> if you pass a frame from avcodec to avfilter, avfilter could take over
>> the field (and just free any info, if its still in there).
>> This would avoid any chances of adding a multitude of fields later,
>> and a single AVFrame instance is not going to be used in multiple
>> libraries at the same time anyway (the contents might, but not the
>> actual AVFrame struct)
>>
>> - Hendrik
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
> No, this would be horrible, lavfi should be able to use what's in the
> avbufferref without reinitializing anything that it should contain. lavu
> should handle anything that has to be initialized in the struct the
> avbufferref backs so that all internal libraries can use it.

The entire point of this field is to contain opaque private data that
no other library ever has any business of even knowing exists.
If additional data needs to be shared between libraries, it should be
a properly defined public shared structure.

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

Re: [FFmpeg-devel] [RFC/PATCH]lavc/v4l2_context: Change the type of the ioctl cmd to unsigned long

[Carl Eugen Hoyos]

2017-11-05 2:46 GMT+01:00 Mark Thompson :
> On 05/11/17 00:46, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes a warning on a current 64bit Linux system (that I
>> do not see on my ancient system where the ioctl cmd has type int).
>> Is there a better way to deal with it?
>
>> Fixes a warning on recent Linux:
>> libavcodec/v4l2_context.c: In function 'ff_v4l2_context_set_status':
>> libavcodec/v4l2_context.c:496:26: warning: comparison is always false due to 
>> limited range of data type
>
> Huh.  I didn't realise that the standard Linux ioctl numbering actually
> acts differently on different achitectures (you don't hit this on ARM
> or x86-64 with a write-only ioctl, as VIDIOC_STREAMON is).
>
> The patch is probably correct, though I think I would prefer the type
> to be uint32_t

Pushed with that change.

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

Re: [FFmpeg-devel] On in-tree external headers

[Carl Eugen Hoyos]

2017-11-05 15:24 GMT+01:00 Mark Thompson :
> On 30/10/17 19:51, Mark Thompson wrote:

> "No external headers may be included in the ffmpeg tree."

So you suggest to remove the Nvidia header?

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 05/11/17 18:28, Carl Eugen Hoyos wrote:
> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>> On 30/10/17 19:51, Mark Thompson wrote:
> 
>> "No external headers may be included in the ffmpeg tree."
> 
> So you suggest to remove the Nvidia header?
If that specific policy is adopted then it would have to be.

Alternative proposals are welcome.

Thanks,

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

Re: [FFmpeg-devel] On in-tree external headers

[Carl Eugen Hoyos]

2017-11-05 19:35 GMT+01:00 Mark Thompson :
> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>>> On 30/10/17 19:51, Mark Thompson wrote:
>>
>>> "No external headers may be included in the ffmpeg tree."
>>
>> So you suggest to remove the Nvidia header?
> If that specific policy is adopted then it would have to be.

Then I don't think this policy is useful.

Iirc, there is a second external header, I have never used
either of those but judging from user response, both features
are heavily used making a removal a no-go.

> Alternative proposals are welcome.

I don't really understand:
It was mentioned several times in the relevant thread - and
I completely agree - that the fact that one external header
is present is no argument to add another. (And iirc - and
again I agree - it was also argued that pushing on this
argument is not a good idea.)
If you believe adding the AMD header makes sense, it may
possibly be added, if you are against it, it will likely not be
added.

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 05/11/17 18:42, Carl Eugen Hoyos wrote:
> 2017-11-05 19:35 GMT+01:00 Mark Thompson :
>> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
>>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
 On 30/10/17 19:51, Mark Thompson wrote:
>>>
 "No external headers may be included in the ffmpeg tree."
>>>
>>> So you suggest to remove the Nvidia header?
>> If that specific policy is adopted then it would have to be.
> 
> Then I don't think this policy is useful.
> 
> Iirc, there is a second external header, I have never used
> either of those but judging from user response, both features
> are heavily used making a removal a no-go.

Ok, sure.

How about:

"No external headers may be added to the ffmpeg tree, unless they are for 
AviSynth or Nvidia."

(Documentation patch below.)

>> Alternative proposals are welcome.
> 
> I don't really understand:
> It was mentioned several times in the relevant thread - and
> I completely agree - that the fact that one external header
> is present is no argument to add another. (And iirc - and
> again I agree - it was also argued that pushing on this
> argument is not a good idea.)
> If you believe adding the AMD header makes sense, it may
> possibly be added, if you are against it, it will likely not be
> added.

I do not believe that adding the AMD header is the right thing to do.

But, I want to be clear what the rules are so that they can be applied 
consistently.  There currently appear to be no written rules, so I would like 
to write some so that we have a clear answer in this case and don't have this 
same dispute again in future (see V4L2 two months ago, where there was a pretty 
much identical argument with a contributor wanting to add their headers to the 
tree).

- Mark


diff --git a/doc/developer.texi b/doc/developer.texi
index a7b4f1d737..c76e0083ce 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -381,6 +381,16 @@ Never write to unallocated memory, never write over the 
end of arrays,
 always check values read from some untrusted source before using them
 as array index or other risky things.
 
+@subheading External headers
+Do not include external headers directly in FFmpeg.  Most packages provide
+suitable headers and linkable libraries when installed, and these should be
+used.  References to external packages in configure should use pkg-config
+if possible to find paths and options - ad-hoc build tests with hard-coded
+paths are to be avoided, but can be used if there is no other possibility.
+If an external package does not provide usable headers or libraries then
+please add directions for how to use it to the documentation.
+AviSynth and Nvidia are exempt from this prohibition on external headers.
+
 @subsection Documentation/Other
 @subheading Subscribe to the ffmpeg-cvslog mailing list.
 It is important to do this as the diffs of all commits are sent there and
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] On in-tree external headers

[Nicolas George]

Le quintidi 15 brumaire, an CCXXVI, Mark Thompson a écrit :
> +AviSynth and Nvidia are exempt from this prohibition on external headers.

So if somebody wants to add new headers, they just have to propose a
patch to this sentence to add another exception? I will not vote for a
proposal like that.

By the way, what voting protocol are you following? It does not look
like the one I proposed some time ago.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] On in-tree external headers

[James Almer]

On 11/5/2017 3:42 PM, Carl Eugen Hoyos wrote:
> 2017-11-05 19:35 GMT+01:00 Mark Thompson :
>> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
>>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
 On 30/10/17 19:51, Mark Thompson wrote:
>>>
 "No external headers may be included in the ffmpeg tree."
>>>
>>> So you suggest to remove the Nvidia header?
>> If that specific policy is adopted then it would have to be.
> 
> Then I don't think this policy is useful.
> 
> Iirc, there is a second external header, I have never used
> either of those but judging from user response, both features
> are heavily used making a removal a no-go.

Removal of the nvidia headers from the tree could be done by creating a
separate repository specifically for them. The work done to get them in
this form is not something that should be lost.

> 
>> Alternative proposals are welcome.
> 
> I don't really understand:
> It was mentioned several times in the relevant thread - and
> I completely agree - that the fact that one external header
> is present is no argument to add another. (And iirc - and
> again I agree - it was also argued that pushing on this
> argument is not a good idea.)
> If you believe adding the AMD header makes sense, it may
> possibly be added, if you are against it, it will likely not be
> added.
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

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

[Moritz Barsnick]

On Sun, Nov 05, 2017 at 02:41:54 +, Mironov, Mikhail wrote:

> > > +{ "quality","", 0, AV_OPT_TYPE_CONST, { .i64 =
> > AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET_QUALITY  }, 0, 0, VE,
> > "quality" },
> > 
> > These are 0, 5, 10.  Do the intermediate values work?  Should they be
> > exposed?
> > 
> Only enum values are supported. I guess they left space for future 
> extensions. 

What if an unsupported value is passed via AMF_ASSIGN_PROPERTY_INT64()?
Despite enumerated values, ffmpeg allows to pass numerical values, and
you don't verify that they are only 0, 5, 10.

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

Re: [FFmpeg-devel] [PATCH 2/2] Document the fact that -to option is now also for input

[Moritz Barsnick]

On Sat, Nov 04, 2017 at 10:02:05 +0300, vi0...@gmail.com wrote:
> From: Vitaly _Vi Shukela 
> 
> Signed-off-by: Vitaly _Vi Shukela 
> ---
>  doc/ffmpeg.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

You can add the documentation in the same commit as you add the
feature.

>  @item -to @var{position} (@emph{output})
> -Stop writing the output at @var{position}.
> +Stop writing the output or reading the input at @var{position}.

The first quoted line also needs to become "@emph{input/output}",
obviously.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-10-09 0:24 GMT+02:00 Carl Eugen Hoyos :
> 2017-10-07 16:51 GMT+02:00 Carl Eugen Hoyos :
>> 2017-10-01 18:23 GMT+02:00 Carl Eugen Hoyos :
>>> 2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :
>>>
 The existing amr demuxer does not allow reading streams,
 it requires the 3GPP-conforming file header.
 Attached patch allows reading amrnb and amrwb from (live)
 streams, fixes ticket #6678.
>>>
>>> New patch with auto-detection attached, passes probecheck.
>>
>> Simplified patch attached that does not duplicate two small arrays
>> in the object file that are already duplicated in the source code.
>> The uninitialized variable is also fixed.
>
> The last version triggered for repeated bytes (like adp),
> new version attached.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 0/6] avcodec: Vorbis encoder improvements

[Carl Eugen Hoyos]

2017-08-22 3:23 GMT+02:00 Tyler Jones :
> Please see the following patches.
>
> The first two patches are identical to my latest pending changes sent to the
> mailing list on July 28. Changelogs are included regardless. The clipping
> avoidance patch should remove most clicking that had been noticed by
> atomnuker in previous versions.

What happened with this patchset?

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

Re: [FFmpeg-devel] On in-tree external headers

[Timo Rothenpieler]

Am 05.11.2017 um 19:59 schrieb Mark Thompson:

On 05/11/17 18:42, Carl Eugen Hoyos wrote:

2017-11-05 19:35 GMT+01:00 Mark Thompson :

On 05/11/17 18:28, Carl Eugen Hoyos wrote:

2017-11-05 15:24 GMT+01:00 Mark Thompson :

On 30/10/17 19:51, Mark Thompson wrote:



"No external headers may be included in the ffmpeg tree."


So you suggest to remove the Nvidia header?

If that specific policy is adopted then it would have to be.


Then I don't think this policy is useful.

Iirc, there is a second external header, I have never used
either of those but judging from user response, both features
are heavily used making a removal a no-go.


Ok, sure.

How about:

"No external headers may be added to the ffmpeg tree, unless they are for AviSynth 
or Nvidia."


I don't think a strict "no external headers" rule makes sense or is a 
good idea at all. Specially if there are seemingly arbitrary exceptions.


If such a rule is to be added at all, it should list the conditions 
under which external headers can be added. And it should clearly be an 
exception.




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] On in-tree external headers

[Mark Thompson]

On 05/11/17 19:01, Nicolas George wrote:
> Le quintidi 15 brumaire, an CCXXVI, Mark Thompson a écrit :
>> +AviSynth and Nvidia are exempt from this prohibition on external headers.
> 
> So if somebody wants to add new headers, they just have to propose a
> patch to this sentence to add another exception? I will not vote for a
> proposal like that.

I suppose it would mean that, yes.

> By the way, what voting protocol are you following? It does not look
> like the one I proposed some time ago.

I wasn't feeling I had reached the point where that was necessary - I am still 
trying to work out what people actually want.  The suggestion to have a vote 
soon on a specific hard-line proposal was, I suppose, a provocation to actually 
reply with something useful (all previous responses only addressed specific 
consequences rather than the proposal itself).  Given some clear proposals, it 
would then be possible to discuss between them and come to an agreed result.

If you feel it would be appropriate to label this as a Decision and follow your 
protocol, I would be happy to do so in following mails.

Thanks,

- Mark


(I'm not sure I necessarily agree with the "nothing is allowed" position, but 
in the absence of any other proposals at all I would back it for the clarity it 
offers.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c()

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: 1939661764 - -454942263 cannot 
be represented in type 'int'
Fixes: 3191/clusterfuzz-testcase-minimized-5688798451073024

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/aacpsdsp_template.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/aacpsdsp_template.c b/libavcodec/aacpsdsp_template.c
index e35e9699b0..19be200653 100644
--- a/libavcodec/aacpsdsp_template.c
+++ b/libavcodec/aacpsdsp_template.c
@@ -130,12 +130,12 @@ static void ps_decorrelate_c(INTFLOAT (*out)[2], INTFLOAT 
(*delay)[2],
 INTFLOAT apd_im = in_im;
 in_re = AAC_MSUB30(link_delay_re, fractional_delay_re,
 link_delay_im, fractional_delay_im);
-in_re -= a_re;
+in_re -= (UINTFLOAT)a_re;
 in_im = AAC_MADD30(link_delay_re, fractional_delay_im,
 link_delay_im, fractional_delay_re);
-in_im -= a_im;
-ap_delay[m][n+5][0] = apd_re + AAC_MUL31(ag[m], in_re);
-ap_delay[m][n+5][1] = apd_im + AAC_MUL31(ag[m], in_im);
+in_im -= (UINTFLOAT)a_im;
+ap_delay[m][n+5][0] = apd_re + (UINTFLOAT)AAC_MUL31(ag[m], in_re);
+ap_delay[m][n+5][1] = apd_im + (UINTFLOAT)AAC_MUL31(ag[m], in_im);
 }
 out[n][0] = AAC_MUL16(transient_gain[n], in_re);
 out[n][1] = AAC_MUL16(transient_gain[n], in_im);
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 2/4] avcodec/mdct_*: Fix integer overflow in addition in RESCALE()

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: 1219998458 - -1469874012 cannot 
be represented in type 'int'
Fixes: 3443/clusterfuzz-testcase-minimized-5369987105554432

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mdct_fixed.c|  8 
 libavcodec/mdct_template.c | 14 +++---
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavcodec/mdct_fixed.c b/libavcodec/mdct_fixed.c
index a32cb00ca0..aabf0c88f8 100644
--- a/libavcodec/mdct_fixed.c
+++ b/libavcodec/mdct_fixed.c
@@ -39,13 +39,13 @@ void ff_mdct_calcw_c(FFTContext *s, FFTDouble *out, const 
FFTSample *input)
 
 /* pre rotation */
 for(i=0;i> 6)
+#   define RSCALE(x, y) ((int)((x) + (unsigned)(y) + 32) >> 6)
 #else /* FFT_FIXED_32 */
-#   define RSCALE(x) ((x) >> 1)
+#   define RSCALE(x, y) ((int)((x) + (unsigned)(y)) >> 1)
 #endif /* FFT_FIXED_32 */
 #endif
 
@@ -181,13 +181,13 @@ void ff_mdct_calc_c(FFTContext *s, FFTSample *out, const 
FFTSample *input)
 
 /* pre rotation */
 for(i=0;ihttp://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] avcodec/aacdec_fixed: Fix undefined shift

[Michael Niedermayer]

Fixes: runtime error: left shift of negative value -801112064
Fixes: 3492/clusterfuzz-testcase-minimized-5784775283441664

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/aacdec_fixed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index ffd577c789..f96999efb4 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c
@@ -309,7 +309,7 @@ static av_always_inline void predict(PredictorState *ps, 
int *coef,
 if (shift > 0) {
 *coef += (unsigned)((pv.mant + (1 << (shift - 1))) >> shift);
 } else
-*coef += (unsigned)(pv.mant << -shift);
+*coef += (unsigned)pv.mant << -shift;
 }
 }
 
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 1/4] avcodec/snowdec: Fix integer overflow in header parsing

[Michael Niedermayer]

Fixes: 3984/clusterfuzz-testcase-minimized-5265759929368576
Fixes: runtime error: signed integer overflow: -1085585801 + -1094995529 cannot 
be represented in type 'int'

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/snowdec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 13668c2105..727e908fb5 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -374,7 +374,7 @@ static int decode_header(SnowContext *s){
 }
 }
 
-s->spatial_decomposition_type+= get_symbol(&s->c, s->header_state, 1);
+s->spatial_decomposition_type+= (unsigned)get_symbol(&s->c, 
s->header_state, 1);
 if(s->spatial_decomposition_type > 1U){
 av_log(s->avctx, AV_LOG_ERROR, "spatial_decomposition_type %d not 
supported\n", s->spatial_decomposition_type);
 return AVERROR_INVALIDDATA;
@@ -390,10 +390,10 @@ static int decode_header(SnowContext *s){
 }
 
 
-s->qlog   += get_symbol(&s->c, s->header_state, 1);
-s->mv_scale   += get_symbol(&s->c, s->header_state, 1);
-s->qbias  += get_symbol(&s->c, s->header_state, 1);
-s->block_max_depth+= get_symbol(&s->c, s->header_state, 1);
+s->qlog   += (unsigned)get_symbol(&s->c, s->header_state, 1);
+s->mv_scale   += (unsigned)get_symbol(&s->c, s->header_state, 1);
+s->qbias  += (unsigned)get_symbol(&s->c, s->header_state, 1);
+s->block_max_depth+= (unsigned)get_symbol(&s->c, s->header_state, 1);
 if(s->block_max_depth > 1 || s->block_max_depth < 0 || s->mv_scale > 256U){
 av_log(s->avctx, AV_LOG_ERROR, "block_max_depth= %d is too large\n", 
s->block_max_depth);
 s->block_max_depth= 0;
-- 
2.15.0

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 05/11/17 20:04, Timo Rothenpieler wrote:
> Am 05.11.2017 um 19:59 schrieb Mark Thompson:
>> On 05/11/17 18:42, Carl Eugen Hoyos wrote:
>>> 2017-11-05 19:35 GMT+01:00 Mark Thompson :
 On 05/11/17 18:28, Carl Eugen Hoyos wrote:
> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>> On 30/10/17 19:51, Mark Thompson wrote:
>
>> "No external headers may be included in the ffmpeg tree."
>
> So you suggest to remove the Nvidia header?
 If that specific policy is adopted then it would have to be.
>>>
>>> Then I don't think this policy is useful.
>>>
>>> Iirc, there is a second external header, I have never used
>>> either of those but judging from user response, both features
>>> are heavily used making a removal a no-go.
>>
>> Ok, sure.
>>
>> How about:
>>
>> "No external headers may be added to the ffmpeg tree, unless they are for 
>> AviSynth or Nvidia."
> 
> I don't think a strict "no external headers" rule makes sense or is a good 
> idea at all. Specially if there are seemingly arbitrary exceptions.
> 
> If such a rule is to be added at all, it should list the conditions under 
> which external headers can be added. And it should clearly be an exception.

Sounds good to me.  What should those conditions be?

Thanks,

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

Re: [FFmpeg-devel] Maintainers : add myself for exr

[Michael Niedermayer]

On Sat, Nov 04, 2017 at 03:23:07PM +0100, Martin Vignali wrote:
> Hello,
> 
> Following Michael Niedermayer request, patch in attach
> to add myself for exr decoder
> 
> 
> Martin

>  MAINTAINERS |1 +
>  1 file changed, 1 insertion(+)
> b0b5ec77736730c422425d34e683d5fd476c512b  
> 0001-Maintainers-add-myself-for-exr.patch
> From 582dd8ad8224b755b344e45557aeb620304a1bc2 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sat, 4 Nov 2017 15:17:28 +0100
> Subject: [PATCH] Maintainers : add myself for exr

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()

[Michael Niedermayer]

On Sat, Nov 04, 2017 at 01:19:20AM +0100, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: -503316480 + -2013265038 
> cannot be represented in type 'int'
> Fixes: 3805/clusterfuzz-testcase-minimized-6578427831255040
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264idct_template.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

will apply

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

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


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

[FFmpeg-devel] [PATCH] Fixing small memory leak when wrapping texture in AVD3D11FrameDescriptor

[Greg Wessels]

---
 libavutil/hwcontext_d3d11va.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 52683b9..65dd665 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -123,6 +123,7 @@ static void d3d11va_frames_uninit(AVHWFramesContext *ctx)
 static void free_texture(void *opaque, uint8_t *data)
 {
 ID3D11Texture2D_Release((ID3D11Texture2D *)opaque);
+av_free(data);
 }
 
 static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)
-- 
2.7.4

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

[FFmpeg-devel] Must I subscribe to ffmpeg-devel in order to submit a patch?

[Jim DeLaHunt]

Hello, ffmpeg developers:

I'm gearing up to submit a patch, adding an FAQ to the documentation. 
According to , 
"Patches should be posted to the ffmpeg-devel 
 mailing list."  
But neither that section, nor the ffmpeg-devel list information at 
 is clear about 
whether one must be subscribed to the list in order to post to it.


I guess, from whether this message bounces or appears in the list 
archives, I'll have my answer.


A clarification of the Submitting Patches documentation may be my second 
contribution. :-)


Thank you for all the work you have put in to make this wonderful tool. 
I appreciate it.


--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil/softfloat: Add FLOAT_MIN

[Michael Niedermayer]

On Wed, Nov 01, 2017 at 02:00:18PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/softfloat.h | 1 +
>  1 file changed, 1 insertion(+)

will apply patchset

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

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mpegts: opus muxing & demuxing expanded

[Carl Eugen Hoyos]

2017-09-01 1:10 GMT+02:00 pkv.stream :
> Hello
>
> per Michael requests:
> 1) I have split patch in 2
> 2) added malloc checks
> 3) changed  "for int" loop to C89 style (if I understood well the comment)
> regards

What happened to this patch?

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

Re: [FFmpeg-devel] FFplay: progress bar feature proposal

[Michael Niedermayer]

On Thu, Apr 13, 2017 at 10:53:49AM -0500, Raymond Pierce wrote:
> 13.04.2017, 09:40, "Steven Liu" :
> > 2017-04-13 20:48 GMT+08:00 Raymond Pierce :
> >
> >>  Hi. Currently FFplay has no visible progress bar and it is hard to tell
> >>  where a stream is currently positioned. So if one wants, for example, to
> >>  rewind
> >>  a little back relative to current position using right mouse click it is
> >>  always
> >>  guessing and trying.
> >>
> >>  I propose very simple 1-pixel progress bar which can be turned on or off
> >>  during
> >>  playback by pressing a button (I use 'L', from 'line'). By default the bar
> >>  is off.
> >>
> >>  I choose bright green color (#00ff00) for the part to the left of a 
> >> current
> >>  position and pure black for the part to the right.
> >>
> >>  You can see how it looks on the attached image.
> >>
> >>  Draft patch is applied. One global variable ('static int
> >>  show_progress_line')
> >>  and one function ('static void video_progress_line_display(VideoState
> >>  *is)')
> >>  have been added. Also the existing 'video_display()' function has been
> >>  moved
> >>  below 'get_master_clock()' as the latter is used in the new function.
> >>
> >>  What do you think?
> >>  ___
> >>  ffmpeg-devel mailing list
> >>  ffmpeg-devel@ffmpeg.org
> >>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > git commit -a
> > git format-patch -s -1
> >
> > You should use the command looks like the above git command to make patch
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Hello, Steven. Thank you for the advice. New patch in the attachment.
> Should I post a new message with the patch to ffmpeg-devel@ffmpeg.org list?

>  ffplay.c |   52 +---
>  1 file changed, 37 insertions(+), 15 deletions(-)
> b7142d62e8a61dcd04b9cbc1c6c847918fea438a  
> 0001-Add-FFplay-progress-bar-feature.patch
> From e780cfa4330ae87cd4506ec2ccfe39ea045f2134 Mon Sep 17 00:00:00 2001
> From: Ray Pierce 
> Date: Thu, 13 Apr 2017 20:41:59 +0500
> Subject: [PATCH] Add FFplay progress bar feature

whats the status of this ?

(just noticed this doesnt apply anymore)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] Must I subscribe to ffmpeg-devel in order to submit a patch?

[Nicolas George]

Le quartidi 14 brumaire, an CCXXVI, Jim DeLaHunt a écrit :
> I'm gearing up to submit a patch, adding an FAQ to the documentation.
> According to , "Patches
> should be posted to the ffmpeg-devel
>  mailing list."  But
> neither that section, nor the ffmpeg-devel list information at
>  is clear about
> whether one must be subscribed to the list in order to post to it.

The comments on your patch will be posted to the mailing-list. You need
to read them.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] On in-tree external headers

[Timo Rothenpieler]

How about:

"No external headers may be added to the ffmpeg tree, unless they are for AviSynth 
or Nvidia."


I don't think a strict "no external headers" rule makes sense or is a good idea 
at all. Specially if there are seemingly arbitrary exceptions.

If such a rule is to be added at all, it should list the conditions under which 
external headers can be added. And it should clearly be an exception.


Sounds good to me.  What should those conditions be?


For once, there should be a good reason to do so.

In case of nvidia the headers in this form is otherwise unobtainable, 
and it's also partially modified specifically for use in ffmpeg.
Getting the original headers is also not straight forward as you need an 
nvidia developer account, which you cannot just register for, but you 
need to apply for.


I also feel like whatever this rule would look like, it's already 
practiced that way. There isn't really a way not do decide this on a 
case by case basis. Luckily it's not something that comes up every other 
day.
If someone would submit random third party library headers to compat/ 
for no apparent reason other than comfort, it would certainly be rejected.




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/2] avformat/mpegts: opus muxing & demuxing expanded

[pkv.stream]

Le 05/11/2017 à 9:35 PM, Carl Eugen Hoyos a écrit :

2017-09-01 1:10 GMT+02:00 pkv.stream :

Hello

per Michael requests:
1) I have split patch in 2
2) added malloc checks
3) changed  "for int" loop to C89 style (if I understood well the comment)
regards

What happened to this patch?


there were several rounds of review with Michael; he's been very helpful 
spotting mistakes.

Here's the latest version:

http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/218928.html

Waiting for next round. No rush, Michael has already given a lot of 
attention so I don't want to put any pressure.
If people knowledgeable on the draft spec on opus + mpegts could also 
review the latest revision of the patch, it would be welcome.


Thanks
pkv


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] [PATCH 1/2] avformat/mpegts: opus muxing & demuxing expanded

[Carl Eugen Hoyos]

2017-11-05 22:07 GMT+01:00 pkv.stream :
> Le 05/11/2017 à 9:35 PM, Carl Eugen Hoyos a écrit :
>>
>> 2017-09-01 1:10 GMT+02:00 pkv.stream :
>>>
>>> Hello
>>>
>>> per Michael requests:
>>> 1) I have split patch in 2
>>> 2) added malloc checks
>>> 3) changed  "for int" loop to C89 style (if I understood well the
>>> comment)
>>> regards
>>
>> What happened to this patch?
>
>
> there were several rounds of review with Michael; he's been very helpful
> spotting mistakes.
> Here's the latest version:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/218928.html

Thank you!

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

Re: [FFmpeg-devel] Must I subscribe to ffmpeg-devel in order to submit a patch?

[Thilo Borgmann]

Am 05.11.17 um 21:37 schrieb Nicolas George:
> Le quartidi 14 brumaire, an CCXXVI, Jim DeLaHunt a écrit :
>> I'm gearing up to submit a patch, adding an FAQ to the documentation.
>> According to , "Patches
>> should be posted to the ffmpeg-devel
>>  mailing list."  But
>> neither that section, nor the ffmpeg-devel list information at
>>  is clear about
>> whether one must be subscribed to the list in order to post to it.
> 
> The comments on your patch will be posted to the mailing-list. You need
> to read them.

Thanks for pointing it out, Jim. We'd appreciate it and welcome you to propose 
a patch for updating the corresponding docs.

Fact is, that it is in most cases of the author's best interest do participate 
in a following review and therefore subscription to the mailing list is highly 
recommended for that purpose like Nicolas pointed out.

However, if it really is in the authors intention, it is better to post a 
possible patch without caring about its future instead of not to post that 
patch at all. I think it should already be documented that it is appreciated 
but not necessary to use a real name for contributing.

Thanks,
Thilo

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

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

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: November 5, 2017 2:11 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On Sun, Nov 05, 2017 at 02:41:54 +, Mironov, Mikhail wrote:
> 
> > > > +{ "quality","", 0, AV_OPT_TYPE_CONST, { .i64 =
> > > AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET_QUALITY  }, 0, 0, VE,
> > > "quality" },
> > >
> > > These are 0, 5, 10.  Do the intermediate values work?  Should they
> > > be exposed?
> > >
> > Only enum values are supported. I guess they left space for future
> extensions.
> 
> What if an unsupported value is passed via
> AMF_ASSIGN_PROPERTY_INT64()?
> Despite enumerated values, ffmpeg allows to pass numerical values, and you
> don't verify that they are only 0, 5, 10.

AMF runtime has strict verification. Error will be returned. 

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

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

Re: [FFmpeg-devel] On in-tree external headers

[Michael Niedermayer]

On Sun, Nov 05, 2017 at 06:59:42PM +, Mark Thompson wrote:
> On 05/11/17 18:42, Carl Eugen Hoyos wrote:
> > 2017-11-05 19:35 GMT+01:00 Mark Thompson :
> >> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
> >>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>  On 30/10/17 19:51, Mark Thompson wrote:
> >>>
>  "No external headers may be included in the ffmpeg tree."
> >>>
> >>> So you suggest to remove the Nvidia header?
> >> If that specific policy is adopted then it would have to be.
> > 
> > Then I don't think this policy is useful.
> > 
> > Iirc, there is a second external header, I have never used
> > either of those but judging from user response, both features
> > are heavily used making a removal a no-go.
> 
> Ok, sure.
> 
> How about:
> 

> "No external headers may be added to the ffmpeg tree, unless they are for 
> AviSynth or Nvidia."

This would be unfair, iam against this

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] On in-tree external headers

[Jan Ekstrom]

On Sun, Nov 5, 2017 at 10:40 PM, Timo Rothenpieler
 wrote:
> For once, there should be a good reason to do so.
>

Agreed.

> In case of nvidia the headers in this form is otherwise unobtainable, and
> it's also partially modified specifically for use in ffmpeg.
> Getting the original headers is also not straight forward as you need an
> nvidia developer account, which you cannot just register for, but you need
> to apply for.
>

Just my 20 cents, but this point is kind of less straightforward.
Sure, we like having more features and various vendors also like the
fact that we've made their things easily usable. But this also leads
to the in my honest opinion uncomfortable case where due to the first
vendor being an unfortunate REDACTED regarding the SDK, anything that
comes afterwards and handles itself properly seems to be getting less
nice handling if requested to behave like a normal thing in the
ecosystem. If we think about a case where the other vendor's SDK would
have been presented here first, and we would have made it available
with a dependency on its SDK, it would have been much less likely that
we would have added this latter feature with the headers there. But
this is just theoretical at this point since no proper SDK has come up
on either vendor's side. I think VA-API is currently the only thing
with a "proper SDK" (and the other Intel thing is one where someone
took the time to make it into a proper "SDK").

To be honest, I wouldn't be against removing nvidia's headers and
having them separate just to have the result be similar (even though
users would most definitely be confused at first). Avisynth/Avxsynth
is kind of a special kind of open source mess where having the header
inside makes sense (and let's not even go into Avisynth+ which doesn't
seem to want to be binary compatible with Avisynth 2.6).

> I also feel like whatever this rule would look like, it's already practiced
> that way. There isn't really a way not do decide this on a case by case
> basis. Luckily it's not something that comes up every other day.
> If someone would submit random third party library headers to compat/ for no
> apparent reason other than comfort, it would certainly be rejected.

Yes, the rule most certainly would contain something along the lines
of "...this is something that should be considered on a case-by-case
basis with a reasoning being mentioned and considered..."

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

Re: [FFmpeg-devel] [PATCH] HW accelerator: Indicate when HW acceleration is in use

[Lim, Michele]

Mark, 

Thanks for your response.  I agree with you and actually had an implementation 
similar to what you've described for the decoder but abandoned it; I haven't 
found an elegant way without making too many changes to indicate it much later 
when hardware is actually set up for execution.  This is being handled in a 
loop for all possible pixel formats supported by the display surface. (for my 
display there are 9, so the same message is logged 9 times).

A more elegant solution will require additional code which is against FFmpeg 
guideline.  I think this benefits everyone wanting assurance as to whether the 
coding or decoding is done using the hardware or software path.

Meanwhile, I can submit with the not-so-elegant solution so that you can see 
what I mean - this is just for the decoder.

I will look into adding more code for a more elegant solution, if that's 
acceptable.  Please let me know which way is best.

Thanks,
Michele

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Saturday, November 4, 2017 12:09 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] HW accelerator: Indicate when HW 
acceleration is in use

On 03/11/17 18:35, Michele Lim wrote:
> Having clear indication of when a hardware accelerator is in operation 
> prevents false assumptions, for e.g., in situations when the command 
> line argument inadvertently omits options for enabling it, resulting 
> to the framework silently switching to the SW path.
> 
> Signed-off-by: Michele Lim 
> ---
>  fftools/ffmpeg_hw.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fftools/ffmpeg_hw.c b/fftools/ffmpeg_hw.c index 
> a4d1cad..f071746 100644
> --- a/fftools/ffmpeg_hw.c
> +++ b/fftools/ffmpeg_hw.c
> @@ -306,6 +306,8 @@ int hw_device_setup_for_decode(InputStream *ist)
>  if (!ist->dec_ctx->hw_device_ctx)
>  return AVERROR(ENOMEM);
>  
> +/* Indicate HW accelerator has been prepared for decode */
> +av_log(ist->dec_ctx, AV_LOG_INFO, "HW accelerator prepared for 
> + decode: %s\n", av_hwdevice_get_type_name(type));
>  return 0;
>  }
>  
> @@ -331,6 +333,9 @@ int hw_device_setup_for_encode(OutputStream *ost)
>  // No device required.
>  return 0;
>  }
> +
> +/* Indicate HW accelerator has been prepared for encode */
> +av_log(ost->enc_ctx, AV_LOG_INFO, "HW accelerator prepared for 
> + encode: %s\n", av_hwdevice_get_type_name(type));
>  }
>  
>  static int hwaccel_retrieve_data(AVCodecContext *avctx, AVFrame 
> *input)
> 

I don't think this does what you want.  It is only a preparation step which 
sets hardware devices which might then be used by a codec, and tells you little 
about whether it is actually used in practice.  Consider that your message will 
appear when setting -hwaccel_device and decoding with a random codec with no 
hardware support, and also when a codec does support some hardware but not the 
actual stream being decoded (e.g. H.264 4:2:2).

If you want a message like this (which I admit ambivalence to, but if other 
people think it's useful then sure), I think it has to be logged later when we 
actually know whether the hardware is usable - either inside lavc or in 
ffmpeg.c after a frame is returned.

- 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

Re: [FFmpeg-devel] [PATCH] ffplay: use SDL2 audio API

[Marton Balint]

On Sat, 4 Nov 2017, James Almer wrote:


On 11/4/2017 3:54 PM, Marton Balint wrote:

It allows us to specify what kind of audio parameter changes are allowed.

Should fix ticket #6721.


Seems to work. Thanks.



Thanks, applied.

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

[FFmpeg-devel] adding bluetooth SBC codec

[Aurelien Jacobs]

Hello everyone,

Long time no see !

I'm glad to see ffmpeg still strong.

I'm curently playing with bluetooth audio (A2DP) and I wanted to
use lavc to do the encoding/decoding, so I added some codecs that
I need to ffmpeg.

Here is the result for the SBC codec.

[PATCH 1/3] sbc: implement SBC codec (low-complexity subband codec)
[PATCH 2/3] sbc: add parser for SBC
[PATCH 3/3] sbc: add raw muxer and demuxer for SBC

Note that this is based on libsbc, and that I have a repository with full
history of the modifications I applied on top of libsbc:
  https://gitlab.com/aurelj/ffmpeg/commits/bluetooth_sbc
If anyone would prefer me to submit all the patches with full history
on this mailing list, just say so. (I just think the squashed
version makes more sense to review)

Thanks everyone for all your efforts to keep ffmpeg going.
--
Aurel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] sbc: add parser for SBC

[Aurelien Jacobs]

---
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   2 +
 libavcodec/sbc_parser.c | 135 
 3 files changed, 139 insertions(+)
 create mode 100644 libavcodec/sbc_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 17648a1c3d..a15573748d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -994,11 +994,13 @@ OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_MPEGAUDIO_PARSER)+= mpegaudio_parser.o
 OBJS-$(CONFIG_MPEGVIDEO_PARSER)+= mpegvideo_parser.o\
   mpeg12.o mpeg12data.o
+OBJS-$(CONFIG_MSBC_PARSER) += sbc_parser.o
 OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o vorbis_data.o
 OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_PNM_PARSER)  += pnm_parser.o pnm.o
 OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
 OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
+OBJS-$(CONFIG_SBC_PARSER)  += sbc_parser.o
 OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
 OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
 OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o vc1data.o  \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 95cf67ce20..02d241c4f3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -717,11 +717,13 @@ static void register_all(void)
 REGISTER_PARSER(MPEG4VIDEO, mpeg4video);
 REGISTER_PARSER(MPEGAUDIO,  mpegaudio);
 REGISTER_PARSER(MPEGVIDEO,  mpegvideo);
+REGISTER_PARSER(MSBC,   msbc);
 REGISTER_PARSER(OPUS,   opus);
 REGISTER_PARSER(PNG,png);
 REGISTER_PARSER(PNM,pnm);
 REGISTER_PARSER(RV30,   rv30);
 REGISTER_PARSER(RV40,   rv40);
+REGISTER_PARSER(SBC,sbc);
 REGISTER_PARSER(SIPR,   sipr);
 REGISTER_PARSER(TAK,tak);
 REGISTER_PARSER(VC1,vc1);
diff --git a/libavcodec/sbc_parser.c b/libavcodec/sbc_parser.c
new file mode 100644
index 00..278ac6f84f
--- /dev/null
+++ b/libavcodec/sbc_parser.c
@@ -0,0 +1,135 @@
+/*
+ * SBC parser
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "sbc.h"
+#include "parser.h"
+
+typedef struct SBCParseContext {
+ParseContext pc;
+uint8_t header[3];
+int header_size;
+int buffered_size;
+} SBCParseContext;
+
+static int sbc_parse_header(AVCodecParserContext *s, AVCodecContext *avctx,
+const uint8_t *data, size_t len)
+{
+static const int sample_rates[4] = { 16000, 32000, 44100, 48000 };
+int sr, blocks, mode, subbands, bitpool, channels, joint;
+int length;
+
+if (len < 3)
+return -1;
+
+if (data[0] == MSBC_SYNCWORD && data[1] == 0 && data[2] == 0) {
+avctx->channels = 1;
+avctx->sample_fmt = AV_SAMPLE_FMT_S16;
+avctx->sample_rate = 16000;
+avctx->frame_size = 120;
+s->duration = avctx->frame_size;
+return 57;
+}
+
+if (data[0] != SBC_SYNCWORD)
+return -2;
+
+sr   =   (data[1] >> 6) & 0x03;
+blocks   = (((data[1] >> 4) & 0x03) + 1) << 2;
+mode =   (data[1] >> 2) & 0x03;
+subbands = (((data[1] >> 0) & 0x01) + 1) << 2;
+bitpool  = data[2];
+
+channels = mode == SBC_MODE_MONO ? 1 : 2;
+joint= mode == SBC_MODE_JOINT_STEREO;
+
+length = 4 + (subbands * channels) / 2;
+if (channels == 1 || mode == SBC_MODE_DUAL_CHANNEL)
+length += ((channels * blocks * bitpool) + 7) / 8;
+else
+length += (((joint ? subbands : 0) + blocks * bitpool) + 7) / 8;
+
+avctx->channels = channels;
+avctx->sample_fmt = AV_SAMPLE_FMT_S16;
+avctx->sample_rate = sample_rates[sr];
+avctx->frame_size = subbands * blocks;
+s->duration = avctx->frame_size;
+return length;
+}
+
+static int sbc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+SBCParseContext *pc

[FFmpeg-devel] [PATCH 3/3] sbc: add raw muxer and demuxer for SBC

[Aurelien Jacobs]

---
 doc/general.texi |  1 +
 libavformat/Makefile |  4 +++
 libavformat/allformats.c |  2 ++
 libavformat/rawenc.c | 28 ++
 libavformat/sbcdec.c | 76 
 libavformat/utils.c  |  1 +
 6 files changed, 112 insertions(+)
 create mode 100644 libavformat/sbcdec.c

diff --git a/doc/general.texi b/doc/general.texi
index baaa308dcf..74f72be69a 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -462,6 +462,7 @@ library:
 @item raw NULL  @tab X @tab
 @item raw video @tab X @tab X
 @item raw id RoQ@tab X @tab
+@item raw SBC   @tab X @tab X
 @item raw Shorten   @tab   @tab X
 @item raw TAK   @tab   @tab X
 @item raw TrueHD@tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index caebe5b146..0dff981c01 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -442,6 +442,10 @@ OBJS-$(CONFIG_S337M_DEMUXER) += s337m.o spdif.o
 OBJS-$(CONFIG_SAMI_DEMUXER)  += samidec.o subtitles.o
 OBJS-$(CONFIG_SAP_DEMUXER)   += sapdec.o
 OBJS-$(CONFIG_SAP_MUXER) += sapenc.o
+OBJS-$(CONFIG_SBC_DEMUXER)   += sbcdec.o rawdec.o
+OBJS-$(CONFIG_SBC_MUXER) += rawenc.o
+OBJS-$(CONFIG_MSBC_DEMUXER)  += sbcdec.o rawdec.o
+OBJS-$(CONFIG_MSBC_MUXER)+= rawenc.o
 OBJS-$(CONFIG_SBG_DEMUXER)   += sbgdec.o
 OBJS-$(CONFIG_SCC_DEMUXER)   += sccdec.o subtitles.o
 OBJS-$(CONFIG_SCC_MUXER) += sccenc.o subtitles.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5ad9..a7109d5abb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -208,6 +208,7 @@ static void register_all(void)
 REGISTER_MUXDEMUX(MPJPEG,   mpjpeg);
 REGISTER_DEMUXER (MPL2, mpl2);
 REGISTER_DEMUXER (MPSUB,mpsub);
+REGISTER_MUXDEMUX(MSBC, msbc);
 REGISTER_DEMUXER (MSF,  msf);
 REGISTER_DEMUXER (MSNWC_TCP,msnwc_tcp);
 REGISTER_DEMUXER (MTAF, mtaf);
@@ -273,6 +274,7 @@ static void register_all(void)
 REGISTER_DEMUXER (S337M,s337m);
 REGISTER_DEMUXER (SAMI, sami);
 REGISTER_MUXDEMUX(SAP,  sap);
+REGISTER_MUXDEMUX(SBC,  sbc);
 REGISTER_DEMUXER (SBG,  sbg);
 REGISTER_MUXDEMUX(SCC,  scc);
 REGISTER_DEMUXER (SDP,  sdp);
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index f640121cb4..ac0119489c 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -413,6 +413,34 @@ AVOutputFormat ff_rawvideo_muxer = {
 };
 #endif
 
+#if CONFIG_SBC_MUXER
+AVOutputFormat ff_sbc_muxer = {
+.name  = "sbc",
+.long_name = NULL_IF_CONFIG_SMALL("raw SBC"),
+.mime_type = "audio/x-sbc",
+.extensions= "sbc",
+.audio_codec   = AV_CODEC_ID_SBC,
+.video_codec   = AV_CODEC_ID_NONE,
+.write_header  = force_one_stream,
+.write_packet  = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
+#if CONFIG_MSBC_MUXER
+AVOutputFormat ff_msbc_muxer = {
+.name  = "msbc",
+.long_name = NULL_IF_CONFIG_SMALL("raw mSBC"),
+.mime_type = "audio/x-msbc",
+.extensions= "msbc",
+.audio_codec   = AV_CODEC_ID_MSBC,
+.video_codec   = AV_CODEC_ID_NONE,
+.write_header  = force_one_stream,
+.write_packet  = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
 #if CONFIG_TRUEHD_MUXER
 AVOutputFormat ff_truehd_muxer = {
 .name  = "truehd",
diff --git a/libavformat/sbcdec.c b/libavformat/sbcdec.c
new file mode 100644
index 00..1eb99bae03
--- /dev/null
+++ b/libavformat/sbcdec.c
@@ -0,0 +1,76 @@
+/*
+ * RAW SBC demuxer
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+
+#define SBC_SYNCWORD   0x9C
+#define MSBC_SYNCWORD  0xAD
+
+#if CONFIG_SBC_DEMUXER
+static int sbc_probe

[FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

The encoder was reverse engineered from binary library and from
EP0398973B1 patent (long expired).
The decoder was simply deduced from the encoder.
---
 doc/general.texi|   2 +
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/aptx.c   | 854 
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 6 files changed, 867 insertions(+)
 create mode 100644 libavcodec/aptx.c

diff --git a/doc/general.texi b/doc/general.texi
index 9e6ae13435..4a89531c47 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -991,6 +991,8 @@ following image formats are supported:
 @item Amazing Studio PAF Audio @tab @tab  X
 @item Apple lossless audio   @tab  X  @tab  X
 @tab QuickTime fourcc 'alac'
+@item aptX   @tab  X  @tab  X
+@tab Used in Bluetooth A2DP
 @item ATRAC1 @tab @tab  X
 @item ATRAC3 @tab @tab  X
 @item ATRAC3+@tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3a33361f33..25706a263d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -188,6 +188,8 @@ OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o 
mjpegenc_common.o \
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
+OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
+OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
 OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
 OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 98655ddd7c..61abe9939c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -406,6 +406,7 @@ static void register_all(void)
 REGISTER_DECODER(AMRNB, amrnb);
 REGISTER_DECODER(AMRWB, amrwb);
 REGISTER_DECODER(APE,   ape);
+REGISTER_ENCDEC (APTX,  aptx);
 REGISTER_DECODER(ATRAC1,atrac1);
 REGISTER_DECODER(ATRAC3,atrac3);
 REGISTER_DECODER(ATRAC3AL,  atrac3al);
diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
new file mode 100644
index 00..4ecb6bb231
--- /dev/null
+++ b/libavcodec/aptx.c
@@ -0,0 +1,854 @@
+/*
+ * Audio Processing Technology codec for Bluetooth (aptX)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "internal.h"
+#include "mathops.h"
+
+
+enum channels {
+LEFT,
+RIGHT,
+NB_CHANNELS
+};
+
+enum subbands {
+LF,  // Low Frequency (0-5.5 kHz)
+MLF, // Medium-Low Frequency (5.5-11kHz)
+MHF, // Medium-High Frequency (11-16.5kHz)
+HF,  // High Frequency (16.5-22kHz)
+NB_SUBBANDS
+};
+
+#define NB_FILTERS 2
+#define FILTER_TAPS 16
+
+typedef struct {
+int pos;
+int32_t buffer[2*FILTER_TAPS];
+} FilterSignal;
+
+typedef struct {
+FilterSignal outer_filter_signal[NB_FILTERS];
+FilterSignal inner_filter_signal[NB_FILTERS][NB_FILTERS];
+} QMFAnalysis;
+
+typedef struct {
+int32_t quantized_sample;
+int32_t quantized_sample_parity_change;
+int32_t error;
+} Quantize;
+
+typedef struct {
+int32_t quantization_factor;
+int32_t factor_select;
+int32_t reconstructed_difference;
+} InvertQuantize;
+
+typedef struct {
+int32_t prev_sign[2];
+int32_t s_weight[2];
+int32_t d_weight[24];
+int32_t pos;
+int32_t reconstructed_differences[48];
+int32_t previous_reconstructed_sample;
+int32_t predicted_difference;
+int32_t predicted_sample;
+} Prediction;
+
+typedef struct {
+int32_t codeword_history;
+int32_t dither_parity;
+int32_t dither[NB_SUBBANDS];
+
+QMFAnalysis qmf;
+Quantize quantize[NB_SUBBANDS];
+InvertQuantize invert_quantize[NB_SUBBANDS];
+Prediction prediction[NB_SUBBANDS];
+} Channel;
+
+typedef struct {
+int32_t sync_idx;
+Channel channels[NB_CHANNELS];
+} AptXContext;
+
+
+static const int32_t quantize_intervals_LF[65] = {
+  -9948,9948,   29860,   49808,   69822,   89

[FFmpeg-devel] adding bluetooth aptX codec

[Aurelien Jacobs]

Hi again,

Here is the other codec I added for my bluetooth needs: aptX.

This one is based on my reverse engineering and my understanding
of patent EP0398973B1 (long expired).

[PATCH 1/2] aptx: implement the aptX bluetooth codec
[PATCH 2/2] aptx: add raw muxer and demuxer for aptX

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

[FFmpeg-devel] [PATCH 2/2] aptx: add raw muxer and demuxer for aptX

[Aurelien Jacobs]

---
 doc/general.texi |  1 +
 libavformat/Makefile |  2 ++
 libavformat/allformats.c |  1 +
 libavformat/aptxdec.c| 70 
 libavformat/rawenc.c | 13 +
 libavformat/utils.c  |  1 +
 6 files changed, 88 insertions(+)
 create mode 100644 libavformat/aptxdec.c

diff --git a/doc/general.texi b/doc/general.texi
index 4a89531c47..79e0bd0993 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -439,6 +439,7 @@ library:
 @item QCP   @tab   @tab X
 @item raw ADTS (AAC)@tab X @tab X
 @item raw AC-3  @tab X @tab X
+@item raw aptX  @tab X @tab X
 @item raw Chinese AVS video @tab X @tab X
 @item raw CRI ADX   @tab X @tab X
 @item raw Dirac @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index caebe5b146..21fb892a81 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -92,6 +92,8 @@ OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
 OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
+OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
+OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
 OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
 OBJS-$(CONFIG_ASF_DEMUXER)   += asfdec_f.o asf.o asfcrypt.o \
 avlanguage.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5ad9..40964a0df0 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -67,6 +67,7 @@ static void register_all(void)
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
 REGISTER_MUXDEMUX(APNG, apng);
+REGISTER_MUXDEMUX(APTX, aptx);
 REGISTER_DEMUXER (AQTITLE,  aqtitle);
 REGISTER_MUXDEMUX(ASF,  asf);
 REGISTER_DEMUXER (ASF_O,asf_o);
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
new file mode 100644
index 00..769b666b4d
--- /dev/null
+++ b/libavformat/aptxdec.c
@@ -0,0 +1,70 @@
+/*
+ * RAW aptX demuxer
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+
+#define APTX_BLOCK_SIZE   4
+#define APTX_PACKET_SIZE  (256*APTX_BLOCK_SIZE)
+
+static int aptx_probe(AVProbeData *p)
+{
+int len, score = 0;
+if (!p || !p->filename)
+return 0;
+len = strlen(p->filename);
+if (len > 5 && !strcmp(&p->filename[len-4], ".aptx"))
+score = AVPROBE_SCORE_EXTENSION;
+return score;
+}
+
+static int aptx_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id = AV_CODEC_ID_APTX;
+st->codecpar->format = AV_SAMPLE_FMT_S16;
+st->codecpar->channels = 2;
+st->codecpar->sample_rate = 44100;
+st->codecpar->bits_per_coded_sample = 4;
+st->codecpar->block_align = APTX_BLOCK_SIZE;
+st->codecpar->frame_size = APTX_PACKET_SIZE;
+st->start_time = 0;
+return 0;
+}
+
+static int aptx_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+return av_get_packet(s->pb, pkt, APTX_PACKET_SIZE);
+}
+
+AVInputFormat ff_aptx_demuxer = {
+.name   = "aptx",
+.long_name  = NULL_IF_CONFIG_SMALL("raw aptX"),
+.extensions = "aptx",
+.read_probe = aptx_probe,
+.read_header= aptx_read_header,
+.read_packet= aptx_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index f640121cb4..aa3ef76fbf 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -91,6 +91,19 @@ AVOutputFormat ff_adx_muxer = {
 };
 #endif
 
+#if CONFIG_APTX_MUXER
+AVOutputFormat ff_aptx_muxer = {
+.name  = "aptx",
+.long_name = NULL_IF_CONFIG_SMALL("raw aptX (Audio Processing 
Technology for Bluetooth)"),
+.extensions= "aptx",
+.audio_codec   = AV_CODEC_ID_APTX,

Re: [FFmpeg-devel] [PATCH 2/3] sbc: add parser for SBC

[Rostislav Pehlivanov]

On 5 November 2017 at 23:35, Aurelien Jacobs  wrote:

> ---
>  libavcodec/Makefile |   2 +
>  libavcodec/allcodecs.c  |   2 +
>  libavcodec/sbc_parser.c | 135 ++
> ++
>  3 files changed, 139 insertions(+)
>  create mode 100644 libavcodec/sbc_parser.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 17648a1c3d..a15573748d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -994,11 +994,13 @@ OBJS-$(CONFIG_PNG_PARSER)  +=
> png_parser.o
>  OBJS-$(CONFIG_MPEGAUDIO_PARSER)+= mpegaudio_parser.o
>  OBJS-$(CONFIG_MPEGVIDEO_PARSER)+= mpegvideo_parser.o\
>mpeg12.o mpeg12data.o
> +OBJS-$(CONFIG_MSBC_PARSER) += sbc_parser.o
>  OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o
> vorbis_data.o
>  OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
>  OBJS-$(CONFIG_PNM_PARSER)  += pnm_parser.o pnm.o
>  OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
>  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
> +OBJS-$(CONFIG_SBC_PARSER)  += sbc_parser.o
>  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
>  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
>  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o vc1data.o  \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 95cf67ce20..02d241c4f3 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -717,11 +717,13 @@ static void register_all(void)
>  REGISTER_PARSER(MPEG4VIDEO, mpeg4video);
>  REGISTER_PARSER(MPEGAUDIO,  mpegaudio);
>  REGISTER_PARSER(MPEGVIDEO,  mpegvideo);
> +REGISTER_PARSER(MSBC,   msbc);
>  REGISTER_PARSER(OPUS,   opus);
>  REGISTER_PARSER(PNG,png);
>  REGISTER_PARSER(PNM,pnm);
>  REGISTER_PARSER(RV30,   rv30);
>  REGISTER_PARSER(RV40,   rv40);
> +REGISTER_PARSER(SBC,sbc);
>  REGISTER_PARSER(SIPR,   sipr);
>  REGISTER_PARSER(TAK,tak);
>  REGISTER_PARSER(VC1,vc1);
> diff --git a/libavcodec/sbc_parser.c b/libavcodec/sbc_parser.c
> new file mode 100644
> index 00..278ac6f84f
> --- /dev/null
> +++ b/libavcodec/sbc_parser.c
> @@ -0,0 +1,135 @@
> +/*
> + * SBC parser
> + *
> + * Copyright (C) 2017  Aurelien Jacobs 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "sbc.h"
> +#include "parser.h"
> +
> +typedef struct SBCParseContext {
> +ParseContext pc;
> +uint8_t header[3];
> +int header_size;
> +int buffered_size;
> +} SBCParseContext;
> +
> +static int sbc_parse_header(AVCodecParserContext *s, AVCodecContext
> *avctx,
> +const uint8_t *data, size_t len)
> +{
> +static const int sample_rates[4] = { 16000, 32000, 44100, 48000 };
> +int sr, blocks, mode, subbands, bitpool, channels, joint;
> +int length;
> +
> +if (len < 3)
> +return -1;
> +
> +if (data[0] == MSBC_SYNCWORD && data[1] == 0 && data[2] == 0) {
> +avctx->channels = 1;
> +avctx->sample_fmt = AV_SAMPLE_FMT_S16;
> +avctx->sample_rate = 16000;
> +avctx->frame_size = 120;
> +s->duration = avctx->frame_size;
> +return 57;
> +}
> +
> +if (data[0] != SBC_SYNCWORD)
> +return -2;
> +
> +sr   =   (data[1] >> 6) & 0x03;
> +blocks   = (((data[1] >> 4) & 0x03) + 1) << 2;
> +mode =   (data[1] >> 2) & 0x03;
> +subbands = (((data[1] >> 0) & 0x01) + 1) << 2;
> +bitpool  = data[2];
> +
> +channels = mode == SBC_MODE_MONO ? 1 : 2;
> +joint= mode == SBC_MODE_JOINT_STEREO;
> +
> +length = 4 + (subbands * channels) / 2;
> +if (channels == 1 || mode == SBC_MODE_DUAL_CHANNEL)
> +length += ((channels * blocks * bitpool) + 7) / 8;
> +else
> +length += (((joint ? subbands : 0) + blocks * bitpool) + 7) / 8;
> +
> +avctx->channels = channels;
> +avctx->sample_fmt = AV_SAMPLE_FMT_S16;
> +avctx->sample_rate = sample_rates[sr];
> +avctx->frame_

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[James Almer]

On 11/5/2017 12:25 PM, Michael Niedermayer wrote:
> On Sun, Nov 05, 2017 at 02:52:50PM +0100, Hendrik Leppkes wrote:
>> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
>>  wrote:
>>> This gives libavcodec a field that it can freely and safely use.
>>> Avoiding the need of wraping of a users opaque_ref field and its issues.
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavutil/frame.c |  8 +++-
>>>  libavutil/frame.h | 10 ++
>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>>> index 982fbb5c81..6ddaef1e74 100644
>>> --- a/libavutil/frame.c
>>> +++ b/libavutil/frame.c
>>> @@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>>  #endif
>>>
>>>  av_buffer_unref(&dst->opaque_ref);
>>> +av_buffer_unref(&dst->avcodec_private_ref);
>>>  if (src->opaque_ref) {
>>>  dst->opaque_ref = av_buffer_ref(src->opaque_ref);
>>>  if (!dst->opaque_ref)
>>>  return AVERROR(ENOMEM);
>>>  }
>>> -
>>> +if (src->avcodec_private_ref) {
>>> +dst->avcodec_private_ref = av_buffer_ref(src->avcodec_private_ref);
>>> +if (!dst->avcodec_private_ref)
>>> +return AVERROR(ENOMEM);
>>> +}
>>>  return 0;
>>>  }
>>>
>>> @@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
>>>  av_buffer_unref(&frame->hw_frames_ctx);
>>>
>>>  av_buffer_unref(&frame->opaque_ref);
>>> +av_buffer_unref(&frame->avcodec_private_ref);
>>>
>>>  get_frame_defaults(frame);
>>>  }
>>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>>> index 0c6aab1c02..73b7d949a9 100644
>>> --- a/libavutil/frame.h
>>> +++ b/libavutil/frame.h
>>> @@ -563,6 +563,16 @@ typedef struct AVFrame {
>>>  /**
>>>   * @}
>>>   */
>>> +/**
>>> + * AVBufferRef for free use by libavcodec. Code outside avcodec will 
>>> never
>>> + * check or change the contents of the buffer ref. FFmpeg calls
>>> + * av_buffer_unref() on it when the frame is unreferenced.
>>> + * av_frame_copy_props() calls create a new reference with 
>>> av_buffer_ref()
>>> + * for the target frame's avcodec_private_ref field.
>>> + *
>>> + * avcodec should never assign mutually incompatible types to this 
>>> field.
>>> + */
>>> +AVBufferRef *avcodec_private_ref;
>>>  } AVFrame;
>>>
>>>  #if FF_API_FRAME_GET_SET
>>
>> I would prefer if this field would not be library-specific, but
>> perhaps just "private_ref" which is not allowed to be touched by
>> users, and documented to only be valid while within one library - ie.
>> if you pass a frame from avcodec to avfilter, avfilter could take over
>> the field (and just free any info, if its still in there).
>> This would avoid any chances of adding a multitude of fields later,
>> and a single AVFrame instance is not going to be used in multiple
>> libraries at the same time anyway (the contents might, but not the
>> actual AVFrame struct)
> 
> that should be easy to implement ...
> 
> a disadvantage is the slightly higher chance of mixing up types if
> some codepath doesnt cleanup the field
> 
> question is what do most prefer ?
> avcodec_private_ref ?   (that is one for each of the 2 libs)
> private_ref ?
> avframe_internal_ref ?  (that is a private struct defined in avutil 
> similar to AVCodecInternal)

Discard my suggestion. Being inside an internal opaque struct would
require avpriv_ functions to access from within avcodec, and as BtbN
mentioned on IRC earlier today we should definitely avoid that.

So take Hendrik's suggestion, unless somebody starts a vote to force
wm4's original implementation instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] sbc: add raw muxer and demuxer for SBC

[Carl Eugen Hoyos]

2017-11-06 0:35 GMT+01:00 Aurelien Jacobs :

> +static int sbc_probe(AVProbeData *p)
> +{
> +int score = 0;

> +int l = strlen(p->filename);
> +if (l > 4 && !strcmp(&p->filename[l-4], ".sbc"))
> +score = AVPROBE_SCORE_EXTENSION;

This may make sense but we don't do it for any
other demuxer and if we want it it should imo be
done for all demuxers.

> +if (p->buf[0] == SBC_SYNCWORD)
> +score++;

Am I correct that the syncword is repeated
throughout the file? If yes, the probing can
be significantly improved (and would not
depend on the suffix).
Additionally, it is a little better not to return
a positive score - not even 1 - for eight bits
conformance.

Thank you!

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

Re: [FFmpeg-devel] [PATCH 2/2] aptx: add raw muxer and demuxer for aptX

[Carl Eugen Hoyos]

2017-11-06 0:39 GMT+01:00 Aurelien Jacobs :

> +static int aptx_probe(AVProbeData *p)
> +{
> +int len, score = 0;
> +if (!p || !p->filename)
> +return 0;
> +len = strlen(p->filename);
> +if (len > 5 && !strcmp(&p->filename[len-4], ".aptx"))
> +score = AVPROBE_SCORE_EXTENSION;
> +return score;
> +}

Just remove the function;-)

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

Re: [FFmpeg-devel] adding bluetooth aptX codec

[Carl Eugen Hoyos]

2017-11-06 0:39 GMT+01:00 Aurelien Jacobs :

> Here is the other codec I added for my bluetooth needs: aptX.

Just curious:
Could you comment on the quality?

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

Re: [FFmpeg-devel] adding bluetooth aptX codec

[Aurelien Jacobs]

On Mon, Nov 06, 2017 at 12:51:55AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-06 0:39 GMT+01:00 Aurelien Jacobs :
> 
> > Here is the other codec I added for my bluetooth needs: aptX.
> 
> Just curious:
> Could you comment on the quality?

Well, my ears aren't really good enough to make a real difference
between SBC and aptX. Also aptX is a quite simple and old codec,
so don't expect it to compete with Vorbis, AAC or any advanced
codec.
OTOH, aptX has one significant advantage in the context of
realtime streaming (ie. bluetooth A2DP): it is really low-latency.

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

Re: [FFmpeg-devel] [PATCH 2/2] aptx: add raw muxer and demuxer for aptX

[Aurelien Jacobs]

On Mon, Nov 06, 2017 at 12:51:19AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-06 0:39 GMT+01:00 Aurelien Jacobs :
> 
> > +static int aptx_probe(AVProbeData *p)
> > +{
> > +int len, score = 0;
> > +if (!p || !p->filename)
> > +return 0;
> > +len = strlen(p->filename);
> > +if (len > 5 && !strcmp(&p->filename[len-4], ".aptx"))
> > +score = AVPROBE_SCORE_EXTENSION;
> > +return score;
> > +}
> 
> Just remove the function;-)

Indeed, I don't know how I ended up writing this...
I will remove it.

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

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Rostislav Pehlivanov]

On 5 November 2017 at 23:39, Aurelien Jacobs  wrote:

> The encoder was reverse engineered from binary library and from
> EP0398973B1 patent (long expired).
> The decoder was simply deduced from the encoder.
> ---
>  doc/general.texi|   2 +
>  libavcodec/Makefile |   2 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/aptx.c   | 854 ++
> ++
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  6 files changed, 867 insertions(+)
>  create mode 100644 libavcodec/aptx.c
>

Very nice job


>
>
> +
> +static const int32_t quantization_factors[32] = {
> +2048 << 11,
> +2093 << 11,
> +2139 << 11,
> +2186 << 11,
> +2233 << 11,
> +2282 << 11,
> +2332 << 11,
> +2383 << 11,
> +2435 << 11,
> +2489 << 11,
> +2543 << 11,
> +2599 << 11,
> +2656 << 11,
> +2714 << 11,
> +2774 << 11,
> +2834 << 11,
> +2896 << 11,
> +2960 << 11,
> +3025 << 11,
> +3091 << 11,
> +3158 << 11,
> +3228 << 11,
> +3298 << 11,
> +3371 << 11,
> +3444 << 11,
> +3520 << 11,
> +3597 << 11,
> +3676 << 11,
> +3756 << 11,
> +3838 << 11,
> +3922 << 11,
> +4008 << 11,
> +};
>


First of all, please put all numbers on the same line.
Second of all, its pointless to do a shift here, either change the numbers
or better yet, since you already do a shift down:



> +/* update quantization factor */
> +idx = (invert_quantize->factor_select & 0xFF) >> 3;
> +shift -= invert_quantize->factor_select >> 8;
> +invert_quantize->quantization_factor = quantization_factors[idx] >>
> shift;
> +}
>


Which would be equivalent to:

 idx = (invert_quantize->factor_select & 0xFF) >> 3;
> shift -= invert_quantize->factor_select >> 8;
> invert_quantize->quantization_factor = (quantization_factors[idx] << 11)
> >> shift;
>

The compiler ought to be smart enough to handle that as a single operation.





>
> +static int##size##_t rshift##size(int##size##_t value, int shift)
>  \
>
> +static int##size##_t rshift##size##_clip24(int##size##_t value, int
> shift)\
>
> +static void aptx_update_codeword_history(Channel *channel)
>
> +static void aptx_generate_dither(Channel *channel)
>
>
+static void aptx_qmf_filter_signal_push(FilterSignal *signal, int32_t
> sample)
>
> +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> +const int32_t coeffs[FILTER_TAPS],
> +int shift)
>
> +static void aptx_qmf_polyphase_analysis(FilterSignal signal[NB_FILTERS],
> +const int32_t
> coeffs[NB_FILTERS][FILTER_TAPS],
> +int shift,
> +int32_t samples[NB_FILTERS],
> +int32_t *low_subband_output,
> +int32_t *high_subband_output)
> +
>


Add an inline flag to small functions like these. Won't make a difference
but eh.




> +
> +static void aptx_quantise_difference(Quantize *quantize,
> + int32_t sample_difference,
> + int32_t dither,
> + int32_t quantization_factor,
> + ConstTables *tables)
>

English spelling of quantize? I prefer quantize since that's how its
spelled throughout the entire codebase.


> +{
> +const int32_t *intervals = tables->quantize_intervals;
> +int32_t quantized_sample, dithered_sample, parity_change;
> +int32_t d, mean, interval, inv;
> +int64_t error;
> +
> +quantized_sample = aptx_bin_search(FFABS(sample_difference) >> 4,
> +   quantization_factor,
> +   intervals, tables->tables_size);
> +
> +d = rshift32_clip24(MULH(dither, dither), 7) - (1 << 23);
> +d = rshift64(MUL64(d, tables->quantize_dither_factors[quantized_sample]),
> 23);
> +
> +intervals += quantized_sample;
> +mean = (intervals[1] + intervals[0]) / 2;
> +interval = intervals[1] - intervals[0];
> +if (sample_difference < 0)
> +interval = -interval;
>


Can be simplified to:
interval *= 1 - 2*(sample_difference < 0);
or
interval *= sample_difference < 0 ? -1 : +1;



> +
> +dithered_sample = rshift64_clip24(MUL64(dither, interval) +
> ((int64_t)(mean + d) << 32), 32);
> +error = ((int64_t)FFABS(sample_difference) << 20) -
> MUL64(dithered_sample, quantization_factor);
> +quantize->error = FFABS(rshift64(error, 23));
> +
> +parity_change = quantized_sample;
> +if (error < 0)  quantized_sample--;
> +elseparity_change--;
>
+
>

Coding style issues, seen this in much of the code, must be
if (something)
stuff;
else
other_stuff;



> +inv = -(sample_difference < 0);
> +quantize->quantized_sample   = qu

Re: [FFmpeg-devel] [PATCH 3/3] sbc: add raw muxer and demuxer for SBC

[Aurelien Jacobs]

On Mon, Nov 06, 2017 at 12:48:32AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-06 0:35 GMT+01:00 Aurelien Jacobs :
> 
> > +static int sbc_probe(AVProbeData *p)
> > +{
> > +int score = 0;
> 
> > +int l = strlen(p->filename);
> > +if (l > 4 && !strcmp(&p->filename[l-4], ".sbc"))
> > +score = AVPROBE_SCORE_EXTENSION;
> 
> This may make sense but we don't do it for any
> other demuxer and if we want it it should imo be
> done for all demuxers.
> 
> > +if (p->buf[0] == SBC_SYNCWORD)
> > +score++;
> 
> Am I correct that the syncword is repeated
> throughout the file? If yes, the probing can
> be significantly improved (and would not
> depend on the suffix).

Indeed it is repeated, and indeed the probing could
be improved by looking at several syncwords.
The problem is that they are not repeated at fixed
intervals, and that the offset to the next one is
not simply encoded in the stream.
So basically, the same process as the parser should
be used to find where is the next syncword. This
seems a bit to much for my taste for a simple probing
function.

> Additionally, it is a little better not to return
> a positive score - not even 1 - for eight bits
> conformance.

Well, the best might be to just remove this probing
function. SBC is not usually stored in files AFAIK
(it is streamed over bluetooth), so this demuxer is
mostly for testing purpose.
Relying on extension autodetection should be good
enough for testing.
Does this sound OK ?

Thanks for the review.
--
Aurel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] sbc: add raw muxer and demuxer for SBC

[Carl Eugen Hoyos]

2017-11-06 1:31 GMT+01:00 Aurelien Jacobs :

> Well, the best might be to just remove this probing
> function.

+1

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

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Marton Balint]

On Fri, 27 Oct 2017, Jeyapal, Karthick wrote:


Please find the patch attached.



Thanks, below some comments:


From b18679b91a79f5e23a5ad23ae70f3862a34ddfb8 Mon Sep 17 00:00:00 2001
From: Karthick J 
Date: Fri, 27 Oct 2017 12:00:23 +0530
Subject: [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

When -format_code is not specified autodetection will happen
---
 doc/indevs.texi |  1 +
 libavdevice/decklink_common.cpp | 33 ++-
 libavdevice/decklink_common.h   |  8 +
 libavdevice/decklink_dec.cpp| 70 +++--
 4 files changed, 89 insertions(+), 23 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index d308bbf..74bfcc5 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -238,6 +238,7 @@ This sets the input video format to the format given by the 
FourCC. To see
 the supported values of your device(s) use @option{list_formats}.
 Note that there is a FourCC @option{'pal '} that can also be used
 as @option{pal} (3 letters).
+Default behavior is autodetection of the input video format


... video format, if the hardware supports it.



 @item bm_v210
 This is a deprecated option, you can use @option{raw_format} instead.
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 2bd63ac..757f419 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -148,23 +148,10 @@ static DECKLINK_BOOL field_order_eq(enum AVFieldOrder 
field_order, BMDFieldDomin
 return false;
 }

-int ff_decklink_set_format(AVFormatContext *avctx,
-   int width, int height,
-   int tb_num, int tb_den,
-   enum AVFieldOrder field_order,
-   decklink_direction_t direction, int num)
-{
+void ff_decklink_set_duplex_mode(AVFormatContext *avctx) {
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-BMDDisplayModeSupport support;
-IDeckLinkDisplayModeIterator *itermode;
-IDeckLinkDisplayMode *mode;
-int i = 1;
 HRESULT res;
-
-av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, frame 
timing %d/%d, field order %d, direction %d, mode number %d, format code %s\n",
-width, height, tb_num, tb_den, field_order, direction, num, (cctx->format_code) ? 
cctx->format_code : "(unset)");
-
 if (ctx->duplex_mode) {
 DECKLINK_BOOL duplex_supported = false;

@@ -181,6 +168,24 @@ int ff_decklink_set_format(AVFormatContext *avctx,
 av_log(avctx, AV_LOG_WARNING, "Unable to set duplex mode, because it is 
not supported.\n");
 }
 }
+}


You factorized this out, but keep in mind that decklink_enc might also use this
to set duplex mode. (even if there is no option to do that at the moment). Also
it would make sense to rename the function and also put the input selection
logic here, because even if you autodetect, you should select the input
(sdi/hdmi/etc) first.

This factorization should be a separate patch for easier review.


+
+int ff_decklink_set_format(AVFormatContext *avctx,
+   int width, int height,
+   int tb_num, int tb_den,
+   enum AVFieldOrder field_order,
+   decklink_direction_t direction, int num)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+BMDDisplayModeSupport support;
+IDeckLinkDisplayModeIterator *itermode;
+IDeckLinkDisplayMode *mode;
+int i = 1;
+HRESULT res;
+
+av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, frame 
timing %d/%d, field order %d, direction %d, mode number %d, format code %s\n",
+width, height, tb_num, tb_den, field_order, direction, num, (cctx->format_code) ? 
cctx->format_code : "(unset)");

 if (direction == DIRECTION_IN) {
 int ret;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index b6acb01..f38fc14 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -31,6 +31,12 @@
 class decklink_output_callback;
 class decklink_input_callback;

+typedef enum autodetect_state {
+AUTODETECT_RESET = 0,


Maybe something like AUTODETECT_INACTIVE is a better name?


+AUTODETECT_START,
+AUTODETECT_DONE,
+} autodetect_state;
+
 typedef struct AVPacketQueue {
 AVPacketList *first_pkt, *last_pkt;
 int nb_packets;
@@ -95,6 +101,7 @@ struct decklink_ctx {
 pthread_mutex_t mutex;
 pthread_cond_t cond;
 int frames_buffer_available_spots;
+autodetect_state autodetect;

 int channels;
 int audio_depth;
@@ -134,6 +141,7 @@ static const BMDVideoConnection 
decklink_video_connection_map[] = {
 };

 HRESULT ff_decklink_get_display_n

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Rostislav Pehlivanov]

On 6 November 2017 at 00:30, Rostislav Pehlivanov 
wrote:

>
>
> On 5 November 2017 at 23:39, Aurelien Jacobs  wrote:
>
>> +*ptr++ = samples[RIGHT][i] >> 8;
>>
>
> How horrible, don't interleave the samples, leave them as planar.
> Change the output format in AVCodec and use
>
> AV_WN16(frame->data[][], samples[][] >>
> 8);
>
> To write the data. No point to convert to interleaved when the data's
> planar.
>
>
>>
>> +
>> +*got_frame_ptr = 1;
>> +return avpkt->size - len;
>>
>
> ?
> Decoders should return the number of bytes read from the packet (if
> convenient) or the packet size, not some random digit.
>
>
>> +}
>> +
>> +static int aptx_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
>> + const AVFrame *frame, int *got_packet_ptr)
>> +{
>> +AptXContext *s = avctx->priv_data;
>> +int16_t *ptr = (int16_t *)frame->data[0];
>> +int32_t samples[NB_CHANNELS][4];
>> +int ret;
>> +
>> +/* input must contain a multiple of 4 samples */
>> +if (frame->nb_samples & 3 || frame->nb_samples == 0) {
>> +av_log(avctx, AV_LOG_ERROR, "Frame must have a multiple of 4
>> samples\n");
>> +return 0;
>> +}
>> +
>> +if ((ret = ff_alloc_packet2(avctx, avpkt, frame->nb_samples, 0)) < 0)
>> +return ret;
>> +
>> +for (int pos = 0; pos < frame->nb_samples; pos += 4) {
>> +for (int i = 0; i < 4; i++) {
>> +/* convert 16 bits interleaved input to 24 bits planar
>> samples */
>> +samples[LEFT][i]  = ptr[LEFT ] << 8;
>> +samples[RIGHT][i] = ptr[RIGHT] << 8;
>> +ptr += NB_CHANNELS;
>> +}
>>
>
> Once again use planar sample fmt and then 
> AV_RN16(&frame->data[][])
> to read them.
>
>
>> +
>> +aptx_encode_samples(s, samples, avpkt->data + pos);
>> +}
>> +
>> +*got_packet_ptr = 1;
>> +return 0;
>> +}
>> +
>> +
>> +#if CONFIG_APTX_DECODER
>> +AVCodec ff_aptx_decoder = {
>> +.name  = "aptx",
>> +.long_name = NULL_IF_CONFIG_SMALL("aptX (Audio
>> Processing Technology for Bluetooth)"),
>> +.type  = AVMEDIA_TYPE_AUDIO,
>> +.id= AV_CODEC_ID_APTX,
>> +.priv_data_size= sizeof(AptXContext),
>> +.init  = aptx_init,
>> +.decode= aptx_decode_frame,
>> +.capabilities  = AV_CODEC_CAP_DR1,
>> +.channel_layouts   = (const uint64_t[]) { AV_CH_LAYOUT_STEREO,
>> 0},
>> +.sample_fmts   = (const enum AVSampleFormat[]) {
>> AV_SAMPLE_FMT_S16,
>>
>
> Change to AV_SAMPLE_FMT_S16P
>
>
>> +
>>  AV_SAMPLE_FMT_NONE },
>> +};
>> +#endif
>> +
>> +#if CONFIG_APTX_ENCODER
>> +AVCodec ff_aptx_encoder = {
>> +.name  = "aptx",
>> +.long_name = NULL_IF_CONFIG_SMALL("aptX (Audio
>> Processing Technology for Bluetooth)"),
>> +.type  = AVMEDIA_TYPE_AUDIO,
>> +.id= AV_CODEC_ID_APTX,
>> +.priv_data_size= sizeof(AptXContext),
>> +.init  = aptx_init,
>> +.encode2   = aptx_encode_frame,
>> +.capabilities  = AV_CODEC_CAP_VARIABLE_FRAME_SIZE,
>> +.channel_layouts   = (const uint64_t[]) { AV_CH_LAYOUT_STEREO,
>> 0},
>> +.sample_fmts   = (const enum AVSampleFormat[]) {
>> AV_SAMPLE_FMT_S16,
>>
>
> And here to AV_SAMPLE_FMT_S16P
>
>

Actually no, the sample format should be AV_SAMPLE_FMT_S32P

The code internally seems to use 24bit precision (for some retarded
reason), so NIHing format conversion to 16 bits is pointless as you lose
precision.
Just use a 32 bit sample format and shift down on the encoder side by 8
bits to get normalized 24 bit samples and shift up on the decoder side by 8
to get 32 bit samples.

It would have been better if the encoder and decoder were float tbh but oh
well, the people writing the code were paid to make it run on uselessly low
speed devices.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] sbc: add parser for SBC

[Aurelien Jacobs]

On Sun, Nov 05, 2017 at 11:43:37PM +, Rostislav Pehlivanov wrote:
> On 5 November 2017 at 23:35, Aurelien Jacobs  wrote:
> 
> > ---
> >  libavcodec/Makefile |   2 +
> >  libavcodec/allcodecs.c  |   2 +
> >  libavcodec/sbc_parser.c | 135 ++
> > ++
> >  3 files changed, 139 insertions(+)
> >  create mode 100644 libavcodec/sbc_parser.c
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 17648a1c3d..a15573748d 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -994,11 +994,13 @@ OBJS-$(CONFIG_PNG_PARSER)  +=
> > png_parser.o
> >  OBJS-$(CONFIG_MPEGAUDIO_PARSER)+= mpegaudio_parser.o
> >  OBJS-$(CONFIG_MPEGVIDEO_PARSER)+= mpegvideo_parser.o\
> >mpeg12.o mpeg12data.o
> > +OBJS-$(CONFIG_MSBC_PARSER) += sbc_parser.o
> >  OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o
> > vorbis_data.o
> >  OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
> >  OBJS-$(CONFIG_PNM_PARSER)  += pnm_parser.o pnm.o
> >  OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
> >  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
> > +OBJS-$(CONFIG_SBC_PARSER)  += sbc_parser.o
> >  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
> >  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
> >  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o vc1data.o  \
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index 95cf67ce20..02d241c4f3 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -717,11 +717,13 @@ static void register_all(void)
> >  REGISTER_PARSER(MPEG4VIDEO, mpeg4video);
> >  REGISTER_PARSER(MPEGAUDIO,  mpegaudio);
> >  REGISTER_PARSER(MPEGVIDEO,  mpegvideo);
> > +REGISTER_PARSER(MSBC,   msbc);
> >  REGISTER_PARSER(OPUS,   opus);
> >  REGISTER_PARSER(PNG,png);
> >  REGISTER_PARSER(PNM,pnm);
> >  REGISTER_PARSER(RV30,   rv30);
> >  REGISTER_PARSER(RV40,   rv40);
> > +REGISTER_PARSER(SBC,sbc);
> >  REGISTER_PARSER(SIPR,   sipr);
> >  REGISTER_PARSER(TAK,tak);
> >  REGISTER_PARSER(VC1,vc1);
> > diff --git a/libavcodec/sbc_parser.c b/libavcodec/sbc_parser.c
> > new file mode 100644
> > index 00..278ac6f84f
> > --- /dev/null
> > +++ b/libavcodec/sbc_parser.c
> > @@ -0,0 +1,135 @@
> > +/*
> > + * SBC parser
> > + *
> > + * Copyright (C) 2017  Aurelien Jacobs 
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +#include "sbc.h"
> > +#include "parser.h"
> > +
> > +typedef struct SBCParseContext {
> > +ParseContext pc;
> > +uint8_t header[3];
> > +int header_size;
> > +int buffered_size;
> > +} SBCParseContext;
> > +
> > +static int sbc_parse_header(AVCodecParserContext *s, AVCodecContext
> > *avctx,
> > +const uint8_t *data, size_t len)
> > +{
> > +static const int sample_rates[4] = { 16000, 32000, 44100, 48000 };
> > +int sr, blocks, mode, subbands, bitpool, channels, joint;
> > +int length;
> > +
> > +if (len < 3)
> > +return -1;
> > +
> > +if (data[0] == MSBC_SYNCWORD && data[1] == 0 && data[2] == 0) {
> > +avctx->channels = 1;
> > +avctx->sample_fmt = AV_SAMPLE_FMT_S16;
> > +avctx->sample_rate = 16000;
> > +avctx->frame_size = 120;
> > +s->duration = avctx->frame_size;
> > +return 57;
> > +}
> > +
> > +if (data[0] != SBC_SYNCWORD)
> > +return -2;
> > +
> > +sr   =   (data[1] >> 6) & 0x03;
> > +blocks   = (((data[1] >> 4) & 0x03) + 1) << 2;
> > +mode =   (data[1] >> 2) & 0x03;
> > +subbands = (((data[1] >> 0) & 0x01) + 1) << 2;
> > +bitpool  = data[2];
> > +
> > +channels = mode == SBC_MODE_MONO ? 1 : 2;
> > +joint= mode == SBC_MODE_JOINT_STEREO;
> > +
> > +length = 4 + (subbands * channels) / 2;
> > +if (channels == 1 || mode == SBC_MODE_DUA

Re: [FFmpeg-devel] [PATCH 1/3] sbc: implement SBC codec (low-complexity subband codec)

[Michael Niedermayer]

Hi 

On Mon, Nov 06, 2017 at 12:35:18AM +0100, Aurelien Jacobs wrote:
> This was originally based on libsbc, and was fully integrated into ffmpeg.
> ---
>  doc/general.texi |   2 +
>  libavcodec/Makefile  |   4 +
>  libavcodec/allcodecs.c   |   2 +
>  libavcodec/arm/Makefile  |   3 +
>  libavcodec/arm/sbcdsp_armv6.S| 245 ++
>  libavcodec/arm/sbcdsp_init_arm.c | 105 ++
>  libavcodec/arm/sbcdsp_neon.S | 714 
> +++
>  libavcodec/avcodec.h |   2 +
>  libavcodec/codec_desc.c  |  12 +
>  libavcodec/sbc.c | 316 +
>  libavcodec/sbc.h | 121 +++
>  libavcodec/sbcdec.c  | 469 +
>  libavcodec/sbcdec_data.c | 127 +++
>  libavcodec/sbcdec_data.h |  44 +++
>  libavcodec/sbcdsp.c  | 569 +++
>  libavcodec/sbcdsp.h  |  86 +
>  libavcodec/sbcdsp_data.c | 335 ++
>  libavcodec/sbcdsp_data.h |  57 
>  libavcodec/sbcenc.c  | 461 +
>  libavcodec/x86/Makefile  |   2 +
>  libavcodec/x86/sbcdsp.asm| 290 
>  libavcodec/x86/sbcdsp_init.c |  51 +++
>  22 files changed, 4017 insertions(+)
>  create mode 100644 libavcodec/arm/sbcdsp_armv6.S
>  create mode 100644 libavcodec/arm/sbcdsp_init_arm.c
>  create mode 100644 libavcodec/arm/sbcdsp_neon.S
>  create mode 100644 libavcodec/sbc.c
>  create mode 100644 libavcodec/sbc.h
>  create mode 100644 libavcodec/sbcdec.c
>  create mode 100644 libavcodec/sbcdec_data.c
>  create mode 100644 libavcodec/sbcdec_data.h
>  create mode 100644 libavcodec/sbcdsp.c
>  create mode 100644 libavcodec/sbcdsp.h
>  create mode 100644 libavcodec/sbcdsp_data.c
>  create mode 100644 libavcodec/sbcdsp_data.h
>  create mode 100644 libavcodec/sbcenc.c
>  create mode 100644 libavcodec/x86/sbcdsp.asm
>  create mode 100644 libavcodec/x86/sbcdsp_init.c

this seems to fail to build on x86-32

libavcodec/x86/sbcdsp_init.o
src/libavcodec/x86/sbcdsp.asm:251: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:264: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:267: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:269: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:270: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:271: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:273: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:274: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:275: error: invalid operands in non-64-bit mode
src/libavcodec/x86/sbcdsp.asm:276: error: invalid operands in non-64-bit mode
STRIP   libavcodec/x86/opus_pvq_search.o


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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] FFplay: progress bar feature proposal

[Steven Liu]

2017-11-06 4:36 GMT+08:00 Michael Niedermayer :
> On Thu, Apr 13, 2017 at 10:53:49AM -0500, Raymond Pierce wrote:
>> 13.04.2017, 09:40, "Steven Liu" :
>> > 2017-04-13 20:48 GMT+08:00 Raymond Pierce :
>> >
>> >>  Hi. Currently FFplay has no visible progress bar and it is hard to tell
>> >>  where a stream is currently positioned. So if one wants, for example, to
>> >>  rewind
>> >>  a little back relative to current position using right mouse click it is
>> >>  always
>> >>  guessing and trying.
>> >>
>> >>  I propose very simple 1-pixel progress bar which can be turned on or off
>> >>  during
>> >>  playback by pressing a button (I use 'L', from 'line'). By default the 
>> >> bar
>> >>  is off.
>> >>
>> >>  I choose bright green color (#00ff00) for the part to the left of a 
>> >> current
>> >>  position and pure black for the part to the right.
>> >>
>> >>  You can see how it looks on the attached image.
>> >>
>> >>  Draft patch is applied. One global variable ('static int
>> >>  show_progress_line')
>> >>  and one function ('static void video_progress_line_display(VideoState
>> >>  *is)')
>> >>  have been added. Also the existing 'video_display()' function has been
>> >>  moved
>> >>  below 'get_master_clock()' as the latter is used in the new function.
>> >>
>> >>  What do you think?
>> >>  ___
>> >>  ffmpeg-devel mailing list
>> >>  ffmpeg-devel@ffmpeg.org
>> >>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>> > git commit -a
>> > git format-patch -s -1
>> >
>> > You should use the command looks like the above git command to make patch
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> Hello, Steven. Thank you for the advice. New patch in the attachment.
>> Should I post a new message with the patch to ffmpeg-devel@ffmpeg.org list?
>
>>  ffplay.c |   52 +---
>>  1 file changed, 37 insertions(+), 15 deletions(-)
>> b7142d62e8a61dcd04b9cbc1c6c847918fea438a  
>> 0001-Add-FFplay-progress-bar-feature.patch
>> From e780cfa4330ae87cd4506ec2ccfe39ea045f2134 Mon Sep 17 00:00:00 2001
>> From: Ray Pierce 
>> Date: Thu, 13 Apr 2017 20:41:59 +0500
>> Subject: [PATCH] Add FFplay progress bar feature
>
> whats the status of this ?
I've tested it, LGTM, but need modify the patch to newest version of
code. because the new version of ffplay.c is moved to fftools
directory
and need add documentation .

>
> (just noticed this doesnt apply anymore)
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
>
> ___
> 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 1/3] sbc: implement SBC codec (low-complexity subband codec)

[Rostislav Pehlivanov]

On 5 November 2017 at 23:35, Aurelien Jacobs  wrote:

> This was originally based on libsbc, and was fully integrated into ffmpeg.
> ---
>  doc/general.texi |   2 +
>  libavcodec/Makefile  |   4 +
>  libavcodec/allcodecs.c   |   2 +
>  libavcodec/arm/Makefile  |   3 +
>  libavcodec/arm/sbcdsp_armv6.S| 245 ++
>  libavcodec/arm/sbcdsp_init_arm.c | 105 ++
>  libavcodec/arm/sbcdsp_neon.S | 714 ++
> +
>  libavcodec/avcodec.h |   2 +
>  libavcodec/codec_desc.c  |  12 +
>  libavcodec/sbc.c | 316 +
>  libavcodec/sbc.h | 121 +++
>  libavcodec/sbcdec.c  | 469 +
>  libavcodec/sbcdec_data.c | 127 +++
>  libavcodec/sbcdec_data.h |  44 +++
>  libavcodec/sbcdsp.c  | 569 +++
>  libavcodec/sbcdsp.h  |  86 +
>  libavcodec/sbcdsp_data.c | 335 ++
>  libavcodec/sbcdsp_data.h |  57 
>  libavcodec/sbcenc.c  | 461 +
>  libavcodec/x86/Makefile  |   2 +
>  libavcodec/x86/sbcdsp.asm| 290 
>  libavcodec/x86/sbcdsp_init.c |  51 +++
>  22 files changed, 4017 insertions(+)
>  create mode 100644 libavcodec/arm/sbcdsp_armv6.S
>  create mode 100644 libavcodec/arm/sbcdsp_init_arm.c
>  create mode 100644 libavcodec/arm/sbcdsp_neon.S
>  create mode 100644 libavcodec/sbc.c
>  create mode 100644 libavcodec/sbc.h
>  create mode 100644 libavcodec/sbcdec.c
>  create mode 100644 libavcodec/sbcdec_data.c
>  create mode 100644 libavcodec/sbcdec_data.h
>  create mode 100644 libavcodec/sbcdsp.c
>  create mode 100644 libavcodec/sbcdsp.h
>  create mode 100644 libavcodec/sbcdsp_data.c
>  create mode 100644 libavcodec/sbcdsp_data.h
>  create mode 100644 libavcodec/sbcenc.c
>  create mode 100644 libavcodec/x86/sbcdsp.asm
>  create mode 100644 libavcodec/x86/sbcdsp_init.c
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c4134424f0..2d541bf64a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -632,6 +632,8 @@ enum AVCodecID {
>  AV_CODEC_ID_ATRAC3AL,
>  AV_CODEC_ID_ATRAC3PAL,
>  AV_CODEC_ID_DOLBY_E,
> +AV_CODEC_ID_SBC,
> +AV_CODEC_ID_MSBC,
>
>
See below.


>  /* subtitle codecs */
>  AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID
> pointing at the start of subtitle codecs.
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 92bf1d2681..8d613507e0 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2859,6 +2859,18 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("ADPCM MTAF"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_SBC,
> +.type  = AVMEDIA_TYPE_AUDIO,
> +.name  = "sbc",
> +.long_name = NULL_IF_CONFIG_SMALL("SBC (low-complexity subband
> codec)"),
> +},
> +{
> +.id= AV_CODEC_ID_MSBC,
> +.type  = AVMEDIA_TYPE_AUDIO,
> +.name  = "msbc",
> +.long_name = NULL_IF_CONFIG_SMALL("mSBC (wideband speech mono
> SBC)"),
> +},
>

Is there a bitstream difference between the two? I don't think so, so you
should instead define FF_PROFILE_SBC_WB and use a single codec ID.


>
>  /* subtitle codecs */
>  {
> diff --git a/libavcodec/sbc.c b/libavcodec/sbc.c
> new file mode 100644
> index 00..99d02cc56a
> --- /dev/null
> +++ b/libavcodec/sbc.c
> @@ -0,0 +1,316 @@
> +/*
> + * Bluetooth low-complexity, subband codec (SBC)
> + *
> + * Copyright (C) 2017  Aurelien Jacobs 
> + * Copyright (C) 2012-2013  Intel Corporation
> + * Copyright (C) 2008-2010  Nokia Corporation
> + * Copyright (C) 2004-2010  Marcel Holtmann 
> + * Copyright (C) 2004-2005  Henryk Ploetz 
> + * Copyright (C) 2005-2008  Brad Midgley 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +/**
> + * @file
> + * SBC common functions for the encoder and decoder
> + */
> +
> +#include "avcodec.h"
> +#include "sbc.h"
> +
> +/*
> +

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Aaron Levinson]

See comments below.

Aaron Levinson

On 11/5/2017 4:49 PM, Marton Balint wrote:


On Fri, 27 Oct 2017, Jeyapal, Karthick wrote:


Please find the patch attached.



Thanks, below some comments:


From b18679b91a79f5e23a5ad23ae70f3862a34ddfb8 Mon Sep 17 00:00:00 2001
From: Karthick J 
Date: Fri, 27 Oct 2017 12:00:23 +0530
Subject: [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input 
format


When -format_code is not specified autodetection will happen
---
 doc/indevs.texi |  1 +
 libavdevice/decklink_common.cpp | 33 ++-
 libavdevice/decklink_common.h   |  8 +
 libavdevice/decklink_dec.cpp    | 70 
+++--

 4 files changed, 89 insertions(+), 23 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index d308bbf..74bfcc5 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -238,6 +238,7 @@ This sets the input video format to the format 
given by the FourCC. To see

 the supported values of your device(s) use @option{list_formats}.
 Note that there is a FourCC @option{'pal '} that can also be used
 as @option{pal} (3 letters).
+Default behavior is autodetection of the input video format


... video format, if the hardware supports it.



 @item bm_v210
 This is a deprecated option, you can use @option{raw_format} instead.
diff --git a/libavdevice/decklink_common.cpp 
b/libavdevice/decklink_common.cpp

index 2bd63ac..757f419 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -148,23 +148,10 @@ static DECKLINK_BOOL field_order_eq(enum 
AVFieldOrder field_order, BMDFieldDomin

 return false;
 }

-int ff_decklink_set_format(AVFormatContext *avctx,
-   int width, int height,
-   int tb_num, int tb_den,
-   enum AVFieldOrder field_order,
-   decklink_direction_t direction, int num)
-{
+void ff_decklink_set_duplex_mode(AVFormatContext *avctx) {
 struct decklink_cctx *cctx = (struct decklink_cctx 
*)avctx->priv_data;

 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-    BMDDisplayModeSupport support;
-    IDeckLinkDisplayModeIterator *itermode;
-    IDeckLinkDisplayMode *mode;
-    int i = 1;
 HRESULT res;
-
-    av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size 
%dx%d, frame timing %d/%d, field order %d, direction %d, mode number 
%d, format code %s\n",
-    width, height, tb_num, tb_den, field_order, direction, num, 
(cctx->format_code) ? cctx->format_code : "(unset)");

-
 if (ctx->duplex_mode) {
 DECKLINK_BOOL duplex_supported = false;

@@ -181,6 +168,24 @@ int ff_decklink_set_format(AVFormatContext *avctx,
 av_log(avctx, AV_LOG_WARNING, "Unable to set duplex mode, 
because it is not supported.\n");

 }
 }
+}


You factorized this out, but keep in mind that decklink_enc might also 
use this
to set duplex mode. (even if there is no option to do that at the 
moment). Also

it would make sense to rename the function and also put the input selection
logic here, because even if you autodetect, you should select the input
(sdi/hdmi/etc) first.

This factorization should be a separate patch for easier review.


+
+int ff_decklink_set_format(AVFormatContext *avctx,
+   int width, int height,
+   int tb_num, int tb_den,
+   enum AVFieldOrder field_order,
+   decklink_direction_t direction, int num)
+{
+    struct decklink_cctx *cctx = (struct decklink_cctx 
*)avctx->priv_data;

+    struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+    BMDDisplayModeSupport support;
+    IDeckLinkDisplayModeIterator *itermode;
+    IDeckLinkDisplayMode *mode;
+    int i = 1;
+    HRESULT res;
+
+    av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size 
%dx%d, frame timing %d/%d, field order %d, direction %d, mode number 
%d, format code %s\n",
+    width, height, tb_num, tb_den, field_order, direction, num, 
(cctx->format_code) ? cctx->format_code : "(unset)");


 if (direction == DIRECTION_IN) {
 int ret;
diff --git a/libavdevice/decklink_common.h 
b/libavdevice/decklink_common.h

index b6acb01..f38fc14 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -31,6 +31,12 @@
 class decklink_output_callback;
 class decklink_input_callback;

+typedef enum autodetect_state {
+    AUTODETECT_RESET = 0,


Maybe something like AUTODETECT_INACTIVE is a better name?


+    AUTODETECT_START,
+    AUTODETECT_DONE,
+} autodetect_state;
+
 typedef struct AVPacketQueue {
 AVPacketList *first_pkt, *last_pkt;
 int nb_packets;
@@ -95,6 +101,7 @@ struct decklink_ctx {
 pthread_mutex_t mutex;
 pthread_cond_t cond;
 int frames_buffer_available_spots;
+    autodetect_state autodetect;

 int channels;
 int audio_depth;
@@ -134,6 +141,7 @@ stati

[FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 10, 30, 01 and 03 msa functions

[kaustubh.raste]

From: Kaustubh Raste 

Align the mask buffer to 64 bytes.
Load the specific destination bytes instead of MSA load and pack.
Remove unused macros and functions.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c | 1269 
 1 file changed, 751 insertions(+), 518 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index dd11f00..9c779bd 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -21,7 +21,7 @@
 #include "libavutil/mips/generic_macros_msa.h"
 #include "h264dsp_mips.h"
 
-static const uint8_t luma_mask_arr[16 * 8] = {
+static const uint8_t luma_mask_arr[16 * 6] __attribute__((aligned(0x40))) = {
 /* 8 width cases */
 0, 5, 1, 6, 2, 7, 3, 8, 4, 9, 5, 10, 6, 11, 7, 12,
 1, 4, 2, 5, 3, 6, 4, 7, 5, 8, 6, 9, 7, 10, 8, 11,
@@ -31,9 +31,6 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 0, 5, 1, 6, 2, 7, 3, 8, 16, 21, 17, 22, 18, 23, 19, 24,
 1, 4, 2, 5, 3, 6, 4, 7, 17, 20, 18, 21, 19, 22, 20, 23,
 2, 3, 3, 4, 4, 5, 5, 6, 18, 19, 19, 20, 20, 21, 21, 22,
-
-2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 24, 25,
-3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 24, 25, 26
 };
 
 #define AVC_CALC_DPADD_B_6PIX_2COEFF_SH(vec0, vec1, vec2, vec3, vec4, vec5,  \
@@ -356,414 +353,6 @@ static void avc_luma_hv_qrt_16x16_msa(const uint8_t 
*src_x,
 }
 }
 
-static void avc_luma_hz_qrt_and_aver_dst_4x4_msa(const uint8_t *src,
- int32_t src_stride,
- uint8_t *dst,
- int32_t dst_stride,
- uint8_t hor_offset)
-{
-uint8_t slide;
-v16i8 src0, src1, src2, src3;
-v16u8 dst0, dst1, dst2, dst3;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 out0, out1;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-v16u8 res0, res1;
-
-LD_SB3(&luma_mask_arr[48], 16, mask0, mask1, mask2);
-
-if (hor_offset) {
-slide = 3;
-} else {
-slide = 2;
-}
-
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-LD_UB4(dst, dst_stride, dst0, dst1, dst2, dst3);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
-HADD_SB2_SH(vec0, vec1, out0, out1);
-VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec2, vec3);
-DPADD_SB2_SH(vec2, vec3, minus5b, minus5b, out0, out1);
-VSHF_B2_SB(src0, src1, src2, src3, mask2, mask2, vec4, vec5);
-DPADD_SB2_SH(vec4, vec5, plus20b, plus20b, out0, out1);
-SRARI_H2_SH(out0, out1, 5);
-SAT_SH2_SH(out0, out1, 7);
-
-PCKEV_B2_UB(out0, out0, out1, out1, res0, res1);
-
-src0 = __msa_sld_b(src0, src0, slide);
-src1 = __msa_sld_b(src1, src1, slide);
-src2 = __msa_sld_b(src2, src2, slide);
-src3 = __msa_sld_b(src3, src3, slide);
-src0 = (v16i8) __msa_insve_w((v4i32) src0, 1, (v4i32) src1);
-src1 = (v16i8) __msa_insve_w((v4i32) src2, 1, (v4i32) src3);
-res0 = (v16u8) __msa_aver_s_b((v16i8) res0, src0);
-res1 = (v16u8) __msa_aver_s_b((v16i8) res1, src1);
-
-XORI_B2_128_UB(res0, res1);
-
-dst0 = (v16u8) __msa_insve_w((v4i32) dst0, 1, (v4i32) dst1);
-dst1 = (v16u8) __msa_insve_w((v4i32) dst2, 1, (v4i32) dst3);
-
-AVER_UB2_UB(res0, dst0, res1, dst1, dst0, dst1);
-
-ST4x4_UB(dst0, dst1, 0, 1, 0, 1, dst, dst_stride);
-}
-
-static void avc_luma_hz_qrt_and_aver_dst_8x8_msa(const uint8_t *src,
- int32_t src_stride,
- uint8_t *dst,
- int32_t dst_stride,
- uint8_t hor_offset)
-{
-uint8_t slide;
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3;
-v16i8 mask0, mask1, mask2;
-v16u8 dst0, dst1, dst2, dst3;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 vec6, vec7, vec8, vec9, vec10, vec11;
-v8i16 out0, out1, out2, out3;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-v16i8 res0, res1, res2, res3;
-
-LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
-
-if (hor_offset) {
-slide = 3;
-} else {
-slide = 2;
-}
-
-for (loop_cnt = 2; loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
-
-LD_UB4(dst, dst_stride, dst0, dst1, dst2, dst3);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec1);
-VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec2, vec3);
-HADD_SB4_SH(vec0, vec1, vec2, vec3, out0, out1, out2, out3);
-VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec4, vec5);
-VSHF_B2_SB(src2, src2, s

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

[kaustubh.raste]

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_bi_msa.c | 1140 +++---
 1 file changed, 685 insertions(+), 455 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_bi_msa.c b/libavcodec/mips/hevc_mc_bi_msa.c
index e9c9184..b17 100644
--- a/libavcodec/mips/hevc_mc_bi_msa.c
+++ b/libavcodec/mips/hevc_mc_bi_msa.c
@@ -3772,20 +3772,20 @@ static void hevc_hv_bi_4t_4x2_msa(uint8_t *src0_ptr,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter_x,
-  const int8_t *filter_y,
-  int32_t height)
+  const int8_t *filter_y)
 {
-v8i16 in0, in1;
+uint64_t tp0, tp1;
+v16u8 out;
+v8i16 in0 = { 0 };
 v16i8 src0, src1, src2, src3, src4;
 v8i16 filt0, filt1;
-v4i32 filt_h0, filt_h1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v8i16 filt_h0, filt_h1;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 v16i8 mask1;
 v8i16 filter_vec, const_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 dst0, dst1, dst2, dst3, dst4;
-v4i32 dst0_r, dst1_r;
-v8i16 dst10_r, dst32_r, dst21_r, dst43_r;
+v8i16 dst20, dst31, dst42, dst10, dst32, dst21, dst43, tmp;
+v4i32 dst0, dst1;
 
 src0_ptr -= (src_stride + 1);
 
@@ -3793,56 +3793,43 @@ static void hevc_hv_bi_4t_4x2_msa(uint8_t *src0_ptr,
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W2_SW(filter_vec, 0, filt_h0, filt_h1);
+SPLATI_W2_SH(filter_vec, 0, filt_h0, filt_h1);
 
 mask1 = mask0 + 2;
 
 const_vec = __msa_ldi_h(128);
 const_vec <<= 6;
 
-LD_SB3(src0_ptr, src_stride, src0, src1, src2);
-src0_ptr += (3 * src_stride);
-XORI_B3_128_SB(src0, src1, src2);
-
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec0, vec1);
-VSHF_B2_SB(src1, src1, src1, src1, mask0, mask1, vec2, vec3);
-VSHF_B2_SB(src2, src2, src2, src2, mask0, mask1, vec4, vec5);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
-dst1 = const_vec;
-DPADD_SB2_SH(vec2, vec3, filt0, filt1, dst1, dst1);
-dst2 = const_vec;
-DPADD_SB2_SH(vec4, vec5, filt0, filt1, dst2, dst2);
-ILVR_H2_SH(dst1, dst0, dst2, dst1, dst10_r, dst21_r);
-
-LD_SB2(src0_ptr, src_stride, src3, src4);
-LD_SH2(src1_ptr, src2_stride, in0, in1);
-in0 = (v8i16) __msa_ilvr_d((v2i64) in1, (v2i64) in0);
-XORI_B2_128_SB(src3, src4);
-/* row 3 */
-VSHF_B2_SB(src3, src3, src3, src3, mask0, mask1, vec0, vec1);
-dst3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst3, dst3);
-dst32_r = __msa_ilvr_h(dst3, dst2);
-dst0_r = HEVC_FILT_4TAP(dst10_r, dst32_r, filt_h0, filt_h1);
-dst0_r >>= 6;
-/* row 4 */
-VSHF_B2_SB(src4, src4, src4, src4, mask0, mask1, vec0, vec1);
-dst4 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst4, dst4);
-dst43_r = __msa_ilvr_h(dst4, dst3);
-dst1_r = HEVC_FILT_4TAP(dst21_r, dst43_r, filt_h0, filt_h1);
-dst1_r >>= 6;
-dst0_r = (v4i32) __msa_pckev_h((v8i16) dst1_r, (v8i16) dst0_r);
-dst0_r = (v4i32) __msa_adds_s_h((v8i16) dst0_r, in0);
-dst0_r = (v4i32) __msa_srari_h((v8i16) dst0_r, 7);
-dst0_r = (v4i32) CLIP_SH_0_255(dst0_r);
-
-dst0_r = (v4i32) __msa_pckev_b((v16i8) dst0_r, (v16i8) dst0_r);
-ST4x2_UB(dst0_r, dst, dst_stride);
+LD_SB5(src0_ptr, src_stride, src0, src1, src2, src3, src4);
+XORI_B5_128_SB(src0, src1, src2, src3, src4);
+
+LD2(src1_ptr, src2_stride, tp0, tp1);
+INSERT_D2_SH(tp0, tp1, in0);
+in0 = __msa_adds_s_h(in0, const_vec);
+
+VSHF_B2_SB(src0, src2, src0, src2, mask0, mask1, vec0, vec1);
+VSHF_B2_SB(src1, src3, src1, src3, mask0, mask1, vec2, vec3);
+VSHF_B2_SB(src2, src4, src2, src4, mask0, mask1, vec4, vec5);
+
+dst20 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
+dst31 = HEVC_FILT_4TAP_SH(vec2, vec3, filt0, filt1);
+dst42 = HEVC_FILT_4TAP_SH(vec4, vec5, filt0, filt1);
+
+ILVRL_H2_SH(dst31, dst20, dst10, dst32);
+ILVRL_H2_SH(dst42, dst31, dst21, dst43);
+
+dst0 = HEVC_FILT_4TAP(dst10, dst32, filt_h0, filt_h1);
+dst1 = HEVC_FILT_4TAP(dst21, dst43, filt_h0, filt_h1);
+dst0 >>= 6;
+dst1 >>= 6;
+tmp = __msa_pckev_h((v8i16) dst1, (v8i16) dst0);
+tmp = __msa_adds_s_h(tmp, in0);
+tmp = __msa_srari_h(tmp, 7);
+tmp = CLIP_SH_0_255_MAX_SATU(tmp);
+out = (v16u8) __msa_pckev_b((v16i8) tmp, (v16i8) tmp);
+ST4x2_UB(out, dst, dst_stride);
 }
 
 static void hevc_

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

[kaustubh.raste]

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_biw_msa.c | 1396 +++--
 1 file changed, 872 insertions(+), 524 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_biw_msa.c 
b/libavcodec/mips/hevc_mc_biw_msa.c
index 0e5f8a0..ea65f00 100644
--- a/libavcodec/mips/hevc_mc_biw_msa.c
+++ b/libavcodec/mips/hevc_mc_biw_msa.c
@@ -4495,26 +4495,25 @@ static void hevc_hv_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
  int32_t dst_stride,
  const int8_t *filter_x,
  const int8_t *filter_y,
- int32_t height,
  int32_t weight0,
  int32_t weight1,
  int32_t offset0,
  int32_t offset1,
  int32_t rnd_val)
 {
+uint64_t tp0, tp1;
 int32_t offset, weight;
-v8i16 in0, in1;
+v8i16 in0 = { 0 };
+v16u8 out;
 v16i8 src0, src1, src2, src3, src4;
 v8i16 filt0, filt1;
-v4i32 filt_h0, filt_h1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v8i16 filt_h0, filt_h1;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 v16i8 mask1;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec, tmp, weight_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 dst0, dst1, dst2, dst3, dst4;
-v4i32 dst0_r, dst1_r, dst0_l;
-v8i16 dst10_r, dst32_r, dst21_r, dst43_r;
-v4i32 weight_vec, offset_vec, rnd_vec;
+v8i16 dst20, dst31, dst42, dst10, dst32, dst21, dst43, tmp0, tmp1;
+v4i32 dst0, dst1, offset_vec, rnd_vec, const_vec;
 
 src0_ptr -= (src_stride + 1);
 
@@ -4522,10 +4521,9 @@ static void hevc_hv_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W2_SW(filter_vec, 0, filt_h0, filt_h1);
+SPLATI_W2_SH(filter_vec, 0, filt_h0, filt_h1);
 
 mask1 = mask0 + 2;
 
@@ -4533,56 +4531,44 @@ static void hevc_hv_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
 weight0 = weight0 & 0x;
 weight = weight0 | (weight1 << 16);
 
-const_vec = __msa_ldi_h(128);
+const_vec = __msa_fill_w((128 * weight1));
 const_vec <<= 6;
 offset_vec = __msa_fill_w(offset);
-weight_vec = __msa_fill_w(weight);
+weight_vec = (v8i16) __msa_fill_w(weight);
 rnd_vec = __msa_fill_w(rnd_val + 1);
+offset_vec += const_vec;
 
-LD_SB3(src0_ptr, src_stride, src0, src1, src2);
-src0_ptr += (3 * src_stride);
-XORI_B3_128_SB(src0, src1, src2);
+LD_SB5(src0_ptr, src_stride, src0, src1, src2, src3, src4);
+XORI_B5_128_SB(src0, src1, src2, src3, src4);
 
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec0, vec1);
-VSHF_B2_SB(src1, src1, src1, src1, mask0, mask1, vec2, vec3);
-VSHF_B2_SB(src2, src2, src2, src2, mask0, mask1, vec4, vec5);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
-dst1 = const_vec;
-DPADD_SB2_SH(vec2, vec3, filt0, filt1, dst1, dst1);
-dst2 = const_vec;
-DPADD_SB2_SH(vec4, vec5, filt0, filt1, dst2, dst2);
-ILVR_H2_SH(dst1, dst0, dst2, dst1, dst10_r, dst21_r);
+VSHF_B2_SB(src0, src2, src0, src2, mask0, mask1, vec0, vec1);
+VSHF_B2_SB(src1, src3, src1, src3, mask0, mask1, vec2, vec3);
+VSHF_B2_SB(src2, src4, src2, src4, mask0, mask1, vec4, vec5);
 
-LD_SB2(src0_ptr, src_stride, src3, src4);
-LD_SH2(src1_ptr, src2_stride, in0, in1);
-in0 = (v8i16) __msa_ilvr_d((v2i64) in1, (v2i64) in0);
-XORI_B2_128_SB(src3, src4);
-/* row 3 */
-VSHF_B2_SB(src3, src3, src3, src3, mask0, mask1, vec0, vec1);
-dst3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst3, dst3);
-dst32_r = __msa_ilvr_h(dst3, dst2);
-dst0_r = HEVC_FILT_4TAP(dst10_r, dst32_r, filt_h0, filt_h1);
-dst0_r >>= 6;
-/* row 4 */
-VSHF_B2_SB(src4, src4, src4, src4, mask0, mask1, vec0, vec1);
-dst4 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst4, dst4);
-dst43_r = __msa_ilvr_h(dst4, dst3);
-dst1_r = HEVC_FILT_4TAP(dst21_r, dst43_r, filt_h0, filt_h1);
-dst1_r >>= 6;
-dst1_r = (v4i32) __msa_pckev_h((v8i16) dst1_r, (v8i16) dst0_r);
+dst20 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
+dst31 = HEVC_FILT_4TAP_SH(vec2, vec3, filt0, filt1);
+dst42 = HEVC_FILT_4TAP_SH(vec4, vec5, filt0, filt1);
 
-ILVRL_H2_SW(dst1_r, in0, dst0_r, dst0_l);
-dst0_r = __msa_dpadd_s_w(offset_vec, (v8i16) dst0_r, (v8i16) weight_vec);
-dst0_l = __msa_dpadd_s_w(offset_vec, (v8i1

[FFmpeg-devel] [PATCH] examples/vaapi_encode: Add a VA-API encode example.

[Jun Zhao]

From d16f766363d9ecc240b0f8e025c2a8f91ea4775e Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 6 Nov 2017 14:45:27 +0800
Subject: [PATCH] examples/vaapi_encode: Add a VA-API encode example.

add a VA-API encode example, only support NV12 input, usage like:
./vaapi_encode 1920 1080 test.yuv test.h264

Signed-off-by: Jun Zhao 
Signed-off-by: Liu, Kaixuan 
---
 configure   |   2 +
 doc/examples/Makefile   |   1 +
 doc/examples/vaapi_encode.c | 308 
 3 files changed, 311 insertions(+)
 create mode 100644 doc/examples/vaapi_encode.c

diff --git a/configure b/configure
index 1b0f064607..2df0205e09 100755
--- a/configure
+++ b/configure
@@ -1524,6 +1524,7 @@ EXAMPLE_LIST="
 scaling_video_example
 transcode_aac_example
 transcoding_example
+vaapi_encode_example
 "
 
 EXTERNAL_AUTODETECT_LIBRARY_LIST="
@@ -3294,6 +3295,7 @@ resampling_audio_example_deps="avutil swresample"
 scaling_video_example_deps="avutil swscale"
 transcode_aac_example_deps="avcodec avformat swresample"
 transcoding_example_deps="avfilter avcodec avformat avutil"
+vaapi_encode_example_deps="avfilter avcodec avformat avutil"
 
 # EXTRALIBS_LIST
 cpu_init_extralibs="pthreads_extralibs"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 58afd71b85..da5af36532 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += 
resampling_audio
 EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
 EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
 EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
+EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
 
 EXAMPLES   := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
 EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c
new file mode 100644
index 00..02b1ac5a4a
--- /dev/null
+++ b/doc/examples/vaapi_encode.c
@@ -0,0 +1,308 @@
+/*
+ * Video Acceleration API (video encoding) encode sample
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Intel VAAPI-accelerated encoding example.
+ *
+ * @example vaapi_encode.c
+ * This example shows how to do VAAPI-accelerated encoding. now only support 
NV12
+ * raw file, usage like: vaapi_enc 1920 1080 input.yuv output.h264
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef struct FilterContext {
+AVFilterContext *buffersink_ctx;
+AVFilterContext *buffersrc_ctx;
+AVFilterGraph   *filter_graph;
+} FilterContext;
+
+static int width, height;
+static AVBufferRef *hw_device_ctx = NULL;
+
+static int init_filter(FilterContext *filter_ctx, char *args, AVBufferRef 
*hw_device_ctx)
+{
+char filter_spec[] = "format=nv12,hwupload";
+int  ret = 0, i = 0;
+const AVFilter *buffersrc, *buffersink;
+AVFilterContext *buffersrc_ctx, *buffersink_ctx;
+AVFilterInOut *outputs = avfilter_inout_alloc();
+AVFilterInOut *inputs  = avfilter_inout_alloc();
+AVFilterGraph *filter_graph = avfilter_graph_alloc();
+
+buffersrc = avfilter_get_by_name("buffer");
+buffersink = avfilter_get_by_name("buffersink");
+if (!buffersrc || !buffersink) {
+av_log(NULL, AV_LOG_ERROR, "filtering source or sink element not 
found\n");
+ret = AVERROR_UNKNOWN;
+goto fail;
+}
+
+ret = avfilter_graph_create_filter(&buffersrc_ctx, buffersrc, "in",
+   args, NULL, filter_graph);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Cannot create buffer source. Error 
code:%s\n", av_err2str(ret));
+goto fail;
+}
+ret = avfilter_graph_create_filter(&buffersink_ctx, buffersink, "out",
+   NULL, NULL, filter_graph);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Cannot create buffer sink. Error 
code:%s\n", av_err2str(ret));
+goto fail;
+}
+
+outputs->name   = av_strdup("in");
+outputs->filter_ctx = buffersrc_ctx;
+outputs->pad_idx= 0;
+outputs->next   = NULL;
+inputs->name= a