[FFmpeg-devel] Looking for the answer about windows-based codec(like wmv) license

[Gigone Lee]

Hi there.

Title says, i have a question about license with windows-based codec, such
as wmv, wma.

As i know, at least, wma(and wmv) is not same wma which is presented from
windows, and it is just compatiable codec so it doesn't require specific
license. but i don't know for sure with that. can i use wmv, wma codec
without license in FFmpeg?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Setting the frame rate in libavcodec/libopenh264enc.c

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 03:49:07PM +, Gregory J Wolfe wrote:
> We have been using Cisco's libopenh264 as part of FFmpeg with good results.
> However, function svc_encode_init() in libavcodec/libopenh264enc.c appears to
> be setting the frame rate incorrectly.  The line of code in question looks 
> like:
> 
> param.fMaxFrameRate = avctx->time_base.den / avctx->time_base.num;
> 
> Since fMaxFrameRate is of type float, shouldn't this be something like:
> 
> param.fMaxFrameRate = avctx->time_base.den / (double)avctx->time_base.num;

equivalent change made

thanks

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 10:10:17PM +0300, Ivan Uskov wrote:
> Hello All,
> 
> Current implementation of handling MFXVideoENCODE_EncodeFrameAsync()
> return codes allows unhanded silent warnings and unclear error
> reporting if the function return some non-successful code.
> The attached patch solves this issue and makes troubleshooting more
> easy. Please review.
>   
> 
> -- 
> Best regards,
>  Ivan  mailto:ivan.us...@nablet.com

>  qsvenc.c |   18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> ea4b9e9cb073156b0fa4f7ffa4fc4c32c43ab0a1  
> 0001-libavcodec-qsvenc.c-improving-handling-for-return-co.patch
> From 0b2b547325821ace205ddfbecad13d56cd21ca7b Mon Sep 17 00:00:00 2001
> From: Ivan Uskov 
> Date: Thu, 9 Jul 2015 22:01:00 +0300
> Subject: [PATCH] libavcodec/qsvenc.c: improving handling for return codes of
>  MFXVideoENCODE_EncodeFrameAsync

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 08:24:52PM +0200, Andreas Cadhalpun wrote:
> On 08.07.2015 18:07, Michael Niedermayer wrote:
> > On Wed, Jul 08, 2015 at 07:24:13AM -0400, Ronald S. Bultje wrote:
> >> - last of all, I want to remind you guys that we haven't done a very
> >> thorough code analysis to see if this can actually be triggered. As an
> >> example, look at commit 458446acfa1441d283dacf9e6e545beb083b8bb0. Before
> >> that, vp8 files smaller than 16x16 or vp9 files smaller than 64x64 could
> >> cause aborts. The vp9 ones I noticed due to some fate files being so small.
> >> I doubt you'll ever find such vp8 files, but they're valid.
> >>
> >> Let's not add silly checks to replace other silly ones.
> 
> Do you have any vp9 files triggering this assert?
> 
> > if people prefer i ca revert b8c438e7623644edcfdb508c946a723a3b79b893
> > or add a check for stride == 0
> > 
> > what do people prefer ?
> 
> The assert can be triggered by the h264 decoder:
> mc_dir_part in libavcodec/h264_mb.c calls the 16 bit variant of
> emulated_edge_mc and thus the assert is triggered due to the
> sizeof(pixel) factor, even though block_w is smaller than buf_linesize.
> 
> If that's valid behavior of the h264 decoder, then the assert should
> be removed, but if on the other hand this is a bug in the h264
> decoder, then that should be fixed and the assert remain.

just posted a patch which should fix these assertion failures

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] avcodec/utils: use a minimum 32pixel width in avcodec_align_dimensions2() for H.264

[Michael Niedermayer]

