Re: [FFmpeg-devel] [PATCH 2/2] lavf: use a video frame pool for each link of the filtergraph
On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron
> wrote:
>
> > From: Matthieu Bouron
> >
> > ---
> > libavfilter/avfilter.c | 1 +
> > libavfilter/avfilter.h | 5 +
> > libavfilter/video.c| 38 +++---
> > 3 files changed, 33 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > index c5c3044..bec8f81 100644
> > --- a/libavfilter/avfilter.c
> > +++ b/libavfilter/avfilter.c
> > @@ -168,6 +168,7 @@ void avfilter_link_free(AVFilterLink **link)
> > return;
> >
> > av_frame_free(&(*link)->partial_buf);
> > +av_video_frame_pool_uninit(&(*link)->video_frame_pool);
> >
> > av_freep(link);
> > }
> > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> > index 7aac3cf..e7d0a65 100644
> > --- a/libavfilter/avfilter.h
> > +++ b/libavfilter/avfilter.h
> > @@ -509,6 +509,11 @@ struct AVFilterLink {
> > * Number of past frames sent through the link.
> > */
> > int64_t frame_count;
> > +
> > +/**
> > + * Video frame pool.
> > + */
> > +AVVideoFramePool *video_frame_pool;
> > };
> >
> > /**
> > diff --git a/libavfilter/video.c b/libavfilter/video.c
> > index 0274fc1..5b0b7f9 100644
> > --- a/libavfilter/video.c
> > +++ b/libavfilter/video.c
> > @@ -32,6 +32,8 @@
> > #include "internal.h"
> > #include "video.h"
> >
> > +#define BUFFER_ALIGN 32
> > +
> > AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w, int h)
> > {
> > return ff_get_video_buffer(link->dst->outputs[0], w, h);
> > @@ -42,21 +44,35 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link,
> > int w, int h)
> > * alloc & free cycle currently implemented. */
> > AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
> > {
> > -AVFrame *frame = av_frame_alloc();
> > -int ret;
> > +int pool_width = 0;
> > +int pool_height = 0;
> > +int pool_align = 0;
> > +enum AVPixelFormat pool_format = AV_PIX_FMT_NONE;
> >
> > -if (!frame)
> > -return NULL;
> > +if (!link->video_frame_pool) {
> > +link->video_frame_pool =
> > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > + link->format,
> > BUFFER_ALIGN);
> > +if (!link->video_frame_pool)
> > +return NULL;
> > +} else {
> > +if (av_video_frame_pool_get_config(link->video_frame_pool,
> > + &pool_width, &pool_height,
> > + &pool_format, &pool_align) <
> > 0) {
> > +return NULL;
> > +}
> >
> > -frame->width = w;
> > -frame->height = h;
> > -frame->format = link->format;
> > +if (pool_width != w || pool_height != h ||
> > +pool_format != link->format || pool_align != BUFFER_ALIGN) {
> >
> > -ret = av_frame_get_buffer(frame, 32);
> > -if (ret < 0)
> > -av_frame_free(&frame);
> > +av_video_frame_pool_uninit(&link->video_frame_pool);
> > +link->video_frame_pool =
> > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > +
> > link->format, BUFFER_ALIGN);
> > +if (!link->video_frame_pool)
> > +return NULL;
> > +}
> > +}
> >
> > -return frame;
> > +return av_video_frame_pool_get(link->video_frame_pool);
> > }
> >
> > AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
> > --
> > 2.6.3
> >
> >
> New patch attached. It does not rely anymore on the public AVVideoFramePool
> but rather on a private FFVideoFramePool declared inside libavfilter since
> I would like this API to cover both audio and video and maybe have the
> ability to reconfigure itself (without the need of changing the underlying
> pools if the width and height are lower than the original ones for example)
> before having it public. The plan is also to factorize this code with the
> one in libavcodec/FramePool as much as possible.
> Makefile|1
> avfilter.c |1
> avfilter.h |5 +
> framepool.c | 189
>
> framepool.h | 84 ++
> internal.h |1
> video.c | 42 -
> 7 files changed, 309 insertions(+), 14 deletions(-)
> 33310aff0621b3255a2723dd8b7388b825a8a5ae
> 0001-lavfi-use-a-video-frame-pool-for-each-link-of-the-fi.patch
> From a307a65bfcbde03bce21928024ab53a901cf3620 Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron
> Date: Fri, 11 Dec 2015 13:32:47 +0100
> Subject: [PATCH] lavfi: use a video frame pool for each link of the
> filtergraph
should be ok, assuming its the same as the previous patch just privatized
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out
Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files
> > using a random IV value would break any regression tests > see AVFMT_FLAG_BITEXACT > Fixed, only generating a random IV when bitexact is not enabled. Updated patch files attached. > > is this filling in a random IV that later is overridden ? > random_seed() can be slow so it would be better not to call it if > its value isnt used > I didn't think it's too significant since it happens only once per decrypted track, but anyway, fixed it as well. I changed av_aes_ctr_init so that it will initialize an empty IV, and exposed av_aes_ctr_set_random_iv. This later function is called only by the encoder (and only when bitexact is disabled). > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Thanks ! Eran 0001-libavutil-add-aes-ctr-support.patch Description: 0001-libavutil-add-aes-ctr-support.patch 0002-movenc-support-cenc-common-encryption.patch Description: 0002-movenc-support-cenc-common-encryption.patch 0003-mov-support-cenc-common-encryption.patch Description: 0003-mov-support-cenc-common-encryption.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files
> are these encrypted mp4 files some kind of standard encryption? > Yes, these files conform to the common encryption specification ISO/IEC 23001-7 > rephrased... will encrypted files created by ffmpeg be able to be > decrypted/decoded and played by quicktime? or any other player? > (assuming other player has the keys of course). > These files can be encrypted/decrypted by MP4Box: https://gpac.wp.mines-telecom.fr/mp4box/encryption/common-encryption/ I'm not familiar with any player that can play it as is, but it can be played once repackaged to MPEG-DASH. In this form, it can be played by Chrome with Widevine / Edge with PlayReady etc. The nginx module we maintain (https://github.com/kaltura/nginx-vod-module/) can perform this repackaging on the fly. If the file is encrypted on disk with the same key that should be used for playback, it will skip the encryption / decryption and serve the data as is (if the keys are different, it has to decrypt + re-encrypt) > thanks! > > -compn Thanks ! Eran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: use a video frame pool for each link of the filtergraph
On Tue, Dec 15, 2015 at 10:00 AM, Michael Niedermayer
wrote:
> On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> > On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > From: Matthieu Bouron
> > >
> > > ---
> > > libavfilter/avfilter.c | 1 +
> > > libavfilter/avfilter.h | 5 +
> > > libavfilter/video.c| 38 +++---
> > > 3 files changed, 33 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > > index c5c3044..bec8f81 100644
> > > --- a/libavfilter/avfilter.c
> > > +++ b/libavfilter/avfilter.c
> > > @@ -168,6 +168,7 @@ void avfilter_link_free(AVFilterLink **link)
> > > return;
> > >
> > > av_frame_free(&(*link)->partial_buf);
> > > +av_video_frame_pool_uninit(&(*link)->video_frame_pool);
> > >
> > > av_freep(link);
> > > }
> > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> > > index 7aac3cf..e7d0a65 100644
> > > --- a/libavfilter/avfilter.h
> > > +++ b/libavfilter/avfilter.h
> > > @@ -509,6 +509,11 @@ struct AVFilterLink {
> > > * Number of past frames sent through the link.
> > > */
> > > int64_t frame_count;
> > > +
> > > +/**
> > > + * Video frame pool.
> > > + */
> > > +AVVideoFramePool *video_frame_pool;
> > > };
> > >
> > > /**
> > > diff --git a/libavfilter/video.c b/libavfilter/video.c
> > > index 0274fc1..5b0b7f9 100644
> > > --- a/libavfilter/video.c
> > > +++ b/libavfilter/video.c
> > > @@ -32,6 +32,8 @@
> > > #include "internal.h"
> > > #include "video.h"
> > >
> > > +#define BUFFER_ALIGN 32
> > > +
> > > AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w, int h)
> > > {
> > > return ff_get_video_buffer(link->dst->outputs[0], w, h);
> > > @@ -42,21 +44,35 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink
> *link,
> > > int w, int h)
> > > * alloc & free cycle currently implemented. */
> > > AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
> > > {
> > > -AVFrame *frame = av_frame_alloc();
> > > -int ret;
> > > +int pool_width = 0;
> > > +int pool_height = 0;
> > > +int pool_align = 0;
> > > +enum AVPixelFormat pool_format = AV_PIX_FMT_NONE;
> > >
> > > -if (!frame)
> > > -return NULL;
> > > +if (!link->video_frame_pool) {
> > > +link->video_frame_pool =
> > > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > > +
> link->format,
> > > BUFFER_ALIGN);
> > > +if (!link->video_frame_pool)
> > > +return NULL;
> > > +} else {
> > > +if (av_video_frame_pool_get_config(link->video_frame_pool,
> > > + &pool_width, &pool_height,
> > > + &pool_format, &pool_align)
> <
> > > 0) {
> > > +return NULL;
> > > +}
> > >
> > > -frame->width = w;
> > > -frame->height = h;
> > > -frame->format = link->format;
> > > +if (pool_width != w || pool_height != h ||
> > > +pool_format != link->format || pool_align !=
> BUFFER_ALIGN) {
> > >
> > > -ret = av_frame_get_buffer(frame, 32);
> > > -if (ret < 0)
> > > -av_frame_free(&frame);
> > > +av_video_frame_pool_uninit(&link->video_frame_pool);
> > > +link->video_frame_pool =
> > > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > > +
> > > link->format, BUFFER_ALIGN);
> > > +if (!link->video_frame_pool)
> > > +return NULL;
> > > +}
> > > +}
> > >
> > > -return frame;
> > > +return av_video_frame_pool_get(link->video_frame_pool);
> > > }
> > >
> > > AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
> > > --
> > > 2.6.3
> > >
> > >
> > New patch attached. It does not rely anymore on the public
> AVVideoFramePool
> > but rather on a private FFVideoFramePool declared inside libavfilter
> since
> > I would like this API to cover both audio and video and maybe have the
> > ability to reconfigure itself (without the need of changing the
> underlying
> > pools if the width and height are lower than the original ones for
> example)
> > before having it public. The plan is also to factorize this code with the
> > one in libavcodec/FramePool as much as possible.
>
> > Makefile|1
> > avfilter.c |1
> > avfilter.h |5 +
> > framepool.c | 189
>
> > framepool.h | 84 ++
> > internal.h |1
> > video.c | 42 -
> > 7 files changed, 309 insertions(+), 14 deletions(-)
> > 33310aff0621b3255a2723dd8b7388b825a8a5ae
> 0001-lavfi-use-a-video-frame-pool-for-each-link-of-the-fi.patch
> > From a307a65bfcbde03bce21928024ab53a901cf3620 Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron
> > Date: Fri, 11 Dec 2015 13:32:47 +0100
> > Subject: [PATCH] lavfi: use a video frame poo
Re: [FFmpeg-devel] [PATCH] lavc/utils: use AVPixFmtDescriptor to probe palette formats
On Mon, Dec 14, 2015 at 6:18 PM, Michael Niedermayer wrote: > On Mon, Dec 14, 2015 at 05:49:48PM +0100, Matthieu Bouron wrote: > > From: Matthieu Bouron > > > > Also use the input frame format instead of the AVCodecContext one > according > > to the documentation of AVCodecContext.get_buffer2(). > > --- > > > > The current code rely on the fact that avpriv_set_systematic_pal2 > > will error out if the format is not a palette one (and that the error > > code is not checked). > > I find it makes more sense to probe this kind of formats using the > > AVPixFmtDescriptor flags. > > > > Also the documentation of AVCodecContext.get_buffer2() mention that the > > frame fields must be used instead of the AVCodecContext one. > > > > Matthieu > > > > --- > > libavcodec/utils.c | 13 +++-- > > 1 file changed, 11 insertions(+), 2 deletions(-) > > probably ok > Pushed. Thanks. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility
I found that the ffmpeg H.265 decoder can't run on the iOS platform when I enable the neon assembly code, it crashed when playing the H.265 clip. When disable the neon assembly code it works fine. What's the problem with the H.265 neon assembly code? Best regards, Zhuhb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> Hallo Michael,
>
> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> > > As I understand it, the temporary stack buffer "src_data" was
> > > introduced solely to avoid a compiler warning. I believe that a better
> > > way to solve this warning it to explicitly cast src->data. This
> > > should be somewhat faster, and just as safe.
> > >
> > > Signed-off-by: Jean Delvare
> > > Cc: Anton Khirnov
> > > ---
> > > libavutil/frame.c |4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > --- ffmpeg.orig/libavutil/frame.c 2015-12-14 18:42:06.272234579 +0100
> > > +++ ffmpeg/libavutil/frame.c 2015-12-14 19:05:18.501745387 +0100
> > > @@ -647,7 +647,6 @@ AVFrameSideData *av_frame_get_side_data(
> > >
> > > static int frame_copy_video(AVFrame *dst, const AVFrame *src)
> > > {
> > > -const uint8_t *src_data[4];
> > > int i, planes;
> > >
> > > if (dst->width < src->width ||
> > > @@ -659,9 +658,8 @@ static int frame_copy_video(AVFrame *dst
> > > if (!dst->data[i] || !src->data[i])
> > > return AVERROR(EINVAL);
> > >
> > > -memcpy(src_data, src->data, sizeof(src_data));
> > > av_image_copy(dst->data, dst->linesize,
> > > - src_data, src->linesize,
> > > + (const uint8_t **)src->data, src->linesize,
> >
> > I think this may be a aliasing violation and thus undefined
> > not that i like that or consider that sane
> > so if someone says iam wrong, i would certainly not be unhappy
>
> Why would it be an aliasing violation? We do not change the fundamental
> type of the pointer, we only add a const where the function wants it.
> For more simple pointer types the compiler would do it for us silently.
A. uint8_t and const uint8_t are distinct types
"Any type so far mentioned is an unqualified type. Each unqualified
type has several
qualified versions of its type,38) corresponding to the combinations of
one, two, or all
three of the const, volatile, and restrict qualifiers. The qualified or
unqualified
versions of a type are distinct types that belong to the same type
category and have the
same representation and alignment requirements."
B. a pointer to uint8_t and const uint8_t are not qualified types of the same
type
See the example in 6.2.5
"28 EXAMPLE 1 The type designated as ‘‘float *’’ has type ‘‘pointer to
float’’. Its type category is
pointer, not a floating type. The const-qualified version of this type
is designated as ‘‘float * const’’
whereas the type designated as ‘‘const float *’’ is not a qualified
type — its type is ‘‘pointer to constqualified
float’’ and is a pointer to a qualified type."
C. They are not compatible
"Two types have compatible type if their types are the same. Additional
rules for
determining whether two types are compatible are described in 6.7.2 for
type specifiers,
in 6.7.3 for type qualifiers, and in 6.7.5 for declarators.46)"
D. None of the aliasing exceptions seems to apply
"An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:76)
— atype compatible with the effective type of the object,
— aqualified version of a type compatible with the effective type of
the object,"
(its not a qualified version)
" — a type that is the signed or unsigned type corresponding to the
effective type of the object,
— a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a subaggregate or
contained union), or
— acharacter type."
(dont apply)
also:
"For two qualified types to be compatible, both shall have the
identically qualified version
of a compatible type; the order of type qualifiers within a list of
specifiers or qualifiers
does not affect the specified type."
"For two pointer types to be compatible, both shall be identically
qualified and both shall
be pointers to compatible types."
I quite possible could misinterpret or miss some parts though ...
>
> Also I can see 12 occurrences of the same cast for this parameter of
> function av_image_copy() in the ffmpeg code already. And over 20 more
> similar casts for similar parameters of other functions
> (ff_combine_frame, swr_convert, copy_picture_field...) So I'm not
> introducing anything new, just proposing one more of the same.
yes, I have no real oppinion on this except that C is insane or I am
and i dont really mind to apply the patch if thats what people prefer.
Any real compiler that follows this litterally and breaks the co
Re: [FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility
On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote: > I found that the ffmpeg H.265 decoder can't run on the iOS platform > when I enable the neon assembly code, it crashed when playing the > H.265 clip. When disable the neon assembly code it works fine. What's > the problem with the H.265 neon assembly code? You description is quite vague. Please read: https://ffmpeg.org/bugreports.html And do note that it will point you to the bug tracker (even if you can't provide gdb or valgrind output), not to the mailing lists. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
>> Hallo Michael,
>>
>> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
>> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
>> > > As I understand it, the temporary stack buffer "src_data" was
>> > > introduced solely to avoid a compiler warning. I believe that a better
>> > > way to solve this warning it to explicitly cast src->data. This
>> > > should be somewhat faster, and just as safe.
>> > >
>> > > Signed-off-by: Jean Delvare
>> > > Cc: Anton Khirnov
>> > > ---
>> > > libavutil/frame.c |4 +---
>> > > 1 file changed, 1 insertion(+), 3 deletions(-)
>> > >
>> > > --- ffmpeg.orig/libavutil/frame.c 2015-12-14 18:42:06.272234579 +0100
>> > > +++ ffmpeg/libavutil/frame.c 2015-12-14 19:05:18.501745387 +0100
>> > > @@ -647,7 +647,6 @@ AVFrameSideData *av_frame_get_side_data(
>> > >
>> > > static int frame_copy_video(AVFrame *dst, const AVFrame *src)
>> > > {
>> > > -const uint8_t *src_data[4];
>> > > int i, planes;
>> > >
>> > > if (dst->width < src->width ||
>> > > @@ -659,9 +658,8 @@ static int frame_copy_video(AVFrame *dst
>> > > if (!dst->data[i] || !src->data[i])
>> > > return AVERROR(EINVAL);
>> > >
>> > > -memcpy(src_data, src->data, sizeof(src_data));
>> > > av_image_copy(dst->data, dst->linesize,
>> > > - src_data, src->linesize,
>> > > + (const uint8_t **)src->data, src->linesize,
>> >
>> > I think this may be a aliasing violation and thus undefined
>> > not that i like that or consider that sane
>> > so if someone says iam wrong, i would certainly not be unhappy
>>
>> Why would it be an aliasing violation? We do not change the fundamental
>> type of the pointer, we only add a const where the function wants it.
>> For more simple pointer types the compiler would do it for us silently.
>
> A. uint8_t and const uint8_t are distinct types
> "Any type so far mentioned is an unqualified type. Each unqualified
> type has several
> qualified versions of its type,38) corresponding to the combinations
> of one, two, or all
> three of the const, volatile, and restrict qualifiers. The qualified
> or unqualified
> versions of a type are distinct types that belong to the same type
> category and have the
> same representation and alignment requirements."
> B. a pointer to uint8_t and const uint8_t are not qualified types of the same
> type
>See the example in 6.2.5
> "28 EXAMPLE 1 The type designated as ‘‘float *’’ has type ‘‘pointer
> to float’’. Its type category is
> pointer, not a floating type. The const-qualified version of this
> type is designated as ‘‘float * const’’
> whereas the type designated as ‘‘const float *’’ is not a qualified
> type — its type is ‘‘pointer to constqualified
> float’’ and is a pointer to a qualified type."
> C. They are not compatible
> "Two types have compatible type if their types are the same.
> Additional rules for
> determining whether two types are compatible are described in 6.7.2
> for type specifiers,
> in 6.7.3 for type qualifiers, and in 6.7.5 for declarators.46)"
> D. None of the aliasing exceptions seems to apply
> "An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:76)
> — atype compatible with the effective type of the object,
> — aqualified version of a type compatible with the effective type of
> the object,"
> (its not a qualified version)
>" — a type that is the signed or unsigned type corresponding to the
> effective type of the object,
> — a type that is the signed or unsigned type corresponding to a
> qualified version of the effective type of the object,
> — an aggregate or union type that includes one of the aforementioned
> types among its members (including, recursively, a member of a subaggregate
> or contained union), or
> — acharacter type."
> (dont apply)
>
> also:
> "For two qualified types to be compatible, both shall have the
> identically qualified version
> of a compatible type; the order of type qualifiers within a list of
> specifiers or qualifiers
> does not affect the specified type."
>
> "For two pointer types to be compatible, both shall be identically
> qualified and both shall
> be pointers to compatible types."
>
> I quite possible could misinterpret or miss some parts though ...
>
>
>>
>> Also I can see 12 occurrences of the same cast for this parameter of
>> function av_image_copy() in the ffmpeg code already. And over 20 more
>> similar casts for similar parameters of other functions
>> (ff_combine_frame, swr_convert, copy_picture_field...) So I'm not
>> introducing anything new, just proposing one more of the sa
Re: [FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility
On Tuesday 15 December 2015 11:29:58 am Moritz Barsnick wrote: > On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote: > > I found that the ffmpeg H.265 decoder can't run on the iOS platform > > when I enable the neon assembly code, it crashed when playing the > > H.265 clip. When disable the neon assembly code it works fine. What's > > the problem with the H.265 neon assembly code? > > You description is quite vague. Please read: > https://ffmpeg.org/bugreports.html > > And do note that it will point you to the bug tracker (even if you > can't provide gdb or valgrind output), A crash report without gdb information and without source code makes very little sense. > not to the mailing lists. The user mailing list is the right place for questions like the one above. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
On Tue, 15 Dec 2015 11:20:40 +0100, Michael Niedermayer wrote: > yes, I have no real oppinion on this except that C is insane or I am C is insane, who would dare to argue otherwise? ;-) More than the language itself, the fact that the compilers think they can reorder instructions the way they like has always frightened me. I prefer when tools obey to whoever if handling them, rather than making their own decisions. -- Jean Delvare SUSE L3 Support ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
Hi Hendrik, On Tue, 15 Dec 2015 11:31:57 +0100, Hendrik Leppkes wrote: > On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer > wrote: > > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote: > >> Also I can see 12 occurrences of the same cast for this parameter of > >> function av_image_copy() in the ffmpeg code already. And over 20 more > >> similar casts for similar parameters of other functions > >> (ff_combine_frame, swr_convert, copy_picture_field...) So I'm not > >> introducing anything new, just proposing one more of the same. > > > > yes, I have no real oppinion on this except that C is insane or I am > > and i dont really mind to apply the patch if thats what people prefer. > > Any real compiler that follows this litterally and breaks the code is > > IMHO a compiler one should avoid (quite independant of it being used > > for FFmpeg or other things) unless one wants to language lawyer around > > on such things instead of writing usefull code > > The "speed up" from removing a copy of 4 pointers is negligible as > well however, so maybe it should just be kept like it is. Originally I proposed this patch for performance reasons and also because I think it makes the code more readable. But seeing how the same cast is already present everywhere in the ffmpeg code, I would now also invoke consistency. There's no rationale for not doing the same here that is already done everywhere else. If it caused any problem we would know by now (and I verified that this patch passes the test suite, FWIW.) -- Jean Delvare SUSE L3 Support ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files
> > > > +struct AVAESCTR; > > Is this needed? > Indeed compiles for me without it, I matched the existing code in aes.h, and in general I prefer to define the structs in advance. If you prefer that I will remove it, please let me know > > +subsample_count = AV_RB16(sc->cenc.auxiliary_info_pos); > > +sc->cenc.auxiliary_info_pos += sizeof(uint16_t); > > I find the following significantly easier to read and understand: > > subsample_count = AV_RB16(sc->cenc.auxiliary_info_pos); > sc->cenc.auxiliary_info_pos += 2; > > But this may just be me, so feel free to ignore. > When it's a simple type my preference is to go with the sizeof, when it becomes slightly more than that, e.g.: + +ctx->auxiliary_info_size += 6; +ctx->subsample_count++; + I use a number (not sizeof(uint16_t) + sizeof(uint32_t)). But again it's all a matter of personal preference, if you want me to change it, let me know. > I suspect a fate test will be needed but this may be an > independent patch. > Ok, I will write one after this one gets approved :-) > Thank you, Carl Eugen > Thanks ! Eran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Bug #3823 (yuvj422p jpeg rtp enc) request for help
On Fri, Dec 11, 2015 at 3:02 PM, Andrey Utkin wrote: > On Wed, Dec 9, 2015 at 2:07 AM, Andrey Utkin > wrote: >> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p >> https://trac.ffmpeg.org/ticket/3823#comment:17 ? This pixel format >> becomes popular for IP cameras having no RTSP, and there are >> constantly issues with RTPizing it. I consider donation for fixing >> this. >> >> Thanks. > > Up. Sorry for annoyance, but we really need this badly. Any help is appreciated. -- Bluecherry developer. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Regarding the QuickTime palette issue in matroskadec.c
I don't really know which is worse, calling a function in mov.c, or "duplicating" (because I'll have to admit that it's a form of duplication in a technical sense) code in it. Because *if*, against all odds, there would have to be a change in the QuickTime color table handling, it's easy to forget one of the files in the process. The best solution would probably be to have a file 'qtpalette.c' with a function that is used by both matroskadec.c and mov.c. Now this is low priority once again, I'm just doubtful about my own approach. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
So, to get somewhere with this, would everybody be ok if I change this to remove the non-free marking, but keep it disabled by default for now? Or is putting that exception-text in nvenc.c enough to make enabling it by default viable? signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
On 15 Dec, Timo Rothenpieler wrote : > So, to get somewhere with this, would everybody be ok if I change this > to remove the non-free marking, but keep it disabled by default for now? I still don't understand why you want to fork this header into the FFmpeg tree. -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10 Dec, Philip Langdale wrote : > >Are we really talking about including a huge 3rd party header because > >distros are so lazy? What's next, do we add Windows headers to the > >FFmpeg tree, because MinGW lags severely behind the newest definitions > >like HEVC DXVA support? > > Admittedly, we are solving someone else's problem, but the header is > buried inside the SDK download which is hidden behind a click-through on > nvidia's web page. So it's not made available in a way that is readily > consumable by an end user or by a distribution vendor. Sorry, but that's true about most headers for Windows, for example, or for the Android SDK/NDK, or for the iOS SDK. If someone is able to compile FFmpeg, he's able to get access to a header. > With the new licencing, a distro vendor *could* take the header and package > it up themselves, but that's the sort of them that's exceptionally hard to > convince them to do. How is that an argument? When have the distributions being lazy on such a thing? On the opposite, I'm quite sure most Linux distributions do not want forking of other libraries/headers/code into other applications/libraries. See the current debates on Debian and Fedora and CSS/JS code. > And in the case of windows (where nvenc works too), there is no distro > vendor and nvidia certainly won't make the header more accessible than it > already is. The Windows SDK is not very accessible either. > If the goal is to make the feature as available as possible to as many users > as possible, then this is the way to do it. I believed the goal was to make the correct thing, not make one feature as available as possible. Else, why are you not forking libmfx into the tree then? or crystalhd headers (pure dlopening on Windows)? With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files
On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
[...]
> @@ -4007,6 +4008,147 @@ static int mov_read_free(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return 0;
> }
>
> +static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +uint32_t format = avio_rl32(pb);
> +enum AVCodecID id;
> +AVStream *st;
> +
> +if (c->fc->nb_streams < 1)
> +return 0;
> +st = c->fc->streams[c->fc->nb_streams - 1];
> +
> +id = mov_codec_id(st, format);
> +st->codec->codec_id = id;
doesnt this allow changing the codec id to anything from anything ?
this seems potentially risky
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/qsv: export session management functionality (variant #3)
Hello All, There is updated patch version initially introduced by Sven Dueking This patch expose 3 QSV functions as public. This is needed because the VPP needs access to these functions too. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-avcodec-qsv-export-session-management-functionality.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files
On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote: > > > > using a random IV value would break any regression tests > > see AVFMT_FLAG_BITEXACT > > > Fixed, only generating a random IV when bitexact is not enabled. > Updated patch files attached. > > > > > is this filling in a random IV that later is overridden ? > > random_seed() can be slow so it would be better not to call it if > > its value isnt used > > > I didn't think it's too significant since it happens only once per decrypted > track, but anyway, fixed it as well. > I changed av_aes_ctr_init so that it will initialize an empty IV, and exposed > av_aes_ctr_set_random_iv. > This later function is called only by the encoder (and only when bitexact is > disabled). > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Thanks ! > > Eran > Makefile |2 > aes_ctr.c | 129 > ++ > aes_ctr.h | 83 +++ > version.h |2 > 4 files changed, 215 insertions(+), 1 deletion(-) > 1704fc6a8cfb2922b3806a1d1e122b668f743408 > 0001-libavutil-add-aes-ctr-support.patch > From 8e6bc361924b6942b879b833c419bb7ea03b516f Mon Sep 17 00:00:00 2001 > From: erankor > Date: Mon, 7 Dec 2015 11:58:41 +0200 > Subject: [PATCH 1/3] libavutil: add aes-ctr support patch 1 and 2 applied if you want to maintain the code in the future then please send a patch that adds you to the maintainers file thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Allow specifying the program number for created programs
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/ffmpeg.texi |4 ++--
ffmpeg_opt.c| 22 +-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6307470..a38a32e 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -355,9 +355,9 @@ To set the language of the first audio stream:
ffmpeg -i INPUT -metadata:s:a:0 language=eng OUTPUT
@end example
-@item -program [title=@var{title}:]st=@var{stream}[:st=@var{stream}...]
(@emph{output})
+@item -program
[title=@var{title}:][program_num=@var{program_num}:]st=@var{stream}[:st=@var{stream}...]
(@emph{output})
-Creates a program with the specified @var{title} and adds the specified
+Creates a program with the specified @var{title}, @var{program_num} and adds
the specified
@var{stream}(s) to it.
@item -target @var{type} (@emph{output})
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index fd2c051..3df46da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2418,7 +2418,7 @@ loop_end:
for (i = 0; i < o->nb_program; i++) {
const char *p = o->program[i].u.str;
int progid = i+1;
-AVProgram *program = av_new_program(oc, progid);
+AVProgram *program;
while(*p) {
const char *p2 = av_get_token(&p, ":");
@@ -2428,6 +2428,25 @@ loop_end:
if(*p) p++;
key = av_get_token(&p2, "=");
+if (!key || !*p2)
+break;
+p2++;
+
+if (!strcmp(key, "program_num"))
+progid = strtol(p2, NULL, 0);
+}
+
+program = av_new_program(oc, progid);
+
+p = o->program[i].u.str;
+while(*p) {
+const char *p2 = av_get_token(&p, ":");
+char *key;
+if (!p2)
+break;
+if(*p) p++;
+
+key = av_get_token(&p2, "=");
if (!key) {
av_log(NULL, AV_LOG_FATAL,
"No '=' character in program string %s.\n",
@@ -2440,6 +2459,7 @@ loop_end:
if (!strcmp(key, "title")) {
av_dict_set(&program->metadata, "title", p2, 0);
+} else if (!strcmp(key, "program_num")) {
} else if (!strcmp(key, "st")) {
int st_num = strtol(p2, NULL, 0);
av_program_add_stream_index(oc, progid, st_num);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch question
Sorry if this may sound idiotic, but if I provide a unified patch for a file that is newer/different from the one I have here, it won't work, right? Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
From: Matthieu Bouron
---
Hi,
This commit is likely to break fate on arm since the current C code path
seems to use less precision.
How should I proceed to fix it ?
Matthieu
---
libswscale/arm/swscale_unscaled.c | 53 ---
libswscale/arm/yuv2rgb_neon.S | 77 ---
2 files changed, 119 insertions(+), 11 deletions(-)
diff --git a/libswscale/arm/swscale_unscaled.c
b/libswscale/arm/swscale_unscaled.c
index dbb0fb0..058ebea 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -63,6 +63,51 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext *context,
const uint8_t *src[
}
#endif
+#define YUV_TO_RGB_TABLE(precision)
\
+c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
+c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
+c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
+c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
+
+#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
\
+int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
\
+ uint8_t *dst, int linesize,
\
+ const uint8_t *srcY, int linesizeY,
\
+ const uint8_t *srcU, int linesizeU,
\
+ const uint8_t *srcV, int linesizeV,
\
+ const int16_t *table,
\
+ int y_offset,
\
+ int y_coeff);
\
+
\
+static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const
uint8_t *src[],\
+ int srcStride[], int srcSliceY, int
srcSliceH, \
+ uint8_t *dst[], int dstStride[]) {
\
+const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
\
+
\
+ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
\
+ dst[0] + srcSliceY * dstStride[0],
dstStride[0], \
+ src[0] + srcSliceY * srcStride[0],
srcStride[0], \
+ src[1] + (srcSliceY / 2) * srcStride[1],
srcStride[1], \
+ src[2] + (srcSliceY / 2) * srcStride[2],
srcStride[2], \
+ yuv2rgb_table,
\
+ c->yuv2rgb_y_offset >> 9,
\
+ c->yuv2rgb_y_coeff / ((precision) == 16 ? 1
<< 7 : 1));\
+
\
+return 0;
\
+}
\
+
+#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
\
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
\
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
\
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
\
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
\
+
+#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
\
+DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)
\
+DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(32)
\
+
+DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
+
#define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
\
int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
\
uint8_t *dst, int linesize,
\
@@ -75,12 +120,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const
uint8_t *src[], \
[FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call
From: Matthieu Bouron --- libswscale/arm/yuv2rgb_neon.S | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S index 01d8536..9f9dd2a 100644 --- a/libswscale/arm/yuv2rgb_neon.S +++ b/libswscale/arm/yuv2rgb_neon.S @@ -226,13 +226,7 @@ function ff_\ifmt\()_to_\ofmt\()_neon_\precision\(), export=1 vsubl.u8q15, d2, d10 @ q15 = V - 128 .endif -.ifc \precision,16 -process_16px_16 \ofmt -.endif - -.ifc \precision,32 -process_16px_32 \ofmt -.endif +process_16px_\precision \ofmt subsr8, r8, #16@ width -= 16 bgt 2b -- 2.6.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch question
Hi Mats, On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote: > Sorry if this may sound idiotic, but if I provide a unified patch for a > file that is newer/different from the one I have here, it won't work, right? "It depends." ;-) By the way, git handles this kind of stuff nicely. It may or may not work. Obviously, if the file hasn't changed upstream, your patch will still apply. a) Best case: The files haven't changed upstream, your diff still applies. b) Good case: Upstream changed only unrelated parts of those file, your diff applies, perhaps with an offset (i.e. shifted in line numbers). b2) Almost as good: The unrelated changes are close to your changes, so you get a so-called fuzz. c) Bad case: Related parts were changed. Your diff won't apply, you have to reintegrate your changes, perhaps even differently. d) Worse case: Your patch applies, but affected methods were incompatibly changed. This leads to build or runtime errors, or broken functionality. It's always a good idea to check upstream changes to see whether they affect your patch. Most likely, a) or b) applies, but you don't know until you've checked. :-) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
On 12/15/2015 10:44 AM, Jean Delvare wrote: > Originally I proposed this patch for performance reasons and also > because I think it makes the code more readable. But seeing how the > same cast is already present everywhere in the ffmpeg code, I would now > also invoke consistency. There's no rationale for not doing the same > here that is already done everywhere else. If it caused any problem we > would know by now (and I verified that this patch passes the test > suite, FWIW.) I'd argue we should fix those instead. Some work on that has already been done, such as 60392480181f24ebf3ab48d8ac3614705de90152. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch question
On 12/15/2015 05:49 PM, Moritz Barsnick wrote: Hi Mats, On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote: Sorry if this may sound idiotic, but if I provide a unified patch for a file that is newer/different from the one I have here, it won't work, right? "It depends." ;-) By the way, git handles this kind of stuff nicely. It may or may not work. Obviously, if the file hasn't changed upstream, your patch will still apply. a) Best case: The files haven't changed upstream, your diff still applies. b) Good case: Upstream changed only unrelated parts of those file, your diff applies, perhaps with an offset (i.e. shifted in line numbers). b2) Almost as good: The unrelated changes are close to your changes, so you get a so-called fuzz. c) Bad case: Related parts were changed. Your diff won't apply, you have to reintegrate your changes, perhaps even differently. d) Worse case: Your patch applies, but affected methods were incompatibly changed. This leads to build or runtime errors, or broken functionality. It's always a good idea to check upstream changes to see whether they affect your patch. Most likely, a) or b) applies, but you don't know until you've checked. :-) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks for the enlightening answer, Moritz. Now I don't possess an enormous amount of Git experience, but I guess it's best to get the latest version from Git before providing any new patches. It makes life easier for the potential testers, of course. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
On Tue, 15 Dec 2015 16:56:02 +, Derek Buitenhuis wrote: > On 12/15/2015 10:44 AM, Jean Delvare wrote: > > Originally I proposed this patch for performance reasons and also > > because I think it makes the code more readable. But seeing how the > > same cast is already present everywhere in the ffmpeg code, I would now > > also invoke consistency. There's no rationale for not doing the same > > here that is already done everywhere else. If it caused any problem we > > would know by now (and I verified that this patch passes the test > > suite, FWIW.) > > I'd argue we should fix those instead. Some work on that has already been > done, > such as 60392480181f24ebf3ab48d8ac3614705de90152. Looks like something different from what we were discussing here. -- Jean Delvare SUSE L3 Support ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fix http chunk encoding parsing
---
ffserver.c | 77 --
1 file changed, 50 insertions(+), 27 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 029771c..b7f9616 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -138,7 +138,7 @@ typedef struct HTTPContext {
int http_error;
int post;
int chunked_encoding;
-int chunk_size; /* 0 if it needs to be read */
+int chunk_size; /* 0 if it needs to be read; negative if reading chunk
footer */
struct HTTPContext *next;
int got_key_frame; /* stream 0 => 1, stream 1 => 2, stream 2=> 4 */
int64_t data_count;
@@ -2598,36 +2598,37 @@ static int http_receive_data(HTTPContext *c)
{
HTTPContext *c1;
int len, loop_run = 0;
+char buf[16];
+int buf_len = 0;
+
+if (c->chunked_encoding && c->chunk_size == 0) {
+for (;;) {
+/* read chunk header, if present */
+len = recv(c->fd, buf + buf_len, 1, 0);
+buf_len += len;
+
+if (len < 0) {
+if (ff_neterrno() != AVERROR(EAGAIN) &&
+ff_neterrno() != AVERROR(EINTR))
+/* error : close connection */
+goto fail;
+return 0;
+}
-while (c->chunked_encoding && !c->chunk_size &&
- c->buffer_end > c->buffer_ptr) {
-/* read chunk header, if present */
-len = recv(c->fd, c->buffer_ptr, 1, 0);
-
-if (len < 0) {
-if (ff_neterrno() != AVERROR(EAGAIN) &&
-ff_neterrno() != AVERROR(EINTR))
-/* error : close connection */
+if (len == 0 || ++loop_run > 10)
+/* end of connection or no chunk size : close it */
goto fail;
-return 0;
-} else if (len == 0) {
-/* end of connection : close it */
-goto fail;
-} else if (c->buffer_ptr - c->buffer >= 2 &&
- !memcmp(c->buffer_ptr - 1, "\r\n", 2)) {
-c->chunk_size = strtol(c->buffer, 0, 16);
-if (c->chunk_size == 0) // end of stream
-goto fail;
-c->buffer_ptr = c->buffer;
-break;
-} else if (++loop_run > 10)
-/* no chunk header, abort */
-goto fail;
-else
-c->buffer_ptr++;
+
+if (buf_len > 1 && !memcmp(buf + buf_len - 2, "\r\n", 2)) {
+c->chunk_size = strtol(buf, 0, 16);
+if (c->chunk_size == 0) // end of stream
+goto fail;
+break;
+}
+}
}
-if (c->buffer_end > c->buffer_ptr) {
+if (c->buffer_end > c->buffer_ptr && c->chunk_size > 0) {
len = recv(c->fd, c->buffer_ptr,
FFMIN(c->chunk_size, c->buffer_end - c->buffer_ptr), 0);
if (len < 0) {
@@ -2644,6 +2645,28 @@ static int http_receive_data(HTTPContext *c)
c->data_count += len;
update_datarate(&c->datarate, c->data_count);
}
+
+// Reading of chunk body is done. Now read 2 bytes of chunk footer.
+if (!c->chunk_size)
+c->chunk_size = -2;
+}
+
+if (c->chunked_encoding && c->chunk_size < 0) {
+while (c->chunk_size < 0) {
+len = recv(c->fd, buf, 1, 0);
+if (len < 0) {
+if (ff_neterrno() != AVERROR(EAGAIN) &&
+ff_neterrno() != AVERROR(EINTR))
+/* error : close connection */
+goto fail;
+return 0;
+}
+if (len == 0) {
+goto fail;
+}
+
+c->chunk_size += len;
+}
}
if (c->buffer_ptr - c->buffer >= 2 && c->data_count > FFM_PACKET_SIZE) {
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video
On 12/15/2015 5:23 PM, Jean Delvare wrote: > Looks like something different from what we were discussing here. In which way? That patch fixes pointer aliasing in the same way yours breaks it, AFAICT? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > > Hi, > > This commit is likely to break fate on arm since the current C code path > seems to use less precision. > > How should I proceed to fix it ? hmm can the precission of the C code path and any asm impl of it under bitexact (if they exist), be changed to higher precission without speedloss? if so that would be an option [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Several, actually, regarding the QuickTime palette issue in Matroska
Here is a *suggestion* for how to end the QuickTime palette in Matroska saga. I have created a new file 'qtpalette.c' with a function get_qtpalette(), that will be called from both matroskadec.c and mov.c. So, no more calling into another demuxer to get the palette, and no duplicated code, since it is more or less moved from mov.c to this new file. The mov_parse_stsd_video() function in mov.c is rather heavily modified as a consequence. Now, please forgive me for not splitting it up, but I hope that someone will be able to try it out in spite of this. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ libavformat-patches.tar.gz Description: GNU Zip compressed data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] mpegtsenc: Do not fail ADTS AAC muxing if the first frame is not ADTS
Fixes ticket 279.
---
libavformat/mpegtsenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 19032f3..a0dca4a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1519,8 +1519,6 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
if (!ts_st->amux) {
av_log(s, AV_LOG_ERROR, "AAC bitstream not in ADTS format "
"and extradata missing\n");
-if (!st->nb_frames)
-return AVERROR_INVALIDDATA;
} else {
av_init_packet(&pkt2);
pkt2.data = pkt->data;
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Several, actually, regarding the QuickTime palette issue in Matroska
On 12/15/2015 06:51 PM, Mats Peterson wrote: Here is a *suggestion* for how to end the QuickTime palette in Matroska saga. I have created a new file 'qtpalette.c' with a function get_qtpalette(), that will be called from both matroskadec.c and mov.c. So, no more calling into another demuxer to get the palette, and no duplicated code, since it is more or less moved from mov.c to this new file. The mov_parse_stsd_video() function in mov.c is rather heavily modified as a consequence. Now, please forgive me for not splitting it up, but I hope that someone will be able to try it out in spite of this. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Once again, test files with palettized video, both QuickTime and Matroska, can be found at https://drive.google.com/open?id=0B3_pEBoLs0faWElmM2FnLTZYNlk Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call
On Tue, Dec 15, 2015 at 05:46:08PM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > libswscale/arm/yuv2rgb_neon.S | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc
On 15.12.2015 08:17, Anton Khirnov wrote: > Can you share the sample that shows the problem? I could, but it's of no use for comparing with libopus, because their decoder errors out in an unrelated check. > From what I can see, libopus does not do any clipping at that point, so > something else must ensure that there is no overflow. Indeed, the real problem is just a silly typo... It might have been caused by the fact that the specification uses i and k in exactly the opposite way than the code. New patch attached. Best regards, Andreas >From d3b2c24d391d7871b978b3372f0f740730996ded Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Tue, 15 Dec 2015 22:00:31 +0100 Subject: [PATCH] opus_silk: fix typo causing overflow in silk_stabilize_lsf Due to this typo max_center can be too large, causing nlsf to be set to too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to overflow to a negative value, which is not allowed for nlsf and can cause an out of bounds read in silk_lsf2lpc. Signed-off-by: Andreas Cadhalpun --- libavcodec/opus_silk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c index 841d1ed..73526f9 100644 --- a/libavcodec/opus_silk.c +++ b/libavcodec/opus_silk.c @@ -824,7 +824,7 @@ static inline void silk_stabilize_lsf(int16_t nlsf[16], int order, const uint16_ /* upper extent */ for (i = order; i > k; i--) -max_center -= min_delta[k]; +max_center -= min_delta[i]; max_center -= min_delta[k] >> 1; /* move apart */ -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffm: reject a negative codec_id
On 15.12.2015 03:15, Michael Niedermayer wrote: > On Tue, Dec 15, 2015 at 01:19:01AM +0100, Andreas Cadhalpun wrote: >> On 15.12.2015 00:43, Michael Niedermayer wrote: >> ffmdec.c | 28 >> 1 file changed, 28 insertions(+) >> 5a300bbcfb78b1f24b8b7c572d420577b2a1b1f3 >> 0001-ffm-reject-invalid-codec_id-and-codec_type.patch >> From 3e16e9c3c32c9740c8851fd22bb60175852ffc25 Mon Sep 17 00:00:00 2001 >> From: Andreas Cadhalpun >> Date: Mon, 14 Dec 2015 22:11:55 +0100 >> Subject: [PATCH] ffm: reject invalid codec_id and codec_type > > LGTM Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
On 15.12.2015 14:42, Timo Rothenpieler wrote: > So, to get somewhere with this, would everybody be ok if I change this > to remove the non-free marking, but keep it disabled by default for now? That would be OK for me. > Or is putting that exception-text in nvenc.c enough to make enabling it > by default viable? I think so. But before doing any of this, there has to be an agreement, whether or not the header should be included at all. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow
On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote:
> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
>> exp2 suffices here. Some trivial (~ 4x) speedup is done in addition here by
>> reusing results.
>>
>
>> This is bit-identical to the old values.
>
> That may be true with a specific compiler and version but
> C makes no such guarantee unless iam missing something
Indeed, fpu behavior is largely uncontrolled. What I meant was that
under reasonable settings, there is no accuracy loss (tested with
clang and gcc). Basically, a priori it is not obvious that this change
is ok, but I tested and the values don't change.
For that matter, this is a rather minor point - many pow
implementations are anyway broken wrt precise < 1 ulp or better yet <
0.5 ulp rounding.
>
>
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/nellymoserenc.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>> index d998dba..e6023e3 100644
>> --- a/libavcodec/nellymoserenc.c
>> +++ b/libavcodec/nellymoserenc.c
>> @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext *avctx)
>>
>> /* Generate overlap window */
>> ff_init_ff_sine_windows(7);
>> -for (i = 0; i < POW_TABLE_SIZE; i++)
>> -pow_table[i] = pow(2, -i / 2048.0 - 3.0 + POW_TABLE_OFFSET);
>> +pow_table[0] = 1;
>> +pow_table[1024] = M_SQRT1_2;
>> +for (i = 1; i < 513; i++) {
>> +double tmp = exp2(-i / 2048.0);
>> +pow_table[i] = tmp;
>> +pow_table[1024-i] = M_SQRT1_2 / tmp;
>> +pow_table[1024+i] = tmp * M_SQRT1_2;
>> +pow_table[2048-i] = 0.5 / tmp;
>
> how much overall init time is gained by this ?
> that is time in ffmpeg main() from start to finish when just opening
> the file with no decoding aka ./ffmpeg -i somefile
Don't know, all I know is cycles are unnecessarily wasted. Will put in
cycle numbers.
> ?
>
> iam asking as this makes the intend of the loop harder to
> see/understand
> if this change is done then please add a comment explaining what the
> code does or maybe leave the unoptimized code in a comment
Comment will be added, sorry.
Note that the trick may be employed to a finer resolution, ie by
storing exp2(3/4) etc and utilizing in simple multiplications and
divisions. There will come a point where the overhead of the binary
size increase will dominate. I chose this as this is reasonably
readable and improves speed at minimal binary size impact.
>
> either way replacing pow -> exp2 LGTM
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>
> ___
> 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] lavu/frame: Optimize frame_copy_video
Hi Derek,
On Tue, 15 Dec 2015 17:39:23 +, Derek Buitenhuis wrote:
> On 12/15/2015 5:23 PM, Jean Delvare wrote:
> > Looks like something different from what we were discussing here.
>
> In which way?
>
> That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
I see two completely different things.
The change I proposed is specific to one function, only changes const
vs non-const, and the object under discussion is being accessed for
reading only (thus the const pointer.) It would remove a memcpy but
does not introduce a direct copy (with =.)
The change you pointed us to is touching very generic functions,
handling by nature a very wide variety of pointer types for both
reading and writing.
So just because the change you pointed us to may be good and desirable,
doesn't imply that the change I am proposing is bad and undesirable.
Side note #1: if gcc really considers pointer types that only differ by
"const" as different when it comes to code optimization, it is
seriously broken IMHO. Unfortunately the man page is quite vague on the
topic ("unless the types are almost the same", can you be more vague
please.)
Side note #2: if strict-aliasing optimizations can do so much damage
to your code that you end up doing
memcpy(arg, &(void *){ NULL }, sizeof(val));
to set a pointer to NULL, maybe you should consider building with
-fno-strict-aliasing.
Side note #3: I'm surprised this change was needed in the first place
as my understanding was that gcc would skip all strict-aliasing
optimizations for void pointers, which is what the affected functions
are handling. It's sad that the commit message is as vague as gcc's
manual page on the topic.
--
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] sonic: make sure num_taps is not larger than frame_size
If that is the case, the loop setting predictor_state in
sonic_decode_frame causes out of bounds reads of int_samples, which has
only frame_size number of elements.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/sonic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index 4ec7d89..8522de3 100644
--- a/libavcodec/sonic.c
+++ b/libavcodec/sonic.c
@@ -928,6 +928,13 @@ static av_cold int sonic_decode_init(AVCodecContext *avctx)
s->frame_size = s->channels*s->block_align*s->downsampling;
//avctx->frame_size = s->block_align;
+if (s->num_taps > s->frame_size) {
+av_log(avctx, AV_LOG_ERROR,
+ "number of taps %d larger than frame size %d\n",
+ s->num_taps, s->frame_size);
+return AVERROR_INVALIDDATA;
+}
+
av_log(avctx, AV_LOG_INFO, "Sonic: ver: %d.%d ls: %d dr: %d taps: %d
block: %d frame: %d downsamp: %d\n",
s->version, s->minor_version, s->lossless, s->decorrelation,
s->num_taps, s->block_align, s->frame_size, s->downsampling);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc
On Tue, Dec 15, 2015 at 10:41:15PM +0100, Andreas Cadhalpun wrote: > On 15.12.2015 08:17, Anton Khirnov wrote: > > Can you share the sample that shows the problem? > > I could, but it's of no use for comparing with libopus, because their > decoder errors out in an unrelated check. > > > From what I can see, libopus does not do any clipping at that point, so > > something else must ensure that there is no overflow. > > Indeed, the real problem is just a silly typo... > It might have been caused by the fact that the specification uses > i and k in exactly the opposite way than the code. > > New patch attached. > > Best regards, > Andreas > > > opus_silk.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 253c6f7d87dcadf712840f45dde18f5698b9c1d4 > 0001-opus_silk-fix-typo-causing-overflow-in-silk_stabiliz.patch > From d3b2c24d391d7871b978b3372f0f740730996ded Mon Sep 17 00:00:00 2001 > From: Andreas Cadhalpun > Date: Tue, 15 Dec 2015 22:00:31 +0100 > Subject: [PATCH] opus_silk: fix typo causing overflow in silk_stabilize_lsf > > Due to this typo max_center can be too large, causing nlsf to be set to > too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to > overflow to a negative value, which is not allowed for nlsf and can > cause an out of bounds read in silk_lsf2lpc. this looks nicer then the previous fixes thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sonic: make sure num_taps is not larger than frame_size
On Tue, Dec 15, 2015 at 11:50:21PM +0100, Andreas Cadhalpun wrote:
> If that is the case, the loop setting predictor_state in
> sonic_decode_frame causes out of bounds reads of int_samples, which has
> only frame_size number of elements.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/sonic.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
> index 4ec7d89..8522de3 100644
> --- a/libavcodec/sonic.c
> +++ b/libavcodec/sonic.c
> @@ -928,6 +928,13 @@ static av_cold int sonic_decode_init(AVCodecContext
> *avctx)
> s->frame_size = s->channels*s->block_align*s->downsampling;
> //avctx->frame_size = s->block_align;
>
> +if (s->num_taps > s->frame_size) {
shouldt this be something like
num_taps* channels > frame_size ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow
On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde wrote:
> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote:
>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
[...]
>>>
>>> diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>>> index d998dba..e6023e3 100644
>>> --- a/libavcodec/nellymoserenc.c
>>> +++ b/libavcodec/nellymoserenc.c
>>> @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext *avctx)
>>>
>>> /* Generate overlap window */
>>> ff_init_ff_sine_windows(7);
>>> -for (i = 0; i < POW_TABLE_SIZE; i++)
>>> -pow_table[i] = pow(2, -i / 2048.0 - 3.0 + POW_TABLE_OFFSET);
>>> +pow_table[0] = 1;
>>> +pow_table[1024] = M_SQRT1_2;
>>> +for (i = 1; i < 513; i++) {
>>> +double tmp = exp2(-i / 2048.0);
>>> +pow_table[i] = tmp;
>>> +pow_table[1024-i] = M_SQRT1_2 / tmp;
>>> +pow_table[1024+i] = tmp * M_SQRT1_2;
>>> +pow_table[2048-i] = 0.5 / tmp;
>>
>> how much overall init time is gained by this ?
>> that is time in ffmpeg main() from start to finish when just opening
>> the file with no decoding aka ./ffmpeg -i somefile
>
> Don't know, all I know is cycles are unnecessarily wasted. Will put in
> cycle numbers.
>
Here they are:
proposed: 424160 decicycles in pow_table, 512 runs, 0 skips
exp2 only: 1262093 decicycles in pow_table, 512 runs, 0 skips
old: 2849085 decicycles in pow_table, 512 runs, 0 skips
Thus old to exp2 is roughly 2.25x speedup, exp2 to proposed roughly 3x
speedup, net ~ 6.7x speedup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add support for HLS PLAYLIST types EVENT and VOD
Adds HLS flags to emit the X-PLAYLIST-TYPE tag to the top of generated
M3U8 files.
See the spec:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3.3.5
There was also an FFMPEG trac ticket #4571 that had this as a wishlist item:
https://trac.ffmpeg.org/ticket/4571
---
doc/muxers.texi | 6 ++
libavformat/hlsenc.c | 9 +
2 files changed, 15 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index b6d8823..cbbf23e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -368,6 +368,12 @@ Will produce the playlist, @file{out.m3u8}, and a single
segment file,
@item hls_flags delete_segments
Segment files removed from the playlist are deleted after a period of time
equal to the duration of the segment plus the duration of the playlist.
+
+@item hls_flags event
+Emit #EXT-X-PLAYLIST-TYPE:EVENT at the top of the M3U8 file.
+
+@item hls_flags vod
+Emit #EXT-X-PLAYLIST-TYPE:VOD at the top of the M3U8 file.
@end table
@anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index adcf7df..8db2088 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -61,6 +61,8 @@ typedef enum HLSFlags {
HLS_ROUND_DURATIONS = (1 << 2),
HLS_DISCONT_START = (1 << 3),
HLS_OMIT_ENDLIST = (1 << 4),
+HLS_EVENT_PLAYLIST = (1 << 5),
+HLS_VOD_PLAYLIST = (1 << 6),
} HLSFlags;
typedef struct HLSContext {
@@ -411,6 +413,11 @@ static int hls_window(AVFormatContext *s, int last)
}
avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
+if (hls->flags & HLS_EVENT_PLAYLIST) {
+avio_printf(out, "#EXT-X-PLAYLIST-TYPE:EVENT\n");
+} else if (hls->flags & HLS_VOD_PLAYLIST) {
+avio_printf(out, "#EXT-X-PLAYLIST-TYPE:VOD\n");
+}
av_log(s, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n",
sequence);
@@ -874,6 +881,8 @@ static const AVOption options[] = {
{"round_durations", "round durations in m3u8 to whole numbers", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX, E, "flags"},
{"discont_start", "start the playlist with a discontinuity tag", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
{"omit_endlist", "Do not append an endlist when ending stream", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX, E, "flags"},
+{"event", "set playlist type as 'EVENT'", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_EVENT_PLAYLIST }, 0, UINT_MAX, E, "flags"},
+{"vod", "set playlist type as 'VOD'", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_VOD_PLAYLIST }, 0, UINT_MAX, E, "flags"},
{ "use_localtime", "set filename expansion with strftime at segment
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
{"method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING,
{.str = NULL}, 0, 0,E},
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit
On 12/10/2015 8:02 PM, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/x86/hevc_sao_10bit.asm | 142 > +++--- > 1 file changed, 57 insertions(+), 85 deletions(-) Ping for patchset. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavu/eval: remove pow and exp2 for postfixes
These postfixes can be computed statically, and there is no need to
waste runtime resources.
Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/eval.c | 52
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavutil/eval.c b/libavutil/eval.c
index 44129d6..dcb8c56 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -57,27 +57,31 @@ typedef struct Parser {
static const AVClass eval_class = { "Eval", av_default_item_name, NULL,
LIBAVUTIL_VERSION_INT, offsetof(Parser,log_offset), offsetof(Parser,log_ctx) };
-static const int8_t si_prefixes['z' - 'E' + 1] = {
-['y'-'E']= -24,
-['z'-'E']= -21,
-['a'-'E']= -18,
-['f'-'E']= -15,
-['p'-'E']= -12,
-['n'-'E']= - 9,
-['u'-'E']= - 6,
-['m'-'E']= - 3,
-['c'-'E']= - 2,
-['d'-'E']= - 1,
-['h'-'E']= 2,
-['k'-'E']= 3,
-['K'-'E']= 3,
-['M'-'E']= 6,
-['G'-'E']= 9,
-['T'-'E']= 12,
-['P'-'E']= 15,
-['E'-'E']= 18,
-['Z'-'E']= 21,
-['Y'-'E']= 24,
+static const struct {
+double bin_val;
+double dec_val;
+int8_t exp;
+} si_prefixes['z' - 'E' + 1] = {
+['y'-'E']= { 8.271806125530276749e-25, 1e-24, -24 },
+['z'-'E']= { 8.4703294725430034e-22, 1e-21, -21 },
+['a'-'E']= { 8.6736173798840355e-19, 1e-18, -18 },
+['f'-'E']= { 8.8817841970012523e-16, 1e-15, -15 },
+['p'-'E']= { 9.0949470177292824e-13, 1e-12, -12 },
+['n'-'E']= { 9.3132257461547852e-10, 1e-9, -9 },
+['u'-'E']= { 9.5367431640625e-7, 1e-6, -6 },
+['m'-'E']= { 9.765625e-4, 1e-3, -3 },
+['c'-'E']= { 9.8431332023036951e-3, 1e-2, -2 },
+['d'-'E']= { 9.921256574801246e-2, 1e-1, -1 },
+['h'-'E']= { 1.0159366732596479e2, 1e2, 2 },
+['k'-'E']= { 1.024e3, 1e3, 3 },
+['K'-'E']= { 1.024e3, 1e3, 3 },
+['M'-'E']= { 1.048576e6, 1e6, 6 },
+['G'-'E']= { 1.073741824e9, 1e9, 9 },
+['T'-'E']= { 1.099511627776e12, 1e12, 12 },
+['P'-'E']= { 1.125899906842624e15, 1e15, 15 },
+['E'-'E']= { 1.152921504606847e18, 1e18, 18 },
+['Z'-'E']= { 1.1805916207174113e21, 1e21, 21 },
+['Y'-'E']= { 1.2089258196146292e24, 1e24, 24 },
};
static const struct {
@@ -105,13 +109,13 @@ double av_strtod(const char *numstr, char **tail)
d = pow(10, d / 20);
next += 2;
} else if (*next >= 'E' && *next <= 'z') {
-int e= si_prefixes[*next - 'E'];
+int e= si_prefixes[*next - 'E'].exp;
if (e) {
if (next[1] == 'i') {
-d*= pow( 2, e/0.3);
+d*= si_prefixes[*next - 'E'].bin_val;
next+=2;
} else {
-d*= pow(10, e);
+d*= si_prefixes[*next - 'E'].dec_val;
next++;
}
}
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: sbr_dequant optimization
This uses ff_exp2fi to get a speedup (~ 6x).
sample benchmark (Haswell, GNU/Linux):
old:
19102 decicycles in sbr_dequant,1023 runs, 1 skips
19002 decicycles in sbr_dequant,2045 runs, 3 skips
17638 decicycles in sbr_dequant,4093 runs, 3 skips
15825 decicycles in sbr_dequant,8189 runs, 3 skips
16404 decicycles in sbr_dequant, 16379 runs, 5 skips
new:
3063 decicycles in sbr_dequant,1024 runs, 0 skips
3049 decicycles in sbr_dequant,2048 runs, 0 skips
2968 decicycles in sbr_dequant,4096 runs, 0 skips
2818 decicycles in sbr_dequant,8191 runs, 1 skips
2853 decicycles in sbr_dequant, 16383 runs, 1 skips
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/aacsbr.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index d1e3a91..15956e3 100644
--- a/libavcodec/aacsbr.c
+++ b/libavcodec/aacsbr.c
@@ -33,6 +33,7 @@
#include "aacsbrdata.h"
#include "aacsbr_tablegen.h"
#include "fft.h"
+#include "internal.h"
#include "aacps.h"
#include "sbrdsp.h"
#include "libavutil/internal.h"
@@ -73,15 +74,22 @@ static void sbr_dequant(SpectralBandReplication *sbr, int
id_aac)
{
int k, e;
int ch;
-
+static const double exp2_tab[2] = {1, M_SQRT2};
if (id_aac == TYPE_CPE && sbr->bs_coupling) {
-float alpha = sbr->data[0].bs_amp_res ? 1.0f : 0.5f;
-float pan_offset = sbr->data[0].bs_amp_res ? 12.0f : 24.0f;
+int pan_offset = sbr->data[0].bs_amp_res ? 12 : 24;
for (e = 1; e <= sbr->data[0].bs_num_env; e++) {
for (k = 0; k < sbr->n[sbr->data[0].bs_freq_res[e]]; k++) {
-float temp1 = exp2f(sbr->data[0].env_facs_q[e][k] * alpha +
7.0f);
-float temp2 = exp2f((pan_offset -
sbr->data[1].env_facs_q[e][k]) * alpha);
-float fac;
+float temp1, temp2, fac;
+if (sbr->data[0].bs_amp_res) {
+temp1 = ff_exp2fi(sbr->data[0].env_facs_q[e][k] + 7);
+temp2 = ff_exp2fi(pan_offset -
sbr->data[1].env_facs_q[e][k]);
+}
+else {
+temp1 = ff_exp2fi((sbr->data[0].env_facs_q[e][k]>>1) + 7) *
+exp2_tab[sbr->data[0].env_facs_q[e][k] & 1];
+temp2 = ff_exp2fi((pan_offset -
sbr->data[1].env_facs_q[e][k])>>1) *
+exp2_tab[(pan_offset -
sbr->data[1].env_facs_q[e][k]) & 1];
+}
if (temp1 > 1E20) {
av_log(NULL, AV_LOG_ERROR, "envelope scalefactor overflow
in dequant\n");
temp1 = 1;
@@ -93,8 +101,8 @@ static void sbr_dequant(SpectralBandReplication *sbr, int
id_aac)
}
for (e = 1; e <= sbr->data[0].bs_num_noise; e++) {
for (k = 0; k < sbr->n_q; k++) {
-float temp1 = exp2f(NOISE_FLOOR_OFFSET -
sbr->data[0].noise_facs_q[e][k] + 1);
-float temp2 = exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
+float temp1 = ff_exp2fi(NOISE_FLOOR_OFFSET -
sbr->data[0].noise_facs_q[e][k] + 1);
+float temp2 = ff_exp2fi(12 - sbr->data[1].noise_facs_q[e][k]);
float fac;
av_assert0(temp1 <= 1E20);
fac = temp1 / (1.0f + temp2);
@@ -104,11 +112,13 @@ static void sbr_dequant(SpectralBandReplication *sbr, int
id_aac)
}
} else { // SCE or one non-coupled CPE
for (ch = 0; ch < (id_aac == TYPE_CPE) + 1; ch++) {
-float alpha = sbr->data[ch].bs_amp_res ? 1.0f : 0.5f;
for (e = 1; e <= sbr->data[ch].bs_num_env; e++)
for (k = 0; k < sbr->n[sbr->data[ch].bs_freq_res[e]]; k++){
-sbr->data[ch].env_facs[e][k] =
-exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
+if (sbr->data[ch].bs_amp_res)
+sbr->data[ch].env_facs[e][k] =
ff_exp2fi(sbr->data[ch].env_facs_q[e][k] + 6);
+else
+sbr->data[ch].env_facs[e][k] =
ff_exp2fi((sbr->data[ch].env_facs_q[e][k]>>1) + 6)
+ *
exp2_tab[sbr->data[ch].env_facs_q[e][k] & 1];
if (sbr->data[ch].env_facs[e][k] > 1E20) {
av_log(NULL, AV_LOG_ERROR, "envelope scalefactor
overflow in dequant\n");
sbr->data[ch].env_facs[e][k] = 1;
@@ -118,7 +128,7 @@ static void sbr_dequant(SpectralBandReplication *sbr, int
id_aac)
for (e = 1; e <= sbr->data[ch].bs_num_noise; e++)
for (k = 0; k < sbr->n_q; k++)
sbr->data[ch].noise_facs[e][k] =
-exp2f(NOISE_FLOOR_OFFSET -
sbr->data[ch].noise_facs_q[e][k]);
+ff_exp2fi(NOISE_FLOOR_OFFSET -
s
[FFmpeg-devel] [PATCH 1/2] lavc: move exp2fi to ff_exp2fi in internal.h
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/internal.h | 19 +++
libavcodec/jpeg2000.c | 18 ++
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 445b45a..afcf00d 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -242,6 +242,25 @@ static av_always_inline int64_t
ff_samples_to_time_base(AVCodecContext *avctx,
}
/**
+ * 2^(x) for integer x
+ * @return correctly rounded float
+ */
+static av_always_inline float ff_exp2fi(int x) {
+/* Normal range */
+if (-126 <= x && x <= 128)
+return av_int2float(x+127 << 23);
+/* Too large */
+else if (x > 128)
+return INFINITY;
+/* Subnormal numbers */
+else if (x > -150)
+return av_int2float(1 << (x+149));
+/* Negligibly small */
+else
+return 0;
+}
+
+/**
* Get a buffer for a frame. This is a wrapper around
* AVCodecContext.get_buffer() and should be used instead calling get_buffer()
* directly.
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index afd0966..b5b2dbf 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -31,6 +31,7 @@
#include "libavutil/imgutils.h"
#include "libavutil/mem.h"
#include "avcodec.h"
+#include "internal.h"
#include "jpeg2000.h"
#define SHL(a, n) ((n) >= 0 ? (a) << (n) : (a) >> -(n))
@@ -192,21 +193,6 @@ void ff_jpeg2000_set_significance(Jpeg2000T1Context *t1,
int x, int y,
// static const uint8_t lut_gain[2][4] = { { 0, 0, 0, 0 }, { 0, 1, 1, 2 } };
(unused)
-static inline float exp2fi(int x) {
-/* Normal range */
-if (-126 <= x && x <= 128)
-return av_int2float(x+127 << 23);
-/* Too large */
-else if (x > 128)
-return INFINITY;
-/* Subnormal numbers */
-else if (x > -150)
-return av_int2float(1 << (x+149));
-/* Negligibly small */
-else
-return 0;
-}
-
static void init_band_stepsize(AVCodecContext *avctx,
Jpeg2000Band *band,
Jpeg2000CodingStyle *codsty,
@@ -236,7 +222,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
* R_b = R_I + log2 (gain_b )
* see ISO/IEC 15444-1:2002 E.1.1 eqn. E-3 and E-4 */
gain= cbps;
-band->f_stepsize = exp2fi(gain - qntsty->expn[gbandno]);
+band->f_stepsize = ff_exp2fi(gain - qntsty->expn[gbandno]);
band->f_stepsize *= qntsty->mant[gbandno] / 2048.0 + 1.0;
break;
default:
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
