[FFmpeg-devel] Some questions about ffmpeg h264_qsv decoder

[Ron]

Hello everyone,

Some questions about ffmpeg h264_qsv decoder.

a) qsv decode h264 file found many duplicated frames.
 ffmpeg -c:v h264_qsv -i in.h264 -c:v h264_qsv -preset veryfast -bf 0 -refs 0 
-b:v 2000k -maxrate 2000k -r 29.97 out.h264
[h264_qsv @ 0x2801ae0] A decode call did not consume any data
Past duration 0.790398 too large
[h264_qsv @ 0x2801ae0] A decode call did not consume any data
Last message repeated 1 times
frame= 7172 fps=264 q=-0.0 Lsize=   58196kB time=00:03:59.63 
bitrate=1989.4kbits/s dup=4178 drop=0  
The input is only 100 seconds and 2997 frames, but output  7172 frames consit 
of 2997 original and 4178 dup.
But if the input file is a mp4 or the decoder is h264 (cmd: ffmpeg -c:v h264 -i 
in.h264 ... )  it works well !!!
Press [q] to stop, [?] for help
frame= 2994 fps=178 q=-0.0 Lsize=   24206kB time=00:01:39.76 
bitrate=1987.6kbits/s
video:24206kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.00%

b) A 1920x1080 video transcode to 1280x720, both CPU and GPU used more than 
1920x1080 to  1920x1080.
[root@localhost video]# time ffmpeg -y -i in.h264 -c:v h264_qsv  out.h264
frame= 2994 fps=145 q=-0.0 Lsize=   12294kB time=00:01:39.73 
bitrate=1009.8kbits/s
video:12294kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.00%

real0m20.878s
user1m14.787s
sys0m5.365s

[root@localhost video]# time ffmpeg  -y -i in.h264 -c:v h264_qsv -s 1280x720 
out.h264
frame= 2994 fps=112 q=-0.0 Lsize=   12194kB time=00:01:39.73 
bitrate=1001.6kbits/s
video:12194kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.00%

real0m26.884s
user1m11.273s
sys0m2.210s

Both 'top' and 'intel_gpu_top' show the second test used more CPU and GPU.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Voting committee

[anshul]

On Monday 14 September 2015 10:50 PM, Nicolas George wrote:

L'octidi 28 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit :

Looks mostly good to me. One thing I think that should be clarified is
the meaning of "linear combination" - I assume you meant a non-trivial
(exclude all zeros) linear combination over the nonnegative integers?

Thanks. You are right, this was imprecise. I meant linear combination with
total coefficients one; barycenter in other words. For example: 10 commits
are ok, 20 devel mails are ok, then 5 commits and 10 devel mails are ok too.

Of course, the value I have put are rather arbitrary. Please people feel
free to propose other values.

Regards,



Some thoughts on voting commitee:
It looks like maintainer list is ignored. Like if there is maintainer of 
XYZ feature. and decision of XYZ features are taken by committee then 
ignoring him just because he don't have lots of commit would be bad 
idea. Maintainer has taken responsibility so until he is not removed 
from maintainer list from that part and his place is not filled by 
someone else.


There could be conflicts like if XYZ part is not developed well or used 
by many people take snow or ffserver for example people want to remove 
it completely. Since majority of comitee don't like that feature then 
that does not mean that they are authorized to remove that part. If 
there is no maintainer for some part they can remove it to decrease work 
load but if there is maintainer they must not over rule him.


There should be restriction on voting committee to remove some part of 
FFMpeg, or I fear that bad voting committee can tear this project apart.


There may be one more scenario like there is committee of  20 people 
where 11 voted on X way and 9 voted on Y way. and at end of day 9 voter 
forked ffmpeg and made there own project.
So I would put one more restriction here that its not about what 
majority wants  X way or Y way there should be what reasons are given to 
follow X way or Y way. and confirmation that everyone understand pros 
and cons of particular way. No valid reason given against anyones wills 
other then majority voter should be avoided at any cost or we may loose 
developer.


-Anshul



___
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] Voting committee

[Thilo Borgmann]

Am 16.09.15 um 09:04 schrieb anshul:
> 
> 
> On Monday 14 September 2015 10:50 PM, Nicolas George wrote:
>> L'octidi 28 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
>>> Looks mostly good to me. One thing I think that should be clarified is
>>> the meaning of "linear combination" - I assume you meant a non-trivial
>>> (exclude all zeros) linear combination over the nonnegative integers?
>> Thanks. You are right, this was imprecise. I meant linear combination with
>> total coefficients one; barycenter in other words. For example: 10 commits
>> are ok, 20 devel mails are ok, then 5 commits and 10 devel mails are ok too.
>>
>> Of course, the value I have put are rather arbitrary. Please people feel
>> free to propose other values.
>>
>> Regards,
>>
>>
> Some thoughts on voting commitee:
> It looks like maintainer list is ignored. Like if there is maintainer of XYZ
> feature. and decision of XYZ features are taken by committee then ignoring him
> just because he don't have lots of commit would be bad idea. Maintainer has
> taken responsibility so until he is not removed from maintainer list from that
> part and his place is not filled by someone else.
> 
> There could be conflicts like if XYZ part is not developed well or used by 
> many
> people take snow or ffserver for example people want to remove it completely.
> Since majority of comitee don't like that feature then that does not mean that
> they are authorized to remove that part. If there is no maintainer for some 
> part
> they can remove it to decrease work load but if there is maintainer they must
> not over rule him.

Removing a maintained part of FFmpeg might be the extreme example - I think the
listed maintainer always deserves to be part of the voting committee whenever
the decision in question directly affects the maintainer's part of FFmpeg.


> There should be restriction on voting committee to remove some part of FFMpeg,
> or I fear that bad voting committee can tear this project apart.
> 
> There may be one more scenario like there is committee of  20 people where 11
> voted on X way and 9 voted on Y way. and at end of day 9 voter forked ffmpeg 
> and
> made there own project.
> So I would put one more restriction here that its not about what majority 
> wants 
> X way or Y way there should be what reasons are given to follow X way or Y 
> way.
> and confirmation that everyone understand pros and cons of particular way. No
> valid reason given against anyones wills other then majority voter should be
> avoided at any cost or we may loose developer.

I think that having a list of decisions deserving more than simple majority
might be overkill. At the end there will always be developers leaving for not
being happy about democratic decisions.

-Thilo

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

[FFmpeg-devel] [PATCH]lavf/mp3dec: Silence a warning if it makes no sense

[Carl Eugen Hoyos]

Hi!

Attached patch silences the following warning:
Skipping 0 bytes of junk at 5772990.