Fixes Assertion failure
Found-by: Andreas Cadhalpun 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 96f177d..925b3ed 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -428,10 +428,12 @@ void avcodec_align_dimensions2(AVCodecContext *s, int 
*width, int *height,
 
 *width  = FFALIGN(*width, w_align);
 *height = FFALIGN(*height, h_align);
-if (s->codec_id == AV_CODEC_ID_H264 || s->lowres)
+if (s->codec_id == AV_CODEC_ID_H264 || s->lowres) {
 // some of the optimized chroma MC reads one line too much
 // which is also done in mpeg decoders with lowres > 0
 *height += 2;
+*width = FFMAX(*width, 32);
+}
 
 for (i = 0; i < 4; i++)
 linesize_align[i] = STRIDE_ALIGN;
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 08:16:29PM +0200, Andreas Cadhalpun wrote:
> On 08.07.2015 01:22, Michael Niedermayer wrote:
> > On Tue, Jul 07, 2015 at 11:32:59PM +0200, Andreas Cadhalpun wrote:
> >> I think the assert is a historic leftover:
> >> Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because
> >> the blocks were interleaved in the tmp buffer and the last block
> >> was added with an offset of 6*MB_SIZE.
> >> It was changed for src_stride <= 7*MB_SIZE to write the blocks
> >> sequentially, hence the larger tmp_stride. (A comment about this
> >> in the code would have been nice.)
> > 
> > yes, should i add one or you want to ?
> 
> I added one to the patch. Updated version attached.
> Does that sound good?
> 
> >> However, there are still some things in this code which are unclear for me:
> >>  * Where does the 5 in 'src_stride > 2*MB_SIZE + 5' come from?
> >>Shouldn't that have been HTAPS_MAX-1, because that is added to block_h,
> >>when calling emulated_edge_mc?
> >>  * Why the factor 2 in 'src_stride > 2*MB_SIZE + 5'?
> >>Before commit cc884a35 the buffer size was 'src_stride*(b_h+5)' and
> >>b_h is at maximum MB_SIZE, not 2*MB_SIZE.
> > 
> > I dont remember trying to make the assert be exact just sufficient
> > to detect problems, it was not intended to stay IIRC, so it would have
> > been a waste of time to calculate exactly what the minimum size
> > was
> > also i think that we should only spend time on this investigation if
> > we intend to work on the code. Its hardly worth for just removing
> > the apparently unneeded assert.
> > if you want to improve snow (the algorithm or implementation)
> > then investigating every smal bit does make sense
> 
> OK.
> 
> >>  * Why is tmp_step based on MB_SIZE and not (MB_SIZE + HTAPS_MAX-1)?
> >>This 'HTAPS_MAX-1' is added to b_w/b_h when calling emulated_edge_mc.
> > 
> > to keep things aligned in memory, it may help or be required for SIMD
> > use
> 
> I suppose that's correct then.
> 
> Best regards,
> Andreas

>  snow.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 62ba6bae883891f9953478d52d591e5f16aa759e  
> 0001-snow-remove-an-obsolete-av_assert2.patch
> From 7747ec5a7e319c05e28c6988caa84ad1f37fd301 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Thu, 9 Jul 2015 19:50:34 +0200
> Subject: [PATCH] snow: remove an obsolete av_assert2
> 
> It asserts that the frame linesize is larger than 37, but it can be
> smaller and decoding such frames works.
> 
> Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because the
> blocks were interleaved in the tmp buffer and the last block was added
> with an offset of 6*MB_SIZE.
> It was changed for src_stride <= 7*MB_SIZE to write the blocks
> sequentially, hence the larger tmp_step.
> After that the assert was only necessary to make sure that the buffer
> remained large enough.
> Since commit bd2b6b33 s->scratchbuf is used as tmp buffer.
> As part of commit 86e107a7 the minimal scratchbuf size was increased to
> 256*7*MB_SIZE, which is enough for any src_stride <= 7*MB_SIZE.
> 
> Also add a comment explaining the tmp_step calculation.
> 
> Signed-off-by: Andreas Cadhalpun 

LGTM

thanks

[...]

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

[FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Fix quantisation table handling

[Carl Eugen Hoyos]

Hi!

Attached patch fixes jpeg over rtp if the encoder placed 
quantisation tables into different DQT chunks.
Sample also attached.

Please review, Carl Eugen
diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index 13d61a9..84aa66c 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -28,7 +28,7 @@
 void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t *buf, int size)
 {
 RTPMuxContext *s = s1->priv_data;
-const uint8_t *qtables = NULL;
+const uint8_t *qtables[4] = { NULL };
 int nb_qtables = 0;
 uint8_t type;
 uint8_t w, h;
@@ -64,18 +64,25 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
 continue;
 
 if (buf[i + 1] == DQT) {
+int tables, j;
 if (buf[i + 4] & 0xF0)
 av_log(s1, AV_LOG_WARNING,
"Only 8-bit precision is supported.\n");
 
 /* a quantization table is 64 bytes long */
-nb_qtables = AV_RB16(&buf[i + 2]) / 65;
+tables = AV_RB16(&buf[i + 2]) / 65;
 if (i + 4 + nb_qtables * 65 > size) {
 av_log(s1, AV_LOG_ERROR, "Too short JPEG header. Aborted!\n");
 return;
 }
+if (nb_qtables + tables > 4) {
+av_log(s1, AV_LOG_ERROR, "Invalid number of quantisation 
tables\n");
+return;
+}
 
-qtables = &buf[i + 4];
+for (j = 0; j < tables; j++)
+qtables[nb_qtables + j] = buf + i + 5 + j * 65;
+nb_qtables += tables;
 } else if (buf[i + 1] == SOF0) {
 if (buf[i + 14] != 17 || buf[i + 17] != 17) {
 av_log(s1, AV_LOG_ERROR,
@@ -150,7 +157,7 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
 bytestream_put_be16(&p, 64 * nb_qtables);
 
 for (i = 0; i < nb_qtables; i++)
-bytestream_put_buffer(&p, &qtables[65 * i + 1], 64);
+bytestream_put_buffer(&p, qtables[i], 64);
 }
 
 /* copy payload data */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement slice threading

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_stereo3d.c | 72 ---
 1 file changed, 49 insertions(+), 23 deletions(-)

diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
index 771bdde..18799d9 100644
--- a/libavfilter/vf_stereo3d.c
+++ b/libavfilter/vf_stereo3d.c
@@ -142,6 +142,7 @@ typedef struct Stereo3DContext {
 int pixstep[4];
 AVFrame *prev;
 double ts_unit;
+int in_off_left[4], in_off_right[4];
 } Stereo3DContext;
 
 #define OFFSET(x) offsetof(Stereo3DContext, x)
@@ -485,6 +486,43 @@ static inline uint8_t ana_convert(const int *coeff, const 
uint8_t *left, const u
 return av_clip_uint8(sum >> 16);
 }
 
+typedef struct ThreadData {
+Stereo3DContext *s;
+AVFrame *ileft, *iright;
+AVFrame *out;
+} ThreadData;
+
+static int filter_slice(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+ThreadData *td = arg;
+Stereo3DContext *s = td->s;
+AVFrame *ileft = td->ileft;
+AVFrame *iright = td->iright;
+AVFrame *out = td->out;
+int height = s->out.height;
+int start = (height *  jobnr   ) / nb_jobs;
+int end   = (height * (jobnr+1)) / nb_jobs;
+uint8_t *dst = out->data[0];
+const int **ana_matrix = s->ana_matrix;
+int x, y, il, ir, o;
+const uint8_t *lsrc = ileft->data[0];
+const uint8_t *rsrc = iright->data[0];
+int out_width = s->out.width;
+
+for (y = start; y < end; y++) {
+o   = out->linesize[0] * y;
+il  = s->in_off_left[0]  + y * ileft->linesize[0];
+ir  = s->in_off_right[0] + y * iright->linesize[0];
+for (x = 0; x < out_width; x++, il += 3, ir += 3, o+= 3) {
+dst[o] = ana_convert(ana_matrix[0], lsrc + il, rsrc + ir);
+dst[o + 1] = ana_convert(ana_matrix[1], lsrc + il, rsrc + ir);
+dst[o + 2] = ana_convert(ana_matrix[2], lsrc + il, rsrc + ir);
+}
+}
+
+return 0;
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 {
 AVFilterContext *ctx  = inlink->dst;
@@ -492,7 +530,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 AVFilterLink *outlink = ctx->outputs[0];
 AVFrame *out, *oleft, *oright, *ileft, *iright;
 int out_off_left[4], out_off_right[4];
-int in_off_left[4], in_off_right[4];
 int i;
 
 switch (s->in.format) {
@@ -534,8 +571,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 for (i = 0; i < 4; i++) {
 int hsub = i == 1 || i == 2 ? s->hsub : 0;
 int vsub = i == 1 || i == 2 ? s->vsub : 0;
-in_off_left[i]   = (FF_CEIL_RSHIFT(s->in.row_left,   vsub) + 
s->in.off_lstep)  * ileft->linesize[i]  + FF_CEIL_RSHIFT(s->in.off_left   * 
s->pixstep[i], hsub);
-in_off_right[i]  = (FF_CEIL_RSHIFT(s->in.row_right,  vsub) + 
s->in.off_rstep)  * iright->linesize[i] + FF_CEIL_RSHIFT(s->in.off_right  * 
s->pixstep[i], hsub);
+s->in_off_left[i]   = (FF_CEIL_RSHIFT(s->in.row_left,   vsub) + 
s->in.off_lstep)  * ileft->linesize[i]  + FF_CEIL_RSHIFT(s->in.off_left   * 
s->pixstep[i], hsub);
+s->in_off_right[i]  = (FF_CEIL_RSHIFT(s->in.row_right,  vsub) + 
s->in.off_rstep)  * iright->linesize[i] + FF_CEIL_RSHIFT(s->in.off_right  * 
s->pixstep[i], hsub);
 out_off_left[i]  = (FF_CEIL_RSHIFT(s->out.row_left,  vsub) + 
s->out.off_lstep) * oleft->linesize[i]  + FF_CEIL_RSHIFT(s->out.off_left  * 
s->pixstep[i], hsub);
 out_off_right[i] = (FF_CEIL_RSHIFT(s->out.row_right, vsub) + 
s->out.off_rstep) * oright->linesize[i] + FF_CEIL_RSHIFT(s->out.off_right * 
s->pixstep[i], hsub);
 }
@@ -556,12 +593,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 for (i = 0; i < s->nb_planes; i++) {
 av_image_copy_plane(oleft->data[i] + out_off_left[i],
 oleft->linesize[i] * s->row_step,
-ileft->data[i] + in_off_left[i],
+ileft->data[i] + s->in_off_left[i],
 ileft->linesize[i] * s->row_step,
 s->linesize[i], s->pheight[i]);
 av_image_copy_plane(oright->data[i] + out_off_right[i],
 oright->linesize[i] * s->row_step,
-iright->data[i] + in_off_right[i],
+iright->data[i] + s->in_off_right[i],
 iright->linesize[i] * s->row_step,
 s->linesize[i], s->pheight[i]);
 }
@@ -571,7 +608,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 case MONO_R:
 for (i = 0; i < s->nb_planes; i++) {
 av_image_copy_plane(out->data[i], out->linesize[i],
-iright->data[i] + in_off_left[i],
+iright->data[i] + s->in_off_left[i],
 iright->linesize[i],
  

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync

[Ivan Uskov]

Hello All,

Current implementation of handling MFXVideoENCODE_EncodeFrameAsync()
return codes allows unhanded silent warnings and unclear error
reporting if the function return some non-successful code.
The attached patch solves this issue and makes troubleshooting more
easy. Please review.
  

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

0001-libavcodec-qsvenc.c-improving-handling-for-return-co.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] concatdec: add support for injecting packet metadata

[Marton Balint]

On Thu, 9 Jul 2015, Nicolas George wrote:


Le decadi 20 messidor, an CCXXIII, Marton Balint a écrit :

I'd still use the metadata directive. If someone needs per-stream, or
per-packet metadata, he can implement selector directives for that. Like
metadata_stream or metadata_interval which will change the scope of the
following metadata directives.

How about that?


I am still uneasy about that. Selectors feel like making the parser more
complex, and also there is the issue of self-documentation.

When someone reads a concat script and see "metadata foo=bar", unless they
already know exactly the directive, they will take a guess at what it does,
and since packet metadata is rare, especially packet metadata that is
duplicated over all the packets, they will probably not guess right.

I really think a more specific name would be useful.


What about "file_packet_metadata"?

It clearly states that metadata is set on a file level, and it belongs to 
packets.




This is an usability issue, though, so my role as maintainer is not very
important: let us ear advice from other people.


Sure, anybody? :)

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Do not check the table number before warning about the precision

[Carl Eugen Hoyos]

Michael Niedermayer  gmx.at> writes:

> > Imo, the precision check in rtpenc_jpeg.c is wrong: 
> > Only the upper four bits contain the precision, the 
> > lower four bits are the table number.

> LGTM

Merged by you.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables

[Carl Eugen Hoyos]

Michael Niedermayer  gmx.at> writes:

> > +   "Only standard Huffman tables are supported\n");
> 
> I think the error messages should be changed to say 
> that RFC... doesnt allow stuff not that its not 
> supported implying it could be supported

Merged with a different error message.

I tried to add some information to ticket #3823:
-vcodec mjpeg -pix_fmt yuv422p -f rtp fails because 
it would require encoding in rows of 1 block 
instead of 2.
Other encoders use custom Huffman tables which are 
also not allowed.
I believe there is still a bug with quantisation 
tables that I'll try to fix.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]Use av_log to print benchmark output

[Carl Eugen Hoyos]

Michael Niedermayer  gmx.at> writes:

> > Attached patch stops -benchmark from using stdout.

> i wonder why this used printf()
> maybe wait a day or 2 before applying in case there 
> was a reason that i forgot

Merged.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not unecessarily consume memory for cuepoints

[Carl Eugen Hoyos]

Michael Niedermayer  gmx.at> writes:

> > > > Matroska streaming currently consumes memory for
> > > > cuepoints that are never used if the output stream
> > > > is no seekable. This can lead to oom.
> > > > Attached patch fixes ticket #4690.


> should be ok

The patch was merged.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2

[Andreas Cadhalpun]

On 08.07.2015 18:07, Michael Niedermayer wrote:
> On Wed, Jul 08, 2015 at 07:24:13AM -0400, Ronald S. Bultje wrote:
>> - last of all, I want to remind you guys that we haven't done a very
>> thorough code analysis to see if this can actually be triggered. As an
>> example, look at commit 458446acfa1441d283dacf9e6e545beb083b8bb0. Before
>> that, vp8 files smaller than 16x16 or vp9 files smaller than 64x64 could
>> cause aborts. The vp9 ones I noticed due to some fate files being so small.
>> I doubt you'll ever find such vp8 files, but they're valid.
>>
>> Let's not add silly checks to replace other silly ones.

Do you have any vp9 files triggering this assert?

> if people prefer i ca revert b8c438e7623644edcfdb508c946a723a3b79b893
> or add a check for stride == 0
> 
> what do people prefer ?

The assert can be triggered by the h264 decoder:
mc_dir_part in libavcodec/h264_mb.c calls the 16 bit variant of
emulated_edge_mc and thus the assert is triggered due to the
sizeof(pixel) factor, even though block_w is smaller than buf_linesize.

If that's valid behavior of the h264 decoder, then the assert should
be removed, but if on the other hand this is a bug in the h264
decoder, then that should be fixed and the assert remain.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown

[Dave Rice]

> On Jul 9, 2015, at 1:53 PM, Michael Niedermayer  wrote:
> 
> On Tue, Jul 07, 2015 at 11:03:39AM -0400, Dave Rice wrote:
>> Hi,
>> 
>>> On Jul 7, 2015, at 10:35 AM, Michael Niedermayer  wrote:
>>> 
>>> On Thu, Jul 02, 2015 at 09:50:21AM -0400, Dave Rice wrote:
 Hi all,
 Last month I posted a draft of the FFV1 specification formatted in 
 Markdown [1], whereas it currently lives in lyx. From that post there were 
 responses in favor of the use of Markdown formatting and suggestions to 
 not use mathml within a draft targeting an RFC specification and 
 suggestions to update a few urls. I propose to proceed with a format 
 conversion of the FFV1 specification from lyx to Markdown and then I'll 
 file tickets or patches to explore simplifying the mathml expressions and 
 updating the urls. Attached is a patch to convert the formatting (but not 
 meaning) of the FFV1 specification from lyx to markdown.
 
 Best Regards,
 Dave Rice
 
 [1] http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/193851
 
>>> 
>>> how can this be edited and converted ?
>> 
>> Via pandoc you can get outputs that are close to the current ffv1.html and 
>> ffv1.pdf outputs of ffv1.lyx.
>> 
>> pandoc --mathml -s --number-sections ../ffv1.md -c lyx.css -o ffv1.html
>> pandoc -s --number-sections ../ffv1.md --latex-engine=xelatex -V 
>> geometry:margin=1in -o ffv1.pdf
>> 
>> I can move this info to a readme.
> 
> please do

Sure. Would you prefer a patch on ffmpeg-devel or a PR in github?

> ive tried with
> pandoc --version
> pandoc 1.9.1.1

I'm using:
pandoc --version
pandoc 1.13.2.1

I'm only recently introduced to pandoc so I'm not well aware of the difference 
from 1.9.1.1 to 1.13.3.1, but I do see a lot of references to markdown and 
table bug fixes in http://pandoc.org/releases.html 
 after 1.9.1.1.

> and it also fails (all tables messed up), the html in git looks good though

Could you give me access to your pdf so I can see the difference.

> does this use features available only in recent pandoc ?

It seems so.
Dave Rice

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

Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2

[Andreas Cadhalpun]

On 08.07.2015 01:22, Michael Niedermayer wrote:
> On Tue, Jul 07, 2015 at 11:32:59PM +0200, Andreas Cadhalpun wrote:
>> I think the assert is a historic leftover:
>> Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because
>> the blocks were interleaved in the tmp buffer and the last block
>> was added with an offset of 6*MB_SIZE.
>> It was changed for src_stride <= 7*MB_SIZE to write the blocks
>> sequentially, hence the larger tmp_stride. (A comment about this
>> in the code would have been nice.)
> 
> yes, should i add one or you want to ?

I added one to the patch. Updated version attached.
Does that sound good?

>> However, there are still some things in this code which are unclear for me:
>>  * Where does the 5 in 'src_stride > 2*MB_SIZE + 5' come from?
>>Shouldn't that have been HTAPS_MAX-1, because that is added to block_h,
>>when calling emulated_edge_mc?
>>  * Why the factor 2 in 'src_stride > 2*MB_SIZE + 5'?
>>Before commit cc884a35 the buffer size was 'src_stride*(b_h+5)' and
>>b_h is at maximum MB_SIZE, not 2*MB_SIZE.
> 
> I dont remember trying to make the assert be exact just sufficient
> to detect problems, it was not intended to stay IIRC, so it would have
> been a waste of time to calculate exactly what the minimum size
> was
> also i think that we should only spend time on this investigation if
> we intend to work on the code. Its hardly worth for just removing
> the apparently unneeded assert.
> if you want to improve snow (the algorithm or implementation)
> then investigating every smal bit does make sense

OK.

>>  * Why is tmp_step based on MB_SIZE and not (MB_SIZE + HTAPS_MAX-1)?
>>This 'HTAPS_MAX-1' is added to b_w/b_h when calling emulated_edge_mc.
> 
> to keep things aligned in memory, it may help or be required for SIMD
> use

I suppose that's correct then.

Best regards,
Andreas
>From 7747ec5a7e319c05e28c6988caa84ad1f37fd301 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Thu, 9 Jul 2015 19:50:34 +0200
Subject: [PATCH] snow: remove an obsolete av_assert2

It asserts that the frame linesize is larger than 37, but it can be
smaller and decoding such frames works.

Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because the
blocks were interleaved in the tmp buffer and the last block was added
with an offset of 6*MB_SIZE.
It was changed for src_stride <= 7*MB_SIZE to write the blocks
sequentially, hence the larger tmp_step.
After that the assert was only necessary to make sure that the buffer
remained large enough.
Since commit bd2b6b33 s->scratchbuf is used as tmp buffer.
As part of commit 86e107a7 the minimal scratchbuf size was increased to
256*7*MB_SIZE, which is enough for any src_stride <= 7*MB_SIZE.

Also add a comment explaining the tmp_step calculation.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/snow.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/snow.h b/libavcodec/snow.h
index 95e07cd..447859f 100644
--- a/libavcodec/snow.h
+++ b/libavcodec/snow.h
@@ -304,6 +304,8 @@ static av_always_inline void add_yblock(SnowContext *s, int sliced, slice_buffer
 BlockNode *lb= lt+b_stride;
 BlockNode *rb= lb+1;
 uint8_t *block[4];
+// When src_stride is large enough, it is possible to interleave the blocks.
+// Otherwise the blocks are written sequentially in the tmp buffer.
 int tmp_step= src_stride >= 7*MB_SIZE ? MB_SIZE : MB_SIZE*src_stride;
 uint8_t *tmp = s->scratchbuf;
 uint8_t *ptmp;
@@ -347,8 +349,6 @@ static av_always_inline void add_yblock(SnowContext *s, int sliced, slice_buffer
 
 if(b_w<=0 || b_h<=0) return;
 
-av_assert2(src_stride > 2*MB_SIZE + 5);
-
 if(!sliced && offset_dst)
 dst += src_x + src_y*dst_stride;
 dst8+= src_x + src_y*src_stride;
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] movtextdec.c: Add support for highlight and hilightcolor box

[Philip Langdale]

On 2015-07-06 14:42, Clément Bœsch wrote:



 {
 int i = 0;
 int text_pos = 0;
 while (text < text_end) {
-for (i = 0; i < style_entries; i++) {
-if (s[i]->style_flag && text_pos == s[i]->style_end) {
-if (s[i]->style_flag & STYLE_FLAG_BOLD)
-av_bprintf(buf, "{\\b0}");
-if (s[i]->style_flag & STYLE_FLAG_ITALIC)
-av_bprintf(buf, "{\\i0}");
-if (s[i]->style_flag & STYLE_FLAG_UNDERLINE)
-av_bprintf(buf, "{\\u0}");
+if (m->box_flags & STYL_BOX) {



+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag && text_pos == 
m->s[i]->style_end) {

+if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
+av_bprintf(buf, "{\\b0}");
+if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
+av_bprintf(buf, "{\\i0}");
+if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
+av_bprintf(buf, "{\\u0}");
+}
+}


keep this block not re-idented (and eventually add a /* TODO: reindent 
*/

above) to keep the diff small and ease review. You can re-indent in a
later commit.


Do you really mean this? This is not a simple re-indent. The variables 
on those
lines are also changing? In which case, I'd include the re-indent at the 
same time.


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

Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown

[Michael Niedermayer]

On Tue, Jul 07, 2015 at 11:03:39AM -0400, Dave Rice wrote:
> Hi,
> 
> > On Jul 7, 2015, at 10:35 AM, Michael Niedermayer  wrote:
> > 
> > On Thu, Jul 02, 2015 at 09:50:21AM -0400, Dave Rice wrote:
> >> Hi all,
> >> Last month I posted a draft of the FFV1 specification formatted in 
> >> Markdown [1], whereas it currently lives in lyx. From that post there were 
> >> responses in favor of the use of Markdown formatting and suggestions to 
> >> not use mathml within a draft targeting an RFC specification and 
> >> suggestions to update a few urls. I propose to proceed with a format 
> >> conversion of the FFV1 specification from lyx to Markdown and then I'll 
> >> file tickets or patches to explore simplifying the mathml expressions and 
> >> updating the urls. Attached is a patch to convert the formatting (but not 
> >> meaning) of the FFV1 specification from lyx to markdown.
> >> 
> >> Best Regards,
> >> Dave Rice
> >> 
> >> [1] http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/193851
> >> 
> > 
> > how can this be edited and converted ?
> 
> Via pandoc you can get outputs that are close to the current ffv1.html and 
> ffv1.pdf outputs of ffv1.lyx.
> 
> pandoc --mathml -s --number-sections ../ffv1.md -c lyx.css -o ffv1.html
> pandoc -s --number-sections ../ffv1.md --latex-engine=xelatex -V 
> geometry:margin=1in -o ffv1.pdf
> 
> I can move this info to a readme.

please do
ive tried with
pandoc --version
pandoc 1.9.1.1

and it also fails (all tables messed up), the html in git looks good though

does this use features available only in recent pandoc ?

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

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


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

Re: [FFmpeg-devel] GSoC Weely report (libswscale)

[Michael Niedermayer]

On Wed, Jul 08, 2015 at 10:36:56PM -0300, Pedro Arthur wrote:
> Hi,
> 
> Last week I worked on adding the ring buffer logic into SwsSlice and fixing
> some seg faults. As I'm having some problems with git send-email through
> gmail I've attached the patch.

these patches dont seem to apply cleanly
You can try to apply them on a fresh checkout to see the problem
(also see below)

Also i think you used git merge in your git branch, this is not
recommanded, and might be related to why they dont apply

In practice its probably best if you use git pull --rebase
when updating to a new version. Its quite likely that earlier changes
in the set will need to be updated and that would not be possible
with a merge occirug later

to correct the patches so they apply again you can probably
checkout origin/master, create a new branch and cherry pick
the comits on top of that, correcting any conflicts that might pop
up, and test that things still work after moving the changes on top
of the latest code


ffmpeg-git/ffmpeg/.git/rebase-apply/patch:142: tab in indent.
int maxSize;
ffmpeg-git/ffmpeg/.git/rebase-apply/patch:153: tab in indent.
maxSize = FFMAX(c->vLumFilterSize, c->vChrFilterSize << 
c->chrSrcVSubSample);
error: libswscale/slice.c: does not exist in index
error: patch failed: libswscale/swscale.c:451
error: libswscale/swscale.c: patch does not apply
error: patch failed: libswscale/swscale_internal.h:932
error: libswscale/swscale_internal.h: patch does not apply
Patch failed at 0001 swscale: fix seg fault when accessing src slice
The copy of the patch that failed is found in:
   ffmpeg-git/ffmpeg/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Applying: swscale: fix seg fault when accessing src slice
ffmpeg-git/ffmpeg/.git/rebase-apply/patch:142: tab in indent.
int maxSize;
ffmpeg-git/ffmpeg/.git/rebase-apply/patch:153: tab in indent.
maxSize = FFMAX(c->vLumFilterSize, c->vChrFilterSize << 
c->chrSrcVSubSample);
warning: 2 lines add whitespace errors.
Using index info to reconstruct a base tree...
A   libswscale/slice.c
M   libswscale/swscale.c
M   libswscale/swscale_internal.h
:142: tab in indent.
int maxSize;
:153: tab in indent.
maxSize = FFMAX(c->vLumFilterSize, c->vChrFilterSize << 
c->chrSrcVSubSample);
:165: new blank line at EOF.
+
warning: 2 lines applied after fixing whitespace errors.
Falling back to patching base and 3-way merge...
error: refusing to lose untracked file at 'libswscale/slice.c'
Auto-merging libswscale/swscale_internal.h
CONFLICT (content): Merge conflict in libswscale/swscale_internal.h
Auto-merging libswscale/swscale.c
CONFLICT (content): Merge conflict in libswscale/swscale.c
CONFLICT (modify/delete): libswscale/slice.c deleted in HEAD and modified in 
swscale: fix seg fault when accessing src slice. Version swscale: fix seg fault 
when accessing src slice of libswscale/slice.c left in tree.
Failed to merge in the changes.
Patch failed at 0001 swscale: fix seg fault when accessing src slice
The copy of the patch that failed is found in:
   ffmpeg-git/ffmpeg/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout

[wm4]

On Thu, 9 Jul 2015 14:10:40 +0200
Hendrik Leppkes  wrote:

> On Thu, Jul 9, 2015 at 1:32 PM, wm4  wrote:
> > On Tue,  7 Jul 2015 03:06:24 -0300
> > James Almer  wrote:
> >
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavcodec/libdcadec.c | 34 ++
> >>  1 file changed, 34 insertions(+)
> >>
> >> diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
> >> index 4bc3765..796826e 100644
> >> --- a/libavcodec/libdcadec.c
> >> +++ b/libavcodec/libdcadec.c
> >> @@ -36,6 +36,8 @@ typedef struct DCADecContext {
> >>  int buffer_size;
> >>  } DCADecContext;
> >>
> >> +static int downmix_warned = 0;
> >> +
> >>  static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
> >> int *got_frame_ptr, AVPacket *avpkt)
> >>  {
> >> @@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx, 
> >> void *data,
> >>  if (exss = dcadec_context_get_exss_info(s->ctx)) {
> >>  enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
> >>
> >> +if (!downmix_warned) {
> >> +uint64_t layout = avctx->request_channel_layout;
> >> +
> >> +if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout == 
> >> AV_CH_LAYOUT_STEREO) && !exss->embedded_stereo) ||
> >> +( layout == AV_CH_LAYOUT_5POINT1 && !exss->embedded_6ch))
> >> +av_log(avctx, AV_LOG_WARNING, "%s downmix was requested 
> >> but no custom coefficients are available, "
> >> +  "this may result in 
> >> clipping\n",
> >> +  layout == 
> >> AV_CH_LAYOUT_5POINT1 ? "5.1" : "stereo");
> >> +downmix_warned = 1;
> >> +}
> >> +
> >
> > What does this mean? Does this happen with FFmpeg's DCA decoder too?
> >
> 
> It just means that the DCA stream has no embedded downmix
> coefficients. It'll downmix using the default coeffs, which can mean
> two things, 1) this was intended, and all is fine, 2) downmixing was
> not considered, and it may clip.
> Personally, I might like a mode where it would downmix if the coeffs
> are available, and not downmix if not (so I can downmix clipping-safe
> using av/swresample later).

I'd prefer that too.

> The native decoder would have the same problem, but I don't know if it
> even supports embedded downmixes properly.

Then I guess it doesn't matter, as it won't cause regressions. Thanks
for the explanation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout

[James Almer]

On 09/07/15 9:10 AM, Hendrik Leppkes wrote:
> On Thu, Jul 9, 2015 at 1:32 PM, wm4  wrote:
>> On Tue,  7 Jul 2015 03:06:24 -0300
>> James Almer  wrote:
>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavcodec/libdcadec.c | 34 ++
>>>  1 file changed, 34 insertions(+)
>>>
>>> diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
>>> index 4bc3765..796826e 100644
>>> --- a/libavcodec/libdcadec.c
>>> +++ b/libavcodec/libdcadec.c
>>> @@ -36,6 +36,8 @@ typedef struct DCADecContext {
>>>  int buffer_size;
>>>  } DCADecContext;
>>>
>>> +static int downmix_warned = 0;
>>> +
>>>  static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
>>> int *got_frame_ptr, AVPacket *avpkt)
>>>  {
>>> @@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx, 
>>> void *data,
>>>  if (exss = dcadec_context_get_exss_info(s->ctx)) {
>>>  enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
>>>
>>> +if (!downmix_warned) {
>>> +uint64_t layout = avctx->request_channel_layout;
>>> +
>>> +if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout == 
>>> AV_CH_LAYOUT_STEREO) && !exss->embedded_stereo) ||
>>> +( layout == AV_CH_LAYOUT_5POINT1 && !exss->embedded_6ch))
>>> +av_log(avctx, AV_LOG_WARNING, "%s downmix was requested 
>>> but no custom coefficients are available, "
>>> +  "this may result in 
>>> clipping\n",
>>> +  layout == 
>>> AV_CH_LAYOUT_5POINT1 ? "5.1" : "stereo");
>>> +downmix_warned = 1;
>>> +}
>>> +
>>
>> What does this mean? Does this happen with FFmpeg's DCA decoder too?
>>
> 
> It just means that the DCA stream has no embedded downmix
> coefficients. It'll downmix using the default coeffs, which can mean
> two things, 1) this was intended, and all is fine, 2) downmixing was
> not considered, and it may clip.
> Personally, I might like a mode where it would downmix if the coeffs
> are available, and not downmix if not (so I can downmix clipping-safe
> using av/swresample later).

It can't be currently done, as the behavior of the flags is pretty inconsistent
as i described in the patch.

We could however open a ticket asking the dcadec developer to actually change
the implementation so something like that is possible before the first version
is tagged (To avoid ifdeffery).

> 
> The native decoder would have the same problem, but I don't know if it
> even supports embedded downmixes properly.
> 
> - Hendrik
> ___
> 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] fate: add removegrain tests

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 08:02:06AM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  tests/fate/filter-video.mak   | 78 
> +++
>  tests/ref/fate/filter-removegrain-mode-00 |  2 +
>  tests/ref/fate/filter-removegrain-mode-01 |  2 +
>  tests/ref/fate/filter-removegrain-mode-02 |  2 +
>  tests/ref/fate/filter-removegrain-mode-03 |  2 +
>  tests/ref/fate/filter-removegrain-mode-04 |  2 +
>  tests/ref/fate/filter-removegrain-mode-05 |  2 +
>  tests/ref/fate/filter-removegrain-mode-06 |  2 +
>  tests/ref/fate/filter-removegrain-mode-07 |  2 +
>  tests/ref/fate/filter-removegrain-mode-08 |  2 +
>  tests/ref/fate/filter-removegrain-mode-09 |  2 +
>  tests/ref/fate/filter-removegrain-mode-10 |  2 +
>  tests/ref/fate/filter-removegrain-mode-11 |  2 +
>  tests/ref/fate/filter-removegrain-mode-12 |  2 +
>  tests/ref/fate/filter-removegrain-mode-13 |  2 +
>  tests/ref/fate/filter-removegrain-mode-14 |  2 +
>  tests/ref/fate/filter-removegrain-mode-15 |  2 +
>  tests/ref/fate/filter-removegrain-mode-16 |  2 +
>  tests/ref/fate/filter-removegrain-mode-17 |  2 +
>  tests/ref/fate/filter-removegrain-mode-18 |  2 +
>  tests/ref/fate/filter-removegrain-mode-19 |  2 +
>  tests/ref/fate/filter-removegrain-mode-20 |  2 +
>  tests/ref/fate/filter-removegrain-mode-21 |  2 +
>  tests/ref/fate/filter-removegrain-mode-22 |  2 +
>  tests/ref/fate/filter-removegrain-mode-23 |  2 +
>  tests/ref/fate/filter-removegrain-mode-24 |  2 +
>  26 files changed, 128 insertions(+)
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-00
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-01
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-02
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-03
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-04
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-05
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-06
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-07
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-08
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-09
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-10
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-11
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-12
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-13
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-14
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-15
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-16
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-17
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-18
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-19
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-20
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-21
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-22
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-23
>  create mode 100644 tests/ref/fate/filter-removegrain-mode-24

LGTM

thanks

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

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


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

[FFmpeg-devel] [PATCH] avfilter: add Dynamic Audio Normalizer filter

[Paul B Mahol]

From: LoRd_MuldeR 


Signed-off-by: Paul B Mahol 
---
 doc/filters.texi| 158 ++
 libavfilter/Makefile|   1 +
 libavfilter/af_dynaudnorm.c | 739 
 libavfilter/allfilters.c|   1 +
 4 files changed, 899 insertions(+)
 create mode 100644 libavfilter/af_dynaudnorm.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 3fce874..74c408a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1520,6 +1520,164 @@ Optional. It should have a value much less than 1 (e.g. 
0.05 or 0.02) and is
 used to prevent clipping.
 @end table
 
+@section dynaudnorm
+Dynamic Audio Normalizer.
+
+This filter applies a certain amount of gain to the input audion in order
+to bring its peak magnitude to a target level (e.g. 0 dBFS). However, in
+contrast to more "simple" normalization algorithms, the Dynamic Audio
+Normalizer *dynamically* re-adjusts the gain factor to the input audio.
+This allows for applying extra gain to the "quiet" sections of the audio
+while avoiding distortions or clipping the "loud" sections. In other words:
+The Dynamic Audio Normalizer will "even out" the volume of quiet and loud
+sections, in the sense that the volume of each section is brought to the
+same target level. Note, however, that the Dynamic Audio Normalizer achieves
+this goal *without* applying "dynamic range compressing". It will retain 100%
+of the dynamic range *within* each section of the audio file.
+
+@table @option
+@item f
+Set the frame length in milliseconds. In range from 10 to 8000 milliseconds.
+Default is 500 milliseconds.
+The Dynamic Audio Normalizer processes the input audio in small chunks,
+referred to as frames. This is required, because a peak magnitude has no
+meaning for just a single sample value. Instead, we need to determine the
+peak magnitude for a contiguous sequence of sample values. While a "standard"
+normalizer would simply use the peak magnitude of the complete file, the
+Dynamic Audio Normalizer determines the peak magnitude individually for each
+frame. The length of a frame is specified in milliseconds. By default, the
+Dynamic Audio Normalizer uses a frame length of 500 milliseconds, which has
+been found to give good results with most files.
+Note that the exact frame length, in number of samples, will be determined
+automatically, based on the sampling rate of the individual input audio file.
+
+@item g
+Set the Gaussian filter window size. In range from 3 to 301, must be odd
+number. Default is 31.
+Probably the most important parameter of the Dynamic Audio Normalizer is the
+@code{window size} of the Gaussian smoothing filter. The filter's window size
+is specified in frames, centered around the current frame. For the sake of
+simplicity, this must be an odd number. Consequently, the default value of 31
+takes into account the current frame, as well as the 15 preceding frames and
+the 15 subsequent frames. Using a larger window results in a stronger
+smoothing effect and thus in less gain variation, i.e. slower gain
+adaptation. Conversely, using a smaller window results in a weaker smoothing
+effect and thus in more gain variation, i.e. faster gain adaptation.
+In other words, the more you increase this value, the more the Dynamic Audio
+Normalizer will behave like a "traditional" normalization filter. On the
+contrary, the more you decrease this value, the more the Dynamic Audio
+Normalizer will behave like a dynamic range compressor.
+
+@item p
+Set the target peak value. This specifies the highest permissible magnitude
+level for the normalized audio input. This filter will try to approach the
+target peak magnitude as closely as possible, but at the same time it also
+makes sure that the normalized signal will never exceed the peak magnitude.
+A frame's maximum local gain factor is imposed directly by the target peak
+magnitude. The default value is 0.95 and thus leaves a headroom of 5%*.
+It is not recommended to go above this value.
+
+@item m
+Set the maximum gain factor. In range from 1.0 to 100.0. Default is 10.0.
+The Dynamic Audio Normalizer determines the maximum possible (local) gain
+factor for each input frame, i.e. the maximum gain factor that does not
+result in clipping or distortion. The maximum gain factor is determined by
+the frame's highest magnitude sample. However, the Dynamic Audio Normalizer
+additionally bounds the frame's maximum gain factor by a predetermined
+(global) maximum gain factor. This is done in order to avoid excessive gain
+factors in "silent" or almost silent frames. By default, the maximum gain
+factor is 10.0, For most inputs the default value should be sufficient and
+it usually is not recommended to increase this value. Though, for input
+with an extremely low overall volume level, it may be necessary to allow even
+higher gain factors. Note, however, that the Dynamic Audio Normalizer does
+not simply apply a "hard" threshold (i.e. cut off values above the threshold).
+Instead

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 06:34:25PM +0300, Ivan Uskov wrote:
> Hello Michael,
> 
> Please review the attached updated patch about height alignment.
> 
> The qsvenc_hevc.c compiles now thanks.
> But same command line that I use for h264_qsv does fail for hevc_qsv
> with error "[hevc_qsv @ 0x25a7620] Unexpected NAL type in the extradata: 52"
> Here can be lot reasons including too old MXF library (I'm use 2015R4
> but latest 2015R6).
> It is just info, I will review qsvenc_hevc.c later when all known minor 
> defects of qsvenc.c will fixed.
> 
> 
> Thursday, July 9, 2015, 5:47:22 PM, you wrote:
> 
> MN> This change was merged by me and originates from libav. I tried to
> MN> merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’
> MN> ill try to fix that but i dont have a libmfx setup here ATM so
> 
> MN> If you can check and if needed correct it, that would help alot!
> 
> MN> Thanks
> 
> MN> [...]
> 
> 
> 
> -- 
> Best regards,
>  Ivanmailto:ivan.us...@nablet.com

>  qsvenc.c |   10 ++
>  qsvenc.h |1 +
>  2 files changed, 7 insertions(+), 4 deletions(-)
> f5b7a7c8b54204643242b785b20176eab2d5238a  
> 0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch
> From 1131ad41f6aedc7aa262ab70e8e320a59cd5121c Mon Sep 17 00:00:00 2001
> From: Ivan Uskov 
> Date: Thu, 9 Jul 2015 16:49:36 +0300
> Subject: [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment
>  during frame encoding  which may be reason of superflous frame copying.

applied

thanks

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: allow 12bit input formats, update warnings

[Derek Buitenhuis]

Hi,

Apologies if this comes through as HTML. I am internet-less and
using the Gmail web interface.

On Wed, Jul 8, 2015 at 11:54 PM, Steve Borho  wrote:
> The range extension profiles have been fully ratified so there
> is no reason to require -strict experimental for them. However
> Main12 support in x265 is experimental so I check for that
> instead.

[...]

> -if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL &&
> -!av_pix_fmt_desc_get(avctx->pix_fmt)->log2_chroma_w) {
> +if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL && 
> ctx->api->bit_depth == 12) {

Style nit: Add a break like it previously had.

Also, do you need an API bump in configure for this?

Rest LGTM.

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

[FFmpeg-devel] Setting the frame rate in libavcodec/libopenh264enc.c

[Gregory J Wolfe]

We have been using Cisco's libopenh264 as part of FFmpeg with good results.
However, function svc_encode_init() in libavcodec/libopenh264enc.c appears to
be setting the frame rate incorrectly.  The line of code in question looks like:

param.fMaxFrameRate = avctx->time_base.den / avctx->time_base.num;

Since fMaxFrameRate is of type float, shouldn't this be something like:

param.fMaxFrameRate = avctx->time_base.den / (double)avctx->time_base.num;

Or is there some reason why the frame rate should get truncated to an integer?

Greg Wolfe, Kodak Alaris (formerly part of Eastman Kodak)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello Michael,

Please review the attached updated patch about height alignment.

The qsvenc_hevc.c compiles now thanks.
But same command line that I use for h264_qsv does fail for hevc_qsv
with error "[hevc_qsv @ 0x25a7620] Unexpected NAL type in the extradata: 52"
Here can be lot reasons including too old MXF library (I'm use 2015R4
but latest 2015R6).
It is just info, I will review qsvenc_hevc.c later when all known minor defects 
of qsvenc.c will fixed.


Thursday, July 9, 2015, 5:47:22 PM, you wrote:

MN> This change was merged by me and originates from libav. I tried to
MN> merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’
MN> ill try to fix that but i dont have a libmfx setup here ATM so

MN> If you can check and if needed correct it, that would help alot!

MN> Thanks

MN> [...]



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

0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello Michael,

Ok, I will take care.

Thursday, July 9, 2015, 5:47:22 PM, you wrote:

MN> Its not my code nor my change, i do not know what the correct value
MN> is.
MN> This change was merged by me and originates from libav. I tried to
MN> merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’
MN> ill try to fix that but i dont have a libmfx setup here ATM so

MN> If you can check and if needed correct it, that would help alot!



-- 
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] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 05:07:38PM +0300, Ivan Uskov wrote:
> Hello Michael,
> 
> Ooops, missed that you modified the file recently. Will prepare
> another patch.
> By the way, now I can not compile master repo under --enable-libmfx config,
> there is compiler error appears:
> libavcodec/qsvenc_hevc.c:71:5: error: too few arguments to function 
> ‘ff_hevc_extract_rbsp’
> Are there some update should be soon?
> 
> Also, do you know a real reason to make
>   q->width_align = avctx->codec_id == AV_CODEC_ID_HEVC ? 32 : 16;
> into the qsvenc.c? I did not check it yet and never work with Intel
> HEVC before but all Intel's samples never perform such check, width
> alignment in latest Intel's samples is always 16...

Its not my code nor my change, i do not know what the correct value
is.
This change was merged by me and originates from libav. I tried to
merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’
ill try to fix that but i dont have a libmfx setup here ATM so

If you can check and if needed correct it, that would help alot!

Thanks

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH 9/9] doc/example: Add http multi-client example code

[Stephan Holljes]

On Thu, Jul 9, 2015 at 3:47 PM, Nicolas George  wrote:
> Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
>> Signed-off-by: Stephan Holljes 
>> ---
>>  doc/examples/Makefile   |   1 +
>>  doc/examples/http_multiclient.c | 120 
>> 
>>  2 files changed, 121 insertions(+)
>>  create mode 100644 doc/examples/http_multiclient.c
>> Changes since first version:
>>   - Move client handling code in separate function
>>   - Close filedescriptors earlier
>>
>> diff --git a/doc/examples/Makefile b/doc/examples/Makefile
>> index 9699f11..8c9501b 100644
>> --- a/doc/examples/Makefile
>> +++ b/doc/examples/Makefile
>> @@ -18,6 +18,7 @@ EXAMPLES=   avio_list_dir  \
>>  extract_mvs\
>>  filtering_video\
>>  filtering_audio\
>> +http_multiclient   \
>>  metadata   \
>>  muxing \
>>  remuxing   \
>> diff --git a/doc/examples/http_multiclient.c 
>> b/doc/examples/http_multiclient.c
>> new file mode 100644
>> index 000..a780321
>> --- /dev/null
>> +++ b/doc/examples/http_multiclient.c
>> @@ -0,0 +1,120 @@
>> +/*
>> + * copyright (c) 2015 Stephan Holljes
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +/**
>> + * @file
>> + * libavformat multi-client network API usage example.
>> + *
>> + * @example http_multiclient.c
>> + * This example will serve a file without decoding or demuxing it over http.
>> + * Multiple clients can connect and will receive the same file.
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +void process_client(AVIOContext *client, const char* in_uri)
>> +{
>
>> +AVIOContext *input =NULL;
>
> Nit: space.
>
>> +uint8_t buf[1024];
>> +int ret, n;
>
>> +avio_handshake(client);
>
> Check for error.
>
>> +fprintf(stderr, "Handshake performed.\n");
>> +fprintf(stderr, "Opening input file.\n");
>
>> +if ((ret = avio_open2(&input, in_uri, AVIO_FLAG_READ, NULL, NULL)) < 0) 
>> {
>> +av_log(input, AV_LOG_ERROR, "Failed to open input: %s\n", in_uri);
>> +return;
>> +}
>
> I just realized this: how would you go about returning 404 to the client
> here?

Good question, I haven't thought about that myself. Adding a 404 error
to handle_http_errors() and calling it with AVERROR_HTTP_NOT_FOUND
could be a solution. I feel like the name "handle_http_errors" is not
well chosen then, though.

>
>> +for(;;) {
>> +n = avio_read(input, buf, sizeof(buf));
>> +if (n < 0) {
>> +if (n == AVERROR_EOF)
>> +break;
>> +av_log(input, AV_LOG_ERROR, "Error reading from input: %s.\n",
>> +   av_err2str(n));
>> +ret = n;
>> +break;
>> +}
>> +avio_write(client, buf, n);
>> +avio_flush(client);
>> +}
>> +fprintf(stderr, "Flushing client\n");
>> +avio_flush(client);
>> +fprintf(stderr, "Closing client\n");
>> +avio_close(client);
>> +fprintf(stderr, "Closing input\n");
>> +avio_close(input);
>> +}
>> +
>> +int main(int argc, char **argv)
>> +{
>> +AVDictionary *options = NULL;
>> +AVIOContext *client = NULL, *server = NULL;
>> +const char *in_uri, *out_uri;
>> +int ret, pid;
>> +if (argc < 3) {
>> +printf("usage: %s input http://hostname[:port]\n";
>> +   "API example program to serve http to multiple clients.\n"
>> +   "\n", argv[0]);
>> +return 1;
>> +}
>> +
>> +in_uri = argv[1];
>> +out_uri = argv[2];
>> +
>> +av_register_all();
>> +avformat_network_init();
>> +
>> +if ((ret = av_dict_set(&options, "listen", "2", 0)) < 0)
>> +goto end;
>> +if ((ret = avio_open2(&server, out_uri, AVIO_FLAG_READ_WRITE, NULL, 
>> &options)) < 0)
>> +goto end;
>> +fprintf(stderr, "Entering main loop.\n");
>> +for(;;) {
>> +if ((ret = avio_accept(server, &client)) < 0)
>> +goto end;
>> +fpr

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello Michael,

Ooops, missed that you modified the file recently. Will prepare
another patch.
By the way, now I can not compile master repo under --enable-libmfx config,
there is compiler error appears:
libavcodec/qsvenc_hevc.c:71:5: error: too few arguments to function 
‘ff_hevc_extract_rbsp’
Are there some update should be soon?

Also, do you know a real reason to make
  q->width_align = avctx->codec_id == AV_CODEC_ID_HEVC ? 32 : 16;
into the qsvenc.c? I did not check it yet and never work with Intel
HEVC before but all Intel's samples never perform such check, width
alignment in latest Intel's samples is always 16...


Thursday, July 9, 2015, 3:18:58 PM, you wrote:

MN> On Thu, Jul 09, 2015 at 02:24:43PM +0300, Ivan Uskov wrote:
>> Hello All,
>> 
>> There is another place into libavcodec/qsvenc.c where height may be
>> aligned to 32 for the case when alignment to 16 is enough. It can be
>> reason of superfluous frame copying. The attached patch does solve
>> this issue. Please review.

MN> does not apply cleanly

MN> Applying: libavcodec/qsvenc.c: Fix for too agressive height
MN> alignment during frame encoding which may be reason of superflous frame 
copying.
MN> Using index info to reconstruct a base tree...
MN> Falling back to patching base and 3-way merge...
MN> Auto-merging libavcodec/qsvenc.h
MN> Auto-merging libavcodec/qsvenc.c
MN> CONFLICT (content): Merge conflict in libavcodec/qsvenc.c
MN> Failed to merge in the changes.
MN> Patch failed at 0001 libavcodec/qsvenc.c: Fix for too agressive
MN> height alignment during frame encoding which may be reason of superflous 
frame copying.

MN> [...]




-- 
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] [PATCH 7/9] lavf/http: increase range for listen, handle connection closing accordingly, add http_handshake and move handshake logic there

[Stephan Holljes]

On Thu, Jul 9, 2015 at 3:42 PM, Nicolas George  wrote:
> Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
>> Signed-off-by: Stephan Holljes 
>> ---
>>  libavformat/http.c | 39 ---
>>  1 file changed, 28 insertions(+), 11 deletions(-)
>> Changes since first version:
>>   - Return from http_handshake() if no errors occured instead of falling 
>> through
>> fail label
>>   - Add av_assert0() check for error in handle_http_errors()
>>   - Remove passthough if error == 0 (should never happen anymore)
>
> Is it possible to use tcp_accept() without tcp_handshake()? If not, you
> probably should merge patches 6 and 7.

I'm assuming you meant http_accept() and http_handshake(). On the API
level it should be possible to use them separately, for an application
it would probably not make much sense to use only http_accept()
without http_handshake(). I will merge the patches.

>
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index 3c1ec35..813870e 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -129,7 +129,7 @@ static const AVOption options[] = {
>>  { "end_offset", "try to limit the request to bytes preceding this 
>> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
>>  { "method", "Override the HTTP method or set the expected HTTP method 
>> from a client", OFFSET(method), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D 
>> | E },
>>  { "reconnect", "auto reconnect after disconnect before EOF", 
>> OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
>> -{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 
>> 0 }, 0, 1, D | E },
>> +{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 
>> 0 }, 0, 2, D | E },
>>  { NULL }
>>  };
>>
>> @@ -305,6 +305,7 @@ static void handle_http_errors(URLContext *h, int error)
>>  static const char bad_request[] = "HTTP/1.1 400 Bad 
>> Request\r\nContent-Type: text/plain\r\n\r\n400 Bad Request\r\n";
>>  static const char internal_server_error[] = "HTTP/1.1 500 Internal 
>> server error\r\nContent-Type: text/plain\r\n\r\n500 Internal server 
>> error\r\n";
>>  HTTPContext *s = h->priv_data;
>> +av_assert0(error < 0);
>>  if (h->is_connected) {
>>  switch(error) {
>>  case AVERROR_HTTP_BAD_REQUEST:
>> @@ -317,15 +318,33 @@ static void handle_http_errors(URLContext *h, int 
>> error)
>>  }
>>  }
>>
>
>> +static int http_handshake(URLContext *c) {
>
> Nit: inconsistent brace placement.

Fixed locally, will be updated in next patch series.

>
>> +int ret, err, new_location;
>> +HTTPContext *ch = c->priv_data;
>> +URLContext *cl = ch->hd;
>> +static const char header[] = "HTTP/1.1 200 OK\r\nContent-Type: 
>> application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n";
>> +if ((ret = ffurl_handshake(cl)) < 0)
>> +return ret;
>> +if ((err = http_read_header(c, &new_location)) < 0)
>> +goto fail;
>> +if ((ret = ffurl_write(cl, header, strlen(header))) < 0)
>> +return ret;
>> +// Avoid returning a positive value from ffurl_write()
>> +ret = ret > 0 ? 0 : ret;
>> +return ret;
>> +fail:
>> +handle_http_errors(c, err);
>> +return ret;
>> +}
>> +
>>  static int http_listen(URLContext *h, const char *uri, int flags,
>> AVDictionary **options) {
>>  HTTPContext *s = h->priv_data;
>>  int ret;
>> -static const char header[] = "HTTP/1.1 200 OK\r\nContent-Type: 
>> application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n";
>>  char hostname[1024], proto[10];
>>  char lower_url[100];
>>  const char *lower_proto = "tcp";
>> -int port, new_location;
>> +int port;
>>  s->chunked_post = 1;
>>  av_url_split(proto, sizeof(proto), NULL, 0, hostname, sizeof(hostname), 
>> &port,
>>   NULL, 0, uri);
>> @@ -333,18 +352,14 @@ static int http_listen(URLContext *h, const char *uri, 
>> int flags,
>>  lower_proto = "tls";
>>  ff_url_join(lower_url, sizeof(lower_url), lower_proto, NULL, hostname, 
>> port,
>>  NULL);
>> -av_dict_set(options, "listen", "1", 0);
>> +if ((ret = av_dict_set_int(options, "listen", s->listen, 0)) < 0)
>> +goto fail;
>>  if ((ret = ffurl_open(&s->hd, lower_url, AVIO_FLAG_READ_WRITE,
>>&h->interrupt_callback, options)) < 0)
>>  goto fail;
>> -if ((ret = http_read_header(h, &new_location)) < 0)
>> - goto fail;
>> -if ((ret = ffurl_write(s->hd, header, strlen(header))) < 0)
>> - goto fail;
>> -return 0;
>> -
>> +if (s->listen == 1) /* single client */
>> +ret = http_handshake(h);
>>  fail:
>> -handle_http_errors(h, ret);
>>  av_dict_free(&s->chained_options);
>>  return ret;
>>  }
>> @@ -1365,6 +1380,8 @@ HTTP_CLASS(http);
>>  URLProtocol ff_http_protocol = {

Re: [FFmpeg-devel] [PATCH 6/9] lavf/http: add http_accept

[Stephan Holljes]

On Thu, Jul 9, 2015 at 3:41 PM, Nicolas George  wrote:
> Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
>> Signed-off-by: Stephan Holljes 
>> ---
>>  libavformat/http.c | 19 +++
>>  1 file changed, 19 insertions(+)
>
>> Changes since first version:
>>   - Add av_assert0() check for sc->listen
>>   - Add bitmask for s->flags in ffurl_alloc
>
> Thanks.
>
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index 676bfd5..3c1ec35 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -25,6 +25,7 @@
>>  #include 
>>  #endif /* CONFIG_ZLIB */
>>
>> +#include "libavutil/avassert.h"
>>  #include "libavutil/avstring.h"
>>  #include "libavutil/opt.h"
>>
>> @@ -382,6 +383,24 @@ static int http_open(URLContext *h, const char *uri, 
>> int flags,
>>  return ret;
>>  }
>>
>> +static int http_accept(URLContext *s, URLContext **c)
>> +{
>> +int ret;
>> +HTTPContext *sc = s->priv_data;
>> +HTTPContext *cc;
>> +URLContext *sl = sc->hd;
>> +URLContext *cl;
>> +av_assert0(sc->listen);
>
>> +if ((ret = ffurl_alloc(c, s->filename, s->flags & AVIO_FLAG_READ_WRITE, 
>> &sl->interrupt_callback)) < 0)
>> +goto fail;
>
> Same remark as in my previous mail.
>
>> +cc = (*c)->priv_data;
>> +if ((ret = ffurl_accept(sl, &cl)) < 0)
>> +goto fail;
>
>> +cc->hd = cl;
>
> Does it make sense to set "cc->listen = 1" here, to indicate that the client
> is not yet a normal client? It may make the tests for trailers simpler.

I am not sure about the implications. So far setting listen has been
exclusive to server contexts. I'll will give it some thoughts and do
some testing.

>
>> +fail:
>> +return ret;
>> +}
>> +
>>  static int http_getc(HTTPContext *s)
>>  {
>>  int len;
>
> 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] [PATCH 4/9] lavf/tcp: add tcp_accept

[Stephan Holljes]

On Thu, Jul 9, 2015 at 3:31 PM, Nicolas George  wrote:
> Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
>> Signed-off-by: Stephan Holljes 
>> ---
>>  libavformat/tcp.c | 18 ++
>>  1 file changed, 18 insertions(+)
>> Changes since first version:
>>   - Add av_assert0() check for sc->listen
>>   - Add bitmask for s->flags in ffurl_alloc
>>   - Use ff_accept() instead of accept()
>>
>>
>> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
>> index f24cad2..6f5e175 100644
>> --- a/libavformat/tcp.c
>> +++ b/libavformat/tcp.c
>> @@ -19,6 +19,7 @@
>>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>>   */
>>  #include "avformat.h"
>> +#include "libavutil/avassert.h"
>>  #include "libavutil/parseutils.h"
>>  #include "libavutil/opt.h"
>>  #include "libavutil/time.h"
>> @@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int 
>> flags)
>>  return ret;
>>  }
>>
>> +static int tcp_accept(URLContext *s, URLContext **c)
>> +{
>> +TCPContext *sc = s->priv_data;
>> +TCPContext *cc;
>> +int ret;
>> +av_assert0(sc->listen);
>
>> +if ((ret = ffurl_alloc(c, s->filename, s->flags & AVIO_FLAG_READ_WRITE, 
>> &s->interrupt_callback)) < 0)
>> +return ret;
>
> Any reason to remove the other flags? Since it is not possible to add flags
> on a context afterwards, setting the flags on the server to have them on the
> clients is the most obvious solution. AVIO_FLAG_NONBLOCK does not work, but
> AVIO_FLAG_DIRECT does and makes sense for network protocols.
>

No reason at all, I wasn't aware of that. What other flags should be
kept? Since you suggested filtering s->flags I'm assuming not all
flags from s should be kept?
Should the same filtering then be applied in http_accept() too?

>> +cc = (*c)->priv_data;
>> +ret = ff_accept(sc->fd, sc->listen_timeout, s);
>> +if (ret < 0)
>> +return ff_neterrno();
>> +cc->fd = ret;
>> +return 0;
>> +}
>> +
>>  static int tcp_read(URLContext *h, uint8_t *buf, int size)
>>  {
>>  TCPContext *s = h->priv_data;
>> @@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
>>  URLProtocol ff_tcp_protocol = {
>>  .name= "tcp",
>>  .url_open= tcp_open,
>> +.url_accept  = tcp_accept,
>>  .url_read= tcp_read,
>>  .url_write   = tcp_write,
>>  .url_close   = tcp_close,
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH 4/4] concatdec: add support for injecting packet metadata

[Nicolas George]

Le decadi 20 messidor, an CCXXIII, Marton Balint a écrit :
> I'd still use the metadata directive. If someone needs per-stream, or
> per-packet metadata, he can implement selector directives for that. Like
> metadata_stream or metadata_interval which will change the scope of the
> following metadata directives.
> 
> How about that?

I am still uneasy about that. Selectors feel like making the parser more
complex, and also there is the issue of self-documentation.

When someone reads a concat script and see "metadata foo=bar", unless they
already know exactly the directive, they will take a guess at what it does,
and since packet metadata is rare, especially packet metadata that is
duplicated over all the packets, they will probably not guess right.

I really think a more specific name would be useful.

This is an usability issue, though, so my role as maintainer is not very
important: let us ear advice from other people.

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 3/4] concatdec: add support for specifying outpoint of files

[Nicolas George]

Le primidi 21 messidor, an CCXXIII, Marton Balint a écrit :
> I gave it a thought, and if we ensure that the decoding timestamp reaches
> outpoint instead of the presentation timestamp, can't we overcome the
> B-frame issue? It's a simple change and seems to do the right thing.

I am not sure if it fixes all the issues (likely, with B-frames some issues
just can not be solved at the muxer level), but I believe that in muxer,
using DTS is almost always better than using PTS, so that should be good.

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 9/9] doc/example: Add http multi-client example code

[Nicolas George]

Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
> Signed-off-by: Stephan Holljes 
> ---
>  doc/examples/Makefile   |   1 +
>  doc/examples/http_multiclient.c | 120 
> 
>  2 files changed, 121 insertions(+)
>  create mode 100644 doc/examples/http_multiclient.c
> Changes since first version:
>   - Move client handling code in separate function
>   - Close filedescriptors earlier
> 
> diff --git a/doc/examples/Makefile b/doc/examples/Makefile
> index 9699f11..8c9501b 100644
> --- a/doc/examples/Makefile
> +++ b/doc/examples/Makefile
> @@ -18,6 +18,7 @@ EXAMPLES=   avio_list_dir  \
>  extract_mvs\
>  filtering_video\
>  filtering_audio\
> +http_multiclient   \
>  metadata   \
>  muxing \
>  remuxing   \
> diff --git a/doc/examples/http_multiclient.c b/doc/examples/http_multiclient.c
> new file mode 100644
> index 000..a780321
> --- /dev/null
> +++ b/doc/examples/http_multiclient.c
> @@ -0,0 +1,120 @@
> +/*
> + * copyright (c) 2015 Stephan Holljes
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * libavformat multi-client network API usage example.
> + *
> + * @example http_multiclient.c
> + * This example will serve a file without decoding or demuxing it over http.
> + * Multiple clients can connect and will receive the same file.
> + */
> +
> +#include 
> +#include 
> +
> +void process_client(AVIOContext *client, const char* in_uri)
> +{

> +AVIOContext *input =NULL;

Nit: space.

> +uint8_t buf[1024];
> +int ret, n;

> +avio_handshake(client);

Check for error.

> +fprintf(stderr, "Handshake performed.\n");
> +fprintf(stderr, "Opening input file.\n");

> +if ((ret = avio_open2(&input, in_uri, AVIO_FLAG_READ, NULL, NULL)) < 0) {
> +av_log(input, AV_LOG_ERROR, "Failed to open input: %s\n", in_uri);
> +return;
> +}

I just realized this: how would you go about returning 404 to the client
here?

> +for(;;) {
> +n = avio_read(input, buf, sizeof(buf));
> +if (n < 0) {
> +if (n == AVERROR_EOF)
> +break;
> +av_log(input, AV_LOG_ERROR, "Error reading from input: %s.\n",
> +   av_err2str(n));
> +ret = n;
> +break;
> +}
> +avio_write(client, buf, n);
> +avio_flush(client);
> +}
> +fprintf(stderr, "Flushing client\n");
> +avio_flush(client);
> +fprintf(stderr, "Closing client\n");
> +avio_close(client);
> +fprintf(stderr, "Closing input\n");
> +avio_close(input);
> +}
> +
> +int main(int argc, char **argv)
> +{
> +AVDictionary *options = NULL;
> +AVIOContext *client = NULL, *server = NULL;
> +const char *in_uri, *out_uri;
> +int ret, pid;
> +if (argc < 3) {
> +printf("usage: %s input http://hostname[:port]\n";
> +   "API example program to serve http to multiple clients.\n"
> +   "\n", argv[0]);
> +return 1;
> +}
> +
> +in_uri = argv[1];
> +out_uri = argv[2];
> +
> +av_register_all();
> +avformat_network_init();
> +
> +if ((ret = av_dict_set(&options, "listen", "2", 0)) < 0)
> +goto end;
> +if ((ret = avio_open2(&server, out_uri, AVIO_FLAG_READ_WRITE, NULL, 
> &options)) < 0)
> +goto end;
> +fprintf(stderr, "Entering main loop.\n");
> +for(;;) {
> +if ((ret = avio_accept(server, &client)) < 0)
> +goto end;
> +fprintf(stderr, "Accepted client, forking process.\n");
> +// XXX: Since we don't reap our children and don't ignore signals
> +//  this produces zombie processes.
> +pid = fork();
> +if (pid < 0) {

> +fprintf(stderr, "Fork failed.\n");

perror()

> +ret = AVERROR(errno);
> +goto end;
> +}
> +if (pid == 0) {
> +fprintf(stderr, "In child.\n")

Re: [FFmpeg-devel] [PATCH 7/9] lavf/http: increase range for listen, handle connection closing accordingly, add http_handshake and move handshake logic there

[Nicolas George]

Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
> Signed-off-by: Stephan Holljes 
> ---
>  libavformat/http.c | 39 ---
>  1 file changed, 28 insertions(+), 11 deletions(-)
> Changes since first version:
>   - Return from http_handshake() if no errors occured instead of falling 
> through
> fail label
>   - Add av_assert0() check for error in handle_http_errors()
>   - Remove passthough if error == 0 (should never happen anymore)

Is it possible to use tcp_accept() without tcp_handshake()? If not, you
probably should merge patches 6 and 7.

> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 3c1ec35..813870e 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -129,7 +129,7 @@ static const AVOption options[] = {
>  { "end_offset", "try to limit the request to bytes preceding this 
> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
>  { "method", "Override the HTTP method or set the expected HTTP method 
> from a client", OFFSET(method), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D 
> | E },
>  { "reconnect", "auto reconnect after disconnect before EOF", 
> OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
> -{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 
> 0 }, 0, 1, D | E },
> +{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 
> 0 }, 0, 2, D | E },
>  { NULL }
>  };
>  
> @@ -305,6 +305,7 @@ static void handle_http_errors(URLContext *h, int error)
>  static const char bad_request[] = "HTTP/1.1 400 Bad 
> Request\r\nContent-Type: text/plain\r\n\r\n400 Bad Request\r\n";
>  static const char internal_server_error[] = "HTTP/1.1 500 Internal 
> server error\r\nContent-Type: text/plain\r\n\r\n500 Internal server 
> error\r\n";
>  HTTPContext *s = h->priv_data;
> +av_assert0(error < 0);
>  if (h->is_connected) {
>  switch(error) {
>  case AVERROR_HTTP_BAD_REQUEST:
> @@ -317,15 +318,33 @@ static void handle_http_errors(URLContext *h, int error)
>  }
>  }
>  

> +static int http_handshake(URLContext *c) {

Nit: inconsistent brace placement.

> +int ret, err, new_location;
> +HTTPContext *ch = c->priv_data;
> +URLContext *cl = ch->hd;
> +static const char header[] = "HTTP/1.1 200 OK\r\nContent-Type: 
> application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n";
> +if ((ret = ffurl_handshake(cl)) < 0)
> +return ret;
> +if ((err = http_read_header(c, &new_location)) < 0)
> +goto fail;
> +if ((ret = ffurl_write(cl, header, strlen(header))) < 0)
> +return ret;
> +// Avoid returning a positive value from ffurl_write()
> +ret = ret > 0 ? 0 : ret;
> +return ret;
> +fail:
> +handle_http_errors(c, err);
> +return ret;
> +}
> +
>  static int http_listen(URLContext *h, const char *uri, int flags,
> AVDictionary **options) {
>  HTTPContext *s = h->priv_data;
>  int ret;
> -static const char header[] = "HTTP/1.1 200 OK\r\nContent-Type: 
> application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n";
>  char hostname[1024], proto[10];
>  char lower_url[100];
>  const char *lower_proto = "tcp";
> -int port, new_location;
> +int port;
>  s->chunked_post = 1;
>  av_url_split(proto, sizeof(proto), NULL, 0, hostname, sizeof(hostname), 
> &port,
>   NULL, 0, uri);
> @@ -333,18 +352,14 @@ static int http_listen(URLContext *h, const char *uri, 
> int flags,
>  lower_proto = "tls";
>  ff_url_join(lower_url, sizeof(lower_url), lower_proto, NULL, hostname, 
> port,
>  NULL);
> -av_dict_set(options, "listen", "1", 0);
> +if ((ret = av_dict_set_int(options, "listen", s->listen, 0)) < 0)
> +goto fail;
>  if ((ret = ffurl_open(&s->hd, lower_url, AVIO_FLAG_READ_WRITE,
>&h->interrupt_callback, options)) < 0)
>  goto fail;
> -if ((ret = http_read_header(h, &new_location)) < 0)
> - goto fail;
> -if ((ret = ffurl_write(s->hd, header, strlen(header))) < 0)
> - goto fail;
> -return 0;
> -
> +if (s->listen == 1) /* single client */
> +ret = http_handshake(h);
>  fail:
> -handle_http_errors(h, ret);
>  av_dict_free(&s->chained_options);
>  return ret;
>  }
> @@ -1365,6 +1380,8 @@ HTTP_CLASS(http);
>  URLProtocol ff_http_protocol = {
>  .name= "http",
>  .url_open2   = http_open,
> +.url_accept  = http_accept,
> +.url_handshake   = http_handshake,
>  .url_read= http_read,
>  .url_write   = http_write,
>  .url_seek= http_seek,

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 6/9] lavf/http: add http_accept

[Nicolas George]

Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
> Signed-off-by: Stephan Holljes 
> ---
>  libavformat/http.c | 19 +++
>  1 file changed, 19 insertions(+)

> Changes since first version:
>   - Add av_assert0() check for sc->listen
>   - Add bitmask for s->flags in ffurl_alloc

Thanks.

> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 676bfd5..3c1ec35 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -25,6 +25,7 @@
>  #include 
>  #endif /* CONFIG_ZLIB */
>  
> +#include "libavutil/avassert.h"
>  #include "libavutil/avstring.h"
>  #include "libavutil/opt.h"
>  
> @@ -382,6 +383,24 @@ static int http_open(URLContext *h, const char *uri, int 
> flags,
>  return ret;
>  }
>  
> +static int http_accept(URLContext *s, URLContext **c)
> +{
> +int ret;
> +HTTPContext *sc = s->priv_data;
> +HTTPContext *cc;
> +URLContext *sl = sc->hd;
> +URLContext *cl;
> +av_assert0(sc->listen);

> +if ((ret = ffurl_alloc(c, s->filename, s->flags & AVIO_FLAG_READ_WRITE, 
> &sl->interrupt_callback)) < 0)
> +goto fail;

Same remark as in my previous mail.

> +cc = (*c)->priv_data;
> +if ((ret = ffurl_accept(sl, &cl)) < 0)
> +goto fail;

> +cc->hd = cl;

Does it make sense to set "cc->listen = 1" here, to indicate that the client
is not yet a normal client? It may make the tests for trailers simpler.

> +fail:
> +return ret;
> +}
> +
>  static int http_getc(HTTPContext *s)
>  {
>  int len;

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]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 01:23:58PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> RFC 2435 requires standard Huffman tables when sending (m)jpeg over rtp.
> Related to ticket #3823.
> 
> Please comment, Carl Eugen

>  rtpenc_jpeg.c |   21 +
>  1 file changed, 21 insertions(+)
> f72f54ec4c4d9fb7f8e61dbb4ce48cd5a492c05e  patchrtpjpghuffman.diff
> diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
> index 7ee26c4..e9d09e9 100644
> --- a/libavformat/rtpenc_jpeg.c
> +++ b/libavformat/rtpenc_jpeg.c
> @@ -21,6 +21,7 @@
>  
>  #include "libavcodec/bytestream.h"
>  #include "libavcodec/mjpeg.h"
> +#include "libavcodec/jpegtables.h"
>  #include "libavutil/intreadwrite.h"
>  #include "rtpenc.h"
>  
> @@ -81,6 +82,26 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
> *buf, int size)
> "Only 1x1 chroma blocks are supported. Aborted!\n");
[...]
> +   "Only standard Huffman tables are supported\n");

I think the error messages should be changed to say that RFC... doesnt
allow stuff not that its not supported implying it could be supported

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH 4/9] lavf/tcp: add tcp_accept