Please comment, Carl Eugen
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index d3080d7..17440b5 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -377,6 +377,7 @@ static int mp3_read_header(AVFormatContext *s)
 if (!(i&1023))
 ffio_ensure_seekback(s->pb, i + 1024 + 4);
 if (check(s->pb, off + i) >= 0) {
+if (i > 0)
 av_log(s, AV_LOG_INFO, "Skipping %d bytes of junk at 
%"PRId64".\n", i, off);
 avio_seek(s->pb, off + i, SEEK_SET);
 break;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/riff: Support ambient wav files

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> > New, imo better patch attached: Also supports float 

and 24bit.

> > and can never interfere when writing a wav file.
> >
> > Sorry, Carl Eugen
> 
> probably ok

Patch applied.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/mp3dec: Silence a warning if it makes no sense

[Hendrik Leppkes]

On Wed, Sep 16, 2015 at 12:16 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch silences the following warning:
> Skipping 0 bytes of junk at 5772990.

Please fix the indentation of the av_log line.

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

Re: [FFmpeg-devel] FFV1: Invalid parameter combination triggers FFV1.2

[Peter B.]

On 09/15/2015 08:47 PM, Michael Niedermayer wrote:
> On Tue, Sep 15, 2015 at 01:31:20AM +0200, Peter B. wrote:
>> I wanted to check what happens if someone uses an invalid parameter
>> combination:
>> "-c:v ffv1 -level 1 -slices 2"
>>
>> I expected an error message about invalid slice number, but the code
>> selected FFV1.2:
>>
>> "[ffv1 @ 0x391b060] Version 2 needed for requested features but version
>> 2 is experimental and not enabled"
> fixed

Thanks.

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

Re: [FFmpeg-devel] [PATCH] lavc/lavf: remove incompatible abi checks for the new 64bit fields

[Michael Niedermayer]

On Wed, Sep 16, 2015 at 01:53:10AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
> All the casts to int64_t for these fields in assorted files can be removed in
> a separate patch. I left those out so this patch was clean and easier to read.
> 
>  libavcodec/avcodec.h| 12 
>  libavcodec/options_table.h  | 11 ---
>  libavformat/avformat.h  | 45 
> +
>  libavformat/mpegts.c|  7 +--
>  libavformat/options_table.h |  8 
>  libavformat/rdt.c   |  4 
>  libavformat/utils.c | 10 +-
>  7 files changed, 11 insertions(+), 86 deletions(-)

LGTM

but maybe wait a bit before applying so others have a chance to
comment

thanks

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

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


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

[FFmpeg-devel] [PATCH]lavf/riff: Support ambient wav files

[Carl Eugen Hoyos]

Hi!

Attached patch allows to decode amb files as requested by Andy Furniss.

Please comment, Carl Eugen
diff --git a/libavformat/riff.c b/libavformat/riff.c
index be76b0a..9a11958 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -486,5 +486,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
 { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71, 0x44, 
0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
 { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB, 0x42, 
0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
 { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 0x11, 
0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
+{ AV_CODEC_ID_PCM_S16LE,{ 0x01, 0x00, 0x00, 0x00, 0x21, 0x07, 0xD3, 0x11, 
0x86, 0x44, 0xC8, 0xC1, 0xCA, 0x00, 0x00, 0x00 } },
 { AV_CODEC_ID_NONE }
 };
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/riff: Support ambient wav files

[Paul B Mahol]

On 9/16/15, Carl Eugen Hoyos  wrote:
> On Wednesday 16 September 2015 12:54:58 pm Paul B Mahol wrote:
>> On 9/16/15, Carl Eugen Hoyos  wrote:
>> > Hi!
>> >
>> > Attached patch allows to decode amb files as requested by Andy Furniss.
>> >
>> > Please comment, Carl Eugen
>>
>> lgtm
>
> New, imo better patch attached: Also supports float and can never
> interfere when writing a wav file.
>
> Sorry, Carl Eugen
>

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

[FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[Tobias Rapp]

Hi,

attached patch fixes ticket #4759 but I guess it is a bit too hasty to 
always abort transcoding if a single frame cannot be written. I guess it 
would be better to check for some "exit_on_error" like flag set but 
couldn't find out how to achieve that.


Any comments would be appreciated.

Regards,
Tobias
>From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Mon, 14 Sep 2015 12:06:22 +0200
Subject: [PATCH] avformat/mxfenc: stop encoding if unfilled video packet
 occurs

Fixes ticket #4759.
---
 libavformat/mxfenc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 84ce979..4eac812 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2262,7 +2262,7 @@ static void mxf_write_system_item(AVFormatContext *s)
 mxf_write_umid(s, 1);
 }
 
-static void mxf_write_d10_video_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+static int mxf_write_d10_video_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
 {
 MXFContext *mxf = s->priv_data;
 AVIOContext *pb = s->pb;
@@ -2286,9 +2286,12 @@ static void mxf_write_d10_video_packet(AVFormatContext *s, AVStream *st, AVPacke
 ffio_fill(s->pb, 0, pad);
 av_assert1(!(avio_tell(s->pb) & (KAG_SIZE-1)));
 } else {
-av_log(s, AV_LOG_WARNING, "cannot fill d-10 video packet\n");
+av_log(s, AV_LOG_ERROR, "cannot fill d-10 video packet\n");
 ffio_fill(s->pb, 0, pad);
+return AVERROR(EIO);
 }
+
+return 0;
 }
 
 static void mxf_write_d10_audio_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
@@ -2459,9 +2462,10 @@ static int mxf_write_packet(AVFormatContext *s, AVPacket *pkt)
 mxf_write_klv_fill(s);
 avio_write(pb, sc->track_essence_element_key, 16); // write key
 if (s->oformat == _mxf_d10_muxer) {
-if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO)
-mxf_write_d10_video_packet(s, st, pkt);
-else
+if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
+if ((err = mxf_write_d10_video_packet(s, st, pkt)) < 0)
+return err;
+} else
 mxf_write_d10_audio_packet(s, st, pkt);
 } else {
 klv_encode_ber4_length(pb, pkt->size); // write length
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH]lavf/mp3dec: Silence a warning if it makes no sense

[Paul B Mahol]

On 9/16/15, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch silences the following warning:
> Skipping 0 bytes of junk at 5772990.
>
> Please comment, Carl Eugen
>

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

Re: [FFmpeg-devel] [PATCH] vp9: add fullpel (avg) SIMD for 10/12bpp.

[Ronald S. Bultje]

Hi,

On Tue, Sep 15, 2015 at 9:38 PM, James Almer  wrote:

> On 9/15/2015 9:24 PM, Ronald S. Bultje wrote:
> > ---
> >  libavcodec/x86/vp9dsp_init_16bpp.c | 42
> ++
>
> Why not just add all this to vp9dsp_init.c and selectively initialize
> everything by checking the existing bpp argument in ff_vp9dsp_init_x86()?
> If you think you wont be able to reuse the existing macros in vp9dsp_init.c
> then i guess a new file would indeed be better to avoid bloat.
>
> Alternatively, macros that can be shared could be moved to a header and
> then used by both init files (like fpel_func and init_fpel).
>

Hm, yes, the macros for func decl should be shared, I'll re-do that part.

The init (func assignments) won't have anything shared, which is why I
thought it'd be useful to put it in separate files.

>  libavcodec/x86/vp9mc.asm   | 24 ++
> >  2 files changed, 58 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
> b/libavcodec/x86/vp9dsp_init_16bpp.c
> > index 3319012..25a7b2a 100644
> > --- a/libavcodec/x86/vp9dsp_init_16bpp.c
> > +++ b/libavcodec/x86/vp9dsp_init_16bpp.c
> > @@ -36,14 +36,22 @@ void ff_vp9_##avg##sz##_##opt(uint8_t *dst,
> ptrdiff_t dst_stride, \
>
> The naming scheme for other dsp functions in libavcodec is more like
> ff_codec_function_size_{8,10,12}_cpuflag(). Not too important for these as
> most are shared between all bpps, but for other functions it may be a good
> idea to rename the 8bit functions to follow the above naming scheme in
> preparation for the new 10/12bits ones.


I'll do that for avg, yes.

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

Re: [FFmpeg-devel] [PATCH]lavf/riff: Support ambient wav files

[Paul B Mahol]

On 9/16/15, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch allows to decode amb files as requested by Andy Furniss.
>
> Please comment, Carl Eugen
>

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

Re: [FFmpeg-devel] [PATCH]lavf/riff: Support ambient wav files

[Carl Eugen Hoyos]

On Wednesday 16 September 2015 12:54:58 pm Paul B Mahol wrote:
> On 9/16/15, Carl Eugen Hoyos  wrote:
> > Hi!
> >
> > Attached patch allows to decode amb files as requested by Andy Furniss.
> >
> > Please comment, Carl Eugen
>
> lgtm

New, imo better patch attached: Also supports float and can never 
interfere when writing a wav file.

Sorry, Carl Eugen
diff --git a/libavformat/riff.h b/libavformat/riff.h
index d6d91ef..e842940 100644
--- a/libavformat/riff.h
+++ b/libavformat/riff.h
@@ -107,6 +107,8 @@ extern const AVCodecGuid ff_codec_wav_guids[];
 
 #define FF_MEDIASUBTYPE_BASE_GUID \
 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA, 0x00, 0x38, 0x9B, 0x71
+#define FF_AMBISONIC_BASE_GUID \
+0x21, 0x07, 0xD3, 0x11, 0x86, 0x44, 0xC8, 0xC1, 0xCA, 0x00, 0x00, 0x00 
 
 static av_always_inline int ff_guidcmp(const void *g1, const void *g2)
 {
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 7eecdb2..26779e1 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -69,6 +69,8 @@ static void parse_waveformatex(AVIOContext *pb, 
AVCodecContext *c)
 
 ff_get_guid(pb, );
 if (!memcmp(subformat + 4,
+(const uint8_t[]){ FF_AMBISONIC_BASE_GUID }, 12) ||
+!memcmp(subformat + 4,
 (const uint8_t[]){ FF_MEDIASUBTYPE_BASE_GUID }, 12)) {
 c->codec_tag = AV_RL32(subformat);
 c->codec_id  = ff_wav_codec_get_id(c->codec_tag,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] About FFmpeg-Library

[Satinder Singh]

Hi ,


I want to use ffmpeg library in my C code for video processing purpose .
Please help me it is very urgent for me.

thanks !!

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

Re: [FFmpeg-devel] [PATCH] checkasm: add unit tests for v210enc

[Henrik Gramner]

On Tue, Sep 15, 2015 at 12:10 AM, James Almer  wrote:
> On 9/5/2015 8:13 PM, Henrik Gramner wrote:
> gcc asan complains about this change.
> http://fate.ffmpeg.org/report.cgi?time=20150914152533=x86_64-archlinux-gcc-asan

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

[FFmpeg-devel] [PATCH 2/2] vp9: add fullpel (avg) MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/vp9dsp_init.c   | 56 ++--
 libavcodec/x86/vp9dsp_init.h   | 12 
 libavcodec/x86/vp9dsp_init_16bpp.c | 58 ++---
 libavcodec/x86/vp9mc.asm   | 59 --
 4 files changed, 120 insertions(+), 65 deletions(-)

diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index 06698b8..7cdec4b 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -30,20 +30,20 @@
 
 #if HAVE_YASM
 
-decl_fpel_func(put,  4, mmx);
-decl_fpel_func(put,  8, mmx);
-decl_fpel_func(put, 16, sse);
-decl_fpel_func(put, 32, sse);
-decl_fpel_func(put, 64, sse);
-decl_fpel_func(avg,  4, mmxext);
-decl_fpel_func(avg,  8, mmxext);
-decl_fpel_func(avg, 16, sse2);
-decl_fpel_func(avg, 32, sse2);
-decl_fpel_func(avg, 64, sse2);
-decl_fpel_func(put, 32, avx);
-decl_fpel_func(put, 64, avx);
-decl_fpel_func(avg, 32, avx2);
-decl_fpel_func(avg, 64, avx2);
+decl_fpel_func(put,  4,   , mmx);
+decl_fpel_func(put,  8,   , mmx);
+decl_fpel_func(put, 16,   , sse);
+decl_fpel_func(put, 32,   , sse);
+decl_fpel_func(put, 64,   , sse);
+decl_fpel_func(avg,  4, _8, mmxext);
+decl_fpel_func(avg,  8, _8, mmxext);
+decl_fpel_func(avg, 16, _8, sse2);
+decl_fpel_func(avg, 32, _8, sse2);
+decl_fpel_func(avg, 64, _8, sse2);
+decl_fpel_func(put, 32,   , avx);
+decl_fpel_func(put, 64,   , avx);
+decl_fpel_func(avg, 32, _8, avx2);
+decl_fpel_func(avg, 64, _8, avx2);
 
 #define mc_func(avg, sz, dir, opt, type, f_sz) \
 void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
@@ -379,8 +379,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 } while (0)
 
 if (EXTERNAL_MMX(cpu_flags)) {
-init_fpel_func(4, 0,  4, put, mmx);
-init_fpel_func(3, 0,  8, put, mmx);
+init_fpel_func(4, 0,  4, put, , mmx);
+init_fpel_func(3, 0,  8, put, , mmx);
 if (!bitexact) {
 dsp->itxfm_add[4 /* lossless */][DCT_DCT] =
 dsp->itxfm_add[4 /* lossless */][ADST_DCT] =
@@ -393,8 +393,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 init_subpel2(4, 0, 4, put, mmxext);
 init_subpel2(4, 1, 4, avg, mmxext);
-init_fpel_func(4, 1,  4, avg, mmxext);
-init_fpel_func(3, 1,  8, avg, mmxext);
+init_fpel_func(4, 1,  4, avg, _8, mmxext);
+init_fpel_func(3, 1,  8, avg, _8, mmxext);
 dsp->itxfm_add[TX_4X4][DCT_DCT] = ff_vp9_idct_idct_4x4_add_mmxext;
 init_dc_ipred(4, mmxext);
 init_dc_ipred(8, mmxext);
@@ -402,9 +402,9 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 }
 
 if (EXTERNAL_SSE(cpu_flags)) {
-init_fpel_func(2, 0, 16, put, sse);
-init_fpel_func(1, 0, 32, put, sse);
-init_fpel_func(0, 0, 64, put, sse);
+init_fpel_func(2, 0, 16, put, , sse);
+init_fpel_func(1, 0, 32, put, , sse);
+init_fpel_func(0, 0, 64, put, , sse);
 init_ipred(16, sse, v, VERT);
 init_ipred(32, sse, v, VERT);
 }
@@ -412,9 +412,9 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 if (EXTERNAL_SSE2(cpu_flags)) {
 init_subpel3_8to64(0, put, sse2);
 init_subpel3_8to64(1, avg, sse2);
-init_fpel_func(2, 1, 16, avg, sse2);
-init_fpel_func(1, 1, 32, avg, sse2);
-init_fpel_func(0, 1, 64, avg, sse2);
+init_fpel_func(2, 1, 16, avg,  _8, sse2);
+init_fpel_func(1, 1, 32, avg,  _8, sse2);
+init_fpel_func(0, 1, 64, avg,  _8, sse2);
 init_lpf(sse2);
 dsp->itxfm_add[TX_4X4][ADST_DCT]  = ff_vp9_idct_iadst_4x4_add_sse2;
 dsp->itxfm_add[TX_4X4][DCT_ADST]  = ff_vp9_iadst_idct_4x4_add_sse2;
@@ -484,14 +484,14 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 init_dir_tm_h_ipred(32, avx);
 }
 if (EXTERNAL_AVX_FAST(cpu_flags)) {
-init_fpel_func(1, 0, 32, put, avx);
-init_fpel_func(0, 0, 64, put, avx);
+init_fpel_func(1, 0, 32, put, , avx);
+init_fpel_func(0, 0, 64, put, , avx);
 init_ipred(32, avx, v, VERT);
 }
 
 if (EXTERNAL_AVX2(cpu_flags)) {
-init_fpel_func(1, 1, 32, avg, avx2);
-init_fpel_func(0, 1, 64, avg, avx2);
+init_fpel_func(1, 1, 32, avg, _8, avx2);
+init_fpel_func(0, 1, 64, avg, _8, avx2);
 if (ARCH_X86_64) {
 #if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
 init_subpel3_32_64(0, put, avx2);
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 8c99c0d..792405e 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -23,16 +23,16 @@
 #ifndef AVCODEC_X86_VP9DSP_INIT_H
 #define AVCODEC_X86_VP9DSP_INIT_H
 
-#define decl_fpel_func(avg, sz, opt) \
-void ff_vp9_##avg##sz##_##opt(uint8_t *dst, ptrdiff_t 

Re: [FFmpeg-devel] About FFmpeg-Library

[Ronald S. Bultje]

Hi Satinder,

On Wed, Sep 16, 2015 at 7:56 AM, Satinder Singh  wrote:

> I want to use ffmpeg library in my C code for video processing purpose .
>

FFmpeg is indeed a great library for video processing purposes. Great
choice!

Please help me it is very urgent for me.


Your email does not contain any question, so it's unclear what you need
help with. Good luck!

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

Re: [FFmpeg-devel] [PATCH] AAC encoder: refactor to resynchronize MIPS port

[Claudio Freire]

On Tue, Sep 15, 2015 at 8:11 AM, Michael Niedermayer  wrote:
> On Tue, Sep 15, 2015 at 04:24:02AM -0300, Claudio Freire wrote:
>> This patch refactors the AAC coders to reuse code
>> between the MIPS port and the regular, portable C code.
>> There were two main functions that had to use
>> hand-optimized versions of quantization code:
>>  - search_for_quantizers_twoloop
>>  - codebook_trellis_rate
>>
>> Those two were split into their own template header
>> files so they can be inlined inside both the MIPS port
>> and the generic code. In each context, they'll link
>> to their specialized implementations, and thus be
>> optimized by the compiler.
>>
>> This approach I believe is better than maintaining
>> several copies of each function. As past experience has
>> proven, having to keep those in sync was error prone.
>> In this way, they will remain in sync by default.
>>
>> Also, an implementation of the reconstructed output
>> argument for the optimized quantize_and_encode
>> functions is included in the patch. While the current
>> implementation of search_for_pred still isn't using
>> it, future iterations of main prediction probably will.
>> It should not imply any measurable performance hit while
>> not being used.
>>
>>
>> Patch attached.
>>
>> I thought it was worth a review.
>>
>> It does include lots of copypaste.
>>
>> FTR, I tested MIPS 74Kf and x86_64 with make fate-aac
>
> full fate passes on qemu mips here as well!

If there's no objections then, I will be pushing it later today,
before it stops applying cleanly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] vp9: add fullpel (put) MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/Makefile|  3 +-
 libavcodec/x86/vp9dsp_init.c   | 73 +-
 libavcodec/x86/vp9dsp_init.h   | 39 
 libavcodec/x86/vp9dsp_init_16bpp.c | 71 
 libavcodec/x86/vp9mc.asm   | 18 --
 5 files changed, 161 insertions(+), 43 deletions(-)
 create mode 100644 libavcodec/x86/vp9dsp_init.h
 create mode 100644 libavcodec/x86/vp9dsp_init_16bpp.c

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 3c3cc1c..616f830 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -62,7 +62,8 @@ OBJS-$(CONFIG_V210_ENCODER)+= x86/v210enc_init.o
 OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_init.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += x86/vorbisdsp_init.o
 OBJS-$(CONFIG_VP6_DECODER) += x86/vp6dsp_init.o
-OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o
+OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o\
+  x86/vp9dsp_init_16bpp.o
 OBJS-$(CONFIG_WEBP_DECODER)+= x86/vp8dsp_init.o
 
 
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index f24cb67..06698b8 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -26,28 +26,24 @@
 #include "libavutil/x86/asm.h"
 #include "libavutil/x86/cpu.h"
 #include "libavcodec/vp9dsp.h"
+#include "libavcodec/x86/vp9dsp_init.h"
 
 #if HAVE_YASM
 
-#define fpel_func(avg, sz, opt) \
-void ff_vp9_##avg##sz##_##opt(uint8_t *dst, ptrdiff_t dst_stride, \
-  const uint8_t *src, ptrdiff_t src_stride, \
-  int h, int mx, int my)
-fpel_func(put,  4, mmx);
-fpel_func(put,  8, mmx);
-fpel_func(put, 16, sse);
-fpel_func(put, 32, sse);
-fpel_func(put, 64, sse);
-fpel_func(avg,  4, mmxext);
-fpel_func(avg,  8, mmxext);
-fpel_func(avg, 16, sse2);
-fpel_func(avg, 32, sse2);
-fpel_func(avg, 64, sse2);
-fpel_func(put, 32, avx);
-fpel_func(put, 64, avx);
-fpel_func(avg, 32, avx2);
-fpel_func(avg, 64, avx2);
-#undef fpel_func
+decl_fpel_func(put,  4, mmx);
+decl_fpel_func(put,  8, mmx);
+decl_fpel_func(put, 16, sse);
+decl_fpel_func(put, 32, sse);
+decl_fpel_func(put, 64, sse);
+decl_fpel_func(avg,  4, mmxext);
+decl_fpel_func(avg,  8, mmxext);
+decl_fpel_func(avg, 16, sse2);
+decl_fpel_func(avg, 32, sse2);
+decl_fpel_func(avg, 64, sse2);
+decl_fpel_func(put, 32, avx);
+decl_fpel_func(put, 64, avx);
+decl_fpel_func(avg, 32, avx2);
+decl_fpel_func(avg, 64, avx2);
 
 #define mc_func(avg, sz, dir, opt, type, f_sz) \
 void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
@@ -311,16 +307,13 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 {
 #if HAVE_YASM
 int cpu_flags;
-if (bpp != 8) return;
+if (bpp != 8) {
+ff_vp9dsp_init_16bpp_x86(dsp, bpp);
+return;
+}
 
 cpu_flags = av_get_cpu_flags();
 
-#define init_fpel(idx1, idx2, sz, type, opt) \
-dsp->mc[idx1][FILTER_8TAP_SMOOTH ][idx2][0][0] = \
-dsp->mc[idx1][FILTER_8TAP_REGULAR][idx2][0][0] = \
-dsp->mc[idx1][FILTER_8TAP_SHARP  ][idx2][0][0] = \
-dsp->mc[idx1][FILTER_BILINEAR][idx2][0][0] = ff_vp9_##type##sz##_##opt
-
 #define init_subpel1(idx1, idx2, idxh, idxv, sz, dir, type, opt) \
 dsp->mc[idx1][FILTER_8TAP_SMOOTH ][idx2][idxh][idxv] = 
type##_8tap_smooth_##sz##dir##_##opt; \
 dsp->mc[idx1][FILTER_8TAP_REGULAR][idx2][idxh][idxv] = 
type##_8tap_regular_##sz##dir##_##opt; \
@@ -386,8 +379,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 } while (0)
 
 if (EXTERNAL_MMX(cpu_flags)) {
-init_fpel(4, 0,  4, put, mmx);
-init_fpel(3, 0,  8, put, mmx);
+init_fpel_func(4, 0,  4, put, mmx);
+init_fpel_func(3, 0,  8, put, mmx);
 if (!bitexact) {
 dsp->itxfm_add[4 /* lossless */][DCT_DCT] =
 dsp->itxfm_add[4 /* lossless */][ADST_DCT] =
@@ -400,8 +393,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 init_subpel2(4, 0, 4, put, mmxext);
 init_subpel2(4, 1, 4, avg, mmxext);
-init_fpel(4, 1,  4, avg, mmxext);
-init_fpel(3, 1,  8, avg, mmxext);
+init_fpel_func(4, 1,  4, avg, mmxext);
+init_fpel_func(3, 1,  8, avg, mmxext);
 dsp->itxfm_add[TX_4X4][DCT_DCT] = ff_vp9_idct_idct_4x4_add_mmxext;
 init_dc_ipred(4, mmxext);
 init_dc_ipred(8, mmxext);
@@ -409,9 +402,9 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 }
 
 if (EXTERNAL_SSE(cpu_flags)) {
-init_fpel(2, 0, 16, put, sse);
-init_fpel(1, 0, 32, put, sse);
-init_fpel(0, 0, 64, put, sse);
+init_fpel_func(2, 0, 16, put, sse);
+init_fpel_func(1, 0, 32, put, sse);
+init_fpel_func(0, 0, 64, put, sse);
 

Re: [FFmpeg-devel] About FFmpeg-Library

[Satinder Singh]

Hi ,

I have no idea how I can merge it in my c code. I follow a tutorial from
dranger.com but when I doing as per as dranger.com , I got large no. of
undefined function errors . So , I want your help , please help me how I
can merge ffmpeg library in my c code , give any example or some thing like
that which will helpful for me.

Thanks !!
Satinder singh


On Wed, Sep 16, 2015 at 6:52 PM, Ronald S. Bultje 
wrote:

> Hi Satinder,
>
> On Wed, Sep 16, 2015 at 7:56 AM, Satinder Singh 
> wrote:
>
> > I want to use ffmpeg library in my C code for video processing purpose .
> >
>
> FFmpeg is indeed a great library for video processing purposes. Great
> choice!
>
> Please help me it is very urgent for me.
>
>
> Your email does not contain any question, so it's unclear what you need
> help with. Good luck!
>
> Ronald
> ___
> 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] Voting committee

[Nicolas George]

Le decadi 30 fructidor, an CCXXIII, anshul a écrit :
> It looks like maintainer list is ignored. Like if there is maintainer of XYZ
> feature. and decision of XYZ features are taken by committee then ignoring
> him just because he don't have lots of commit would be bad idea. Maintainer
> has taken responsibility so until he is not removed from maintainer list
> from that part and his place is not filled by someone else.
> 
> There could be conflicts like if XYZ part is not developed well or used by
> many people take snow or ffserver for example people want to remove it
> completely. Since majority of comitee don't like that feature then that does
> not mean that they are authorized to remove that part. If there is no
> maintainer for some part they can remove it to decrease work load but if
> there is maintainer they must not over rule him.
> 
> There should be restriction on voting committee to remove some part of
> FFMpeg, or I fear that bad voting committee can tear this project apart.
> 
> There may be one more scenario like there is committee of  20 people where
> 11 voted on X way and 9 voted on Y way. and at end of day 9 voter forked
> ffmpeg and made there own project.

Thilo's reply already gives the gist of what I wanted to reply.

The current list of maintainers should probably be used to help establish
the "second stage" list of voters.

After that... Well, there is a basic assumption behind the rule set that I
propose: that the majority of developers mean well for the project, and
would vote accordingly.

If most voters agree on the principle "feature X has an active maintainer =>
it should not be removed", then they would vote NO to removing it, and there
is no need to make it a formal rule.

> So I would put one more restriction here that its not about what majority
> wants  X way or Y way there should be what reasons are given to follow X way
> or Y way. and confirmation that everyone understand pros and cons of
> particular way. No valid reason given against anyones wills other then
> majority voter should be avoided at any cost or we may loose developer.

You may notice that this is already in the rule set that I proposed:

# The reply must include, in its first sentence, an unambiguous statement of
# the nature of the reply and a terse rationale for it.

It is only for the "clear consensus" case, because I consider the "formal
vote" case to be a last resort: at this point, all arguments have been
discussed to death already.

To summarize it another way: having a voting process should not be an excuse
to vote like an egoistical asshole.

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] Voting committee

[Nicolas George]

Le nonidi 29 fructidor, an CCXXIII, Yayoi Ukai a écrit :
> > Thanks. You are right, this was imprecise. I meant linear combination with
> > total coefficients one; barycenter in other words. For example: 10 commits
> > are ok, 20 devel mails are ok, then 5 commits and 10 devel mails are ok too.
> >
> > Of course, the value I have put are rather arbitrary. Please people feel
> > free to propose other values.
> 
> Yes. There is an value and I will explain why later.
> 
> Well, unfortunately I couldn't quite understand after a certain point
> the point you tried to make
> but I would say don't worry about it. I mean you have been
> contributing more than... so many years..
> of course what you really care would be respected. I am sure.


I am really sorry, I read your mail several times and I do not understand
how it relates to mine.

Was something I wrote disparaging for Outreachy? I am not aware of it, but
if so, please point it to me.

Or do you think that the voting rules I proposed make FFmpeg as a project
less inclusive? Then can you suggest how to amend them?

Or... really, I can not see what. Sorry.

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] policy on "necro-bumping" patches

[Nicolas George]

Le nonidi 29 fructidor, an CCXXIII, Ronald S. Bultje a écrit :
> The shell wouldn't know the difference. It has to be an atexit() mechanism
> in the application cleaning up after itself. This isn't specific to the
> shell state changing - it applies more generally imo.

There is no atexit() when a program crashes due to a signal.

If ffmpeg crashes, it is a bug. We fix it, period.

If you frequently deal with programs that crash, possibly due to being a
developer, then you should configure your shell to restore the tty state. I
have done it more than fifteen years ago and did not regret it once since; I
am in fact dumbfounded that this is not the default behaviour, and even more
dumbfounded that smart people make so much fuss instead of applying this
simple solution.

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] [PATCH] AAC encoder: refactor to resynchronize MIPS port

[Nedeljko Babic]

>>>
>>>
>>> Patch attached.
>>>
>>> I thought it was worth a review.
>>>
>>> It does include lots of copypaste.
>>>
>>> FTR, I tested MIPS 74Kf and x86_64 with make fate-aac
>>
>> full fate passes on qemu mips here as well!
>
>If there's no objections then, I will be pushing it later today,
>before it stops applying cleanly.

LGTM regarding mips part. I have no objection.

This is very helpful. Thanks.

Regarding problem with ffserver, I don't think that the cause is the same with 
the one in:
http://fate.ffmpeg.org/log.cgi?time=20150914220602=compile=mips-linux-gcc-4.3.2

The problem on the link is caused by environment on which tests are being 
compiled and run.

You can send me your configuration line and how did you tested it (I am afraid 
that I didn't work with ffserver), so I can check what is going on.

Also, are you building it on some board, or are you cross compiling it?

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Nicolas George]

Le nonidi 29 fructidor, an CCXXIII, Clement Boesch a écrit :
> I don't like FFABSDIFF() patch because it creates a macro very much type
> specific, while all other FF macro around are type agnostic.

I agree, and I stick to the advice I already posted: define the macro
locally when needed.

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] policy on "necro-bumping" patches

[Ganesh Ajjanagadde]

On Wed, Sep 16, 2015 at 11:08 AM, Nicolas George  wrote:
> Le nonidi 29 fructidor, an CCXXIII, Ronald S. Bultje a écrit :
>> The shell wouldn't know the difference. It has to be an atexit() mechanism
>> in the application cleaning up after itself. This isn't specific to the
>> shell state changing - it applies more generally imo.
>
> There is no atexit() when a program crashes due to a signal.
>
> If ffmpeg crashes, it is a bug. We fix it, period.
>
> If you frequently deal with programs that crash, possibly due to being a
> developer, then you should configure your shell to restore the tty state. I
> have done it more than fifteen years ago and did not regret it once since; I
> am in fact dumbfounded that this is not the default behaviour, and even more
> dumbfounded that smart people make so much fuss instead of applying this
> simple solution.

This is why I ask for an example natural user script where terminal
trashing occurs. The fate trashing thing (and its fix) made sense -
fate is meant to find regressions, sometimes expressed as fatal
signals. Even in non fate scenarios, ordinary signals that are within
FFmpeg's scope and not the shell's (non fatal) go to the handler,
which will restore the tty state once it receives sufficiently many
signals. Fatal signals should be very rare for non developers, and are
bugs with FFmpeg that need to be fixed as Nicolas points out.
Michael's point applies only to users and not developers; developers
can easily change their shell configuration.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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] About FFmpeg-Library