[Nicolas George]

Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
> Signed-off-by: Stephan Holljes 
> ---
>  libavformat/tcp.c | 18 ++
>  1 file changed, 18 insertions(+)
> Changes since first version:
>   - Add av_assert0() check for sc->listen
>   - Add bitmask for s->flags in ffurl_alloc
>   - Use ff_accept() instead of accept()
> 
> 
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index f24cad2..6f5e175 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -19,6 +19,7 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  #include "avformat.h"
> +#include "libavutil/avassert.h"
>  #include "libavutil/parseutils.h"
>  #include "libavutil/opt.h"
>  #include "libavutil/time.h"
> @@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int 
> flags)
>  return ret;
>  }
>  
> +static int tcp_accept(URLContext *s, URLContext **c)
> +{
> +TCPContext *sc = s->priv_data;
> +TCPContext *cc;
> +int ret;
> +av_assert0(sc->listen);

> +if ((ret = ffurl_alloc(c, s->filename, s->flags & AVIO_FLAG_READ_WRITE, 
> &s->interrupt_callback)) < 0)
> +return ret;

Any reason to remove the other flags? Since it is not possible to add flags
on a context afterwards, setting the flags on the server to have them on the
clients is the most obvious solution. AVIO_FLAG_NONBLOCK does not work, but
AVIO_FLAG_DIRECT does and makes sense for network protocols.

> +cc = (*c)->priv_data;
> +ret = ff_accept(sc->fd, sc->listen_timeout, s);
> +if (ret < 0)
> +return ff_neterrno();
> +cc->fd = ret;
> +return 0;
> +}
> +
>  static int tcp_read(URLContext *h, uint8_t *buf, int size)
>  {
>  TCPContext *s = h->priv_data;
> @@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
>  URLProtocol ff_tcp_protocol = {
>  .name= "tcp",
>  .url_open= tcp_open,
> +.url_accept  = tcp_accept,
>  .url_read= tcp_read,
>  .url_write   = tcp_write,
>  .url_close   = tcp_close,

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 04/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [4/4]

[Michael Niedermayer]

On Tue, Jun 30, 2015 at 11:53:06AM +0200, Nedeljko Babic wrote:
> From: Jovan Zelincevic 
> 
> Build system modified
> 
> There are several warnings occurring during build after this patch is
> applied. The cause of most of these warnings is in that some definitions
> needed here are logical part of sbr module and are added in later patches.
> When this patches are applied these warnings stop occurring.
> 
> The only warning that is added here and is not fixed with later patches
> is warning that warns that type mismatch for table ff_aac_eld_window_480.
> 
> The reason for this warning is in that ER AAC ELD 480 is not integrated in
> to the fixed point implementation at this moment and there is no fixed point
> version of this table.
> 
> Signed-off-by: Nedeljko Babic 
> ---
>  configure |  1 +
>  libavcodec/Makefile   | 13 ++---
>  libavcodec/aacdec.c   |  1 -
>  libavcodec/aacdec_fixed.c |  1 -
>  libavcodec/allcodecs.c|  1 +
>  5 files changed, 12 insertions(+), 5 deletions(-)

applied

thanks

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

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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

Re: [FFmpeg-devel] [PATCH 03/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [3/4]

[Michael Niedermayer]

On Tue, Jun 30, 2015 at 11:53:05AM +0200, Nedeljko Babic wrote:
> From: Djordje Pesut 
> 
> Add fixed point implementation
> 
> Signed-off-by: Nedeljko Babic 
> ---
>  libavcodec/aac.h |  80 ++--
>  libavcodec/aacdec.c  |   5 +
>  libavcodec/aacdec_fixed.c| 444 
> +++
>  libavcodec/aacdec_template.c | 421 
>  libavcodec/mdct_template.c   |   5 +
>  5 files changed, 809 insertions(+), 146 deletions(-)
>  create mode 100644 libavcodec/aacdec_fixed.c

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH 02/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/4]

[Michael Niedermayer]

On Tue, Jun 30, 2015 at 11:53:04AM +0200, Nedeljko Babic wrote:
> From: Jovan Zelincevic 
> 
> Add fixed point implementation of functions for generating tables
> 
> Signed-off-by: Nedeljko Babic 
> ---
>  libavcodec/aac.h   |  23 +
>  libavcodec/aacdectab.h |  34 +-
>  libavcodec/aactab.c| 486 
> +
>  libavcodec/aactab.h|   4 +
>  .../{cbrt_tablegen.c => cbrt_fixed_tablegen.c} |   3 +
>  libavcodec/cbrt_tablegen.c |   3 +
>  libavcodec/cbrt_tablegen.h |  17 +-
>  libavcodec/cbrt_tablegen_template.c|   2 +-
>  libavcodec/sinewin.c   |   1 +
>  libavcodec/sinewin.h   |  20 +-
>  libavcodec/{sinewin.c => sinewin_fixed.c}  |   1 +
>  ...sinewin_tablegen.c => sinewin_fixed_tablegen.c} |   3 +
>  libavcodec/sinewin_tablegen.c  |   3 +
>  libavcodec/sinewin_tablegen.h  |  31 +-
>  libavcodec/sinewin_tablegen_template.c |  20 +-
>  libavcodec/tableprint.h|   2 +
>  16 files changed, 618 insertions(+), 35 deletions(-)
>  copy libavcodec/{cbrt_tablegen.c => cbrt_fixed_tablegen.c} (94%)
>  copy libavcodec/{sinewin.c => sinewin_fixed.c} (97%)
>  copy libavcodec/{sinewin_tablegen.c => sinewin_fixed_tablegen.c} (93%)

applied

thanks

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH 01/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [1/4]

[Michael Niedermayer]

On Tue, Jun 30, 2015 at 11:53:03AM +0200, Nedeljko Babic wrote:
> From: Jovan Zelincevic 
> 
> Move existing code to the new template files
> 
> Signed-off-by: Nedeljko Babic 
> ---
>  libavcodec/aacdec.c| 3132 
> +---
>  libavcodec/{aacdec.c => aacdec_template.c} |  623 +---
>  libavcodec/cbrt_tablegen.c |   16 -
>  .../{cbrt_tablegen.c => cbrt_tablegen_template.c}  |0
>  libavcodec/sinewin_tablegen.c  |   25 -
>  ...ewin_tablegen.c => sinewin_tablegen_template.c} |0
>  6 files changed, 97 insertions(+), 3699 deletions(-)
>  copy libavcodec/{aacdec.c => aacdec_template.c} (85%)
>  copy libavcodec/{cbrt_tablegen.c => cbrt_tablegen_template.c} (100%)
>  copy libavcodec/{sinewin_tablegen.c => sinewin_tablegen_template.c} (100%)

applied

btw, the diff would have had ~40% fewer added lines shown if done by
using git ... --patience
might make sense to use in the future

thanks

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

[FFmpeg-devel] [PATCH 4/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 intra functions

[shivraj.patil]

From: Shivraj Patil 

This patch adds MSA (MIPS-SIMD-Arch) optimizations for VP9 intra functions in 
new file vp9_intra_msa.c

Signed-off-by: Shivraj Patil 
---
 libavcodec/mips/Makefile   |   3 +-
 libavcodec/mips/vp9_intra_msa.c| 880 +
 libavcodec/mips/vp9dsp_init_mips.c |  23 +
 libavcodec/mips/vp9dsp_mips.h  |  73 +++
 4 files changed, 978 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/mips/vp9_intra_msa.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 7dca55d..b71d2c4 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -44,7 +44,8 @@ MSA-OBJS-$(CONFIG_HEVC_DECODER)   += 
mips/hevcdsp_msa.o\
  mips/hevcpred_msa.o
 MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o \
  mips/vp9_lpf_msa.o\
- mips/vp9_idct_msa.o
+ mips/vp9_idct_msa.o   \
+ mips/vp9_intra_msa.o
 MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o\
  mips/h264idct_msa.o
 MSA-OBJS-$(CONFIG_H264QPEL)   += mips/h264qpel_msa.o
diff --git a/libavcodec/mips/vp9_intra_msa.c b/libavcodec/mips/vp9_intra_msa.c
new file mode 100644
index 000..e29e727
--- /dev/null
+++ b/libavcodec/mips/vp9_intra_msa.c
@@ -0,0 +1,880 @@
+/*
+ * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *
+ * 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 "libavcodec/vp9dsp.h"
+#include "libavutil/mips/generic_macros_msa.h"
+#include "vp9dsp_mips.h"
+
+#define IPRED_SUBS_UH2_UH(in0, in1, out0, out1)  \
+{\
+out0 = __msa_subs_u_h(out0, in0);\
+out1 = __msa_subs_u_h(out1, in1);\
+}
+
+static void intra_predict_vert_4x4_msa(const uint8_t *src, uint8_t *dst,
+   int32_t dst_stride)
+{
+uint32_t src_data;
+
+src_data = LW(src);
+
+SW4(src_data, src_data, src_data, src_data, dst, dst_stride);
+}
+
+static void intra_predict_vert_8x8_msa(const uint8_t *src, uint8_t *dst,
+   int32_t dst_stride)
+{
+uint32_t row;
+uint32_t src_data1, src_data2;
+
+src_data1 = LW(src);
+src_data2 = LW(src + 4);
+
+for (row = 8; row--;) {
+SW(src_data1, dst);
+SW(src_data2, (dst + 4));
+dst += dst_stride;
+}
+}
+
+static void intra_predict_vert_16x16_msa(const uint8_t *src, uint8_t *dst,
+ int32_t dst_stride)
+{
+uint32_t row;
+v16u8 src0;
+
+src0 = LD_UB(src);
+
+for (row = 16; row--;) {
+ST_UB(src0, dst);
+dst += dst_stride;
+}
+}
+
+static void intra_predict_vert_32x32_msa(const uint8_t *src, uint8_t *dst,
+ int32_t dst_stride)
+{
+uint32_t row;
+v16u8 src1, src2;
+
+src1 = LD_UB(src);
+src2 = LD_UB(src + 16);
+
+for (row = 32; row--;) {
+ST_UB2(src1, src2, dst, 16);
+dst += dst_stride;
+}
+}
+
+static void intra_predict_horiz_4x4_msa(const uint8_t *src, int32_t src_stride,
+uint8_t *dst, int32_t dst_stride)
+{
+uint32_t out0, out1, out2, out3;
+
+out0 = src[0 * src_stride] * 0x01010101;
+out1 = src[1 * src_stride] * 0x01010101;
+out2 = src[2 * src_stride] * 0x01010101;
+out3 = src[3 * src_stride] * 0x01010101;
+
+SW4(out0, out1, out2, out3, dst, dst_stride);
+}
+
+static void intra_predict_horiz_8x8_msa(const uint8_t *src, int32_t src_stride,
+uint8_t *dst, int32_t dst_stride)
+{
+uint64_t out0, out1, out2, out3, out4, out5, out6, out7;
+
+out0 = src[0 * src_stride] * 0x0101010101010101;
+out1 = src[1 * src_stride] * 0x0101010101010101;
+out2 = src[2 * src_stride] * 0x0101010101010101;
+out3 = src[3 * src_stride] * 0x0101010101010101;
+out4 = src[4 * src_stride] * 0x0101010101010101;
+out5 = src[5 * src_stri

[FFmpeg-devel] [PATCH 3/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 idct functions

[shivraj.patil]

From: Shivraj Patil 

This patch adds MSA (MIPS-SIMD-Arch) optimizations for VP9 idct functions in 
new file vp9_idct_msa.c

Signed-off-by: Shivraj Patil 
---
 libavcodec/mips/Makefile   |3 +-
 libavcodec/mips/vp9_idct_msa.c | 1811 
 libavcodec/mips/vp9dsp_init_mips.c |   24 +
 libavcodec/mips/vp9dsp_mips.h  |   29 +
 4 files changed, 1866 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/mips/vp9_idct_msa.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 6d55a20..7dca55d 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -43,7 +43,8 @@ MSA-OBJS-$(CONFIG_HEVC_DECODER)   += 
mips/hevcdsp_msa.o\
  mips/hevc_lpf_sao_msa.o   \
  mips/hevcpred_msa.o
 MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o \
- mips/vp9_lpf_msa.o
+ mips/vp9_lpf_msa.o\
+ mips/vp9_idct_msa.o
 MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o\
  mips/h264idct_msa.o
 MSA-OBJS-$(CONFIG_H264QPEL)   += mips/h264qpel_msa.o
diff --git a/libavcodec/mips/vp9_idct_msa.c b/libavcodec/mips/vp9_idct_msa.c
new file mode 100644
index 000..dad4b18
--- /dev/null
+++ b/libavcodec/mips/vp9_idct_msa.c
@@ -0,0 +1,1811 @@
+/*
+ * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *
+ * 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 
+#include "libavcodec/vp9dsp.h"
+#include "libavutil/mips/generic_macros_msa.h"
+#include "vp9dsp_mips.h"
+
+#define VP9_DCT_CONST_BITS   14
+
+static const int32_t cospi_1_64 = 16364;
+static const int32_t cospi_2_64 = 16305;
+static const int32_t cospi_3_64 = 16207;
+static const int32_t cospi_4_64 = 16069;
+static const int32_t cospi_5_64 = 15893;
+static const int32_t cospi_6_64 = 15679;
+static const int32_t cospi_7_64 = 15426;
+static const int32_t cospi_8_64 = 15137;
+static const int32_t cospi_9_64 = 14811;
+static const int32_t cospi_10_64 = 14449;
+static const int32_t cospi_11_64 = 14053;
+static const int32_t cospi_12_64 = 13623;
+static const int32_t cospi_13_64 = 13160;
+static const int32_t cospi_14_64 = 12665;
+static const int32_t cospi_15_64 = 12140;
+static const int32_t cospi_16_64 = 11585;
+static const int32_t cospi_17_64 = 11003;
+static const int32_t cospi_18_64 = 10394;
+static const int32_t cospi_19_64 = 9760;
+static const int32_t cospi_20_64 = 9102;
+static const int32_t cospi_21_64 = 8423;
+static const int32_t cospi_22_64 = 7723;
+static const int32_t cospi_23_64 = 7005;
+static const int32_t cospi_24_64 = 6270;
+static const int32_t cospi_25_64 = 5520;
+static const int32_t cospi_26_64 = 4756;
+static const int32_t cospi_27_64 = 3981;
+static const int32_t cospi_28_64 = 3196;
+static const int32_t cospi_29_64 = 2404;
+static const int32_t cospi_30_64 = 1606;
+static const int32_t cospi_31_64 = 804;
+
+static const int32_t sinpi_1_9 = 5283;
+static const int32_t sinpi_2_9 = 9929;
+static const int32_t sinpi_3_9 = 13377;
+static const int32_t sinpi_4_9 = 15212;
+
+#define VP9_DOTP_CONST_PAIR(reg0, reg1, cnst0, cnst1, out0, out1)  \
+{  \
+v8i16 k0_m = __msa_fill_h(cnst0);  \
+v4i32 s0_m, s1_m, s2_m, s3_m;  \
+   \
+s0_m = (v4i32) __msa_fill_h(cnst1);\
+k0_m = __msa_ilvev_h((v8i16) s0_m, k0_m);  \
+   \
+ILVRL_H2_SW((-reg1), reg0, s1_m, s0_m);\
+ILVRL_H2_SW(reg0, reg1, s3_m, s2_m);   \
+DOTP_SH2_SW(s1_m, s0_m, k0_m, k0_m, s1_m, s0_m);   \
+SRARI_W2_SW(s1_m, s0_m, VP9_DCT_CONST_BITS);   \
+out0 = __msa_pckev_h((v8i16) s0_m, (v8i16) s1_m);  \
+

[FFmpeg-devel] [PATCH 2/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 lpf functions

[shivraj.patil]

From: Shivraj Patil 

This patch adds MSA (MIPS-SIMD-Arch) optimizations for VP9 lpf functions in new 
file vp9_lpf_msa.c

Signed-off-by: Shivraj Patil 
---
 libavcodec/mips/Makefile|3 +-
 libavcodec/mips/vp9_lpf_msa.c   | 2503 +++
 libavcodec/mips/vp9dsp_init_mips.c  |   25 +
 libavcodec/mips/vp9dsp_mips.h   |   33 +
 libavutil/mips/generic_macros_msa.h |3 +
 5 files changed, 2566 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/mips/vp9_lpf_msa.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 0728d42..6d55a20 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -42,7 +42,8 @@ MSA-OBJS-$(CONFIG_HEVC_DECODER)   += 
mips/hevcdsp_msa.o\
  mips/hevc_idct_msa.o  \
  mips/hevc_lpf_sao_msa.o   \
  mips/hevcpred_msa.o
-MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o
+MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o \
+ mips/vp9_lpf_msa.o
 MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o\
  mips/h264idct_msa.o
 MSA-OBJS-$(CONFIG_H264QPEL)   += mips/h264qpel_msa.o
diff --git a/libavcodec/mips/vp9_lpf_msa.c b/libavcodec/mips/vp9_lpf_msa.c
new file mode 100644
index 000..067fd8c
--- /dev/null
+++ b/libavcodec/mips/vp9_lpf_msa.c
@@ -0,0 +1,2503 @@
+/*
+ * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *
+ * 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 "libavcodec/vp9dsp.h"
+#include "libavutil/mips/generic_macros_msa.h"
+#include "vp9dsp_mips.h"
+
+#define VP9_LPF_FILTER4_8W(p1_in, p0_in, q0_in, q1_in, mask_in, hev_in,  \
+   p1_out, p0_out, q0_out, q1_out)   \
+{\
+v16i8 p1_m, p0_m, q0_m, q1_m, q0_sub_p0, filt_sign;  \
+v16i8 filt, filt1, filt2, cnst4b, cnst3b;\
+v8i16 q0_sub_p0_r, filt_r, cnst3h;   \
+ \
+p1_m = (v16i8) __msa_xori_b(p1_in, 0x80);\
+p0_m = (v16i8) __msa_xori_b(p0_in, 0x80);\
+q0_m = (v16i8) __msa_xori_b(q0_in, 0x80);\
+q1_m = (v16i8) __msa_xori_b(q1_in, 0x80);\
+ \
+filt = __msa_subs_s_b(p1_m, q1_m);   \
+filt = filt & (v16i8) hev_in;\
+q0_sub_p0 = q0_m - p0_m; \
+filt_sign = __msa_clti_s_b(filt, 0); \
+ \
+cnst3h = __msa_ldi_h(3); \
+q0_sub_p0_r = (v8i16) __msa_ilvr_b(q0_sub_p0, q0_sub_p0);\
+q0_sub_p0_r = __msa_dotp_s_h((v16i8) q0_sub_p0_r, (v16i8) cnst3h);   \
+filt_r = (v8i16) __msa_ilvr_b(filt_sign, filt);  \
+filt_r += q0_sub_p0_r;   \
+filt_r = __msa_sat_s_h(filt_r, 7);   \
+ \
+/* combine left and right part */\
+filt = __msa_pckev_b((v16i8) filt_r, (v16i8) filt_r);\
+ \
+filt = filt & (v16i8) mask_in;   \
+cnst4b = __msa_ldi_b(4); \
+filt1 = __msa_adds_s_b(filt, cnst4b);\
+filt1 >>= 3; \
+ \
+   

Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> +break;

break removed locally.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 02:24:43PM +0300, Ivan Uskov wrote:
> Hello All,
> 
> There is another place into libavcodec/qsvenc.c where height may be
> aligned to 32 for the case when alignment to 16 is enough. It can be
> reason of superfluous frame copying. The attached patch does solve
> this issue. Please review.

does not apply cleanly

Applying: libavcodec/qsvenc.c: Fix for too agressive height alignment during 
frame encoding which may be reason of superflous frame copying.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging libavcodec/qsvenc.h
Auto-merging libavcodec/qsvenc.c
CONFLICT (content): Merge conflict in libavcodec/qsvenc.c
Failed to merge in the changes.
Patch failed at 0001 libavcodec/qsvenc.c: Fix for too agressive height 
alignment during frame encoding which may be reason of superflous frame copying.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Do not check the table number before warning about the precision

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 01:26:23AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Imo, the precision check in rtpenc_jpeg.c is wrong: Only the upper four bits 
> contain the precision, the lower four bits are the table number.
> 
> Please review, Carl Eugen

LGTM

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout

[Hendrik Leppkes]

On Thu, Jul 9, 2015 at 1:32 PM, wm4  wrote:
> On Tue,  7 Jul 2015 03:06:24 -0300
> James Almer  wrote:
>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/libdcadec.c | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
>> index 4bc3765..796826e 100644
>> --- a/libavcodec/libdcadec.c
>> +++ b/libavcodec/libdcadec.c
>> @@ -36,6 +36,8 @@ typedef struct DCADecContext {
>>  int buffer_size;
>>  } DCADecContext;
>>
>> +static int downmix_warned = 0;
>> +
>>  static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
>> int *got_frame_ptr, AVPacket *avpkt)
>>  {
>> @@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx, 
>> void *data,
>>  if (exss = dcadec_context_get_exss_info(s->ctx)) {
>>  enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
>>
>> +if (!downmix_warned) {
>> +uint64_t layout = avctx->request_channel_layout;
>> +
>> +if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout == 
>> AV_CH_LAYOUT_STEREO) && !exss->embedded_stereo) ||
>> +( layout == AV_CH_LAYOUT_5POINT1 && !exss->embedded_6ch))
>> +av_log(avctx, AV_LOG_WARNING, "%s downmix was requested but 
>> no custom coefficients are available, "
>> +  "this may result in 
>> clipping\n",
>> +  layout == 
>> AV_CH_LAYOUT_5POINT1 ? "5.1" : "stereo");
>> +downmix_warned = 1;
>> +}
>> +
>
> What does this mean? Does this happen with FFmpeg's DCA decoder too?
>