[Lou Logan]

On Wed, 16 Sep 2015 19:00:25 +0530, Satinder Singh wrote:

> Hi ,
> 
> I have no idea how I can merge it in my c code. I follow a tutorial from
> dranger.com but when I doing as per as dranger.com , I got large no. of
> undefined function errors . So , I want your help , please help me how I
> can merge ffmpeg library in my c code , give any example or some thing like
> that which will helpful for me.
> 
> Thanks !!
> Satinder singh

Wrong mailing list: ffmpeg-devel is for patch submissions and
discussions involving the development of FFmpeg. You should be asking
for help at the libav-user mailing list. That is the FFmpeg mailing
list for library usage.

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: use frequency domain windowing

[Ganesh Ajjanagadde]

Have not checked what the filter is doing, but have a minor comment:
int sign computation - please use FFSIGN.

Regards,
Ganesh

On Wed, Sep 16, 2015 at 1:15 PM, Muhammad Faiz  wrote:
>
>
> ___
> 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 2/2] vp9: add fullpel (avg) MC SIMD for 10/12bpp.

[James Almer]

On 9/16/2015 10:12 AM, Ronald S. Bultje wrote:
> @@ -52,19 +60,37 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp, 
> int bpp)
>  cpu_flags = av_get_cpu_flags();
>  
>  if (EXTERNAL_MMX(cpu_flags)) {
> -init_fpel_func(4, 0,   8, put, mmx);
> +init_fpel_func(4, 0,   8, put, , mmx);
> +}
> +
> +if (EXTERNAL_MMX(cpu_flags)) {
> +init_fpel_func(4, 1,   8, avg, _16, mmxext);

EXTERNAL_MMXEXT(cpu_flags). We don't want those Pentium 2 and K6 crashing :P

[...]

> diff --git a/libavcodec/x86/vp9mc.asm b/libavcodec/x86/vp9mc.asm
> index fb5b1e9..bc61c12 100644
> --- a/libavcodec/x86/vp9mc.asm
> +++ b/libavcodec/x86/vp9mc.asm
> @@ -553,7 +553,7 @@ filter_vx2_fn avg
>  
>  %endif ; ARCH_X86_64
>  
> -%macro fpel_fn 6-7 4
> +%macro fpel_fn 6-8 0, 4
>  %if %2 == 4
>  %define %%srcfn movh
>  %define %%dstfn movh
> @@ -562,12 +562,22 @@ filter_vx2_fn avg
>  %define %%dstfn mova
>  %endif
>  
> +%if %7 == 8
> +%define %%pavg pavgb
> +%define %%szsuf _8
> +%elif %7 == 16
> +%define %%pavg pavgw
> +%define %%szsuf _16
> +%else
> +%define %%szsuf
> +%endif
> +
>  %if %2 <= mmsize
> -cglobal vp9_%1%2, 5, 7, 4, dst, dstride, src, sstride, h, dstride3, sstride3
> +cglobal vp9_%1%2%%szsuf, 5, 7, 4, dst, dstride, src, sstride, h, dstride3, 
> sstride3
>  lea  sstride3q, [sstrideq*3]
>  lea  dstride3q, [dstrideq*3]
>  %else
> -cglobal vp9_%1%2, 5, 5, %7, dst, dstride, src, sstride, h
> +cglobal vp9_%1%2%%szsuf, 5, 5, %8, dst, dstride, src, sstride, h
>  %endif
>  .loop:
>  %%srcfn m0, [srcq]
> @@ -582,10 +592,16 @@ cglobal vp9_%1%2, 5, 5, %7, dst, dstride, src, sstride, 
> h
>  %endif
>  lea   srcq, [srcq+sstrideq*%6]
>  %ifidn %1, avg
> -pavgb   m0, [dstq]
> -pavgb   m1, [dstq+d%3]
> -pavgb   m2, [dstq+d%4]
> -pavgb   m3, [dstq+d%5]
> +%%pavg  m0, [dstq]
> +%%pavg  m1, [dstq+d%3]
> +%%pavg  m2, [dstq+d%4]
> +%%pavg  m3, [dstq+d%5]
> +%if %2/mmsize == 8
> +%%pavg  m4, [dstq+mmsize*4]
> +%%pavg  m5, [dstq+mmsize*5]
> +%%pavg  m6, [dstq+mmsize*6]
> +%%pavg  m7, [dstq+mmsize*7]
> +%endif
>  %endif
>  %%dstfn [dstq], m0
>  %%dstfn [dstq+d%3], m1
> @@ -611,25 +627,38 @@ INIT_MMX mmx
>  fpel_fn put, 4,  strideq, strideq*2, stride3q, 4
>  fpel_fn put, 8,  strideq, strideq*2, stride3q, 4
>  INIT_MMX mmxext
> -fpel_fn avg, 4,  strideq, strideq*2, stride3q, 4
> -fpel_fn avg, 8,  strideq, strideq*2, stride3q, 4
> +fpel_fn avg, 4,  strideq, strideq*2, stride3q, 4, 8
> +fpel_fn avg, 8,  strideq, strideq*2, stride3q, 4, 8
>  INIT_XMM sse
>  fpel_fn put, 16, strideq, strideq*2, stride3q, 4
>  fpel_fn put, 32, mmsize,  strideq,   strideq+mmsize, 2
>  fpel_fn put, 64, mmsize,  mmsize*2,  mmsize*3, 1
> -fpel_fn put, 128, mmsize, mmsize*2,  mmsize*3, 1, 8
> +fpel_fn put, 128, mmsize, mmsize*2,  mmsize*3, 1, 0, 8
>  INIT_XMM sse2
> -fpel_fn avg, 16, strideq, strideq*2, stride3q, 4
> -fpel_fn avg, 32, mmsize,  strideq,   strideq+mmsize, 2
> -fpel_fn avg, 64, mmsize,  mmsize*2,  mmsize*3, 1
> +fpel_fn avg, 16, strideq, strideq*2, stride3q, 4, 8
> +fpel_fn avg, 32, mmsize,  strideq,   strideq+mmsize, 2, 8
> +fpel_fn avg, 64, mmsize,  mmsize*2,  mmsize*3, 1, 8
>  INIT_YMM avx
>  fpel_fn put, 32, strideq, strideq*2, stride3q, 4
>  fpel_fn put, 64, mmsize,  strideq,   strideq+mmsize, 2
>  fpel_fn put, 128, mmsize, mmsize*2, mmsize*3, 1
>  %if HAVE_AVX2_EXTERNAL
>  INIT_YMM avx2
> -fpel_fn avg, 32, strideq, strideq*2, stride3q, 4
> -fpel_fn avg, 64, mmsize,  strideq,   strideq+mmsize, 2
> +fpel_fn avg, 32, strideq, strideq*2, stride3q, 4, 8
> +fpel_fn avg, 64, mmsize,  strideq,   strideq+mmsize, 2, 8
> +%endif
> +INIT_MMX mmxext
> +fpel_fn avg,  8,  strideq, strideq*2, stride3q, 4, 16
> +INIT_XMM sse2
> +fpel_fn avg,  16, strideq, strideq*2, stride3q, 4, 16
> +fpel_fn avg,  32, mmsize,  strideq,   strideq+mmsize, 2, 16
> +fpel_fn avg,  64, mmsize,  mmsize*2,  mmsize*3, 1, 16
> +fpel_fn avg, 128, mmsize,  mmsize*2,  mmsize*3, 1, 16, 8
> +%if HAVE_AVX2_EXTERNAL
> +INIT_YMM avx2
> +fpel_fn avg,  32, strideq, strideq*2, stride3q, 4, 16
> +fpel_fn avg,  64, mmsize,  strideq,   strideq+mmsize, 2, 16
> +fpel_fn avg, 128, mmsize,  mmsize*2,  mmsize*3, 1, 16
>  %endif
>  %undef s16
>  %undef d16

Well, it doesn't exactly look cleaner than the previous version, but it's ok :P

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

Re: [FFmpeg-devel] Some questions about ffmpeg h264_qsv decoder

[Ivan Uskov]

Hello Ron,

Wednesday, September 16, 2015, 9:00:02 AM, you wrote:

R> a) qsv decode h264 file found many duplicated frames.
I  have  posted the patch "[PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong
ticks_per_frame."  to  this  list, please try to apply it the issue should be
solved.

R> b) A 1920x1080 video transcode to 1280x720, both CPU and GPU used more than 
1920x1080 to  1920x1080.
Unfortunately  the  current  implementation of qsv modules of ffmpeg does use
own  standalone  MXF  session. So there are copying from GPU memory to system
memory  and  back  are existing during transcoding. Also here software scaler
uses   when  you  transcode  1920x1080  ==>  1280x720.  We  a  working  under
possibility to create complete pipeline into GPU:  
[qsv_dec]==>[qsv_vpp(scaler)]==>[qsv_enc]
But I can not say currently when exactly it will available.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

Re: [FFmpeg-devel] Need guidance

[Kinnera Saranu]

Hey,

Yes I am interested in coding.In the first stage i would like to setup
the environment/code base of this organization and understand more about it.

Regards
Kinnera

On Thu, Sep 17, 2015 at 12:46 AM, Lou Logan  wrote:

> On Thu, 17 Sep 2015 00:24:38 +0530, Kinnera Saranu wrote:
>
> > Hey I'm new, but I'd like to contribute to your organisation, can someone
> > please guide me along?
>
> Hi,
>
> How would you like to contribute? What are you interested in doing?
> With more specifics we can point you in the right direction.
>
> Lou
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: add subpel MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/Makefile |   5 +-
 libavcodec/x86/vp9dsp_init.c| 197 +++--
 libavcodec/x86/vp9dsp_init.h| 110 +++-
 libavcodec/x86/vp9dsp_init_10bpp.c  |  25 ++
 libavcodec/x86/vp9dsp_init_12bpp.c  |  25 ++
 libavcodec/x86/vp9dsp_init_16bpp.c  |   2 +-
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  63 +
 libavcodec/x86/vp9mc.asm|  26 +-
 libavcodec/x86/vp9mc_16bpp.asm  | 413 
 9 files changed, 701 insertions(+), 165 deletions(-)
 create mode 100644 libavcodec/x86/vp9dsp_init_10bpp.c
 create mode 100644 libavcodec/x86/vp9dsp_init_12bpp.c
 create mode 100644 libavcodec/x86/vp9dsp_init_16bpp_template.c
 create mode 100644 libavcodec/x86/vp9mc_16bpp.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 616f830..b3cfb0b 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -63,6 +63,8 @@ OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_init.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += x86/vorbisdsp_init.o
 OBJS-$(CONFIG_VP6_DECODER) += x86/vp6dsp_init.o
 OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o\
+  x86/vp9dsp_init_10bpp.o  \
+  x86/vp9dsp_init_12bpp.o  \
   x86/vp9dsp_init_16bpp.o
 OBJS-$(CONFIG_WEBP_DECODER)+= x86/vp8dsp_init.o
 
@@ -157,5 +159,6 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
 YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
   x86/vp9itxfm.o\
   x86/vp9lpf.o  \
-  x86/vp9mc.o
+  x86/vp9mc.o   \
+  x86/vp9mc_16bpp.o
 YASM-OBJS-$(CONFIG_WEBP_DECODER)   += x86/vp8dsp.o
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index 7cdec4b..084dff6 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -45,144 +45,52 @@ decl_fpel_func(put, 64,   , avx);
 decl_fpel_func(avg, 32, _8, avx2);
 decl_fpel_func(avg, 64, _8, avx2);
 
-#define mc_func(avg, sz, dir, opt, type, f_sz) \
-void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
- const uint8_t *src, ptrdiff_t 
src_stride, \
- int h, const type 
(*filter)[f_sz])
-#define mc_funcs(sz, opt, type, fsz) \
-mc_func(put, sz, h, opt, type, fsz); \
-mc_func(avg, sz, h, opt, type, fsz); \
-mc_func(put, sz, v, opt, type, fsz); \
-mc_func(avg, sz, v, opt, type, fsz)
-
-mc_funcs(4, mmxext, int16_t, 8);
-mc_funcs(8, sse2, int16_t, 8);
-mc_funcs(4, ssse3, int8_t, 32);
-mc_funcs(8, ssse3, int8_t, 32);
+decl_mc_funcs(4, mmxext, int16_t, 8, 8);
+decl_mc_funcs(8, sse2, int16_t,  8, 8);
+decl_mc_funcs(4, ssse3, int8_t, 32, 8);
+decl_mc_funcs(8, ssse3, int8_t, 32, 8);
 #if ARCH_X86_64
-mc_funcs(16, ssse3, int8_t, 32);
-mc_funcs(32, avx2, int8_t, 32);
+decl_mc_funcs(16, ssse3, int8_t, 32, 8);
+decl_mc_funcs(32, avx2, int8_t, 32, 8);
 #endif
 
-#undef mc_funcs
-#undef mc_func
-
-#define mc_rep_func(avg, sz, hsz, dir, opt, type, f_sz) \
-static av_always_inline void \
-ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
-const uint8_t *src, ptrdiff_t 
src_stride, \
-int h, const type (*filter)[f_sz]) 
\
-{ \
-ff_vp9_##avg##_8tap_1d_##dir##_##hsz##_##opt(dst,   dst_stride, src, \
- src_stride, h, filter); \
-ff_vp9_##avg##_8tap_1d_##dir##_##hsz##_##opt(dst + hsz, dst_stride, src + 
hsz, \
- src_stride, h, filter); \
-}
-
-#define mc_rep_funcs(sz, hsz, opt, type, fsz) \
-mc_rep_func(put, sz, hsz, h, opt, type, fsz); \
-mc_rep_func(avg, sz, hsz, h, opt, type, fsz); \
-mc_rep_func(put, sz, hsz, v, opt, type, fsz); \
-mc_rep_func(avg, sz, hsz, v, opt, type, fsz)
-
-mc_rep_funcs(16, 8, sse2, int16_t, 8);
+mc_rep_funcs(16,  8,  8,  sse2, int16_t,  8, 8);
 #if ARCH_X86_32
-mc_rep_funcs(16, 8, ssse3, int8_t, 32);
+mc_rep_funcs(16,  8,  8, ssse3, int8_t,  32, 8);
 #endif
-mc_rep_funcs(32, 16, sse2, int16_t, 8);
-mc_rep_funcs(32, 16, ssse3, int8_t, 32);
-mc_rep_funcs(64, 32, sse2, int16_t, 8);
-mc_rep_funcs(64, 32, ssse3, int8_t, 32);
+mc_rep_funcs(32, 16, 16, sse2,  int16_t,  8, 8);
+mc_rep_funcs(32, 16, 16, ssse3, int8_t,  32, 8);
+mc_rep_funcs(64, 32, 32, sse2,  int16_t,  8, 8);
+mc_rep_funcs(64, 32, 32, ssse3, int8_t,  32, 8);
 #if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
-mc_rep_funcs(64, 32, avx2, int8_t, 32);
+mc_rep_funcs(64, 32, 

[FFmpeg-devel] [PATCH] vp9: add subpel MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/Makefile |   5 +-
 libavcodec/x86/vp9dsp_init.c| 197 +++--
 libavcodec/x86/vp9dsp_init.h| 110 +++-
 libavcodec/x86/vp9dsp_init_10bpp.c  |  25 ++
 libavcodec/x86/vp9dsp_init_12bpp.c  |  25 ++
 libavcodec/x86/vp9dsp_init_16bpp.c  |   2 +-
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  63 +
 libavcodec/x86/vp9mc.asm|  26 +-
 libavcodec/x86/vp9mc_16bpp.asm  | 420 
 9 files changed, 708 insertions(+), 165 deletions(-)
 create mode 100644 libavcodec/x86/vp9dsp_init_10bpp.c
 create mode 100644 libavcodec/x86/vp9dsp_init_12bpp.c
 create mode 100644 libavcodec/x86/vp9dsp_init_16bpp_template.c
 create mode 100644 libavcodec/x86/vp9mc_16bpp.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 616f830..b3cfb0b 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -63,6 +63,8 @@ OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_init.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += x86/vorbisdsp_init.o
 OBJS-$(CONFIG_VP6_DECODER) += x86/vp6dsp_init.o
 OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o\
+  x86/vp9dsp_init_10bpp.o  \
+  x86/vp9dsp_init_12bpp.o  \
   x86/vp9dsp_init_16bpp.o
 OBJS-$(CONFIG_WEBP_DECODER)+= x86/vp8dsp_init.o
 
@@ -157,5 +159,6 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
 YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
   x86/vp9itxfm.o\
   x86/vp9lpf.o  \
-  x86/vp9mc.o
+  x86/vp9mc.o   \
+  x86/vp9mc_16bpp.o
 YASM-OBJS-$(CONFIG_WEBP_DECODER)   += x86/vp8dsp.o
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index 7cdec4b..084dff6 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -45,144 +45,52 @@ decl_fpel_func(put, 64,   , avx);
 decl_fpel_func(avg, 32, _8, avx2);
 decl_fpel_func(avg, 64, _8, avx2);
 
-#define mc_func(avg, sz, dir, opt, type, f_sz) \
-void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
- const uint8_t *src, ptrdiff_t 
src_stride, \
- int h, const type 
(*filter)[f_sz])
-#define mc_funcs(sz, opt, type, fsz) \
-mc_func(put, sz, h, opt, type, fsz); \
-mc_func(avg, sz, h, opt, type, fsz); \
-mc_func(put, sz, v, opt, type, fsz); \
-mc_func(avg, sz, v, opt, type, fsz)
-
-mc_funcs(4, mmxext, int16_t, 8);
-mc_funcs(8, sse2, int16_t, 8);
-mc_funcs(4, ssse3, int8_t, 32);
-mc_funcs(8, ssse3, int8_t, 32);
+decl_mc_funcs(4, mmxext, int16_t, 8, 8);
+decl_mc_funcs(8, sse2, int16_t,  8, 8);
+decl_mc_funcs(4, ssse3, int8_t, 32, 8);
+decl_mc_funcs(8, ssse3, int8_t, 32, 8);
 #if ARCH_X86_64
-mc_funcs(16, ssse3, int8_t, 32);
-mc_funcs(32, avx2, int8_t, 32);
+decl_mc_funcs(16, ssse3, int8_t, 32, 8);
+decl_mc_funcs(32, avx2, int8_t, 32, 8);
 #endif
 
-#undef mc_funcs
-#undef mc_func
-
-#define mc_rep_func(avg, sz, hsz, dir, opt, type, f_sz) \
-static av_always_inline void \
-ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
-const uint8_t *src, ptrdiff_t 
src_stride, \
-int h, const type (*filter)[f_sz]) 
\
-{ \
-ff_vp9_##avg##_8tap_1d_##dir##_##hsz##_##opt(dst,   dst_stride, src, \
- src_stride, h, filter); \
-ff_vp9_##avg##_8tap_1d_##dir##_##hsz##_##opt(dst + hsz, dst_stride, src + 
hsz, \
- src_stride, h, filter); \
-}
-
-#define mc_rep_funcs(sz, hsz, opt, type, fsz) \
-mc_rep_func(put, sz, hsz, h, opt, type, fsz); \
-mc_rep_func(avg, sz, hsz, h, opt, type, fsz); \
-mc_rep_func(put, sz, hsz, v, opt, type, fsz); \
-mc_rep_func(avg, sz, hsz, v, opt, type, fsz)
-
-mc_rep_funcs(16, 8, sse2, int16_t, 8);
+mc_rep_funcs(16,  8,  8,  sse2, int16_t,  8, 8);
 #if ARCH_X86_32
-mc_rep_funcs(16, 8, ssse3, int8_t, 32);
+mc_rep_funcs(16,  8,  8, ssse3, int8_t,  32, 8);
 #endif
-mc_rep_funcs(32, 16, sse2, int16_t, 8);
-mc_rep_funcs(32, 16, ssse3, int8_t, 32);
-mc_rep_funcs(64, 32, sse2, int16_t, 8);
-mc_rep_funcs(64, 32, ssse3, int8_t, 32);
+mc_rep_funcs(32, 16, 16, sse2,  int16_t,  8, 8);
+mc_rep_funcs(32, 16, 16, ssse3, int8_t,  32, 8);
+mc_rep_funcs(64, 32, 32, sse2,  int16_t,  8, 8);
+mc_rep_funcs(64, 32, 32, ssse3, int8_t,  32, 8);
 #if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
-mc_rep_funcs(64, 32, avx2, int8_t, 32);
+mc_rep_funcs(64, 32, 

[FFmpeg-devel] [PATCHv2] all: do standards compliant absdiff computation

[Ganesh Ajjanagadde]

This resolves implementation defined behavior, and also silences 
-Wabsolute-value in clang 3.5+.
Moreover, the generated asm is identical to before modulo nop padding.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/flashsv2enc.c | 8 +---
 libavfilter/vf_hqx.c | 8 +---
 libavfilter/vf_xbr.c | 7 ---
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/libavcodec/flashsv2enc.c b/libavcodec/flashsv2enc.c
index c2c00f4..65db112 100644
--- a/libavcodec/flashsv2enc.c
+++ b/libavcodec/flashsv2enc.c
@@ -412,12 +412,14 @@ static inline unsigned pixel_color15(const uint8_t * src)
 
 static inline unsigned int chroma_diff(unsigned int c1, unsigned int c2)
 {
+#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
+
 unsigned int t1 = (c1 & 0x00ff) + ((c1 & 0xff00) >> 8) + ((c1 & 
0x00ff) >> 16);
 unsigned int t2 = (c2 & 0x00ff) + ((c2 & 0xff00) >> 8) + ((c2 & 
0x00ff) >> 16);
 
-return abs(t1 - t2) + abs((c1 & 0x00ff) - (c2 & 0x00ff)) +
-abs(((c1 & 0xff00) >> 8) - ((c2 & 0xff00) >> 8)) +
-abs(((c1 & 0x00ff) >> 16) - ((c2 & 0x00ff) >> 16));
+return ABSDIFF(t1, t2) + ABSDIFF(c1 & 0x00ff, c2 & 0x00ff) +
+ABSDIFF((c1 & 0xff00) >> 8 , (c2 & 0xff00) >> 8) +
+ABSDIFF((c1 & 0x00ff) >> 16, (c2 & 0x00ff) >> 16);
 }
 
 static inline int pixel_color7_fast(Palette * palette, unsigned c15)
diff --git a/libavfilter/vf_hqx.c b/libavfilter/vf_hqx.c
index fa15d9c..d1e360f 100644
--- a/libavfilter/vf_hqx.c
+++ b/libavfilter/vf_hqx.c
@@ -65,9 +65,11 @@ static av_always_inline int yuv_diff(uint32_t yuv1, uint32_t 
yuv2)
 #define YMASK 0xff
 #define UMASK 0x00ff00
 #define VMASK 0xff
-return abs((yuv1 & YMASK) - (yuv2 & YMASK)) > (48 << 16) ||
-   abs((yuv1 & UMASK) - (yuv2 & UMASK)) > ( 7 <<  8) ||
-   abs((yuv1 & VMASK) - (yuv2 & VMASK)) > ( 6 <<  0);
+#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
+
+return ABSDIFF(yuv1 & YMASK, yuv2 & YMASK) > (48 << 16) ||
+   ABSDIFF(yuv1 & UMASK, yuv2 & UMASK) > ( 7 <<  8) ||
+   ABSDIFF(yuv1 & VMASK, yuv2 & VMASK) > ( 6 <<  0);
 }
 
 /* (c1*w1 + c2*w2) >> s */