It just means that the DCA stream has no embedded downmix
coefficients. It'll downmix using the default coeffs, which can mean
two things, 1) this was intended, and all is fine, 2) downmixing was
not considered, and it may clip.
Personally, I might like a mode where it would downmix if the coeffs
are available, and not downmix if not (so I can downmix clipping-safe
using av/swresample later).

The native decoder would have the same problem, but I don't know if it
even supports embedded downmixes properly.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout

[wm4]

On Tue,  7 Jul 2015 03:06:24 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavcodec/libdcadec.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
> index 4bc3765..796826e 100644
> --- a/libavcodec/libdcadec.c
> +++ b/libavcodec/libdcadec.c
> @@ -36,6 +36,8 @@ typedef struct DCADecContext {
>  int buffer_size;
>  } DCADecContext;
>  
> +static int downmix_warned = 0;
> +
>  static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
> int *got_frame_ptr, AVPacket *avpkt)
>  {
> @@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx, 
> void *data,
>  if (exss = dcadec_context_get_exss_info(s->ctx)) {
>  enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
>  
> +if (!downmix_warned) {
> +uint64_t layout = avctx->request_channel_layout;
> +
> +if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout == 
> AV_CH_LAYOUT_STEREO) && !exss->embedded_stereo) ||
> +( layout == AV_CH_LAYOUT_5POINT1 && !exss->embedded_6ch))
> +av_log(avctx, AV_LOG_WARNING, "%s downmix was requested but 
> no custom coefficients are available, "
> +  "this may result in 
> clipping\n",
> +  layout == AV_CH_LAYOUT_5POINT1 
> ? "5.1" : "stereo");
> +downmix_warned = 1;
> +}
> +