diff --git a/libavfilter/vf_xbr.c b/libavfilter/vf_xbr.c
index 8586608..c92e9a8 100644
--- a/libavfilter/vf_xbr.c
+++ b/libavfilter/vf_xbr.c
@@ -65,13 +65,14 @@ static uint32_t pixel_diff(uint32_t x, uint32_t y, const 
uint32_t *r2y)
 #define YMASK 0xff
 #define UMASK 0x00ff00
 #define VMASK 0xff
+#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
 
 uint32_t yuv1 = r2y[x & 0xff];
 uint32_t yuv2 = r2y[y & 0xff];
 
-return (abs((yuv1 & YMASK) - (yuv2 & YMASK)) >> 16) +
-   (abs((yuv1 & UMASK) - (yuv2 & UMASK)) >>  8) +
-   abs((yuv1 & VMASK) - (yuv2 & VMASK));
+return (ABSDIFF(yuv1 & YMASK, yuv2 & YMASK) >> 16) +
+   (ABSDIFF(yuv1 & UMASK, yuv2 & UMASK) >>  8) +
+ABSDIFF(yuv1 & VMASK, yuv2 & VMASK);
 }
 
 #define ALPHA_BLEND_128_W(a, b) a) & LB_MASK) >> 1) + (((b) & LB_MASK) >> 
1))
-- 
2.5.2

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

[FFmpeg-devel] Need guidance

[Kinnera Saranu]

Hey I'm new, but I'd like to contribute to your organisation, can someone
please guide me along?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Ivan Uskov]

Hello All,

The   attached  patch  does  fixes  the  issue  of  frames  duplication when
elementary h.264 stream decodes by qsvdec.
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h2645.c-Bug-fixed-wrong-ticks_per_.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Need guidance

[Lou Logan]

On Thu, 17 Sep 2015 00:24:38 +0530, Kinnera Saranu wrote:

> Hey I'm new, but I'd like to contribute to your organisation, can someone
> please guide me along?

Hi,

How would you like to contribute? What are you interested in doing?
With more specifics we can point you in the right direction.

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

Re: [FFmpeg-devel] [PATCH 1/2] vp9: add fullpel (put) MC SIMD for 10/12bpp.

[Ronald S. Bultje]

Hi,

On Wed, Sep 16, 2015 at 3:14 PM, James Almer  wrote:

> On 9/16/2015 10:12 AM, Ronald S. Bultje wrote:
> > ---
> >  libavcodec/x86/Makefile|  3 +-
> >  libavcodec/x86/vp9dsp_init.c   | 73
> +-
> >  libavcodec/x86/vp9dsp_init.h   | 39 
>
> vp9dsp.h would be more in line with other headers in the x86 folder.
>

I found that name a little weird because it would suggest the header is
related to actual dsp, whereas it really just covers init routines. If you
prefer I can still change it.

> diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
> b/libavcodec/x86/vp9dsp_init_16bpp.c
> > new file mode 100644
> > index 000..be70429
> > --- /dev/null
> > +++ b/libavcodec/x86/vp9dsp_init_16bpp.c
> > @@ -0,0 +1,71 @@
> > +/*
> > + * VP9 SIMD optimizations
> > + *
> > + * Copyright (c) 2013 Ronald S. Bultje 
> > + *
> > + * 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/attributes.h"
> > +#include "libavutil/avassert.h"
> > +#include "libavutil/cpu.h"
> > +#include "libavutil/mem.h"
> Why? You're not using alloc functions or anything similar.
>
> LOCAL_ALIGNED doesn't work w/o it.

> +#include "libavutil/x86/asm.h"
> Isn't this header meant for inline asm?


Yes, removed.

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

Re: [FFmpeg-devel] Need guidance

[anshul]

On Thursday 17 September 2015 12:52 AM, Kinnera Saranu wrote:

Hey,

 Yes I am interested in coding.In the first stage i would like to setup
the environment/code base of this organization and understand more about it.

Regards
Kinnera

On Thu, Sep 17, 2015 at 12:46 AM, Lou Logan  wrote:


On Thu, 17 Sep 2015 00:24:38 +0530, Kinnera Saranu wrote:


Hey I'm new, but I'd like to contribute to your organisation, can someone
please guide me along?

Hi,

How would you like to contribute? What are you interested in doing?
With more specifics we can point you in the right direction.

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


Rule 1) Don't Top Post on this Mailing List.

for setting up your environment look here.
https://trac.ffmpeg.org/wiki/CompilationGuide

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

Re: [FFmpeg-devel] [PATCH 1/2] vp9: add fullpel (put) MC SIMD for 10/12bpp.

[James Almer]

On 9/16/2015 10:12 AM, Ronald S. Bultje wrote:
> ---
>  libavcodec/x86/Makefile|  3 +-
>  libavcodec/x86/vp9dsp_init.c   | 73 
> +-
>  libavcodec/x86/vp9dsp_init.h   | 39 

vp9dsp.h would be more in line with other headers in the x86 folder.

[...]

> diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c 
> b/libavcodec/x86/vp9dsp_init_16bpp.c
> new file mode 100644
> index 000..be70429
> --- /dev/null
> +++ b/libavcodec/x86/vp9dsp_init_16bpp.c
> @@ -0,0 +1,71 @@
> +/*
> + * VP9 SIMD optimizations
> + *
> + * Copyright (c) 2013 Ronald S. Bultje 
> + *
> + * 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/attributes.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/cpu.h"
> +#include "libavutil/mem.h"
Why? You're not using alloc functions or anything similar.

> +#include "libavutil/x86/asm.h"
Isn't this header meant for inline asm?

Aside from that it should be ok.

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

[FFmpeg-devel] [PATCH 1/3] vp9: add fullpel (put) MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/Makefile|  3 +-
 libavcodec/x86/vp9dsp_init.c   | 74 +-
 libavcodec/x86/vp9dsp_init.h   | 39 
 libavcodec/x86/vp9dsp_init_16bpp.c | 65 +
 libavcodec/x86/vp9mc.asm   | 18 --
 5 files changed, 155 insertions(+), 44 deletions(-)
 create mode 100644 libavcodec/x86/vp9dsp_init.h
 create mode 100644 libavcodec/x86/vp9dsp_init_16bpp.c

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 3c3cc1c..616f830 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -62,7 +62,8 @@ OBJS-$(CONFIG_V210_ENCODER)+= x86/v210enc_init.o
 OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_init.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += x86/vorbisdsp_init.o
 OBJS-$(CONFIG_VP6_DECODER) += x86/vp6dsp_init.o
-OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o
+OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o\
+  x86/vp9dsp_init_16bpp.o
 OBJS-$(CONFIG_WEBP_DECODER)+= x86/vp8dsp_init.o
 
 
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index f24cb67..ebfd963 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -23,31 +23,26 @@
 #include "libavutil/attributes.h"
 #include "libavutil/cpu.h"
 #include "libavutil/mem.h"
-#include "libavutil/x86/asm.h"
 #include "libavutil/x86/cpu.h"
 #include "libavcodec/vp9dsp.h"
+#include "libavcodec/x86/vp9dsp_init.h"
 
 #if HAVE_YASM
 
-#define fpel_func(avg, sz, opt) \
-void ff_vp9_##avg##sz##_##opt(uint8_t *dst, ptrdiff_t dst_stride, \
-  const uint8_t *src, ptrdiff_t src_stride, \
-  int h, int mx, int my)
-fpel_func(put,  4, mmx);
-fpel_func(put,  8, mmx);
-fpel_func(put, 16, sse);
-fpel_func(put, 32, sse);
-fpel_func(put, 64, sse);
-fpel_func(avg,  4, mmxext);
-fpel_func(avg,  8, mmxext);
-fpel_func(avg, 16, sse2);
-fpel_func(avg, 32, sse2);
-fpel_func(avg, 64, sse2);
-fpel_func(put, 32, avx);
-fpel_func(put, 64, avx);
-fpel_func(avg, 32, avx2);
-fpel_func(avg, 64, avx2);
-#undef fpel_func
+decl_fpel_func(put,  4, mmx);
+decl_fpel_func(put,  8, mmx);
+decl_fpel_func(put, 16, sse);
+decl_fpel_func(put, 32, sse);
+decl_fpel_func(put, 64, sse);
+decl_fpel_func(avg,  4, mmxext);
+decl_fpel_func(avg,  8, mmxext);
+decl_fpel_func(avg, 16, sse2);
+decl_fpel_func(avg, 32, sse2);
+decl_fpel_func(avg, 64, sse2);
+decl_fpel_func(put, 32, avx);
+decl_fpel_func(put, 64, avx);
+decl_fpel_func(avg, 32, avx2);
+decl_fpel_func(avg, 64, avx2);
 
 #define mc_func(avg, sz, dir, opt, type, f_sz) \
 void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
@@ -311,16 +306,13 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 {
 #if HAVE_YASM
 int cpu_flags;
-if (bpp != 8) return;
+if (bpp != 8) {
+ff_vp9dsp_init_16bpp_x86(dsp, bpp);
+return;
+}
 
 cpu_flags = av_get_cpu_flags();
 
-#define init_fpel(idx1, idx2, sz, type, opt) \
-dsp->mc[idx1][FILTER_8TAP_SMOOTH ][idx2][0][0] = \
-dsp->mc[idx1][FILTER_8TAP_REGULAR][idx2][0][0] = \
-dsp->mc[idx1][FILTER_8TAP_SHARP  ][idx2][0][0] = \
-dsp->mc[idx1][FILTER_BILINEAR][idx2][0][0] = ff_vp9_##type##sz##_##opt
-
 #define init_subpel1(idx1, idx2, idxh, idxv, sz, dir, type, opt) \
 dsp->mc[idx1][FILTER_8TAP_SMOOTH ][idx2][idxh][idxv] = 
type##_8tap_smooth_##sz##dir##_##opt; \
 dsp->mc[idx1][FILTER_8TAP_REGULAR][idx2][idxh][idxv] = 
type##_8tap_regular_##sz##dir##_##opt; \
@@ -386,8 +378,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 } while (0)
 
 if (EXTERNAL_MMX(cpu_flags)) {
-init_fpel(4, 0,  4, put, mmx);
-init_fpel(3, 0,  8, put, mmx);
+init_fpel_func(4, 0,  4, put, mmx);
+init_fpel_func(3, 0,  8, put, mmx);
 if (!bitexact) {
 dsp->itxfm_add[4 /* lossless */][DCT_DCT] =
 dsp->itxfm_add[4 /* lossless */][ADST_DCT] =
@@ -400,8 +392,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 init_subpel2(4, 0, 4, put, mmxext);
 init_subpel2(4, 1, 4, avg, mmxext);
-init_fpel(4, 1,  4, avg, mmxext);
-init_fpel(3, 1,  8, avg, mmxext);
+init_fpel_func(4, 1,  4, avg, mmxext);
+init_fpel_func(3, 1,  8, avg, mmxext);
 dsp->itxfm_add[TX_4X4][DCT_DCT] = ff_vp9_idct_idct_4x4_add_mmxext;
 init_dc_ipred(4, mmxext);
 init_dc_ipred(8, mmxext);
@@ -409,9 +401,9 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 }
 
 if (EXTERNAL_SSE(cpu_flags)) {
-init_fpel(2, 0, 16, put, sse);
-init_fpel(1, 0, 32, put, sse);
-init_fpel(0, 0, 64, put, sse);
+init_fpel_func(2, 0, 16, put, sse);
+  

Re: [FFmpeg-devel] [PATCH] vp9: add subpel MC SIMD for 10/12bpp.

[Ronald S. Bultje]

Hi,

On Wed, Sep 16, 2015 at 4:31 PM, James Almer  wrote:

> On 9/16/2015 4:17 PM, Ronald S. Bultje wrote:
> > ---
> >  libavcodec/x86/Makefile |   5 +-
> >  libavcodec/x86/vp9dsp_init.c| 197 +++--
> >  libavcodec/x86/vp9dsp_init.h| 110 +++-
> >  libavcodec/x86/vp9dsp_init_10bpp.c  |  25 ++
> >  libavcodec/x86/vp9dsp_init_12bpp.c  |  25 ++
> >  libavcodec/x86/vp9dsp_init_16bpp.c  |   2 +-
> >  libavcodec/x86/vp9dsp_init_16bpp_template.c |  63 +
>
> Using a template file seems unnecessarily complex. Why not just call the
> macros
> to declare both 10 and 12 bits prototypes inside vp9dsp_init_16bpp.c, then
> in
> ff_vp9dsp_init_16bpp_x86() do
>
> if (bpp == 10) { init stuff }
> else if (bpp == 12) { init stuff }
>
> Sort of like how h264 and hevc currently do.
> Afaics all 10/12bit function prototypes are going to be the same so the
> above
> approach is probably cleaner (One file instead of four).


Well, two of these files are only 2 lines, so it's really just 2 files. The
nice thing is that it's half the code for the bpp-specific stuff.

If you don't like it I'll remove it, but I personally liked the fact that
it prevents duplicate source code between the 10/12bpp setup.

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

Re: [FFmpeg-devel] [PATCH] vp9: add subpel MC SIMD for 10/12bpp.

[James Almer]

On 9/16/2015 5:48 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Sep 16, 2015 at 4:31 PM, James Almer  wrote:
> 
>> On 9/16/2015 4:17 PM, Ronald S. Bultje wrote:
>>> ---
>>>  libavcodec/x86/Makefile |   5 +-
>>>  libavcodec/x86/vp9dsp_init.c| 197 +++--
>>>  libavcodec/x86/vp9dsp_init.h| 110 +++-
>>>  libavcodec/x86/vp9dsp_init_10bpp.c  |  25 ++
>>>  libavcodec/x86/vp9dsp_init_12bpp.c  |  25 ++
>>>  libavcodec/x86/vp9dsp_init_16bpp.c  |   2 +-
>>>  libavcodec/x86/vp9dsp_init_16bpp_template.c |  63 +
>>
>> Using a template file seems unnecessarily complex. Why not just call the
>> macros
>> to declare both 10 and 12 bits prototypes inside vp9dsp_init_16bpp.c, then
>> in
>> ff_vp9dsp_init_16bpp_x86() do
>>
>> if (bpp == 10) { init stuff }
>> else if (bpp == 12) { init stuff }
>>
>> Sort of like how h264 and hevc currently do.
>> Afaics all 10/12bit function prototypes are going to be the same so the
>> above
>> approach is probably cleaner (One file instead of four).
> 
> 
> Well, two of these files are only 2 lines, so it's really just 2 files. The
> nice thing is that it's half the code for the bpp-specific stuff.
> 
> If you don't like it I'll remove it, but I personally liked the fact that
> it prevents duplicate source code between the 10/12bpp setup.

Keep it like this, then. Since you're the one writing the stuff of course use
whatever you like the most. It's just cosmetics and I'm fine either way.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] OpenHEVC CU-level decoding profiling

[Roshantha Mendis]

Hi,

I'm very sorry if this is the wrong place to ask these questions, I could
not find a mailing list or forum targeted towards OpenHEVC. It seems to me
that the OpenHEVC decoder has been integrated with ffmpeg - but if this is
not the right place to ask questions regarding the OpenHEVC decoder, then
please let me know where else to try.

I hope to use these information for research purposes to build an abstract,
statistical, application model of HEVC decoding tasks, so we can
incorporate it into simulations.

I would very much appreciate if someone could please point me out, on how
to obtain the following information :

- Get the decoding time for each CU in a bitstream. I want to see the
timing for each CU/PU, their type (intra/inter/skip)
- Get the total decoding time for each I/P/B-slice. (this should
essentially tally to the child CUs)
- each inter-CUs dependency information related to motion estimation (I
want to know how much data from other frames has a particular frame
referenced)
- Dependency frame relationship : what are the other frames in the GoP this
frame is dependent on.