What does this mean? Does this happen with FFmpeg's DCA decoder too?

>  switch(exss->matrix_encoding) {
>  case DCADEC_MATRIX_ENCODING_SURROUND:
>  matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
> @@ -195,6 +208,27 @@ static av_cold int dcadec_init(AVCodecContext *avctx)
>  if (avctx->flags & CODEC_FLAG_BITEXACT)
>  flags |= DCADEC_FLAG_CORE_BIT_EXACT;
>  
> +if (avctx->request_channel_layout > 0 && avctx->request_channel_layout 
> != AV_CH_LAYOUT_NATIVE) {
> +switch (avctx->request_channel_layout) {
> +case AV_CH_LAYOUT_STEREO:
> +case AV_CH_LAYOUT_STEREO_DOWNMIX:
> +/* libdcadec ignores the 2ch flag if used alone when no custom 
> downmix coefficients
> +   are available, silently outputting a 5.1 downmix if possible 
> instead.
> +   Using both the 2ch and 6ch flags together forces a 2ch 
> downmix using default
> +   coefficients in such cases. This matches the behavior of the 
> 6ch flag when used
> +   alone, where a 5.1 downmix is generated if possible, 
> regardless of custom
> +   coefficients being available or not. */
> +flags |= DCADEC_FLAG_KEEP_DMIX_2CH | DCADEC_FLAG_KEEP_DMIX_6CH;
> +break;
> +case AV_CH_LAYOUT_5POINT1:
> +flags |= DCADEC_FLAG_KEEP_DMIX_6CH;
> +break;
> +default:
> +av_log(avctx, AV_LOG_WARNING, "Invalid 
> request_channel_layout\n");
> +break;
> +}
> +}
> +
>  s->ctx = dcadec_context_create(flags);
>  if (!s->ctx)
>  return AVERROR(ENOMEM);

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

Re: [FFmpeg-devel] [PATCH]Error out if mjpeg over rtp is not 4:2:0

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> Looking at rtpenc_jpeg: 422 is mentioned there.

Yes, it might work if you use the right encoder.

Patch withdrawn, I sent a new patch that adds an 
additional necessary check when sending mjpeg.

Carl Eugen

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

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello All,

There is another place into libavcodec/qsvenc.c where height may be
aligned to 32 for the case when alignment to 16 is enough. It can be
reason of superfluous frame copying. The attached patch does solve
this issue. Please review.
  

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

0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables

[Carl Eugen Hoyos]

Hi!

RFC 2435 requires standard Huffman tables when sending (m)jpeg over rtp.
Related to ticket #3823.

Please comment, Carl Eugen
diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index 7ee26c4..e9d09e9 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -21,6 +21,7 @@
 
 #include "libavcodec/bytestream.h"
 #include "libavcodec/mjpeg.h"
+#include "libavcodec/jpegtables.h"
 #include "libavutil/intreadwrite.h"
 #include "rtpenc.h"
 
@@ -81,6 +82,26 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
"Only 1x1 chroma blocks are supported. Aborted!\n");
 return;
 }