I was able to obtain some of these in the HM decoder, but the structure of
the code in OpenHEVC seems a bit different to HM, hence it's a bit
difficult.



Many thanks for your help,


-- 
Rosh Mendis
Research Student - EngD in LSCITS
Dept. of Computer Science
University of York

Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: add -D_DEFAULT_SOURCE to silence -Wcpp

[Ganesh Ajjanagadde]

Glibc 2.20 onwards generates a deprecation warning for usage of _BSD_SOURCE and 
_SVID_SOURCE.
The solution from man feature_test_macros is to define both _DEFAULT_SOURCE and 
the old macros.
This change is done in configure while testing for Glibc. Doing it in source 
code
would require __UCLIBC__ checks, etc since uclibc also defines __GLIBC__ and 
__GLIBC_MINOR__,
so placing it in configure avoids the repeated checks.

Signed-off-by: Ganesh Ajjanagadde 
---
 configure | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configure b/configure
index cd6f629..0cd0a6c 100755
--- a/configure
+++ b/configure
@@ -4520,6 +4520,12 @@ probe_libc(){
 elif check_${pfx}cpp_condition features.h "defined __GLIBC__"; then
 eval ${pfx}libc_type=glibc
 add_${pfx}cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600
+# define _DEFAULT_SOURCE for glibc 2.20 onwards to silence deprecation
+# warnings for _BSD_SOURCE and _SVID_SOURCE.
+if check_${pfx}cpp_condition features.h "(__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 20) \
+|| (__GLIBC__ > 2)"; then
+add_${pfx}cppflags -D_DEFAULT_SOURCE
+fi
 # MinGW headers can be installed on Cygwin, so check for newlib first.
 elif check_${pfx}cpp_condition newlib.h "defined _NEWLIB_VERSION"; then
 eval ${pfx}libc_type=newlib
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] avformat/mpjpegdec: silence unused variable/function warnings

[Ganesh Ajjanagadde]

Silences a -Wunused-variable and -Wunused-function observed under GCC 5.2.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/mpjpegdec.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index d955304..4b57fad 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -77,27 +77,11 @@ static int split_tag_value(char **tag, char **value, char 
*line)
 return 0;
 }
 
-static int check_content_type(char *line)
-{
-char *tag, *value;
-int ret = split_tag_value(, , line);
-
-if (ret < 0)
-return ret;
-
-if (av_strcasecmp(tag, "Content-type") ||
-av_strcasecmp(value, "image/jpeg"))
-return AVERROR_INVALIDDATA;
-
-return 0;
-}
-
 static int parse_multipart_header(AVIOContext *pb, void *log_ctx);
 
 static int mpjpeg_read_probe(AVProbeData *p)
 {
 AVIOContext *pb;
-char line[128] = { 0 };
 int ret = 0;
 
 if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-')
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] WAV demuxer: Document the ignore_length option.

[Calvin Walton]

---
 doc/demuxers.texi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 34bfc9b..fe9b7b1 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -522,4 +522,27 @@ Example: convert the captions to a format most players 
understand:
 ffmpeg -i http://www.ted.com/talks/subtitles/id/1/lang/en talk1-en.srt
 @end example
 
+@section wav
+
+WAV demuxer.
+
+This demuxer accepts the following option:
+@table @option
+
+@item ignore_length
+Ignore the length field in the WAV file header.
+
+Some tools, when generating extremely long or streaming WAV files, may set the
+length field to an incorrect or invalid value.
+
+If you set the @option{ignore_length} option to 1, FFmpeg will ignore the
+length field in the WAV header, and treat all of the data in the file after
+the header as a continuous stream of audio data. If the file contains non-audio
+data after the audio (e.g. ID3 tags), it will be treated as audio data and
+cause audible artifacts or decoding errors.
+
+The default, 0, respects the length field.
+
+@end table
+
 @c man end DEMUXERS
-- 
2.5.1

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

[FFmpeg-devel] [PATCH] swscale/swscale: silence unused function warning

[Ganesh Ajjanagadde]

gamma_convert is only used with the old code. Thus, it is
placed under a header guard. This patch silences a -Wunused-function
observed on GCC 5.2.

Signed-off-by: Ganesh Ajjanagadde 
---
 libswscale/swscale.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 9558048..120bba1 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -52,6 +52,7 @@ DECLARE_ALIGNED(8, static const uint8_t, sws_pb_64)[8] = {
 64, 64, 64, 64, 64, 64, 64, 64
 };
 
+#ifndef NEW_FILTER
 static void gamma_convert(uint8_t * src[], int width, uint16_t *gamma)
 {
 int i;
@@ -67,6 +68,7 @@ static void gamma_convert(uint8_t * src[], int width, 
uint16_t *gamma)
 AV_WL16(src1 + i*4 + 2, gamma[b]);
 }
 }
+#endif
 
 static av_always_inline void fillPlane(uint8_t *plane, int stride, int width,
int height, int y, uint8_t val)
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] checkasm: add flacdsp decorrelate tests

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/Makefile   |  1 +
 tests/checkasm/checkasm.c |  3 ++
 tests/checkasm/checkasm.h |  1 +
 tests/checkasm/flacdsp.c  | 91 +++
 4 files changed, 96 insertions(+)
 create mode 100644 tests/checkasm/flacdsp.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 359ec69..ae85321 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,5 +1,6 @@
 # libavcodec tests
 AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
+AVCODECOBJS-$(CONFIG_FLACDSP)  += flacdsp.o
 AVCODECOBJS-$(CONFIG_H264PRED) += h264pred.o
 AVCODECOBJS-$(CONFIG_H264QPEL) += h264qpel.o
 AVCODECOBJS-$(CONFIG_V210_ENCODER) += v210enc.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 8d648be..00a7c18 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -60,6 +60,9 @@ static const struct {
 #if CONFIG_BSWAPDSP
 { "bswapdsp", checkasm_check_bswapdsp },
 #endif
+#if CONFIG_FLACDSP
+{ "flacdsp", checkasm_check_flacdsp },
+#endif
 #if CONFIG_H264PRED
 { "h264pred", checkasm_check_h264pred },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index fdc6fe0..6014f5a 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -30,6 +30,7 @@
 #include "libavutil/timer.h"
 
 void checkasm_check_bswapdsp(void);
+void checkasm_check_flacdsp(void);
 void checkasm_check_h264pred(void);
 void checkasm_check_h264qpel(void);
 void checkasm_check_v210enc(void);
diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
new file mode 100644
index 000..1c33ea4
--- /dev/null
+++ b/tests/checkasm/flacdsp.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2015 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 
+#include "checkasm.h"
+#include "libavcodec/flacdsp.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define BUF_SIZE 256
+#define MAX_CHANNELS 8
+
+#define randomize_buffers()\
+do {   \
+uint32_t r;\
+int i, j;  \
+for (i = 0; i < BUF_SIZE; i += 4) {\
+for (j = 0; j < channels; j++) {   \
+r = rnd() & (1 << (bits - 2)) - 1; \
+AV_WN32A(ref_src[j] + i, r);   \
+AV_WN32A(new_src[j] + i, r);   \
+}  \
+}  \
+} while (0)
+
+static void check_decorrelate(uint8_t **ref_dst, uint8_t **ref_src, uint8_t 
**new_dst, uint8_t **new_src,
+  int channels, int bits) {
+declare_func(void, uint8_t **out, int32_t **in, int channels, int len, int 
shift);
+
+randomize_buffers();
+call_ref(ref_dst, (int32_t **)ref_src, channels, BUF_SIZE / 
sizeof(int32_t), 8);
+call_new(new_dst, (int32_t **)new_src, channels, BUF_SIZE / 
sizeof(int32_t), 8);
+if (memcmp(*ref_dst, *new_dst, bits == 16 ? BUF_SIZE * (channels/2) : 
BUF_SIZE * channels) ||
+memcmp(*ref_src, *new_src, BUF_SIZE * channels))
+fail();
+bench_new(new_dst, (int32_t **)new_src, channels, BUF_SIZE / 
sizeof(int32_t), 8);
+}
+
+void checkasm_check_flacdsp(void)
+{
+LOCAL_ALIGNED_16(uint8_t, ref_dst, [BUF_SIZE*MAX_CHANNELS]);
+LOCAL_ALIGNED_16(uint8_t, ref_buf, [BUF_SIZE*MAX_CHANNELS]);
+LOCAL_ALIGNED_16(uint8_t, new_dst, [BUF_SIZE*MAX_CHANNELS]);
+LOCAL_ALIGNED_16(uint8_t, new_buf, [BUF_SIZE*MAX_CHANNELS]);
+uint8_t *ref_src[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1], 
_buf[BUF_SIZE*2], _buf[BUF_SIZE*3],
+   _buf[BUF_SIZE*4], _buf[BUF_SIZE*5], 
_buf[BUF_SIZE*6], _buf[BUF_SIZE*7] };
+uint8_t *new_src[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1], 
_buf[BUF_SIZE*2], _buf[BUF_SIZE*3],
+   _buf[BUF_SIZE*4], _buf[BUF_SIZE*5], 
_buf[BUF_SIZE*6], _buf[BUF_SIZE*7] };
+static const char * const names[3] = { "ls", "rs", "ms" };
+static const struct {
+enum AVSampleFormat fmt;
+int bits;
+} fmts[] = {
+

[FFmpeg-devel] [PATCH] avcodec/libx264: silence -Waddress

[Ganesh Ajjanagadde]

This patch moves the pointer validity check outside the macro,
and silences the -Waddress observed with GCC 5.2.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/libx264.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..c7c772e 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -346,7 +346,7 @@ static av_cold int X264_close(AVCodecContext *avctx)
 #define OPT_STR(opt, param)   \
 do {  \
 int ret;  \
-if (param && (ret = x264_param_parse(>params, opt, param)) < 0) { \
+if ((ret = x264_param_parse(>params, opt, param)) < 0) { \
 if(ret == X264_PARAM_BAD_NAME)\
 av_log(avctx, AV_LOG_ERROR,   \
 "bad option '%s': '%s'\n", opt, param);   \
@@ -437,7 +437,8 @@ static av_cold int X264_init(AVCodecContext *avctx)
 x4->params.i_log_level  = X264_LOG_DEBUG;
 x4->params.i_csp= convert_pix_fmt(avctx->pix_fmt);
 
-OPT_STR("weightp", x4->wpredp);
+if (x4->wpredp)
+OPT_STR("weightp", x4->wpredp);
 
 if (avctx->bit_rate) {
 x4->params.rc.i_bitrate   = avctx->bit_rate / 1000;
@@ -467,7 +468,8 @@ static av_cold int X264_init(AVCodecContext *avctx)
 (float)avctx->rc_initial_buffer_occupancy / avctx->rc_buffer_size;
 }
 
-OPT_STR("level", x4->level);
+if (x4->level)
+OPT_STR("level", x4->level);
 
 if (avctx->i_quant_factor > 0)
 x4->params.rc.f_ip_factor = 1 / fabs(avctx->i_quant_factor);
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] vp9: add subpel MC SIMD for 10/12bpp.

[James Almer]

On 9/16/2015 4:17 PM, Ronald S. Bultje wrote:
> ---
>  libavcodec/x86/Makefile |   5 +-
>  libavcodec/x86/vp9dsp_init.c| 197 +++--
>  libavcodec/x86/vp9dsp_init.h| 110 +++-
>  libavcodec/x86/vp9dsp_init_10bpp.c  |  25 ++
>  libavcodec/x86/vp9dsp_init_12bpp.c  |  25 ++
>  libavcodec/x86/vp9dsp_init_16bpp.c  |   2 +-
>  libavcodec/x86/vp9dsp_init_16bpp_template.c |  63 +

Using a template file seems unnecessarily complex. Why not just call the macros
to declare both 10 and 12 bits prototypes inside vp9dsp_init_16bpp.c, then in
ff_vp9dsp_init_16bpp_x86() do

if (bpp == 10) { init stuff }
else if (bpp == 12) { init stuff }

Sort of like how h264 and hevc currently do.
Afaics all 10/12bit function prototypes are going to be the same so the above
approach is probably cleaner (One file instead of four).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] vp9: add subpel MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/Makefile |   5 +-
 libavcodec/x86/vp9dsp_init.c| 197 +++--
 libavcodec/x86/vp9dsp_init.h| 110 +++-
 libavcodec/x86/vp9dsp_init_10bpp.c  |  25 ++
 libavcodec/x86/vp9dsp_init_12bpp.c  |  25 ++
 libavcodec/x86/vp9dsp_init_16bpp.c  |   2 +-
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  62 
 libavcodec/x86/vp9mc.asm|  26 +-
 libavcodec/x86/vp9mc_16bpp.asm  | 421 
 9 files changed, 708 insertions(+), 165 deletions(-)
 create mode 100644 libavcodec/x86/vp9dsp_init_10bpp.c
 create mode 100644 libavcodec/x86/vp9dsp_init_12bpp.c
 create mode 100644 libavcodec/x86/vp9dsp_init_16bpp_template.c
 create mode 100644 libavcodec/x86/vp9mc_16bpp.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 616f830..b3cfb0b 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -63,6 +63,8 @@ OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_init.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += x86/vorbisdsp_init.o
 OBJS-$(CONFIG_VP6_DECODER) += x86/vp6dsp_init.o
 OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o\
+  x86/vp9dsp_init_10bpp.o  \
+  x86/vp9dsp_init_12bpp.o  \
   x86/vp9dsp_init_16bpp.o
 OBJS-$(CONFIG_WEBP_DECODER)+= x86/vp8dsp_init.o
 
@@ -157,5 +159,6 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
 YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
   x86/vp9itxfm.o\
   x86/vp9lpf.o  \
-  x86/vp9mc.o
+  x86/vp9mc.o   \
+  x86/vp9mc_16bpp.o
 YASM-OBJS-$(CONFIG_WEBP_DECODER)   += x86/vp8dsp.o
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index 244f5f0..cd4af99 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -44,144 +44,52 @@ decl_fpel_func(put, 64,   , avx);
 decl_fpel_func(avg, 32, _8, avx2);
 decl_fpel_func(avg, 64, _8, avx2);
 
-#define mc_func(avg, sz, dir, opt, type, f_sz) \
-void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
- const uint8_t *src, ptrdiff_t 
src_stride, \
- int h, const type 
(*filter)[f_sz])
-#define mc_funcs(sz, opt, type, fsz) \
-mc_func(put, sz, h, opt, type, fsz); \
-mc_func(avg, sz, h, opt, type, fsz); \
-mc_func(put, sz, v, opt, type, fsz); \
-mc_func(avg, sz, v, opt, type, fsz)
-
-mc_funcs(4, mmxext, int16_t, 8);
-mc_funcs(8, sse2, int16_t, 8);
-mc_funcs(4, ssse3, int8_t, 32);
-mc_funcs(8, ssse3, int8_t, 32);
+decl_mc_funcs(4, mmxext, int16_t, 8, 8);
+decl_mc_funcs(8, sse2, int16_t,  8, 8);
+decl_mc_funcs(4, ssse3, int8_t, 32, 8);
+decl_mc_funcs(8, ssse3, int8_t, 32, 8);
 #if ARCH_X86_64
-mc_funcs(16, ssse3, int8_t, 32);
-mc_funcs(32, avx2, int8_t, 32);
+decl_mc_funcs(16, ssse3, int8_t, 32, 8);
+decl_mc_funcs(32, avx2, int8_t, 32, 8);
 #endif
 
-#undef mc_funcs
-#undef mc_func
-
-#define mc_rep_func(avg, sz, hsz, dir, opt, type, f_sz) \
-static av_always_inline void \
-ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
-const uint8_t *src, ptrdiff_t 
src_stride, \
-int h, const type (*filter)[f_sz]) 
\
-{ \
-ff_vp9_##avg##_8tap_1d_##dir##_##hsz##_##opt(dst,   dst_stride, src, \
- src_stride, h, filter); \
-ff_vp9_##avg##_8tap_1d_##dir##_##hsz##_##opt(dst + hsz, dst_stride, src + 
hsz, \
- src_stride, h, filter); \
-}
-
-#define mc_rep_funcs(sz, hsz, opt, type, fsz) \
-mc_rep_func(put, sz, hsz, h, opt, type, fsz); \
-mc_rep_func(avg, sz, hsz, h, opt, type, fsz); \
-mc_rep_func(put, sz, hsz, v, opt, type, fsz); \
-mc_rep_func(avg, sz, hsz, v, opt, type, fsz)
-
-mc_rep_funcs(16, 8, sse2, int16_t, 8);
+mc_rep_funcs(16,  8,  8,  sse2, int16_t,  8, 8);
 #if ARCH_X86_32
-mc_rep_funcs(16, 8, ssse3, int8_t, 32);
+mc_rep_funcs(16,  8,  8, ssse3, int8_t,  32, 8);
 #endif
-mc_rep_funcs(32, 16, sse2, int16_t, 8);
-mc_rep_funcs(32, 16, ssse3, int8_t, 32);
-mc_rep_funcs(64, 32, sse2, int16_t, 8);
-mc_rep_funcs(64, 32, ssse3, int8_t, 32);
+mc_rep_funcs(32, 16, 16, sse2,  int16_t,  8, 8);
+mc_rep_funcs(32, 16, 16, ssse3, int8_t,  32, 8);
+mc_rep_funcs(64, 32, 32, sse2,  int16_t,  8, 8);
+mc_rep_funcs(64, 32, 32, ssse3, int8_t,  32, 8);
 #if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
-mc_rep_funcs(64, 32, avx2, int8_t, 32);
+mc_rep_funcs(64, 32, 32, 

[FFmpeg-devel] [PATCH 2/3] vp9: add fullpel (avg) MC SIMD for 10/12bpp.

[Ronald S. Bultje]

---
 libavcodec/x86/vp9dsp_init.c   | 56 ++--
 libavcodec/x86/vp9dsp_init.h   | 12 
 libavcodec/x86/vp9dsp_init_16bpp.c | 58 ++---
 libavcodec/x86/vp9mc.asm   | 59 --
 4 files changed, 120 insertions(+), 65 deletions(-)

diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index ebfd963..244f5f0 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -29,20 +29,20 @@
 
 #if HAVE_YASM
 
-decl_fpel_func(put,  4, mmx);
-decl_fpel_func(put,  8, mmx);
-decl_fpel_func(put, 16, sse);
-decl_fpel_func(put, 32, sse);
-decl_fpel_func(put, 64, sse);
-decl_fpel_func(avg,  4, mmxext);
-decl_fpel_func(avg,  8, mmxext);
-decl_fpel_func(avg, 16, sse2);
-decl_fpel_func(avg, 32, sse2);
-decl_fpel_func(avg, 64, sse2);
-decl_fpel_func(put, 32, avx);
-decl_fpel_func(put, 64, avx);
-decl_fpel_func(avg, 32, avx2);
-decl_fpel_func(avg, 64, avx2);
+decl_fpel_func(put,  4,   , mmx);
+decl_fpel_func(put,  8,   , mmx);
+decl_fpel_func(put, 16,   , sse);
+decl_fpel_func(put, 32,   , sse);
+decl_fpel_func(put, 64,   , sse);
+decl_fpel_func(avg,  4, _8, mmxext);
+decl_fpel_func(avg,  8, _8, mmxext);
+decl_fpel_func(avg, 16, _8, sse2);
+decl_fpel_func(avg, 32, _8, sse2);
+decl_fpel_func(avg, 64, _8, sse2);
+decl_fpel_func(put, 32,   , avx);
+decl_fpel_func(put, 64,   , avx);
+decl_fpel_func(avg, 32, _8, avx2);
+decl_fpel_func(avg, 64, _8, avx2);
 
 #define mc_func(avg, sz, dir, opt, type, f_sz) \
 void ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
@@ -378,8 +378,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 } while (0)
 
 if (EXTERNAL_MMX(cpu_flags)) {
-init_fpel_func(4, 0,  4, put, mmx);
-init_fpel_func(3, 0,  8, put, mmx);
+init_fpel_func(4, 0,  4, put, , mmx);
+init_fpel_func(3, 0,  8, put, , mmx);
 if (!bitexact) {
 dsp->itxfm_add[4 /* lossless */][DCT_DCT] =
 dsp->itxfm_add[4 /* lossless */][ADST_DCT] =
@@ -392,8 +392,8 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 init_subpel2(4, 0, 4, put, mmxext);
 init_subpel2(4, 1, 4, avg, mmxext);
-init_fpel_func(4, 1,  4, avg, mmxext);
-init_fpel_func(3, 1,  8, avg, mmxext);
+init_fpel_func(4, 1,  4, avg, _8, mmxext);
+init_fpel_func(3, 1,  8, avg, _8, mmxext);
 dsp->itxfm_add[TX_4X4][DCT_DCT] = ff_vp9_idct_idct_4x4_add_mmxext;
 init_dc_ipred(4, mmxext);
 init_dc_ipred(8, mmxext);
@@ -401,9 +401,9 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 }
 
 if (EXTERNAL_SSE(cpu_flags)) {
-init_fpel_func(2, 0, 16, put, sse);
-init_fpel_func(1, 0, 32, put, sse);
-init_fpel_func(0, 0, 64, put, sse);
+init_fpel_func(2, 0, 16, put, , sse);
+init_fpel_func(1, 0, 32, put, , sse);
+init_fpel_func(0, 0, 64, put, , sse);
 init_ipred(16, sse, v, VERT);
 init_ipred(32, sse, v, VERT);
 }
@@ -411,9 +411,9 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 if (EXTERNAL_SSE2(cpu_flags)) {
 init_subpel3_8to64(0, put, sse2);
 init_subpel3_8to64(1, avg, sse2);
-init_fpel_func(2, 1, 16, avg, sse2);
-init_fpel_func(1, 1, 32, avg, sse2);
-init_fpel_func(0, 1, 64, avg, sse2);
+init_fpel_func(2, 1, 16, avg,  _8, sse2);
+init_fpel_func(1, 1, 32, avg,  _8, sse2);
+init_fpel_func(0, 1, 64, avg,  _8, sse2);
 init_lpf(sse2);
 dsp->itxfm_add[TX_4X4][ADST_DCT]  = ff_vp9_idct_iadst_4x4_add_sse2;
 dsp->itxfm_add[TX_4X4][DCT_ADST]  = ff_vp9_iadst_idct_4x4_add_sse2;
@@ -483,14 +483,14 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 init_dir_tm_h_ipred(32, avx);
 }
 if (EXTERNAL_AVX_FAST(cpu_flags)) {
-init_fpel_func(1, 0, 32, put, avx);
-init_fpel_func(0, 0, 64, put, avx);
+init_fpel_func(1, 0, 32, put, , avx);
+init_fpel_func(0, 0, 64, put, , avx);
 init_ipred(32, avx, v, VERT);
 }
 
 if (EXTERNAL_AVX2(cpu_flags)) {
-init_fpel_func(1, 1, 32, avg, avx2);
-init_fpel_func(0, 1, 64, avg, avx2);
+init_fpel_func(1, 1, 32, avg, _8, avx2);
+init_fpel_func(0, 1, 64, avg, _8, avx2);
 if (ARCH_X86_64) {
 #if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
 init_subpel3_32_64(0, put, avx2);
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 8c99c0d..792405e 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -23,16 +23,16 @@
 #ifndef AVCODEC_X86_VP9DSP_INIT_H
 #define AVCODEC_X86_VP9DSP_INIT_H
 
-#define decl_fpel_func(avg, sz, opt) \
-void ff_vp9_##avg##sz##_##opt(uint8_t *dst, ptrdiff_t 

[FFmpeg-devel] [PATCHv2] configure: add -D_DEFAULT_SOURCE to silence -Wcpp

[Ganesh Ajjanagadde]

Glibc 2.20 onwards generates a deprecation warning for usage of _BSD_SOURCE and 
_SVID_SOURCE.
The solution from man feature_test_macros is to define both _DEFAULT_SOURCE and 
the old macros.
This change is done in configure while testing for Glibc. Doing it in source 
code
would require __UCLIBC__ checks, etc since uclibc also defines __GLIBC__ and 
__GLIBC_MINOR__,
so placing it in configure avoids the repeated checks.

Signed-off-by: Ganesh Ajjanagadde 
---
 configure| 6 ++
 libavformat/os_support.c | 1 -
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index cd6f629..0cd0a6c 100755
--- a/configure
+++ b/configure
@@ -4520,6 +4520,12 @@ probe_libc(){
 elif check_${pfx}cpp_condition features.h "defined __GLIBC__"; then
 eval ${pfx}libc_type=glibc
 add_${pfx}cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600
+# define _DEFAULT_SOURCE for glibc 2.20 onwards to silence deprecation
+# warnings for _BSD_SOURCE and _SVID_SOURCE.
+if check_${pfx}cpp_condition features.h "(__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 20) \
+|| (__GLIBC__ > 2)"; then
+add_${pfx}cppflags -D_DEFAULT_SOURCE
+fi
 # MinGW headers can be installed on Cygwin, so check for newlib first.
 elif check_${pfx}cpp_condition newlib.h "defined _NEWLIB_VERSION"; then
 eval ${pfx}libc_type=newlib
diff --git a/libavformat/os_support.c b/libavformat/os_support.c
index 7950e44..3c22631 100644
--- a/libavformat/os_support.c
+++ b/libavformat/os_support.c
@@ -21,7 +21,6 @@
  */
 
 /* needed by inet_aton() */
-#define _DEFAULT_SOURCE
 #define _SVID_SOURCE
 
 #include "config.h"
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avformat/mpjpegdec: silence unused variable/function warnings

[Timothy Gu]

On Wed, Sep 16, 2015 at 2:25 PM, Ganesh Ajjanagadde
 wrote:
> Silences a -Wunused-variable and -Wunused-function observed under GCC 5.2.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/mpjpegdec.c | 16 
>  1 file changed, 16 deletions(-)

Applied, thanks.

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

[FFmpeg-devel] [PATCH] avformat/format: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

lpd.buf is non-const and discards the const qualifier of zerobuffer.
This fixes -Wdiscarded-qualifiers observed with GCC 5.2.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/format.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/format.c b/libavformat/format.c
index fd81d7a..9c40512 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -172,7 +172,7 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int 
is_opened,
 AVProbeData lpd = *pd;
 AVInputFormat *fmt1 = NULL, *fmt;
 int score, nodat = 0, score_max = 0;
-const static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];
+static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];
 
 if (!lpd.buf)
 lpd.buf = zerobuffer;
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] swscale/swscale: silence unused function warning

[Timothy Gu]

On Wed, Sep 16, 2015 at 2:20 PM, Ganesh Ajjanagadde
 wrote:
> gamma_convert is only used with the old code. Thus, it is
> placed under a header guard. This patch silences a -Wunused-function
> observed on GCC 5.2.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libswscale/swscale.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

[...]

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

Re: [FFmpeg-devel] [PATCH] avformat/format: silence -Wdiscarded-qualifiers

[Timothy Gu]

On Wed, Sep 16, 2015 at 3:50 PM, Ganesh Ajjanagadde
 wrote:
> lpd.buf is non-const and discards the const qualifier of zerobuffer.
> This fixes -Wdiscarded-qualifiers observed with GCC 5.2.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/format.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Michael Niedermayer]

On Tue, Sep 15, 2015 at 04:54:19PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 15, 2015 at 08:48:33AM -0400, Ganesh Ajjanagadde wrote:
> > On Tue, Sep 15, 2015 at 6:54 AM, Ronald S. Bultje  
> > wrote:
> > > Hi Ganesh,
> > >
> > > On Mon, Sep 14, 2015 at 10:27 PM, Ganesh Ajjanagadde 
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> What is ffmpeg's policy on "necro-bumping" old patches? Or more
> > >> precisely, what is the policy of requesting a patch to be merged where
> > >> all objections raised have been addressed via discussion/updated
> > >> patches, and which have not been merged in over 2 weeks due to unknown
> > >> reasons?
> > >>
> > >> In particular, there are 2 patchsets I would like to get merged:
> > >> 1. This I consider an important patch, simply because it solves a trac
> > >> ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964,
> > >> which also contains links to the patches. A lot of discussion went on
> > >> around it on the mailing lists, and it is supported strongly by
> > >> Nicolas and me. Michael seemed initially hesitant but later became
> > >> convinced of (at least one of the set's) utility, and one of the
> > >> patches was applied. The only objection I recall was from Hendrik,
> > >> which was addressed by Nicolas in a follow-up.
> > >>
> > >> 2. This I consider much more trivial, but in this case there are no
> > >> remaining objections. However, I still consider it important enough
> > >> for a request to re-examine, as I am doing here. The patchset is more
> > >> recent, https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html
> > >> and https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html.
> > >
> > >
> > > Trivial patches can be merged after 24-48 hours if there's no objections
> > > outstanding. For more elaborate patches, poke anyone for review if you 
> > > feel
> > > it would be helpful.
> > >
> > > In both cases, having push access yourself will hurry this along (i.e. you
> > > really should get push access), but in this case I will push later today.
> > > If you don't want push access, poke one of us on IRC to do the push for
> > > you, or bump the original email with a "poke" or "ping".
> > 
> > Thanks. Patches for 2) needs work, and I will be posting it soon.
> 
> 
> > Patch for 1) should be ok (it was reviewed by Nicolas, and Michael
> > seems ok with it like I mentioned).
> 
> there where a few patches, iam not exactly sure which are left and
> what effects they have

> What i objected to and still object to is to cause the terminal to

i withdraw my objection, ill leave it to others to decide which way is
better. Some arguments in this thread have sort of changed my oppinion
from prefering the heuristic to being undecided on what is better

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] -noautorotate option not shown in help

[Ryan Williams]

Thanks Paul, I wasn't aware Boolean options could be set to false by appending 
'=no'.
Perhaps that could be added to the -h full documentation instead?

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Paul B 
Mahol
Sent: Tuesday, 15 September 2015 18:37
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] -noautorotate option not shown in help

On 9/15/15, Ryan Williams  wrote:
> ffmpeg -h full contains the following line:
>
>   -autorotate automatically insert correct rotate filters

Whats wrong with -autorotate=no

>
>
>
> I would like to see an additional line included in the output for the 
> -noautorotate option.
>
> The corresponding comment in doc/ffmpeg.html is "Disable automatically 
> rotating video based on file metadata."
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[Ganesh Ajjanagadde]

Fixes -Wunused-function from
http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/hls.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index c16c770..2ea3a22 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct playlist 
**pls, const char *url
 return 0;
 }
 