+} else if (buf[i + 1] == DHT) {
+if (   AV_RB16(&buf[i + 2]) < 418
+|| i + 420 >= size
+|| buf[i +   4] != 0x00
+|| buf[i +  33] != 0x01
+|| buf[i +  62] != 0x10
+|| buf[i + 241] != 0x11
+|| memcmp(buf + i +   5, avpriv_mjpeg_bits_dc_luminance   + 1, 
16)
+|| memcmp(buf + i +  21, avpriv_mjpeg_val_dc, 12)
+|| memcmp(buf + i +  34, avpriv_mjpeg_bits_dc_chrominance + 1, 
16)
+|| memcmp(buf + i +  50, avpriv_mjpeg_val_dc, 12)
+|| memcmp(buf + i +  63, avpriv_mjpeg_bits_ac_luminance   + 1, 
16)
+|| memcmp(buf + i +  79, avpriv_mjpeg_val_ac_luminance, 162)
+|| memcmp(buf + i + 242, avpriv_mjpeg_bits_ac_chrominance + 1, 
16)
+|| memcmp(buf + i + 258, avpriv_mjpeg_val_ac_chrominance, 
162)) {
+av_log(s1, AV_LOG_ERROR,
+   "Only standard Huffman tables are supported\n");
+return;
+}
+break;
 } else if (buf[i + 1] == SOS) {
 /* SOS is last marker in the header */
 i += AV_RB16(&buf[i + 2]) + 2;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: Move return code setting code to the error cases

[Michael Niedermayer]

On Thu, Jul 09, 2015 at 12:47:25AM -0300, James Almer wrote:
> On 09/07/15 12:26 AM, Michael Niedermayer wrote:
> > Iam not sure this is better or worse than before
> > What do people prefer ?
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevc_ps.c |9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 1038516..372081a 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -998,7 +998,6 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
> > unsigned int *sps_id,
> >   sps, 0)) < 0)
> >  goto err;
> >  }
> > -ret = AVERROR_INVALIDDATA;
> >  
> >  sps->long_term_ref_pics_present_flag = get_bits1(gb);
> >  if (sps->long_term_ref_pics_present_flag) {
> > @@ -1006,6 +1005,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext 
> > *gb, unsigned int *sps_id,
> >  if (sps->num_long_term_ref_pics_sps > 31U) {
> >  av_log(avctx, AV_LOG_ERROR, "num_long_term_ref_pics_sps %d is 
> > out of range.\n",
> > sps->num_long_term_ref_pics_sps);
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  for (i = 0; i < sps->num_long_term_ref_pics_sps; i++) {
> > @@ -1096,6 +1096,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext 
> > *gb, unsigned int *sps_id,
> >  
> >  if (sps->log2_ctb_size > MAX_LOG2_CTB_SIZE) {
> >  av_log(avctx, AV_LOG_ERROR, "CTB size out of range: 2^%d\n", 
> > sps->log2_ctb_size);
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  if (sps->log2_ctb_size < 4) {
> > @@ -1104,6 +1105,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext 
> > *gb, unsigned int *sps_id,
> > "log2_ctb_size %d differs from the bounds of any known 
> > profile\n",
> > sps->log2_ctb_size);
> >  avpriv_request_sample(avctx, "log2_ctb_size %d", 
> > sps->log2_ctb_size);
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  
> > @@ -1124,29 +1126,34 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext 
> > *gb, unsigned int *sps_id,
> >  if (av_mod_uintp2(sps->width, sps->log2_min_cb_size) ||
> >  av_mod_uintp2(sps->height, sps->log2_min_cb_size)) {
> >  av_log(avctx, AV_LOG_ERROR, "Invalid coded frame dimensions.\n");
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  
> >  if (sps->max_transform_hierarchy_depth_inter > sps->log2_ctb_size - 
> > sps->log2_min_tb_size) {
> >  av_log(avctx, AV_LOG_ERROR, "max_transform_hierarchy_depth_inter 
> > out of range: %d\n",
> > sps->max_transform_hierarchy_depth_inter);
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  if (sps->max_transform_hierarchy_depth_intra > sps->log2_ctb_size - 
> > sps->log2_min_tb_size) {
> >  av_log(avctx, AV_LOG_ERROR, "max_transform_hierarchy_depth_intra 
> > out of range: %d\n",
> > sps->max_transform_hierarchy_depth_intra);
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  if (sps->log2_max_trafo_size > FFMIN(sps->log2_ctb_size, 5)) {
> >  av_log(avctx, AV_LOG_ERROR,
> > "max transform block size out of range: %d\n",
> > sps->log2_max_trafo_size);
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  
> >  if (get_bits_left(gb) < 0) {
> >  av_log(avctx, AV_LOG_ERROR,
> > "Overread SPS by %d bits\n", -get_bits_left(gb));
> > +ret = AVERROR_INVALIDDATA;
> >  goto err;
> >  }
> >  
> 
> Why not just replace every "goto err" with a return AVERROR_INVALIDDATA? The 
> gotos
> seem pointless considering the only code after it is "return ret". No memory 
> being
> freed and nothing being uninitialized to justify them.

hmm, ive missed that somehow
done that

thanks

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

[FFmpeg-devel] [PATCH 1/2] avcodec: loongson optimized h264pred with mmi

[周晓勇]

Hi, Michael.

did you install the new FC21 and is there any problem when installing?
the installation maybe freted, but worth.
i add ".set arch=loongson3a" for last h264pred patch to pass compiling on 
FC19-O32, and fate success in both FC19-O32 and FC21-N64.
i think it's ok to use ".set arch=loongson3a" to bypass using dli in 
O32-system, as
these codes only for loongson3 cpu, and 3A, 3B use same option 
-march=loongson3a to enable mmi.




---
From f378ba9b5d15495f8fcb93e049ee3538b744ecba Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong 
Date: Thu, 9 Jul 2015 10:59:12 +0800
Subject: [PATCH 1/2] avcodec: loongson optimized h264pred with mmi


Signed-off-by: ZhouXiaoyong 
---
 libavcodec/mips/Makefile |   1 +
 libavcodec/mips/h264pred_init_mips.c |  53 +++
 libavcodec/mips/h264pred_mips.h  |  53 +++
 libavcodec/mips/h264pred_mmi.c   | 804 +++
 4 files changed, 911 insertions(+)


diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 5569a03..c16c93a 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -58,3 +58,4 @@ MSA-OBJS-$(CONFIG_MPEGVIDEOENC)   += 
mips/mpegvideoencdsp_msa.o
 MSA-OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_msa.o
 MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
 MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
+MMI-OBJS-$(CONFIG_H264PRED)   += mips/h264pred_mmi.o
diff --git a/libavcodec/mips/h264pred_init_mips.c 
b/libavcodec/mips/h264pred_init_mips.c
index 27ff10f..a2124ec 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *Zhou Xiaoyong 
  *
  * This file is part of FFmpeg.
  *
@@ -20,6 +21,7 @@
 
 #include "config.h"
 #include "h264dsp_mips.h"
+#include "h264pred_mips.h"
 
 #if HAVE_MSA
 static av_cold void h264_pred_init_msa(H264PredContext *h, int codec_id,
@@ -94,6 +96,54 @@ static av_cold void h264_pred_init_msa(H264PredContext *h, 
int codec_id,
 }
 #endif  // #if HAVE_MSA
 
+#if HAVE_MMI
+static av_cold void h264_pred_init_mmi(H264PredContext *h, int codec_id,
+const int bit_depth, const int chroma_format_idc)
+{
+if (bit_depth == 8) {
+if (chroma_format_idc == 1) {
+h->pred8x8  [VERT_PRED8x8   ] = ff_pred8x8_vertical_8_mmi;
+h->pred8x8  [HOR_PRED8x8] = ff_pred8x8_horizontal_8_mmi;
+} else {
+h->pred8x8  [VERT_PRED8x8   ] = ff_pred8x16_vertical_8_mmi;
+h->pred8x8  [HOR_PRED8x8] = ff_pred8x16_horizontal_8_mmi;
+}
+
+h->pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_8_mmi;
+h->pred16x16[VERT_PRED8x8   ] = ff_pred16x16_vertical_8_mmi;
+h->pred16x16[HOR_PRED8x8] = ff_pred16x16_horizontal_8_mmi;
+h->pred8x8l [TOP_DC_PRED] = ff_pred8x8l_top_dc_8_mmi;
+h->pred8x8l [DC_PRED] = ff_pred8x8l_dc_8_mmi;
+h->pred8x8l [HOR_PRED   ] = ff_pred8x8l_horizontal_8_mmi;
+
+switch (codec_id) {
+case AV_CODEC_ID_SVQ3:
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_svq3_8_mmi;
+;
+break;
+case AV_CODEC_ID_RV40:
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_rv40_8_mmi;
+;
+break;
+case AV_CODEC_ID_VP7:
+case AV_CODEC_ID_VP8:
+;
+break;
+default:
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_h264_8_mmi;
+break;
+}
+
+if (codec_id == AV_CODEC_ID_SVQ3 || codec_id == AV_CODEC_ID_H264) {
+if (chroma_format_idc == 1) {
+h->pred8x8[TOP_DC_PRED8x8   ] = ff_pred8x8_top_dc_8_mmi;
+h->pred8x8[DC_PRED8x8   ] = ff_pred8x8_dc_8_mmi;
+}
+}
+}
+}
+#endif /* HAVE_MMI */
+
 av_cold void ff_h264_pred_init_mips(H264PredContext *h, int codec_id,
 int bit_depth,
 const int chroma_format_idc)
@@ -101,4 +151,7 @@ av_cold void ff_h264_pred_init_mips(H264PredContext *h, int 
codec_id,
 #if HAVE_MSA
 h264_pred_init_msa(h, codec_id, bit_depth, chroma_format_idc);
 #endif  // #if HAVE_MSA
+#if HAVE_MMI
+h264_pred_init_mmi(h, codec_id, bit_depth, chroma_format_idc);
+#endif /* HAVE_MMI */
 }
diff --git a/libavcodec/mips/h264pred_mips.h b/libavcodec/mips/h264pred_mips.h
new file mode 100644
index 000..16bf6fc
--- /dev/null
+++ b/libavcodec/mips/h264pred_mips.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong 
+ *
+ * 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

[FFmpeg-devel] [PATCH 2/2] avcodec: loongson optimized mpegvideo dct unquantize with mmi

[周晓勇]

From 86f901e61532d3c06dbd93e15d47a66b119c44f8 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong 
Date: Thu, 9 Jul 2015 14:34:21 +0800
Subject: [PATCH 2/2] avcodec: loongson optimized mpegvideo dct unquantize with
 mmi


Signed-off-by: ZhouXiaoyong 
---
 libavcodec/mips/Makefile  |   1 +
 libavcodec/mips/mpegvideo_init_mips.c |  14 ++
 libavcodec/mips/mpegvideo_mips.h  |  35 
 libavcodec/mips/mpegvideo_mmi.c   | 303 ++
 4 files changed, 353 insertions(+)


diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index c16c93a..9eb815a 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -59,3 +59,4 @@ MSA-OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_msa.o
 MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
 MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
 MMI-OBJS-$(CONFIG_H264PRED)   += mips/h264pred_mmi.o
+MMI-OBJS-$(CONFIG_MPEGVIDEO)  += mips/mpegvideo_mmi.o
diff --git a/libavcodec/mips/mpegvideo_init_mips.c 
b/libavcodec/mips/mpegvideo_init_mips.c
index ee14b31..85a833c 100644
--- a/libavcodec/mips/mpegvideo_init_mips.c
+++ b/libavcodec/mips/mpegvideo_init_mips.c
@@ -19,6 +19,7 @@
  */
 
 #include "h263dsp_mips.h"
+#include "mpegvideo_mips.h"
 
 #if HAVE_MSA
 static av_cold void dct_unquantize_init_msa(MpegEncContext *s)
@@ -29,9 +30,22 @@ static av_cold void dct_unquantize_init_msa(MpegEncContext 
*s)
 }
 #endif  // #if HAVE_MSA
 
+#if HAVE_MMI
+static av_cold void dct_unquantize_init_mmi(MpegEncContext *s)
+{
+s->dct_unquantize_h263_intra = ff_dct_unquantize_h263_intra_mmi;
+s->dct_unquantize_h263_inter = ff_dct_unquantize_h263_inter_mmi;
+s->dct_unquantize_mpeg1_intra = ff_dct_unquantize_mpeg1_intra_mmi;
+s->dct_unquantize_mpeg1_inter = ff_dct_unquantize_mpeg1_inter_mmi;
+}
+#endif /* HAVE_MMI */
+
 av_cold void ff_mpv_common_init_mips(MpegEncContext *s)
 {
 #if HAVE_MSA
 dct_unquantize_init_msa(s);
 #endif  // #if HAVE_MSA
+#if HAVE_MMI
+dct_unquantize_init_mmi(s);
+#endif /* HAVE_MMI */
 }
diff --git a/libavcodec/mips/mpegvideo_mips.h b/libavcodec/mips/mpegvideo_mips.h
new file mode 100644
index 000..dbcea6a
--- /dev/null
+++ b/libavcodec/mips/mpegvideo_mips.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong 
+ *
+ * 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
+ */
+
+#ifndef MPEGVIDEO_MIPS_H
+#define MPEGVIDEO_MIPS_H
+
+#include "libavcodec/mpegvideo.h"
+
+void ff_dct_unquantize_h263_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_h263_inter_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_mpeg1_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_mpeg1_inter_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+
+#endif /* MPEGVIDEO_MIPS_H */
diff --git a/libavcodec/mips/mpegvideo_mmi.c b/libavcodec/mips/mpegvideo_mmi.c
new file mode 100644
index 000..b3d58bd
--- /dev/null
+++ b/libavcodec/mips/mpegvideo_mmi.c
@@ -0,0 +1,303 @@
+/*
+ * Loongson SIMD optimized mpegvideo
+ *
+ * Copyright (c) 2015 Loongson Technology Corporation Limited
+ * Copyright (c) 2015 Zhou Xiaoyong 
+ *Zhang Shuangshuang 
+ *
+ * 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 "mpegvideo_mips.h"
+
+void ff_dct_unquantize_h263_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale)
+{
+int64_t level, qmul, qadd, nCoeffs;
+
+ 

[FFmpeg-devel] [PATCH 1/2] avcodec: loongson optimized h264pred with mmi

[周晓勇]

Hi, Michael.
did you install the new FC21 and is there any problem when installing?
the installation maybe freted, but worth.
i add ".set arch=loongson3a" for last h264pred patch to pass compiling on 
FC19-O32, and fate success in both FC19-O32 and FC21-N64.
i think it's ok to use ".set arch=loongson3a" to bypass using dli in 
O32-system, as
these codes only for loongson3 cpu, and 3A, 3B use same option 
-march=loongson3a to enable mmi.




---
From f378ba9b5d15495f8fcb93e049ee3538b744ecba Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong 
Date: Thu, 9 Jul 2015 10:59:12 +0800
Subject: [PATCH 1/2] avcodec: loongson optimized h264pred with mmi


Signed-off-by: ZhouXiaoyong 
---
 libavcodec/mips/Makefile |   1 +
 libavcodec/mips/h264pred_init_mips.c |  53 +++
 libavcodec/mips/h264pred_mips.h  |  53 +++
 libavcodec/mips/h264pred_mmi.c   | 804 +++
 4 files changed, 911 insertions(+)


diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 5569a03..c16c93a 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -58,3 +58,4 @@ MSA-OBJS-$(CONFIG_MPEGVIDEOENC)   += 
mips/mpegvideoencdsp_msa.o
 MSA-OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_msa.o
 MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
 MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
+MMI-OBJS-$(CONFIG_H264PRED)   += mips/h264pred_mmi.o
diff --git a/libavcodec/mips/h264pred_init_mips.c 
b/libavcodec/mips/h264pred_init_mips.c
index 27ff10f..a2124ec 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *Zhou Xiaoyong 
  *
  * This file is part of FFmpeg.
  *
@@ -20,6 +21,7 @@
 
 #include "config.h"
 #include "h264dsp_mips.h"
+#include "h264pred_mips.h"
 
 #if HAVE_MSA
 static av_cold void h264_pred_init_msa(H264PredContext *h, int codec_id,
@@ -94,6 +96,54 @@ static av_cold void h264_pred_init_msa(H264PredContext *h, 
int codec_id,
 }
 #endif  // #if HAVE_MSA
 
+#if HAVE_MMI
+static av_cold void h264_pred_init_mmi(H264PredContext *h, int codec_id,
+const int bit_depth, const int chroma_format_idc)
+{
+if (bit_depth == 8) {
+if (chroma_format_idc == 1) {
+h->pred8x8  [VERT_PRED8x8   ] = ff_pred8x8_vertical_8_mmi;
+h->pred8x8  [HOR_PRED8x8] = ff_pred8x8_horizontal_8_mmi;
+} else {
+h->pred8x8  [VERT_PRED8x8   ] = ff_pred8x16_vertical_8_mmi;
+h->pred8x8  [HOR_PRED8x8] = ff_pred8x16_horizontal_8_mmi;
+}
+
+h->pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_8_mmi;
+h->pred16x16[VERT_PRED8x8   ] = ff_pred16x16_vertical_8_mmi;
+h->pred16x16[HOR_PRED8x8] = ff_pred16x16_horizontal_8_mmi;
+h->pred8x8l [TOP_DC_PRED] = ff_pred8x8l_top_dc_8_mmi;
+h->pred8x8l [DC_PRED] = ff_pred8x8l_dc_8_mmi;
+h->pred8x8l [HOR_PRED   ] = ff_pred8x8l_horizontal_8_mmi;
+
+switch (codec_id) {
+case AV_CODEC_ID_SVQ3:
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_svq3_8_mmi;
+;
+break;
+case AV_CODEC_ID_RV40:
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_rv40_8_mmi;
+;
+break;
+case AV_CODEC_ID_VP7:
+case AV_CODEC_ID_VP8:
+;
+break;
+default:
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_h264_8_mmi;
+break;
+}
+
+if (codec_id == AV_CODEC_ID_SVQ3 || codec_id == AV_CODEC_ID_H264) {
+if (chroma_format_idc == 1) {
+h->pred8x8[TOP_DC_PRED8x8   ] = ff_pred8x8_top_dc_8_mmi;
+h->pred8x8[DC_PRED8x8   ] = ff_pred8x8_dc_8_mmi;
+}
+}
+}
+}
+#endif /* HAVE_MMI */
+
 av_cold void ff_h264_pred_init_mips(H264PredContext *h, int codec_id,
 int bit_depth,
 const int chroma_format_idc)
@@ -101,4 +151,7 @@ av_cold void ff_h264_pred_init_mips(H264PredContext *h, int 
codec_id,
 #if HAVE_MSA
 h264_pred_init_msa(h, codec_id, bit_depth, chroma_format_idc);
 #endif  // #if HAVE_MSA
+#if HAVE_MMI
+h264_pred_init_mmi(h, codec_id, bit_depth, chroma_format_idc);
+#endif /* HAVE_MMI */
 }
diff --git a/libavcodec/mips/h264pred_mips.h b/libavcodec/mips/h264pred_mips.h
new file mode 100644
index 000..16bf6fc
--- /dev/null
+++ b/libavcodec/mips/h264pred_mips.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong 
+ *
+ * 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 

[FFmpeg-devel] [PATCH] fate: add removegrain tests

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 tests/fate/filter-video.mak   | 78 +++
 tests/ref/fate/filter-removegrain-mode-00 |  2 +
 tests/ref/fate/filter-removegrain-mode-01 |  2 +
 tests/ref/fate/filter-removegrain-mode-02 |  2 +
 tests/ref/fate/filter-removegrain-mode-03 |  2 +
 tests/ref/fate/filter-removegrain-mode-04 |  2 +
 tests/ref/fate/filter-removegrain-mode-05 |  2 +
 tests/ref/fate/filter-removegrain-mode-06 |  2 +
 tests/ref/fate/filter-removegrain-mode-07 |  2 +
 tests/ref/fate/filter-removegrain-mode-08 |  2 +
 tests/ref/fate/filter-removegrain-mode-09 |  2 +
 tests/ref/fate/filter-removegrain-mode-10 |  2 +
 tests/ref/fate/filter-removegrain-mode-11 |  2 +
 tests/ref/fate/filter-removegrain-mode-12 |  2 +
 tests/ref/fate/filter-removegrain-mode-13 |  2 +
 tests/ref/fate/filter-removegrain-mode-14 |  2 +
 tests/ref/fate/filter-removegrain-mode-15 |  2 +
 tests/ref/fate/filter-removegrain-mode-16 |  2 +
 tests/ref/fate/filter-removegrain-mode-17 |  2 +
 tests/ref/fate/filter-removegrain-mode-18 |  2 +
 tests/ref/fate/filter-removegrain-mode-19 |  2 +
 tests/ref/fate/filter-removegrain-mode-20 |  2 +
 tests/ref/fate/filter-removegrain-mode-21 |  2 +
 tests/ref/fate/filter-removegrain-mode-22 |  2 +
 tests/ref/fate/filter-removegrain-mode-23 |  2 +
 tests/ref/fate/filter-removegrain-mode-24 |  2 +
 26 files changed, 128 insertions(+)
 create mode 100644 tests/ref/fate/filter-removegrain-mode-00
 create mode 100644 tests/ref/fate/filter-removegrain-mode-01
 create mode 100644 tests/ref/fate/filter-removegrain-mode-02
 create mode 100644 tests/ref/fate/filter-removegrain-mode-03
 create mode 100644 tests/ref/fate/filter-removegrain-mode-04
 create mode 100644 tests/ref/fate/filter-removegrain-mode-05
 create mode 100644 tests/ref/fate/filter-removegrain-mode-06
 create mode 100644 tests/ref/fate/filter-removegrain-mode-07
 create mode 100644 tests/ref/fate/filter-removegrain-mode-08
 create mode 100644 tests/ref/fate/filter-removegrain-mode-09
 create mode 100644 tests/ref/fate/filter-removegrain-mode-10
 create mode 100644 tests/ref/fate/filter-removegrain-mode-11
 create mode 100644 tests/ref/fate/filter-removegrain-mode-12
 create mode 100644 tests/ref/fate/filter-removegrain-mode-13
 create mode 100644 tests/ref/fate/filter-removegrain-mode-14
 create mode 100644 tests/ref/fate/filter-removegrain-mode-15
 create mode 100644 tests/ref/fate/filter-removegrain-mode-16
 create mode 100644 tests/ref/fate/filter-removegrain-mode-17
 create mode 100644 tests/ref/fate/filter-removegrain-mode-18
 create mode 100644 tests/ref/fate/filter-removegrain-mode-19
 create mode 100644 tests/ref/fate/filter-removegrain-mode-20
 create mode 100644 tests/ref/fate/filter-removegrain-mode-21
 create mode 100644 tests/ref/fate/filter-removegrain-mode-22
 create mode 100644 tests/ref/fate/filter-removegrain-mode-23
 create mode 100644 tests/ref/fate/filter-removegrain-mode-24

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index f502c45..87af23b 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -129,6 +129,84 @@ fate-filter-overlay_yuv444: CMD = framecrc -c:v pgmyuv -i 
$(SRC) -filter_complex
 FATE_FILTER_VSYNTH-$(CONFIG_PHASE_FILTER) += fate-filter-phase
 fate-filter-phase: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf phase
 
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-00
+fate-filter-removegrain-mode-00: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=0:0:0
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-01
+fate-filter-removegrain-mode-01: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=1:1:1
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-02
+fate-filter-removegrain-mode-02: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=2:2:2
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-03
+fate-filter-removegrain-mode-03: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=3:3:3
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-04
+fate-filter-removegrain-mode-04: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=4:4:4
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-05
+fate-filter-removegrain-mode-05: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=5:5:5
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-06
+fate-filter-removegrain-mode-06: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=6:6:6
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-07
+fate-filter-removegrain-mode-07: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=7:7:7
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-08
+fate-filter-removegrain-mode-08: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=8:8:8
+
+FATE_REMOVEGRAIN += fate-filter-removegrain-mode-09
+fate-filter-removegrain-mode-09: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 
1 -vf removegrain=9:9:9
+
+FATE_REMOVEGRAIN += fate-filter-removegrai

[FFmpeg-devel] [PATCH] configure: try to fix \r when build for android on cygwin

[Zhang Rui]

---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 5833808..46c4788 100755
--- a/configure
+++ b/configure
@@ -475,7 +475,7 @@ sh_quote(){
 }
 
 cleanws(){
-echo "$@" | sed 's/^ *//;s/  */ /g;s/ *$//;s/\\r//g'
+echo "$@" | sed "s/^ *//;s/  */ /g;s/ *$//;s/\\r//g"
 }
 
 filter(){
-- 
2.0.0

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