-static int open_in(HLSContext *c, AVIOContext **in, const char *url)
-{
-AVDictionary *tmp = NULL;
-int ret;
-
-av_dict_copy(, c->avio_opts, 0);
-
-ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback, );
-
-av_dict_free();
-return ret;
-}
-
 static int url_connect(struct playlist *pls, AVDictionary *opts, AVDictionary 
*opts2)
 {
 AVDictionary *tmp = NULL;
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avformat/format: silence -Wdiscarded-qualifiers

[Michael Niedermayer]

On Wed, Sep 16, 2015 at 06:50:54PM -0400, Ganesh Ajjanagadde wrote:
> lpd.buf is non-const and discards the const qualifier of zerobuffer.
> This fixes -Wdiscarded-qualifiers observed with GCC 5.2.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/format.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/format.c b/libavformat/format.c
> index fd81d7a..9c40512 100644
> --- a/libavformat/format.c
> +++ b/libavformat/format.c
> @@ -172,7 +172,7 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, 
> int is_opened,
>  AVProbeData lpd = *pd;
>  AVInputFormat *fmt1 = NULL, *fmt;
>  int score, nodat = 0, score_max = 0;
> -const static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];
> +static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];

this is wrong, the buffer is constant
if the content of the buffer would change that would be a serious
bug.
Before this change the compiler would detect direct changes done to
the buffer

[...]
-- 
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] avformat/format: silence -Wdiscarded-qualifiers

[Timothy Gu]

On Wed, Sep 16, 2015 at 6:09 PM Michael Niedermayer 
wrote:

> this is wrong, the buffer is constant
> if the content of the buffer would change that would be a serious
> bug.
> Before this change the compiler would detect direct changes done to
> the buffer
>

Commit reverted before a consensus is reached.

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

[FFmpeg-devel] [PATCH] avcodec: use HAVE_THREADS header guards to silence -Wunused-function

[Ganesh Ajjanagadde]

When compiled with --disable-pthreads, e.g
http://fate.ffmpeg.org/report.cgi?time=20150917015044=alpha-debian-qemu-gcc-4.7,
a bunch of -Wunused-functions are reported due to missing header guards
around threading related functions.
This patch should silence such warnings.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/alac.c  | 2 ++
 libavcodec/exr.c   | 2 ++
 libavcodec/ffv1dec.c   | 4 
 libavcodec/flacdec.c   | 2 ++
 libavcodec/h264.c  | 2 ++
 libavcodec/huffyuvdec.c| 2 ++
 libavcodec/mdec.c  | 2 ++
 libavcodec/mimic.c | 4 
 libavcodec/mpeg12dec.c | 2 ++
 libavcodec/mpeg4videodec.c | 2 ++
 libavcodec/pngdec.c| 2 ++
 libavcodec/takdec.c| 2 ++
 libavcodec/tta.c   | 2 ++
 libavcodec/vp3.c   | 4 
 libavcodec/vp8.c   | 2 ++
 libavcodec/vp9.c   | 2 ++
 libavcodec/wavpack.c   | 2 ++
 17 files changed, 40 insertions(+)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 827c0db..1842e7b 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -609,12 +609,14 @@ static av_cold int alac_decode_init(AVCodecContext * 
avctx)
 return 0;
 }
 
+#if HAVE_THREADS
 static int init_thread_copy(AVCodecContext *avctx)
 {
 ALACContext *alac = avctx->priv_data;
 alac->avctx = avctx;
 return allocate_buffers(alac);
 }
+#endif
 
 static const AVOption options[] = {
 { "extra_bits_bug", "Force non-standard decoding process",
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 3b6b245..86a9908 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1426,6 +1426,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 return 0;
 }
 
+#if HAVE_THREADS
 static int decode_init_thread_copy(AVCodecContext *avctx)
 {EXRContext *s = avctx->priv_data;
 
@@ -1436,6 +1437,7 @@ static int decode_init_thread_copy(AVCodecContext *avctx)
 
 return 0;
 }
+#endif
 
 static av_cold int decode_end(AVCodecContext *avctx)
 {
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 557b1a0..e50d943 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -1008,6 +1008,7 @@ static int decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame, AVPac
 return buf_size;
 }
 
+#if HAVE_THREADS
 static int init_thread_copy(AVCodecContext *avctx)
 {
 FFV1Context *f = avctx->priv_data;
@@ -1032,6 +1033,7 @@ static int init_thread_copy(AVCodecContext *avctx)
 
 return 0;
 }
+#endif
 
 static void copy_fields(FFV1Context *fsdst, FFV1Context *fssrc, FFV1Context 
*fsrc)
 {
@@ -1061,6 +1063,7 @@ static void copy_fields(FFV1Context *fsdst, FFV1Context 
*fssrc, FFV1Context *fsr
 }
 }
 
+#if HAVE_THREADS
 static int update_thread_context(AVCodecContext *dst, const AVCodecContext 
*src)
 {
 FFV1Context *fsrc = src->priv_data;
@@ -1104,6 +1107,7 @@ static int update_thread_context(AVCodecContext *dst, 
const AVCodecContext *src)
 
 return 0;
 }
+#endif
 
 AVCodec ff_ffv1_decoder = {
 .name   = "ffv1",
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 8653da7..126f4e0 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -623,6 +623,7 @@ static int flac_decode_frame(AVCodecContext *avctx, void 
*data,
 return bytes_read;
 }
 
+#if HAVE_THREADS
 static int init_thread_copy(AVCodecContext *avctx)
 {
 FLACContext *s = avctx->priv_data;
@@ -633,6 +634,7 @@ static int init_thread_copy(AVCodecContext *avctx)
 return allocate_buffers(s);
 return 0;
 }
+#endif
 
 static av_cold int flac_decode_close(AVCodecContext *avctx)
 {
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index b797893..12fa5c0 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -701,6 +701,7 @@ av_cold int ff_h264_decode_init(AVCodecContext *avctx)
 return 0;
 }
 
+#if HAVE_THREADS
 static int decode_init_thread_copy(AVCodecContext *avctx)
 {
 H264Context *h = avctx->priv_data;
@@ -719,6 +720,7 @@ static int decode_init_thread_copy(AVCodecContext *avctx)
 
 return 0;
 }
+#endif
 
 /**
  * Run setup operations that must be run after slice header decoding.
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index a700abb..7314519 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -571,6 +571,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 return ret;
 }
 
+#if HAVE_THREADS
 static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
 {
 HYuvContext *s = avctx->priv_data;
@@ -595,6 +596,7 @@ static av_cold int decode_init_thread_copy(AVCodecContext 
*avctx)
 
 return 0;
 }
+#endif
 
 /** Subset of GET_VLC for use in hand-roller VLC code */
 #define VLC_INTERN(dst, table, gb, name, bits, max_depth)   \
diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index a9b7e82..1cc4ca4 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -233,6 +233,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 return 0;
 }
 
+#if HAVE_THREADS
 static 

Re: [FFmpeg-devel] [PATCH] AAC encoder: refactor to resynchronize MIPS port

[Claudio Freire]

On Wed, Sep 16, 2015 at 12:30 PM, Nedeljko Babic
 wrote:


 Patch attached.

 I thought it was worth a review.

 It does include lots of copypaste.

 FTR, I tested MIPS 74Kf and x86_64 with make fate-aac
>>>
>>> full fate passes on qemu mips here as well!
>>
>>If there's no objections then, I will be pushing it later today,
>>before it stops applying cleanly.
>
> LGTM regarding mips part. I have no objection.
>
> This is very helpful. Thanks.
>
> Regarding problem with ffserver, I don't think that the cause is the same 
> with the one in:
> http://fate.ffmpeg.org/log.cgi?time=20150914220602=compile=mips-linux-gcc-4.3.2
>
> The problem on the link is caused by environment on which tests are being 
> compiled and run.
>
> You can send me your configuration line and how did you tested it (I am 
> afraid that I didn't work with ffserver), so I can check what is going on.

This is the configure line that works:

./configure --target-os=linux --arch=mips --enable-cross-compile
--cross-prefix=mips-linux- --target-exec='qemu-mips -cpu 74Kf'
--prefix=/opt/cross
--samples=/home/claudiofreire/tmp/audiosamples/ffsamples
--extra-ldflags=-static --ranlib=mips-linux-ranlib --disable-ffserver

And this one blows with the ICE:

./configure --target-os=linux --arch=mips --enable-cross-compile
--cross-prefix=mips-linux- --target-exec='qemu-mips -cpu 74Kf'
--prefix=/opt/cross
--samples=/home/claudiofreire/tmp/audiosamples/ffsamples
--extra-ldflags=-static --ranlib=mips-linux-ranlib

>
> Also, are you building it on some board, or are you cross compiling it?

I'm cross-compiling as you may notice from the above configure lines.

$> /opt/cross/bin/mips-linux-gcc --version
mips-linux-gcc (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Ganesh Ajjanagadde]

On Wed, Sep 16, 2015 at 11:10 AM, Nicolas George  wrote:
> Le nonidi 29 fructidor, an CCXXIII, Clement Boesch a écrit :
>> I don't like FFABSDIFF() patch because it creates a macro very much type
>> specific, while all other FF macro around are type agnostic.
>
> I agree, and I stick to the advice I already posted: define the macro
> locally when needed.

Updated patch on these lines.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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] Need guidance

[anshul]

On Thursday 17 September 2015 12:24 AM, Kinnera Saranu wrote:

Hey I'm new, but I'd like to contribute to your organisation, can someone
please guide me along?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hello,

Welcome to FFmpeg community.

Please Read following link
https://www.ffmpeg.org/developer.html#Contributing

If you need some idea about what you should do, pick anything from 
following link

https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015

If development is not your taste or you don't find yourself capable of 
doing any above task.
Then start with trac.ffmpeg.org and start reproducing bugs, which will 
give you confidence, exposure and curiosity(may be) and if some bug is 
very trivial then come back here and ask for help here on how to solve it.


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

[FFmpeg-devel] [PATCH] avfilter/avf_showcqt: use frequency domain windowing

[Muhammad Faiz]

From c1481882aef8ae45f6416cedfffd26d921fd6fe7 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Wed, 16 Sep 2015 15:24:23 +0700
Subject: [PATCH] avfilter/avf_showcqt: use frequency domain windowing

faster initialization and less code
slightly different result computationally from previous
coeffclamp option is ignored
---
 libavfilter/avf_showcqt.c | 136 +++---
 1 file changed, 31 insertions(+), 105 deletions(-)

diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index 39e1c55..7089758 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -24,8 +24,6 @@
 #include "libavutil/channel_layout.h"
 #include "libavutil/opt.h"
 #include "libavutil/xga_font_data.h"
-#include "libavutil/qsort.h"
-#include "libavutil/time.h"
 #include "libavutil/eval.h"
 #include "avfilter.h"
 #include "internal.h"
@@ -49,7 +47,6 @@
 #define SPECTOGRAM_HEIGHT ((VIDEO_HEIGHT-FONT_HEIGHT)/2)
 #define SPECTOGRAM_START (VIDEO_HEIGHT-SPECTOGRAM_HEIGHT)
 #define BASE_FREQ 20.051392800492
-#define COEFF_CLAMP 1.0e-4
 #define TLENGTH_MIN 0.001
 #define TLENGTH_DEFAULT "384/f*tc/(384/f+tc)"
 #define VOLUME_MIN 1e-10
@@ -59,9 +56,9 @@
 "r(1-ld(1)) + b(ld(1))"
 
 typedef struct {
-FFTSample value;
-int index;
-} SparseCoeff;
+FFTSample *values;
+int start, len;
+} Coeffs;
 
 typedef struct {
 const AVClass *class;
@@ -70,11 +67,9 @@ typedef struct {
 FFTComplex *fft_data;
 FFTComplex *fft_result;
 uint8_t *spectogram;
-SparseCoeff *coeff_sort;
-SparseCoeff *coeffs[VIDEO_WIDTH];
+Coeffs coeffs[VIDEO_WIDTH];
 uint8_t *font_alpha;
 char *fontfile; /* using freetype */
-int coeffs_len[VIDEO_WIDTH];
 uint8_t fontcolor_value[VIDEO_WIDTH*3];  /* result of fontcolor option */
 int64_t frame_count;
 int spectogram_count;
@@ -124,10 +119,9 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_fft_end(s->fft_context);
 s->fft_context = NULL;
 for (k = 0; k < VIDEO_WIDTH; k++)
-av_freep(>coeffs[k]);
+av_freep(>coeffs[k].values);
 av_freep(>fft_data);
 av_freep(>fft_result);
-av_freep(>coeff_sort);
 av_freep(>spectogram);
 av_freep(>font_alpha);
 av_frame_free(>outpicref);
@@ -305,14 +299,6 @@ static double b_func(void *p, double x)
 return (int)(x*255.0+0.5);
 }
 
-static inline int qsort_sparsecoeff(const SparseCoeff *a, const SparseCoeff *b)
-{
-if (fabsf(a->value) >= fabsf(b->value))
-return 1;
-else
-return -1;
-}
-
 static int config_output(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
@@ -325,11 +311,10 @@ static int config_output(AVFilterLink *outlink)
 static const char * const expr_fontcolor_func_names[] = { "midi", "r", 
"g", "b", NULL };
 static double (* const expr_funcs[])(void *, double) = { a_weighting, 
b_weighting, c_weighting, NULL };
 static double (* const expr_fontcolor_funcs[])(void *, double) = { midi, 
r_func, g_func, b_func, NULL };
-int fft_len, k, x, y, ret;
+int fft_len, k, x, ret;
 int num_coeffs = 0;
 int rate = inlink->sample_rate;
 double max_len = rate * (double) s->timeclamp;
-int64_t start_time, end_time;
 int video_scale = s->fullhd ? 2 : 1;
 int video_width = (VIDEO_WIDTH/2) * video_scale;
 int video_height = (VIDEO_HEIGHT/2) * video_scale;
@@ -344,11 +329,10 @@ static int config_output(AVFilterLink *outlink)
 }
 
 s->fft_data = av_malloc_array(fft_len, sizeof(*s->fft_data));
-s->coeff_sort   = av_malloc_array(fft_len, sizeof(*s->coeff_sort));
 s->fft_result   = av_malloc_array(fft_len + 1, sizeof(*s->fft_result));
 s->fft_context  = av_fft_init(s->fft_bits, 0);
 
-if (!s->fft_data || !s->coeff_sort || !s->fft_result || !s->fft_context)
+if (!s->fft_data || !s->fft_result || !s->fft_context)
 return AVERROR(ENOMEM);
 
 #if CONFIG_LIBFREETYPE
@@ -359,8 +343,6 @@ static int config_output(AVFilterLink *outlink)
 s->font_alpha = NULL;
 #endif
 
-av_log(ctx, AV_LOG_INFO, "Calculating spectral kernel, please wait\n");
-start_time = av_gettime_relative();
 ret = av_expr_parse(_expr, s->tlength, expr_vars, NULL, NULL, 
NULL, NULL, 0, ctx);
 if (ret < 0)
 goto eval_error;
@@ -376,22 +358,10 @@ static int config_output(AVFilterLink *outlink)
 goto eval_error;
 
 for (k = 0; k < VIDEO_WIDTH; k++) {
-int hlen = fft_len >> 1;
-float total = 0;
-float partial = 0;
 double freq = BASE_FREQ * exp2(k * (1.0/192.0));
-double tlen, tlength, volume;
+double flen, center, tlength, volume;
+int start, end;
 double expr_vars_val[] = { s->timeclamp, s->timeclamp, freq, freq, 
freq, 0 };
-/* a window function from Albert H. Nuttall,
- * "Some Windows with Very Good Sidelobe Behavior"
- * -93.32 dB peak sidelobe and 18 dB/octave asymptotic decay